Vena is an optimistically responsive consensus protocol in the partially synchronous network model tailored for deployment on public blockchains with large validator sets. Vena employs a form of "optimistic" aggregation committee broadcast that when successful results in all participants, including the leader, sending less than messages in a given round. In the uncommon case that this broadcast fails (robustness is parameterizable), Vena falls back to a single, all-to-all broadcast that guarantees eventual progress in the presence of static byzantine faults. It is left to future work to construct a formal proof of correctness for Vena.
Simplex Consensus, as proposed by Benjamin Y. Chan and Rafael Pass, is an optimistically responsive consensus protocol that tolerates static byzantine faults in the partially synchronous network model. While Simplex Consensus "matches the best optimistic liveness bounds, while at the same time matching and even improving the best known pessimistic liveness bounds (both in expectation and in the worst-case)," its application to public blockchains with large validator sets has been limited by its usage of multiple all-to-all broadcasts per round. Chan and Pass suggest that deployment of Simplex Consensus in such environments may be achieved by "subsampling the committee of voters" to reduce the number of messages sent and received by any participant, akin to Algorand.
To bound the probability of failure on any composed committee ( where is the size of the committee) to a reasonable level, however, Algorand parameterizes each committee to contain thousands of participants drawn from all "online tokens". For some critical operations, the committees are parameterized to include over participants (which bounds the risk of failure to if where is the total population of "online tokens"). This parameterization is made practically efficient by allowing operators that control multiple selected tokens to aggregate their participation using a technique referred to as "party aggregation". In a scenario where a large population of operators each own the same number of tokens (where each committee participant in expectation has ~1 selected token), the number of messages sent and received by each participant in each round will still be significant.
Vena is an extension of Simplex Consensus tailored for deployment on public blockchains with large validator sets that retains both optimistic responsiveness and the ability to confirm blocks with a single, honest leader. Vena takes a different approach to scaling participation than that suggested by Chan and Pass. Rather than subsampling the committee of voters, Vena employs a form of "optimistic" aggregation committee broadcast that when successful results in all participants, including the leader, sending less than messages in each round. We refer to Vena's aggregation committee broadcast as "optimistic" because validators always attempt to use it at least once for broadcast per round, even in some cases where they end up voting for the "dummy" block (the fallback vote after a timeout). Vena remains correct in the presence of static byzantine faults unlike alternative protocols that operate over a subsample of the total population of participants (review the performance of any configuration when ).
Aggregation committees, popularized by the ETH2 Altair Fork, are some randomly assigned subset of validators that work together to aggregate their communications with a broader network (often by sending messages to other aggregation committees rather than all other participants) to minimize the communication complexity of the broader population of which they are part. Each aggregation committee typically consists of some set of "aggregators" to which all committee members send their messages to. Likewise, each aggregator also pools messages sent by other committees (specifically the aggregators in those committees) and forwards them to all committee members once they have a sufficient stake weight. As long as there exists one honest aggregator in an aggregation committee, messages generated by honest participants in the committee will be forwarded to other aggregators and messages sent to a committee will be forwarded to its participants.
Aggregation committees in Ethereum, to accommodate a now superseded data sharding model and to protect RANDAO, are tuned to never incur a supermajority byzantine takeover. Vitalik Buterin concluded that a minimum committee size of was required to maintain a probability of a supermajority byzantine takeover, when drawing from an equal weight population that is dishonest. Ethereum opted to use members because it is the next higher power of 2. Likewise, the target number of aggregators in each committee is set to 16 to avoid the scenario where all aggregators in a committee are dishonest. Vena has no such requirements around aggregation committee construction and can recover from any assignment of participants and/or aggregators with a single, all-to-all broadcast.
Vena's capacity to recover from "uncooperative" aggregation committee assignments enables aggressive tuning of the broadcast parameterization to reduce message complexity when the validator set is predominantly honest and online. If things suddenly deteriorate, the all-to-all broadcast fallback ensures safety and liveness will be maintained (as long as there are byzantine faults where is the number of total participants). Optimizing consensus for the "happy path" and falling back to a more expensive but rarely invoked mechanism to recover was inspired by Frosty, however unlike Frosty, Vena does not require voting to enter an explicit "recovery epoch" nor does it require running a separate consensus protocol in said "recovery epoch" to progress to the next round.
This post concludes with a section that outlines future optimizations for Vena. First, it offers an overview of a streamlined variant of Vena (similar to the streamlined variant proposed in Simplex Consensus) where a for is sent in the same message as a for , reducing the number of messages sent in each successful round by . This proposed variant, like Vena, does not require consecutive honest leaders to finalize but does increase confirmation latency. Second, it outlines a mechanism for validators to individually adjust their aggregation committee broadcast strategy based on their observation of network conditions (unseen notarizations included in newly constructed blocks and the dummy block rate). This subjective, out-of-consensus tuning would allow validators to increase aggregation committee robustness even when a standard block cannot be finalized (where a synchronized parameter change or validator eviction could be done). Lastly, it outlines a technique to further reduce message complexity (for very large validator sets) using a multi-layered aggregation committee broadcast where committees can be composed of aggregators who mediate the broadcast to other committees. Vena assumes participant depth of 1, however, this isn't required and could be increased to reduce message complexity at the cost of additional latency.
The deployment of consensus protocols to public blockchains in byzantine environments is rife with complex tradeoffs between communication complexity, confirmation latency, and fault tolerance. Vena explores a favorable balance between these tradeoffs for blockchains with large validator sets. It is left to future work to construct a formal proof of correctness for Vena.
Vena borrows terminology and techniques from Simplex Consensus. It is strongly recommended that you familiarize yourself with the linked work before continuing.
Vena operates over a chain of blocks where each block is a tuple of . At a given height , there exists either a "standard" block or a "dummy" block (of form ) that does not extend the blockchain. is an array of notarizations (i.e. a BLS Multi-Signature) each over the hash of some block (either standard or dummy) from to , inclusive. The dummy block does not contain a notarization for (if it did, it may not be possible to achieve a quorum with a dummy block vote). is the hash of some standard block that the block at extends. is a set of arbitrary bytes contained in the block at (i.e. transactions).
Vena employs a form of "optimistic" aggregation committee broadcast that when successful results in all participants, including the leader, sending less than messages in a given round. Each aggregation committee is composed of some subset of validators, of which some smaller subset are given the unique role of "aggregator". Aggregators collect signed messages from members of a committee, aggregate their signatures, and forward aggregated messages to the aggregators of other committees. When receiving messages from other committees, aggregators buffer signatures until there exists signatures over a message, at which point the message and aggregate signature are forwarded to all members of the committee the aggregator is assigned.
Validators only belong to one aggregation committee for a given height and rotate which committee they belong to at each height (can be configured to be stable for longer periods of time). This assignment of validators to aggregation committees is performed using a deterministic and bias-resistant random oracle. One leader is randomly selected per height to propose a block. The leader is responsible for proposing a block and broadcasting it to the aggregators of all aggregation committees. After broadcast, the leader (who is a member of some aggregation committee but is not an aggregator) behaves as a normal validator.
Vena is optimistically responsive (i.e. blocks are finalized at network speed) when there is an honest leader and a "cooperative" aggregation committee assignment. A cooperative assignment exists when a leader's standard block at can be (if there exists an honest leader) broadcast to honest participants before , vote messages for from honest participants reach honest participants before , and finalize messages for from honest participants eventually reach honest participants (timeouts explained in detail later). In other words, a cooperative assignment is simply a round where the constructed aggregation committees provide a functional approximation of multicast.
To see how Vena works in practice, let's first walkthrough this "happy path". To begin, the honest leader first sends a standard block to the aggregators of all aggregation committees. The aggregators then forward the block to the participants of their committee:
After a block is distributed to all aggregation committees, participants in each committee vote on the block. Participants broadcast their vote messages to the aggregators of their committee. Aggregators aggregate these vote messages and forward the aggregated committee vote to the aggregators of other committees. To retain optimistic responsiveness, aggregators use message weight to determine when to forward messages to other aggregation committees rather than timeouts. Aggregators send an initial aggregate message as soon as they collect an initial message weight, the "Initial Broadcast Weight" (), and then send some number of additional aggregate messages every "Delta Broadcast Weight" () they collect. and can be dynamically adjusted based on network conditions and desired tolerance to byzantine faults. When an aggregator has buffered vote messages, they forward the aggregated notarization to all participants in their committee and to the leader of (to ensure they enter the next round within of the first honest aggregator):
Upon receiving vote messages (referred to as a "notarization" for ), the participants in each committee begin voting on (referred to as "entering the next round") and attempt to finalize the block at . Like before, participants broadcast their finalize messages to the aggregators of their committee. Aggregators aggregate these finalize messages and forward the aggregated finalization to the aggregators of other committees (again once they collect signatures from of the stake weight of the committee and then subsequently every ). When an aggregator has buffered finalize messages, they forward the aggregated finalization to all participants in their committee:
Hooray! The block is confirmed!
In the case that a validator has not seen a block at height by , it will optimistically send a vote for the dummy block via its assigned aggregation committee. Like Simplex Consensus, any honest participant in a given round will send either a dummy block vote message or a standard block finalize message. As soon as a participant begins the dummy block voting procedure, they will never contribute to finalizing a standard block at . Vena's aggregation committees are considered "optimistic" because validators attempt to use said aggregation committees although there is no proof that they are functional (unbeknown to the validator, the reason they may be voting for the dummy block is because all aggregators are byzantine and they didn't forward the leader's standard block). A useful byproduct of optimistic aggregation committee broadcast is that dishonest leaders cannot force validators to fallback to all-to-all communication by not broadcasting a block in a timely manner.
When all the aggregators for a given committee are dishonest/offline, committee participants may not learn about new blocks, messages sent by committee participants may not be sent to other aggregation committees, they may not receive aggregate messages from other aggregation committees, and/or notarizations may not be sent to the leader at . There can be more than one aggregator assigned to each committee to increase the likelihood there is at least one honest aggregator. The robustness and communication complexity of different aggregation committee configurations is explored in detail in later sections (directly correlated).
If a large number of aggregators are offline or byzantine, the aggregation committee assignment in a round may be "uncooperative" and it may not be possible to produce a notarization for any block at using aggregation committee broadcast. If a validator has not seen a notarization for some block (standard or dummy) at by , it enters an all-to-all broadcast phase where it sends a vote for the dummy block to all other validators. This broadcast fallback does not require any aggregation committee reconfiguration, opting instead for all validators to "bail out" of a given configuration and try again at .
It is possible that a participant may by chance be included in a "run" of faulty aggregation committees and not see a notarization or finalization for some time (potentially much later than other participants especially if almost all other aggregation committees are stable). If this occurs, the participant will stall until it eventually receives a notarization for when receiving a block broadcast at (where is the number of heights the participant has been stalled). At this time, said participant will backfill the standard block ancestry of and enter (as they would have seen a notarization for to ). If there is an honest leader and a cooperative aggregation committee assignment, this will permit honest participants to then send vote messages (and eventually notarize) for the standard block (even though they potentially entered long after the leader and/or other participants).
The leader in round has (evaluated against the local timer set by the first participant entering round ) to distribute a standard block to honest participants for said block to have any chance of being notarized (and eventually included in the canonical blockchain). It takes for a standard block to be sent from an honest leader to all aggregators and for honest aggregators to forward the block to all participants in their committee. Thus, an honest leader must enter within of the first honest participant for the standard block they produce to be notarized.
Said differently, if a byzantine adversary of can force any honest participant to enter round more than before the leader (e.g. they control all aggregators for the committee containing the leader), they can prevent the notarization of a standard block at produced by an honest leader even if the aggregation committee assignment is cooperative. If repeated, this could allow an adversary to significantly reduce the number of standard blocks included in the canonical blockchain.
The dummy block vote timeout semantics are slightly different in Simplex Consensus (timeout after not seeing notarization rather than after not seeing a block), however, the same potential attack applies. Simplex defends against this by requiring all honest participants that see a notarization for to "multicast [their] view of the notarized blockchain to everyone else." This ensures all honest participants enter within of the first honest participant (providing enough time to construct a notarization before timeout). Vena could introduce the same mechanism and require all honest participants to send a broadcast to all other participants when they see a notarization for , however, this would arguably defeat the purpose of introducing aggregation committees in the first place (as the "happy path" would no longer operate with sublinear message complexity).
Vena, instead, requires all honest aggregators to forward any notarization they see for to the leader at when sending said notarization to all participants in their committee. This ensures that if a notarization is constructed through aggregation committee broadcast that the leader at will see a notarization for within of the first honest aggregator. Aggregators (assuming a cooperative assignment) are the first honest participants to enter .
If no honest aggregators see a notarization for , it is still possible that the leader at will not enter within of the first honest participant and a standard block notarization at will be impossible to construct (even if there is an honest leader and a cooperative assignment at ). Consider some aggregation committee assignment where all aggregators across all committees are dishonest but not crashed. They follow the protocol as described previously (forwarding a standard block from an honest leader, aggregating vote messages from their committee, forwarding aggregate vote messages to other committees) but differ in 2 specific flows. Once each aggregator collects vote messages for , they forward the notarization to all committee participants (unless that participant is the leader in the next round ) and they do not forward said notarization to the leader at if they are not a committee participant. We later explore how the dummy block rate (especially when a standard block is seen after the timeout) can be used to locally adjust aggregation committee assignment robustness to counteract sudden changes in byzantine participation without a consensus decision (adding more aggregators makes it less likely no honest aggregator will see a notarization if any honest committee participant does).
For completeness, if the aggregation committee assignment is not cooperative, the all-to-all dummy block vote that occurs at also results in an honest leader entering within of the first honest participant. There is a thoughtful analysis of this case in the original Simplex Consensus paper.
Participants enter round as soon as they see a notarization for a standard block or a dummy block at , however, they will only finalize if they see finalize messages for a standard block at . Recall, the dummy block never extends the blockchain (and is thus never finalized). A participant may see up to 2 notarizations per height (one for the standard block and one for the dummy block). If this occurs, the leader of can choose to include either notarization (may not have seen other at time of block broadcast) and build off of the standard block at or some earlier standard block (that does not conflict with the finalized tip) as long as they can provide all dummy block notarizations between and , inclusive.
When Validator enters round :
If :
If :
If :
Vena is a Permissioned Consensus protocol and assumes all validators are known and fixed prior to the start of each round (validators can still change between rounds). Aggregator in a Committee serves as both an Aggregator and a Committee Participant (also sends its own and messages). Leader is never an Aggregator.
Participants only broadcast a vote for the first non-dummy block they receive at a given height that does not conflict with their finalized tip. Observing a block broadcast that conflicts with the finalize tip (under some conditions), observing multiple block broadcasts at a given height , or observing a participant sending a vote/finalize message for conflicting standard blocks at could be used to apply a penalty (i.e. slashing).
Vena participants begin voting for the dummy block as soon as ("standard block timeout") fires. This differs from Simplex Consensus where participants only begin voting after ("notarization timeout"). Simplex Consensus could adopt this technique to reduce the expected round latency for dishonest leaders.
Initial Broadcast Weight () and Delta Broadcast Weight () are configurable and can be dynamically adjusted based on network stability and desired tolerance to byzantine faults (where less required tolerance can lead to more "dummy blocks" but can reduce message complexity without reducing safety tolerance). When sending a delta weight broadcast, aggregators still send the cumulative aggregated message to other aggregators (not just an aggregation of the signatures received since the last broadcast). This doesn't require extra bandwidth or computation by the broadcasting aggregator and makes tracking aggregated messages easier for the receiving aggregator.
A cooperative assignment exists when aggregation committees are constructed such that the standard block can be (if there exits an honest leader) broadcast to honest participants before , vote messages for from honest participants reach honest participants before , and finalize messages for from honest participants reach honest participants.
To finalize a standard block at (and transitively its ancestry), there must exist some honest leader that enters within of the first honest participant, said leader produces and broadcasts a valid standard block at , and a cooperative aggregation committee assignment at . While byzantine faults are static, the behavior of any byzantine actor is not. It is possible for some actor to vote honestly for and then refuse to produce a finalize message for or aggregate committee finalize messages for (if an aggregator). If this occurs, a standard block may be notarized at but never be finalized at .
The timer to broadcast an optimistic dummy block vote is set to because the latest possible time an honest leader will enter (if there is at least one honest aggregator that sees a notarization in ) is (evaluated against the local timer set by the first participant entering round ). It will take to disseminate their standard block to the first honest participant entering round .
The timer to broadcast a pessimistic dummy block vote is set to because all honest participants in a cooperative assignment in should enter within of the first honest aggregator in their assigned committee (which should itself be within of other aggregators). If there is a cooperative assignment in , it takes (after the timeout) for an optimistic dummy block vote to be communicated over the aggregation committees. This means that the latest a participant should see said notarization is (evaluated against the local timer set by the first participant entering round ). Note, Vena is not optimized for the case where there are a significant number of uncooperative assignments (in this case, aggregator robustness should be increased).
It is important that honest participants don't accept standard block votes from other participants that aren't aggregators. Otherwise it would be easier for a byzantine adversary to cause an honest node to enter more than before the leader for .
Other consensus protocols have reduced latency and/or message complexity in the "happy path" by only sending certain messages to the leader in round or (at the cost of worse performance in the "worst case"). Similar changes could be made to Vena by modifying aggregators to send votes to the leader at and rely on leader to broadcast notarization for in . There are other complexities of pursuing this approach that are considered future work to explore.
To make the comparisons in this section easier, we assume all participants enter a given round of consensus at the same time.
With the introduction of aggregation committees, Vena is not (nor does it attempt to be) as fast as Simplex Consensus. However, it is still optimistically responsive when there is an honest leader and a cooperative aggregation committee assignment. On the optimistically responsive path, Vena confirms blocks 2.6x slower than Simplex Consensus ( rather than ). The block time in Vena, on this path, is 1.6x slower than Simplex Consensus ( rather than ).
If confirmation latency is more important than message complexity when there is a dishonest leader or aggregation committees are uncooperative, Vena can be configured to avoid optimistic dummy block voting and immediately transition to all-to-all broadcast. This would result in notarization latency of in the "unhappy path" instead of (same as Simplex Consensus).
Simplex Consensus, for comparison, has the following confirmation latency profile:
To better reason about and , let us also translate Snowman Consensus to this model. Snowman Consensus, like Simplex and Vena, is optimistically responsive and routinely finalizes blocks in ~1.5s over 1800 validators. Confirmation occurs in time assuming that all polls are successful:
In Snowman Consensus, there is no dedicated block broadcast step. Instead, participants poll each other for new blocks and upon learning of one begin to vote on it (after fetching it from the peer that first informed it of its existence). Snowman Consensus collects no voting artifacts from participants and requires an out-of-protocol mechanism to generate certificates of acceptance (Vena provides this out-of-the-box).
The communication complexity of Vena (prior to all-to-all broadcast) is primarily dependent on:
As discussed previously, Vena does not require committees to be supermajority honest for correctness, so committees don't need to contain a significant number of validators. Vena, however, is more sensitive to the number of honest aggregators in each committee as one honest aggregator is required to forward messages between honest participants in different committees and honest aggregators help honest leaders enter the next round in a timely manner. If there are no honest aggregators in a committee (even if all non-aggregators are honest), their messages (outside of a fallback all-to-all dummy block vote) will never reach other validators. Likewise, setting the value of too high means that even when there are honest aggregators, aggregation committee signatures will never be forwarded to other committees. Setting the value of too high means that the number of messages sent by aggregators (not non-aggregators) could far exceed the messages they would send in Simplex Consensus.
We can model the communication complexity of Vena as follows:
It is left to future work to better optimize the broadcast of the block within an Aggregation Committee. As currently specified, each Aggregator will forward the entire block to each Committee Participant.
Simplex Consensus has the following communication profile:
To reduce the message complexity of Simplex, one could batch the notarized view broadcast with the block finalize broadcast on the "happy path".
Again, to put things in context, let us also represent Snowman Consensus in this model. Snowman Consensus, unlike many other consensus mechanisms, only requires an expected constant communication overhead per processing in the "happy path" (when the protocol is not under substantial byzantine attack):
We assume all Snowman Consensus polls are successful and symmetric to simplify the analysis.
Depending on the desired tolerance to byzantine faults when confirming standard blocks, there are many ways to reasonably compose (where the communication complexity is expected to be less than Simplex Consensus) Vena's aggregation committees. To help explore the tradeoff between robustness and message complexity, we simulate the performance of Vena over a range of possible values of (the number of aggregators per committee), (the initial broadcast weight), and (the delta broadcast weight) for a given (the number of aggregation committees) and (the number of validators). The code for these simulations is included at the end of this write-up and can be modified to explore different settings of and (which default to and , respectively). The simulation is run over 10,000 samples for each configuration and the percentage of cooperative samples (where a standard block is confirmed) is recorded (we always assume the leader is honest). Recall, a failure of a given sample just means that the standard block was not confirmed but does not mean that the protocol stalled (as participants always fallback to all-to-all broadcast).
As noted in the original Simplex Consensus paper:
To recover a streamlined protocol, it is possible to “piggyback” the finalize message onto the first vote message of the next block; this would only make liveness a little slower, and consistency would still hold.
A similar optimization could be applied to Vena to reduce the number of messages attributable to each round . Unlike many other "streamlined" protocols, this optimization could be introduced without requiring consecutive, honest leaders/healthy aggregation committees to finalize a standard block. To see how this is true, let us consider a scenario where some honest leader broadcasts a block at , participants vote for , and the notarization of the standard block is delivered before (such that participants enter and will never vote for the dummy block at ). Now, let us say that the leader elected at does not broadcast a block (or there is an uncooperative aggregation committee assignment). After , participants will broadcast a vote for the dummy block at and will include their finalize for in the same message. If the dummy block for is not notarized by , these participants will then all-to-all broadcast a vote for the dummy block at including the same finalize for . The "trick" here is that some block in (standard or dummy) is always voted upon, whether or not there is an honest leader (allowing , if its notarization is delivered before to honest participants, to always be confirmed).
The communication profile of such an approach would look something like:
The described approach to streamlining is not without tradeoffs. Streamlining Vena would increase the confirmation latency for (as participants would wait to broadcast their finalization for until they voted for a block at instead of as soon as they saw a notarization for ). There is likely, however, some set of potential deployers of Vena that would trade a further elevated confirmation latency for a meaningful reduction in message complexity.
As demonstrated previously, there are a number of parameters (all else equal) that have a significant impact on the robustness and communication profile of Vena. It is worthwhile to consider adjusting these parameters based on observed network conditions (e.g. unseen notarizations included in newly constructed blocks, the dummy block rate, the all-to-all fallback rate) to maintain an optimal balance between robustness and message complexity. In essence, why incur additional network overhead to defend against a byzantine adversary if of the time no such adversary exists (recall, safety will always be maintained regardless of aggregation committee robustness)?
A network with less than byzantine participation can almost always confirm blocks with only 1 aggregator per committee (2048 validators, 32 committees, 64 participants per committee):
Likewise, the same can be considered for (the initial broadcast weight) and (the delta broadcast weight) to dynamically adjust the message complexity of Vena based on previously observed committee participation. This should allow the number of broadcasts per aggregator (per vote/finalize) to approach ~1.
When implementing such a feature, it would be wise to avoid relying on standard block finalization to perform a synchronized adjustment to aggregation committee parameterization. Standard block finalization requires a successful aggregation committee shuffle and a large, sudden drop in participation (i.e. AWS outage of of validator set) could prevent the finalization of a standard block for hours (even when participants are online). Let us sketch an algorithm that each validator can follow to adjust their broadcast robustness independently (agreement on aggregation committee roles never synchronized):
To further reduce message complexity (which may be required to support very very large validator sets), Vena could introduce a multi-layer aggregation committee topology. Instead of populating each committee with aggregators and participants, layers of committees could be populated with "super-aggregators" and "sub-aggregators" where each super-aggregator is responsible for serving the role of an aggregator in a Vena committee and each sub-aggregator is a participant in a given layer and a super-aggregator in a committee one layer deeper. At the lowest layer, committees would contain sub-aggregators as aggregators and some set of participants which serve as neither super-aggregators nor sub-aggregators elsewhere.
Each layer would incorporate committee-based aggregation but instead of forwarding aggregated messages to all other "super-aggregators" at a layer (across committees like in Vena), messages would just be passed to the "super-aggregators" in the parent layer (the committee in in which the super-aggregator of serves as a sub-aggregator). When at the first layer, messages would be passed to all other aggregators (across committees). This extra relaying per message would increase latency per additional layer introduced.
If you are interested to learn more about this approach, Vitalik Buterin explored the idea of supporting multiple layers of aggregation a few years ago in "Paths toward single-slot finality". His high-level construction contemplates how to best integrate layers of aggregation within Ethereum's existing consensus (or a close derivative of it) but generally speaking seeks the same outcome: scaling participation in a single round of consensus to massive numbers of participants.
Thanks to Benjamin Y. Chan (byc@cs.cornell.edu) and Rafael Pass (rafaelp@tau.ac.il) for their novel work on Simplex Consensus. Thanks to Benjamin Y. Chan, in particular, for answering detailed questions about Simplex Consensus and for reviewing numerous pre-release drafts of Vena.
Thanks to Stephen Buttolph for contributing "Delta Signatures" (to maintain optimistic responsiveness), suggesting to explore the use of multi-layer aggregation committees, for collaborating on "Dynamically Adjusting Aggregation Committee Parameterization", and for catching numerous errata in earlier drafts. He is as much an author of Vena as I am.
Thanks to Michael Kaplan for suggesting that "Delta Signatures" include the aggregation of all messages seen up to weight rather than just weight.
Thanks to Aaron Buchwald, Andrew Lewis-Pye, and Kevin Sekniqi for their feedback during initial Vena research.
Thanks to Ben Edgington for publishing Upgrading Ethereum, which clearly details how Aggregation Committees work in ETH2.
This simulation code computes the probability that a subsampled committee of size has faults given an attacker controls proportion of the validator set. Below, you'll find some example configurations and the code used to reproduce the results. You can read more about this calculation here.