In-depth Analysis of Avalanche Architecture

Author: Dan Smith

Key Points

• Avalanche Platform: Avalanche aims to build an interoperable, flexible, and high-performance blockchain.

• Durango Upgrade (completed on March 6): Introduced cross-chain communication capabilities for all EVM-based subnets, marking the arrival of a new era of interoperability for the Avalanche network.

• Performance-focused upgrades: Upgrades including HyperSDK, Vryx, and Firewood are planned for implementation in the second half of this year, expected to promote widespread adoption of subnets alongside ACP-13.

• Avalanche Infrastructure: Provides the infrastructure to create highly optimized blockchains connected through native interoperability solutions. Currently, Avalanche is known for its C-chain (Contract Chain), a general-purpose EVM-compatible L1 with 37 DeFi applications and a total locked value exceeding $100 million, including popular applications like Trader Joe, Aave, and GMX. However, Avalanche's construction is based on the idea that a single chain optimized for globally shared state cannot scale to meet the demands of the modern world. In the future, there will be many high-performance chains that require seamless interaction.

Emin Gün Sirer, founder and CEO of Ava Labs, recently released the team's development roadmap, emphasizing the importance of creating a platform to launch heterogeneous blockchains with asynchronous composability. The roadmap focuses on three core areas: expanding the number of subnets, increasing network throughput, and strengthening the robustness of the consensus mechanism.

Avalanche aims to provide developers with a framework to customize blockchains according to specific application scenarios. The blockchain systems built under the Avalanche technical framework rely on Subnets (a group of validator nodes) for validation work. It is important to clarify that a Subnet itself is not a blockchain but a cluster of validators responsible for designing, managing, and adjusting the operational mechanisms and economic models of the blockchains it validates. A Subnet has the capability to validate from one to multiple different blockchains, but each blockchain can only be validated by a single Subnet. In this way, the numerous blockchains validated by Subnets collectively construct the vast system architecture of the Avalanche network.

The Mainnet is the First Subnet

Guided by the currently popular modular architecture concept, the creators of the Avalanche network designed an innovative structure: the main network. This network optimizes resource allocation by dividing its key functions into several independent blockchains—C-chain, X-chain, and P-chain—these three serve as the initial blockchains in the Avalanche network, validated collectively by the first Subnet—the main network.

All three chains utilize the Snowman consensus mechanism, originally developed by the Ava Labs team. This mechanism ensures high security, rapid confirmation, and scalability through repeated sampling. Unlike other consensus mechanisms that require comprehensive communication between nodes, the Snowman consensus can complete validation without needing to communicate with each node individually, thus building a powerful engine that can quickly reach consensus even in the presence of a large number of validators.

Similar to other popular L1s in the market, the C-chain provides an open platform for developing Ethereum Virtual Machine (EVM)-based smart contract applications. Over the past cycle, the C-chain has witnessed active exploration in the DeFi space, with a total TVL peaking at $21 billion, primarily driven by lending platforms Aave and Benqi, as well as decentralized exchanges Trader Joe and Curve. The C-chain has also achieved several key integrations to facilitate DeFi activities, including the minting and redemption of Tether (USDT) and Circle (USDC) on the C-chain, with the current total value of USDT and USDC on-chain reaching $1.2 billion. Additionally, for DeFi applications like lending markets, support from price oracle providers is crucial, with Chainlink being the largest provider, holding a 53% market share and currently supporting 116 applications on the C-chain.

In December 2023, the C-chain maintained an average transaction rate of 40 transactions per second (TPS) throughout the month, peaking at 106 TPS in a single minute. Although this surge in transaction volume was primarily due to mempool transactions (often considered lower-quality lightweight transactions), it still demonstrates the superior performance of the Avalanche tech stack compared to other EVM chains. However, compared to high-throughput chains like Solana, the C-chain's transaction processing capacity is relatively low, with the latter's average transaction speed typically being 100 times that of the C-chain. To enhance network performance, the platform plans to support high-throughput chains built using HyperSDK.

The X-chain has a singular function, solely responsible for creating and transferring the native assets of the Avalanche network. In contrast, the P-chain plays a more critical role in the Avalanche tech ecosystem, serving as the subnet registry, recording the active status of validators and their staking weights, ensuring smooth communication across subnets.

