Scaling Limitations Across Blockchain Ecosystems

The current landscape for scaling blockchain apps includes Avalanche Subnets and L2s on Ethereum, just to name a few. Each of these models has limitations.

Layer-2 Protocols

L2s are a common approach Ethereum builders use to improve efficiency. By removing the overhead for validation, L2s offload work from the primary chain and create faster transactions and more potential for growth. Unsurprisingly, L2s, especially on Ethereum, have become a go-to for developers who want to expand the functionality and composability of their applications. While these L2 chains help mitigate performance and scalability issues, they also increase the system's complexity. Depending on the blockchain, guaranteeing performance or security becomes more challenging.

L2s have proven a useful, if limited, approach to addressing blockchain scalability. However, it is much harder to ensure that a project is secure, composable, and fully takes advantage of blockchain technology's inherent decentralized nature.

Avalanche Subnets (Now Avalanche L1s)

Until now, the foundation of scaling on Avalanche was driven by the concept of subnets. Much like an L2, developers who wanted to build apps on the Avalanche blockchain would create these subnets, increasing throughput without impacting the mainnet, while improving performance.

We identified some clear issues with this design approach:

• Developers who wanted to build a subnet had to attract a set of validators who would be required to validate the primary network, with a required 2,000 AVAX stake—a significant amount of funding for small and mid-size organizations and development houses.
• While subnets would increase throughput, they also required syncing with the primary network as a validator. As the activity on the primary chain grows, the computing requirements for validation also grow, placing a performance tax on these subnets.
• As subnets were previously tied to the primary network through shared validator sets, this created limitations for projects looking to deploy permissioned chains to comply with jurisdictional or geographical regulations.

To address these challenges, the Avalanche9000 upgrade introduces a new approach to subnets: a network of independent L1 blockchains offering more autonomy, economic efficiency, and operational flexibility.

Innovating Communication and Collaboration: Horizontal Scaling Across Avalanche

Under the previous paradigm of subnets, Avalanche was designed as a multi-lane highway that could support higher throughput by placing larger applications within their execution environments. The problem was that subnets didn’t necessarily address core problems related to control or accessibility, especially regarding builders and their ability to create new applications with specific regulatory or compliance requirements. Organizations couldn’t create a distinct blockchain that fully controls their tokenomics, data privacy, and security mandates.

This approach comes with its tradeoffs. Layered solutions tend to fragment the community into centralized enclaves and ecosystems that don’t work together, so much so that Blockworks suggests that centralization threatens the “foundational principles of blockchain.” While L2s enhance scalability to some extent, they delay, rather than solve, the underlying problem.

Avalanche9000 empowers builders to harness the power of the Avalanche network to create their own L1 chain without some of the baggage of the original subnet architecture. That means full customization,decentralization, and control over the economics and functionality of your chain.

The Avalanche9000 Ecosystem

The network of Avalanche L1s is made possible through a combination of unique functions:

• The Primary Network: The primary Avalanche chain serves as the economic foundation of the Avalanche network, controlling smart contracts (C-Chain), managing network validators (P-Chain), and supporting asset exchange (X-Chain). Every new L1 can access the functionality of the C-Chain, and new builders can leverage the robust infrastructure and tooling from the start, increasing liquidity and reducing overhead to launch new projects.
• The Network of L1s:Unlike subnets or L2s, these independent L1s give developers full control over what they build. Avalanche L1s control staking economics, gas tokens, permissions, compliance and security standards, and other features without sacrificing performance or scalability.
• Interchain Messaging (ICM):Every L1 is connected through ICM so that asset exchange across chains is fast and secure. The ICM locks assets on the source chain and mints the equivalent on the receiving chain while maintaining the integrity and decentralization of exchange.

Avalanche9000 and the Etna Upgrade

The driving force behind Avalanche9000 is the Etna upgrade, a series of network upgrades and optimizations that address the challenges previously discussed and will used in a new era of Avalanche L1s

The core changes after Etna are:

