Split Alpha into AlphaPreference and AlphaConfidence

[StephenButtolph]

Background

The Avalanche network uses the Snow* consensus protocols to reach distributed agreement. Specifically, each blockchain runs its own isolated instance of Snowman.

Snowman

Snowman is a multi-decree multivariate chain-based consensus process built from the single-decree binary consensus protocol, Snowball. It runs (potentially many) dependent Snowball protocols concurrently, which form a binary tree with the root being the last accepted Snowball decision.

As an example:

graph BT
  A[LastAccepted]
  B[Block A]
  C[Block B]
  D[Block C]

  B-->A
  C-->A
  D-->C

The tree above has 3 processing blocks, A, B, and C. For simplicity, we'll ignore that blocks can have many conflicts. Since A and B are conflicting there is a Snowball instance that will determine which block to accept. Even though C is built on top of B, this does not impact the likelihood of B being accepted over A. The only mechanism that decides between A and B is the Snowball instance.

Snowball

Snowball's goal is to have a network agree on one of two values. Typically, we refer to these values as Red and Blue. This process can itself be broken into 2 primary mechanisms.

1. Color selection - Each node attempts to match its own color to the network's majority color. Over time, the network should converge so that every correct node reports the same color.
2. Finalization detection - Each node determines when to stop changing their color.

It's critical that these mechanisms are able to tolerate arbitrary failures. Specifically, nodes reporting incorrect colors, or not reporting any color at all, must not impact network progress.

The existing Snowball specification is:

def onQuery(peer, peerColor):
  respond(peer, currentColor) // Send our current color to the peer, which might be ⊥
  if currentColor = ⊥:
    currentColor = peerColor // If we do not currently have a color, adopt the peer's color

def snowball():
  confidence = 0
  preferenceStrength = {Red:0, Blue:0}
  while confidence < β:
    if currentColor = ⊥:
      continue // Wait until we hear of a color from a peer

    sampledNodes = sample(N, k) // Sample k nodes from the network
    sampledPreferences = [query(node, currentColor) ∀ node ∈ sampledNodes]
    sampledPreferenceCounts = count(sampledPreferences) // Map each color to the number of times it was sampled
    sampledMajorityColor = argmax(sampledPreferenceCounts)
    if sampledMajorityColor ∉ {Red, Blue}: // The network is still initializing its preferences
      confidence = 0
      continue

    majorityCount = sampledPreferenceCounts[sampledMajorityColor]
    if majorityCount < α:
      confidence = 0 // No one got an alpha majority
      continue

    preferenceStrength[sampledMajorityColor]++
    minorityColor = otherColor(majorityColor)
    if preferenceStrength[majorityColor] > preferenceStrength[minorityColor]:
      currentColor = majorityColor // Update the color we report to other peers

    if majorityColor != lastMajorityColor:
      confidence = 0
    lastMajorityColor = majorityColor
    confidence++
  currentColor = lastMajorityColor

We can see the two mechanisms at play.

1. The node determines it's currentColor by adopting whichever color has had the most alphaMajority samples.
2. The node determines that the network will finalize lastMajorityColor once it sees β consecutive samples where lastMajorityColor had an alphaMajority.

Snowball Simulation

With this specification, we can run simulations on how many rounds of sampling it takes for the network to finalize.

Parameters:

N = 250
K = 21
β = 30

The network is initialized with 125 Red and 125 Blue nodes. Nodes perform sampling in lockstep.

For small values of α, the majority of the sampling time is done to trigger the finalization mechanism. The finalization detector requires at least β = 30 rounds until termination. However, as α increases, the number of rounds increases significantly higher than β. This is because the color selection mechanism becomes less aggressive as α increases towards K.

This is a major reason why α = 15 and K = 20 are the current Mainnet consensus parameters.

When nodes are randomly selected to perform the sampling, versus in lockstep, the average rounds until termination decreases.

However, the growth pattern is similar as α increases.

Conflicting Optimization

As the above graph shows, increasing α can significantly increase the required rounds until termination. This is because having a high α can take an extended amount of time for nodes to adopt the majority color. However, increasing α is often desirable to increase the safety of the decision.

Increasing α trades off performance for safety.

Suggested change

Snowball's color selection and finalization detection mechanisms should be better separated. Specifically, the usage of α in the Snowball specification should be modified to have two values: alphaPreference and alphaConfidence.

It is required that alphaPreference <= alphaConfidence.

The updated Snowball specification would be:

def onQuery(peer, peerColor):
  respond(peer, currentColor) // Send our current color to the peer, which might be ⊥
  if currentColor = ⊥:
    currentColor = peerColor // If we do not currently have a color, adopt the peer's color

