The founder personally describes Avail’s “Trinity” solutions and vision

Author: Anurag Arjun, co-founder of Polygon and founder of Avail; Translation: xiaozou@金财经

On February 26, 2024, Avail  announced that it had received a US$27 million seed round led by Founders Fund and Dragonfly  Financing, other well-known venture capital firms also participated, including SevenX, Figment, Nomad Capital and a number of angel investors. This round of funding will be used to fuel the development of Avail Trinity - a three-phase roadmap that unifies the entire web3 ecosystem.  

Polygon co-founder and Avail founder Anurag Arjun published an in-depth discussion of the background and origin of "Avail Trinity" and how Avail solves the challenges faced by today's ecosystem. User fragmentation and scalability issues.

1. Overview

The permissionless environment of Web3 has given rise to a variety of breakthrough technologies. Together they have promoted today's booming ecosystem, which still has a lot of room for development. There are many technical challenges that need to be overcome to achieve the scale required for mass adoption, and the ecosystem has built a number of innovative solutions based on the web3 technology stack. However, the difficult problem that still needs to be solved is to bring all these technologies together and operate as a whole for the end user, while maintaining the decentralized spirit of the ecosystem.

Transactions across ecosystems are more complex than expected, leading to unnecessary fragmentation. User adoption efforts should be geared toward attracting new users to the web rather than focusing on the existing web3 community.

To solve all these problems, Avail is accelerating the unification of web3 through Avail Trinity, a roadmap divided into three phases that can be used by anyone The ecosystem provides end users with a secure, scalable and seamless web3 experience.

In this article, we will delve into the background and theory of Avail Trinity and show how it solves the user fragmentation and scalability issues faced by today's ecosystem of. We'll show how Avail DA is the perfect foundation for many rollups that crave efficient data availability, and lays the foundation for seamless implementation of user intent across the web3 ecosystem through Avail Nexus, a permissionless coordination hub. Avail Fusion Security completes Avail Trinity, solving the growing need for shared security and making the thriving web3 unified ecosystem even stronger.

2. Foreword

If you have ever tried to conduct transactions across multi-chain networks, then It becomes clear that the corresponding experience is not ready for mass adoption.

With a very deep technical understanding of the blockchain architecture, you can start to solve this long-term problem. Going back through first principles, we can derive the technical foundation needed to create a unified experience on the blockchain. This foundation will connect separate L2 rollup networks and L1 while still enabling permissionless, decentralized innovation and experimentation by developers across the ecosystem.

Rollup was developed as part of a solution to the scalability challenge by processing transactions off-chain and then packaging multiple transactions into a single on-chain transaction . While Rollup effectively reduces fees and enhances Ethereum's scalability, it introduces new complexities:

● Due to limited availability , the demand for more block space leads to rising costs.

● The proliferation of L2 ecosystems has exacerbated market fragmentation, further hampering user experience and economies of scale.

With these issues resolved, the scalability and interoperability potential of blockchain systems, which has been stagnant for years, can finally be realized.

3. Avail solution

