This is worth checking. But I assumed that swapping one hash with another won’t change the semantics in a way that it breaks existing smart contracts. Is there any particular cases that you have in mind?
seems like we won’t have separate shard for ETH1 anymore, it will be merged with beacon chain and no separate consensus mechanism for it will exist.
Phase 2 is still on the table. The “rollup-centric roadmap” is a short- and medium-term roadmap (say, for 2021 and 2022). It is not a long-term roadmap.
This would require validators to run an Eth1 full node to validate. This goes against the design goal of allowing validators to run on cheap hardware (e.g. entry-level laptops, NUCs, Raspberry Pis, phones, etc.). This is especially relevant for validators that are staking a small amount of ETH through an m-of-n pooled validator.
The beacon block roots are extremely malleable making them unusable as a source of randomness, hence unusable for Eth1 dApps (and other infrastructure) that use the BLOCKHASH as a source of randomness. A possible fix for this use case is to make BLOCKHASH return the relevant RANDAO mix.
However, as mentioned by @matt, we also need to cater for Eth1 dApps (and other infrastructure) that use BLOCKHASH to authenticate Eth1 headers and bodies. I’m not sure how to modify BLOCKHASH to reconcile both use cases (randomness and authentication).
3 Likes
Excellent proposal. This gives us a way to merge Eth1 and Eth2 even before statelessness has been achieved (though it would be better with statelessness).
I think we should provide access through a more semantic data structure rather than using a generalized index. The generalized index would severely limit upgradability of beacon chain data structures.
2 Likes
Excellent proposal! I have 2 questions:
-
Making a sync BeaconState access API today could we support it tomorrow when/if we have several execution shards? Async looks safer for me even if it’s possible to make it sync in the near term.
-
As noted above, we want to go stateless in the middle-long term. How could eth1 engine be incentivized and verified as a separate actor in the future?
Great work!
I am definitely worried about the idea of synchronous interaction between eth1 execution and the beacon chain. The reason is that using synchronous interaction, while simpler, permanently enshrines the requirement that verifying an eth2 block requires running the corresponding eth1 execution. It excludes alternatives like allowing eth2 nodes to be stateless clients of eth1 and only verify the eth1 side if they are part of an assigned committee, for example (and it would also exclude the possibility of migrating eth1 to a shard further down the road).
So even if executable data is directly inside beacon blocks I’d be inclined to favor keeping the communication between the executable data and the beacon chain logic fully asynchronous.
6 Likes
Previously people have discussed using the block hash in contracts to prove the existence of previous event logs, see this discussion:
…which includes a couple of people’s POC implementations:
This obviously relies on whatever is returned by BLOCKHASH hashing a header with the same structure as currently, but certain parts of it could be replaced - for instance, you might want to replace the nonce with a random number from Randao.
I don’t know whether anything like this was ever used in production, beyond proving that it could be done, or whether it’s still expected to work. “Eth1 block headers will never change” doesn’t really feel like a reasonable thing to assume, but maybe somebody assumed it.
2 Likes
Well, I think if this is a direction, the beacon chain needs to run for a while to prove stability, and I am not sure this can be done in 2021, because some people may need more time. Most complex software products take years to polish and fix bugs.
Weakly coupling ETH1 & ETH2 in 2021 is realistic in IMO.
On the other hand forcefully killing ETH1 PoW consensus in 2021 would be scary for many people.
People in general like to have an option to do something and not be forced to do something. Giving people an option to move ETH1 tokens to ETH2 is better than telling them that the old thing stops and everyone needs to move to the new one.
If I were an investor keeping my money on PoW and someone would tell me that the PoW chain is going to be terminated, say on June 1, 2021, and I would be moved to the PoS chain, I would start worrying, because I do not know how stable the new thing is.
I would like it much more if the old one keeps running and I am given an option to move my funds to the new one.
To summarize, the optimal solution imo is to somehow embed ETH1 merkle roots into ETH2 blocks and ETH2 merkle roots into ETH1 so the funds can go back in forth.
The simplest way to do it is probably to introduce a long delay to make sure the state is finalized on the source chain before funds are moved to the destination chain.
Then, in particular, ETH2 can flow back into ETH1 slowly but surely.
Perhaps, the wording regarding Phase2 is confusing. The assumption is that rollup-centric roadmap makes eth1 as the only execution thread for a longer period than it was previously planned with Phase2. The option of scaling the execution on L1 is not excluded by this proposal.
Right, but what if there is eth1 nodes market that provides access to eth1 state transition and block production for Tx fees? We may think of centralisation risk here but eth1 Tx fees could be enough for relatively high number of independent parties to run their own nodes and provide such a service mitigating the risk.
This is a good point! I agree with you and @matt that we can’t change the semantics of BLOCKHASH and rather introduce a BEACONBLOCKROOT opcode for proofs verification. Preserving BLOCKHASH semantics addressing both, randomness and blocks identity, is an open question.
It definitely need to prove stability. And executable beacon chain will highly likely not happen in 2021. Technically with eth2 light client contract on eth1 some of the use cases that require bi-directional communication becomes possible.
Well I am a bit confused now …
Why does one need to run a full PoW node if the PoW consensus is no longer valid?
My understanding that you would need to either add EVM and the historic ETH1 state to ETH2 clients, or run and ETH1 node in parallel to ETH2 node, but only the part of it that does EVM, not PoW consensus …
Good point! This restriction is addressed by the following note:
I totally agree with these points! Tight coupling eth1 and eth2 by synchronous state accesses puts a big restrictions on upgradability. Making such a change requires a clear path towards execution scalability and we definitely should use less restrictive asynchronous model, at least at the beginning.
This is probably a good path to follow. RANDAO mix is embedded into eth1 block header (into extra data field or whatever else) by eth1-engine. Eth1 block execution takes 200ms in average which restricts the number of potential re-rolling the dice attempts by introducing a risk of loosing proposer reward and hence transaction fees if block is not propagated in time.
Come to think of it I’m not sure this works - Couldn’t a validator bias the randomness of the block hash after getting the randao number by grinding any other part of the header that isn’t part of the block execution? (Or do something at the end of the block after the 200ms?)
If so then it seems like you have to choose between just replacing the block hash with a random number, which preserves the use of the block hash for contracts that use it as a ghetto (moderately expensive-to-bias) random number generator, and preserving its use for already-deployed existing contracts that want to prove things about the block.
We can avoid this by including eth1 block hash onchain and validating that unused fields are e.g. filled with zeros. Though, coinbase can be manipulated in any case.
He means run eth1 state and tx verification, but with the the consensus driven by the beacon chain.
The software architecture of this might very well look like an eth2 client and portions of an eth1 client (often called an eth1-engine) running adjunct on the same system, where the eth2-client drives consensus and the eth1-engine handles user layer validity (state, txs, etc).
See this post for a high level on the division of concerns – Eth1+eth2 client relationship
1 Like
Current proposal makes a lot of sense for developers and Ethereum architecture in common. ETH1-shard is actually a new entity type and creating new types usually is not a good idea. We already have two different types: beacon and shard. Merging this new type to existing one is pretty obvious and eliminates future pain of managing and supporting special ETH1-shard.
Moreover, beacon chain merging will protect ETH1 state data. It will be important for the moment when PoW miners start to leave ETH1 chain and hash rate drops dramatically.
Is this only an issue when synchronously writing to beacon state? It seems like we can get away with synchronous reads.
Reading from the post beacon state of slot N in eth1 during slot N does seem reasonable and backwards compatible in many future designs.
Specifically if eth1 went into a disconnected shard, and read from slot N, it would need to be staggered within the slot (e.g. 4 seconds into the slot).
The design that does not handle slot N reads is if the eth1 shard were to be executed at the start of slot N at the exact same time as the beacon chain.