Avail's Vision: The unification layer for web3.

Overview

The permissionless environment of web3 has led to multiple ground breaking technologies that collectively power today’s thriving ecosystem which still has plenty more room for growth. Faced with numerous technical challenges to overcome in order to reach the scale required for mass-adoption, the ecosystem has built a multitude of innovative solutions across the web3 tech stack. However the need for all of this technology to come together and operate as a cohesive whole for end users, while upholding the decentralized ethos of the ecosystem, still remains.

Cross-ecosystem transactions are more cumbersome than they should be, driving needless fragmentation. User adoption efforts should be directed towards onboarding net-new users, instead of pulling them between existing web3 communities.

To address all of this, Avail is accelerating the unification of web3 via the Unification Layer, enabling a secure, scalable and seamlessly interconnected web3 experience for end users of any ecosystem.

In this deep dive we explore the background and thesis behind the Unification Layer and how it addresses user fragmentation and scalability issues facing the ecosystem today. We show how the first component, Avail DA provides a perfect foundation for not only the numerous rollups hungry for efficient data availability, but to set a base where user intents can be seamlessly fulfilled across the web3 ecosystem via Avail Nexus, a permissionless coordination hub. Avail Fusion Security completes the Unification Layer addressing the growing need for shared security to fortify a thriving and unified web3 ecosystem.

Introduction

If you have ever attempted to make a transaction that crosses more than one blockchain network, then you will know the experience is not yet ready for mass adoption.

With a very deep technical understanding of blockchain architectures, one can begin to address this long-standing problem. By working backward from first principles, we can distill the technical foundation needed to create the unified blockchain experience. One that connects separate L2 rollup networks and L1s, while still enabling permissionless, decentralized innovation, and experimentation from developers across different ecosystems.

Rollups have been developed as a partial solution to scalability challenges, processing transactions off-chain before bundling them into a single on-chain transaction. While effective in reducing fees and enhancing Ethereum's scalability, rollups have introduced new complexities:

The demand for more blockspace has escalated costs due to limited availability
The proliferation of Layer 2 (L2) ecosystems has fragmented the market, further hindering user experience and economies of scale

With these problems solved, the scalability and interoperability potential of blockchain systems which has been laying dormant for years, can finally be realized.

The Avail Solution

Avail is leveraging the asynchronous messaging principle - the same principle that scaled the apps on the Internet - to scale blockchains, and the right time to build this is now.

A foundational Data Availability (DA) layer, Nexus interoperability layer, and Fusion Security network layer come together to form the Unification Layer.

The DA layer is a highly optimized, low-level layer, specifically constructed for data availability. This is the deepest blockchain layer, with the minimal functionality required to build cross-ecosystem interoperability on top.
Nexus acts as a light but powerful proof aggregation and sequencer selection ZK rollup on top of Avail, allowing for cross-rollup and cross-ecosystem settlement.
Fusion Security enables a basket of tokens to pool their crypto-economic security to serve and secure the Avail network.

Avail's mission is to streamline the rollup experience, offering a unified, efficient platform for both users and developers from any ecosystem.

This vertically integrated stack aims to dissolve the growing pains and user fragmentation experienced today, enabling rollups to seamlessly access users and liquidity across the entire blockchain landscape.

Avail's vision is to provide a cohesive user experience within a flexible and modular blockchain ecosystem, drawing on lessons from Web2 to innovate in Web3. By marrying advanced technology with a clear roadmap and accelerated execution pace, Avail is not just building a product; we are pioneering a new phase for the blockchain space, paving the way for an era of enhanced scalability and seamless user interactions.

Background and Inspiration

What can we learn from web2?

How did apps on the Internet really scale? Asynchronous microservices.

The Internet is not one huge world computer. It is a series of interconnected computers doing a few specific things based on the business use case, and then communicating with each other whenever required.

Amazon is a set of related microservices specializing in ecommerce. Visa operates a set of microservices that handle payment.

When a user clicks on the Buy button for a product at Amazon, it triggers a call from the browser to an Amazon product microservice.
This in turn calls a Visa microservice to send a payment page to the user.
Once the user fills in the payment details, another request is sent to the Visa microservice to validate the payment.
Once the payment is validated, it gives a callback to the Amazon product microservice to let the user know that the product has been bought and the payment went through.

