At a historical point of the infrastructure debate, rollups showed that data publishing costs were one of the key performance bottlenecks and a fundamental limiter of rollup throughput. As rollups are required to publish data such as transaction call data to a DA layer, prohibitively high data publishing costs meant that rollups were unable to post a large amount of data, and thus, could not scale rollup throughput. As a result, various DA layers with a much larger data publishing capacity built for a modular future have appeared. However, as demand grows, other DA solutions have tossed their hats in the ring, including EigenDA, Avail, and EIP 4844. Eventually, DA layers will likely become commoditized, if not already commoditized with existing solutions that are in production or multiple others with imminent launches. Thus the natural question is, what is the long term business viability of DA layers and how does one build a valuable product surrounding it?

The Problem

In a world with potentially thousands or tens of thousands of rollups, many are left wondering what the future of interoperability across rollups may be. Fragmented liquidity and a fragmented user experience due to a lack of rollup interoperability are a significant barrier to the everyday user. As Ethereum doubles down on a rollup-centric future and more protocols launch their own app-specific rollup, both for practical considerations and larger value capture, a modular world must be supported by effective and efficient communication between these modular blockchains.

The crux of cross-rollup communication and interoperability is the introduction of minimal new trust assumptions. General-message-passing protocols can be utilized and can promise eventual execution but often have censorship vectors and new trust assumptions. When it comes to ordering transactions, guaranteeing atomic execution across rollups, and more complex bundles of transactions across rollups, they fall short.

There are a few complex questions that a common “bridge” with minimal net trust assumptions has to answer. For example, how will rollup A know the canonical order of rollup B? How will multichain state verification happen without being a bottleneck? How will rollups understand events taking place on other rollups in the ecosystem and can the messaging be asynchronous?

Inter-rollup communication refers to the ability for chains to send messages between each other; more often than not, this message is the state of a chain. The state of a chain then usually determines the correct ordering and execution of transactions on other chains. Thus, there are two main questions that a rollup needs to answer when receiving messages (state) from other rollups. What is the canonical and final order of the rollup, and are the executions valid? Avail’s products aim to answer these questions and accelerate the unification of web3 through three core solutions: Avail DA, Avail Nexus, and Avail Fusion.

Avail DA

Based on the above problems that the modular future needs to tackle, the base level of the unified stack should be a DA layer that provides consensus for the order of a rollup’s transactions. Avail DA is such a solution:an optimized DA layer built with data availability sampling (DAS) based on validity proofs. A DA layer acts as the root of trust, ordering transactions and reaching consensus on the order of those transactions.

Avail DA provides a network that can ingest and order transaction data. This layer is dedicated to storing the data for a sufficient length of time (with validators being able to make their own choices about pruning) and guaranteeing its availability, which is crucial for rollups so that optimistic rollups have transaction data available to construct fraud proofs, and ZK-rollups have the state data available such that anyone can independently validate the chain.. With this state data, anyone can reproduce the rollup’s state and validate the chain themselves without the need to rely on full nodes. The DA layer ensures that every full node of the rollup does not need to execute transactions and thus, as a result, can be much more performant than the blockchain upon which it is built.

Avail uses DAS, like Celestia. However, unlike Celestia, Avail has a Nominated PoS consensus model with BABE/GRANDPA consensus and uses validity proofs generated through KZG commitments instead of fraud proofs to ensure the correctness of erasure coding. KZG commitments are commitments by a validator that erasure encoding was executed correctly. A validity proof can be generated based on the KZG commitment, which can then be used to verify the DA guarantees. These validity proofs allow anyone to verify that blocks are erasure encoded correctly without needing to download the entire data blob. This removes the need for an honest minority via mathematical DA guarantees, which is in stark contrast to fraud proof based DA layers. 

There are four types of nodes in Avail:

1. Full nodes: Full nodes download and verify the correctness of blocks, but do not partake in consensus. Full nodes are not needed but will run solely as an additional level of redundancy and resiliency.
2. Validator nodes: Validator nodes help the network come to consensus and achieve this by generating blocks, deciding on transaction inclusion, and maintaining transaction ordering. 
3. Light clients: Light clients let anyone interact with Avail DA without requiring a full node and without trust assumptions towards remote peers. This is accomplished by leveraging Data Availability Sampling (DAS) performed by the light client on every newly created block.
4. RPC nodes: RPC nodes expose an API for remote interactions, serving as a gateway for developers and external clients to interact with the Avail network.
    

The light client listens on the Avail network for finalized blocks and performs DAS on a predetermined number of cells on each new block. After successful block verification, block confidence is calculated for a number of cells in the matrix, with the number depending on the percentage of certainty the user wishes to achieve.

The transaction lifecycle on Avail DA is as follows:

1. Transaction Submission: As with most existing rollups, transaction call data is batched up and state roots are submitted to Avail DA, with a unique application ID that signifies the rollup origin.
2. Data extension and Erasure Coding: Transactions submitted to Avail DA are processed through erasure coding, where blocks are divided into n original chunks and extended to 2n, allowing for reconstruction from any n out of 2n chunks.
3. Commitment Creation: Avail DA takes the redundant data and applies KZG polynomial commitments to each block. These commitments serve as cryptographic proofs of the data’s integrity, ensuring that what is stored is accurate and tamper-proof. 
4. Block Propagation: Validators receive the blocks with the KZG commitments, and regenerate the commitments to verify their accuracy and reach a consensus on the block. 
5. Light Client Network: Light clients utilize DAS to verify block data integrity. This is achieved by checking KZG polynomial openings against the commitments in the block header for each sampled cell. This eradicates the need for reconstructing full KZG commitments or relying on fraud proofs.
6. Proof Verification: Light clients perform proof verification through cell-level proofs generated from the data matrix.
    

Avail utilizes two consensus mechanisms. The first, BABE, which stands for Blind Assignment for Blockchain Extension, serves as a block production engine. BABE functions autonomously and offers probabilistic finality, but in Avail’s case, is integrated with a finality mechanism known as GRANDPA, which stands for Ghost-based Recursive Ancestor Deriving Prefix Agreement. GRANDPA itself is a block finalization algorithm, and as such, has to be paired with a block production mechanism.

BABE operates on a slot-based algorithm, with each slot (block) lasting for twenty seconds. Each slot has a primary author chosen by a VRF function. However, in some instances, there may be no primary author. In such scenarios, BABE employs a round-robin system to designate secondary slot leaders.

BABE and GRANDPA were chosen as consensus mechanisms because Avail wanted to maintain a hybrid ledger. Most chains today choose safety over liveness, which means that every block needs to be finalized before the next block can be produced. However, during periods of network partition or if a large number of nodes fail to come to consensus, then the chain itself will suffer in terms of liveness. On the other hand, POW chains typically favor liveness over finality, and thus any finality is probabilistic. The question of whether a DA layer should favor safety or liveness is a topic for discussion. For example, based rollups should favor liveness because a user’s inclusion of transactions comes from the inclusion and the block production engine of the base layer. The base layer needs to at least give a soft guarantee of the ordering of the transactions otherwise the rollups built on top of it cannot function. On the other hand, safety is also important because, for example, for a shared sequencer, the finalization occurs over the rollups which are batched together and one sequencer determines the ordering across the rollups, hence not needing ordering guarantees from the DA layer. In this scenario, the DA layer is only relied upon for finality guarantees and that is where safety becomes important. There are various desired features of a DA layer depending on what type of rollup has been built on it. For example, censorship resistance comes from the base layer and thus its liveness is important. On the other hand, finality comes from the safety guarantees of the base layer which can be abstracted upon by the rollups.

In Avail’s case, GRANDPA is used as the finality gadget with BABE being used for block production, and importantly, GRANDPA finalizes over multiple blocks at the same time rather than individual blocks. Finality is obtained by consecutive rounds of voting by the validator nodes. With such a setup, Avail can offer the best of both worlds in terms of safety and liveness, achieving a time to finality of ~40 seconds (2 blocks) under normal circumstances with strong finality guarantees.