Currently, validators participating in any subnet validation must also bear the validation responsibilities for the three chains of the main network (C-chain, X-chain, P-chain). To date, the main network has gathered 1,821 validator nodes, which have collectively staked 259 million AVAX tokens, accounting for 59% of the total staked amount. To become a validator in the main network, nodes must stake at least 2,000 AVAX, while token holders can participate in network maintenance by staking a minimum of 25 AVAX. Of the total staked amount, approximately 82% comes from the nodes themselves, while the remaining 18% comes from individual delegators. Compared to other proof-of-stake (PoS) chains, Avalanche's liquid staking feature has not yet been widely adopted. As the two largest liquid staking service providers on Avalanche, Benqi and GoGoPool currently account for only 3% of the total staked amount. The Ava Labs team introduced the ACP-13 proposal to the Avalanche community, aiming to reduce the cost and complexity of launching subnets. This proposal introduces a new type of staker identity—Subnet-only validators (SOV), which do not need to synchronize and validate the entire mainnet but focus solely on validating the P-chain. This is because cross-subnet communication relies only on the validation mechanism of the P-chain. This change is expected to significantly reduce the initial fixed costs of deploying subnets, optimize the resource allocation of validator hardware, and lower regulatory risks for institutional clients while maintaining interoperability between subnets.

Under the current rules, all subnet validators must participate in the validation of the three chains of the main network, requiring a minimum stake of 2,000 AVAX, which, at today's market price for AVAX, translates to approximately $88,000 in initial capital for each validator. The ACP-13 proposal aims to reduce this cost by allowing SOVs to stake only 500 AVAX, thus reducing costs by 75%, given that SOVs do not participate in the main network validation, this portion of the stake will not generate network rewards. Nevertheless, even with the reduced costs proposed, launching a subnet validator would still require about $22,000, and the price sensitivity effect on potential validators remains to be assessed.

By exempting the validation requirements of the C-chain and X-chain, the proposal allows subnet validators to allocate their hardware resources more efficiently, focusing on maintaining their own chains rather than spreading resources to support the main network. Although the current hardware requirements of the main network are not high, there are still voices within the community calling for increased hardware configurations to enhance overall performance. This dual demand for resources raises questions about whether Avalanche's technical architecture is fully committed to becoming a high-performance platform.

More importantly, the ACP-13 proposal also addresses the regulatory risk issues faced by validators of permissionless smart contract platforms (like the C-chain). For instance, the U.S. government has imposed OFAC sanctions on certain Ethereum addresses, forcing regulated validators, developers, and relayers to exclude specific transactions to remain compliant. By exempting subnet validators from participating in the main network consensus, ACP-13 effectively reduces this regulatory risk, providing more opportunities for risk-averse entities in the U.S. to establish blockchains.

Subnet Architecture

Avalanche is committed to becoming the preferred network for developers to build customized blockchains, and achieving this goal hinges on providing an infrastructure that is interoperable, flexible, and efficient.

Avalanche Warp Messaging

In a blockchain world where multiple chains coexist, interoperability is particularly crucial. Avalanche Warp Messaging (AWM), as a core technology provided by Avalanche, enables communication between different subnets. This technology allows clusters of validators from two different chains to communicate directly, eliminating the need to transfer data or assets through third-party bridges, significantly simplifying interactions between the various blockchains within the Avalanche network. AWM is designed with great flexibility, supporting message passing between any chains registered on the P-chain, whether they are permissionless base chains like the C-chain or fully permissioned application-specific chains, or any form in between.

Message passing between subnets is accomplished through relayers, and these messages are verified using BLS multi-signature technology. The receiving subnet confirms the validity of these signatures by querying the P-chain—a system that serves as a registry for subnet validators. For example, when Subnet A sends a message to Subnet B, once a user action activates AWM, the validators of Subnet A collectively sign a message and relay it to Subnet B. Subsequently, the validators of Subnet B will verify the message, determining whether it has been signed by a certain proportion of staking weight from Subnet A. It is worth emphasizing that this entire process of message transmission, reception, and verification does not rely on any external entities.

Since its launch in December 2022, Avalanche Warp Messaging (AWM) has been active, but to achieve compatibility with the Ethereum Virtual Machine (EVM), a series of important engineering optimizations need to be completed. The introduction of ACP-30 establishes a unified implementation standard for cross-subnet message passing on the C-chain and all EVM-based blockchains within the Avalanche network.

