Building an Erigon-Based Node for a Type-2 zkEVM |Max Revitt - Gateway.fm |

hello everyone for our next talk it's building on Aragon Bas node for type 2 ZK evm and speaking with us today who traveled 20 hours to get here is Max Revit he's a developer all right go ahead hey thanks for the intro man um so welcome yeah this afternoon I want to explain to you how we modified the ethereum um implementation Aragon um to build the client for polygon cdkl2 so in the presentation I'm going to cover the following topics so who are Gateway FM like who are we um who's the company I'm going to go into what is a rollup you've probably heard that a few times today um and what is cdk um I'm going to cover gateways product Presto just in brief um and then I'm going to go into why did we choose Aragon to do this implementation um and then we're going to go through the main two parts of the system that we've built and that we're building so the bit that we've built already is the synchronizer so we're going to cover the evm changes we made um we're going to cover the sparse mle tree um we're going to cover the dynamic Fork enable ments um we're going to look at the L1 and data stream sync so where the no gets this info from and then the bit that's work in progress which is the sequencer um so we're going to cover virtual counters the witness um executive verification dat stream generation and then a load testing tool which is the TX replayer so who's gateway gateway FM is team Professionals in the crypto space um we build web 3 infrastructure um and tooling um we have expertise in blockchain fintech infosec other Industries um and that lets us lend our experience to other people to sort of really help the businesses in in the space um so I'm Max Revit I'm on the R&D team uh I'm a developer um my team is a group of people who've been on the Aragon team previously um so we have good experience with this node software um and we've been Building Solutions in the space for for quite a while now so Gateway work with with um some industry leaders and some names that you will recognize um polygon Wix Etc um trusted by these Partners so Presto so Presto is gateway's Flagship product um this is rollups as a service um so four clicks to your own rollup so private ZK rollups um with all of the tooling so once you've deployed that you get kyc Block explorers um Etc so kind of you know TurnKey solution for rollup um you know we run these rollups for other people um as well as building the technology that underpins them so that gives us a unique perspective and you know we understand the requirements for a user friendly and performant client um you know and how to use this client with our Presto users so having that R&D Department also means that we we produce a better product in Presto so what is a rollup um a rollup is a layer two scaling solution um it will reduce costs and increase throughput by processing transactions away from the main blockchain um so when it comes to ZK rollups um there are a few types um and they each come with their own tradeoffs so um a type one is essentially ethereum compatible um you know is basically running the L1 um the issue here in the tradeoff is that proof can take a long time to generate so realistically that might not be the option that you want um type two has minor changes um so State Tre modification ations uh change gas cost some small evm changes um this comes with the benefit and the tradeoff that you get quicker proofs um but you may encounter some incompatibilities when trying to run your smart contracts um we then move to the type three and again the trade-off towards performance is most heavily skewed here so it's mostly ethereum compatible um you've got fast proofs um but you get more incompatibilities so for example most of them be no pre- compiles so cdk is a type to rollup and throughout this um cdk was Hermes polygon ZK evm so um it's useful to know the terminology in in the history so cdk is the name we'll be using um so the question is why did we choose to use Aragon as the node to do this um so ergon benefits from a low footprint on disk anyone familiar with the um the node in the uh ethereum L1 space will know that um it's an all-in-one solution so RPC uh transaction pool evm Etc um they're all there in one one repo to be run um it has a stagewise sync so instead of going block by block the node will sync in in stages um so we can optimize some oper operations for the batch um so for example in this case we can verify multiple blocks in a in a single state rout calculation um Aragon uses mdbx um so this has some advantages over things like bolt and level DB in that it's simultaneous read whilst you're writing the DB um which means we can split the parts of the system up and it and it's super fast um so as I said you can run components of of Aragon separately um a good example there being that you can separate the RPC out and it can still talk to the database whilst it's been written and the sync is happening in in the background um so it's very capable as an archival node um and it's an ideal candidate in fact for syncing the layer too so the first part of the solution that we've provided and this is the synchronizer um this is a node that will consume and sync the block chain um and it will allow you to then stand up an RPC um so it it syncs from both the L1 and a data stream which is produced by the sequencer um so the sequencer will produce the data stream which contains transactions batches um and other data and then we use L1 sequences and verifications so the L1 verification will contain a state route which we can use to then check and make sure that the chain is is okay um so we made some adjustments to the stage sync as well um so we replac the head as and body stage um with a stage which actually retrieves data from from this stream and and pipes that into the Aragon DB mdbx and we have a new stage which is for creating the smt so we replace the Aragon into hash's Stage um and this allows us to generate a spar Merkel tree um which will give us the state roots and so that differs a little bit from ethereum Main net um with the with the Merkel tree um where possible we have tried to maintain Upstream compatibility so obviously this is a fork of Aragon um we want to be able to take changes from the Upstream as and when they come so we we've kind of added undor zkm to the to the file names and tried to where possible separate out the code we've written as much as we can so that when we when it comes to the the actual code files that are that are already in Aragon and in the Upstream we've made small incisions there um so hopefully when we re base on the Upstream that's going to be a lot more easy because we're just going to see like a function name change or something like that and it'll be fairly clear that okay this is the zkm version um and we'll know which to take so also we've added a new RPC name space um so with this being an L2 um there is a zek zkm namespace um and that allows you to get stuff by batch and do some operations like that around the batches so since we're running a type 2 rollup um we had to make changes to the evm uh as discussed with the types of of rollup so this is a evm that's based on the Berlin hard Fork um we've made various changes to op code so xcode hash uh Returns the hash of contract by code from the state tree difficulties returning zero um static call doesn't override return data you know if the execution is reverted um we also have a new type of error for disabled smart contract so makes it b a bit like an error reverted um with each Fork we've changed the pre- compiles to match the cdk requirements and we also replace self with sendall um so this prevents funds from from being lost in the L2 um this isn't necessarily evm changes but there's a couple of things that we have to write into contract storage as we do the execution um so Global exit routs are placed in the global exit route manager contract storage um and then the transaction number and State Route reach placed into the system contract at that point as well so the SP Merkel tree um this replaces the the Merkel tree from from the ethereum implementation um and the benefit of sparse Merkel tree which is a 20- minute presentation on its own maybe longer um is that we can do efficient non-inclusion proofs um so we took an algorithm that existed from the JavaScript implementation of the node um and we made some performance increases so as I said we have the stage sync well that means that we can do a batchwise operation on this tree um and we added some efficiencies there so that we don't multiply hash nodes um and so we got a huge performance benefit there um we use the Aragon history so that we can incrementally update and unwind this sparse Merkel tree um and luckily we retained DB compatibility with the JS implementation um which was a huge debugging win for us because we've got a lot of state and we're trying to compare and see why our state routs have differed um so that's been a huge help as we've we've done the project um we've also added Dynamic Fork enablement so normally in Upstream Aragon you would need to know uh a block height or a time stamp of which a fork would be enabled ahead of time um here we can code for it and say that it's Fork idx um and when that fork ID is actually enabled by the chain we'll consume that and that will set that feature set live um so this is this synchronizer is currently an alpha um and we'll be doing the beta soon this brings me on to the sequencer um so this is a work in progress and this is a separate mode of operation for Aragon where the node will build blocks and batches which will be sent to the L1 so it acts as the centralized sequencer now this is obviously replacing an existing sequencer which has a different evm implementation um so we have virtual counters which mimic the requirements of the cdk hard hardware and they prevent us basically from overwhelming the the appr um and the way we've done this is we wrap the Aragon jump table um and and so different counts are assigned to different things more expensive operations will have a higher impact here um and so we're aiming to limit work done by transactions and limit the batch data size so because proof are expensive we want to maximize each batch so as we go through we're working with these counters um and if we hit a counter overflow we will simply revert back to the previous transaction and and then build an optimized batch size um we've implemented the witness um so the witness is a is a description of changes to state so it's like a partial sparse Merkel tree um and we can send that to the approver um and we can send that to the uh existing executor in fact for for reasons we'll see later um and and that allows you to sort of have a stateless reconstruction um and we can use this to verify the existing sequence or implementation which we're going to see next so this is where we run Aragon in the sequencer mode and obviously once we built a batch we need to know that our evm has had the same outcome um as the existing executor evm so we we actually you know we have to keep compatible with the Upstream rum um due performance reasons we use a pool of executors um asynchronously and this is where the statelessness comes in with the witness so we can verify multiple of those at once now on the happy path that's great um when there's an issue we go into like a limbo mode that we're calling it and so we we have to sort of revert the batch to find the failing TX um where there's this incompatibility and we'll remove that transaction from the pool and then we'll move forward again um so that's how we're dealing with the the differences that we may perceive there and obviously that'll be logged and hopefully the issues will be raised and we we can then resolve that um the sequencer does data stream generation so at the moment the synchronizer node we talked of is consuming the stream from the the polygon implementation of the the sequencer um at this point we will start generating that stream um for these synchronizer nodes and exposing it so pieces of stream are being verified by the executor in that in that verification step as well um obviously whilst doing this one of the one of the outcomes that we want is a a performant node uh performance sequencer um so we built a TX replayer which allows us basically to push transaction into the sequencer um and and replay them say from Main net um and that's kind of like a good real world test so to summarize um what I've talked about rollups are a layer one scaling solution um the rollup type indicates that compatibility and performance tradeoff um you know cdk sits at the the the type two um so we do get a performance benefit but we don't introduce massive incompatibilities um you know most smart contracts hopefully will work there with with minimal tweaking um the reason for the project the existing polygon cdk ecosystem is being augmented uh by this Aragon based node um I think it's going to be slightly more ergonomic for infrastructure uh you know to run this node um and hopefully we can squeeze a little bit more performance out there as well we've talked about the Presto ecosystem so obviously that's gateways rollups as a service um and we deploy things like this solution um to allow you to have four clicks to your own private ZK rollup which obviously is super super cool and a kind of like you know TurnKey solution um we talked about the synchronizer which is an alpha the beta is coming soon um and so that's for running basically your RPC nodes and we also talked about the sequencer which is the work in progress where we're building blocks batches and submitting them um to the L1 so I'd like to thank you for listening um if there are any questions we'll be at the polygon booth for a bit um you know we talked through quite a lot of deep Concepts there in brief um so I'd be happy to go into a little bit more detail if anyone wants that so yeah thanks very much