[trustless://interop.landscape] Doris Hernandez - Keystore Layer: Enabling secure, interop wallets

Transcript

Okay. And without further ado, please welcome to the stage Doris Hernandez. GMDM Dev Connect and Trust List. Super excited to be here and today I'm going to be talking you about key store layers and how they enable interoperable wallets. I just want to introduce myself. I've been in this space for a while now. I'm a product first developer and I'm co-founder of Functor which we are being pioneering in the development of a keyster layer for the past year. Um and meanwhile I've been in the infraace I've

experimenting with NPC to peer-to-peer networks and everything in between. And in that journey I made two wallets that acrew more than 650,000 users. But at the end of the day, what I realized that my mission and how we want to contribute as a company in fun network is to make self-custody usable at scale. So why a keyster layer exist in the first place? What's the current state? Smart contract wallets are amazing. They really change how we're going to be interacting with user experience and security, but unfortunately they break in this multi-chain world.

Why? Because of signer state. There is no shared account state between the chains. And what do we mean by that? Just let me break this down to you. EOAS or your wallets that you currently use, your MetaMask wallets are stateless. And a good example of what a stateless infra is is just like you were here in Bernocitis and you were grabbing a analog map, right? There is no state. If you you you don't need to be updating. The problem with it is that it's not connected to the internet, but if there's traffic jams, you're not able to see that. In contrast, smart accounts are stateful. And a great analogy for that will be Google Maps, right? You're able to update what is the latest state

of the traffic, but you need to be connected. So, because of this, smart accounts signers live per chain. So, what's going on right now is that you have the same address using create 2. So you see the same address in arbitrum, polygon, optimism, but the signer in each chain, it's different. Why? Because each blockchain stores a different contract to manage the state of that signer. And that is a massive problem if we're talking about UX security and most importantly adoption in the space.

So each L2 has its own smart account and its own copy of who can sign. That means that if you want to add or remove a serer, updating the state, you need to update the state in every chain and it's a nightmare if you add a new L2 because counterfactual accounts is just chaos. So, Vitalik realized this and in his one of his talks in the three transitions, he frames a fix for this where you actually decouple the assets and signer separation. So you have the assets in the wallet but the signer is not coupled to that wallet.

So what is a keyster layer? The keyster layer introduces a shared global state. A single registry of signers that every chain could read from. So I show you what it is. The core idea of this is to separate who can act from where the assets are. Now right now your assets are tied to a private key. Smart accounts decouple that and kisser layers make that global. Right now you have your assets and the vision is to have your wallet with different assets and a signer infrastructure the keys store that is able to decouple the signers and verify the logic of what you can sign. You have signature validations, access control

rules, recovery mechanisms and this is all accessible across all chains. So when you do this now you still have the same account address but your serer is still the same across every chain. Now you don't have these weird composibility issues that if kissers don't exist will happen in the future. So what are the outcomes which is what we you know it's really excited about. If you change your signer you have one keyster update and now everyone can read in any L2 the update of that signer. You have a new L2 launch it doesn't matter.

You just plug into the kester layer and you read the latest state of that wallet. It's pretty convenient. Think about it as an access control layer of what designers can do on chain. So the biggest challenge in key stores is to communicate the state to the other wallet like how can I know that I have the latest state of who can sign on the keys store. So I'm just explaining the highle architecture of what we've been proposing and researching and what's the best implementation for this. You have a key store layer contract in the L1. We call it the L1 keyster contract and that's the source truth of all the signer information. And then you will have an L2 mirror contract deployed in every L2 that will read the latest state of the L1. That's high level overview

how be able to communicate to all the L2s uh who is the latest signer. So reading the state there's certain things and this is where the industry has been researching on like how can we do this properly but at the end of the day there has to be certain components to read the state. So any design agnostic to what it is to read the L1 state on the L2 you need to have two ingredients the commitment of the key store state that means the Merkel root and then the proof of the specific key value. So a Merkel proof the design space that we've been doing that the ecosystem has been exploring are two you have the L1S load which is the one that you know a lot of people have been talking about. Uh and

basically what this enables you is it lets the L2 contract load the L1 storage directly. Unfortunately this still needs to be implemented by the L2s and it's not accessible. So what we have been exploring with funer has been using the canonical bridges today to use uh messages across the canonical bridges to manage the state in every uh L2. What really excites me and as I mentioned you earlier in the talk I'm a product first developer and that's the whole thesis of what we build here the infra that we're building and why we're so passionate about keyster layers is beyond the infrastructure but more about like how are we going to be enabling the EVM ecosystem to become more useful and secure in the long run and most

importantly how can become all a single place where users can interact this is where interoperable wallets comes into play with the keys layer all all Your wallets across all chains behave like one wallet. That's the dream. And the beauty of it is that keyster layers enable you that. Now you make interoperable wallets first class citizens in the EV EVM space. What are the things that you can do when you have a keyster layer implemented? You have native universal recovery which is something we haven't seen before.

That means that you're able to attach multiple signers. This could be your pass key, your phone, your laptop pass key, your EOA threshold signatures to a single account. You can rotate those signers and propagate the state everywhere. You have access to a global policy engine. Now you have programmable permissions to interact on chain whether you want to set permissions of who and what you want to interact. Interesting for the future of agents and automation because you're able to have programmable signers. you enable asynchronous transactions and thirdparty delegation.

And lastly, a lot of the things that we've been doing, what is the future as funer and that we envision for the users? Let me show it to you. Here you aggregate and connect your wallet and you're able to upgrade your RA account into a smart account using the 7702. Now, once you have smart account uh capabilities, you're able to add as much signers as you want. This is thankfully to the kisser layer infrastructure. The coolest part and what is really exciting for us is that now you're able to have session keys and programmable permissions that you can execute on

chain and you have a single viewpoint of how those ex of how those session keys have been executed. You decide in which chains they have permission and something extremely important is how can you integrate that permission to what application. You have integrations whitelisting of how you can send that programmable permission and you have now a single source of truth of your signers and permissions in a single place making it easier to interact on chain and making it more importantly secure for the end consumers.

And I'll close with this. By making walables interoperable, Ethereum becomes the most decentralized, secure, and resilient ecosystem of the world. Thank you very much. >> That was amazing. Doris, we actually have some questions from the audience here. So let's see what you can say to the audience. Question number one, does it make does it mean that the layer 2 nodes have to run keystone layer along with the node? Oh, they're going so fast these questions I can't keep track. If not, how is it going to work?

>> The L2 nodes the L2 nodes something important. This is part of the execution layer, not the consensus layer, right? So this has nothing to do with the consensus or anything like that. that this is more like a has a lot of components of an L2 but fundamentally just updating a Merkel tree state and updating the ses across lo chains and this is running on its own contract so it has nothing to do with the states of other L2s nodes in general >> okay next question how is the approximate gas cost for updating serer a serer will it send a message through canonical bridge for every chain even those that I don't use >> yeah it's a phenomenal question that's one of the hardest challenges in uh

keyster layer implementation. So right now we've been experimenting how that's going to look like right because how are you going to be basically batching the updates of that Merkel tree state? Is it going to be through a certain amount of transactions? Is it going to be timebased? And the the initial idea implementation is the end user is paying for those gas fees. Uh we need to understand better how it's going to look in the long term especially when you start adding more L2s to uh the infrastructure. Right now we are testing with a couple of chains two or three to see how the state propagates and the latency that it brings. Uh nonetheless the gas is involved to you know give the update to the states. Um it's something that there's still you know being being

developed for sure. >> Next question. Can you support all EVMS or only roll-ups? Yeah, we definitely support anything that is EVM compatible. Next question. Wow, they keep coming. How does it compare to previous or other keys store layer efforts? >> Uh great question. So when we were building these and experimenting the biggest unlock for us was understanding how to send the signer to the kester layer. So from a high level perspective it took us a while to understand how a current infrastructure smart account infrastructure can actually connect. We actually used the year7579 modular accounts and we actually created a web off module. We started testing with pass

keys. So different implementations from us is that we are experimenting first with pass keys. So that specific signature P256 that we need to validate. And that took us a real a long time to allow you you know basically preparate the user operation and fetch the signer uh and then preparate the the the signature using passi. So that's one of the differences that we did. Two is extremely seamless. The demo that I show you the first part is something that we actually implemented already. uh and you're able to attach multiple signers, pasy signers to a single wallet, which is something new that we haven't seen so far. Uh so that's one of the biggest components is our Uber focus in UX than anything else.

Fantastic. Doris, there's one more question for you actually before we let you go. This one is having one source of truth is convenient, but at the same time more risk to being attacked. What's your take on that? fragmentation is it's you have more risk because now you have to be keeping up what you're doing in every chain right it's like did I did my permissions in optimism and then I forgot that I'm doing this in arbitum oh I completely forgot that I didn't do this in polygon so you the more chains you have and more applications you interact the more things you need to keep up and that makes it very hard that you know in obssec how do you actually keep track on that especially if you become like cryptonative quite complex >> okay that's all we have time for today

Thank you so much, Doris. Please, a big round of applause for Doris Hernandez. She has some wonderful fans. You guys are amazing.