var img = document.createElement('img'); img.src = "https://nethermind.matomo.cloud//piwik.php?idsite=6&rec=1&url=https://www.surge.wtf" + location.pathname; img.style = "border:0"; img.alt = "tracker"; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(img,s);
Skip to main content

Set up a Prover

note

You can skip deploying provers in a local devnet if you only want to test basic transaction flow and block proposals. However, because Surge uses a 2-of-3 multi-prover security model, without at least two provers running:

  • No L2 blocks will ever be proven or finalized on-chain.
  • Any actions requiring finalized state (e.g., bridging back to L1, claiming certain rewards) will remain pending or unavailable.

Deploying a prover can be challenging due to:

  • Hardware Requirements: Certain provers (e.g., SGX) require specialized hardware or secure enclaves.
  • Complex Setup: Installing and configuring toolchains, drivers, or required libraries can be time-consuming.

In a based rollup like Surge, provers generate cryptographic proofs verifying L2 blocks proposed by proposers. These proofs are then submitted on-chain through a prover-relayer, marking blocks as verified (finalized).

Without provers submitting proofs, blocks remain unverified, limiting critical functionalities such as cross-chain finalizations.

To see how provers fit into the overall system, refer to the Surge Architecture documentation.

Understanding Provers in Surge​

What is a Prover?​

A prover is a component responsible for generating cryptographic proofs that validate the correctness and integrity of Layer 2 transactions and blocks. Surge leverages multiple provers—three independent ones in total—to ensure the security and reliability of rollup chains.

Why Do You Need Provers?​

Provers are essential because:

  • They guarantee that only valid transactions and blocks are finalized on-chain.
  • They enable trustless, secure interactions between Layer 2 and Layer 1, facilitating safe bridging and asset transfers.
  • They maintain the integrity and finality of the blockchain, preventing invalid or fraudulent state transitions.
  • Surge's 2-of-3 model means that having two of these provers independently confirm a block is sufficient to finalize it on-chain.

How Do Provers Work?​

Provers execute computationally intensive algorithms to create succinct proofs that validate batches of L2 transactions. Once generated, these proofs are submitted on-chain via a prover-relayer, which then finalizes and confirms the validity of these transactions on the blockchain—provided at least two of the three available provers agree on the block.

Prover Requirements for Surge​

Surge Proof Systems​

Surge supports three provers in production scenarios:

Although you only need two of these provers to finalize blocks under Surge’s 2-of-3 security model, you may choose to run all three for maximum redundancy and security. Each prover has distinct setup and operational requirements. Follow the respective guides carefully to properly configure, deploy, and maintain each.

Prover Collateral Requirements​

In Surge, every proposed block needs to be proven. To ensure a 1-to-1 mapping from proposals to proofs, Surge requires proposers to provide collateral; the proving liveness bond, committing to submitting the proof within the proving liveness window (currently set to 24 hours), or forfeitting the the proving liveness bond. In the event that the original proposer does not submit the proof in time, anyone can instead submit a proof for the block, and collect the proving liveness bond. As such, the proving liveness bond acts as both an incentive for the original prover to submit the proof, and as an incentive for someone else to provide the proof in case of original proposer failure.

With this in mind, the proving liveness bond needs to be large enough to ensure both of these incentives are achieved. This worst-case cost for providing a Surge proof involves:

  • an upperbound cost to submit and verify the proof on-chain.
  • the cost to run all 3 provers, in the worst case scenario where there is a bug in 1 of the 3 provers.

On mainnet, we can use mainnet ETH as the collateral, creating a clear financial incentive for ensuring proving tasks are completed. On testnet however, no financial incentive for proving exists.

Proving Liveness Bond on Testnet​

To handle this lack of financial incentive on testnet, we have chosen the proving liveness bond to be 10,000 testnet ETH. This number is chosen to balance permissionlessness and spam protection for Surge.

  • Permissionlessness: Testnet participants can accumulate 10,000 testnet ETH with some minor coordination among other participants.
  • Spam protection: Spam protection: If a block proposer does not provide a proof within the proving liveness window, a malicious block, the proposer will lose the 10,000 testnet ETH proving liveness bond. This creates a loose upperbound on the number of malicious blocks that can be proposed on Surge. Such an upperbound gives any public good entity running the provers a chance to eventually prove these blocks, ensuring the queue of unproven blocks on Surge never becomes too long. In turn, this ensures two critical properties that we must ensure for a rollup:
    • withdrawals can be processed in finite time
    • upgrades can be queued and eventually pushed.