Avail is leveraging the asynchronous messaging principle (similar to the (using the same principles as scaling applications) to scale the blockchain, and now is the perfect time to build.

Avail Trinity consists of the basic data availability (DA) layer, the Nexus interoperability layer and the Fusion Security network layer.

● The DA layer is built specifically for data availability and is highly optimized. It is the lowest layer of the blockchain and has the capabilities needed to build cross-ecosystem interoperability. minimal functionality.

● Nexus, as a lightweight but powerful ZK rollup running on Avail, supports cross-rollup and cross-ecosystem settlement.

● Fusion Security can bring together the cryptoeconomic security of many tokens to serve and protect the Avail network.

Avail's mission is to simplify the rollup experience and provide an efficient unified platform for users and developers across all different ecosystems.

This vertical integration model is designed to solve today's increasing troubles and user fragmentation problems, allowing rollup to seamlessly touch the entire blockchain field. Users and liquidity.

Avail's vision is to provide a consistent user experience in a flexible modular blockchain ecosystem, drawing on the experience of Web2 to innovate in Web3. By combining advanced technology, a clear roadmap and rapid execution, Avail is building more than just a product. It is ushering in a new phase in the blockchain space, paving the way for an era of better scalability and seamless user interaction. Flat road.

4. Background and inspiration

What can we learn from web2?

How do applications on the Internet truly achieve scale? Asynchronous microservices.

The Internet is not one giant world computer, but a series of interconnected computers that perform specific tasks based on business use cases and communicate with each other when needed.

Amazon is a set of related microservices that specializes in e-commerce. Visa operates a series of microservices that process payments.

● When a user clicks the purchase button of a product on Amazon, a call from the browser to the Amazon product microservice is triggered.

● Then the Visa microservice will be called to send the payment page to the user.

● Once the user fills in the payment details, another verification payment request is sent to the Visa microservice.

● Once the payment is verified, a callback is sent to the Amazon product microservice to let the user know that the product has been purchased and the payment has been completed.

If there is a holiday promotion day like Black Friday, Amazon and Visa microservices will expand their scale to meet more Internet needs.

The point is that the Internet can only scale to such a large scale through asynchronous microservices. So will blockchain.

How do we achieve this in web3?

UPI is a good example for learning. It is one of the largest payment systems in the world in terms of user volume and transaction volume. Currently, UPI processes over 10 billion transactions every month, which is a testament to the sheer scale of the system.

UPI is a system that enables customers from different banks to interact. But it wasn't that successful when it first launched. Banks were initially very hesitant to join the system - the government did not make it mandatory to join UPI. The main concern expressed by banks is that if they support UPI transactions, the end result will be the transfer of funds from customer accounts to other banks (liquidity outflow).

The principle of reciprocity is used to solve this problem. The principle of reciprocity replaced economic incentives and was used to convey the idea that banks can only join UPI to obtain the "pay-in" of other bank customers if they allow "pay-out". ).

Although this is an example of a permissioned setup (a bank in web2), web3's permissionless unified layer should still have reciprocity embedded in it, which is important for the entire It is beneficial and harmless to the ecosystem.

The principle of reciprocity helps banks open their doors to their customers and wallets and collaborate effectively to ensure the end customer has the best user experience possible.

Such cooperation is beneficial to the ecosystem. But this is only possible if the underlying technology uses the right primitives to enable cooperation. UPI has these, and we designed Avail to bring the experience of web2 systems around the world into web3.

Bringing web2 experience into web3

The development of the Internet provides the blockchain world with gained valuable insights. The expansion of the Internet is mainly achieved through asynchronous microservices. Asynchronous microservices are a network of interconnected computers. Each computer performs specific tasks and communicates when needed.

● Platforms such as Amazon and Visa are examples of this model, which provide a series of specialized microservices for e-commerce and payment processing respectively.

● These services scale independently to meet demand, demonstrating the power of decentralized asynchronous operations.

● The success of systems like UPI (Unified Payments Interface) further highlights the importance of interconnected reciprocity in scaling large and complex systems.

In web3, we are witnessing a similar phase of complexity and growth. Today, there are many rollup and Layer 2 solutions emerging on Ethereum, which leads to fragmentation issues of users and liquidity, and a disconnected user experience that is reminiscent of the challenges of the early Internet. Now let's take a closer look at these problems and how Avail helps solve them.

The current status of the modular ecosystem

Rollup has become a recognized blockchain scaling solution . As rollup technology matures and develops, and new advanced technologies that are more efficient and application-specific continue to be integrated, they are becoming a standard feature of various blockchain platforms. We see that rollup is increasingly gaining multi-chain adoption, and this development trend is obvious.

However, this development raises significant concerns about user experience, as there are hundreds of chains, each with countless user interactions.

Major L2 players have developed their own unique solutions in response to these challenges. Unfortunately, this leads to further fragmentation issues.

While these ecosystems allow for smooth integrated operations within their boundaries, operating across ecosystems creates friction that creates problems for users within the broader blockchain. The search for seamless interoperability in the chain space poses an obstacle.

DA layer based on validity proof as the basis

Thinking based on first principles, unified The bottom layer of the stack needs to be a DA layer built using data availability sampling based on validity proofs.

