Skip to main content

Architecture

ComponentPlacementDescription
Bolt RPCOff-chainRPC proxy server that propagates preconfirmation requests to opted-in proposers in the lookahead
Bolt sidecarOff-chainThe entrypoint for Bolt. Implements the commitments-API and turns commitments into constraints
MEV-BoostOff-chainModified MEV-Boost client that implements the constraints-API and verifies contraint proofs
RegistryOn-chainThe registry smart contract that keeps track of the opted-in proposer set and their associated stake
ChallengerOn-ChainThe fault dispute challenge game to keep proposers accountable on their commitments

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:

Components

Red = new / modified

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​

Validator Registration: BoltValidators​

The BoltValidators contract is the only point of entry for validators to signal their intent to participate in Bolt Protocol and authenticate with their BLS private key.

The registration process includes the following steps:

  1. Validator Authentication: The validator signs a message with their BLS private key to prove ownership and control of the validator private key.
  2. Registration Call: The validator calls the registerValidator function, providing:
    • BLS Public Key: The public key of their validator.
    • BLS Signature: The signature of the registration message.
    • Authorized Collateral Provider: The address of the authorized collateral provider.
    • Authorized Operator: The address of the authorized operator.

Until the Pectra hard fork is activated, the contract exposes a registerValidatorUnsafe function that does not check the BLS signature. This is gated by a feature flag that will be turned off post-Pectra, allowing testing of the registration flow in a controlled environment.

Bolt Network Entrypoint: BoltManager​

The BoltManager contract is a crucial component of Bolt that integrates with restaking ecosystems like Symbiotic and EigenLayer. It manages the registration and coordination of validators, operators, and vaults within the Bolt network.

Key features include:

  1. Stake Retrieval: Retrieval of operator stake and proposer status from their public key.
  2. Symbiotic Integration: Facilitating interactions with Symbiotic restaking.
  3. EigenLayer Integration: Facilitating interactions with EigenLayer restaking.

Specific functionalities about the restaking protocols are handled inside the IBoltMiddleware contracts, such as BoltSymbioticMiddleware and BoltEigenLayerMiddleware.

The integration guide for Eigenlayer and Symbiotic can be found here

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 fault attribution and slashing section.

Opt-in procedure for proposers​

info

This procedure is for the initial version.

Ethereum validators have the option to opt-in to Bolt by registering with the BoltValidators contract. The registration process is as follows:

  1. Validator Authentication: The proposer signs a message with their BLS private key to prove ownership and control.
  2. Registration Call: The proposer calls the registerValidator function on the BoltValidators contract, providing:
    • BLS Public Key: The public key of their validator.
    • BLS Signature: The signature of the registration message.
    • Authorized Collateral Provider: The address of the entity providing collateral.
    • Authorized Operator: The address of the operator authorized to submit commitments on their behalf.
  3. Collateral Provisioning: The proposer must add collateral to guarantee economic credibility behind its preconfirmations. This is achieved through restaking protocols like Symbiotic or EigenLayer, as described in the integration guides above.