Avail uses a nominated proof-of-stake system to determine who can partake in consensus. In typical PoS systems, delegates have to think about their ROI when choosing which validator to delegate to, and this often has centralizing effects because one would always choose the validator with the highest amount of stake given that they would propose the most number of blocks (all else being equal), and in turn, receive the most rewards. For Avail, a slightly different leader selection algorithm is utilized. Leaders will be chosen in a manner that maximizes the decentralization of the network, whereby every nominator can participate and select a prioritized list of up to 16 validators over which they want to distribute their stake to, and the leader selection algorithm views all elected validators on an equal footing regardless of their stake size or the number of nominators supporting them. Validators with larger stakes and a higher number of nominators still hold a greater probability of being elected, however, irrespective of stake size, validators share an equitable workload.

There are a few core features of Avail DA that make it stand out from competitors. The first is the use of validity proofs instead of fraud proofs. When committing new blocks to the chain, Avail uses KZG commitments so that users do not need to trust Avail that the data is available, and users can verify it themselves. With the validity proof, it is computationally efficient to prove and verify data availability in a scalable manner. Once Avail finalizes in a time of around 40 seconds, which is much faster than the Ethereum base layer, this means that the validators have generated the KZG commitment and included them into the block header, with those blocks being finalized. From there, light clients can perform data availability sampling and verify samples against the header.

In fraud proof designs, the commitments in the header are not sufficient to verify that the samples are correct and that the block is correctly constructed (erasure coding was done correctly). In such a construct, light clients will sample, and are required to wait to see if any full node alerts of an invalid block, similar to fraud proof challenge periods in optimistic rollups. This means that a certain challenge period window needs to elapse before a light client can verify DA guarantees. In Avail’s validity proof based design, the KZG commitments make it possible to verify that the samples are correct and that the block is correctly constructed, which means that DA guarantees can be verified much faster and in a succinct manner in comparison to other fraud proof based DA layers. This is critical as interoperability solutions and rollup safety are often dependent on such DA guarantees, and the more timely these DA guarantees are verified, the more viable interoperability solutions and more certain rollup safety guarantees are.

If one wants to ascertain the state of the rollup, one needs two guarantees. The first is a guarantee of the correctness of execution, and the second is the guarantee of DA. In a scenario where a ZK rollup is built upon a fraud proof based DA layer, then when it comes to verifying the correctness of execution, one can rely on a validity proof or a ZK proof. However, when it comes to verifying the guarantee of DA, in a fraud proof based DA layer, there will be a challenge period during which a rollup would have to wait, and thus, a ZK rollup would be unlikely to use a fraud proof based DA layer since a conscious design decision was already made to avoid fraud proofs/challenge periods. KZG commitments and erasure coding enable Avail to avoid fraud proofs.

Erasure coding, specifically in the context of Avail DA, is a process in which data sent to Avail is duplicated and published within each block. All of Avail’s full nodes store entire erasure coded blocks, as a result, for a light client which doesn’t download the block but wants to know that the data is available, >50% of the block would need to be unavailable for the data to be suppressed. If >50% of the block is available, the light client can use the erasure coded (duplicated) data to reconstruct the missing data. This prevents a malicious actor from being able to hide any part of a block up to the redundant size (50%), and makes it much more likely that random sampling from light clients would catch gaps in the data. Effectively, erasure coding adds redundancy to the data availability.

Light clients also play a crucial role within Avail DA. The benefit of light clients is that they can run almost anywhere with incredibly minimal hardware requirements, for example, on your phone/within a wallet/through a browser extension, and thus, significantly lower the barrier to verifying data availability. This is achieved through data availability sampling performed by light clients on every newly created block. With a sufficient number of light clients and cells that are sampled, one can be sure with a high confidence factor that the data in the block is fully available. The larger the number of light clients, the stronger the data availability guarantee is. This allows execution layers to easily verify data availability efficiently, through light clients that perform DAS on the erasure-coded data. Unlike normal light clients that normally rely on an honest majority assumption that the state of the chain indicated by the block header is valid, DA layers that have DAS do not make an honest majority assumption for state validity because they can also verify the body of the block through data availability sampling.

