Is it possible to make a large (> 500 validators) and robust (liveness and safety up to f < n/3 byzantine faults) blockchain snappy (~1s finality)?
Over the last few months, @stephenbuttolph and I explored this question.
After many rounds of iteration (i.e. Stephen poking holes in my ideas), we arrived at Vena.
Vena drives finality at network speed, provides strong liveness guarantees, and natively outputs confirmation artifacts (aggregate signature for each block) over large validator sets.
This construction employs a form of tunable aggregation committee broadcast that when successful results in all participants, including the leader, sending less than n messages in a given round.
In the uncommon case that broadcast fails (robustness is parameterizable), Vena falls back to a single, all-to-all broadcast that guarantees eventual progress in the presence of f < n/3 static byzantine faults.
Vena's capacity to recover from "uncooperative" aggregation committee assignments enables aggressive tuning of the broadcast parameterization when the validator set is predominantly honest and online (reducing unneeded message broadcast) and pessimistic tuning when it is not.
If things deteriorate, the all-to-all broadcast fallback ensures safety and liveness will be maintained (as long as there are f < n/3 byzantine faults).
Vena even proposes an out-of-consensus mechanism for participants to dynamically tune robustness, if this occurs.
Optimizing for the "happy path" and falling back to a more expensive mechanism was inspired by Frosty (strong Snowman liveness).
Unlike Frosty, Vena does not require voting to enter an explicit "recovery epoch" or running separate consensus in it.
arxiv.org/abs/2404.14250
As evidenced by the abundance of interesting techniques, the deployment of consensus protocols on public blockchains in byzantine environments is rife with complex tradeoffs between:
* communication complexity
* confirmation latency
* fault tolerance
Vena provides an early exploration into an interesting compromise between these tradeoffs that suits large blockchains.
You can read about Vena in detail here:
hackmd.io/@patrickogrady/vena
If you have any suggestions for techniques to improve Vena's construction or wish to contribute to formal proofs of correctness, please reach out! 🙏
You can read the unrolled version of this thread here: typefully.com/_patrickogrady/tCwiHwu