If it’s Black Friday, then Amazon and Visa microservices will be scaled up to meet the demand independent of other microservices on the Internet.

The point is, that the Internet scaled to such a massive extent only via asynchronous microservices. That’s the same thing that will happen with blockchains as well.

How can we enable this in web3?

UPI is a great example to learn from. It is one of the largest payment systems in the world in terms of users, transactions and volume. Currently, it processes over 10 bn transactions per month, which is a testament to the scale of the system.

UPI is a system which enables customers from different banks to interact. But it wasn’t as successful when it launched. Banks were initially very hesitant to join the system - there was no government mandate to join UPI. The main concern expressed by the banks was that if they allowed UPI transactions, they would end up enabling money from customer accounts to move to other banks (liquidity outflow).

The principle of reciprocity was used to solve this problem. Instead of economic incentives, the principle of reciprocity was used to communicate the notion that banks would get access to UPI and the “pay-in” from other bank customers only if they allowed “pay-outs”.

Although this is an example from a permissioned setting (banks in web2), a permissionless unification layer for web3 should still have the principle of reciprocity embedded within it, and be net positive for the whole ecosystem.

The simple principle of reciprocity helped in making individual banks open their customers and wallets to co-operate effectively in order to ensure that the end customer had the best UX possible.

This is a lesson in making cooperation net-positive for the ecosystem. And this is only possible if the underlying technology has the right primitives to enable cooperation. UPI had these and we have designed Avail to translate the learnings from global-scale web2 systems to web3.

Implementing web2's learnings in web3

The evolution of the Internet offers invaluable insights for the blockchain world. The scaling of the Internet was primarily achieved through asynchronous microservices – a network of interconnected computers each performing specific tasks and communicating as needed.

This model is exemplified by platforms like Amazon and Visa, which operate a series of specialized microservices for e-commerce and payment processing, respectively.
These services scale up independently to meet demand, demonstrating the effectiveness of decentralized, asynchronous operations.
The success of systems like UPI (Unified Payments Interface) further highlights the importance of interconnectivity and reciprocity in scaling large, complex systems.

In web3, we are witnessing a similar phase of growth and complexity. The growing pains experienced today with a number of rollups and Layer 2 solutions on Ethereum has led to the fragmenting of users and liquidity and a disconnected user experience, reminiscent of early Internet challenges. Let’s dive into what those problems are and how Avail is helping solve them.

Current Landscape of the Modular Ecosystem

Rollups have become the recognized solution for scaling blockchains, increasingly dominating the execution layer of the technology. As roll-up technology matures and evolves, incorporating new, more efficient, and application-specific advancements, they are becoming a standard feature across various blockchain platforms. This growing trend is evident as we observe rollup stacks being increasingly adopted by multiple chains.

However, this development raises significant concerns about user experience in an environment where hundreds of chains exist, each hosting a myriad of user interactions.

The major L2 players, in their efforts to address these challenges, have each crafted their unique solutions. Unfortunately, this has led to the creation of growing pains in the form of further fragmentation.

While these ecosystems allow for smooth and integrated operations within their boundaries, friction ensues when moving between them, posing a hurdle to the seamless interoperability that users seek in the broader blockchain landscape.

Validity Proof based DA as the Foundation of the Stack

Based on first principles thinking, the base level of the unified stack needs to be a DA layer built with Data Availability Sampling based on validity proofs.

A DA layer is the most minimal layer of a blockchain possible because it’s a consolidation point for both consensus and ordering. While a DA layer requires other components (i.e. execution) to build a blockchain on top, it acts as the root of trust, ordering transactions and reaching consensus on the order of those transactions.

When the execution layers check ordering and DA guarantees from the base layer, the most efficient and trust minimized way to perform it is by sampling against commitments of ordering. By making the commitments validity proof based makes it the irrefutable source of truth. This is precisely the role KZG commitments play in Avail DA. However, in order to get guarantees of availability against the committed ordering, the clients would either have to download the entire data or perform sampling over erasure coded data to provide high confidence of availability. The former forces the client to run full nodes of the base layer and hence Avail enables light clients which perform DAS on the erasure coded data to verify availability efficiently.

