EIP-4788 uses a smart contract to temporarily store beacon chain roots on the execution layer in EVM storage. The contract is written directly in EVM assembly. Internally, the contract uses two ring buffers, one for timestamps and one for beacon roots. Hence, previously written beacon roots will be overwritten eventually. The most critical subjects covered in our audit are the security and the correctness of this smart contract storing and providing the beacon roots. The most important properties are:
(1) only the privileged SYSTEM_ADDRESS can store beacon roots
(2) only previously stored beacon roots can be retrieved
(3) the ring buffer correctly overwrites old beacon roots
(4) previously stored beacon roots can be queried by any smart contract by providing the timestamp of the following beacon block
Furthermore there was an important performance property:
(5) limit the storage consumption of the contract and use the storage efficiently
For the originally submitted contract, we found that property (2) can be violated by querying the Zero-Timestamp and that property (5) depends on block interval to stay constant at 12 seconds. To improve the storage efficiency and hence reach property (5) we proposed that the ring buffer should have a prime size. Furthermore, we investigated possible gas savings and made some recommendations which focused on reducing the execution cost of the contract’s usual execution path.
The smart contract and the EIP were consecutively updated as follows:
(1) an explicit check was added to prevent querying the Zero-Timestamp
(2) the ring buffer size became a prime number (specifically 8191), which provides more efficiency independent of block interval as described in the audit report, see “Implications of Ring Buffer Size”
We then further analyzed these updates. We found that during regular times the contract can return the 8191 most recent beacon roots. Given the current block interval that results in roughly 27 hours of historic data. However, before hard forks or with varying block intervals the contract might only return the beacon roots from the past 8191 seconds (roughly two hours), as described in “Changes in Block Interval”.
Last but not least, we wrote “Notes for smart contract developers”, planning to interact with this contract, so that they can avoid potential mistakes.
Overall, we found that after these fixes the smart contract code provides a high level of security.
It is important to note that security audits are time-boxed and cannot uncover all vulnerabilities. They complement but do not replace other vital measures to secure a project. Specifically, in this review the way how clients interact with this special smart contract to set beacon roots was out of scope.