The DA layer is an essential layer in the blockchain because it is the integration point of consensus and ordering. While the DA layer requires other components (i.e. execution) to build the blockchain, it acts as the root of trust, ordering transactions and reaching consensus on the order of those transactions.

While the execution layer checks ordering and DA guarantees from the base layer, the most efficient and trust-minimizing execution method is to sample the ordering commitments. Make a promise an irrefutable source of truth by basing it on proof of validity. This is exactly the role KZG promises to play in Avail DA. However, to obtain availability guarantees against submitted orders, the client must either download the complete data or perform sampling of the erasure-coded data to provide high-confidence availability. The former forces clients to run a base-layer full node, so Avail enables light clients that perform DAS on erasure-coded data to efficiently verify availability.

The DAS supported by the validity proof is the superpower of AvailDA, and it is the fulcrum on which we build AvailTrinity.

Avail Trinity

The Avail ecosystem is designed to provide a superior experience for users and developers , balancing the three essential elements of scalability, interoperability and security without compromising. The structure of the platform is mainly composed of the following three layers:

● Basic Data Availability (DA) layer

This layer is a universal base layer that any blockchain can leverage to enhance its scalability and security. Avail's simple yet powerful design is flexible and adapts to the needs of each chain without imposing specific constraints or biases.

● The Nexus layer for interoperability

The Nexus layer is the coordination of Avail Component, which provides a permissionless framework for rollup internal messaging.

This layer is critical to creating a seamless user experience across multiple scenarios, whether the user is using a single rollup or across multiple rollups in Avail , or interact with chains in external ecosystems.

● Fusion security layer

Fusion allows the Avail base chain to combine non-native tokens with Avail native tokens are combined to secure the Avail platform, enabling a strong and reliable security layer.

Fusion Security will provide higher security and more utility for rollup tokens built on Avail.

Fusion will also help bring more liquidity from other blockchains into the Avail ecosystem and lock it away.

5. Avail DA

The DA layer is the core foundation of the blockchain network and serves as a reliable Extended shared source of truth. It ensures that every time a new block is born, all relevant data in the network is there and nothing is hidden or deleted, allowing it to continue functioning.

Although important, the DA layer requires other layers to create the blockchain, especially the execution layer that determines changes in the blockchain state. The execution layer is efficiently scaled through rollup, but without an optimized DA layer, data availability can quickly become a bottleneck.

(1) Avail DA layer working principle

Avail DA layer is a Centralized blockchain network. It creates and secures block space that other blockchains can use as their own data availability layer.

Using a dedicated AppID, the blockchain publishes transaction data to Avail, which is then submitted and becomes available.

● The data published on the Avail block is verified by the Avail network but not executed (because this is the job of the execution layer).

● Avail’s data availability blockchain can support any blockchain network.

● Avail uses proof of validity, so developers and users do not need to trust the Avail network to confirm that data is available; they can verify it themselves.

● The data published to Avail is expanded through erasure coding, thereby increasing data redundancy.

● Avail uses KZG polynomial commitment to ensure that data leaves traces in the Avail block header.

● Once a new block is finalized by a validator, validity proofs can be used to ensure that the data is available immediately after the block is confirmed.

● Avail’s Nominated Proof-of-Stake (NPoS) blockchain is built using the Polkadot SDK and will support up to 1,000 external validators.

(2) Data Availability Sampling (DAS)

DAS is a core concept. Used to effectively verify data available to other networks, wallets and users on the Avail blockchain.

Using Avail's LightClient, users can quickly sample the Avail blockchain to verify validity proofs proving that data is available. This efficient and clean code can be easily deployed across different products and devices, including users’ phones and browsers.

8. Scalability

Avail supports scalability through Avail light client and data availability sampling Blocks, which can increase the block size and support more blocks as demand grows.

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

The Avail light client can sample a subset of data from the network and verify the availability of that data. The light client can quickly generate close to 100% data availability guarantee through 8-30 samples, providing security protection equivalent to that of a full node. When replicating across a light client network, the light client network itself begins to form a copy of the current state of the chain, adding redundancy to the entire network. Eventually, you will have a copy of the Avail network with validators and light client networks.

