On the security challenges of L2 and L3 AppChains

Transcript

Hi everyone, thanks for coming. I know we see heart of the lunch. So I'm Michael from Starkware uh exploration team and uh today I wanted to share a really short keynote on something about application uh chain security which is well known and uh quite maybe quite obvious but still I believe it's not covered enough not repeated enough and uh yeah I just like wanted to do that to like once again remind what we're building here and uh Yeah. So you can fi most information will be high level. You will find you can find a more deep dive materials uh published by L2B which are

by the way doing guts work by keeping L2 accountable and also uh sharing education materials. So huge kudos to them. Uh small observation. So I I used to work more closely with the rollups tech uh years ago and when I was preparing slides I thinking oh god it's like it's it's years we're still talking about settlement DA execution fraud proofs validity proofs and it's like the same thing not that exciting anymore which is probably a good sign which means that like overall we are we are more mature than we used to be. Couple of words about starware and why we even talking about upchains. So you might probably know Starware as the core entity behind Starknet the layer 2 on Ethereum but

actually the first product uh that was shipped was the uh upchain engine called Stark X and I think it's yeah like this month it's five years that is in production. It's a tailored made uh validium step uh framework that allows to trade spot per uh to do payments and now it is not maintain not developed. It's superseded by a more modern rollup stack. It's called stacknet stack and uh essentially the similar code base that is used to power stacknet. You can also use it yourself to launch any application and uh there are ro as a service providers that that can

uh host that info for you and uh at the moment uh you probably know paradex one of the top per exchanges out there that are running on the stack. Interesting thing about stark and stack is that uh different parts are maintained by multiple community me uh members and uh this is pretty cool because it's kind of like improves the overall decentralization. So it's not just darkware that is the main maintainer. Uh okay so upchains are cool and we see increased interest in 2024. Now it's a club season and it's a race who would overtake hyperlquid maybe it's going to

be Robin Hood someone else but like generally if you think about it why would anyone launch an upchain in 2025 and uh what can be like legit reasons so it can be performance arguably this is not that much bottleneck anymore we can get thousands uh hundreds thousands TPS from public chains we can get pre-confirmations for better user experience we If the problem is competing for resources, we can use something like Zika threads. Uh so this not necessarily like unless it's like a really specific use case, not necessarily a problem.

Sovereignty uh it's quite vague uh the uh I think like one of the important aspects is to to have something the opposite to credible neutrality which public chains tend to care about. Right? So what it means in simple words is that you are able to do reworks like if your let's say like application is hacked uh which you cannot do like on the public rollup of course and like overall be able to make decisions that are in the interest of your of your application and the users of your application soly.

So privacy privacy might be not a popular take but arguably this is the only way to achieve scalable privacy uh right now. uh by just withholding data through data loility committee or use encrypted DA. I think a veil is is working on something like that. Uh so privacy maxi would obviously say that this is and they are probably right in some sense. Uh but like unfortunately any privacy solution we have right now confidential transfers or privacy pools like Zcash like circuits it's it's it's it doesn't scale. So it's okay for peer-to-peer transfers. It's not okay for payrolls uh payments at scale etc.

Lastly, MEV. So if you suspect that the public roll up radar front run your users, you want or there is a alpha leakage through public meool, you might want to capture me yourself or use any of the solutions like tees uh that uni chain uses or threshold encryption. though I'm not sure if it's actually anyone uses in production then it's it's a good reason to to go with your upchain uh controversial take but probably it's I mean at least it used to be easier from what I heard to to race if you launch an upchain rather than the public I don't think it's it is the case anymore

uh so the kind of like the main message that I wanted to send is that okay there is a good reason why I wanted to launch an opchain when you choose the stack. It's it's like really important to think uh about it because not you cannot just like take any stack that public roll-ups use and expect that it would work for your for you. Most likely it won't be the case unless you're like Robin Hood or Uniswap. uh I mean like a like a really large entity and uh today uh we have a like multiple role as a service providers that show you a nice constructor where you choose a u uh like a your proof

stack slap a DA some like options and uh just like run it and uh it's like it's super nice super easy but it it hides the subtleties that are very very important And um it might be that the system that you get in the result is not much secure than the AWS instance and then like why why even care. So um yeah I just like wanted to to go over the uh most important things I believe.

Uh again so this is all well known. uh there was some like several published paper uh research papers were published over the last two years and uh but I believe so this is not uh repeated enough and um yeah we just like we I think we should do better job at making this um publicly known um thing state validation most important uh it's either you choose to go with a fraud proofs or validity proofs with

optimistic rolls or validity rolls accord um respectively. Uh the issue that immediately occurs is uh if you are not uh if your your upchain doesn't secure that much value you you might end up having costreward imbalance which means that in a fraud proof's case uh you the cost for uh monitoring are disproportionate to the secured value which makes it economically irrational to even stay on the gu guard. This is get this gets more this gets worse because veterans would

rather choose to rely on others to do the monitoring or just opt out because why care if everything seems to be fine. Uh so finally some app chains choose to even reduce the set of the entities that can submit uh challenges like world for instance. Um, so it's like it's even it reduces the security even further. So in other words, if it's really it's really non-trivial to design a properly working fraud proofs if we're talking about low value application chains.

