In-depth analysis of Avalanche architecture

Key takeaways

• Avalanche Platform: Avalanche aims to build an interoperable, flexible, and high-performance blockchain.
• Durango Upgrade (completed on March 6th): Introduces cross-chain communication capabilities for all EVM-based subnets, marking the arrival of a new era of interoperability in the Avalanche network.
• Performance-first upgrades: Upgrades such as HyperSDK, Vryx, and Firewood are scheduled to be implemented in the second half of this year, expected to promote widespread adoption of subnets in conjunction with ACP-13.
• Infrastructure of Avalanche: Provides the foundation for creating highly optimized blockchains connected through native interoperability solutions. Currently, Avalanche is renowned for its C-Chain (Contract Chain), which is a versatile EVM-compatible L1 with 37 DeFi applications and a total locked value exceeding $100 million, including popular apps like Trader Joe, Aave, and GMX. However, Avalanche’s development is based on the idea that a single chain optimized for global shared states cannot scale to meet the needs of the modern world. In the future, there will be many high-performance chains that require seamless interaction.

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

Avalanche aims to provide developers with a framework to customize blockchains according to specific application scenarios.

In the blockchain system built on the Avalanche technical framework, validation tasks rely on Subnets, which consist of a group of validator nodes. It’s important to clarify that Subnet itself is not a blockchain but rather a cluster of validators responsible for designing, managing, and adjusting the operational mechanisms and economic models of the blockchains they validate. 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 multitude of blockchains validated through Subnets collectively construct the extensive system architecture of the Avalanche network.

The Mainnet Is The First Subnet

Under the guidance of the popular modular architecture concept, the creators of the Avalanche network have designed an innovative structure: the Mainnet. This network optimizes resource allocation by dividing its key functionalities into several independent blockchains — C-Chain, X-Chain, and P-Chain, all initially verified by the first Subnet — the Mainnet.

All three chains adopt the Snowman consensus mechanism pioneered by the Ava Labs team. This mechanism ensures high security, fast confirmation, and scalability by repeatedly sampling. Unlike other consensus mechanisms that require comprehensive communication between nodes, Snowman consensus can achieve verification without the need to communicate individually with each node, thereby creating a powerful engine for quickly reaching consensus even in the presence of a large number of validators.

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

In December 2023, 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 the surge in transaction volume is mainly attributed to lightweight transactions (typically considered lower quality), it still demonstrates the superior performance of the Avalanche technology stack compared to other EVM chains. However, compared to high-throughput chains like Solana, C-Chain’s transaction processing capacity is relatively lower, with the latter’s average transaction speed typically being 100 times that of C-Chain. To enhance network performance, the platform plans to support high-throughput chains built using HyperSDK.

X-Chain has a simple function, solely responsible for creating and transferring native assets of the Avalanche network. In contrast, P-Chain plays a more critical role in the Avalanche technical ecosystem, serving as the registry for subnets, recording the active status of validators and their staking weights to ensure smooth communication across subnets.

Currently, validators participating in the validation work of any subnet must also undertake the responsibility of validating the three chains (C-Chain, X-Chain, P-Chain) in the Mainnet. To date, the Mainnet has attracted 1,821 validator nodes, collectively staking 259 million AVAX tokens, accounting for 59% of the total stake. To become a validator in the Mainnet, a node must stake at least 2,000 AVAX, while token holders can participate in network maintenance by staking a minimum of 25 AVAX. Approximately 82% of the total stake comes from nodes themselves, while the remaining 18% comes from individual delegators. Compared to other Proof of Stake (PoS) chains, Avalanche’s liquidity staking feature has not been widely adopted. As the two largest liquidity staking service providers on Avalanche, Benqi and GoGoPool currently only account for 3% of the total stake.

The Ava Labs team has introduced Proposal ACP-13 to the Avalanche community, aiming to reduce the cost and complexity of launching subnets. This proposal introduces a new type of validator 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 solely 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, reduce regulatory risks for institutional clients, and maintain interoperability between subnets.

Under the current rules, all subnet validators must participate in the Mainnet’s three-chain validation, requiring a minimum stake of 2,000 AVAX, which, at the current market price of AVAX, is equivalent to approximately $88,000 initial capital per validator. Proposal ACP-13 aims to reduce costs by 75% by allowing SOVs to stake only 500 AVAX, as they do not participate in Mainnet validation and therefore do not receive network rewards. However, even with the reduced cost proposed, starting a subnet validator still requires around $22,000, and the price sensitivity effect on potential validators remains to be evaluated.

