Unified Preconf Registry

# Unified Preconf Registry ## Background - mteam's [original writeup on the preconf registry](https://ethresear.ch/t/credibly-neutral-preconfirmation-collateral-the-preconfirmation-registry/19634) and [recording of original presentation on the registry](https://www.youtube.com/watch?v=BxtXcxYzL1k) - Spire Labs' [preconf registry repo](https://github.com/spire-labs/preconfirmation-registry) and [associated Notion spec](https://spirelabs.notion.site/EthCC-7-Preconfirmation-Registry-923dabf24d4540da92ed2780b7f6c3cc?pvs=74) - Limechain's [work on opt-in mechanics](https://github.com/LimeChain/based-preconfirmations-research/blob/main/docs/optin-mechanics.md) - Chainbound's [work on the Bolt registry](https://github.com/chainbound/bolt/blob/unstable/bolt-contracts/src/contracts/BoltRegistry.sol) and [associated discussion](https://github.com/chainbound/bolt/discussions/95) - Nethermind's [registry](https://github.com/NethermindEth/Taiko-Preconf-AVS/blob/master/SmartContracts/src/avs/PreconfRegistry.sol) for their Taiko project - Lido's [subregistry (draft) write up](https://hackmd.io/XgMJCBkKQp2Ya57R1M7Y1g) ## Design Considerations There are a few major design considerations that we propose for the unified registry. - **easy integrations for proposer commitment (preconf) protocols:** integration of new penalty conditions and easy opt-in by proposers - **easy integration for validators:** opt-in for validators is simple, fast, and cheap. - **supported integration for rollups:** information should be available that can be ingested and used for things like sequencer election - **maximum permissionlessness:** permissionless registration, permissionless creation + opt-in of penalty conditions, (default) permissionless slashing - **realistic high credible neutrality:** credible neutrality as a priority, with the realistic expectation of future market forces degrading this neutrality - **maximum simplicity, minimal gas usage:** conceptually simple, minimal lines of code, minimal gas overhead, easy to audit - **future-proofing and extensibility:** whenever possible while non-upgradable, support future changes to Ethereum and new features And consideration of the following actors: - **proposer commitment (preconf) protocols:** enable coordination for proposers to provide commitments that can be fulfilled or not fulfilled - **validators:** any actors that stake ETH to Ethereum, including staking pools and DVT systems - **based rollups:** any rollup that builds on the sequencer election of Ethereum as a foundation With the intention of being a "common factor" registry, that encapsulates logic and state that would be present in every feasible proposer commitment protocol. We suggest the following non-goals: - **out-of-the-box for proposer commitment protocols:** we don't suggest that proposer commitment protocols will be able to use the registry without a wrapper or some other integration effort (creating penalty conditions etc.) - **native integration with any restaking protocol:** we explicitly avoid integration with any restaking protocol in the unified registry, but support integration of external collateral (such as a restaking protocol) through extensions. - **reward distribution:** we do not support distribution of any rewards for providing proposer commitments. ## Foundations This section contains a proposed design for the unified registry, in broad strokes. ### Native ETH Staking The first function of the unified registry is staking of native and pure ETH. The exact construction of such a staking system is relatively unimportant (the penalty conditions explained below shape how staking must work). Registration and identification of stakers to the unified registry is discussed below. This function is important primarily because it encourages the usage of credibly neutral collateral (raw ETH) but also a simple interface for retrieving a lower bound on collateral (excluding restaked collateral, etc.) that can be easily ingested by a variety of actors (especially based rollups). I personally imagine many consumers of proposer commitments being especially interested in a collateral option with low collateral risk for simplicity's sake. ### Penalty Conditions The other important functions of a full registry are of course alternate collateral forms and slashing. In the unified registry, we take an unopinionated and extensible approach. Penalty conditions (aka slashing conditions) are represented within the unified registry through a simple unique identifier that corresponds to EVM bytecode. This bytecode must follow a certain interface (which defines the penalty itself) but could theoretically do *anything.* In practice, I expect penalty conditions are used to delegate calls to another "subregistry" that contains logic and state for the specific needs of the proposer commitment protocol in question. Penalty conditions are not upgradable, but they can make external calls to upgradable contracts and therefore can be logically "upgraded". Penalty conditions, when executed, return a penalty to apply to native collateral (see above) but may execute other penalties on external collateral. Because of this, penalty conditions act as a representation of collateral that may exist in any form (restaked ETH, reputation, shares of future rewards, etc.). This is important because it maintains credible neutrality of the unified registry but is also extensible enough to accommodate the preferences of both proposer commitment protocols and validators. Finally, the registry keeps track of penalties already applied (each penalty must contain a unique ID) to avoid application of the same penalty multiple times. This information is accessible from the execution of the penalty condition. ### Registering Validators The registration of validators is a complex topic because validators are not homogenous. Huge staking pools and solo stakers have much different preferences around collateral provision, permissioning, and security. Because of this reality, I think it is best to use an arbitrary permissioning scheme to enable the expression of these preferences. Every permissioning scheme supported by the registry (it is permissionless to add more) will have a unique ID and contain arbitrary data that can be interpreted to establish a relationship between a validator and the commitment protocols. Examples include an ECDSA or BSA signature of a message regarding the unique ID of a list of penalty conditions. Data about the validator and their status is included if relevant. Arbitrary permissioning schemes, keep track of relationship between native ETH staked and penalty conditions ### Based Sequencer Election Based sequencer election, loosely defined, is the granting of some specific sequencing rights to a specific entity based on some criteria. In this context, we attempt to provide a simple interface to access the Ethereum lookahead and avoid repeated overhead for multiple different based rollups or proposer commitment protocols. The actual criteria and logic used to elect a sequencer is not the focus of this writing. A notable choice to be made here is the minimum collateral required to be considered eligible to be elected. We fully expect some based rollups to build additional rules and criteria on top of the registry's sequencer election mechanism. ## Next Steps The continued development of the unified registry with input from proposer commitment protocols and stakers is a top priority. In the past months, a few teams have begun work on protocol-specific registries. To avoid further fragmentation of R&D efforts, we encourage more communication about design goals and collaboration on the unified registry. Spire Labs is offering our support (we are onboarding a few dedicated devs for the development of the registry) and coordination efforts around the [Ethereum Foundation GitHub repo](https://github.com/ethereum/preconfs). For more information on how the registry fits into our strategy, please read [our litepaper](https://github.com/spire-labs/litepaper).