A Deep Dive into Avalanche

Our engineering team recently added support for the Avalanche network to our walletOS product suite. For a refresher on walletOS, read our product announcement. This blog provides an overview of the different components of Avalanche including its transaction lifecycle. Engineers and operators working to integrate Avalanche with their business will find this post most useful.

The Avalanche network includes three purpose-built blockchains which compose a greater interoperable ecosystem. The difference between the three chains makes integration non-trivial and more involved than other blockchains.

TL;DR

• Avalanche uses three built in chains to support network functions.
• The Exchange chain is optimized for the creation and trading of assets, The Platform chain handles validator coordination and subnet management, and the Contract chain is an instance of the EVM for deploying smart contracts.
• In addition to deploying smart contracts on the C-chain, apps can also be built on app-specific blockchains validated by subsets of the Avalanche validator set known as subnets.
• The three chain design allows for a wide range of functionality, but also makes implementation a bit more complex.

Architecture Overview

The three built-in blockchains that make up the Avalanche Platform are:

• Exchange Chain (X-Chain);
• Platform Chain (P-Chain); and
• Contract Chain (C-Chain).

The network is designed with each chain having a specific purpose. The X-Chain is used for the creation and trading of “smart assets”, which are digital assets that can represent real world resources and may have covenants. Covenants restrict the spending rules for the asset. The P-Chain coordinates validators, tracks active subnets, and facilitates the creation of new subnets. The C-Chain is an instance of the EVM, and thus allows users to deploy and use smart contracts as they would on any other EVM-compatible chain. Assets can be easily moved back and forth between these chains via Atomic Transactions, a concept that will be covered in more depth later in this blog post.

Avalanche also supports the creation of subnets. These are sovereign networks made up of a subset of Avalanche validators - they specify their own execution logic, maintain their own state, facilitate their own networking and manage their own security. Avalanche's three built-in blockchains are validated and secured by a special subnet known as the Primary Network, which is composed of all Avalanche validators. Users of the platform can create their own subnets to deploy and secure customized blockchains that precisely meet their needs.

Using a single blockchain to achieve all of Avalanche's functionality would require architectural compromises, so instead the network delegates different functionality to multiple purpose-built chains. This approach can complicate working with Avalanche since each built in chain uses slightly different cryptographic constructs, data structures, and virtual machines.

Each built-in blockchain on Avalanche is run using its own virtual machine:

• AVM: Avalanche Virtual Machine
• Platform VM: Platform Virtual Machine
• C-Chain: coreth

X-Chain

The X-Chain optimizes for fast finality and low fees to facilitate the creation and trading of smart assets. To achieve this, the X-Chain uses a consensus algorithm known as Avalanche Consensus. Unlike most other deployed blockchains, Avalanche consensus uses a directed acyclic graph (DAG). In a DAG, each vertex may have multiple descendents and ancestor vertices, so in some cases there is no notion of which element came first. For example, in the Basic DAG image below, both b and d are descendents of a, but there’s no indication which descendent was first.

Fees on the X-Chain are determined by a predefined fee schedule, so the fees required to make a transaction depend solely on the type of transaction being made. The X-Chain uses an unspent transaction output (UTXO) transaction model.

P-Chain

The P-Chain is designed to coordinate validators and manage subnets. Unlike the X-Chain’s Avalanche Consensus Mechanism, the P-Chain uses a modified version of Avalanche Consensus known as Snowman. The Snowman Consensus Protocol is simply a linearized version of Avalanche consensus. Since the P-chain is responsible for operations that are dependent on prior events, it’s important to have a total ordering of events that take place. For example, adding a validator modifies the rewards for all future validators, so there must be a clear history of all validator additions. The P-Chain also uses a UTXO transaction model and transaction fees are determined based on the same fee schedule.

C-Chain

The C-Chain is an instance of the EVM and follows EVM architecture very closely. It runs coreth, a fork of Geth that uses Snowman Consensus to achieve a linear, totally ordered blockchain. The C-Chain uses the account model for transactions and prices fees based on EIP-1559.

Subnets

With the exception of the Primary Network, subnets are not a core part of the Avalanche Platform’s infrastructure. A subnet describes a sovereign network composed of a dynamic subset of Avalanche validators. Note that subnets are not themselves blockchains, rather they are coalitions of validators that work together to achieve consensus over one or more blockchains.

Subnets are extremely flexible. They can define their own rules for membership, token economics, and fees. Moreover, rather than being constrained to run a specific virtual machine like Avalanche’s built-in chains, subnets can launch their blockchains with any existing VM of their choice or a custom VM. They maintain state, facilitate networking, and provide security all on their own. One advantage of subnet blockchains, beyond customization, is that app-specific subnet chains don’t need to share blockspace with other applications. We’ve seen the benefit of this approach in the DeFi Kingdoms subnet chain, which recently processed over 1 million transactions in a single day.

