Streamlining L2 Integrations


  • 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]:

  1. 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.
  2. Once approved, the validator would receive rewards that are initially bootstrapped through the depositing of AXL into a pool by certain entities, potentially foundations.
  3. 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.


Thanks for sharing the views on this Sergey.

If i understand this right we will implement Part 1 first followed by part 2 in future?

A few queries for my understanding,

can you explain a bit more about alternative ways of achieving security without involving validators. I am assuming this is possible via provers in zk. Is that it or do we have any other means? a end to end flow will help vizualise better.

without validators what are the means of achieving decentralisation?
using zk provers will be cpu intensive based on what we have understood, so this will require cpu inline with miners. In that case we will be limited to a few provers?

@brightlystake good questions.

Part I is expected to go live sooner than Part II, but both are being worked on in parallel by various teams.

Different projects are investigating use of light-clients (IBC-style) and ZK proofs to plug in new connections to Axelar network. In that instantiation, a smart contract on the Axelar network can encode all validation logic. Once the connection is made, the traffic can be routed from the new chain (or an existing one) to all interconnected chains. Validation will happen on the Axelar chain and validators do not need to link to external RPC endpoints. Relaying is handled on top at the transport layer and anyone can continue relaying packets. You can see some related diagrams here: GitHub - axelarnetwork/cgp-spec: Cross-Chain Gateway Protocol Specification

So validators will continue operating and execution critical functions for maintaining the network. The network will continue providing security, translation of packets across different formats, many to many routing, and programmability at the interoperability layer unique to the Axelar network.

1 Like

thanks @sergey we will take a look at the docs.

So we can expect the base inflation to remain and the external inflation will not be necessary.

The ecosystem should of course preserve some min rewards to make sure staking is incentivized to secure the network. That would be the lower bound. A part of that can be contributed via external inflation for some chains, but most newer chains can more to a more efficient model.