Etna: Enhancing the Sovereignty of Avalanche L1 Networks

Intro

A release for the latest upgrade to the Avalanche Network, dubbed the “Etna” upgrade, was published for activation on Avalanche Mainnet scheduled for 12 PM ET (5 PM UTC), December 16, 2024. This proposed upgrade consists of Avalanche Community Proposals (ACPs) [ACP-77] Reinventing Subnets, [ACP-103] Add Dynamic Fees to the P-Chain, [ACP-118] Warp Signature Interface Standard, [ACP-125] Reduce C-Chain minimum base fee from 25 nAVAX to 1 nAVAX, [ACP-131] Activate Cancun EIPs on C-Chain and Subnet-EVM chains, and [ACP-151] Use current block P-Chain height as context for state verification. The prereleased code version was successfully activated on the Fuji Test Network at 11 AM ET (4 PM UTC), November 25, 2024.

The Etna Upgrade release includes protocol optimizations that are not compatible with AvalancheGo versions <v1.12.0. If you run a node on Mainnet, you must upgrade your software to AvalancheGo >=v1.12.0 before the scheduled activation time. If you are a Mainnet node operator, upgrading to v1.12.0 is mandatory. The plugin version is unchanged at 38, and is compatible with v1.11.13.

C-Chain Fees Reduced

This upgrade activates ACP-125, which reduces the C-Chain transaction minBaseFee from 25 nAVAX to 1 nAVAX, a reduction of nearly 96%. This change has big implications for users, as it affects the lower bound of transaction fees under the EIP-1559 fee mechanism. This update simply lowers the floor for transaction fee pricing, making Avalanche transactions significantly cheaper during periods of low activity.

For context, the minBaseFee sets the minimum possible value for the base fee of all transactions on the C-Chain, as defined by EIP-1559. The base fee is a dynamic component of transaction fees that is adjusted based on the demand for block space. When the network is less congested, the base fee will decrease, approaching the minBaseFee, making transactions less expensive. At high demand, fees will increase proportionally with the load on the network, so the fees may be higher.

Dynamic Fees Introduced on the P-Chain

A similar dynamic fee mechanism has also been introduced to the P-Chain in this upgrade, implemented according to the specification proposed by ACP-103. With the previous fixed fee mechanism, P-Chain users were provided with simplicity and predictability, but network congestion and resource constraints weren’t properly accounted for. Adding this dynamic fee mechanism has made it possible to significantly lower the transaction fees on the P-Chain, as it no longer relies on hard-coded, artificially high fees as the main DoS prevention mechanism. Furthermore, adding a fee mechanism that can more robustly handle spikes in load was necessary to prepare for the possibility of increased P-Chain usage following the new functionality added in ACP-77, which introduces five new P-Chain transaction types that perform Layer 1 (L1) validator management.

A Network of Sovereign Networks

ACP-77 introduces a mechanism for creating and operating a sovereign Layer 1 blockchain, aimed at addressing the biggest concerns around the existing Subnet architecture. 

Etna introduces the ability to create sovereign Avalanche L1s, with lightweight, cost-efficient validation. Instead of staking 2000 AVAX, L1 validators will pay a dynamic continuous fee for L1 validation as defined by the ACP-77 specification, which should initially be approximately 1.3 AVAX per month. Unlike Subnet validation, L1 validators are not required to sync and validate the Primary Network. For an explanation on the distinction between Subnet and L1 validators, see ACP-77 for a note on the nomenclature.

This upgrade also enables L1s to enforce custom validator management logic with smart contracts. Projects can choose from conventional proof-of-authority and proof-of-stake validator management contracts made available by the Avalanche Platform engineers for the community to review or use as they see fit, or define their own staking logic with a custom smart contract, such as the contract proposed by community member Gauthier Leonard in ACP-99. This unlocks a new level of network design for creators, enabling unlimited custom staking logic to be easily defined and enforced on L1 networks. 

This new functionality significantly reduces the economic barrier to create and operate a blockchain (over 99.9% reduction in upfront costs), drastically reducing the required validator resources and defining a new industry standard for L1 network creation.

Messages Ensured by an Entire Network 

This upgrade includes [ACP-118] which proposes a VM-agnostic standard payload format for requesting signatures for Avalanche Interchain Messages. A valid ICM signature is produced by querying a blockchain’s validator set, requesting a threshold majority sign a message confirming an event has or has not occurred on that chain, and then aggregating those signatures into a single BLS signature. Most of the new validator management transaction types introduced by ACP-77 require valid ICM signatures signed by either the source chain or the P-Chain to secure validator addition and removal. 

ACP-118 standardizes the request and retrieval of Warp signatures, defining it as part of the AvalancheGo client such that VMs do not need to independently implement this logic. This will simplify signature aggregator implementations by allowing them to depend only on AvalancheGo for message construction, rather than individual VM codecs.

‍