I worked on a research project called Gasper-Siesta to reduce Ethereum's commit latency. Here is my technical writeup on the project.
Ethereum uses a proof-of-stake consensus protocol to solve BFT-SMR by combining two different gadgets: a fork-choice rule and a finality gadget. The fork-choice rule, LMD-GHOST, is used to produce new blocks. On the other hand, Casper is the finality gadget used to finalize existing blocks produced via LMD-GHOST. The combination of both gadgets is used in Ethereum today and is known as Gasper. Two key techniques of Gasper are chaining and leader-speaks-once. Many other consensus protocols also build on the same properties, such as HotStuff, DiemBFTv4, and Jolteon. Chaining is a technique used to ensure safety of the protocol while reducing expensive cryptography and reusing messages. BFT SMR protocols use voting phases to create quorum certificates (QCs) to prove honest replicas signed a given proposal. To improve throughput, protocols often pipeline quorum certificates to use votes on the second or third phase of a block from round π£ to certify a block in round π£ +1. This helps minimize expensive cryptographic operations and reuse messages. Leader-speaks-once (LSO) is a technique that helps minimize the effect of Byzantine leaders on the progress of the protocol. In this design, leaders propose a block in a given round or view and are rotated out. Other BFT and crash tolerant protocols, such as PBFT and Paxos, use stable leaders and only rotate when leaders do not make progress or behave faulty. This leads to consensus protocols requiring π + 1 consecutive honest leaders to commit a block, where k is a parameter set by the protocol.
However, in scenarios where there are not π + 1 honest leaders, the chain can take significantly longer to finalize. This can occur in scenarios where the network is facing asynchrony, has partitioned, or has buggy consensus layer implementations. By allowing Casper FFG to finalize over any π + 1 honest leaders, we can strengthen liveness and resilience of Ethereum. We show that we can modify Casper to satisfy a property called any honest leaders (AHL), introduced by BeeGees. Essentially, if we have π + 1 potentially non-contiguous honest leaders, we can still finalize a block. This can help improve network resilience under adversarial conditions similar to what is described above. We can achieve this by breaking Casper into two scenarios: a fast commit rule and a slow commit rule. The fast commit rule is identical to Casper today and handles the consecutive honest leaders scenario.
The slow commit rule uses additional state to ensure safety when finalizing over potentially non-contiguous
leaders. We carefully design Gasper-Siesta to allow for blocks to be justified if they do not violate Casper
slashing rules, but not finalize if any other block could have been finalized across non-contiguous views. We
keep track of the previous attestations from replicas voting on proposals to create equivocation proofs that
show whether certain blocks could have been finalized across non-contiguous views. If we have any equivocation
proofs, or conflicting votes with over 2/3 of network stake on each vote, in an attempted commit, we must abort
the commit in the current epoch. We also recognize, similar to BeeGees, that in the partial synchrony model, we
cannot assume blocks will be justified before GST. Thus, prior to committing a block, we check for other
potential committed blocks during periods of asynchrony. We achieve this using the helper function
existsConflictingVotes(FC, JC). This function allows replicas to iterate through the slots of history between
the finalized checkpoint and the current justified checkpoint. We iterate through every slot to ensure there
were no forks of the chain that may have been justified in a conflicting manner. If no conflicting blocks or
forks could have been finalized, we are safe to commit! If we detect any conflicting stake used to attest
conflicting blocks, we must abort our commit. This is because up to 1/3 of network stake can be inactive or not
attest to a slot transition due to network asynchrony, and an additional 1/3 can be Byzantine stake. When we sum
this stake, we see this already reaches the 2/3 of network stake, so any additional stake voting for such a
transition may have been finalized in another chainβs view.
In our pseudocode, implementing this change requires changes to the core data structures and functionality of
Ethereum validators. We iterate over the history and past attestations in lockstep to
check whether there is conflicting history. We abstract this logic away in
existsConfictingVotes(FC, JC), where
we get the local view of the block proposed at a slot. We use the set π΄ to index the attestations that specify
the block at the current slot as the target. The set π΄ tracks all of the proposals from leaders and responses
from replicas at a given slot. We also attach the local view of the replica that send an attestation to check
the attestations are voting along the same view (no equivocation). If a slot is missed, we also check to make
sure no other blocks were proposed for that slot that a replica may not have seen due to asynchrony. We also
check to ensure there exists a valid chain between the given start and end block. Validators try to commit
between their current finalized checkpoint, previous justified checkpoint, and the current justified checkpoint.
We use existsValidChain(start, end) to check there is a valid chain and attestations between these
blocks. We
also check for isKJustified(JC) to ensure there are π + 1 blocks justified for finalization.