Cortina: X Chain Linearization

Author: Cortina

On Monday, April 3, 2023, the pre-release code for the Avalanche Cortina upgrade will be released. This upgrade will activate at 11 AM on Thursday, April 6, 2023, Eastern Time (UTC 3 PM). Please note that this pre-release code is only applicable to Fuji. If you run the code on the mainnet, it will exit upon launch.

The activation time for the Avalanche mainnet will be announced after the successful completion of the Cortina upgrade on Fuji, along with the release of the official Cortina AvalancheGo version (v1.10.0).

The Cortina upgrade includes protocol optimizations that are incompatible with AvalancheGo versions < v1.10.0. If you are running a node on Fuji, you must upgrade your software to AvalancheGo >= v1.10.0 before the activation time on Fuji. If you are a mainnet node operator, no action is required until the official [email protected] code is released.

X-Chain Linearization

The X-Chain runs Avalanche Consensus, a DAG-based leaderless protocol that allows for high-throughput concurrent processing of non-conflicting UTXOs without establishing an active total order. On the other hand, the C-Chain, P-Chain, and all Avalanche subnets run Snowman++, a fully ordered chain-based protocol that can sort non-conflicting block production among thousands of participants without time-based slots.

The existing semantics of the X-Chain hinder or significantly complicate the integration of Avalanche Warp Messaging (AWM), the addition of complex X-Chain transactions, the enabling of state synchronization, and broad exchange support. AWM integration requires Snowman++ to verify the BLS multi-signatures of incoming messages from other Avalanche subnets.

This limitation means that the current form of the X-Chain cannot interact with subnets, and its DAG-based consensus cannot be widely applied to subnets, while the vast majority of subnets wish to communicate seamlessly with other subnets. Partial ordering on the X-Chain means that there is no canonical state during vertex validation (a vertex is a container for batched transactions on the X-Chain, similar to blocks in a blockchain), and vertices are designed to be processed in different orders on different nodes.

Without a canonical state, interacting with shared on-chain objects (such as exchanges) and synchronizing state to the network tip (to avoid reprocessing all historical activity) becomes a significant and error-prone issue that the community can spend further development time on subnets.

Finally, the uncertain ordering of on-chain activity greatly hinders the ability of many traditional exchanges to integrate with the X-Chain in its current form, as most traditional exchanges are designed for fully ordered blockchains like Bitcoin and Ethereum, and they struggle to coordinate balances at different points in time on a partially ordered blockchain.

Cortina migrates the X-Chain to run Snowman++ consensus and operates as a fully ordered blockchain in a process called "linearization." Once linearization begins, it will no longer be possible to add additional vertices to the X-Chain DAG. The final state of the DAG is now immutable and will serve as the genesis state for the linearized X-Chain supported by Snowman++. The transaction format used on the X-Chain and the APIs for submitting transactions, getting transaction status, and retrieving balances will not change in this process, so most wallets will not need to make any changes to support this linearization event.

However, explorers supporting the X-Chain will need to migrate to parsing X-Chain blocks instead of parsing X-Chain vertices, which will look very similar to P-Chain blocks. The linearization is seamless and should not cause any downtime for the P-Chain, C-Chain, or any subnets. However, the X-Chain will be temporarily inaccessible.

As mentioned above, this migration paves the way for the integration of Avalanche Warp Messaging, with new transaction types modifying the shared X-Chain state, providing a direct path for state synchronization, and enabling exchanges to support the X-Chain, which will include many tokens used on resilient subnets.

While total ordering can be introduced on the DAG, doing so on the X-Chain would require rewriting the existing Avalanche consensus engine and would not benefit any subnet. Migrating to a single consensus engine for the entire Avalanche network, reducing the scale of the trusted computing base, and leveraging existing R&D work will enable faster development and more widely applicable innovations.

We have prepared a migration guide for integrators that highlights all the changes to the AvalancheGo API required to support Cortina.

Batch Delegation Rewards

Since the launch of the Avalanche network, validators have had the opportunity to charge service fees to anyone who delegates to their nodes. If a validator is online for 80% of the delegation period, they will receive a percentage of the rewards (fees) earned by the delegator. The P-Chain allocates this fee as a separate UTXO for each delegation period.

With the significant increase in the number of delegators on the network over the past few months (reaching about 80k as of March 20, 2023), the number of UTXOs that validators may receive as fees has also increased significantly. This often means that validators end up with thousands of small UTXOs that must be aggregated for any use. Tracking thousands of UTXOs in browsers and wallets also makes providing an excellent user experience more challenging than necessary.

Cortina modifies how these delegation fees are allocated to all validators who start staking after the activation of Cortina (validators who staked previously will see no changes). Fees are now processed in batches over the entire validation period of the node rather than sending fee UTXOs for each successful delegation period, and they are allocated when the node unstakes.

Increase C-Chain Gas Limit

Since Apricot Phase 1, the gas limit for C-Chain blocks has been set to 8M gas. Blocks on the C-Chain are generated approximately every 2 seconds, so this setting limits the maximum amount of gas that can be consumed every 10 seconds to about 40M gas. However, the gas target for each rolling 10-second window is set to 15M gas. This means that when more than 15M gas is used within a 10-second window, the gas price will increase (and decrease when using less than 15M).

In addition to limiting the amount of gas that can be consumed at any gas price within a given window, the block gas limit also restricts the complexity of transactions that can be published in a single block. As different developers on Avalanche begin to deploy more complex dApps, they have indicated that 8 million gas per block is insufficient for their use cases. Cortina increases the gas limit for C-Chain blocks to 15 million gas. To avoid increasing the resource requirements needed to validate the main network, the gas target will remain at 15M gas every 10 seconds.