Validity proof powered DAS is the superpower of Avail DA, which is the fulcrum over which we architect the Unification Layer.

The Unification Layer

Avail's ecosystem is designed to offer a superior experience for both users and developers, balancing the essentials of scalability, interoperability and security without compromise. The platform's structure is anchored in three primary layers:

Unopinionated Foundational Data Availability (DA) Layer
- This layer serves as the universal foundation that any blockchain can utilize to enhance its scalability and security. Avail DA’s simple yet powerful design is flexible, accommodating various chains without imposing specific constraints or biases on them.
Nexus Layer for Interoperability and Sequencer Selection
- The Nexus layer is the coordination component of Avail, which provides a permissionless framework for inter-rollup messaging.
- This layer is pivotal in crafting a seamless user experience across multiple scenarios, whether users are engaging with a single rollup, navigating multiple rollups within Avail, or interacting with chains in external ecosystems.
Fusion Security Layer
- Fusion allows the Avail base chain to incorporate non-native tokens alongside the Avail native token to secure the Avail platform, enabling a robust security layer.
- Fusion security will provide increased security and added utility for tokens of rollups built on Avail.
- Fusion will also help bring and lock more liquidity from other blockchains into the Avail ecosystem.

Avail DA

The DA layer is a core foundation of any blockchain network acting as a scalable and shared source of truth. It ensures all the relevant data within the network is present each time a new block is produced, with nothing hidden or removed from the network, allowing it to continue operating.

While important, the DA Layer alone needs other layers to create a blockchain. Crucially, the execution layer which enacts blockchain state changes. The execution layer is being effectively scaled through rollups, but without an optimized DA Layer built to scale, DA quickly becomes the bottleneck.

How Avail’s DA Layer works

Avail’s DA Layer is a decentralized blockchain network. It produces and secures blockspace that other blockchains can use as their own ‘pluggable’ data availability layer.

Using a dedicated AppID, blockchains publish transaction data to Avail which gets committed and made available.

The data that is published on Avail’s blocks is validated by the Avail network, but not executed (as that’s what the execution layer is for).
Avail’s data availability blockchain can support any blockchain network.
Avail uses validity proofs so that developers and users don’t need to trust the Avail network that data is available; they can actually verify it for themselves.
Data published to Avail is extended through erasure encoding, adding redundancy to the data.
Avail ensures the data has a footprint in the Avail block header using KZG polynomial commitments.
Once new blocks are finalized by validators, validity proofs can be used to guarantee data availability immediately after finalization.
Avail’s nominated proof of stake (NPoS) blockchain was built using the Polkadot SDK, and it will support up to 1,000 external validators.

Data Availability Sampling (DAS)

DAS is a core concept used to efficiently validate that data is available on the Avail blockchain by other networks, wallets, and users.

Using Avail’s Light Client, a user can quickly sample the Avail blockchain to verify a validity proof that proves the data is available. This efficient and lite code can be easily implemented across different products and devices, including a user’s phone and in the browser.

Ability to Scale

With Avail light clients and Data Availability Sampling, Avail supports expandable blocks allowing it to increase the size of blocks and support more blockchains as demand grows.

This is due to the unique features of light clients and DAS.

The Avail light client can sample a subset of the data in the network and validate the availability of that data. Light clients can quickly generate data availability guarantees very close to 100% with 8-30 samples providing comparable security guarantees to a full node. When replicated across a network of light clients, the light client network itself begins to form a replica of the current state of the chain, adding redundancy to the network as a whole. You end up with a copy of the Avail network both with validators and with the network of light clients.

With more light clients, the network has more capacity to sample data. With more DAS happening within the network, the coverage from the Light Client network grows large enough to collectively sample larger blocks. This leads to a positive feedback loop where blockspace actually increases the more light clients there are in the network. Contrary to monolithic blockchain designs which reduce the amount of blockspace available as demand increases, Avail’s DA layer will be able to scale DA blockspace with demand.

Maintaining Order

