Beyond the Cron Job: Eliminating Single Points of Failure With Automation

Transcript

Hello guys. Can you hear me fine? Yep. Great. So, uh welcome. Um this talk is called uh beyond the crunch of eliminating single points of failure. Um well, thank you for the organizers to for having me the chance to to speak here. Um my name is Fakospanola. I'm one of the co-founders and CTO at Mimik. We've been working this space doing automation uh for four years now. I've been in this space for a long time. Um I started as a security researcher and engineer at opening in 2017 and then I contributed to many different projects like balancer Aragon the graph and four years ago we started mimic [snorts]

um let's let's begin with a with a talk. So this week uh in one of the panels I was asked if users actually cared about decentralization if if there was actually something that the users were um willing to pay for or to suffer for um if they do actually care. Not sure if you know this guy, but Mariano Kand is one of my closest friends here in Argentina. And in one of his Devcon talks, he said that decentraliz decentralization doesn't matter until it matters, which is actually right.

And the the answer that I gave to to the question was that in my opinion, it's a somehow a trade-off. Um, of course, you are always dealing between this trade-off between user experience and uh security. Um I remember back in the days where like around those ICOs in 2017 like everyone was building a project on top of a blockchain they were basically trying to decentralize everything. I remember like huge architectures of smart contracts um in order to implement this type of projects and it was kind of a nightmare. I remember also like dealing with um UIs being served through IPFS which was uh like a really bad experience. I think we move on somehow and this is not happening um nowadays

but the lema is still uh the same like not your keys not your crypto and probably this is something that you may not think uh since day one uh I mean or maybe you will not implement since day one but at some point it must be part of the of the road map and you need to be prepared ahead of time to make sure when you're going to actually to commit to it and how you're going going to implement it also So it's not just for the users. It's not for them to be secure or safe. I think it's also for us for the builders. Um in my opinion like thinking about decentralization is a way to sleep at night. Uh thinking about not having custody of my user users funds. It's

something that keeps me um in a better place. I think [snorts] have we seen probably we're all aware that hacks these days are not um all about the smart contract vulnerabilities. Um we've been we've been seeing like well fishing the NS hijacking like uh social engineering uh many different things that are going on these days that are not just about smart contracts being hacked. The thing is, um, I've been doing a little bit of research and the thing is that many projects that I think they still rely on on privileged keys, right?

I mean, at some point there's there are keys that are stored somewhere that somehow got leaked or stolen or whatever and these projects got hacked. [snorts] We've seen like custom scripts trying to run like periodic transactions in order to keep this project up and running. could be like validators or rebalancing for D5 projects something like that. Um and all of these require of course uh um keys stored somewhere in order to execute those transactions.

Moreover, multisix or hardware wallets are not um always used even even though we think this is this should be something like the common base but it's not what what happens. Um and this is something that we've been thinking a lot uh at mimic. Um so the idea today is to explore uh this concept about what we call or internally we call about this um trustless execution that that I think it's something interesting that we find uh for ourselves and it it should be something that I think the rest of the projects could also use um and might help uh avoiding some of the hack these hacks. [snorts] First first of all what what we what we

what do I mean uh with uh trustless execution basically allowing anyone to execute code. So every time we think about the solution sometimes I mean it's trivial to think okay this smart contract can be owned by an account an EOA or multisake whatever and we permission all our functions and that's it but maybe we can go one step further and start thinking is there a way that we can execute this code uh in a trustless way or a permissions permissionless way like anyone uh can execute this code [snorts] is there a way of course if we do that we might rely on signature So is there a way that I can sign only once and execute multiple times? Um

another great concept is what we call um onchain safeguards. This is basically like a the ultimate safety net right that we have. Even though if our keys uh are exposed somehow is there like a an ultimate layer of security that may prevent things for like to go wrong. Um, of course, the the goal at the end of at the end of the day is not not not to expose the the keys. [snorts] So, let's revisit some some real hacks uh for reference to to bear in mind what what I'm speaking of.

Wintermute. Not sure this was a couple of years ago if you remember, but basically Wintermute was an algorith algorithm make uh marketmaking [snorts] um company that they basically relied on a smart contract that was owned by by NOA. This COA was uh basically uh generated it was a panity address that was generated with profanity. Profanity back then has uh had like a um security issue that that basically was um generating the addresses with 32 words seats.

Basically this EOA was I mean the private key was brute forced and this ended up on on a 160 million loss for the for the company. So again in this case it was even pretty obvious but no harbor wallets were used um no multis and of course like in case they should have some sort of as we were saying onchain safeguards maybe some some of these uh withdrawals could have been prevented. [snorts] Another one was the horizon bridge. The Horizon Bridge was a bridge used from the for the Harmony protocol um in order to bridge assets of course from Ethereum and Binance chain to their own uh side chain. And this was basically built on

