[[2308.05096] Optimal Flexible Consensus and its Application to Ethereum](https://arxiv.org/abs/2308.05096) # Abstract Classic BFT consensus guarantees safety and liveness for all protocol if fewer than 1/3 nodes are malicious For some use cases, clients may prefer safety over liveness *Flexible consensus* allows each client to opt for higher safety resilience, at the expense of reduced liveness resilience This paper presents the first construction that allows optimal safety-liveness tradeoff for every client simultaneously Modular add-on for existing consensus protcols Additional round of voting, permanent locking by nodes Clients can adopt unilaterally without requiring system-wide changes # Introduction ## Flexible Consensus SMR consensus protocol has clients and replicas Clients input transactions to replicas, which use a distributed algo to develop a common ordering and report back to clients Two desired traits are safety - logs are consistent across clients across time, and liveness - all transactions submitted to all replicas eventually appear in client logs BFT consensus protocols guarantee these as long as a certain fraction are honest replicas Safety and liveness can have different levels of resilience, but classic [[PBFT]]-style prtocols balance them both at 1/3 - the highest both can be in the partially-synchronous setting Different clients may have different needs related to safety, and liveness can always be restored, whereas safety breaks if an inconsistency occurs even once. *Flexible consensus* allows each client to choose a resilience pair where safety resilience >= liveness resilience For these clients, their logs are guaranteed to be consistent across time (safety), and transactions submitted to all replicas eventually appear in the log of event client with f <= liveness resilience ## Quest for Optimal Flexible Consensus Some mechanisms, like DiemBFT, allow for running different instances of the protocol that support different regions of resilience pairs BUT, no single instance can simultaneously support a maximally safety-favoring client and a liveness preserving client ## Contribution: OFlex Family of Resilience-Optimal Flexible Consensus Protocols First resilience-optimal flexible consensus protocols Each can support all clients on a straight line between (0,1) and (1/3,1/3) simultaneously Decouple consensus protocol into two phases: 1. Interactive replica logic that depends only on a system-wide quorum 2/3 2. Confirmation rule run locally by clients that depends on client-specific quorums greater than 2/3 Key idea is to augment replica logic with additional round of voting (post-voting) and permanent locking After further review, this does not seem relevant to my topic, so I'm stopping the reading here. There's a chance I come back to it to see if it would be possible to implement SSF on the client-side instead of at the consensus level, which would be incredibly interesting. I don't think this is a possible approach, since the tradeoff made for safety over liveness would simply mean that these clients would wait until casper checkpoint is confirmed before accepting a block, and only be looking at the finalized chain.