The Nexus Runtime is a state verification engine that will operate on Avail with the Nexus Upgrade. This major upgrade adds significant new functionality to Avail, taking it from a general purpose DA layer, to a feature complete rollup-centric blockchain with execution proof verification through new ZK Apps and state-of-the-art Data Availability Sampling.
The Nexus Runtime enables flexible ZK App verification on the Avail base layer. It is the engine that will verify ZK Apps and enable cross-chain verification for the Nexus Interop Apps. The Nexus Runtime will enable new functionality on Avail, like native Avail rollups that are seamlessly connected to each other, as well as custom logic from ZK Apps that connect external chains to unify liquidity and users across ecosystems.
The state updates submitted to Nexus from ZK Apps are verified using ZK proofs within the Nexus Runtime to ensure state updates were executed correctly. Avail Nexus then updates the state of each App Address in its memory according to the verified updates, which other ZK Apps can read from. This state verification engine provides the back-bone for a highly scalable and verifiable, crosschain ecosystem.
ZK App Execution
A key difference in the way that ZK Apps run on Nexus versus the way smart contracts run on Ethereum is that with Nexus, ZK Apps are executed on the client side first and not within the Nexus Runtime. This frees up the onchain component of Nexus to be extremely efficient in order to optimize for scale.
Using a quick comparison for analogy, smart contracts on Ethereum are deployed onchain and run on the EVM. As we have seen, replicating substantial execution onchain, in the way most blockchains do today, limits the blockchain’s throughput. As more applications compete to have their transactions executed at the same time, the computational demands on the execution layer increases and this creates a scaling bottleneck.
With Nexus, all of this computation is moved off-chain and executed on the client side. Only a succinct execution proof is checked and verified onchain, removing this scaling bottleneck from the equation.
To use the Nexus Runtime, developers will:
- Deploy an App Address on Nexus with an App statement, analogous to deploying a smart contract.
- Execute transactions, ordered through Avail DA or elsewhere at any speed, based on specific block times and/or preferences, and submit state updates to Nexus at any stage.
- The Nexus Runtime checks the submitted proof against the App Statement, on Ethereum the transaction execution happens on the execution layer itself.
- If the transactions were processed correctly as per the App Statement, Nexus updates the state of the App Address onchain.
ZK Apps
ZK Apps could be used for many different use cases, including creating new tokens or supporting fully-fledged rollups. In the Nexus Upgrade, ZK Apps will be used to power the Nexus Interop Apps for seamless crosschain transactions. However, any program that can be proven by RISC Zero, SP1 or any supported zkVM could become a ZK App.
Let’s take a look at an example where a ZK App verifies the state of a chain built on ZKsync’s ZK Stack. When the ZK chain wants to interoperate with others, it submits the State Root, Proof, State-diffs and Rollup metadata to Nexus.
Nexus verifies the correctness of the computed state by validating the App Statement. The App Statement is critical as it binds the program to the Nexus Runtime. If the program’s code changes, the proof will no longer match the statement, causing verification to fail. If the App Statement is correct, then the Nexus Runtime will update the state of the App Address to its new state, which can then be verified by anyone.
With state updates verified by the Nexus Runtime, it then creates an aggregate ZK proof. This aggregate proof provides an efficient, onchain verification mechanism which anyone can use to verify the state of any connected chain. When chains can verify the state of other chains via Nexus, it provides the ability for cross-chain transactions to take place without users needing to manually bridge their assets. Instead, message passing between the chains can happen on the back end, and state can be verified independently by both chains to settle cross-chain transactions.
This can be useful for unlocking unified liquidity between ecosystems, where users can send assets from one chain or application to another without bridging. Instead, the cross-chain complexity is moved to the application developer and simplified through Avail Nexus. This can also be useful for non-financial use cases too. For example, a decentralized identity Appchain could be connected to Nexus, which specializes in verifying Personally Identifiable Information (PII). The Appchain could have a ZK App which verifies the users’ age, and any receiving application could verify the aggregate proof of Nexus to grant the user age-gated access. All of this could be done onchain, without any manual intervention, and all within the user’s control.
Equally, an app developer that needs to verify the age of users could simply plug into Nexus and start verifying whether users are over a certain age before granting them access to apps. This can be done with minimal trust on any central entity. The identity Appchain simply operates as it was programmed to, verifying PII data without exposing unnecessary details. Nexus then verifies the state of the identity chain, and other apps can simply verify the aggregate Nexus proof to check user credentials.
Start Building
If you’re interested in learning more about Nexus, there are two ZK App examples in the Nexus demo repo which you can take a look at, and more will be published soon. See the Ethereum ZK App and the ZKsync ZK App which verify the state of Ethereum and ZKsync on Nexus respectively.
You can discuss the Avail Nexus Runtime and other topics in the Avail Forum, and follow the Avail Nexus launch on Twitter.
