How the Stake Table Contract Works
Last updated
Last updated
The HotShot contract, which verifies and stores Espresso state updates, also stores the entirety of the latest HotShot stake table. By taking this to be not just a mirror of the stake table but the canonical version of it, we gain a number of advantages, including the potential for the L1 itself to make changes to the stake table, a requirement for implementing .
Restaking is a , since it allows Espresso to share a security budget with Ethereum and aids in incentive alignment between the Ethereum operator set and rollups integrated with Espresso. But to enable restaking using a system like , the restaking contracts must be able to change the state of the Espresso stake table, such that new entries can be added when new L1 validators opt into restaking for Espresso.
By treating the stake table stored on the L1 as the canonical stake table, we allow L1 smart contracts to do exactly this, merely by writing to another contract on the same L1. Espresso nodes will then read the updated stake table back from the L1 at the start of the next and begin using the stake table with the restaker's entry for validating future consensus decisions.
This does require every HotShot consensus participant to run an L1 light client in order to make trustless reads from the HotShot smart contract. However, Ethereum's proof-of-stake consensus enables very efficient, lightweight, trustless clients, and this Ethereum client can be bundled directly into the HotShot client executable for a seamless user experience.
In order to verify consensus decisions, a HotShot client must know the stake table that was used to authenticate each decision, so that it can accurately account for the number of votes endorsing each decision. This means that, naively, if a new HotShot client or consensus participant wanted to sync with the current state of consensus, it would have to replay from genesis at least every block which updated the stake table. By storing verified snapshots of the stake table on a trusted L1, new HotShot nodes can instead read the latest snapshot from the L1 and start replaying blocks from there, trusting the L1 validator set to have already verified each block which led up to the snapshot. This is very similar to how rollups can enable fast, trustless sync for their clients by leveraging L1 state updates.