Richard Meissner (Safe Research) - Safenet: A transaction security protocol

Hey. Hello. Welcome. Um I hope you're all happy to be here, as happy as I am. I really enjoyed ECC and on very sunny place near the sea, and it's sadly already the last day, but for most of us, I think the last day is a very interesting day because it's security day.

And I'm Richard. I'm part of the safe research team, and in the last couple months we have been working on SafeNet, which we designed as a defense protocol for self-custody. And yeah, I want to give you an update what we have been cooking, and want to start out with why did we even do this? Why do we think it's necessary that we need another protocol for security? And yeah, if we look at the current state, we can really see that the UX in web3 is like evolving.

You can do more stuff, a lot of complex stuff, just by one click, it gets nicely encoded, but it's very hard to understand what is actually happening. We do have quite some checks for this, right? Like if, for example, on the safe wallet UI and most other wallets, you execute your transaction, you get this nice you're interacting with a verified contract, you there are no threats, only certain balances are changing, but most of these checks only happen on the UI layer. And we had to learn the hard way that the UI layer can be compromised, and if it is compromised, it becomes really hard for the user to really understand what is happening because on most of their wallets, this is what they see, and it's like, "Hey, please read this and sign this, and hopefully you know what you're doing." And this is really where we think like with smart accounts, suddenly we have a tool that allows us to really break into this and provide another layer.

And um in the smart accounts, in the safe smart accounts, there's this paradigm called guards, which actually work that you have before and after an execution an additional check that can check what does a transaction look like, what does the user sign, what state did it change? And this is not only specific to safe accounts, this is actually in most smart accounts standard present, where it's called hooks or modules in some others, but this is a very universal tool, and it allows us to do nice stuff like time locks or cosigners. And these are really useful, but not commonly um used so far because they are hard to use, right? And if you look at time locks, for example, kind of relevant when you look at news around crypto in France, sadly, it is this point where they can give you a deterrent against wrench attacks, because if suddenly an attacker has to wait a week before they can access your funds, the whole game changes how long can they hold your hostage. The another thing that we see are cosigners.

And cosigners are tool where you can have a third party that checks and verifies your transaction, and that this doesn't happen only on the UI layer, but really inside the execution layer, inside the guards. The challenge with cosigners is that like what is a good cosigner, right? Like we they are quite some solutions out there, there are some integrated in the safe wallet UI, um namely like Hypernative, but many of these solutions are very permissioned. So they are centralized tools, you have to apply to them, you have to pay them. Actually, the trans uh the transparency is very limited.

Like what do they exactly check, right? You can ask them, they will not give you their trade secret. It is their trade secret, right? And also the accountability is there, but it's very off-chain if at all, right? Like you kind of have to use your legal contract to sue them and hope that you win.

And this is something that is not scalable. And it's also not scalable when we think about like, "Hey, we see there are more chains, chains are spinning up, chains are spinning down." And all of these are waiting that one of these permissioned tools supports the new chain. And this is this is not the flexibility that we need for the current ecosystem. And as mentioned before, if you want to set them up, most of them again require you to sign some transactions that you don't understand, configure your guard, and it's massively complex.

Looking all of at all of this, we can see that these security limitations can or will become a growth limitations. Because if users don't feel comfortable, if self- custody like if there is no trustworthiness and no security that scales, then self-custody will not scale. Users will not use self-custody at scale. And if we don't solve this, this will become a hard blocker for our adoption of self-custody. Yeah, and that's why we started building SafeNet, and that's why we launching SafeNet in a beta state today.

So, what is SafeNet? So we designed SafeNet as a last line of defense, right? Like we um it is a consensus protocol that is on-chain and that gives attestations that can be used in a guard. It is basically decentralizing the cosigner role, so that it is not permissioned, that it's not accessible just to an exclusive group, but everybody can use easily the cosigner logic. And that it bridges the gap, that it prevents this gap between intent and execution.

I'm not sure if how many of you listened to the talk from Vitalik yesterday, and he was mentioning this, right? Like AI is omnipresent. AI is a tool that we have to accept that it is there. And it can be good and it can be bad. And on the good side, it allows us to build easier transactions, but uh and to interact faster, but Vitalik at the same time said, right?

Like for critical actions, the user should be the one that ultimately approves. So we still have this gap between the intent and the execution, where SafeNet for us is also a bridge to bring this closer together. So, what makes SafeNet different to the all existing solutions? And I think when we look back at the earlier checks that I have shown in the screenshot of the safe wallet UI, it is really this point where we move the security from a UI pinky promise to the protocol level truth, right? Like it is enforced, there's no way around it, it's not that your your UI gets compromised and suddenly that's disabled.

