Casper and Sharding Merger Confirmed, Constantinople Back on the Table

0

Ethereum developers have now confirmed a change in the roadmap that effectively deprecates 1,500 eth Casper FFG in favor of 32 eth Casper.

In an extensive developers update, Raul Jordan from Prysmatic labs said they had finished minimal sharding protocol implementation. There are proposer and notaries performing their responsibilities, he said, and they are researching random beacon chains, dynamic shard count properties, but since they are in flux, they’re trying to be as scrappy and as efficient as possible.

They may be ready for a Proof of Concept release. “That’s where we are,” he said, trying to get something that works and is in line with current spec.

In response to a question by Vitalik Buterin, ethereum’s inventor, Jordan said they haven’t figured out reorgs, with the current design gossiped through the same net, rather than in a peer to peer network. Not trying to do anything that would be disrupted by changes on the research side, he said.

Vitalik Buterin said Casper FFG as a smart contract is out, in favor of a Casper which runs on a beacon chain, links to the main chain, can be used to finalize the main chain without being directly inside the main chain.

The only contract in the roadmap is a contract to call a function to send 32 eth, all else processed by the rest of the system.

Functionality, in the short term, similar to Casper FFG as a contract, except for the one way mechanism whereby if you deposit 32 eth for staking, the 32 eth can not be withdrawn until a hardfork implements states and so allows withdrawal into a shard. 

The beacon chain is Proof of Stake (POS). All blocks in PoS reference the main chain blocks. If PoS finalizes, it points to a main chain block, so gets indirectly confirmed.

This simplification removes the need to have one infrastructure for casper and another for sharding because there is only one validator from the start, so it is directly on route of what we expect later stages of sharding to look like.

Once the beacon chain is fully operation and sharding is enabled, the beacon chain would be the main chain of the sharding system. Therefore much work would not need to be redone all over again to move from partial casper to full casper and sharding.

The algorithm for Casper FFG is kept roughly the same, but implemented in native code rather than in vyper, pushes us towards a final product sharding system.

Justin Drake, an ethereum developer, said it is fair to say casper and sharding have effectively merged, but while the design is simplified, it is possible for casper to come before sharding. It is more likely casper comes before sharding, he said.

Explaining this change in roadmap he said it offers more security as there will be no withdrawals until state, allowing developers to feel safer and thus experiment more easily.

As it is not a contract, developers won’t need to worry about gas, gas limits, and whether they got it all right.

It is more future proof, he said. The end goal is to deprecate the Ethereum Virtual Machine (EVM) 1.0, so it is much closer to the final design.

It unlocks new functionality, BLC signature stuff, he said. Then added the beacon chain will have 5 second blocks.

There will be more unity between casper/sharding teams, he said. And the simplified structure means more security because if you want to be a validator you have to validate both casper and shards. So if developers get the parameters wrong where it is profitable to validate casper but not shards, well in this design they have no choice but to validate both.

He then spoke about a new technical aspect called custody bonds. Validators voting on a shard block, we can trust their votes, he said, or we have custody bond when you make a vote, there are cryptoeconomics aspects which incentivizes you to have custody of the data you are voting for.

Vitalik Buterin shared an interesting link with quite a bit of code for those more technically inclined. We’ll quote below the general introductory part at some length:

Full Casper chain v2

This is the work-in-progress document describing the specification for the Casper+Sharding chain, version 2.

Unlike the earlier version, which heavily relied on the existing Ethereum Proof of Work (PoW) chain as a central chain, this spec uses as its base a full proof of stake chain based on a RANDAO beacon, attestations and the Casper FFG mechanism, with a relatively simple tie to the main PoW chain, including block referencing and one-way deposits.

Broad description of structure

There is a central PoS chain which stores and manages the current set of active PoS validators. The only mechanism available to become a validator initially is to send a transaction on the existing PoW main chain burning 32 ETH.

When you do so, as soon as the PoS chain processes that block, you will be queued, and eventually inducted as an active validator until you either voluntarily log out or you are forcibly logged out as a penalty for misbehavior.

The primary source of load on the PoS chain is cross-links. A cross-link is a special type of transaction that says “here is the hash of some recent block on shard X. Here are signatures from at least 2/3 of some randomly selected sample of M validators (eg. M = 1024) that attest to the validity of the cross-link”.

Every shard (eg. there might be 4000 shards total) is itself a PoS chain, and the shard chains are where the transactions and accounts will be stored.

The cross-links serve to “confirm” segments of the shard chains into the main chain, and are also the primary way through which the different shards will be able to talk to each other.”

Dates were not discussed except for pretty much an expression of certainty that all of this won’t be out this year. So Constantinople was brought back on the table, with Hudson Jameson, an ethereum developer, stating they can probably do the Metropolis Constantinople hardfork between now and Devcon. That being within five months.

They have to finalize what exactly goes in it, with the upgrade having some nice things for developers that can increase functionality, but nothing structurally changing.

While sharding v.2 will pretty much transform the base layer. We’d like to think it will come out next year, but we’re not going to give any estimates any more until they confirm a block number except to say we have self-imposed on them a deadline of 2020 which we are sure no one takes seriously.

The most interesting part to come out of this, and while there is plenty of new information, is the suggestion that confirmation times may be reduced to five seconds.

That has been the aim for a long time, but for years it wasn’t mentioned any longer until now. As the beacon chain is linked to the PoW chain with one beacon chain having one corresponding PoW block, you’d think this 5 seconds aim applies holistically, rather than to just the beacon chain.

But just how exactly all of this narrates together is for another day or presentation by Vitalik Buterin who sort of acts as the spokesperson for the entire ethereum development team.

From what sense we can make, however, it looks like the base structure is there and sort of fits together with development clearly moving pretty fast as they race to turn ethereum 1.0 to something we can say is ready.

By that we mean a decentralized public blockchain that can handle considerable demand comparable to the shift from dial-up to the very, very, early versions of broadband internet.

Copyrights Trustnodes.com

 

Leave a Reply

100000
  Subscribe  
Notify of