DAPPCON 2025: SKUL- Slim Keystore Utility Layer - Jerome de Tychey

Transcript

Why? All right. Hello everyone. Really glad to be here again this year. I'm here to tell you a little bit about our uh crosschain wandering adventure uh me at Kamoth uh and uh and all the different people that we work with and also to present something that we were cooking for the past uh for the past year called skull slim key store utility layer. Um so first off thank you for coming to my talk. Um I'll be hosting the Ethereum community the Ethereum community conference ECC in can in a few weeks. I hope to see you all over there.

Uh and if you want to chat if you want to reach out I'm easy to find always using the same endle at g.t like this. Okay. So just one quick word about what we do. Uh we have um anat abstraction SDK uh for heavy duty apps mostly. Uh we do a lot of R&D on pass keys. uh we implemented a few uh a few verification of the of the curve uh in solidity. We participated in various thing on that front. We also work on social keys on crushing stuff. You can find all about there. Um and we also are a custodian registered in France. So if you're looking for a compliant mica defi infrastructure, reach out. Uh we have a lot of cool thing to talk about. Um, and we run a a white labelled optimization

for treasury with Monerium called Louis. Finance if you want to check it out. Okay, so here's the plan for today. Um, we're going to discuss those four points. So, a a chain abstraction abstraction in production right now and going multi-chain. Uh, and finally, uh, a small contribution to going for better multi-chain with skull. Here we go. Um so this is where we stand. Uh personally at me and and us at KTH uh we are in a world of abundance of block space and we have a lot of challenges to tackle.

So what we what we think when we look at the oh a damn I had a few a few cool memes in inserted that was missed in the in the update of the of the slides. Well never mind. Um we believe in safe uh like smart accounts for everyone. We believe this is the right way to onboard and to run uh applications. We believe in pass keys because they are already available in every devices that the user will use. But Pisces pass keys to sign and not to login on a third party service for accessing the serer. I think it's much cleaner to use pass keys this way. But to be honest, the current status is that smart accounts in a multi-gen context uh with fragmentation

of the experience, with fragmentation of the liquidity is a bit hard. It's a bit harming the UX and it's also a bit slowing down the AA adoption unfortunately. But it gives rises to new challenges that we are happy to tackle. Um what's Yep. Uh yeah, here we go. So in terms of fragmentation, we already have 158 mainet layers that are listed on um L2B. A lot of more that are going to be released, a lot more that are not listed because they don't list themselves. We have countless EVM everywhere. And we have this topic of um uh use cases and complexity of reading state of reading information from one layer to the next

that have been discussed since 2022 2023. And we know it's a complicated topic and we are like kind of ignoring it in my in my opinion even if we just had a pretty good presentation from uh the guys at uh at Codbri Stephanie Cox uh that's are really inspiring in what the thing we can do right now. So here is a couple of stakes that uh I'm happy to uh debate with you over lunch or uh in the question session of this talk. Few hot to swallow pills. Uh first the EOAS really do not work for accounts for the average Jane and the average Joe. Uh they barely work as ser uh people lose their key. People don't understand the security model. Uh it takes a lot of

time to make them evolve toward this. It's also much easier for the web tree guy uh to go his smart account u that he already has some web tree some some way knowledge. He already have some uh funds on an account. It's much easier for this guy to find his smart account than it is for the web user to use anything but account abstraction actually. So if you are thinking about retail adoption, if you're building a retail app, like keep keep that to yourself. Um if you're not going abstraction first and not thinking the experience around abstraction, you're probably fooling yourself in the addressable market and in your customer acquisition cost.

Are we in a state of disillusion right now in account abstraction? So it's kind of hard to get um good data on account abstraction because not all account abstraction implementation are 4337 compliant. Uh there is a lot of work done at BundleB here but the the data are a bit um um messed up with some uh big actors like uh world chain in uh in world app that have arguably a few millions of users. So maybe we can say that 80% of the of the account with one user ops are coming from world app. uh if you take a few uh a few one it wonder a few scam and so on uh you end up with roughly I think in my opinion less than

four maybe 5 million users with all the legacy safes as well so yeah we we're still not there in term of account abstraction adoption and one of the reason why we are still not there is that there is a perceived complexity uh that's kind of hard to overcome we had a lot of debate on which smart account standard to use even and if we had safe for all of this time. Uh yeah, it's better to rebuild my own smart account because I'll go faster with this. Uh 4337 had a few updates. It moved a lot. Uh there is a perceived complexity behind this as well. Uh and once you start to implement accountant abstraction as the default accounting method in your application, there's likely no way back like you are into account abstraction and you have to