Maintaining an order of transactions is the minimal layer on which blockchain systems can be built. With each new Avail block comes a new order of transactions for the blockchain on top.

While the responsibility for maintaining the order of published data lies with the Avail DA validator set, the onus of verification is outsourced to users. To ascertain the correctness of any chain, a user must:

Verify Data Availability: This involves checking DA against an established order. Users can do this by performing Data Availability Sampling (DAS) against the order finalized by the Avail validator set. Avail’s use of validity proofs in Avail DA provides finality guarantees of around 60 seconds which is one of the fastest offered by DA layers today.
Verify Execution: This is achieved by validating the rollup-specific proof of execution.

Practically, these verification processes will be integrated into user wallets by default. This integration ensures that users are not burdened with the technicalities of verification or the need to run specialized software. Such an approach not only simplifies the user experience but also maintains the robustness and integrity of the interactions within the Avail ecosystem.

Avail Nexus

The ability to easily spin up rollups means there will be thousands of rollups. That means, the end-user experience of interacting with these rollups will be fragmented. Blockchain user's experience already suffers in the multichain world with a few chains and by increasing the number further without having fundamental changes in composability will lead to even bigger issues. That is why we are building Avail Nexus, which acts as the verification hub unifying the rollups, using Avail DA as the root of trust.

Avail Nexus is a custom ZK coordination rollup on top of Avail that consists of:

Proof aggregation and verification layer
Sequencer selection/slot auction mechanism

Nexus also submits the aggregated proof periodically to Ethereum and the Avail DA layer for verification. A custom module within Avail DA verifies the aggregate proof.

Background

Rollups are important to solve scalability issues. A monolithic chain will always be a bottleneck when it comes to onboarding more users. In an ideal future, each dapp would be its own roll-up, only limited by its own performance. But, the most important piece to this future is the seamless communication between them. A modularised world would only be as efficient as the messaging protocol that dictates cross-rollup communication.

Cross-rollup communications require bridges, and minimal trust is important for these bridges if it is to be comparable to the security that a monolithic chain offers. When the bridges are between rollups on the same DA Layer, then they are not crossing trust and security zones, as they all depend on the same consensus and economic security that dictates the ordering (with nuances), but for the bridges to be trustless, it is important for a rollup to know if the executions were done correctly, and it has to verify this statement itself so it does not have to trust someone else to provide these guarantees. This brings us to an important set of questions.

How will state verification happen without being a bottleneck?
How will rollups understand messages or events taking place on other rollups in the ecosystem, and can the messaging be asynchronous?
How will rollup A know the canonical order of rollup B?
Do the security assumptions change across rollups?
How many bridges are required, even if they are generic?

Avail Nexus aims to solve these questions at scale.

Design

When a blockchain wants to talk to another chain, for its own safety, there are two important questions it needs to answer.

What is the canonical and final order of the chain?
Are the executions valid?

Consensus determines the canonical order of a chain, and a common DA Layer offers uniform security in this aspect. The DA layer provides rollups consensus for the order of its transactions, and for rollups with the same DA layer, this is game-changing. The order of transactions of all rollups including its own is determined by the same consensus, and so even if there is a re-org, the order of all rollups is then dictated by this re-org.

However, determining whether executions are valid is a difficult problem even for rollups with a common DA Layer.

Let us imagine the case of an NFT rollup wanting to confirm payment on a payments rollup. The cross-rollup communication would roughly look like this:

The lines in red signify the flow of information from the payments rollup to the NFT rollup. Although this looks simple enough, the complexity blows up as more rollups join the ecosystem.

Even for a few rollups that want to talk to each other, the constructions would end up looking like this, with unique bridge instances between them, performing all of the above functions.

The challenge becomes more pronounced when we recognize that each rollup may have unique state transition functions, with design choices tailored to its specific domain. And validation of executions might depend on game theory, incorporating fraud proofs, or validity proof systems relying on zero-knowledge proofs (ZK proofs). Even within the ZK rollups, the proof systems themselves may exhibit variation, ranging from Groth16 to PLONK.