• Switchover to L1s: All subnets are now sovereign L1s as the network adopts this new Avalanche9000 architecture.
• Accessibility for Validators:Validators no longer have to synchronize with the primary network and stake the 2,000 AVAX previously required to spin up a new validator. Now, fees are calculated based on their L1 validators (at a reduced rate).
• L1 Ownership: The ownership of validator set management will be moved from the P-Chain to individual L1 ValidatorManager smart contracts.

Individual Community Proposals in the Etna Upgrade:

• ACP-77: Separates primary network validators from subnet validators, allowing L1s to set up validation management features via smart contracts. Now, individual L1s can have different rules for their local validators that can extend to the Avalanche system.
• ACP-20: Adds Ed25519 TLS certificate security support for p2p communications on the Avalanche network.
• ACP-103:Creates the dynamic fee mechanism for the primary chains (specifically the X-Chain and the P-Chain). Previously, these fees were static and did not represent changes to resource usage and network load.
• ACP-113: Proposes a mechanism to create verifiable, non-cryptographic random number seeds. Avalanche currently doesn’t have a secure random number generator for EVM-compatible smart contracts, which limits their ability to be used for things like lotteries or security tasks.
• ACP-118: ACP-118 is an Avalanche Community Proposal proposing a standard AppRequest payload format type, simplifying potential Avalanche Warp Messaging (AWM) signature aggregation implementations.
• ACP-125: Reduces the base fee on the C-Chain from 25 nAVAX to 1 nAVAX. nAVAX represents the lowest possible gas price needed to execute a transaction on the C-Chain.
• ACP 131:Brings EVM opcodes from the Cancun Upgrade to the C-Chain and Subnet EVM.

Lowering the Barrier to Entry for Builders

One of the biggest challenges of building a blockchain project involves the underlying economics of the L1. This was as true for Avalanche, where starting projects became prohibitive for anyone but the most established developers.

Avalanche9000, from the ground up, is a solution to this barrier. With the drastic lowering of startup costs and the ease of launching fully independent yet connected L1 blockchains, rolling out a dedicated L1 project only takes minutes. Just register your validator on the P-Chain and pay a fee that will be burned.

Opening Space for Freedom and Decentralization

Under the previous subnet schema, developers faced some limitations that were tied directly to the necessary relationship between the subnet and the Avalanche chain.

With Avalanche9000, developers now have the freedom to launch chains that match their specific needs. That means:

• There is potential to build private, permissioned chains distinct from the public, permissionless architecture of Avalanche to support various regulatory compliance needs.
• You can bring your Virtual Machine to your L1, including the EVM, Ava-VM, WASM, and any other VM.
• The ability to connect Avalanche L1s to oracle networks via Avalanche Interchain Messaging

The Retro9000 Incentive Program

In addition to these lowered fees, Avalanche is offering developers retroactive grant funding for being among the first to build their apps on Avalanche9000.

Retro9000 is a retroactive grant program funded by the Avalanche Foundation, designed to reward developers for pioneering testers and building the critical foundations of a network of Avalanche L1s. neration of L1 apps and tools on the Avalanche9000 testnet.

This program offers up to $40 million in retroactive grants and rewards developers building the first generation of L1 apps and tools on the Avalanche9000 testnet.

Retro9000 is a new way to think of untapped possibilities. This retroactive rewards platform will launch with the initial track of 9000 testnet contributions. The earliest builders can participate and share their contributions publicly to show what’s possible on Avalanche.

REGISTER NOW

The Promise of Secure, Scalable, Controllable Development with Avalanche9000

Avalanche9000 is the upgrade we’ve envisioned for years. Instead of driving ourselves further and further into layered and fragmented solutions that don’t share tokenomics, resources, or even basic communication features, it’s possible to open up a network of Avalanche L1s in a way that empowers developers to truly innovate.

The Avalanche9000 network of L1s is our first step down this road. With it, developers can gain the advantages of building on an L1 (security, customization, control) without sacrificing the benefits they’d expect from an L2 (scalability, speed, integration with foundational on-chain economics).