Architecture
| Component | Placement | Description |
|---|---|---|
| Bolt RPC | Off-chain | RPC proxy server that propagates preconfirmation requests to opted-in proposers in the lookahead |
| Bolt sidecar | Off-chain | The entrypoint for Bolt. Implements the commitments-API and turns commitments into constraints |
| MEV-Boost | Off-chain | Modified MEV-Boost client that implements the constraints-API and verifies contraint proofs |
| Registry | On-chain | The registry smart contract that keeps track of the opted-in proposer set and their associated stake |
Off-chain components
By default, the software stack for proposers will be extended with a new component called bolt-sidecar that implements the default builder-API. The bolt-sidecar will serve like a proxy
for the modified mev-boost client, which implements the constraints-API. Users interact with the bolt-sidecar, turning commitments into constraints and communicating them to the PBS pipeline through the constraints-API.
Schematically, the proposer software stack will look like this:
bolt-sidecar
The Bolt sidecar is the off-chain entrypoint for Bolt. To enable it, proposers will need to point their beacon node builder-api to the sidecar's endpoint. From the perspective
of the beacon node, the sidecar will look like a regular external block builder. The sidecar is responsible for the following tasks:
- Receiving & validating commitment requests from users through the
commitments-API - Turning commitments into constraints and communicating them downstream
- Proposing a safe fallback block in case of any faults
Fallback block building
To ensure that proposers don't take on any of the risks of the PBS pipeline in case of faults, the sidecar will contain a fallback block building mechanism. Any commitments made will be stored in a local block template, which can be proposed in case no other block is available.
Modified mev-boost
The modified mev-boost client will implement the constraints-API and verify those constraints against incoming builder bids, which will have proofs attached. For more information
on how proofs and verification will work, see the proofs section.
Bolt RPC
The Bolt RPC will be a public RPC endpoint that will proxy requests from users to opted in proposers according to the lookahead and provide additional functionality like DoS protection and rate limiting. The Bolt RPC will be a separate process from the proposer, and anyone can run one. Proposers can configure the Bolt sidecar to point to their preferred Bolt RPC.
On top of these protective measures, it will also provide a translation layer to turn regular eligible Ethereum transactions into preconfirmations. In practice, the Bolt RPC will
implement the regular eth_sendRawTransaction method, which means that users can plug it into their wallets as a custom RPC endpoint and immediately benefit from preconfirmations.
Builders & relays
Builders & relays will need to be modified to support the new constraints-API.
On-chain components
Registry
The Bolt Registry is the smart contract that keeps track of the currently opted-in proposers and their associated stake. The responsibilities of the registry include:
- Registering new proposers via an EOA, verifying their authenticity cryptographically (see the opt-in procedure below)
- Storing the proposer's stake in Bolt, including the collateral deposited in restaking protocols
- Opting out proposers that no longer wish to participate in Bolt (with a cooldown period)
- Providing read access to the proposer set useful for the Bolt RPC and Challenger components
Challenger
Since Bolt operates in an optimistic mode, there is a need for a mechanism to challenge invalid proposals. An invalid proposal is one that does not meet the constraints that were committed by the proposer in advance.
The Challenger smart contract is the component responsible for handling disputes in Bolt. Its responsibilities include:
- Opening a dispute for a specific block proposal targeting a proposer that is opted-in to Bolt
- Providing a resolution mechanism for disputes, which relies on constraint satisfaction verification through inclusion proofs on-chain. If a dispute is resolved in favor of the challenger, the proposer will be slashed depending on the severity of the fault (e.g. safety or liveness).
The specifics of how the challenge resolution proofs work are detailed in the proofs section.
Opt-in procedure for proposers
This will not be implemented in the initial proof of concept version.
The exact authentication method is still an open research topic, and this procedure is experimental.
Ethereum validators will have the option to opt-in to Bolt by registering with the Bolt Registry smart contract. The registration process is as follows:
- The Proposer signs a message with their withdrawal address private key 1 to signify that they are requesting to opt-in. The message will need to contain the Ethereum address that the proposer intends to use as signer to authenticate individual preconfirmation requests. This way, proposers in Bolt will have a separate identity from their validators private key.
- The Proposer sends a transaction to the Registry, requesting to opt-in to Bolt. The transaction must be sent from the same address that was specified in the signed message, which must be passed in the transaction's data. This way, the ownership of this new ECDSA key-pair is proven on-chain.
- Once opted-in, the Proposer must add some form of collateral to guarantee economic credibility behind its preconfirmations. The specific method in which this is achieved in Bolt is left as an open point for now.
Delegation
Proposers can choose to delegate the task of providing commitments to a trusted third party.
This can be achieved by signing a permit
message that allows the third party to submit commitments on their behalf. They then have to point their builder-API to the third party's
bolt-sidecar endpoint.
Delegation leads to a fully trusted relationship. If the operator commits a fault, the proposer's restaked collateral will be slashed.
Footnotes
-
One alternative for node operators is to use the private key that they use to authenticate on shared security protocols. ↩