Avail DA will have a P2P network comprised of multiple light clients which one can sample from. This is made possible as when light clients fetch some data initially from finalized blocks while conducting DAS, it utilizes that data to simultaneously populate a distributed hash table through a Kademlia implementation. As each light client stores a small fragment of the data, with sufficient light clients, an entire block can be stored within the P2P light client network. The light clients not only verify DA guarantees but may also contribute to the data availability themselves. Instead of purely sampling the data, light clients will also keep the samples available on this overlay P2P network. Given a sufficient number of light clients, the network has strong probabilistic guarantees of data availability as there are a large number of light clients sampling blocks. This would make Avail the only DA layer that can sample from its light client P2P network instead of relying on full nodes. With a sufficient number of light clients, the P2P overlay network should, in theory, have all the cells within a block, and thus one can query an entire block without relying on RPCs. Impressively, only 50% of the block is needed in the light client distributed hash table for this to be possible due to erasure coding, where only 50% of every column of the matrix needs to be available for the whole data matrix to be reconstructible.

Avail Nexus

For rollups, the DA layer provides consensus for the order of its transactions. This is the key unlock for Avail Nexus, a verification hub that unifies rollups utilizing Avail DA as the source of trust. This is possible as rollups using the same DA layer have uniform security, and the order of all transactions posting to the same DA layer are determined by the same consensus, and thus even with the risk of a re-org at the DA layer, all rollups’ transaction ordering will be affected equally by such a re-org.

If you recall, the two questions we had to answer for cross-rollup interoperability were “What is the canonical and final order of the rollup, and are the executions valid?” Avail DA solves the problem of what is the canonical and final order of the rollup. To prove whether transaction execution is valid is a much more complicated problem. As more rollups seek to bridge to each other, in the current fragmented world, one would require a unique bridge instance between each origin rollup and destination rollup, resulting in N! bridge instances for N rollups. In addition, each rollup may have unique State Transition Functions, and execution validation may depend on various proof systems. In theory, rollups do not need to be aware of the state transition function of other rollups, but simply need to verify execution validity and certain relevant state outputs.

Avail Nexus acts as a verification hub, being a custom ZK coordination rollup that sits between various rollups and Avail’s DA layer, with its role being proof aggregation and verification, along with sequencer selection/operating a slot auction. Instead of needing to verify validity proofs of individual rollups, each stakeholder now only has to verify a single aggregated proof, which verifies the validity proof of all rollups that submit their validity proofs to Avail Nexus. Avail Nexus submits the succinct aggregated proof to both Ethereum and Avail DA for verification, with a custom module within Avail DA that verifies the aggregate proof. Proofs are posted 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 Avail validators for anything other than the DA and the associated ordering guarantees, which is no different than the trust assumptions for a standard validium. Utilizing a common cross-chain coordination hub between rollups that post to the same DA layer means that there are no new trust assumptions, as all the rollups depend on the same DA layer for consensus and the economic security that is associated with it. Thus, with this single succinct proof, any connected rollup can verify the state of any other rollups. Avail Nexus acts as the unification layer for the rollups, and Ethereum utilizes this custom ZK-rollup as a source of truth for its assurances. This allows rollups to settle to Ethereum, but greatly amortizes the cost of execution from verifying one proof per validium to verifying a single proof for all Avail Nexus participating rollups.

An interesting point of Avail Nexus is that, theoretically, even optimistic rollups can participate, which is not the case for other similar aggregation layers. Optimistic rollups can submit their receipts and state roots to Avail Nexus, and instead of using normal fraud proofs, ZK fraud proofs are utilized which enables much shorter challenge periods. However, the key focus will still primarily be on ZK rollups at the current moment, with much more experimentation required to, for example, add things such as consensus proofs/storage proofs for optimistic rollup support.