With more light clients, the network has more powerful data sampling capabilities. As more DAS occurs in the network, the coverage of the light client network will become large enough that larger blocks can be sampled. This will create a positive feedback loop, where as the block space becomes larger, the number of light clients in the network will also increase. Contrary to monolithic chain designs where available block space decreases as demand increases, Avail’s DA layer will be able to expand DA block space as demand increases.

9. Maintain ordering

Maintaining transaction ordering is a basic requirement for building a blockchain system . With each new Avail block, there will be a new ordering of transactions on the blockchain.

Although the responsibility for maintaining the ordering of published data lies with the Avail DA validator set, the verification responsibility is outsourced to the user. In order to determine the correctness of the chain, the user must:

● Verify data availability: This is to check the data availability according to the established ordering. Users can achieve this by performing Data Availability Sampling (DAS) based on the ordering determined by the Avail validator set. Avail achieves finality of approximately 60 seconds using validity proofs in Avail's DA, arguably the fastest finality guarantee available with a DA layer today.

● Verified execution: This is achieved by verifying the rollup-specific proof of execution.

In fact, these verification processes will be integrated into user wallets by default. This integration ensures that users do not need to possess authentication skills or run specialized software. This approach not only simplifies the user experience, but also maintains the reliability and integrity of interactions within the Avail ecosystem.

6. Avail Nexus

Being able to easily support rollup means that it will be welcomed Come the arrival of thousands of rollups. That is, the end user experience interacting with these rollups will be fragmented. In the multi-chain world, the experience of blockchain users has been affected to a certain extent. If the number of rollups is further increased without changing composability, more serious problems will arise. That's why we're building Avail Nexus, which serves as a unified verification center for rollups, using Avail DA as the root of trust.

Avail Nexus is a custom ZK coordination rollup based on Avail, including:

●  Proof aggregation and verification layer

● Sorter/slot auction mechanism

Nexus also regularly submits aggregated proofs to the Ethereum and Avail DA layers for verification. Aggregate proofs are verified by a custom module in AvailDA.

Background

Rollup is crucial to solving scalability issues. Monolithic chains are always a bottleneck when it comes to attracting more users. In an ideal future, each dapp is its own rollup, limited only by its own performance. However, the most important part of this future is seamless communication between dapps. A modular world will surely be as efficient as messaging protocols that dictate cross-rollup communication.

Cross-rollup communication involves cross-chain bridges. If the security provided by the monolithic chain is to be comparable, then the trust for these cross-chain bridges is minimal. ization is very important. When bridging between rollups on the same DA layer, there is no cross-trust and security zones involved, as they both rely on the same consensus and economic security to decide ordering (there are subtle differences), but for trustless bridging It is quite important that rollup needs to know whether the execution is correct, and it must verify it itself so that it does not have to trust others to rely on it to provide these guarantees. This raises a series of important questions.

● How to perform state verification without becoming a bottleneck?

● How does Rollup understand the messages or events on other rollups in the ecosystem? Can message delivery be implemented asynchronously?

● Rollup How does A know the canonical ordering of rollup B?

● Do the security assumptions change between different rollups?

● How many cross-chain bridges are needed, even if they are universal?

Avail Nexus aims to solve these problems at scale.

Design

When one blockchain wants to talk to another chain, in order For its own security, it needs to answer two important questions.

1.  What is the specification and final order of the chain?

2. Is the execution effective?

Consensus determines the canonical order of the chain, and the universal DA layer provides unified security in this regard. The DA layer provides Rollups consensus for their transaction order, which is a game-changer for Rollups with the same DA layer. The transaction order of all rollups (including its own rollup) is determined by the same consensus, so even if there is a reorganization, the order of all rollups will be determined by that reorganization.

However, even for Rollup with a public DA layer, determining whether the execution is valid is a difficult problem.

Let's imagine a situation where an NFT Rollup wants to confirm a payment on a Rollup  Cross-Rollup communication is roughly as follows:

The red line represents the information flow from payment Rollup to NFT Rollup. Although this seems simple, the complexity increases as more Rollups join the ecosystem.

Even for some Rollups that want to communicate with each other, the structure will end up looking like this, with unique bridge instances between them that perform all the functions mentioned above.