By waiving the validation requirements for C-Chain and X-Chain, the proposal enables subnet validators to more efficiently allocate their hardware resources, focusing on maintaining their own chains rather than dispersing resources to support the Mainnet. Although the current hardware requirements for the Mainnet are not high, there are still voices within the community calling for increased hardware configuration 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, Proposal ACP-13 also addresses the regulatory risk issues faced by permissionless smart contract platforms (such as C-Chain). For example, the US government has imposed OFAC sanctions on certain Ethereum addresses, forcing regulated validators, developers, and transmitters to exclude specific transactions to remain compliant. By exempting subnet validators from the requirement to participate in Mainnet consensus, ACP-13 effectively reduces this regulatory risk, providing more possibilities for entities in the US inclined to mitigate risks to build blockchains.

Subnet Architecture

Avalanche is committed to becoming the preferred network for developers to build custom blockchains. To achieve this goal, it is crucial to provide an interoperable, flexible, and efficient infrastructure.

Avalanche Warp Messaging

In the world of blockchain 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 validator clusters of two different chains to communicate directly, eliminating the need for third-party bridges to transfer data or assets, greatly simplifying interactions between various blockchains within the Avalanche network. The design of AWM is highly flexible, supporting message passing between any chains registered on the P-Chain, whether they are permissionless base chains like C-Chain, fully permissioned application-specific chains, or any combination thereof.

Inter-subnet message passing is facilitated by 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, which serves as a registry for subnet validator hubs. For example, suppose subnet A sends a message to subnet B. Once AWM is activated by user action, validators of subnet A collectively sign a message and relay it to subnet B through a relayer. Subnet B’s validators then verify the message to determine if it is signed by a certain proportion of staking weight from subnet A. It’s worth emphasizing that the 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. However, to achieve compatibility with the Ethereum Virtual Machine (EVM), a series of significant engineering optimizations are required. With the introduction of ACP-30, a unified implementation standard for inter-subnet message passing has been established on C-Chain and all EVM-based blockchains within the Avalanche network.

This community proposal officially took effect with the Durango upgrade on March 6, 2024, enabling users to easily transfer assets between different chains using the Teleporter tool. Built on AWM, Teleporter provides a simple interface for sending and receiving cross-chain messages, thereby supporting the transfer of ERC-20 tokens between blockchains within the Avalanche network. Teleporter is designed to provide a smooth and reliable user experience, including features such as avoiding transaction duplicates, implementing relayer whitelists, and setting optional transaction fees. With the widespread adoption 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

Virtual machines (VMs) are software systems that define the specific operational behavior of a blockchain by specifying transaction formats, state access permissions, gas mechanisms, and other key elements. Different VM design philosophies and implementations have profound implications for the performance and functionality of applications developed on top of them. Take Ethereum’s Ethereum Virtual Machine (EVM) and Solana’s Solana Virtual Machine (SVM) as examples. The two have drastically different design trade-offs: EVM is known for its large developer community and mature development tools, while SVM focuses on optimizing performance through its multithreaded runtime, parallel execution capabilities, and improved transaction fee mechanisms.

The Avalanche network allows blockchain systems built on it to choose to run pre-built virtual machines, such as the Subnet-EVM designed specifically to be compatible with Subnets, or developers’ custom virtual machines. Given that building a brand-new virtual machine is a highly challenging task, the vast majority of chains on the Avalanche network choose to run Subnet-EVM. The development of HyperSDK aims to lower the barrier to creating custom virtual machines, enabling developers to achieve personalized customization without starting from scratch.

HyperSDK provides a framework for building custom virtual machines (HyperVM) that can be directly integrated into the Avalanche network. Equipped with powerful default settings, this framework allows developers to focus on core application development without the need to build virtual machines from scratch. In theory, HyperSDK can reduce the time required to develop a virtual machine from several months to just a few days, greatly accelerating developers’ market response speed.

The development of HyperSDK not only signifies a new level of performance enhancement for Avalanche but also introduces an advanced transaction processing mechanism called Vryx. The design philosophy of Vryx is inspired by several widely recognized research papers, especially the Narwhal Tusk paper released by Diem (formerly Facebook team), which has profound implications for modern blockchains like Aptos and Sui. At its core, Vryx separates the various steps of transaction processing, allowing validators to simultaneously build and replicate blocks. In short, it achieves horizontal scalability of throughput by reducing the total time required for block construction, replication, and validation. This means that Vryx will significantly increase the transaction processing speed of the Avalanche network, pushing its transactions per second (TPS) to new highs. While Vryx has not been officially launched yet, Ava Labs plans to integrate it into HyperSDK by the end of this year. The performance benchmarks to be released by Ava Labs will demonstrate the efficient performance of Vryx, with an expected TPS breakthrough of over 100,000.