Ownership Model

The significant difference between the chains is the varying ownership model. For wallet engineers, this makes the cost of developing a native Avalanche integration expensive.

All the chains use Secp256k1 with ECDSA.

Both the X-Chain and P-Chain use a UTXO model. Each coin includes additional properties that allows wallets to distinguish the type of output based on fields like TypeID.

On X-Chain and P-Chain, addresses are encoded with bech32, with an additional chain-alias that identifies the chain VM. Our team was not able to find the rationale for the alias. The bech32 encoding scheme already allows for a human readable part (hrp). Avalanche uses the hrp to denote which network environment the address is part of (e.g. mainnet, fuji testnet), but does not help users identify which chain VM to use.

An address is the digest of a two hash functions, RIPEMD and SHA256, of a public key. The hrp for a mainnet avalanche address is avax and the separator is 1.

On C-Chain, the Ethereum-style addresses are inherited which are keccak256 digests encoded with base16. Addresses on the C-Chain can also be encoded using Bech32 in order to transfer assets to other chains.

Transactions

Transaction construction also works a bit differently on all of Avalanche’s built-in blockchains. Since each chain serves its own specialized purpose in the broader Avalanche platform, each chain supports different types of transactions.

Atomic Transactions

Atomic Transactions facilitate the transfer of assets between Avalanche’s built in chains. All three of Avalanche’s built in chains share two transaction types that facilitate atomic transactions, ImportTX and ExportTX.

Asset transfers between chains require two steps in Avalanche. First, an ExportTX spends a UTXO from the source chain and creates an output owned by the receiving address on the destination chain. The output created by the ExportTX is not immediately recorded on the destination chain. Instead, it is stored in Exported Atomic Memory until it is used by the receiver as an input to an ImportTX on the destination chain. Once this ImportTX is complete, the UTXO representing the assets transferred can be used to create regular transactions on the destination chain. Refer to the diagram below from the Avalanche documentation for a visual representation of this process.

Though the C-chain uses an account model for most transactions, it is still possible to create an ExportTX UTXO from a C-chain account balance. Similarly, it’s possible for the C-chain to create an ImportTX by spending UTXOs stored in Exported Atomic Memory.

X-Chain and P-Chain Transactions

On both the X-Chain and P-Chain, creating transactions requires two primary components: A BaseTx, and transaction type specific information. The BaseTx contains common fields and operations, and is embedded into every transaction type on the X and P chains. Specifically, it contains fields for a TypeID, NetworkID, BlockchainID, Outputs, Inputs, and a Memo. If you’re looking for an in-depth explanation of what each BaseTx field entails, check out this documentation page.

Both the X-Chain and P-Chain have specific transaction types to support their assigned functionality. For example, transaction types on the X-Chain include CreateAssetTx and OperationTx, while some P-Chain transaction types include AddValidatorTX, CreateSubnetTx, and AddSubnetValidatorTx. The AVM and PVM have their own transaction formats.

Once an unsigned transaction is created, a CodecID and an array of Credentials are added to create a finalized transaction. The CodecID indicates how the transaction data should be deserialized. Today, the only valid codec id is 00 00. Credentials are a bit more interesting; on the X-Chain, there are two possible types of Credential: SECP256K1Credential, and NFTCredential. Each of these contains an array of 65-byte recoverable signatures, and they are differentiated only by a TypeID field. The P-Chain only has one possible type of credential, the SECP256K1Credential.

C-Chain Transactions

Given its EVM architecture, the transaction format of C-Chain transactions follows Ethereum’s very closely. To be more precise, all intra-C-Chain transactions follow the same lifecycle as Ethereum. The specifics of EVM transactions fall outside the scope of this article, but you can learn more about the EVM’s transaction format here.

The only Avalanche-specific transaction types supported by the C-chain are importTX and exportTX, which facilitate atomic transactions. It’s worth noting that C-Chain atomic transactions do not require a BaseTx. Instead, the relevant information from BaseTx on other chains is simply included directly in inputTx or exportTx.  Like the P-Chain, creating a signed transaction from an unsigned transaction on the C-Chain requires a CodecID of 00 00 and an array of Credentials of one possible type: SECP256K1Credential.

Conclusion

Avalanche uses a unique three-chain model to provide a very wide range of functionality to its users. The X-chain provides a highly optimized platform to create and trade smart assets, while the C-chain allows applications to be deployed as smart contracts on an EVM based chain.

While Avalanche's architecture opens up these possibilities, it also adds significant development overhead for teams that want to support it. If you're looking to quickly and easily add support for Avalanche or any other blockchain to your product without the need to divert engineering resources to the task, request access to walletOS today.