With Avail Nexus, connected rollups will finally have trust minimized access to other rollups through the proof aggregation mechanisms and ordering guarantees. All of the connected rollups will exist and interoperate as if they are within the same network, creating a much more frictionless user experience with minimal liquidity fragmentation and without the introduction of new trust assumptions, be it for asset issuance or rollup guarantees. One can envision a world with hundreds of app-specific rollups, each excelling in a specific function or type of protocol, and whenever a user wishes to conduct a bundle of actions, a wallet or some other service simply conducts an asynchronous message call to utilize the product/service of whichever rollup excels at that function. Such a world is especially true in an intent-centric future, where a user could express an intent to do something, and from there Avail Nexus provides the substrate for a solver to come in, bundle a sequence of transactions on multiple rollups together, and then provide inclusion guarantees for said bundle. 

Avail Fusion

Ultimately, the security of Avail Nexus is derived from Avail’s DA layer, and one of the benefits of building a rollup is the ability to inherit security from the base layer rather than having to bootstrap your own validator set and the associated economic security. To fulfill this value proposition and build a base layer with a large amount of economic security, Avail is developing Avail Fusion, which allows native assets from large established blockchains to be used to secure the Avail base layer. Said assets include tokens like BTC, ETH, and SOL, along with Avail’s upcoming token, while a small % of the total stake will be reserved for emerging rollup tokens. A small % of the total stake is being reserved for emerging rollup tokens building on Avail, as rollup developers may want the interoperability that comes with Avail Nexus and this promotes economic alignment but also enables their native rollup token to accrue value in some form, e.g. sequencer fees/proof generation fees, which they can now receive as their native rollup token helps to partially secure Avail Fusion.

Avail Fusion is a combination of existing ideas from protocols such as EigenLayer, Babylon Chain, and Osmosis, where the ideas of staking and borrowing economic security from other assets are realized.

There are two potential approaches that Avail Fusion may take. The first is a staking module on Avail blockchain, where said module will support multiple foreign tokens through the assets pallet in the Avail node. The second is a staking module for asset conversion, which will enable the conversion of foreign assets to Avail’s native token, maintaining a price conversion mapping at the time of conversion. Which approach will be chosen has not been determined yet and will only be done so after consideration of various factors such as economic risk, inflation constraints, etc. 

Avail Token

The Avail token will be staked to secure all three of Avail’s products, Avail DA, Avail Nexus, and Avail Fusion. Transaction fees and bridging fees will be paid in Avail’s native token. Thus, any rollup that wants the increased interoperability that comes with Avail Nexus, the shared security derived from Avail Fusion, and the guarantees of Avail DA, all increase the value and utility of Avail’s native token. The larger the rollup ecosystem, the more demand there is to own Avail’s native token given that one needs to stake it to be part of the sequencer pool and the proof aggregator pool, with a large amount of value capture expected to occur in both of those processes.

Source: Avail

Synergies

One can easily imagine that DA layers will eventually be commoditized. There are differences in technical architectures, but it is likely that most rollups will opt into DA layers with the lowest cost relative to the cryptographic/crypto-economic guarantees if viewing it solely from what the DA layer provides. DA costs will not only be “subsidized” but also likely be a race to zero. Existing DA layer revenue models are likely unsustainable independently, as shown by a DA layer such as Celestia only having generated $11,558 in revenue to date.

As such, DA layers will likely have to, a.) differentiate through providing different guarantees, and b.) build up their own ecosystem as a moat. However, an ecosystem is only as good as the interoperability between all the different chains in the ecosystem. Thus, the reason for Avail building out the trifecta of a DA layer, an interoperability solution in the form of Avail Nexus, and a shared security solution in the form of Avail Fusion.