The challenge becomes even more apparent when we realize that each Rollup may have a unique state transition function, with design choices tailored to its specific domain. The verification performed may depend on game theory, combined with fraud proofs or a validity proof system relying on zero-knowledge proofs (ZK proofs). Even in ZK rollups the proof system itself may exhibit changes from Groth16 to PLONK.

Rollup  does not really need to know the details of other Rollup and what the state transition functions are, but only needs to be able to verify whether the execution of these state transition functions Execute truthfully and need to be able to understand these executions as they relate to them. Additionally, by verifying a single proof, they can essentially verify the validity of all executions associated with them, which would be a game changer. The Validation Hub provides exactly this by enabling certain interfaces for cross-chain communication and events and abstracting the domain-specific details of Rollup behind it. Avail Nexus  is the embodiment of this philosophy.

Aggregation proof

ZK Prove that there is a A very important feature is simplicity. Verifying a statement requires far fewer computational resources than deriving the statement itself. In the context of blockchain, state verification is much easier than reaching a certain state by executing a state transition function. Beyond that, the possibility of being able to prove that n proofs are valid through a single proof (aggregation) is groundbreaking. Now, instead of verifying the validity proofs of Rollup  individually, verifying a single aggregate proof verifies all validity proofs participating in Rollup  up to that point, which means verifying all the validity proofs participating in Rollup  Validity of the entire history.

Avail Nexus As it runs, it verifies all validity proofs submitted to it if certain conditions are met, and creates a concise proof to prove that this has been done. This proof is then submitted to the Avail base layer for verification by all nodes. In essence, it becomes a sacred settlement layer. Any participating Rollup can verify the state of any other Rollup by verifying this concise proof, and most importantly, this world has access to the outside world through the L1 bridge.

Implementation details may change, but this can be achieved by verifying the proof inside a Zeth instance or using a more targeted proof aggregation tool such as Tools built by Nebra) to perform aggregation.

An important detail is that Avail Nexus itself is a ZK rollup. Each aggregated proof is a new block or batch in the Rollup world. A block header is a commitment to some state that stores the Nexus' previous Rollup block header, as well as a list of all events generated by Rollup up to that point. Additionally, this allows even optimistic Rollups to participate. Optimistic Rollup will be able to submit its receipt and state root to Nexus and the fraud proof will be ZK fraud proof, shortening the challenge period. If no proof of fraud is submitted during the challenge period, the receipt (or event) generated by the optimistic rollup will be included in the Nexus status.

Going back to the NFT and payment example, the current implementation looks like this.

The orange part describes the information flow between the two chains. The receipt root provided by Avail Nexus describes the root of a tree built based on all events generated by all Rollups in the history. Importantly, non-inclusion proofs can be proved for events. In the current implementation, events are all stored as a sparse Merkle tree, with the hash of the event as its index, and Nexus enforces that each event is unique.

Synchronically composed applications are more predictable and easier to build. However, as use cases expand and user experience requirements increase, synchronous composition does not provide enough flexibility. In a monolithic chain or a single Rollup, the applications are in the same system and it is easy to have both structures at the same time. Any communication between applications needs to occur within block times, but higher-level structures like futures can be used to store future promises, and when these futures are realized, certain pre- Submitted executions (we know them as callbacks in web2).

As we move from a single-chain world to a modular world with many Rollups, the need for asynchronous composability becomes even more apparent. It's not ideal for one chain to be stopped because it's waiting for a payment on another chain to complete. Any type of communication needs to be able to occur across multiple blocks. Beyond this, for any asynchronously composed system, atomic properties become important. All partially completed executions need to be resumed if external conditions fail. As demonstrated above, these are challenges that Avail Nexus solves. Avail Nexus delivers a unified experience in a modular world through converged proofs. This allows for custom implementations such as future storage and future-proofing completion across systems. (In this structure, the rollup itself does not recover from external failures, but the rollup enters a new state and is canceled in the future.) Essentially, the NFT can only be transferred to someone after the payment is completed. Pay for a rollup, just like the UX we're familiar with in the web2 world.

