Avail's Unification component: Nexus
gAvail.
Today, in Naruto’s Scroll of Wisdom, we are going to talk about Avail Nexus.
So, a quick rundown on what Nexus is and why we need it?
Think of a landscape where you have 100s or even 1000s of chains. These can be appchains or L2s or anything you wanna call them if you don’t want to get into definitions. Because of this, I might be in a situation as a user where I have 50 USDCe on Polygon, 2eth on Scroll, and everything looks messed up. I have to go to multiple bridges, look for the best gas price and route and move assets with 10 clicks - all while making sure that I don’t get hacked. Too much, right?
That is why we need Avail Nexus: A zk-coordination rollup which is basically a proof aggregation layer and a verification hub, and has a sequencer selection mechanism. Nexus uses Avail DA as a root of trust and submits aggregated proofs to Ethereum and Avail DA periodically.
Okay, first let’s look into what is a “proof aggregation layer”.
In very easy terms, proof aggregation is exactly what it sounds like! It is a method where a prover collects multiple proofs and produces a new proof that proves the validity of the initial proofs. There are multiple ways of doing proof aggregation such as via Folding or Recursive STARKs. There are more methods as well, and every method has its own pros and cons and tradeoffs between verification time, efficiency and proof size or required compute power.
So let’s jump back to Nexus and see how it all works out together. As we know that Nexus is aggregating proofs, it is verifying the state of all the chains which are using Nexus. This aggregated proof can also be verified by other chains and the end-user clients. For applications, this means that by using Nexus they can compose async states from any chain, and Nexus works as a verification hub for cross-chain communication and rollup events. If you look at the diagram below, you’ll realize that a lot of chain specific details are abstracted away with the help of Nexus. These chains don’t necessarily talk directly with each other and just use Nexus as a Middleware for verifying cross-chain transactions. Pretty powerful, right?
During its runtime, Avail Nexus checks all validity proofs submitted once certain conditions are met and produces a single, concise proof of these validations. This proof is then forwarded to the Avail base layer, where it is verified by all participating nodes, making it an integrated settlement layer. Any rollup involved can verify the state of another rollup by validating this single proof.
Importantly, through L1 bridges, this system can connect to and interact with external networks. It is safe to say that Nexus itself is a ZK rollup.
Let’s take an example now to understand how it actually works:
Imagine it is the year 2049, and you are living in a world full of rollups. There are specialized rollups for payments, a chain for NFTs, a chain for NFT metadata or a chain that keeps track of account balances and transfers.
Now, let’s say Alice lists her NFT for sale on a marketplace, and Bob wants to buy it. When Bob clicks buy, he is redirected to another page from the payment provider/wallet. Once the payment goes through, Bob is redirected back to the NFT marketplace with a new, shiny NFT in his wallet. If you think about it, this process is similar to Stripe's payment process. Bob buys something from Alice, and then he is directed onto Stripe’s payment page where he puts in his card number (connect wallet in Nexus/web3 space). He then makes the payment and goes back to the product page. This is similar to web2.
Let’s see what is happening here in the background:
If you look at the diagram above, you’ll realize that the NFT chain has NFT owner A (Alice). The Balances chain has the accounts and the balances of those accounts. When Bob puts in a buy order, the NFT gets locked, and the payment requirement is encoded into the NFT itself.
Bob makes the payment on the “payment chain.” These changes result in new proofs for both chains which are verified by the Nexus, and a new aggregate proof is created. This new aggregated proof is downloaded by all the chains and clients and has a verifiable state.
With this, Bob can now show the payment was made, send the txn proof to the NFT chain and get the NFT transferred to his wallet. If you look at the figure below, you’ll see that the aggregated proof is generated by Nexus after taking the proofs of both the NFT Chain and the Balances Chain. You can also notice that the state has `Pending: abc` on the NFT Chain side.
This whole process creates a seamless user and dev experience for Alice and Bob, and they don’t need to go to different bridges to move their assets in order to execute transactions. Why is Avail Nexus so goated? Because of the following reasons:
Scalable: Each chain is running on its own, and there are no direct connections needed for chains to talk to each other. Adding new chains to Nexus also doesn’t affect existing chains and doesn’t need additional verification.
Flexibility: The whole Nexus design is flexible enough to be used on anything from VMs to SocialFi apps or even different chain stacks. As mentioned above, any chain doesn't have to be aware about any technical parts of other chains in order to use Nexus. The interesting thing is that the “pending” requirement in the state can be considered similar to intents. So, this design is easily flexible for a wide variety of Chains and VMs.
Trust-Minimized: This is not a bridge, and unlike them, a user gets cryptographic guarantees of the state of the chains, without the need of all the transactions of each and every chain. This is the reason why this design is so powerful and allows for direct, trustless verification of the same proofs and DA at the end-user client.
Seamless UX and DX: Our experience with UX and DevEx is currently so bad that there are countless bridges, mints & burns, and moving assets from one chain to another. This is a nightmare for any user. And while doing all the bridging, a user’s wallet can potentially be drained by connecting to a phishing site. This is not the best solution when we are trying to aim for mass adoption, and Avail fixes this.
This is the whole idea of Avail Nexus. We want to unify web3 rather than building walls and bridging to 100 chains. Every project’s goal is the same, i.e., mass adoption, and we are building for the future. A future that has seamless UX and DevEx. A future that is Unified.
More tutorials on Avail Nexus soon.