def snowball():
  confidence = 0
  preferenceStrength = {Red:0, Blue:0}
  while confidence < β:
    if currentColor = ⊥:
      continue // Wait until we hear of a color from a peer

    sampledNodes = sample(N, k) // Sample k nodes from the network
    sampledPreferences = [query(node, currentColor) ∀ node ∈ sampledNodes]
    sampledPreferenceCounts = count(sampledPreferences) // Map each color to the number of times it was sampled
    sampledMajorityColor = argmax(sampledPreferenceCounts)
    if sampledMajorityColor ∉ {Red, Blue}: // The network is still initializing its preferences
      confidence = 0
      continue

    majorityCount = sampledPreferenceCounts[sampledMajorityColor]
-    if majorityCount < α:
+    if majorityCount < alphaPreference:
      confidence = 0 // No one got an alpha majority
      continue

    preferenceStrength[sampledMajorityColor]++
    minorityColor = otherColor(majorityColor)
    if preferenceStrength[majorityColor] > preferenceStrength[minorityColor]:
      currentColor = majorityColor // Update the color we report to other peers

+    if majorityCount < alphaConfidence:
+      confidence = 0 // No one got an alphaConfidence majority
+      continue
+
    if majorityColor != lastMajorityColor:
      confidence = 0
    lastMajorityColor = majorityColor
    confidence++
  currentColor = lastMajorityColor

Updated Snowball Simulation

Parameters:

N               = 250
K               = 21
β               = 30
AlphaPreference = 11

The network is initialized with 125 Red and 125 Blue nodes.

Nodes performing sampling in lockstep:

Sampling which node to perform the sampling:

These simulations show that keeping alphaPreference constant while increasing alphaConfidence increases the rounds until termination significantly less than increasing α in the current protocol specification.

Safety Impact

While modifying the color selection does impact the safety analysis, the impact is not expected to be significant.

As a simple argument for why safety shouldn't be drastically impacted, consider the case that one virtuous node has accepted Red. If byzantine nodes switching their color to Blue caused polls to see more Blue than Red, safety will eventually be violated. This is because eventually nodes will switch their preferences, except for the one node that has accepted Red, to Blue. Once enough nodes have updated their preferences to Blue, another virtuous node may accept Blue. Notice that this is independent of α. α in this situation only impacts the speed at which such a failure would occur.

The actual impact on the safety analysis is due to the variance in sampling. Larger α values protect more against unlikely samples of a disproportionate number of byzantine nodes. Before modifying the default consensus parameters, this should be included in the formal safety analysis.

Additionally, this change can unblock using a larger alphaConfidence than currently configured without significantly degrading performance.

Why this should be merged

• This change meaningfully improves the performance of the core consensus mechanism.
• This change does not actually change the behavior of the node. The node will only behave differently if alphaPreference is set to a different value than alphaConfidence. Changing the default value of these parameters is left to a future proposal.

How this was tested

• Performance simulations
• CI

[marun]

Where can I find documentation about avalanchego consensus? I'm curious about the different implementations (binary, nnary, flat, etc) and what they are used for.

[StephenButtolph]

Where can I find documentation about avalanchego consensus? I'm curious about the different implementations (binary, nnary, flat, etc) and what they are used for.

In general - the only thing that is used from the snowball package is snowball.NewTree. Flat (and correspondingly all the nnary implementations) could be moved into test files.

As for binary - the spec has only been slightly modified since the original paper: https://assets.website-files.com/5d80307810123f5ffbb34d6e/6009805681b416f34dcae012_Avalanche%20Consensus%20Whitepaper.pdf

[abi87]

@StephenButtolph can you elaborate on the difference between lockstep vs sampled simulations? They seems to represent a synchronous vs asynchronous enviroment but not sure.

[StephenButtolph]

can you elaborate on the difference between lockstep vs sampled simulations?

When run in lockstep:

1. every (virtuous) node samples k peers and stores their color
2. after the sampling, all of the samples are then applied (where nodes update their colors).

This means that in any given round, the nodes observe the same colors of virtuous nodes. This was meant to behave as if all the nodes are very equal and there is some (constant) network delay.

When running by sampling nodes:

1. a random (non-finalized + virtuous) node is selected (uniformly randomly)
2. the selected node samples k peers and applies those votes (may update its color)

This is why the last graph Rounds Until Termination by alphaConfidence (Sampled Node) grows more with a higher alphaConfidence than Rounds Until Termination by alphaConfidence (Lockstep). Specifically, the network is waiting for the last few virtuous nodes to be sampled in the first step so that their color updates. This kind of emulates where some nodes in the network are "slower" than other nodes.

[abi87]

nits and possibly a type in a UT. Still looking at this.

[gyuho]

lgtm

just nits to make sure I understand the test changes :)

addressed

[abi87]

lgtm

[gyuho]

Lgtm 🫡

[hsk81]

In my own simulations, the number of rounds until finalization used to go higher when the underlying stake distribution was weird with no expected mean. See "Law of Large Numbers":

《The average of the results obtained from a large number of trials may fail to converge in some cases. For instance, the average of n results taken from the Cauchy distribution or some Pareto distributions (α<1) will not converge as n becomes larger; the reason is heavy tails.[4] 》

What distribution and parametrization did you assume during the simulations? See my repository if you're interested:

https://github.com/hsk81/avalanche-sim