Context:
- With L2s, L3 appchains, and modular blockchains, the number and diversity of blockchains building atop Ethereum is heading toward a rapid increase, making Ethereum a newly fragmented and complex ecosystem. For a complete view of the team’s insights into the requirements and dimensions of this future state of Ethereum L2s, read this blog post on L2 interoperability.
- Today, integrating L2s into the Axelar network is analogous to integration with any other EVM. Compatibility checks are performed, validators onboard, gateway contracts are deployed and relayers start forward packets between chains. Some problems with this approach include: (a) higher than desired engineering overheads, (b) manual steps for validators, (c) additional inflation on the network to incentivize validators, and (d) slower onboarding for L2 partners.
We believe the Axelar network should be able to connect L2 stacks more efficiently [reduce engineering overhead], more securely [potentially eliminate reliance on external validation] and in a more automated fashion [when you spin up a new L2/rollup app-chain, you get connectivity for free] – without adding inflation on the network.
On the protocol side, the Axelar core team proposes to tackle this via two potential paths.
Part I: Interchain Amplifier with external validation.
The upcoming launch of the Virtual Machine environment on the Axelar Network will help streamline a lot of integrations. Instead of relying on the protocol developers to add support for new chains to the consensus logic, anyone can instantiate a set of smart contracts on the network to connect to a new chain. There will also be a universal “router” smart contract that, upon acceptance by the governance, will allow routing traffic to any of the other N interconnection ecosystems.
This is similar to what the Axelar network has today at the network layer, but the envisaged model to select validators is a bit different [to avoid having to build a secondary economic zone]:
- A validator wishing to join the active set to support a new chain enters a governance process, in which AXL token holders vote to approve the validator.
- Once approved, the validator would receive rewards that are initially bootstrapped through the depositing of AXL into a pool by certain entities, potentially foundations.
- When a connection generates enough traffic, a further governance process can be initiated for fees to be turned on and distributed to validators.
A validator can enroll to support any number of chains they wish [it’s an opt-in model], and the rewards they receive are proportional to the number of connections they serve and their quality of service.
Governance could also be used to approve new chain connections themselves. Anyone can propose to add a new chain, deploy the contracts, recruit validators and set up relayers. Relayers are self-contained and open-source.
This path would reimplement a lot of Axelar network functions at the VM layer, minus differences in rewards and how validators are selected.
Status: Ongoing.
Devnet: Complete. End-to-end flows across EVMs have been established.
Target go-live on testnet [subject to testnet governance approval]: ~Q4-Q1.
Target go-live on mainnet [subject to mainnet governance approval]: ~Q1-Q2.
Part 2: Light-client based integrations.
The above model technically can serve an unlimited number of chains. However, it offers somewhat limited automation [even if it’s an EVM chain where all contracts are reusable]. What is one way for the Axelar network to automate integration with a lot of L2s/L3s without relying on external validator support? The idea is to reuse the validity mechanisms of these chains themselves that are used to anchor them to Ethereum where they establish a root of trust. That is, most L2s have an efficient light-client or a ZK-based roadmap to serve proofs of validity to Ethereum. These serve as compact programs that can be verified externally to validate that a certain transaction has indeed happened. With the programmability of the Axelar network, we can reuse those proofs and verify them directly on the Axelar network chain. That is, instead of having an external validator set vote on a state of a transaction, a proof can be relayed to the Axelar network, verified and, if valid, routed via the Router Smart Contract to any other destination chain.
For instance, multiple projects are building ZK-based light clients for Ethereum and/or specific stacks around them. Polyhedra, Succinct Labs and RISC Zero are examples.
- Polyhedra aims to generate ZK proofs for many chains, using hash functions only [no fancy crypto assumptions].
- Succinct Labs built a ZK light client for verifying the Ethereum sync committee.
- RISC Zero is a generic ZK virtual machine [VM] with multiple roll-ups building on top of their stack. These roll-ups will be able to produce proofs of validity based on the execution within the RISC Zero VM. The proofs of validity can be integrated in other chains.
In addition, zkSync and Polygon will be using ZK validity proofs to integrate with Ethereum, which can be used as access points by interoperability networks that connect other L2s.
Endgame: Overlay networks
One may ask, why do you need the Axelar network if L2s and L3s connect to Ethereum anyways? Can the appchains talk to each other directly or rely on Ethereum as the routing hub?
The answer to all of these questions is that it’s possible, but it’s a matter of ecosystem focus and costs. Interoperability is not just about the connectivity protocol – you need to make gas efficient protocols, build layers of execution services, account abstractions, monitoring stacks, and developer tools to make it usable. This is where the concept of overlay networks comes handy.
From its beginnings, the Axelar network was introduced as an overlay across multiple blockchains. Don’t know what these are? That’s exactly the point! But these networks serve most of the internet’s content. While the internet is connected by bare-bones protocols like TCP/IP, developers do not interact with these directly. Instead, they rely on networks like those offered by Akamai or Cloudflare to efficiently and securely be able to find the cheapest, most efficient content to deliver information from A to B. Developers often plug into these APIs.
Similarly, we envisage the world with multiple paths of connectivity across A and B, and it’s the paths that offer unique advantages on the cost, speed, and security and developer experiences that will be used by developers. While native pairwise connectivity will continue to exist within these ecosystems, a truly “chain-agnostic” protocol supported by the Axelar network would uniquely offer 1-to-N distribution properties [one connection gives access to N ecosystems], programmable network, and a full stack of services around them [like gas services, monitoring, etc.]
Axelar network developer tools offer orchestration, comparable to those available for internet developers, a programmable cross-chain network, and products like the Interchain Token Service [ITS] that allow simple deployment and management of tokens across many chains. At the core team, we call this full-stack interoperability.
This is the way to establish a Web3 that can open up possibilities existing internet infrastructure cannot support. Together, we can build applications that are easy to use, delivering capabilities that change the way we experience the internet.