Staking Mechanism
In the Succinct Prover Network, staking acts to prevent liveness failures and secure provers' contributions to the network. The amount of stake a prover has is used to determine the number of concurrent auctions they can participate in. For any request, before a competitive auction begins, the network checks if the prover has enough stake to participate in the auction.
Staking for Economic Security
Staking is primarily used in the Succinct Prover Network to provide accountability for provers to deliver their assigned proofs within user-specified deadlines, and is therefore a form of economic security for the network. For each proof request, users in the network can specify a MIN_STAKE_AMOUNT that defines the minimum amount of stake required for a prover to be eligible to participate an auction for the request. If the requester specifies a high MIN_STAKE_AMOUNT, this means that the requester is very sensitive to the proof being delivered within the deadline. The prover who is assigned the request risks having this amount slashed if they do not deliver the proof in time.
Example: Staking for Real-Time Proving
A concrete example of how staking is used for economic security in the network is in the case of real-time proving for Ethereum, which is the ability to generate a ZK proof of Ethereum blocks within a single slot time (currently 12 seconds). Succinct recently achieved real-time proving on a cluster of GPUs.
In Ethereum, block builders are responsible for producing blocks and submitting them to the network. With the integration of real-time proving in Ethereum, they may be additionally responsible for submitting ZK proofs of their blocks. If the proof is not submitted in time, the block will be ignored.
Block builders can use the Succinct Prover Network to source these proofs. Because receiving the proof in time is economically valuable, and the value of a successful block can vary, builders can use the network's staking functionality to ensure that provers have an incentive to deliver their proofs in time. They can do this by setting a MIN_STAKE_AMOUNT that is high enough to cover the value of the proof. Staking therefore gives Ethereum block builders high confidence in the network's ability to procure procure proofs reliably.
Delegated Staking
Provers can provide their stake themselves or source it from third parties via delegated staking. Anyone can stake PROVE and delegate it a prover to cover their staking requirements.
Delegates are interested in staking to provers for two reasons. First, they earn additional incentives proportional to their share of the total amount of stake. Second, they also earn a fraction of PROVE fees that their designated prover earns; this fraction is decided by the prover.
The delegated staking mechanism therefore decouples proving capabilities from staking requirements, allowing provers to source capital from external market participants.
Delegated staking is implemented via a nested vault structure using the PROVE token. For more information on how delegated staking works, see the PROVE staking documentation.
Walkthrough: Staking
Suppose Alice makes a proof request for which she specifies a MIN_STAKE_AMOUNT of 100 PROVE. Bob is a prover who has himself staked 10 PROVE and sourced 90 PROVE from external delegates. Therefore, he is entitled to participate in the auction for Alice's request. In contrast, if Charlie only has 50 PROVE in total stake, he is not eligible to participate in the auction. As Bob and Charlie increase their stake, they will be able to participate in more concurrent auctions for proof requests.
Suppose Bob wins the auction and delivers the proof within the deadline. In this case:
- Bob earns the fee from the request.
- Bob's delegates earn a fraction of the fee for the request, for providing economic security to the prover.
- The protocol takes a network fee.
However, if Bob fails to deliver the proof in time, the network will slash his stake. All stakers also earn additional incentives proportional to their share of the total amount of stake.