Zum Hauptinhalt springen

# Optimistic Confirmation and Slashing

Progress on optimistic confirmation can be tracked here

https://github.com/solana-labs/solana/projects/52

At the end of May, the mainnet-beta is moving to 1.1, and testnet is moving to 1.2. With 1.2, testnet will behave as if it has optimistic finality as long as at least no more than 4.66% of the validators are acting maliciously. Applications can assume that 2/3+ votes observed in gossip confirm a block or that at least 4.66% of the network is violating the protocol.

## How does it work?#

The general idea is that validators must continue voting following their last fork, unless the validator can construct a proof that their current fork may not reach finality. The way validators construct this proof is by collecting votes for all the forks excluding their own. If the set of valid votes represents over 1/3+X of the epoch stake weight, there may not be a way for the validators current fork to reach 2/3+ finality. The validator hashes the proof (creates a witness) and submits it with their vote for the alternative fork. But if 2/3+ votes for the same block, it is impossible for any of the validators to construct this proof, and therefore no validator is able to switch forks and this block will be eventually finalized.

The safety margin is 1/3+X, where X represents the minimum amount of stake that will be slashed in case the protocol is violated. The tradeoff is that liveness is now reduced by 2X in the worst case. If more than 1/3 - 2X of the network is unavailable, the network may stall and will only resume finalizing blocks after the network recovers below 1/3 - 2X of failing nodes. So far, we haven’t observed a large unavailability hit on our mainnet, cosmos, or tezos. For our network, which is primarily composed of high availability systems, this seems unlikely. Currently, we have set the threshold percentage to 4.66%, which means that if 23.68% have failed the network may stop finalizing blocks. For our network, which is primarily composed of high availability systems, a 23.68% drop in availability seems unlikely. 1:10^12 odds, assuming five 4.7% staked nodes with 0.995 uptime.

## Security#

Long term average votes per slot has been 670,000,000 votes / 12,000,000 slots, or 55 out of 64 voting validators. This includes missed blocks due to block producer failures. When a client sees 55/64, or ~86% confirming a block, it can expect that ~24% or (86 - 66.666.. + 4.666..)% of the network must be slashed for this block to fail full finalization.

## Why Solana?#

This approach can be built on other networks, but the implementation complexity is significantly reduced on Solana because our votes have provable VDF-based timeouts. It’s not clear if switching proofs can be easily constructed in networks with weak assumptions about time.