embrace it. So a lot of the a lot of the the large application in our industry have considered like an abstraction and said like hey it's not mature uh let's build my own wallet. Yeah it's not mature uh let's use a wallet as a service. Uh so it's kind of hard to piggy back for um the defy applications and uh and help kickstart the account abstraction adoption this way because they are busy fighting for TVL and web to users have proven to be very expensive to grab in um in their user base.

So what are the pioneer doing? What are the successful app in abstraction doing right now? So you have metry here with the circles implementation. So try it out at this um at this conference if you haven't had your metri account already. Uh it's smooth, it's beautiful, it's working and it shows how account abstraction can work at scale. Another example is poly market. They use safe, they use proxy account. So when you go on poly market, you just create a safe and use a safe. It's not directly showing into the data of 4337 because it's not using 4337, but still it's like an abstraction. And of course in terms of number of users and usage on the chain uh you have to mention what up.

So here is the problem that is looming the don't look up aspect of accountant abstraction. Here is Bob. Bob is a web tree curious. Bob's uh just on boarded seamlessly with accountant abstraction on circles with metry. Yay Bob is here now. Uh yeah. Hey to Bob. Thank you for coming to circles. Uh I'm going to trust you. you want to trust me back and uh we are going to action some CLC. Bob's transaction are sponsored. He doesn't have to pay any money to do any transaction. It's great. Um the experience is smooth. He's on noisy chain. He likes he likes the aspect of it. And he clicks on copy my address. So now he knows his address. Uh it turns out that Bob out of old account on Binance because he met a friend that

told him like, "Hey, crypto is great. You should buy $10 of it." And now he wants to withdraw his EH from Binance to the mainet or the Binance smart chain on his smart account. And then Bob rushes to the discord ask for help because his balance is not showing of course. So we experienced this firsthand at Kamoth with uh one of the game we were powering cosmic battle with over 100k players and we had this a lot people coming up like hey where is my balance? I just res optimism. Yeah but the game is running on an L3 on top of arbitrum. So yeah, it's not showing and solving this kind of problem is really complex. Last year at DPCON uh I had a talk with um at the ghostep with um from Frontier Research uh talking

about the the the cake layer. So you have the application layer, you have the permissioning layer, you have the solver layer, you have the settlement layer. Uh this is what you need to consider when you are thinking about crosschain crosschain communication gas abstraction of course liquidity unification around uh what you want to do between chains interlockchain communication as well and aggregating defy stuff. Um encompassing all of those problems you have a few uh tryyouts in the industry at particle network layer and so on. Um and most of those application are trying to uh en encapsulate this complexity and expose uh good endpoint to to tackle that but it doesn't really translate

directly into a kind of fraction unfortunately. So we were lucky to have one of our tryyouts being funded by nosis guild. uh we used the resource lock module to expose this kind of cake approach for multi-chain crosschain interactions via the resource lock um it was good it's working uh you can use the resource lock module to say hey I want to have if on arbitum and I have if on optimism so let me lock up the if on optimism create an intent that I want to receive the if on optimism sorry on arbitum and uh if you fulfill this intent you're going to get the money out. This is cool, but this is not super duper scalable because it's more of a of

a of a push model than a pull model and thus uh it creates some uh some discrepancies in the in the UX. So, this is what has been driving our R&D trying to bring the control of your smart account everywhere for everything and all at once. And one of the problem that it bring up is how to properly read across L2s. How to properly prove that something happened between layers. Uh and this is why uh we love the thing that Kibri is doing on on that front. So one of our one of our achievement for last year was to try to think about this problem at larger scale. Uh thinking about how we could potentially index on an application layer um the whole

history of all participating chains. So storing the block headers of any layers of any blockchains and trying to prove the recursively through uh hash trees the inclusion of specific transaction the the particular um storage at a particular state for a particular account and so on and well unfortunately it was kind of hard to rally people around this idea and to find um and to find funding to continue this kind of R&D but we are keeping that uh on the on the stove uh waiting for it to be uh mature enough for the industry to kind of adopt this kind of approach and by pectra we had 2939 that gave us a lot of access to uh historical uh information

in the block hashes. So there's still things to do regarding this uh kind of multi-chain indexing and industry proving. Um we tried to implement that as a uh safe module uh just so that we would have um a primary, secondary or a master slave relationship between uh between safe like relying on Ashi notably to um to pass the messages across multiple different oracles and arbitrary message buses. So you have a a message uh that you want to convey uh on chain B. you have a safe on chain B, but your safe is being activated from chain A. Uh we managed to implement something that was kind of a not a not even a prototype but

kind of a proof of concept and we really wanted to to be pushing forward towards having a a pool module like you're on chain B you want to do something you have funds on chain A just do something and get that running so that brought us to the approach of skull here. So, slim key store utility layer like a small module for every smart account that you can easily rely on that allows you to manipulate your funds on any chain that your smart account is deployed on from a reference chain where the skull is deployed for your smart account. So, as it's been kind of hard so far to uh bring up this

