Avail 🛠️ Learn how to build a Avail Powered zkEVM Validium

hi everyone this will be a short walk through of our available ADM repositories so of course the first thing that we want to look at is the aail module itself just note that since the underlying polygon ckvm node is written in go of course our implementation or other implementation of that has to be in go as well so we have this particular file called avail.co on the underlying ler we use something called gsrp C which is basically go based client for working with substrate and then we have for that as well and so we have our own custom Fork of aail GSR PC that we use to do everything from sending data to quaring data uh to set dispatching data roots and so on and so forth so let's delve directly into the init function we basically have this file called aail config so if we go here and this this config.py that confirms to this particular stru so you have Jon in your Jon you can write seed and then you can put the seed of the account that we should use to dispatch the extens X from the API URL the Bas basically the RPC URL the app ID is the one that you'll be creating through create application key the destination domain will be 1,000 for ethereum the destination address will be the address of the Dage router and then the timeout will be whatever the timeout you want it to be we just use it to have sort of a fixed timeline for finalization of your particular extrinsics okay so let's go back to avail. go in here what we basically do is we just store all the variables that we'll kind of need to perform repeated queries so for example we get the latest metadata we create the API we get the config um and so on and so forth and the reason we do that is so that with every other API call for example in post data we have a couple of other calls as well we don't really want to incur the cost of this again and again and then that's pretty much all that we do so we just set the variables or like you can think of them as almost Global variables here and so kind of what we really interested in is this post data function here right so what we do is we construct an extrinsic of The Da pallet called submit data and then we just send the DX data and that's pretty much it I'll show you as well where we kind of call this submit data in a bit but yeah basically what happens is we create this particular extrinsic and we create the signature options we sign it with our key ring pair and that's pretty much it and then what we have have is like this a loop that runs for that time out period that we specified earlier and so for example if it is in the block we just submit that as part of the log if it is finalized that's when it sort of break out and this is what kind of timeout is keeping track off so we just subit a log here then we hash it and this transaction hash will become important because we submit it to the Z AVM contract on the L1 layer whatever that is to sort of prove that the data that we are saying that we're sequencing is actually being posted to a will so with here what we do is we try to find the extrinsic index so we can keep track of that while submm the proof as well we get the header in which we have the block number and uh this block number is what you use to kind of fetch the data route from the contract later on and so we also have this function called dispatch data route which is doing similar to how post data is sending data in the extrinsic with dispatch data route we can give it a header so you will see we we give it the header we create the header here and we send it the entire header and then on the other hand on the L1 da Bridge order contract it is able to send that entire data route or so it'll basically map a block number to Vertical data route so again we make a new extrinsic we get the next nons we again craft the extra signature options and then finally we submit and wait similar to how we waited for the previous um extrinsic and finally we have get data so this is required for our synchronizer for example like let's say you're running a new valadium node right like and then you kind of want to sync your node that entire process is not that straightforward with the valadium because the data does not live on L1 so what we do is we have this kit data function here um and then based on on the data that we already indexed from that particular L1 contract we will be calling as you can see we kind of get the block from a full node with the block hash and then we search for the particular extrinsic where our data is stored basically so what we'll then do is that the unsynced validum node can then sync using the transaction data that are posted to a uh which then allows you to kind of build trustless sequencer sort of models that would not be possible otherwise and then this is just a helper function that kind of gets the next nons from substrate it's pretty trivial what we are more interested in is basically the finalizer logic so in the sequencer module we have something called finalizer doco and this is where we have sort of readjusted to use AA so for example if I were to show you let's go to close B so we kind of get raw transactions when we encode it it's basically an rlp encoding of the transactions in a particular batch and a batch is basically a collection of transaction data across multiple blocks or anything to be honest so basically if the block is non empty what we do is we retry aail three times uh and then we attempt to post the data and then we kind of hash it we store everything related to that particular batch so that we can submit it later and then we close the batch so similar to how you would have uh the normal function ongoing we just sort of intercept the Clos batch flow and we send over the data to aail and that is pretty much um what we do here and then of course we dispat the data rout as well so we can access the data uh later on or basically you can attest to that data on L1 so that is what we have here maybe I can show you the sequence sender logic here the logic is sort of complicated but the thing that you need to understand is now in this sequence Ender what we do is we sort of combine multiple batches and then we start sending them at as a batch as possible as the number we can send the maximum number we can send in a single transaction so let's say we have batch x y z and we include x and y and then the transaction is full what we do is we just send XY with the corresponding sequencing data um on L1 and that's basically what is happening here so as you can see we have also sent the Da Block number the da proof the da width and the da index while we submit uh sequence and that is because of the data attestation function that we have on the L1 contract so basically what we call your rollup contracts on L1 which does a data attestation verification so basically if you have no L2 data we don't really care if you have any L2 data and then the data route has not been dispatched yet then we sort of just wait until the data will get dispatched because in the optimistic pattern it can take sometime between 20 to 30 minutes to kind of do the entire flow and then if we observe the data route is already available on L1 then we just append to the sequence and then we send it and that's pretty much it on this side of things we can kind of look into see synchronizer bit as well so let's do get data here that's sort of what we are going of interested in let's say the Da Block number for this was zero so like this is relevant in the case like let's say you are uh roll up migrating to AUM then of course like your previous sequences will not have any Da Block number so technically what we do is we give it the Da Block number we give it the da index and we are able to get the raw transactions from aail and we then reexecute the block as if we have the data already and that's sort of the trustless sequence or um model that I was talking about earlier which a function like this enables to the synchronizer model and then similar to here it's basically when we observe the event on L1 we immediately Fest dator from aail and then we ensure just for sanity you know that the data that we posted is actually correct so it's sort of like an extra layer of uh ensuring data availability so that's pretty much it on the Node front I'll do a short walk through to contracts so similar to how polygon have polygon ZM as well we have have our version of the polygon zkm so to say we can see that we have inherited this D outo verification contract that's s of the extra library that we have added so for example if I had to show you let's go to D verification right so we basically just have a router that we set and then this is just some simple Merkel rout verification and that's pretty much it yeah so going back to polygon Z KVM if you go to sequence batches that's sort of the important function that we have where we sign to submit the badge of L2 data and then you submit the da data and then with the da data we able to check for data restation so with the block number the proof the width the index and the batch hash that if a recall we submit from the sequence sender we can indeed prove that some data that we're kind of claiming to submit here has been all posted to Avail and then basically the rest of the flow sort of remains similar we have for example first batch datas as well we do some comparison checks here and the sort of this is what's important here this is what's the current relat input hash where we kind of take the batch hash of what we have submitted and then based on whatever is previously stored in the contract we kind of create a new accumulated input has and this is what the Prov is actually proving it's proving the change from the previous accumulated input hash to the next input hush so since we Prov data attestation at the time of sequencing we don't really need to post it again at the time of uh proving and this kind of helps you save on prover resources because then the prover doesn't waste its computational resources on basically unattested data or useless data in some form and that's sort of kind of all the cruxs of the changes that you have made as you can see it's pretty straightforward to implement we also plan to kind of change this over to use our vectorx Bridge as well as also use the cdk release that will happen in the late February so this version might kind of change drastically but from our implementation standpoint it will kind of remain fairly similar because the code that we have today is fok from polygon ckvm as will be cdk so the scope for changes will be quite low in that regard but still it will be like a decent level change so you should be technically aware we'll kind of publish the documentation for the new bridge in the coming days so you'll also have more clear ideas on what we're doing and once we have that we'll also reimplement the validium with cdk so it and that's the one that will be officially supported going forward but if you wanted to build ADM today this is the solution that you have and feel free to use it yeah that's pretty much it thanks everyone