Database Solution

In the pursuit of optimizing performance in blockchain design, performance enhancements often come with the trade-off of higher hardware requirements for validators. The future hardware requirements of subnets will be influenced by the selected type of virtual machine, and the main network community will face a decision: whether this trade-off is appropriate for the C-Chain. Typically, increasing hardware requirements are thought to increase the cost of becoming a validator, which may in turn reduce the universality of node operation, a critical aspect in balancing performance with decentralization. While theoretically reasonable, this is not always the case in practical operations. For example, despite higher hardware requirements, the Solana network can maintain 1,606 staked nodes, exceeding the scale of the Avalanche main network. Additionally, factors such as the geographical distribution of nodes and servers are also essential considerations in decentralization discussions.

To take further steps in performance improvement, Ava Labs is actively developing a proprietary database solution called Firewood. Firewood aims to address the core obstacle of state management encountered in the blockchain expansion process. The blockchain state refers to the real-time snapshot of relevant data stored in the system, which expands as usage increases. As a result, validators need to quickly access the current state for efficient transaction processing, a demand that becomes increasingly challenging as the state grows.

The goal of Firewood is to enhance the previously developed MerkleDB database. It adopts an innovative mechanism to efficiently store and retrieve blockchain states by reducing the overhead required to modify the existing state. The introduction of this mechanism is expected to create a more robust database system that can provide rapid state access capabilities, thereby removing the key obstacles to improving transaction processing capacity. Ava Labs expects to soon release benchmark test results for Firewood performance to demonstrate its superior performance capabilities.

Comparison With Other Technology Solutions

Avalanche is not the only technology stack building infrastructure for launching blockchains. Currently, the most well-known methods for building one’s own chain include application chains (appchains) in the Cosmos ecosystem and rollups on Ethereum. Each framework has its own set of trade-offs, attracting different groups of developers.

Cosmos Application Chain

Avalanche network and the Cosmos ecosystem share almost identical ultimate goals: connecting asynchronous independent chains through trust-minimized messaging standards. Both platforms allow developers to build blockchains that manage their own security, requiring the establishment of a high-quality validator set. Even with the implementation of ACP-13, a deposit of 500 AVAX may still serve as a barrier to entry for becoming a subnet validator. Therefore, 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 requirement; however, we see significant overlap among appchain validator sets. For example, Chorus One, Allnodes, Polkachu, and Informal Systems are validators for Celestia, Cosmos Hub, Osmosis, and dYdX, respectively.

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

Currently, the P-chain in the Avalanche network serves as the central registry system for subnets, where validator information is stored. This architecture means that although subnets are technically independent, they are to some extent dependent on the P-chain and cannot operate completely autonomously. For example, the distribution of staking rewards within subnets is determined by the P-chain, limiting the subnets’ freedom to experiment with new reward distribution mechanisms. In contrast, chains in the Cosmos ecosystem have more sovereignty; they do not have a centralized hub like Avalanche, allowing them more freedom to adjust and design their technology stack. One reform proposal currently under discussion by Ava Labs is to allow validator sets controlled by subnets to manage and report any changes to the P-chain, granting subnets more autonomy while the P-chain acts only as a bridge for cross-subnet communication. This proposal is still in the discussion stage, and its implementation prospects are uncertain.

The Cosmos ecosystem has undergone extensive technical experimentation in recent years, with successful cases such as Terra and dYdX showcasing its 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 development community brings more innovation to the technology stack, such as modules developed by external teams for use by other chains.

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

In both AWM and IBC technologies, inter-chain message delivery relies on relayers. However, in the Cosmos ecosystem, relayers’ work is not directly economically incentivized, often provided by service providers based on business needs. Although the proposal to increase fees for IBC transfers has not gained widespread support, the Cosmos ecosystem has still established a large relay network, with players like Crossnest, Informal Systems, and Notional playing crucial roles. As the subnet ecosystem expands, building a similar relay network takes time, but Teleporter provides incentives for relayers by introducing optional fees, theoretically improving the quality of relay services and accelerating asset transfer speeds. Although Teleporter has been online for less than a day, we will continue to monitor the development of the relay ecosystem.

