Avalanche

Info

To keep the content on this page factually correct and up-to-date, contributions are welcome.

Polkadot and Avalanche both have architectures that enable application-specific blockchains to connect to a primary network for publicly available state verification. In Polkadot, the primary network is the relay chain, while Avalanche uses three main chains—P-chain, X-chain, and C-chain—collectively known as the "Primary Chain." Similar to Polkadot's parachains and rollups, Avalanche uses subnets. Both networks employ a PoS mechanism where validators stake tokens to secure the network.

Architecture

Avalanche's architecture separates responsibilities into three chains, enabling distinct roles for validators, transactions, and smart contract execution. The X-chain uses a DAG (Directed Acyclic Graph) structure, which is non-linear, while Polkadot uses a linear chain structure similar to Bitcoin and Ethereum.

Image source: Avalanche docs.

Smart contracts in Polkadot are implemented on parachains. Avalanche's Primary Network is divided into three blockchains:

P-chain (Platform)

• Maintains the validator set and secures the network.
• Supports staking operations and Avalanche L1s.
• Uses Delegated Proof-of-Stake (DPoS), allowing token holders to delegate their stake to validators.

X-chain (Exchange)

• Handles the transaction layer using a UTXO model (similar to Bitcoin).
• Implements a DAG structure for fast transaction processing.
• Does not support smart contract execution.

C-chain (Contracts)

• Supports EVM-compatible smart contracts.
• Runs the Coreth VM, a fork of go-ethereum with Avalanche-specific networking and consensus.
• Focuses on high activity for smart contract execution.

Subnets

Avalanche defines a subnet as a dynamic set of validators achieving consensus on a set of blockchains. In Polkadot's terminology, subnets are comparable to parachains (rollups) utilizing available compute on the Polkadot relay chain. Subnets allow validators to validate specific runtimes, offering flexibility in transaction fee models, tokenomics, and custom rules. Validators can validate one or more subnets, forming subsets of the overall validator set.

Virtual Machines

Avalanche uses virtual machines (VMs) as blueprints for defining blockchain behavior, including state transitions, transaction rules, and API interfaces. Developers can use the same VM to create multiple independent blockchains with identical rules.

Avalanche allows developers to build custom VMs for advanced use cases. These VMs can be implemented in any programming language and communicate with Avalanche using a language-agnostic RPC protocol. However, developers can also use prebuilt runtimes, such as Subnet-EVM for quick deployment of Solidity-based blockchains.

In contrast, Polkadot developers use the Polkadot SDK to build customized blockchain runtimes. Polkadot SDK compiles runtimes to WASM, which the relay chain uses to verify state changes from parachains or rollups. Polkadot does not have a native smart contract layer; instead, EVM and WASM smart contract capabilities are implemented on parachains.

This distinction highlights Avalanche's focus on VM-based blockchain customization and Polkadot's emphasis on shared security and modular runtime development.

Consensus

Image source: gyuho.dev.

Avalanche Consensus combines features of classical and Nakamoto consensus to achieve throughput, finality, and energy efficiency. It uses repeated sub-sampled voting to ensure scalability and robustness.

Polkadot employs deterministic finality and shared security through its relay chain. Polkadot uses a synchronous hybrid model with BABE for block production and GRANDPA for deterministic finality. Polkadot validators agree on entire chains rather than individual blocks, ensuring robust finality. These two mechanisms ensure the network maintains its robustness and liveness.

Snowball Algorithm

The Snowball algorithm is a core component of Avalanche Consensus. It ensures consensus through iterative sampling and preference updates:

• Parameters:
• k: Sample size (e.g., 20 validators).
• α: Quorum size (e.g., 14 validators).
• β: Decision threshold (e.g., 20 consecutive rounds).
• Process:
• Nodes query k validators and adopt the majority preference if it meets the quorum size α.
• This process repeats until the same preference is confirmed for β consecutive rounds.

