What is this about?

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 forum⁴¹. 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 verification², and the question raised by Jochem-brouwer about whether the storage address should be added to warm addresses by default^3,4. Mkalinin points out the complexity of using epoch/slot/timestamp as a fork trigger⁵, while Axic suggests a method for reading the value⁶. The potential usefulness of this EIP for liquid staking protocols is discussed by Bbuddha and Ralexstokes^8,9,10,11, and Kanewallmann raises concerns about future compatibility¹³.

How is the community reacting?

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 API¹⁴, while Holterhus proposes a solution to the issue of tree depth increasing due to newly appended properties¹⁵. Haltman-at questions the use of a stateful precompile rather than a new opcode¹⁶, and Ralexstokes responds with the motivation for this approach¹⁷. Jochem-brouwer raises several questions about the EIP¹⁸, 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 address^34,35, and Etan-status questions the necessity of the system contract³⁷. Madlabman's elaboration on the block roots cache has also been added to the discussion⁴¹.

Why this is positive?

The proposal could unlock many applications, particularly for liquid staking protocols, as discussed by Bbuddha and Ralexstokes^8,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 solutions⁴¹.

Why this is negative?

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 trigger⁵, and Kanewallmann raises concerns about future compatibility¹³. There are also questions about the necessity of the system contract³⁷ and the use of a stateful precompile rather than a new opcode¹⁶. 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 discussion⁴¹.