top of a not not a network but a multisig of validators with a scheme like two of out of five. And basically what happened here was that there were no even though there were no cryptographic issues um the keys were simply stolen and again happened again close to 100 millions were lost. [snorts] At the end of the day the keys uh in this case were actually exposed. Um there were no anomaly detections here. Um, again something like safeguards could have prevented this from happening.

And probably this is one of the biggest that I remember. Not sure if you do, but the running bridge was the the bridge that was basically used by Ax Infinity uh to bridge assets for uh from Ethereum mainly USDC and ETH. The running um running bridge was basically built on top of a network of validators with uh five out of nine signatures. And what happened here was that basically four of them were held by the by by the same company and one one of the other ones were temporarily uh delegated to this same company. That permission was never revoked and basically the attacker only had to take control of one guy or one company in order to make um whatever whatever he

wanted to do. Um this was probably a bit more sophisticated attack probably social engineering again but at the end of the day keys got compromised around more than 600 million loss. It was huge again like no anomaly detections uh basically they didn't they didn't um understood what what was going on until like few days later. So it was it was kind of crazy. no one chain safeguards keys uh ended up being exposed and the same thing happened again.

We can continue discussing like more about this um more and more hacks but that's not the idea. Um I will I would love to push a little bit for this standard that I think um many other uh projects in this space could could try to follow. Um again trust this execution is one of the core concepts that we apply at mimic. I'm not saying like these projects using mimic would have avoided this, but maybe following the same best practices or the same concepts uh could could be a good fit.

To give you just a um a little short description why we use it and what it's mimic mimic for. Um mimic is is an abstraction layer for builders to build on top of blockchain and the idea is to abstract them from um the lowlevel complexity. So at some point the idea is that they can sign once and execute multiple times. So trustless execution it's a core concept for us. Let's revisit one one more time the what we say at the beginning when I say about trustless execution I mean um allowing anyone to execute the code on our behalf. Is it possible to make it permissionless? Uh can can we avoid like having an only owner in our contracts or something like that? Um is it possible

to sign once and execute multiple times? So we don't have to be like imagine sometimes plugging a multi with a hardware wallet might not be scalable. So this is extremely important and again having some sort of onchain uh safeguards this kind of um ultimate layer of security uh that could be um ensured onchain. So how does it work? Um let me explain a little bit how does it work for us. Uh again just to share the idea it's not what I'm I'm not saying that the same pattern could I mean must be followed this way for other projects but maybe there is a way similar that they could follow to implement something um

[snorts] like this. So in our case the developer basically uh implements what we call a task. The task is going to be translated and this is the layer of abstraction that I was uh saying before. This is just mimic um but the the task itself is just a program that will be translated into um it will be executed by the relayers. The relayers will produce some output. This output will val will be validated by the valid validators network and this this will produce intents which will be ended up being fulfilled by solvers and finally this will be translated into transactions.

not gonna get uh into the the the box underneath too much. Uh but the good thing is the developer is basically providing some code some we can think about this as simply as a function. Uh but not only that they're also signing what we call uh the configuration. This is like the input for the for the function. So with those two in a deterministic way we can be sure if the relayers are doing their job correctly or not. This is the job for the validators and moreover the developers the developers can define some sort of onchain uh safeguards. So let's let's see um a quick example of um what do I mean with this?

A classic example that um we've been dealing a lot in with mimic is um people trying to convert like many different assets. When I say many different I'm saying like thousands or like in different layers like 10 or 20 sorry [snorts] 10 or or 20 uh chains and this is clearly impossible for a treasury manager to handle this with a multisig even though if they want to do it in a secure way. So how do they do that? So basically they can implement a task. This task basically says what they want to do. they want to fetch I don't know assets from different oracles to know what what are the ones that they have some balance from um they want to swap

it against USDC whatever then the input itself the signature that they provide is okay which are the chains for example that they want to execute this uh or they that they want to allow to execute this which is the slippage that they are okay with which is the the oracles that they want to read prices from etc ETA and finally they can they can they can put some sort of safeguard uh in the blockchain itself saying okay the only uh recipient address that you can withdraw funds to is someone I don't know and the only token that you can withdraw is USDC. So what happens here is basically we've been always asking to ourselves uh

this hard question. What is the worst thing that can happen even if our keys are stolen? Well in this case as we were saying before um even if the protocol behaves maliciously what are the which is the worst thing that could happen? Maybe they can try to execute the not actually a bad swap. Maybe they can use the maximum slippage that the users agreed for. Maybe they will only be allowed to um swap tokens against USDC and ultimately the ultimate thing that they could do is only to withdraw USDC funds to this guy. That's it. Even if the network works um uh maliciously, there's nothing too bad that can go wrong.