No, you put it on the execution layer. And this uh furthermore, it is set up in a way that you can easily take it and run it on other chains, across all chains, and it's theoretically even possible to do this independent of EVM chains and um scale it across all the different chains that there are. And one of the things that is for us important is that there is accountability um built into the protocol, since we want to strive for democratizing the cosigner role. People have to be held accountable if they don't do their job, and there needs to be a protocol which is also a path towards a sustainable security um protocol. So, how does it work?

And interestingly enough at ECC, I have heard multiple talks, way more than I expected, about FROST. Um So, I might repeat certain things that we have heard so far. And um but what we have to say like at the core, we use FROST, and FROST is a round-based threshold signature scheme, right? And we see that our validators, so the validators that act and attest transactions, they are basically the set is represented by a FROST public key or FROST group ID. And we track this on-chain, and they together then generate the attestations um that you can then so the attestations are signature FROST signatures, and you can use them on-chain to check them in a guard or in a hook, however you want.

This since this is such a like this cryptographic property makes it very nice that you can just take the signature and utilize it on any other chain as long as you know the public key of your validator set. And this makes it very scalable, and since we also want that you can rotate your validators over time, we actually use a very common approach that is utilized by many blockchains, where you can basically have epochs in which validators change, and you basically create this validator set chain. And each current validator set basically hands off towards the new validator set. Um this makes it possible that if you go to some other chain, you actually only need to know this initial genesis validator set, and with this you can validate any um signature across the other chains very permissionlessly. Another very, very nice property of FROST if it's used with um EC keys is that you can very cheaply verify it on chain.

So far, a lot of the solutions where if you want to use large validator sets have been very expensive, but with FROST you can combine them together in one signature. It's basically as cheap as adding another signature towards your um transaction, and it you get the verification from a whole validator set. So, how does it work in the consensus level? So for us, it's important that we want to be able to scale to larger validator sets, and that it is a very deterministic consensus. So in this case, there is no ambiguity.

There is it's very clear what is right and what is wrong, right? Like it's like the everybody has to do the Caesar moment um from the validators, they have to say this transaction is good, there's no security risk, or this transaction we should not attest. And this because it's so deterministic, we actually get a uh Byzantine fault tolerance of 33%. So that means up to 1/3 of our validators can behave maliciously. They can try to actively um work against the protocol and it will still hold and it will not fail the protocol.

Even further, you can say that if validators just go down, like they are offline, it's not that they behave maliciously, it's can even go up to half of the validator set, so you always need strictly more than half of the validators to approve a transaction, which makes it really that this protocol can continue working even so if certain validators behave maliciously or go down, which is for us extremely important because we don't want our to just security should always be present. We you should always be able to utilize it. So, if you look at the flow um how our protocol works, there are three phases. The first phase is the setup phase, the second phase is the attestation phase, and the last phase is the um enforcement or the execution phase. In the first phase, it's really about how do we set up the distributed key generation.

I think also the Kohaku team also yesterday presented a nice prototype where you could see how um Frost setups have been used. And in general um what we are using here is that it's an extended Patterson um distributed key generation, which is very important for us in this decentralized context because it allows us it brings us two nice properties. One is that um we get a proof of possession, so we actually know that the shares that each of these validators create that you can prove that they own the share and that they can utilize it. And the second one is that most of the DKG protocols are quite chatty, so they require multiple rounds and we can reduce this down quite a lot um like to two plus minus one depending on the how you set it up. Um So, in our setup, we have in our consensus, we have different roles and one of the roles is this Frost coordinator.

And to set up a group, we go to the Frost coordinator. We say we want to set up a new group and that then basically is a signal for the validators to get into action and publish their proof of knowledge and the commitments that they want to participate in this key generation. Once all of the validators that want to participate in this group submitted their uh these proof of these information, then the next part is that they encrypt the shares that they share with the others so that we can then deet um like distributed generate this um our Frost key. Here, because we're in a very distributed setup, after we have built up Yeah, then we build our verification and signing share. As soon as we have this ready, now we have to say, "Okay, are we really ready to sign?"

And this is one extension that we had to do because we are in this very centralized uh decentralized setup, is that we signal towards our Frost coordinator that our keys are ready and that we want to use them. If this doesn't happen, there are some fallback negative flows with challenge graphs and so on, but I leave them out for simplicity here. If you want to read them, we share documentation later. Um but yeah. Once we have this group ready, we can now actually signal to our consensus, "Hey, this is a new validator set represented as by this group ID.

Let's hand over control to this new validator set." And that brings us to the second phase, the attestation, because it's not only transactions that need to be attested, it is also this new group that needs to be attested. Again, we start out This time we start out at the consensus level, right? Like we propose the information that we want to get attested, which then triggers our Frost coordinator to say, "Guys, you need to sign something." As soon as this happens, the validators spin in and it's important here to see that validators have two steps that they need to perform.