Order and execution verification

 rollups  on Ethereum today assumed the use Ethereum as the cost of DA. When Gas charges go up, they pay around 1300-1600 USD/MB or more. As a result, we see many chains looking to use Avail as the DA layer of their chain. This can reduce operating costs by  70-90% depending on their construction choices and batch size. They still publish proofs on Ethereum and use it as a settlement layer. In fact, they just use Ethereum as their canonical bridge.

While we will continue to see this trend in the coming months, in reality, if there are hundreds of Rollups per block, It resolves itself on Ethereum, and Ethereum execution will not be able to scale again. We hope that Avail validators will continue to build a bridge on Ethereum to be able to access users and liquidity there. But we will spread the cost of bridging through Avail Nexus.

Participation in Avail Nexus Rollup will be verified by Avail Rollup and its certification. Verified proofs will reach Ethereum via the Vector Bridge, a ZKP-based consensus proof bridge from Avail to Ethereum. Ethereum is still able to verify aggregated proofs of execution and does not have to rely on Avail validators, which is the same assumption as Validiums except for DA and order.

The only difference now is that Avail becomes Rollup's canonical bridge, while Ethereum uses the same bridge for guarantees. This design reduces the cost of execution on Ethereum from validating one proof per validation to validating a single proof for all Rollups participating in Avail Nexus. The Rollup can then exit on Ethereum like normal.

7. Avail Fusion

Unified layers require unified security. The biggest value proposition of building a new Rollup rather than creating a separate L1 is the ability to inherit security from the base layer. For Avail to be a web3 ordination layer, it needs to be extremely secure, as cryptoeconomic guarantees and cryptographic guarantees will ultimately define the Avail ecosystem.  

To meet this, we are developing Fusion Security, which uses native assets from the most mature ecosystems, such as BTC, ETH etc. , and allow them to contribute to the Avail consensus. Not only that, it allows new Rollup tokens to play a role in securing the base layer, thereby empowering them.  

Fusion Security  is additional cryptographic economic security designed to achieve the unified vision of Avail .

external tokens.  

Fusion allows two new classes of tokens to be added to Avail 's staking vault, enhancing the cryptoeconomics of its entire ecosystem Security:

● Mature cryptocurrencies: tokens such as BTC, ETH, and SOL.

● Emerging Rollup Tokens: New tokens created on Avail limited to a small portion of the total stake to bootstrap their utility.

This approach will gradually enhance Avail 's cryptoeconomic security and mark the beginning of leveraging external tokens such as ETH and BTC  One of the first instances of reaching consensus on different blockchains.

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

: left;">1. Staking module on Avail blockchain: This module will support multiple external tokens through asset trays in Avail nodes.

2. Staking module for asset conversion: This will enable external assets to be converted into Avail 's native tokens and maintained upon conversion Price conversion mapping.

The final choice of these methods will be determined after careful consideration of economic risk models, inflation constraints and other key factors. This move represents an important step towards the integration and interoperability of various cryptocurrencies within the Avail ecosystem.

Fusion is inspired by:

● Eigenlayer, pioneered the independent Re-staking ETH

● Babylon Chain, is creating a service that allows the use of  A platform for BTC (Bitcoin) security across different blockchain networks

● Osmosis, pioneering mesh security that allows one chain to secure data from other chains Borrowing Economic Security

Fusion is a construct similar to but different from these methods. It borrows the economic security of other assets but penalizes security and liveness failures in the Avail consensus.

8. Avail Token

Avail Token will promote the circular economy within the network

● DA, Nexus  and Fusion security layers will be protected by Avail token staking

● Transaction and bridging fees are paid in Avail 's native token, ensuring the network is self-sustaining and providing consistent incentives for all participants 

Avail Token holders will form the foundational community for many projects looking to build on Avail DA and take advantage of the Avail ecosystem.

9. Unified vision

In an environment composed of hundreds of chains, each Each chain has its own security and interoperability considerations, and Avail's goal is to be a platform that provides a seamless, unified experience across the entire ecosystem.

The platform will provide a single user interface, allowing users to easily manage all assets on various blockchains. When users wish to execute a transaction, they simply sign the intent on the interface.

The Avail platform's backend then springs into action leveraging Avail Nexus and its support for asynchronous messaging. The system communicates with other chains in the ecosystem to fulfill user requests, ensuring a smooth, efficient, and unified web3 user experience.