The rollups do not really need to know the details and what the state transition functions of other rollups are but just need to be able to verify that the executions of these state transition functions were performed faithfully, and need to be able to understand certain results of these executions that are relevant to them. Additionally, by verifying a single proof if they could essentially verify the validity of all executions that could ever be relevant to them, that would be game-changing. A verification hub that enables certain interfaces for cross-chain communication and events, and behind it abstract domain-specific details of rollups, offers exactly that. Avail Nexus is an embodiment of this idea.

Proof Aggregation

ZK proofs come with a very important property that they are concise. Verification of a statement requires much fewer computational resources, than arriving at the statement itself. In the context of blockchains, state verification is much easier compared to arriving at a certain state by performing state transition functions. Added to this, the possibility of being able to prove that n proofs are valid with a single proof (aggregation) is groundbreaking. We now no longer have to verify validity proofs of rollups individually, but verification of a single aggregated proof verifies all the validity proofs of participating rollups up to that point, which translates to verifying the validity of the entire history of all participating rollups.

Avail Nexus, within its runtime, verifies all validity proofs that are submitted to it on certain conditions being met and creates a single succinct proof of having done that. This proof is then submitted to the Avail base layer, which is verified by all nodes. Essentially it becomes an enshrined settlement layer. Any participating rollup can perform state verification on any other rollup by verifying this single succinct proof, and most importantly, through L1 bridges, this world could then have access to the world outside.

The implementation details are subject to change, but the aggregation could be performed by verifying the proofs inside of a Zeth instance or using more target proof aggregation tools like the one built by Nebra.

An important detail is that Avail Nexus itself is a ZK rollup. Each aggregated proof is in the rollup world a new block or a batch. The headers are commitments of a certain state that stores Nexus previous headers of rollups, and a list of all events generated by rollups up to that point. Also, this allows for even optimistic rollups to participate. Optimistic rollups will be able to submit their receipts and state roots to Nexus, and the fraud proofs will be ZK proofs of fraud, allowing for shorter challenge periods. The receipts (or events) generated by the optimistic rollups would be included in the Nexus state on no fraud proofs being submitted within the challenge period.

Going back to the example of NFT and payments, the implementation would now look like this.

The parts in orange depict the flow of information between the two chains. The receipt root provided by Avail Nexus depicts the root of a tree built over all events generated by all rollups in history. It is important that non-inclusion proofs are possible to be proven for events. In the current implementation, the events are all stored as a sparse Merkle tree, with the hash of the event being its index, and Nexus enforcing that each event is unique.

Synchronously composed applications are accurately predictable and easier to build. However, as use cases expand, and UX requirements advance, synchronous composition does not offer enough flexibility. In monolithic chains or in a single rollup, applications live in the same system, and it is easy to have both constructions. Any communication between applications needs to happen within block times, but advanced constructions like futures can be used to store future commitments, and on those futures being realized, certain pre-committed executions can be done (callbacks as we know them in web2).

As we move from a single-chain world to a modular world with many rollups, the need for asynchronous composability becomes more obvious. It is not ideal for a chain to halt, simply because it is waiting for a payment to be done on another chain. Any sort of communication needs to be able to take place across multiple blocks. Along with this, for any asynchronously composed systems, atomic properties become important. All partly completed executions need to be reverted on an external condition failure. These are the challenges that Avail Nexus solves, as demonstrated above. Avail Nexus provides a unified experience in the modular world via proof aggregation. This allows for custom implementations like futures to be stored, and completion of a future to be proven across systems. (In such a construction, the rollup itself is not reverted due to an external failure, but the rollup progresses to its new state, where the future is canceled.) Essentially, an NFT could be transferred to someone only on payment being completed on the payments rollup, just like the UX we are all familiar with in the web2 world.

Ordering and Execution Verification

The rollups on Ethereum today bear the cost of using Ethereum as DA. They pay somewhere around $1300-$1600/MB or even beyond when gas fees rise. Hence, we see that many chains want to use Avail as the DA layer for their chains. This reduces their operating cost by 70-90%, depending on their construction choices and batch sizes. They still post their proofs on Ethereum and use it as their settlement layer. In reality, they just use Ethereum as their canonical bridge.