So in the cases that we've mentioned before, we've been seeing like this um evolution. Let's say first with uh winter mute we've seen just an EOA plugged in then we saw like a multis of validators then we saw the network of validators what I'm saying is maybe that's not enough it's it's a good progress but I think it's not enough and I think that there are many um different things that we can that we can do [snorts] um but it's something it's a concept that I think as many different projects should stress a little bit more and probably there are so many other ideas um for example these are some of the ones that we follow internally like having some sort of time locks or challenge periods like if there's

something weird going on it's not just straightforward uh to like break the system entirely. Um well of course also anomalies detection like monitoring tools all of that should happen. I didn't mention it before but in many of these cases uh about the hacks that I mentioned before um they they were not aware of of what was going wrong like they it took a like couple of days maybe for some of them to actually be aware of that that those funds were not anymore there. So that's even um um but again uh yeah so the idea would be to push for a standard um I'll be happy to to have your ideas on on this

uh off stage if if you want to join a discussion and um you can read more uh about this again there are many different concepts that for us are very much important because of the the things we do um it's extremely important to us to find a way of making trust execution possible. This hard question of uh what are the things that can go wrong even if our kids are exposed is I think it's something that everyone should be asking to ourselves. Um you can read more about this in our docs or white paper or whatever. Um and again well thank you uh thank you for listening to to the talk.

Hope you enjoy it. [applause] Do we you have time for question? >> Thank you, Faku. Yeah, we have some time. So, uh yeah, decentralization only matters doesn't matter until it does, right? That was the quote. Yeah, I want that on a tattoo from Mariano. >> That was good. Yeah, Mariano Conti. >> Yeah. >> Any questions from the from the audience? >> Yeah, in the back. being you have to really trust a a single like a particular person like you

your protocol won't work if you can't really put your whole trust on it like the decentralization would work for your protocol so how do you handle those cases where maybe for now you don't know how to implement a mechanism that will be trustless but you just have to use maybe your EOA or your private So how how do we handle that situation? >> What what was the the situation? Can I describe again? Sorry. >> Like maybe you you have a smart contract that you have to maybe you have a smart contract that receives um that you have to validate that okay this person won or this person did not win. Maybe you cannot um implement ZK proofs or mark or for proofs or any like those complex

mechanisms. you just want to use your own private key to be sending the message to a smart contract. Would is is are you compromising decentralization? I don't know how to put it, but there are situations where we can't really be decentralized. How do you handle those situations? Um, it's hard hard to say if uh I'm not sure if what what you're thinking of, but um I think I mean probably maybe there is a way to to decentralize everything, but I think it should be stressed a little bit more. I'm curious which is exactly the case that you think that something that cannot be decentralized or why having a a private key only send transactions is the only way around.

>> Yeah, I I don't know. But like I feel like there are situations where you really have to trust one party when he has to do it even though the funds are so many. So I don't know maybe you be more careful on the web two side but decentralization might not really be possible >> even though I think for example in the case of wintermute that I mentioned at the beginning they were marketing companies so maybe they won't have like I mean maybe it doesn't make sense to have a network of validators in that case but at least I don't know a multi something like that should be >> should be possible I mean why having a single key is the the only way around.

>> Okay, then I understand. >> All right, we have another question in the back. Uh, do you have an idea what kinds of standards uh would be useful? >> No. Do you? No. But I'm um this is something I haven't seen this concept. Not sure if someone else is uh has has seen something like this or I'm actually not not even sure if the trustless exe execution concept is something um going on in this space but um I remember since the beginning that we started working on this um it was crucial for us not to have custody of our users funds. So we stressed it a a lot and we're always

asking the question okay every time we implement a new feature it's like what if everything goes wrong like someone stole the keys like what's the worst that can happen our answer is the worst thing that can happen is that like halting the the system but not withdrawing money from it I think it's something that many other projects in this space should should be asking to ourselves Thank you for the session. You just mentioned that it's possible to halt the system, but we're trying to push for something decentralized. That sounds like a a chain halt like what maybe Solana could do or something.

>> I mean hold temporarily. I mean the private keys is still there. What what the what's the worst thing that can happen in our case? I'm saying yeah. Um for example from our side if the solvers wants wants to act maliciously the worst thing that can happen is that transactions don't get mined but at some point the user can withdraw I mean the user himself can withdraw the money because the user's private key was never exposed. If ours is exposed then we cannot produce more intents in order to process uh the task that the user wanted to but the user of course can they can withdraw the funds. That's that's what I mean. I mean it might if our keys are are stolen we are halting uh the system our system but not users funds.

>> I see a quick follow-up question. So does Mimic get to control the the relayers verifiers and the solvers. Okay. >> Yeah. >> All right. Thank you. >> All right. Thanks for the great questions. Thank you Faku for your talk. We need to move on to the next one. So uh another round of applause please. Thank you. [applause] >> All right. Next up, we have Antonina Norwire from M0 Protocol.