This community proposal took effect on March 6, 2024, with the Durango upgrade, enabling users to easily transfer assets between different chains using the Teleporter tool. Teleporter, built on AWM, provides a simple interface for sending and receiving cross-chain messages, thus supporting the transfer of ERC-20 tokens between blockchains in the Avalanche network. Teleporter is designed to provide a smooth and reliable user experience, including features to avoid transaction duplication, implement relay whitelists, and set optional transaction fees. With the promotion of the ACP-30 standard, it will soon be applied to HyperSDK, further expanding the number of chains connected by Teleporter and enhancing the interoperability of the Avalanche network.

Subnet VMs and HyperSDK

A virtual machine (VM) is a software that defines the specific operational behavior of a blockchain by specifying key elements such as transaction formats, state access permissions, and gas mechanisms. Different VM design philosophies and implementations have profound impacts on the performance and functionality of applications developed on them. For example, Ethereum's virtual machine (EVM) is known for its large developer community and mature development tools, while Solana's virtual machine (SVM) focuses on optimizing performance through its multi-threaded runtime and parallel execution capabilities, as well as improved transaction fee mechanisms.

The Avalanche network allows blockchains built on it to choose to run pre-built virtual machines, such as the Subnet-EVM designed for compatibility with Subnets, or custom virtual machines selected by developers. Given that building an entirely new virtual machine is a highly challenging task, the vast majority of chains on the Avalanche network currently choose to run the Subnet-EVM. The development of HyperSDK aims to lower the barrier for creating custom virtual machines, enabling developers to personalize their VMs without starting from scratch.

HyperSDK provides a framework for building custom virtual machines (HyperVMs) that can be directly integrated into the Avalanche network. This framework comes equipped with powerful default settings, allowing developers to focus on core application functionality without having to build the VM from the ground up. Theoretically, HyperSDK can reduce the time required to develop a virtual machine from months to just days, significantly accelerating developers' market responsiveness.

The development of HyperSDK not only marks a new height in Avalanche's performance enhancement but also introduces an advanced transaction processing mechanism called Vryx. The design philosophy of Vryx is derived from several widely recognized research papers, particularly the Narwhal Tusk paper published by Diem (formerly the Facebook team), which has had a profound impact on modern blockchains like Aptos and Sui. The core of Vryx lies in separating the various steps in the transaction processing process, a strategy that allows validators to simultaneously build and replicate blocks. In short, it achieves horizontal scalability of throughput by shortening the total time taken to build, replicate, and validate blocks. This means that Vryx will significantly enhance the transaction processing speed of the Avalanche network, pushing its transactions per second (TPS) to new heights. Although Vryx has not yet been officially launched, Ava Labs plans to integrate it into HyperSDK by the end of this year. Upcoming performance benchmarks from Ava Labs are expected to showcase Vryx's efficient performance, with TPS anticipated to exceed 100,000.

Database Solutions

In the pursuit of performance optimization in blockchain design, performance improvements often come with higher hardware requirements for validators. The hardware demands of future subnets will be influenced by the type of virtual machine chosen to run, and the main network community will face a decision: whether this trade-off is appropriate for the C-chain. Generally, increasing hardware requirements is seen as raising the cost of becoming a validator, which could potentially reduce the prevalence of node operations, a critical factor in balancing performance and decentralization. While it may seem reasonable in theory, this is not always the case in practice; for example, despite higher hardware requirements, the Solana network maintains 1,606 staked nodes, surpassing the scale of the Avalanche main network. Additionally, factors such as the geographical distribution of nodes and servers are also important elements in the decentralization discussion.

To take further steps in performance enhancement, Ava Labs is working on a proprietary database solution called Firewood. Firewood was created to address the core obstacle encountered in blockchain scalability: state management. The so-called blockchain state refers to a real-time snapshot of relevant data stored in the system, which expands with increased usage. Consequently, validators need to access the current state quickly to execute transaction processing efficiently, a demand that becomes increasingly challenging as the state continues to grow.

Firewood aims to improve the MerkleDB database previously developed by the team. It employs an innovative mechanism to efficiently store and read blockchain states by reducing the overhead required to modify existing states. The introduction of this mechanism is expected to create a more powerful database system capable of providing rapid state access, thereby removing a key barrier to enhancing transaction processing capacity. Ava Labs expects to release performance benchmark results for Firewood soon to demonstrate its superior performance.

Comparison with Other Technical Solutions

Avalanche is not the only technology stack building blockchain launch infrastructure. Currently, the most notable ways to build one's own chain include application chains (appchains) in the Cosmos ecosystem and rollups on Ethereum. Each framework has a different set of trade-offs, attracting different groups of developers.