While we will keep seeing this trend over the next few months, practically speaking, if there are 100s of rollups settling on Ethereum by themselves per block, Ethereum’s execution will not be able to scale again. We would want Avail validators to keep having a bridge on Ethereum to be able to access the users and liquidity there. But we will amortize the cost of bridging by doing it through Avail Nexus.

The rollups participating in Avail Nexus will have their proofs aggregated and verified by Avail. The verified proofs will then go to Ethereum through the Vector bridge, which is a ZKP-based proof of consensus bridge from Avail to Ethereum. Ethereum would still be able to verify the aggregate proof of execution and does not have to rely on the Avail validators, except for DA and order, the same assumptions they have for Validiums.

The only difference now is that Avail Nexus becomes the source of truth for the rollups and Ethereum utilizes that for its assurances. The design reduces the cost of execution on Ethereum from verifying one proof per validium to verifying a single proof for all rollups participating on Avail Nexus. The rollups can then exit on Ethereum as they would have done normally.

Avail Fusion

A unifying layer needs unified security. The biggest value proposition for spinning up a new rollup rather than creating a separate L1 is the ability to inherit security from the base layer. For Avail to be the web3 coordination layer, it needs to be extremely secure - as the crypto-economic guarantees along with cryptographic ones will ultimately define the Avail ecosystem.

To cater to that, we are developing Fusion Security, which takes the native assets of the most mature ecosystems such as BTC, ETH and more and allows them to contribute to the Avail consensus. Not only that, it allows the new rollup tokens to also play a role in securing the base layer which empowers them.

Fusion Security is additive crypto economic security for the unified vision of Avail.

In the context of the Avail platform, Fusion Security enables the inclusion of foreign tokens other than Avail's native token inside the Avail DA consensus.

Fusion allows two new categories of tokens to be added to Avail’s staking pallet, thereby enhancing the crypto-economic security of its entire ecosystem:

Established Cryptocurrencies: Tokens like BTC, ETH, and SOL, among others.
Emerging Rollup Tokens: New tokens created on Avail, limited to a small percentage of the total stake to bootstrap their utility.

This approach will progressively bolster Avail's cryptoeconomic security and marks one of the first instances where foreign tokens like ETH and BTC are utilized to power consensus on a different blockchain.

Currently, the Fusion prototype being developed for Avail follow two different approaches:

Staking Module on Avail Blockchain: This module will support multiple foreign tokens through the assets pallet in the Avail node.
Staking Module for Asset Conversion: This will enable the conversion of foreign assets to Avail’s native token, maintaining a price conversion mapping at the time of conversion.

The final selection between these approaches will be determined after careful consideration of economic risk modeling, inflation constraints, and other critical factors. This initiative represents a significant step in the integration and interoperability of various cryptocurrencies within the Avail ecosystem.

The inspiration for Fusion came from:

Eigenlayer, that is pioneering the restaking of ETH in services that operate independently of Ethereum's consensus mechanism or full validator set
Babylon Chain, that is creating a platform that allows the use of BTC (Bitcoin) for security across different blockchain networks
Osmosis, that pioneered mesh security that allows a chain to borrow economic security from other chains

Fusion is a construction that is similar to, but also different from these approaches. It borrows economic security from other assets, but penalizes both safety and liveness failures in the Avail consensus.

Avail Token

The Avail token will drive a circular economy within the network

The DA, Nexus, and Fusion Security layers will be secured through Avail token staking
Transaction and bridging fees are paid in Avail's native token, ensuring a self-sustaining network with incentives aligned across all participants

Avail token holders will form the base community for many projects looking to build on Avail DA and leverage the benefits of the Avail ecosystem.

The Unification Vision

In a landscape populated by hundreds of chains, each with its own security and interoperability considerations, Avail aims to be the platform offering a seamless, unified experience across the entire ecosystem.

This platform will provide a single-user interface, allowing users to easily manage all their assets across various blockchains. When a user wishes to execute a transaction, they simply need to sign an intent on the interface.

The backend of the Avail Platform then springs into action, utilizing Avail Nexus and its support for asynchronous message passing. This system communicates with other chains across the ecosystem to fulfill the user's request, ensuring a smooth and efficient, unified web3 user experience.

Learn more about Avail on Discord, Twitter, GitHub, Our Blog