The algorithm ensures scalability, as the number of consensus messages remains constant even as the network grows.

DAG (Directed Acyclic Graph)

Avalanche uses a DAG structure for partial ordering of transactions. Each transaction is represented as a vertex, with edges pointing to parent transactions. This structure allows for high throughput and efficient conflict resolution using the Snowball algorithm.

Staking Mechanics

Avalanche uses a Delegated Proof-of-Stake (DPoS) mechanism without slashing. Key staking details include:

• Validator Requirements: A minimum of 2,500 AVAX is required to become a validator.
• Delegator Requirements: A minimum of 25 AVAX is required to delegate stake.
• Staking Period: Validators and delegators can stake for a minimum of two weeks and a maximum of one year. After this period, re-staking is required.
• Rewards: Validators earn rewards based on uptime and correctness. Delegators share rewards with their chosen validators.

In Polkadot, staking requirements are dynamic and depend on network conditions. The minimum stake for validators and nominators varies based on the total staked amount in the network. Polkadot also employs slashing to penalize misbehavior. For more details, refer to the staking page.

Message Passing

Avalanche has introduced Avalanche Interchain Messaging (ICM), a native protocol for secure and trustless cross-chain communication. Key features include:

• Interoperability: Enables subnets to exchange messages using cryptographic proofs.
• Limitations: ICM is restricted to subnets within the Avalanche ecosystem and does not extend to external blockchains.

Polkadot, by contrast, uses XCM and XCMP for native, trustless cross-chain communication. XCM supports composability across parachains and extends beyond Polkadot's ecosystem, enabling broader interoperability.

Governance

According to its whitepaper, Avalanche plans to have an on-chain governance mechanism. It currently does not have an on-chain or off-chain system in production. Its governance system will limited to updating only a few key protocol parameters which include:

• Staking amount: This value defines the minimal stake required to be placed as bond before participating in the system.
• Minimum staking time for a node: The minimal amount of time required for a node to stake into the system.
• Maximum staking time for a node: The maximal amount of time a node can stake.
• Minting rate: Reward rate function, also referred to as minting rate, determines the reward a participant can claim as a function of their staking amount given some number of x publicly disclosed nodes under its ownership, over a period of t consecutive minimal staking time timeframes, such that t*minimal staking time* ≤ maximum staking time.
• Transaction fee amount: The fee structure, which is a set of governable fees parameters that specify costs to various transactions.

Limiting the governance functionality is a design choice to increase predictability and safety.

Polkadot's governance (OpenGov) mechanism has been in production from the very beginning and was used to slowly release functionality and decentralize the initial network. Polkadot governance can set parameters for various network parameters, but it can also upgrade itself using governance by allowing stakeholders to vote on referenda.

This notion of runtime upgrades via protocol makes Polkadot a meta-protocol.

Upgrades

Avalanche upgrades are managed by Ava Labs and require coordination among validators for implementation. Each validator in a subnet must apply the same upgrade, making the process manual and collaborative.

Polkadot employs forkless runtime upgrades through on-chain governance. Parachain upgrades are automated and do not require validator coordination, streamlining the process.

Conclusion

Avalanche focuses on providing a customizable environment for blockchain developers, enabling the creation of independent blockchains via subnets. However, subnets do not share the security of Avalanche's primary network. Polkadot emphasizes shared security and interoperability through its relay chain, parachains, and beyond.

Polkadot's features, such as XCM for trustless messaging and forkless upgrades, are already in production, while Avalanche is still developing similar capabilities. Polkadot's governance mechanism, OpenGov, also enables for decentralized decision making when it comes to the direction and technical aspects of the Polkadot relay chain.

References

1. The Avalanche Platform Whitepaper
2. The Avalanche Consensus Whitepaper
3. The AVAX Token Dynamics Paper
4. Nakomoto vs Snow consensus
5. Avalanche Consensus
6. [Avalanche L1s]https://build.avax.network/docs/quick-start/avalanche-l1s)