Scaling Ethereum Development With Mimic Protocol | Facu Spagnuolo - Mimic

excellent so we're keeping it rolling on Saturday uh hope you guys are enjoying the talks uh we got a great great talk coming up from the CTO of mimic protocol uh faku and he's going to be talking about scaling ethereum development so round of applause [Applause] testing can can you hear me fine yeah okay um so we're here today to talk a little bit about how we think we can scale ethereum development uh through trusses automation um so yeah my name is faku I'm the CTO of mimic and we've been working um in the industry for a while mainly pushing for Automation in this space I would love to tell you a little bit about my background um I started uh working as a blockchain engineer in open seing in 2017 then I joined other projects uh like Aragon I helped building Balan serv2 uh I also been contributing to the graph um it's been a great journey until we got here and something that uh I kind of realized in all these projects that I've been working with is that uh automation is something that it's always uh sa for for later um you always take care about uh uh architecture security smart contracts modeling um lot of critical details for your protocol but at some point all of these rely on some sort of automation that you need to take care of but this is uh simply procrastinated this is definitely an endless cycle uh it's something that you push forward for future uh iterations and at some point you need to take care of it uh the thing is that um you don't put too much effort into it you don't think this is a critical part of your project but I think it is and at the end of the day this this end up being a huge waste of time for for the depths the thing is that automation is critical for both the depths in a project but also for the users you can expect users to be interacting manually with projects so this is heavily and and critical let me tell you a little bit uh about what what we have seen uh during these years um in all the project we've been working with of course uh mainly repeated processes like tons of teams doing manual things once a week once a month repeated tasks that they need to take care of manually and there's no um common way of doing things this is a huge waste of time um also manual intervention like uh Gathering a group of people so they um meet in a in a in a in a war room um to reuse stuff that they need to take care of um this is definitely error prone um also at some point they realize they start like doing the same thing many many times so they start building custom scrips to take care of that the thing is that uh this kind of uh Snippets are unmaintainable no one uh follows like a common pattern in order to build this and at some point you start um it starts growing a few guys in the team know about this it is start it starts um being a huge mess definitely also relying on on private data sources like all these uh pieces of code at some point need to rely on uh onchain data or offchain information like prices or information about the protocol whatever um the thing is that uh this end up being unreliable there's no decentralized way of accessing this data and it end up being a single point of failure this is probably the most critical ones um this scripts at some point needs to do uh some transactions they need to do something on chain they need to sign things you so we heard like a lot of people storing these keys in in servers and well we we know uh about a huge hack that we had the last couple of days uh about the server that has been compromised what we would love to see uh instead is mainly a standard processes there should be an no-rain way of doing things when you come up with uh the idea of automating something there must be a standard way of doing things um this needs to provide lowlevel abstractions um at the end of the day you need to interact with chains with prices with information with lot of things that you don't have to reinvent the whe right uh this standards this tooling needs to abstract you from all of that trust this data sources at the end of the day this data that you are ing in order to automate whatever you're doing in your protocol it's something critical so there must be a good data availability for that decentralized execution as well um at some point when you need to uh perform some transactions on chain you just want that to be executed you don't want to deal with something that uh it's being stucked or something like that so um being able to rely on a network uh decentralized Network to execute something it's a good way to just forget about it proper access control again we are always uh dealing with some critical concepts of your protocol or having access to different parts of it so it's critical that we have a good way of uh controlling access for it and finally monitoring tools um which is uh sounds simple but it's critical as well you can build a great solution but if you don't know what's going on behind the scenes if it's working well uh if it's getting stock um you need to have like dashboards mat tricks locks um this is um a really important thing as well this would be amazing right if we have a single way of doing of doing all this if if there's uh um a common tool or protocol that we could use it would be it would be such a great thing the fact is that there isn't um so and this is what we are calling trustus automation we've been pushing this for a while uh during the last couple of years and we're um we have a lot of um a lot of evidence of what have helped other users and what not and I would love to take you uh to tell you a little bit more about it so going back a little bit how we got here I remember in 2022 when we started uh working with some some projects in this space like the Central and Par Swap and other protocols we started building Simply onchain Recipes this was okay uh because it was an easy way to interact with our protocols um we started using onine articles um that that was fine I mean we were kind of uh forgetting about accessing data in a reliable way there was rainforce security of course like every everything was rning in smart contract so there was no doubt about what was going to happen but the thing was that it was really hard to change if the user wanted to twe some variables or configurations or something related about what what that code was doing they had to ask us we need to implement that deploy to the all chains that we were going through and it was uh not an easy thing to do so then we came up with the idea of I start um extracting these configurations to to be customizable by our our users so mainly they started being able to control thres colds for example like uh okay I need to use these balance thres colds to trigger this or this um actions in the in the chain um also time logs users were uh wanted to be able to control time like when things need to happen like once a week or once a month or um everything related to time of course um also volume limits they wanted to control which is the amount of volume that was going to be processed through these actions like okay I don't want to process more than 100K a month whatever um also access control like who is going to be able to TW this uh barbles in the team so we need like a permission layer in the built in um they wanted to al control like Network congestions like um if something's going on in the in the chain that is being uh uh raising the gas price maybe they wanted to u to act in a different way so they wanted to control this limits as well the thing was that it was really cool but we still uh were very very uh highly coupled to protocols all these Integrations were built on chain and it was again Flex not that flexible if they wanted to like play things in and out if they want wanted to I don't know start using another aggregator or uh another another protocol to do some sort of things it was not easy they have to ask us to build those Integrations and and deploy them and this is where we came up with the idea of uh the Lego pieces um mainly this was what we call the protocols connectors they were some sort of plugins uh that they can play with so every time we integrated a new protocol to our stock that was super easy for them to plug them in and out if they wanted to try WR it um it allowed us to Define standard standard tasks around it uh that was that was a great thing especially for the for the relays because we could build um a common logic about how these tasks needs to be executed there was a Common Language between them that was very good and also it started uh allowing users to model complex things uh these Lego pieces were able to be connected between them and it was super easy to model like complex solutions that they wanted to automate the last thing is that they are still dependent on us like uh even though the stock that we built uh was open source and it's uh public uh at the end of the day they were handling like critical things and they were dependent on us like having our support in order to deploy those Solutions and much more so the good thing is that we definitely validated the idea um we process like 4 billions in terms of USD uh of automated value we work with this uh list of top tier uh projects in this space as you can see uh even the like the the the big ones are are requiring this type of solutions um but now what we want to do is basically to open the game like uh decentralize what we're doing open it more so more deps can come and build their own Solutions um why because uh main we're still receiving a lot of requests of um developers or teams that are willing to automate things for their own projects but the thing is that we cannot take care of all of them at the same time uh so we need to scale more and definitely decentralizing and open up these standards are are a good way of doing it there's definitely no solution in this space like if they want to take to take care of all the things that we've been saying before there's no easy thing that take care of all that um and definitely the community needs to be pushed with good standards there's going to be like uh huge challenges as well uh finding a standard way to model everything that we've been saying before data sources related executions um monitoring tools everything related about automation is not easy to define the standard because mainly developers want to um um automate like custom stuff they want to create their own ideas that they want to automate and this is not easy to Define like a common common way of doing things um at the same time guaranteeing a good developer experience that's going to be a huge deal and even even if uh we find some adoption and and we validate the problem Market fit with the solutions that we've been building decentralizing that uh is going is going to be a huge challenge as well while keeping that adoption so I would love to tell you a little bit about how a mimic protocol is going to work this is the name that we are giving to to this prot protocol of course um May protocol is going to be a three- layer protocol uh and let me tell you uh some details about how how each of these is going to work so the first one is the planning layer um this is basically the probably the the huge deal here it's what allows uh deps in the space to Define define their own tasks tasks are implemented in um programming language uh these are these task are being compiled into wasum which is going to be executed by the re layers so this layer will basically provide both things uh access to the Rel layers to take care about the execution but also to the oracles they will they're going to be able to access this data that they're needing for the task in a decentralized way um and of course uh they will not just Define what the task should do but also the triggers what triggers them it could be an unchain event it could be a balance threshold it could be some sort of uh Crown schedule whatever the next layer is the execution as I was saying before uh since task are compiling to wasam and this is going to be executed by the Rel layers the Rel layers are going to be the ones interacting actually with the chain and if we need to send transactions we cannot of course delegate access to our private keys to the Rel layers so this is why we are uh leveraging the concept of intents here the good thing is that users don't need to take care of uh how things are done they just need to tell what they want to do and we can leverage the whole architecture sorry the whole infrastructure that the community is building for solvers in order to take care of that the good thing is that always the best proposal will win so users won't won't won't be harm um and the last one is the security layer this is basically where we guarantee uh on chain that whatever the user wanted to do is uh being done otherwise it gets roll backed um mainly we're using settler content which is the the backbone of the intense idea um and we're introducing a new concept uh here uh which is optional for users but it allows them to Define um onchain conditions that they want to make sure that are met before everything gets executed this is what we call safeguards so in a sense we do need this we want to push this standards for for the community our goal with this is to provide uh again a common way of then things something that abstracts you from all the critical things that you need to take care of when you're dealing with automation accessing data related executions a great developer experience monitoring tools and much more um so we're here to push for this if you're uh interested in learning more um we have tons of technical details in our documentation you can access the white paper which is uh a really good piece of um information if you want to read more about the math behind it incentives the architecture the security um measures that that we're taking uh it's it's great if you want to come and learn so thank you FS uh for hearing me today hope you enjoy the the talk and well there you got my my Tor G back on if you want to get in touch with me feel free to drop a message I'll be more than happy [Applause]