Avalanche’s consensus mechanism, using the Subsample technique, has successfully expanded the scale of active validator sets to over 1,800, which is significantly better than Cosmos chains, where the number of validators typically ranges from 80 to 180. This expansion enables permissionless blockchains to thrive on the Avalanche network. However, both networks support developers in creating chains with permissioned validator sets, such as Cosmos’s Noble and Avalanche’s Evergreen subnets. With the launch of HyperSDK, Vryx, and Firewood, Avalanche is expected to provide more efficient technical support. However, specific performance improvements will only be determined after the release of relevant benchmark tests.

Rollups

Rollups provide another pathway for launching new blockchains on 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 and involve state verification technologies such as fraud proofs or zero-knowledge proofs, frameworks like OP Stack or Arbitrum Orbit, settlement options like Ethereum or other rollups, and data availability solutions like Ethereum or Celestia. The design of Rollups significantly impacts their security and stability, so when summarizing this construction method, we aim to compare it with the concept of launching a blockchain on the Avalanche network.

One significant difference lies in the source of security. Blockchains within the Avalanche network rely on themselves to ensure security, while Rollups inherit security from their base layer. Rollups extend the execution capabilities of the underlying blockchain by creating a mechanism provided by the base layer for consensus, settlement, and data availability support for Rollups. In contrast, subnets are essentially independent Layer1 blockchains that provide their own consensus, settlement, and data availability, having their own staking tokens. While most rollup solutions focus on EVM-compatible rollups, which may have performance limitations compared to newer virtual machines, building rollups based on new or custom virtual machines (such as the SVM fork used by Eclipse) is feasible. Avalanche subnets remain neutral regarding virtual machines, meaning subnets can run blockchains based on any virtual machine. Although most subnets in production environments currently 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 responsible for making transaction data public to the data availability layer, ensuring public visibility. Under this architecture, the sequencer becomes a potential centralized failure point; if a system failure occurs, users may be unable to execute layer-two transactions. Although such failures usually do not directly result in user asset losses, the specific design of rollups determines the level of security assurance. On the other hand, the Avalanche network ensures no single point of failure through fault isolation mechanisms, so even if the P-chain fails, it only affects cross-chain communication, and activities within each subnet will continue normally. This contrasts sharply with the performance degradation of rollups when settlement or data availability problems occur.

Avalanche’s security mechanism is based on subnets responsible for execution, data availability, and consensus, where validators perform all chain roles. Like most proof-of-stake-based 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 the data is not made public, it may result in the rollup state being unable to update, thereby freezing user assets. In theory, users should be able to download block data and verify rollup state transitions themselves to ensure security.

Within the Avalanche network, since subnets are responsible for security themselves, 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 operating cost of rollups mainly consists of the cost of publishing data to the data availability layer, which is a variable cost that changes with usage and is typically passed on to users as transaction fees. The launch of Celestia significantly reduces the economic burden of operating rollups by reducing these costs by 99%.

A significant advantage of subnets over rollups lies in the Avalanche Warp Messaging (AWM) technology they adopt, providing natural interoperability within the Avalanche network. This interoperability is currently lacking in rollups, leading to unresolved challenges in cross-rollup communication. In the isolated network formed by rollups, fund flows, user communities, and market attention have begun to diversify. Although various third-party bridging solutions currently exist, each solution is based on its own set of trust mechanisms.

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

Conclusion

Avalanche network is steadily emerging as the premier platform for building high-performance blockchains that seamlessly interoperate. Their biggest challenge will be attracting builders into the Avalanche ecosystem rather than choosing competitors’ ecosystems. The strong focus on performance and scalability in blockchain technology may become a competitive advantage for Avalanche. We anticipate that the launch of HyperSDK, Vryx, and Firewood in the second half of the year will serve as major catalysts for widespread adoption of Subnets. Additionally, discussions about ACP-13 are strictly focused on reducing barriers to entry and increasing Subnet adoption rates. The purpose of ACP-13 is to make it easier for more developers and projects to join the Avalanche network by lowering costs and simplifying processes to promote the creation and growth of Subnets. Such measures are expected to increase the diversity and functionality of the Avalanche network, thereby attracting more builders to participate in its ecosystem.

Disclaimer：

1. This article is reprinted from [chaincatcher], All copyrights belong to the original author [Dan Smith],. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.