Skip to content

Latest commit

 

History

History

bolt-contracts

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
config
config
 
 
docs
docs
 
 
lib
lib
 
 
script
script
 
 
src
src
 
 
test
test
 
 
.gas-snapshot
.gas-snapshot
 
 
.gitignore
.gitignore
 
 
README.md
README.md
 
 
foundry.toml
foundry.toml
 
 
go.mod
go.mod
 
 
go.sum
go.sum
 
 
main.go
main.go
 
 

README.md

Bolt Contracts

Table of Contents

Overview

The Bolt smart contracts cover the following components:

  • Registration and delegation logic for validators to authenticate and opt-in to Bolt
  • Operator registration and collateral deposits through flexible restaking protocol integrations (EigenLayer & Symbiotic)
  • Fault proof challenges and resolution without slashing

Architecture

A high-level overview of architecture is depicted in the diagram below:

Notes

Admin Privileges

The smart contracts are deployed with a single administrator account operated by the Bolt team. In this testnet deployment, all contracts are upgradeable and multiple system-wide parameters can be changed by this administrator in the case of bugs, hacks, or other critical events.

System-wide Parameters: BoltParameters

BoltParameters is an upgradeable storage contract that stores system-wide parameters that the other contracts can read from. An overview is given in the table below:

Parameter Initial Value Mutable after deployment
EPOCH_DURATION 86400 (1 day) No
SLASHING_WINDOW 604800 (1 week) No
BLOCKHASH_EVM_LOOKBACK 256 No
ETH2_GENESIS_TIMESTAMP 1694786400 No
SLOT_TIME 12 No
JUSTIFICATION_DELAY 32 Yes (by admin)
MINIMUM_OPERATOR_STAKE 1 ether Yes (by admin)
MAX_CHALLENGE_DURATION 604800 (1 week) Yes (by admin)
CHALLENGE_BOND 1 ether Yes (by admin)
ALLOW_UNSAFE_REGISTRATION true Yes (by admin)

The values of these parameters can also be found in parameters.json.

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 signs a message with their BLS private key. This is required to prove that the validator private key is under their control and that they are indeed its owner.
  2. Validator calls the registerValidator function providing:
    1. Their BLS public key
    2. The BLS signature of the registration message
    3. The address of the authorized collateral provider
    4. The address of the authorized operator

Until the Pectra hard-fork will be activated, the contract will also expose a registerValidatorUnsafe function that will not check the BLS signature. This is gated by a feature flag that will be turned off post-Pectra and will allow us to test 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 Symbiotic and Eigenlayer. It manages the registration and coordination of validators, operators, and vaults within the Bolt network.

Key features include:

  1. Retrieval of operator stake and proposer status from their pubkey
  2. Integration with Symbiotic
  3. Integration with Eigenlayer

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

Fault Proof Challenge: BoltChallenger

The BoltChallenger contract is the component responsible for handling fault attribution in the case of a validator failing to meet their commitments.

In short, the challenger contract allows any user to challenge a validator's commitment by opening a dispute with the following inputs:

  1. The signed commitment made by the validator (or a list of commitments on the same slot)
  2. An ETH bond to cover the cost of the dispute and disincentivize frivolous challenges

The entrypoint is the openChallenge function. Once a challenge is opened, a ChallengeOpened event is emitted, and any arbitrator has a time window to submit a valid response to settle the dispute.

Dispute resolution

The dispute resolution process is one-shot and requires the arbitrator to submit all necessary evidence of the validator's correct behaviour within the challenge time window.

The arbitrator is anyone who can submit a valid response to the challenge. It doesn't have to be the validator themselves. There is however one limitation: the time window for submitting a response must be respected in the following way:

  • Start: the target block must be justified by LMD-GHOST: a minimum of 32 slots must have passed
  • End: depending on the EVM block hash oracle:
    • . If using the BLOCKHASH EVM opcode, the window is limited to 256 blocks (roughly 1 hour)
    • . If using the EIP-2935 historical oracle, the window is limited to 8192 blocks (roughly 1 day)

The inputs to the resolution process are as follows:

  1. The ID of the challenge to respond to: this is emitted in the ChallengeOpened event and is unique.
  2. The inclusion proofs, consisting of the following components: a. the block number of the block containing the committed transactions (we call it "inclusionBlock") b. the RLP-encoded block header of the block before the one containing the committed transactions (we call it "previousBlock") b. the RLP-encoded block header of the block containing the included transactions (aka "inclusionBlock") c. the account merkle proofs of the sender of the committed transactions against the previousBlock's state root d. the transaction merkle proofs of the included transactions against the inclusionBlock's transaction root e. the transaction index in the block of each included transaction

If the arbitrator submits a valid response that satisfies the requirements for the challenge, the challenge is considered DEFENDED and the challenger's bond is slashed to cover the cost of the dispute and to incentivize speedy resolution.

If no arbitrators respond successfully within the challenge time window, the challenge is considered BREACHED and anyone can call the resolveExpiredChallenge() method. The BoltChallenger will keep track of this information for future reference.

Holesky Deployments

Name Address Notes
BoltParametersV1 0x20d1cf3A5BD5928dB3118b2CfEF54FDF9fda5c12 Proxy: ERC1967Proxy@5.0.0
BoltValidatorsV2 0x47D2DC1DE1eFEFA5e6944402f2eda3981D36a9c8 Proxy: ERC1967Proxy@5.0.0
BoltManagerV2 0x440202829b493F9FF43E730EB5e8379EEa3678CF Proxy: ERC1967Proxy@5.0.0
BoltEigenLayerMiddlewareV2 0xa632a3e652110Bb2901D5cE390685E6a9838Ca04 Proxy: ERC1967Proxy@5.0.0
BoltSymbioticMiddlewareV2 0x04f40d9CaE475E5BaA462acE53E5c58A0DD8D8e8 Proxy: ERC1967Proxy@5.0.0

Testing

We use Forge, a fast and flexible Ethereum testing framework, for our smart contract tests. Here's a guide to running the test suite for the Bolt contracts:

  1. Make sure you have Forge installed. If not, follow the installation guide.

  2. Navigate to the bolt-contracts directory

  3. Run all tests

    forge test

  4. Run tests with verbose output:

    forge test -vvv

Security Considerations

While the Bolt Contracts have been designed with security best practices in mind, it's important to note that they are still undergoing audits and should not be used in production environments without thorough review and testing. As with any smart contract system, users should exercise caution and conduct their own due diligence before interacting with these contracts.

The following considerations should be taken into account before interacting with smart contracts:

  • Restaking is a complex process that involves trusting external systems and smart contracts.
  • Validators should be aware of the potential for slashing if they fail to meet their commitments or engage in malicious behavior.
  • Smart contracts are susceptible to bugs and vulnerabilities that could be exploited by attackers.