When the Avail project first began, our core focus was on solving the data availability problem. We could see that in order for blockchain technology to be widely used across a variety of use cases, large volumes of transaction data needed to be secured in a way that was efficient, decentralized and secure. In addition, we put a lot of effort into implementing a chain that is fully aligned with Ethereum’s full-danksharding roadmap, ensuring that data published on the Avail network could be verified by any user, or any program, from practically any device. Now we have achieved that goal, and begun onboarding our initial wave of early adopters, we have started addressing other vital technical hurdles holding blockchains back, most notably, making cross-chain transactions seamless with the Nexus upgrade.
Everything built on Avail from this point onwards, creates exponential returns in terms of scalability and performance. The reason for this is simple, Avail has implemented an elegant solution to web3’s largest scalability bottleneck - data availability. Adding cross-chain transactions to Avail from now means that cross-chain transactions can inherit all the scalability features of Avail’s underlying blockchain, like KZG commitments and Data Availability Sampling (DAS). The same is true for rollups and Appchains that integrate with Avail too.
A core thesis of Avail’s rollup centric architecture is that execution should happen off the main chain. In the case of rollups, validiums etc this is relatively well understood; chains manage their own execution environments and publish transaction data to Avail. While this is a valuable offering, it’s often more appealing to larger established projects (Lens being a good example) with high-throughput requirements, and in need of an efficient data availability solution. This however overlooks a significant portion of the community who want to build apps and services on the network, without launching a new chain, similar to deploying smart contracts on Ethereum. However, without native execution support, Avail’s offering here would remain limited. This necessitates a fresh perspective.
Execution Remains Off-Chain, But Verified Onchain
Implementing an EVM or SVM style execution environment on Avail would make little sense. Doing so would largely defeat the purpose of building an optimized blockchain for DA in the first place, and we’d be back to where all of this began (admittedly with improved DA efficiency).
This is because a general purpose, Turing complete blockchain is always going to lead to bottlenecks at some point. Every Turing complete chain will have their own Crypto Kitties that will hog bandwidth, clog up the chain for others and negatively impact performance for users.
Rather than executing the transactions on-chain and clogging up the network, the computation for Avail’s execution layer is run off-chain, then verified onchain with ZK proofs for settlement.
This adds numerous benefits. It enables the Avail network to verify and settle transactions while providing highly efficient DA at the same time. The ZK execution engine doesn’t bloat the chain and negatively impact the scalability gains we’ve made, which is what would happen if we implemented an EVM or SVM style approach. There’s also no strictly enforced execution runtime, allowing for greater developer flexibility. Now you can bring any execution environment and prove it with ZK on Avail’s base layer.
By checking and verifying ZK proofs on the base layer, Avail’s execution engine actually outsources a large part of the computation externally, in keeping with the core thesis of Avail’s horizontally scalable design. Avail’s version of Crypto Kitties won’t hog the chain’s resources and negatively impact others, because Avail’s Crypto Kitties will provide its own computation.
ZK Apps That Verify Like Smart Contracts
Instead of launching a new blockchain, developers can now build ZK apps and verify them directly in Avail, leveraging its security and scalability, similar to deploying a smart contract on Ethereum.
Avail’s execution runtime can verify any program provable by RISC Zero or SP1 today, and support can be added for Brevis, Starkware and other ZKVMs going forward. This opens up a wide range of ZK-powered use cases, such as:
- Native token deployments (e.g. ZK-minted assets or stablecoins)
- Smart contracts (e.g. ZK verified smart contract logic)
- TEE (Trusted Execution Environment) attestations (e.g. confidential compute proofs)
- ZK-automated compliance (e.g. KYC/AML checks without exposing private user data)
Developers can begin experimenting with ZK apps and deploying them on Avail’s execution runtime now. There’s currently a ZK App for Ethereum and a ZK App for ZKsync which verify the state of Ethereum and ZKsync on the runtime respectively. If you’re interested in finding out more, check out the repos for each, or reach out to me, or our dev rels @naruto11eth and @robin_rrtx.
Avail’s Growth Journey
Since the beginning, we’ve been focussed on understanding the technical fundamentals of blockchain technology and building up from first principles. We’ve now built a high performance team who understand this more than most, and we’ve welcomed other pioneering teams into the Avail ecosystem who share our vision too. Yet, as with many things, the job is never fully done, and there’s still a lot we can do now to get more out of Avail’s unique architecture.
Avail’s ZK execution runtime is going to play a key role in facilitating cross-chain transactions with the upcoming Nexus upgrade. It also significantly expands the scope of the Avail network from providing DA services to serve a much wider developer base. Now the Avail network includes a general purpose execution layer, optimized for verifying and settling the latest ZK technologies, while also providing state-of-the-art Data Availability Sampling.
This is just the beginning. Avail’s ZK-native execution layer opens a new design space for developers to build a wide range of hyper-scalable and interoperable applications with much greater flexibility than ever before.
