parent
42aaacf520
commit
9fae5aacc2
|
@ -4,52 +4,51 @@ Progress on optimistic confirmation can be tracked here
|
||||||
|
|
||||||
https://github.com/solana-labs/solana/projects/52
|
https://github.com/solana-labs/solana/projects/52
|
||||||
|
|
||||||
At the end of May, the mainnet-beta is moving to 1.1, and testnet
|
At the end of May, the mainnet-beta is moving to 1.1, and testnet is
|
||||||
is moving to 1.2. With 1.2, testnet will behave as if we have 1-block
|
moving to 1.2. With 1.2, testnet will behave as if it has optimistic
|
||||||
conf as long as no more than 4.66% of the validators are acting
|
finality as long as at least no more than 4.66% of the validators are
|
||||||
maliciously. Applications can assume that 2/3+ votes observed in
|
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
|
gossip confirm a block or that at least 4.66% of the network is violating
|
||||||
violating the protocol.
|
the protocol.
|
||||||
|
|
||||||
## How does it work?
|
## How does it work?
|
||||||
|
|
||||||
The general idea is that validators have to continue voting, following
|
The general idea is that validators must continue voting following their
|
||||||
their last fork, unless they can construct a proof that their fork
|
last fork, unless the validator can construct a proof that their current
|
||||||
may not reach finality. The way validators construct this proof is
|
fork may not reach finality. The way validators construct this proof is
|
||||||
by collecting votes for all the other forks, excluding their own.
|
by collecting votes for all the forks excluding their own. If the set
|
||||||
If the set of valid votes represents over 1/3+X of the epoch stake
|
of valid votes represents over 1/3+X of the epoch stake weight, there
|
||||||
weight, there is may not be a way for the validators current fork
|
may not be a way for the validators current fork to reach 2/3+ finality.
|
||||||
to reach 2/3+ finality. The validator hashes the proof (creates a
|
The validator hashes the proof (creates a witness) and submits it with
|
||||||
witness) and submits it with their vote for the alternative fork.
|
their vote for the alternative fork. But if 2/3+ votes for the same
|
||||||
But if 2/3+ votes for the same block, it is impossible for any of
|
block, it is impossible for any of the validators to construct this proof,
|
||||||
the nodes to construct this proof, and therefore no node is able
|
and therefore no validator is able to switch forks and this block will
|
||||||
to switch forks and this block will be eventually finalized.
|
be eventually finalized.
|
||||||
|
|
||||||
|
|
||||||
## Tradeoffs
|
## Tradeoffs
|
||||||
|
|
||||||
The safety margin is 1/3+X, where X represents the minimum amount
|
The safety margin is 1/3+X, where X represents the minimum amount of stake
|
||||||
of stake that will be slashed in case the protocol is violated. The
|
that will be slashed in case the protocol is violated. The tradeoff is
|
||||||
tradeoff is that liveness is now reduced by 2X in the worst case.
|
that liveness is now reduced by 2X in the worst case. If more than 1/3 -
|
||||||
If more than 1/3 - 2X of the network is unavailable, the network
|
2X of the network is unavailable, the network may stall and will only
|
||||||
may stall and will resume finalizing blocks after the network
|
resume finalizing blocks after the network recovers below 1/3 - 2X of
|
||||||
recovers. So far, we haven’t observed a large unavailability hit
|
failing nodes. So far, we haven’t observed a large unavailability hit
|
||||||
on our mainnet, cosmos, or tezos. For our network, which is primarily
|
on our mainnet, cosmos, or tezos. For our network, which is primarily
|
||||||
composed of high availability systems, this seems unlikely. Currently,
|
composed of high availability systems, this seems unlikely. Currently,
|
||||||
we have set the threshold percentage to 4.66%, which means that if
|
we have set the threshold percentage to 4.66%, which means that if 23.68%
|
||||||
23.68% have failed the network may stop finalizing blocks. For our
|
have failed the network may stop finalizing blocks. For our network,
|
||||||
network, which is primarily composed of high availability systems
|
which is primarily composed of high availability systems a 23.68% drop
|
||||||
a 23.68% drop in availabilty seems unlinkely. 1:10^12 odds assuming
|
in availabilty seems unlinkely. 1:10^12 odds assuming five 4.7% staked
|
||||||
five 4.7% staked nodes with 0.995 of uptime.
|
nodes with 0.995 of uptime.
|
||||||
|
|
||||||
## Security
|
## Security
|
||||||
|
|
||||||
Long term average votes per slot has been 670,000,000 votes /
|
Long term average votes per slot has been 670,000,000 votes / 12,000,000
|
||||||
12,000,000 slots, or 55 out of 64 voting validators. This includes
|
slots, or 55 out of 64 voting validators. This includes missed blocks due
|
||||||
missed blocks due to block producer failures. When a client sees
|
to block producer failures. When a client sees 55/64, or ~86% confirming
|
||||||
55/64, or ~86% confirming a block, it can expect that ~24% or (86
|
a block, it can expect that ~24% or `(86 - 66.666.. + 4.666..)%` of
|
||||||
- 66.666.. + 4.666..)% of the network must be slashed for this
|
the network must be slashed for this block to fail full finalization.
|
||||||
block to fail full finalization.
|
|
||||||
|
|
||||||
## Why Solana?
|
## Why Solana?
|
||||||
|
|
||||||
|
@ -62,11 +61,11 @@ time.
|
||||||
## Slashing roadmap
|
## Slashing roadmap
|
||||||
|
|
||||||
Slashing is a hard problem, and it becomes harder when the goal of
|
Slashing is a hard problem, and it becomes harder when the goal of
|
||||||
the network is to be the fastest possible implementation. The
|
the network is to have the lowest possible latency. The tradeoffs are
|
||||||
tradeoffs are especially apparent when optimizing for latency. For
|
especially apparent when optimizing for latency. For example, ideally
|
||||||
example, we would really like the validators to cast and propagate
|
validators should cast and propagate their votes before the
|
||||||
their votes before the memory has been synced to disk, which means
|
memory has been synced to disk, which means that the risk of local state
|
||||||
that the risk of local state corruption is much higher.
|
corruption is much higher.
|
||||||
|
|
||||||
Fundamentally, our goal for slashing is to slash 100% in cases where
|
Fundamentally, our goal for slashing is to slash 100% in cases where
|
||||||
the node is maliciously trying to violate safety rules and 0% during
|
the node is maliciously trying to violate safety rules and 0% during
|
||||||
|
|
Loading…
Reference in New Issue