Cosmos Application Chains

The ultimate goals of the Avalanche network and the Cosmos ecosystem are nearly identical: to connect asynchronous independent chains through trust-minimized messaging standards. Both platforms allow developers to build blockchains that manage their own security, which requires launching a high-quality set of validators. Even with the implementation of ACP-13, the 500 AVAX deposit may still pose an entry barrier for becoming a subnet validator. Therefore, those validators who do pay the deposit may be more inclined to validate multiple chains to earn more rewards and offset their initial deposit. In today's Cosmos ecosystem, there is no mechanism similar to the 500 AVAX deposit; however, we see significant overlap among validator sets for appchains. For example, Chorus One, Allnodes, Polkachu, and Informal Systems are validators for Celestia, Cosmos Hub, Osmosis, and dYdX.

This comparison highlights the differences in design and strategy among different blockchain technology stacks and how they attract and retain validator and developer communities. Avalanche attempts to lower the entry barrier through the ACP-13 proposal to promote the creation and maintenance of more subnets and blockchains, while the Cosmos ecosystem attracts validators to participate without requiring significant upfront deposits, showcasing different ecological dynamics and developer appeal. These differences reflect each platform's varying strategies in balancing security, decentralization, and usability.

Currently, the P-chain in the Avalanche network serves as the central registry for subnets, where validator information is stored. This architecture means that while subnets are technically independent, they rely on the P-chain to some extent and cannot operate entirely autonomously. For example, the distribution of staking rewards within a subnet is determined by the P-chain, limiting the subnet's freedom to experiment with new reward distribution mechanisms. In contrast, chains in the Cosmos ecosystem are more sovereign, without similar centralized hub restrictions, allowing for more freedom in adjusting and designing their tech stacks. One reform proposal currently being discussed by Ava Labs is to allow validator sets controlled by subnets to manage themselves and report any changes to the P-chain, granting subnets more autonomy while the P-chain serves merely as a bridge for cross-subnet communication. This proposal is still in discussion, and its implementation prospects remain uncertain.

The Cosmos ecosystem has conducted extensive technical experiments in recent years, with successful cases like Terra and dYdX demonstrating its tech stack's ability to handle general L1 traffic and meet specific application needs. Compared to Avalanche's 34 subnets and 36 active chains, Cosmos currently has 88 active chains, and its large developer community brings more innovation to the tech stack, such as modules developed by external teams for use by other chains.

While Avalanche's AWM and Cosmos's IBC protocol have similarities in cross-chain communication, there are fundamental differences in their message verification mechanisms. AWM utilizes the P-chain as a universal registry for signatures from active validators of all subnets, while IBC does not have such a unified verification point; Cosmos validators need to synchronize information between chains and locally record the validator sets of other chains. This means that channels between Cosmos chains need to be updated regularly to ensure the accuracy of the effective validator set, and each time a new channel is established, a connection setup is required.

In both AWM and IBC technologies, inter-chain message passing relies on relayers. However, in the Cosmos ecosystem, relayer work does not have direct economic incentives, often leading service providers to take on this role out of business necessity. Although the proposal to add fees for IBC transfers has not gained widespread support, the Cosmos ecosystem has established a large relayer network, with key players like Crossnest, Informal Systems, and Notional. As the subnet ecosystem expands, building a similar relayer network will take time; however, Teleporter provides incentives for relayers by introducing optional fees, theoretically improving the quality of relayer services and accelerating asset transfer speeds. Although Teleporter has only been live for less than a day, we will continue to monitor the development of the relayer ecosystem.

Avalanche's consensus mechanism employs subsampling technology, successfully expanding the active validator set to over 1,800, which is significantly better than Cosmos chains, where the number of validators typically ranges from 80 to 180. This expansion allows permissionless blockchains to thrive within the Avalanche network; however, both networks support developers in creating blockchains with permissioned validator sets, such as Cosmos's Noble and Avalanche's Evergreen subnets. With the introduction of HyperSDK, Vryx, and Firewood, Avalanche is expected to provide more efficient technical support. However, specific performance improvements will only be determined once relevant benchmark tests are released.

Rollups

Rollups provide another path for launching new blockchains within the Avalanche network. They work by extending the execution capabilities of another blockchain and returning transaction data to the original blockchain. Rollup deployment options are diverse, involving state verification technologies such as fraud proofs or zero-knowledge proofs, as well as frameworks like OP Stack or Arbitrum Orbit, along with settlement options on Ethereum or other rollups, and data availability solutions like Ethereum or Celestia. The design of rollups has significant implications for their security and stability; therefore, when summarizing this construction method, we aim to compare it with the concept of launching a blockchain on the Avalanche network.

