Editor's note:Editor's note:MediumRecently, "Ethereum Constantinople Fork" has become a hot topic in the blockchain field, and as a planned alternative to Ethereum, the real "hard dish" - ETH2.0 will gradually reveal its face. Putting aside the interpretation of boring term definitions, James Prestwich discusses the current Ethereum roadmap. At the same time, he opened his mind and imagined the possible direction of the later stage of Ethereum in these specific discussions. article from
, the following is the full text of the compilation.
Editor | Lu Xiaoming
Editor | Lu Xiaoming
secondary title
What is ETH2.0?
ETH2.0 is the planned alternative to Ethereum. In the next few years, the developers of ETH2.0 intend to fully incorporate the current consensus system and state of Ethereum. Because its scope is so broad, we also cannot convey exactly what ETH2.0 will or will not include. Indeed, we've built some working specs, and there's a fair amount of team effort working on an early implementation. ETH2.0 developers tentatively plan to include sharding technology (Sharding), Casper protocol, state lease (State Rent), and the upgrade project eWASM of the Ethereum virtual machine EVM.Today, the ETH2.0 initial client has been tested online, and it is expectedwithin three months, ETH2.0 will allow the Ethereum in the Ethereum chain to be mapped to the past, but the ETH2.0 designer eventually plans to change this by making ETH2.0 the main chain and Ethereum 1.X a branch chain under its management. situation.
secondary title
What does it mean for an engineer?If you are a professional Solidity programmer or Dapp developer, and you are a "die-hard fan" of deploying ETH2.0 smart contracts. Well, you may need to do a lot of update iterations. ETH2.0 is a complete replacement for Ethereum that will overturn many of the assumptions we make when writing smart contracts. Its planned multi-year rollout feels less like an upgrade cycle and more like a product release cycle.The tools and smart contracts we wrote for ETH1.X may need to be reinvented
phased rollout
phased rollout
at present,at present,Sharding Roadmap(Twice the ETH2.0 roadmap) lists seven phases. onlyhave clear specifications, andRegularly updated。Regularly updatedPhase 1 Specificationare much less stringent, less accurate, and may be in thenegative development status
. From Phase 1 onwards, the roadmap becomes a list of goals rather than a technical document.ethresear.ch three times as many as linking to Github. Since any future steps are more speculation than engineering, our specific discussion is limited to phases 0, 1, and 2. At the same time, several rough outlines of possible directions for later stages are covered in these specific discussions.
first level title
Phase 0: The Beacon ChainPhase 0 introduces the "beacon chain",(Odaily Note: The beacon chain is a brand new blockchain, and it occupies a core position in the new Ethereum. One of the functions of this chain is to allow verifiers to participate in the pledge system, replace the role of miners and become a chain builder. Another function is to store the index of the shard state).
Clearly, early iterations like this "beacon chain" were designed to be as simple as possible, which is why phase 0 does not support smart contracts, accounts, asset transfers, nor does it include any sharding. At the same time, ether based on the beacon chain cannot be transferred on the chain, which means that users cannot deposit it on the exchange.
secondary title
BETH: The New Ether
As a new asset type, Beacon ETH (BETH) is only used by Stakers (coin holders or users) on the Beacon Chain. BETH can be created in the following two ways.
As a reward for validating the Beacon Chain (and shards after Phase 1);Any ETH1.X user can passETH1.X contract
Buy 1 ETH of BETH, the contract calls it "deposit/recharge" (Deposit).
Engineers may notice that there is no revocation functionality mentioned in the contract. This is due to Phase 0, where users cannot withdraw BETH from the Beacon Chain. That is to say, once the user is stored in the ETH1.X validator registration contract, the ETH1.X ether will be destroyed. Beacon chain verifiers will observe the contract and submit recharge information to the beacon chain, and the beacon chain will issue new BETH to recharge users.
Therefore, shortly after ETH is sent to the verification registration contract, the user will receive the corresponding amount of BETH issued by the beacon chain. During this process, the recharge can be temporarily reviewed, but according to the Casper protocol, it cannot be permanently reviewed.
In the past, some low-function Token projects like BETH have been traded on exchanges through IOUs. For example, during the Tezos crowdsale, it launched HitBit and BitMEX XTZ futures markets. Therefore, if there is a demand for BETH, we should be committed to building an exchange ecosystem that supports the trading and staking of managed BETH. However, users may have doubts about the current demand for BETH. Since the one-way peg from ETH to BETH results in a BETH price ceiling of 1 ETH, BETH is not an excellent investment target. In other words, BETH will never be worth more than ETH, and may even be worth less.
first level title
Stage 0+: staking
On the beacon chain, users can stake 32 BETH deposits to become validators. In phase 0, validators only need to manage the beacon chain; from the beginning of phase 1, validators will also manage 1024 shard chains while managing the beacon chain. The beacon chain and each shard chain will use Casper FFG to complete block generation. FFG is a proof-of-stake algorithm (Proof of Stake) that is used to implement penalties (ie, cut stakes) for bad behavior on the chain.Careful readers will find FFG's cousin Casper CBC in the "Ethereum 3.0" part of the sharding roadmap. Although a detailed interpretation of FFG (and of course CBC) is beyond the scope of this article. If you are interested, you can read Vitalik Buterin, founder of EthereumA Note on Hybrid PoW / FFGAbout Minimizing Cut ConditionsandFFG Papers。
secondary title
What do users (stakers) need to do?
The purpose of sharding is to split the state information of shards between nodes, without requiring any node to have a full picture of the network at the same time. Based on this, validators will not validate all shards. Instead, the beacon chain will coordinate the verification of other shards, and all validators will conduct the verification of the beacon chain.After a fixed period of time (64 blocks or about 6.4 minutes), the beacon chain will "check" the validators, and randomly assigns it toFragmentationFragmentation. A group of validators assigned to a shard is called a Committee, which includes128 membersMulti-stage random number generation processas well asas well asVerifiable delay function
, thereby being able to thwart attempts to manipulate the committee selection process.
The committee will be responsible for protecting the security, activity and integrity of its fragments, and at the same time, it is necessary to confirm (Attest) the state of the fragments on the beacon chain. The importance of its existence is self-evident, so ETH2.0 will be random Committee selection and frequent rotation of committee members. At the same time, this is the only way that the beacon chain can know the state of the shard, and vice versa.64。
secondary title
What are the implications of PoS proofs?Stateless Simplified Payment Verification (SPV)andandNon-Interactive Proof of Work (NIPoPoW)
In other words, a remote proof-of-state on proof-of-stake would contain roughly the same amount of data as a PoW stateless SPV verification, but require pre-verification of the entire PoS history. In contrast, stateless SPV verification does not require additional information for verification. This means that cross-shard or cross-chain applications have reduced functionality but increased overhead in a subjective proof-of-stake environment.
first level title
Phase 1: Sharding
Phase 1 aims to achieve consensus on the content of the shard chains, not on their meaning. In other words, this is a "trial run" of the sharding structure, rather than trying to use sharding for expansion (Scale). The beacon chain regards the shard chain as a collection of bits with no structure or simple meaning. Shard chains do not yet own accounts, assets, or smart contracts. Shard validators are randomly selected by the beacon chain for each epoch of shards. It simply agrees on the content of each block. It doesn't matter what information appears in the shard, as long as all committee members reach a consensus and regularly update the beacon chain on the shard.Through a process called crosslinking (Crosslinking), shard validators can verify the content and state of the shard. In simple terms, the committee must include verifiable information about the shard (e.g. root hash) in the beacon chain. In phase 2 or even higher, cross-link will support cross-shard communication (Cross-Shard Communication). Beacon chain receives a given crosslink from multiple committeesproof of accuracy
After that, the beacon chain can trust that the crosslink is a true representation of the shard without validating the entire shard. If the committee disagrees on the validity of the crosslink, i.e. it is clear that one of the committees is wrong, the validator should be slashed.
This is the root of security for all shards, i.e. misbehavior of their validators will eventually be discovered and punished by the beacon chain.
Interestingly, the implementation of Phase 0 is progressing at the same time as the development of the specification. Even now—less than three months away from the testnet—the Phase 0 specification is regularly revised. The estimation of the timeline also means that there will be great differences in the development time of the future ETH2.0 phase. Optimists tell me 6 months is enough, but it seems to me that after seeing Phase 0 go into testing, Phase 1 needs a 12- to 18-month development cycle.
first level title
Phase 2: Smart Contract eWASMUltimately, Phase 2 will lead to a system similar to the one we are familiar with on Ethereum. With the Phase 2 release, shard chains transition from simple data containers to structured chain states. At this point, the new BETH is transferable and smart contracts will be reintroduced. Each shard will be based on
(We'll call it "EVM2") manages a virtual machine.
State Rent may be included in Phase 2, which also poses some interesting challenges to current Solidity programming language engineers. Instead of storing code and data indefinitely, state leasing requires contract developers and users to pay for EVM2 storage over a period of time. Preventing state bloat by ensuring that unused information is out of state over time ultimately achieves its goal of having users pay state costs rather than entire nodes. People propose differentmodelmodel
, "A hundred schools of thought contend", but there is still no clear conclusion.with someEthereum Upgrade Planadvance, and the famousEthereum Core Developer
Also, we don't know where Phase 2 will end up, it's still in an early research phase and includes several major unresolved questions. Given the informal specification and development process, and the extension of Phase 2 to Phase 1. Starting Phase 2 before 2020 does not seem reasonable. In other words, although ETH2.0 may be launched this year, it is expected that the ETH2.0 version will not support asset transfers or smart contracts until at least 2020.
first level title
Phase 3: Off-chain state storage
Phase 3 minimizes on-chain state by moving as much state as possible off-chain. When storing on the chain, it is not necessary to store the entire state, but only some state information and aggregators (an aggregator is a short data representing a long data list; a Merkle tree is a kind of aggregator) are stored. Users will be responsible for storing the full state off-chain.
When a user interacts with the state, it includes a proof of the current state in the transaction. This way, the resource requirements for running a validator are much lower. A number of aggregator designs have emerged today with different features and performance characteristics, but no specific selection has been made so far. At this stage, we stop using on-chain communication for user coordination as the chain can no longer guarantee data availability. In Phase 3, maintaining and obtaining off-chain state will become one of the key factors limiting the design of DApps.
Phase 4: Sharding Smart Contracts
text
However, an insurmountable problem remains. Although ETH2.0 contracts are as powerful as Ethereum contracts, they are necessarily bound to one shard and can never directly interact with contracts on another shard. This is a direct consequence of sharding, which aims to split state between shards without having direct knowledge of other shards. Scaling is achieved by splitting the state and reducing the workload of validators as much as possible.
Direct interaction requires direct knowledge storage. By design, shards have no direct knowledge of other shards. It only knows about other shards through cross-chain communication with the beacon chain. Therefore, when users want to interact across shards, they must wait for the beacon chain. Specifically, this means that if a SafeMath module is deployed on shard A, users on shard B must wait for access, or deploy a new SafeMath module on shard B.
Long delays between CDP activation and DAI collection can result in unaffordable economic losses. What if the market changes and the CDP is liquidated before the user receives the DAI? In practice, this may mean that users need to have an account on each shard containing the smart contract, but the cross-shard structure is useless. Maker and 0x can only interact if they are both deployed on the same shard, and 0x users also need to own a certain amount of assets on that shard.
secondary title
The Fundamental Tradeoff: Synchronize or Scale
The designers of the ETH2.0 version did not know what the final cross-shard communication system would look like. By reading many proposals, the system may make a fundamental trade-off between instant feedback and predictability. The nature of sharding will not change, any user will have to wait for cross-shard communication. However, we can tightly or loosely couple the local and remote execution phases of transactions to each shard.
Tight coupling makes waiting a priority. Transactions do nothing until the shards communicate. Instead, we can loosely couple transactions by executing parts now and executing parts later. Transactions are executed on the local shard, and then executed on the remote shard after cross-shard communication.
Loose coupling provides a better user experience. Users can instantly see their trades executed locally and know that remote execution will happen at some point in the future. But luck and misfortune come together, and users must wait to know the results of the remote phase of loosely coupled transactions. Tightly coupled transactions are more predictable than loosely coupled transactions. At the same time, users are more aware of the results because remote state does not transition between local and remote execution stages. But "you can't eat hot tofu in a hurry", tight coupling requires users to wait before seeing any results.There is very little information about the communication model of ETH2.0. We know that the model must provide cross-shard contract calls at the expense of almost all scaling advantages. I don't blame you if you stop reading here, because Phase 4 only existsmind map and some obscure links
. An unobvious consequence of this situation is that ETH2.0 will not provide significant scaling advantages for complex smart contract systems until phase 4. Previously, smart contracts wishing to interact with other contracts had to co-exist with a shard and were limited to the speed and scaling effects of that shard. Compared with ETH1.X, sharding may only achieve a speedup of at most a small constant factor. This means that before the release of phase 4 (around 2025), there is no reason to migrate smart contract code or users due to its small advantages.Important: Everything below is speculative。
secondary title
Basic Model: Receipt and Proof
All forms of cross-chain communication rely on the Beacon Chain. Since the beacon chain is able to retrieve the state of all shards, and each shard affects the state of the beacon chain, it is used as the core in the shard chain ecosystem. In a sense, the information from one chain to another must be transmitted through the beacon chain. Considering that this requires the beacon chain to process each transaction itself, the expansion effect cannot be achieved at all, so it is not desirable to send a complete information.
Instead, when a user or contract on shard A wants to interact with shard B, shard A generates a "receipt" with a message for that interaction. Shard A submits all its receipts in its block header, and the beacon chain waits for A to confirm completion before submitting to shard A's block header (including the submission of receipts). Shard B must also wait for the final confirmation of the beacon before committing to the beacon block header.
It is not difficult to see that this process takes a lot of time. Each of the four communication steps requires a few minutes to complete. Unfortunately, we cannot completely avoid waiting. If we want to determine the remote state, at each step we have to wait for the final result. The best case for round-trip communication is four final confirmation cycles. In other words, since users can see shard B's data before shard A sees them, users gain confidence after three confirmation cycles. With ETH2.0's epoch length of 6.4 minutes, the user would have to wait 19 minutes to see the result, and 26 minutes to get the result on-chain.
secondary title
Concrete Receipts: Token Migration Between Shards
The versatility of ERC20 tokens makes them ubiquitous in Ethereum today. However, ETH2.0 also brings some logical problems to Token. Since the smart contract manages all Token balances, and the smart contract only exists on a single shard. Therefore, the token from shard A does not exist on shard B at all. But with some smart cross-shard communication, we can deploy the same token on multiple shards and allow token transfers between shards, effectively establishing a two-way peg between token contracts.
The solution is very simple.
We need to redeploy our token contract on each shard, but it seems worth it. Migration is unidirectional, requiring at least two final confirmations of cross-shard communication. Therefore, it takes about 10 minutes after we call MigrateSend for "CCT" to be available on the receiving shard.
secondary title
Yanking (pull)Yanking Receipts are a general way of passing information across shards. We can put any on-chain information in the receipt, even entire smart contracts.
This will allow any one smart contract to communicate with any other smart contract (after the cross-shard wait time). But because the receipt contains the entire contract and all its storage, the cost of transferring a large or user-popular contract can be high. The receipt is in transit and the contract will be completely unusable. It has been pulled from shard A, but has not yet reached shard B. This means that all other users cannot use the contract until it reaches shard B. At the same time, only users who are already on shard B can interact with it. Therefore, Yank is best suited for small smart contracts with few users, it enables tightly coupled execution, but is not a general solution.
secondary title
Shard Pairings
Let's move on to some more creative build ideas.
Receipts are designed to enable asynchronous (loosely coupled) communication. But we may also need synchronous communication. To do this, we have to be more creative. With a simple design, shard pairing enables tightly coupled execution with as little hassle as possible.
In this model, if a cross-chain transaction is required between A and B, it is necessary to wait for A and B to be paired randomly. But Vitalik describes 100 cases of sharding. There are 1024 shards and we expect it to take 512 blocks, so it will take about an hour. But since the pairing is random, it may need to be longer or shorter. As Vitalik said, this doesn't scale well when you want to interact with multiple shards.
secondary title
Shard Zones
This is a broader version of shard pairing.
Additionally, zones negate many of the scaling benefits of sharding since they require validators to know the state of all shards in the zone. If a region consists of 16 shards, then you sacrifice about 15/16 (94%) of the scaling advantage and only get 15/1024 (1%) of the total network's tightly coupled execution.
secondary title
However, when applied to smart contracts, this solution becomes complex because the state is never replaceable. Stateful IOUs are impossible to implement, so they are not suitable for generic interactions. We should think of encumbrances as user experience improvements in loose coupling, allowing loose coupling to simulate tight coupling, and fast execution of certain transactions.
secondary title
Consensus and State Separation
Only all state contained in the execution blockrenewrenew
After that, Ethereum miners and full nodes accept blocks. But in fact, it's not. Instead, it can accept blocks first and then make state updates. In this case, instead of reaching consensus on the state of the system as we do in Ethereum, we will reach consensus on the total history (or "total order") of all transactions across all shards.
first level title
summary
summary
ETH2.0 will be a completely different system than Ethereum, and the two will exist side by side for many years with different feature sets. In the near future, a one-way peg from ETH to BETH is expected. If you operate an exchange or escrow service, you can consider supporting users to conduct BETH escrow transactions and bets before the BETH is transferred on the chain. In the long run, there is also the need to consider how smart contracts can adapt to sharding with or without cross-shard communication.