This is one of the advantages of Frost. Also this, we hope that we can further optimize this, but currently the two steps are that first you commit to the nonces that you want to use for signing and then that you use these nonces to create the signature shares. Why is it important that it's two steps? It's because currently we do this on chain, so it means we have at least two blocks on which we have to interact before we get the final signature, which is basically the attestation. And depending on your block time, uh this basically dictates how fast can you get an attestation for the user.

As soon as we have this attestation, now the magic of smart accounts come in, right? Like we can do the enforcement. We can use this attestation inside a guard to enforce it on chain that you can only execute transaction if this attestation is um present. And the first thing what we have to do is that we have to take this attestation and bundle it together with the signing information of the transaction. So, this normally happens off chain.

You pull the information from the safe transaction service and prepare it to submit it to the safe smart account where it then invokes the guards and the guard can then check this information of the attestation and the transaction. For this, it first recovers the group ID and the from the transaction details and the attestation and then verifies that this group ID, so it's basically an easy recover, and then you check that this public key that results in this, that this is actually part of our validator set um that that we have that we know, right? Like that it is part of our chain of validator group IDs. And only if this holds, then you really execute the transaction. So, this is a very I have to speed up.

This is a very strong guarantee on the execution. So, where are we right now? So, at the current state, we launched the network. We enabled staking of safe tokens to bootstrap the economic security of the network. We are running with six validators right now in a permission set.

They are run by ecosystem partners and the safe the safe companies themselves. So, it's Greenfield, it's Gnosis, it's Blockchain Capital, it's Rockaway, Safe Labs, and the Core Contributor Stream GmbH. And as our consensus network, we use Gnosis Chain. So, all of the contracts that I mentioned earlier and the block times as 5 seconds on Gnosis Chain, this is where we execute it. So, what can we do right now?

Actually, the current validator set performs very static checks. So, we check that there are no destructive delegate calls, that there are no unknown modules being enabled or guards, and that there is or that you have a malicious fallback handler. And as a result, you already right now get quite some baseline security that you couldn't enforce in guards. But that is not enough, right? Like this is just very much the start.

Static checks don't uh like they don't protect us against everything, and that is why over this year we want to advance these checks. We also want to release the guard in a with our security standards of audits and formal verification. Um because that is what we think is required to also then ship it to the public with a wallet integration and with some initial fee implementation. But we want to go further beyond like these just static checks, no matter how advanced they are, and we want to create this transaction checker markets where we can integrate third parties um security checkers like our partners Hibernate, BlockAid, and all the others that we know in the ecosystem. And once this system is set up, then we feel we are at the point that we also transition from a system where it's primarily you are incentivized by gaining rewards that you actually introduce the accountability on a level that you lose something, you lose stake, if you do something wrong.

Oh, um that is a very unfortunate typical thing to happen. The last slide is missing with the QR code. That

[laughter]

is um unfortunate. So, generally we would love if you can reach out. We We are looking for people that want to participate as security um checkers, that want to integrate this, that give us feedback. We're in a very early stage with a beta network where we want to see that the throughputs hold, that we can validate all the transactions from safe users before we scale this further out. Um so, if you're interested in running either a validator, a security checker, want to integrate it, or just want to chat with us about where we want to go and why this is necessary, yeah, please reach out to us.

Happy to share more information um and look at the Safe Foundation page since I cannot show a QR code. 2 minutes. I think we have time for one or two questions depending how long I take to answer. Who says a question?

[snorts]

Thank you very much for the presentation. Uh I have one question. How much censorship is happening on the validator level? Because making sure transactions safe is one thing, but what do you define as safe? Is interacting with Crime Enjoyer V2 safe if I want to do that?

Tornado Cash is another one. So, yeah, at the current state, right? Like it's very, very deterministic where we say you can look at our repository, you could look at the implementation um what is defined as as secure, right? Like and this especially if you look at these modules in the current state, you have like some lists and you would have to convince us that we should put you on the list. So, yes, it is permissioned, right?

Like it's Again, it's in a beta state, but it's exactly this point where we say we need we need third-party checkers where we say, "Okay, they have very much different criterias." And we have to find this balance where do you say I choose which security checker um do I trust or do I also want to give information to, and where do you say oh, it needs to be the whole system, right? Like everybody needs to confirm. And I think this is very much it is the topic that we say, "Okay, we when we move from the static checks to the dynamic checks." Because it's not only important for the censorship, but also for privacy because if you want to do selective information sharing because you don't potentially want to expose the transaction to the whole um eco public, then this also becomes apparent.

So, long story uh short answer is there is definitely some permissionless which might be used for censorship, but we want to go into an open system where we find the balance where it's where as long as you find one party that approves it, you can get around this. Nice. I think my time is up anyways. So, if you want to chat to us, um you see people running around with safe logos on their t-shirts or hoodies, um talk to them.