One notable distinction lies in the source of security. Blockchains within the Avalanche network rely on themselves to ensure security, while rollups inherit security from their underlying layer. Rollups create a mechanism that extends the execution capabilities of the underlying blockchain, which provides consensus, settlement, and data availability support for the rollup. In contrast, subnets are essentially Layer 1 blockchains that independently provide their own consensus, settlement, and data availability, with their own staking tokens. Although most rollup solutions focus on EVM compatibility, their performance may not match that of new virtual machines, but it is feasible to build rollups based on new or custom virtual machines (like the SVM fork used by Eclipse). Avalanche subnets fundamentally maintain neutrality towards virtual machines, meaning subnets can run blockchains based on any virtual machine. While most subnets currently in production support EVM, the introduction of MoveVM, WASM-based virtual machines, and other custom virtual machines developed through HyperSDK is steadily progressing.

In most current rollup architectures, transaction execution relies on a single sequencer, which is responsible for publicly posting transaction data to the data availability layer, ensuring public visibility. In this architecture, the sequencer becomes a potential point of centralization failure; if a system failure occurs, it may prevent users from executing layer two transactions. Although such failures typically do not directly lead to user asset loss, the specific design of the rollup determines the level of security assurance. On the other hand, the Avalanche network ensures that there is no single point of failure through its fault isolation mechanism; even if the P-chain fails, it will only affect cross-chain communication, while activities within each subnet will continue normally. This contrasts sharply with the performance degradation that occurs when rollups face issues at the settlement or data availability layers.

Avalanche's security mechanism is based on subnets responsible for execution, data availability, and consensus, where validators assume all functional roles of the chain. Like most proof-of-stake chains, validators are economically incentivized to participate in maintaining network security through inflation rewards or transaction fees. In contrast, rollups need to publish transaction data to the data availability layer so that the execution and settlement layers can confirm the availability of transaction data. If data is not made public, it may lead to the rollup state being unable to update, thus freezing user assets. Theoretically, users should have the ability to download block data and independently verify the rollup's state transitions to ensure security.

Within the Avalanche network, since subnets are responsible for their own security, the cost of running a blockchain is essentially fixed, with the only cost being the AVAX staking fee reduced by the ACP-13 plan. In contrast, the operational costs of rollups primarily consist of the fees for publishing data to the data availability layer, which are variable costs that change with usage, typically passed on to users as transaction fees. The launch of Celestia has significantly reduced these costs by 99%, alleviating the economic burden of operating rollups.

A significant advantage of subnets over rollups is the Avalanche Warp Messaging (AWM) technology they employ, which provides inherent interoperability for the Avalanche network. This interoperability is currently a clear deficiency in rollups, leading to the fragmentation of capital flows, user bases, and market attention within the isolated networks formed by rollups. Although various third-party bridging solutions currently exist, each is based on its own trust mechanism.

Currently, attempts are underway to build more robust bridging solutions using zk proofs; if two rollups use the same zk prover, they can asynchronously exchange messages without additional trust mechanisms, but this approach also has limitations. Multiple teams are developing their own zk provers, each hoping their solution will become the standard. This may lead to further fragmentation of liquidity between different rollup clusters based on the same technology, rather than being limited to a single rollup, and communication outside each cluster will still rely on third-party bridging. In stark contrast, Avalanche enables powerful asynchronous communication across the entire network by adopting a unified messaging protocol, without relying on any third-party bridging services.

Conclusion

The Avalanche network is steadily becoming the best platform for building high-performance blockchains that can seamlessly interconnect. Their biggest challenge will be attracting builders into the Avalanche ecosystem rather than choosing to compete in rival ecosystems. A strong focus on performance and scalable blockchains may become Avalanche's competitive advantage, and we anticipate that the launches of HyperSDK, Vryx, and Firewood in the second half of the year will serve as major catalysts for the widespread adoption of subnets. Furthermore, discussions around ACP-13 are strictly focused on lowering entry barriers and expanding subnet adoption rates. The goal of ACP-13 is to enable more developers and projects to join the Avalanche network more easily, promoting the creation and development of subnets by lowering costs and simplifying processes. Such measures are expected to increase the diversity and functionality of the Avalanche network, thereby attracting more builders to participate in its ecosystem.