Reading time saved: 13 minutes
40 replies, 6330 views, 22 likes
The Ethereum community is actively discussing EIP-4788, a proposal to include the beacon block root in the Ethereum Virtual Machine (EVM), with key points including potential impacts, benefits, challenges, and the concept of block roots cache. While the proposal could unlock applications for liquid staking protocols, concerns exist about its complexity, future compatibility, and the necessity of the system contract.
The community continues to discuss EIP-4788, a proposal to include the beacon block root in the Ethereum Virtual Machine (EVM). The conversation has expanded to include the concept of the block roots cache, as elaborated by Madlabman at the Lido research forum41. The discussion still revolves around the potential impacts, benefits, and challenges of this proposal. Key points include the suggestion by MicahZoltu to include ommersHash validation for minimal changes during block production and verification2, and the question raised by Jochem-brouwer about whether the storage address should be added to warm addresses by default3,4. Mkalinin points out the complexity of using epoch/slot/timestamp as a fork trigger5, while Axic suggests a method for reading the value6. The potential usefulness of this EIP for liquid staking protocols is discussed by Bbuddha and Ralexstokes8,9,10,11, and Kanewallmann raises concerns about future compatibility13.
The community remains actively engaged in the discussion, with various members raising questions, proposing solutions, and expressing concerns. Dapplion asks about the specification of changes to the consensus layer and engine API14, while Holterhus proposes a solution to the issue of tree depth increasing due to newly appended properties15. Haltman-at questions the use of a stateful precompile rather than a new opcode16, and Ralexstokes responds with the motivation for this approach17. Jochem-brouwer raises several questions about the EIP18, and Haltman-at and Ralexstokes engage in a detailed discussion about the distinction between "execution state" and "additional context"20,21,22,23,24,25. Chfast and Holiman propose deploying real bytecode at the given address34,35, and Etan-status questions the necessity of the system contract37. Madlabman's elaboration on the block roots cache has also been added to the discussion41.
The proposal could unlock many applications, particularly for liquid staking protocols, as discussed by Bbuddha and Ralexstokes8,9. The community's active engagement in the discussion is also a positive sign, with various members contributing their expertise to address potential challenges and propose solutions. The addition of Madlabman's concept of the block roots cache to the discussion could potentially provide new insights and solutions41.
There are concerns about the complexity and potential impacts of the proposal. Mkalinin points out the complexity of using epoch/slot/timestamp as a fork trigger5, and Kanewallmann raises concerns about future compatibility13. There are also questions about the necessity of the system contract37 and the use of a stateful precompile rather than a new opcode16. The discussion also reveals some confusion about the distinction between "execution state" and "additional context"24,25. The introduction of the block roots cache concept by Madlabman adds another layer of complexity to the discussion41.
Posted 2 years ago
Last reply 14 days ago
Summary updated 13 days ago
Last updated 04/12 00:22