Uh validative proofs is a much more simpler system to reason about in ter like from the security perspective not from the from the implementation although I I would argue it's comparable these days. uh still it implies some issues with the operational costs which are which are much higher right because you need to generate proofs you need to submit them offchain and verify which pushes you towards pro centralization right so it's it's not economically uh feasible to pay let's say to a prover network um but what you can do but this will improve right because like prover

uh new provers uh systems uh come and they are cheaper, they are faster uh sue air bender. So you probably heard these names. Uh you can also what you can do these days is you can improve your costs by sharing them with others. differences in starknet ecosystem. Uh starknet and all the upchains that are running on either starket stack or starkex uh share prover and verification costs right so that you don't like none of them pay for them separately.

Now dataability so if with state transition it's kind of binary choice and it's like with the upchains it's kind of obvious. So with the data you have more options and um the popular choice is to use a specialized layers for data ability like celestia veil uh aen and uh while it's it's it's much more expensive like several magnitudes like several orders of magnitude expense more more cheaper uh it uh it naturally has some downsides.

In short, the security of your app chain reduces to security of the datability layer you use. And this is not immediately obvious to the people that that use your app chain. And uh but even more important aspect is that you um it also reduces down boils down to the security of the bridge uh between the datability layer you use and the settlement layer which is typically Ethereum. And if you take a look at L2B the other step which is newly introduced you will see dozens of chains that do not have operating bridge uh which is understandable because uh I I I had experience with blobstream for

instance and it's it's really really not straightforward uh it's really hard to integrate uh especially with with some some of the proof systems uh but yeah I mean if if you choose this opt the running bridge is an absolutely must I believe and so another aspect which is also u it's not immediately obvious but also important is that for instance the cist itself relies on fraud proofs for its security which makes the end finality of your entire system longer and it's it becomes like really really hard to reason about the overall security

is like really complex and fragile system. A more pragmatic uh and like arguably less secure option is to rely on um on a datability committee. So a permission reduced set of operators that hold your data and um um return that on demand and here you rely on the honest majority. Uh and essentially the the your users the users of your upchain can only withdraw if you maintain this honest majority. And again, so uh you will see on LCBs that there are dozens of chains

that have this label low duct threshold, which means that let's say it's only two or three, sometimes is even like one out of one parties uh that you should rely on to to to get your data. So it's it's it's not a good option. Uh so we should note here that I already mentioned that with community you can achieve privacy uh specifically compliant privacy where you can um like in case you have a like request from author from authorities so you can provide them with the data. Um so in some cases where let's say you have an institutional app chain or um something

similar so that that may might be a working option. So finally the most secure uh approach is to use Ethereum blobs which is also the most expensive one. And uh so here if you take a look at the chart when um what is the consumption in bytes for different rollups on Ethereum. So you would see that it's mostly for optimistic rollups. Well, obviously because there there's more volume there right now, but also because uh state divs, which is what validity rollups uh publish are much smaller and also they compress really well, especially if you

do if you squash the state state changes across multiple rollups and that's typically the case because you settle not for every block but every several hours. Uh so lastly if you run as a layer three you can also enjoy blob sharing because essentially you you not you don't have to pay for the blob space you are not using. So lastly uh I think really underappreciated uh thing is escape hatch. So how you withdraw in worst case scenario and I believe last week there was an issue with some uh real war assets chain. I don't I don't I don't remember the name.

I think it's still like half a million locked and uh the sequencer goes like off offline and uh though they have like mechanism for self-proposing self-sequencing it's not it's not that secure. So uh you would really wanted to have like one or another approach to do withdrawals. So for instance in stark kegs there is a built-in there was a built-in mechanism for application specific withdrawal that was used by the yx version version 3 but you also have to think really really well about exit windows. So exit window is not a meme.

So it has to be compatible with uh whatever the state finality or proposal rotation you have in your system and of course so the the size of the security security console that can do upgrades matters. Uh right so this is kind of like a really simple checklist uh I guess that can be used both for um upchain developers and for users of those upchains. And uh the I think the takeaway is that unless you are u Robin Hood or like unis swap like think like about whether you really need an upchain and if it's like absolutely necessary thing so you better go with a validity stack use blobs and make sure

that you have a exit um escape hatch for the worst case scenario. Um thank you a lot. So I I mean there are now like a lot of insights but I guess it's like important to repeat this over and over to remind ourselves like that's this is like the original values of Ethereum right. So if your system is not secure it it's not Ethereum and it's it's not really you know like crypto. So yeah let's let's let's remember that. Thanks.

[Applause] Thank you very much Michael. Uh raise your hand if you have any question. Hello. Thanks for the talk. Um just a question. How does this darkness tack handle uh the escape hatch or censorship um you know live the livveness problem more? Yeah thanks. So uh for this starknet stack I mean like an like unlike starkx which had a kind of application specific mechanism like a merkelized balance tree. So in uh starket stack you don't have a uh generic mechanism because it really

depends on your application. So you either have to implement that for your application yourself uh or you you you can use the force inclusion mechanism that is also now used uh on the public startet instance. So you can force inclusions through layer 1 and there is also uh like a mechanism to change the um the block proposer after a certain uh period of time. Okay. Okay. So the solution if the the main sequencer dies is to just roll out your own and uh yeah I mean so it's it can be like both. So right so either you have a generic mechanism which is like self-proposing self-sequencing

right or you do application specific where it's it's it's possible to withdraw through layer 1 by submitting some proofs like evidence that you own this balance like okay thanks thank you very much. Uh is there any question? Thank you very much. [Applause]