[Music] And for this one, I'd like to bring on Martin from Zirket to tell you all the things that they're doing to help make sequencing a lot more intelligent. Please give Martin a big round of applause. [Applause] Thank you, Cartik. Hi, everybody. Welcome.
Uh my name is Martin. It's my great pleasure to be here. Uh I'm from Zirkit. I'm actually also originally from Czech Republic. So I love speaking at events uh here in Prague.
And I will be talking about Zirket and about sequencing. Before I go there, these are our cats. Uh please take a look at them very carefully right in the middle of the slide. They are really really cute and that's why I have them on the slide. But I also have them there so that I can do this.
This is last week. Uh, and I also have this slide and I also have this slide and I also have this slide. Those are all the hacks, you know, that keep happening on blockchains over and over and this is why I am here. I'm from Zirkit. Uh, we are a blockchain and it was started a couple years ago where you know I was working as a smart contract auditor together with some friends.
We started asking these questions. Hey, could blockchains actually do a little bit more for the security of the participants on chains? Could they be a little bit more proactive? Right? Could we not you know rely only on the security audits that you know no matter how they are good uh they occasionally can miss stuff.
So could the chain be an active actor here? Could it discover hacks and could it prevent hacks despite vulner vulnerable code? And this is what Zirket is. uh we are an EVM equivalent zero knowledge rollup and we use sequencer level security to protect the assets on the network and it's been working tremendously well throughout the existence the network has been managing anything between 1 and 3.6 6 billion US and you know I sleep pretty okay.
So this talk is about how we can engineer such a system or how you could engineer such a system and what challenges you would have to solve when doing so. So let me sort of tell you you know what exactly we want to develop in here. This is the traditional flow of stuff on regular roll-ups. You have the users, they produce transactions, they send those transactions to the memp pool. From the memp pool, the transactions are picked by the sequencer.
The sequencer decides, you know, on the order and inclusion into the blocks. So, it just like fishes the ones that it likes and it puts them in blocks. When I say sequencer level security, I am talking about this blue add-on. So what is happening in zirkit and with chains that are equipped with sequencer level security is that when the sequencer receives a transaction before it puts it into the block it actually uses some external module. In our particular case this is all powered by AI uh and it ships the transaction to the module and asks hey is this a hack or is this the a benign transaction that is like normal you know and should happen.
If the transaction is benign then it just sends it in for execution. So it places it in a block and everything you know happens as normally and if the transaction is actually damaging it is exploiting some protocol then it quarantines it so that it can be further investigated and if there really is a vulnerable protocol plus a transaction that has just discovered the vulnerability and is trying to exploit it we can actually do something about it right so this is kind of what we would like to achieve and on top of that we have whole bunch of other requirements right I said we are a zero knowledge rollup uh that we are EVM compatible and so on. So for the sake of engineering the system what I will want is that we will be building a rollup with a single block producer. So centralized sequencer this is our particular setting as well. We will want to be producing blocks at some constant rate.
It can be anything that is sort of popular these days. So let's say some constant between 500 milliseconds and 2 seconds. Blocks will be you know regularly large. let's say 30 million gas units and because as humans we don't like to think about gas units. Let's just you know think about 100 transactions that you pack into a block and you want every transaction or block to be scanned and the rule is that if there is a hack it just like cannot make it on chain.
Okay, so this is what we want to achieve. Well, if you think about it, you know, you will have to make some design decisions, right? The very first design decision that you will have to make is what do you actually want to scan and what do you actually want to analyze because you have multiple options and there will be some tra tradeoffs. So the decision here particularly is do you want to take a look at every single transaction or do you actually want to consider the blocks after they are formed and there is a big difference here if you take a look at every single transaction this is what we called SLS 1.0 know and what we developed first.
The good thing is that you can actually paralyze your scanning, right? You have, you know, full meool. You can literally spin up an instance for every single transaction that needs to be simulated and analyzed and then the results will be coming back. It's really easy to parallelize. The other advantage here is that you actually act before the block formation process because if something tells you, hey, this transaction is bad, it wasn't placed in the context of the block.
So you don't have to deal with the necessity of reforming the the block which we will see is a small complication. At the same time there are some transaction dependencies. That's a concept that exists and that you know in some situations may hide hacks. I have an example in here. I have two transactions.
The first one has the format of a conditional which says if some account 0x123 is funded with balance you know it has at least one ether then execute something otherwise turn this into no op right and the other transaction will just funded account 0x123 with one ether well the effect of the first transaction will really depend on whether we mine the first transaction first or second right this is what we in the professional setting called transaction ordering ing dependence. So therefore, you might actually want to be scanning entire blocks. This is what we call SLS 2.0. In that case, dependencies will not matter, right?
Because we you know where the transaction is sitting and you know exactly what was processed before the transaction. So you have the full picture. If you can literally identify a hack, you cannot miss it. You know it you know where it is. On the other hand, now you've lost that parallelization.
You suddenly have a block. it's some volume of firm work that you have to do. it's hard to parallelize and then you know you've already formed a block right and I say that you have to form a block at a constant rate let's say every 500 milliseconds imagine that you're at millisecond 400 your analysis just finished that and says hey this block is bad it has a hack in it you have to do a new one maybe you don't have time to analyze again right so this actually could have some performance implications and there is actually a third option in here uh this is what we call SLS 3.0 I know we considered it sort of superior design to both of these or maybe to the second one where you actually optimistically allow any transaction to land in a block and you keep scanning and analyzing and simulating and if your simulation says hey this is actually a bad block. it does have a hack then you force a quick reorg.
Your analysis actually in fact is pretty fast. You know it will finish within those 500 milliseconds but sometimes it can take just a little bit longer. So this allows you to live in those situations when the analysis takes a little bit longer and comes back uh you know um bad. However, it can have some liveness problems uh and can enable DOS attacks. So it has to be combined with some counter measures and I might talk about that later in the talk.
So on zirkuit what we currently use is a combination of these two measures. Uh we use SLS 1.0 to actually take a look at every single transaction before it is uh being included in the meool. This is how we protect the mempool and then we follow with SLS 2.0 so so that we actually absorb the context of the block and roughly these days we are actually switching to this new architecture where again SLS 1.
0 O protects our meool and SLS 3.0 then you know performs uh the analysis just so that we can actually compute a little bit more because we would like to cool. So we got to the situation where we made the first design decision. We know how to architect the system right. So if we can spot a hack we know that we will not uh let it through.
So can we really spot and identify a hack when I show you a transaction? So how do we do that? I said that we use AI. So imagine that you want to train for yourself a model that discover hacks discovers hacks among regular transaction traffic and that you are starting a new chain. We started our mainet in August 2024.
So we didn't have any transaction history, right? And what still holds up up until this point is there is no project that was ever hacked on Zirkin. We've never seen a hack. So you know how could I even think about training an AI model that says this is a hack. This is where this EVM compatibility actually comes to the rescue.
I said that we are an EVM compatible chain. If you take a look at L2B right now today you will find more than 50 other EVM compatible chains that actually do have a pretty rich history. Over the past two to three years they have processed over 4 billion transactions and they did have hacks because mainet is there and all the other networks are there right so there we can actually take a look at the databases that exist for example slow mist currently includes 1,800 web 3 incidents in their database they are you know all across web 3 so not all of them on athereum but clearly hacks happened and because the execution model is the same it's still the EVM we can actually use these real world hacks that happened to train a model to discover um discover hacks on circuit. So the next question is how accurate can you get with this? The false negative rate that the models powering zirkuit achieve currently miss one in 200 real hacks.
That's actually really powerful because when you think about it, if all the blockchains in the world included such a system powered by these models, this number projects to saying out of those 1,800 hacks that are listed on slowmist that currently boil down to over 36 billion US, there would be only nine. That's actually pretty cool, right? Well, it's really easy to train a model that discovers every single hack. I will tell you how. It will say this is a hack and this is a hack and this is a hack and everything is a hack.
It will not miss a single real hack. You obviously don't want to use it, right? Because it will falsely be saying, "Hey, this is a hack to every single transaction." So what you really want to achieve in here is developing a model that not only discovers a lot but also you know doesn't suffer from uh high false positive rate. So the models that we use they currently uh in the theoretical settings uh achieve half a percent false positive rate which is already pretty low but in practice we are actually actually observing that this number is significantly better and it is because the regular user transactions they're actually pretty simple.
you really it's like a persontoperson payment you know deposit into a D5 protocol and so on and because they are so simple it's actually really easy to uh to analyze them and uh classify them. So those are the numbers. But here's the thing. Now you will actually want to test it. You will need to test this, right?
Because what I just told you is, hey, take data from somewhere else and trade on this. Train on this and now use your model over here and sort of assume that it works. Well, this is not true in the general case, right? So you will have to start testing because for example, your model might have learned something really really stupid. It might have been overfitted and it might have learned that you know no transaction ever has or no hack ever has the zirkits chain ID 48900 and you know it might just ignore those transactions.
So you may want to make sure that this is not happening. How can you do that? Well again there are hacks that happened in the past in the wild and you know you want to discover those hacks. So you probably should be actually testing using those real world hacks. This is rather complicated because those hacks happen somewhere else, right?
So you have smart contracts that were present on that particular chain that are currently not present on Zirkit. So you you know cannot replay that hack as it is and hope that everything is going to work. So you know here is our research piece. I am referencing some work that uh we have published at uh this year. It's together with people from Quanstamp and uh some academics from Australia.
But essentially we have developed a methodology that allows us to take a look at deployed uh D5 protocols and the hacks that happened uh there and migrated uh onto circuit. These are the types of problems that the methodology solves. You have a smart contract. It includes uh you know hard-coded references to other addresses for example, right? Some of them might be in in uh hardcoded in the uh bite code.
So they will actually be compiled in and perhaps you can automatically detect them. Some of them might not. They come in the form of the parameters during the constructor invocation or they are coded in the constructor and that actually doesn't get stored on chain. Right? So you will need to address all of these so that you can port hacks but we were able to do so and so we ported the entire damned vulnerable DeFi repository plus some extra fabricated hacks and we are running that periodically on all our tests plus the mainet because you know we run the sequencer we collect the sequencing fees we can actually invoke the test without you know incurring high cost and that convinces us that these transference issues do not really exist.
So I'm going to pause with challenges and thinking about you know how you can actually develop the system. I'm going to return to that at the end of the talk but I'm going to do a little intermission in here and I will keep you know thinking about what this system actually could be used for. This is my favorite one. It's fishing protection. Right?
If you're using wallets right now, almost every single wallet has some kind of a module at this point that says, "Hey, you should not be sending money to that address when you are trying to send money to a drainer, right? Or when you actually get fished." Well, these solutions that we have, they're great. They are honestly great and I'm very very happy that they exist in the wallets, but they are in some way a little bit imperfect, right? Because uh they very often work with uh obsolete data.
They use only the known list of drainers that perhaps are currently active on this chain and other chains. Uh they also use website reputation data, right? The age of the domain name, the similarity to other records, potentially other suspicious activity that is being reported across uh the web traffic. But this is web three, you know, you don't need a website to transact, right? I can do it from my command line.
You can do it from your telegram app. And sometimes you know even if you show the user the clear message hey right now you're getting hacked like please don't click this button they will click it anyways you know and then they are very surprised and sad. So this fishing protection onchain via SLS it's actually in some way complimentary maybe even superior depending on how you want to take a look at it because it can use all those means that the wallets use maybe ex except for the you know website origin and so on. So it can still employ static lists but it actually doesn't suffer suffer from the fact that it doesn't have access to the DNS record and so on because the payload it's actually enough even these like fishing attacks and drainers they do have patterns right it's just some random address that suddenly started collecting a lot of potentially substantial payments that are you know outliers with respect to the regular user traffic and all of this is available onchain and you can actually pretty clearly find it because you already have all those lists that are statically updated, right? So you can see what transactions are coming and again you can start detecting similarities and it works really really well as well and it also solves the problem where the user clicks the button and signs it anyways because this is as close to the blog production that you can really really get.
The other one is rulebased transacting. Imagine that you are a bank somewhere in North America and you really do not want to receive assets from North Korea. How do you right now prevent on Athereum somebody from sending you ETH? You cannot here you literally can right because you can include an additional analysis that says if address is not on my KYC list or if it is on an offack list please I do not want to receive these assets because I'm an institution and I cannot. We want institutions on chain, right?
We want the adoption, but they clearly have some hurdles and this is something that we can solve. So those are possible other use cases. Now I'm going to get back to the challenges for the remainder of the talk. So developing such a system, you know, I went through the major steps, but it's actually a pretty interesting and multifaceted uh engineering problem. So you will have to think a lot about uh synchronization.
The fact is that you will be running that centralized sequencer, right? And simulating and tracing it's actually not free. It costs computational cycles. It's actually quite intensive. So you will not want this sequencer to be simulating on its own.
You will actually be using some set of simulation nodes, but they have to be synchronized with the sequencer. Right? Imagine the sequencer knows about a block six. It's now forming block seven. And I have set of simulation nodes where the connection to one of them is broken.
It's out of sync. It only knows about block five. and I'm already sending it transactions for block number seven. Smart contracts might not exist. Nonsis might have you know moved that simulation node is probably be not going to be good.
So you need to uh tackle that. There is also this principle called forced inclusion. If you remember earlier this maybe even actually last year sonium uh they tried to uh restrict some memecoin activity on their chain but they were op stack based rollup with force inclusion capabilities. So it actually didn't really work. Clearly you will want to analyze all the transactions including those that you know went through the uh forced inclusion submission means and that will require some protocol engineering uh especially if you're thinking about the optack architecture.
So you will require some adjustments on the DA. Then I was talking about the DOS attacks. You know, basically what's going on is you are receiving transactions and you are analyzing them. And if that transaction is a hack, you're going to see, hey, this is a hack and you're going to throw it away. You're not going to process it.
So you're not you are not going to charge gas to anybody. You're doing this for free. And in theory, this could actually result in mounting an attack. So you need to engineer against that and include a preventative measure. Then obviously you always have to think about the user and developer experience right I now said hey there is a new reason why a transaction might not mine and uh you need to communicate that and then finally you know you will need toolkit for yourself for investigation there will be some decentralization topics and you will always want some new detectors right because the security field is moving hacks are getting more and more innovative here you have an opportunity to actually keep up.
That's everything from me. I really thank you for your attention. There is actually a lot more interesting stuff that is happening at Zirkit. I just, you know, dumped it here into the bullet points. I'll be here for the whole day.
I also have a colleague here, Joseeppe. We have a booth at the back, so feel free to drop by for a chat. But, uh, appreciate you being here. Thank you. [Applause] [Music]
Automatic transcript — names and jargon may be misspelled.