big idea of having all the different EVM flavors indexed at the same place so we can have this proof that we can carry over to any change that we need to. Uh we're trying to do a a smaller step. Let's do that as just a small uh module that you can put on any smart account. Here are a few design rational for that. Uh we rely on storage proof. So we had a question before on uh the overhead on of the proof um on on the talk about Calibri. Um storage proof typically give you an overhead of 250,000 gas which is what you need to prove that the uh a specific transaction a specific state was actually included in the reference chain. So you can trust it. We

believe that current effort about zik proving the EVM will ultimately lower that and uh and accelerate this kind of adoption. uh we may have some op code optimization at some point. So for proof validation it will likely accelerate. So that's likely your highest threshold here. The trust model for this kind of approach is typically the trust model that you have on the reference chain. The worst cases are some delays. Uh arguably there can be some uh reorganization if you deploy on uh the L1. Sometime you have blocks that are reorgs but yeah worst case is mostly delays uh in our opinion. But happy to discuss this kind of trust model later on and you need to rely on an arbitrary message buses. So from our perspective those those tools are kind

of mature right now uh and available for production. They are available for multiple DeFi applications that are relying on them to do crosschain stuff. Uh chain link and USDC across chain are a good example of that. And the readiness is here. It's ready. It's ready for 437 smart accounts and it's also ready for uh 7579. So from a L1 to N2 standpoint uh you have access regularly to the state root infos u well every time the the the L2 uh sequence in the L1 uh you have exchange of information so you can recursively do these proofs regarding L2 to L2 it's a bit more tricky uh but there are ways to

do uh to do it and this is why we thought initially that uh a a layer to index everything and to um and to create those proof would have been uh pretty cool as So, here's what it looks like. Um, you have Bob on uh on chain B uh is looking at swapping uh E to USDC. Uh he has a safe on chain A uh or a smart account on chain A. He's multiple owner. He's one of the owner and is a a a big enough holder, a big enough owner to actually trigger a transaction. The safe on chain A does have this skull module implemented and you have some off-chain

services that will generate the proof and pass the proof. So for Bob's interaction on chain B just swapping E to USDC, Bob's creating this intent that will be a user on chain B. like any user Rob uh except that you have an extra information about the storage proof that Bob's uh wants to do that and is allowed to do that. And voila, Bob can now uh pull the information from chain A and do something on chain B. So we go to on demand action for crushing of smart account interactions.

And uh yeah, this is it for today. I'm happy to take some questions. If you want to read more about skull and its implementation, here is a link to a medium post by Frederick Deat, Yuan Salver, and Vincent Legalik that shows how it's implemented, give you more detail about skull and why why we went this direction. Uh, and the code is of course available for you to check out. It was freshly published two weeks ago. Uh, we think it's hard and ready for production, but uh challenges please, we'll happy be happy to uh answer and u and uh improve the model with you guys.

Thank you for your attention. [Applause] Thank you, Jerome. And we have a few moments. Uh maybe actually one question up here. Damn it, thank you for the talk. Um I wanted to ask you mentioned that um the worst case um in case of like reorganizations would be delays but how is that the case? How is the case that you can you don't need

to wait for uh for instance roll up chain finality to make these transactions? Yep. Um so regarding rearchs um yeah you should take into consideration that uh as a as um as a solver as a as a crosschain actors uh before you take an intent you need to well trust that the intent will be fulfilled uh normally. Uh so typically if you look at uh uh $1 million being moved from one side to the other uh you may want to wait a few blocks before saying like hey this is the this is a cool a good enough

reference block. Uh this block has I don't know 10 10 10 blocks of age. Uh so there's very unlikely that this will be delayed and reorged sorry and so I can trust this one. Um so typically what we recommend is uh that before uh you interpret a storage proof as a reference proof that uh you can act on uh you should wait a little bit that uh this uh this the the storage proof is actually showing from a block that is old enough uh from your security considerations.

Nevertheless, uh when it comes to uh to uh the L2s, uh well, you do have to take into consideration that uh not the not all the L2s are the same uh in terms of uh fraud proving and uh and potential uh potential centralization points. Um so yeah, do your own research regarding the the L2 that you consider. Uh but when uh let's say B is uh sequencing into um into the L1 uh you can take uh you can more or less take it for granted that what B just wrote in the L1 is here to stay and that B won't change its uh

state to something else because they decided to reorgively and go back from uh the previous state that they uh previously sequenced. uh so there's definitely some consideration to take here uh in terms of security but overall the zkification the zk proving of the EVM all the effort that are going into this direction will give us much more clarity and much more um security regarding the question communication overall but that doesn't mean that this kind of approach won't just adapt uh to the new state when we get zig proof everywhere