There are competitors in every sector that Avail is developing in, namely Celestia/EigenDA within the DA layer, solutions such as Polygon’s Agg Layer or shared sequencers within the interop layer, and products such as EigenLayer/Babylon for shared security. A key component of crypto in recent times has been minimizing the additional trust assumptions of introducing a new infrastructure layer, both from a cryptographic standpoint, but also from a cryptoeconomic standpoint. By vertically integrating a DA layer, an interop layer, and shared security, with the same cryptoeconomic trust assumptions and minimal new cryptographic trust assumptions, Avail’s design choices may prove to be the logical end game for DA layers given the natural synergies between DA layers and interoperability solutions. For example, EigenLayer + EigenDA is already a form of vertical integration, and one should not be surprised if a cross-rollup interoperability AVS launches based on EigenLayer shared security given the natural synergies.

Risks

There are several risks to Avail’s success over the long term. For example, it is possible that crypto lives in a world with many large general purpose rollups that have their own established ecosystems with an internal interoperability solution, or many app-specific rollups that do not care about interoperability with each other. In both scenarios, said rollups will not require “external” interoperability systems, which would diminish the value proposition of Avail Nexus. However, this is unlikely given the large amount of app-specific rollups that are launching and the headaches that users experience today with the extreme fragmentation.

In addition, there are a plethora of DA solutions that will be available soon, including Celestia which is already live, and other solutions like EigenDA which recently went live. Furthermore, Ethereum has implemented EIP-4844 which has introduced blobs as a data publishing option. Given the eventual fierce competition between DA layers, and the fact that past a certain threshold, rollups are likely much less price-sensitive for data publishing costs, and that we have likely hit that point to some extent already, it is entirely possible that rollups choose to opt into available DA solutions that have been “battle tested” that enjoy a first mover advantage, chooses to “align” with some other ecosystem, or choose to utilize Ethereum when full danksharding is eventually achieved. Data publishing costs and data publishing capacity will not be a large differentiating factor for most use cases.

With respect to Avail Fusion, which provides shared security through various blue-chip tokens and the AVAIL token, there are a few potential risks. The first is that developers only want shared security from a singular asset such as ETH or BTC, rather than relying on multiple tokens for cryptoeconomic guarantees. Similarly, if Avail fails to bootstrap sufficient security from a lack of staked assets backing the DA layer through Avail Fusion, then developers may view that in a negative light and choose to utilize other DA solutions with more economic security. Furthermore, other restaking/shared security products may have a large ecosystem of middleware/value-add solutions, specially catered towards rollups. For example, EigenLayer may have AVSs that facilitate decentralized sequencing, data availability, fast finality, keeper networks, watcher networks, and more. This might increase the value of being “aligned” with those ecosystems, although there is nothing stopping Avail DA based rollups to utilize some of those AVS.

Final Thoughts

Interoperability is front and center for many builders, thinkers, and users alike. Crypto is as fragmented as it has ever been, and if there was ever a time to start thinking about what the future of interoperability looks like, it is now. Without a shared DA layer, chains can only interoperate with additional trust assumptions, taking on additional risk in terms of transaction order guarantees and the finality of other chains, along with additional concerns about execution validity.

Utilizing a common DA layer with some form of validity proof aggregation could very well be the end state of the modular future, with a few existing ecosystems exploring similar designs. Given that, utilizing a common DA layer and an interoperability mechanism with the same trust assumptions and crypto-economic backing is the logical evolution given that a shared DA layer is necessary to facilitate interoperability in the first place. Avail DA, Avail Nexus, and Avail Fusion combined together is poised to be the first implementation of such a design and could pave the way for an interoperable, low-cost, and scalable future for blockchains.

This research report has been funded by Avail Technology Ltd. By providing this disclosure, we aim to ensure that the research reported in this document is conducted with objectivity and transparency.  Blockworks Research makes the following disclosures: 1) Research Funding: The research reported in this document has been funded by Avail Technology Ltd. The sponsor may have input on the content of the report, but Blockworks Research maintains editorial control over the final report to retain data accuracy and objectivity. All published reports by Blockworks Research are reviewed by internal independent parties to prevent bias. 2) Researchers submit financial conflict of interest (FCOI) disclosures on a monthly basis that are reviewed by appropriate internal parties. Readers are advised to conduct their own independent research and seek the advice of a qualified financial advisor before making any investment decisions.