DappCon 2023: Developing on Safe{core} - German Martinez
DappCon 2023 · September 2023 · 48:23
At DappCon 2023, German Martinez presents a talk titled 'Developing on Safe{core},' part of the event's protocol track. Safe, formerly known as Gnosis Safe, is smart account infrastructure widely used on Ethereum for multisignature and programmable wallets.
Speakers
Topics
From DappCon 2023, hosted by Dappcon Berlin.
Transcript
hello hello um welcome to developing ons saafe core protocol I'm Herman like German but I'm not German I'm Spanish uh I work as the at safe and today we're going to talk about the safe core protocol can you raise your hand if you have heard of it okay pretty good pretty good so there are so many questions like different terms and Concepts that were uh recently introduced like a lot of them like plugins modules the manager uh there was even a white paper have you read
it okay good good today uh we are going to talk about the safe smart account refreshing a little bit what it is what are the different elements there then talk about the safe core protocol what are the new things the new components and how they are connected to the safe smart account we are also going to see some resources some repositories where you can find the find the contracts some um applications that use it and then we will see a demo and if you brought your laptops you can you can also follow me and play with it so let's start with the safe smart account which is a modular
account framework there are different elements there being the most important one or the main one the account itself in this case it is the safe contract but then we can extend the functionality adding different other contracts for example modules modules allow to extend the functionality by uh triggering transactions that are sent to the contract and in a way that you could bypass for example the regular flow where the signers need to to approve all the transactions and with this uh you can for example automate transactions and do much more stuff one example of a module would be a recovery module that
could at some point trigger a transaction that replaces uh an owner that was in the account with a new one so you can get access again there are different elements like the transaction guard transaction guards allow to uh add extra logic when transactions are executed uted so uh this logic can run before and after the transaction executed is executed and they can pass the transaction all the properties the data like what is the destination the value and also see the state changes in the contract and act on it and decide if the transaction is executable or not an example of a transaction guard would be
an allow list guard that checks what is the destination of the address uh this guard would have a list of of addresses and if the destination of the transaction is included then it will be available to execute otherwise not and lastly we have the fallback Handler which is a contract that can be enabled in the account and would and would handle all the uh all the calls to functions that don't exist in the main contract but are implemented in the fallback Handler and this is very useful if new uh for example uh standards for tokens are implemented while you have uh already your account deployed you want they require you to add new functions to
the contract that you don't have them implemented and you could do it that way so this is how the safe smart account looks I hope we all uh we will all agree that modular smart accounts fail without three things interoperability Discovery and security interoperability because there is a risk of bendor locking if different um projects are doing their own thing then the that are not compatible between each other then the ecosystem will end up with a lot of tools and very fragmented and also there will be a lot of duplicate work that
won't be uh reusable regarding Discovery there's no uh currently there is no central place where you can can search or discover these elements like plugins uh etc for smart accounts and this also leads to a lack of distribution to users and security uh we need to make sure that all of this is secure and the funds are not at risk now that we have seen uh the safe smart account a little bit an overview we're going to talk about the safe core protocol which is a modular smart account protocol uh some things first it is in
uh version 0.1 Alpha so it's in a very early stage this means that it's ready for hack for hacking but not for production use yet so we expect things to uh change and to break in the coming months also while the protocol is meant to be uh account agnostic for now we will focus just on Save uh the versions 1.x to speed up the development it is open source and right now we are seeking for Community feedback is the best time to do it as we are still uh working on it and uh your suggestions are very welcome so this is how the safe account
safe smart account look like and now we are going to see how the safe cor protocol is connected to this so them uh instead of having modules guards and fallback handlers enabled directly into saves with this uh with the safe core protocol we will have a manager the manager will be the element that is placed in the middle and and will coordinate all the communication between these different components and the account it will also well we we have a say protocol manager implemented that you can check it will also access to Registries Registries uh a registry is a
contract that can uh Define a list of modules different elements that we will talk about later Registries will have an owner this owner will decide which uh elements to include in the registry and these owners can be like individual accounts multi6 for example if there's a a council managing this registry ideally daos would have their own registry and or or registry would be managed by a DA so they all decide together what to include or not they will Define some requirements for uh Dev developers that they need to meet in terms of security and uh we have the safe
protocol registry implemented that you can check as well and now we have the modules modules are uh these external components that will U extend the functionality of the safe there are different types here and you will see some relations between these new ones and the ones we saw before for example plugins plugins are kind of an evolution of the modules we saw before in the account as they uh can be connected in this case to a manager and send transactions to the safe the the difference uh between them is that plugins must be added to a registry and uh accounts would be to
enable these plugins in the manager uh and then the transactions will be sent from the plugin to the manager and to the account while in the in the safe smart account we saw that uh the modules were connected directly to the safe we will see uh why this is beneficial later so for plugins for example we have a recovery plugin that would uh do the same action as we saw before we also have hooks hooks would be very similar to the transaction guard so we can have here an allow list hook that will uh check the destination of the of the
address for every transaction and act on that we also have function handlers which are SE similar to the fullback Handler and we have the signature validators and some others uh in the future we will be able to have uh more more different type of modules now we are going to see uh different flows like uh adding a plugin to a registry how to enable a plugin in an account once it is included in a registry and then how executing a transaction from a plugin looks like so let's start with adding a plugin to our
registry here we have the different components the save the manager the registry and the plugin and to add a plugin to the registry we just need a call to a method at module in our registry and that's it it looks easy but it's not that easy as this will be the most um bureaucratic step probably for developers as they have to uh not not just convince but prove they are worth uh to be included in the in the registry so here the owners will decide if uh they accept or not the request they get depending on the criteria they they
decide and then the owner of the registry can call this uh method to add it now once we have the the pluging added to the registry we can as users from an account enable them so here we would need to uh call the save to execute a transaction that will call the manager the method enable pluging and there we will pass the address of the plugin we want to enable in a save and a Boolean property that is called allow root access what is root access this can be true or false depending on the uh permissions we allow the plug-in to execute uh and this is very similar to
when we are if you are developers when we write a command in the command line and you have you want to have some extra privilege and you add Pudo before it so for example if you have a plug-in with root access this plug-in will be able to execute delegate calls otherwise they won't be able to do that also if you have a plugin with root access you will be able to execute transactions where the destination is the manager or the safe why is this uh why do we need root access for this because if the destination is the manager or the safe the plugins would be able to uh will have access to functions that are quite
critical like uh enable a plugin disable a plugin adding extra owners in the save or removing them so we would only allow this if a pluging has root access if they don't don't they would be able to execute regular transactions once uh once the safe calls the manager uh to enable the plugin the manager will check if the plugin the save wants to enable is included in the registry because that is mandatory also our implementation of the registry has uh a property for each pluging that is uh where they can be flagged or not and being flagged
if a module is flagged it means it's not usable it's marked as uh blocked for example if there's a registry with multiple modules and somebody finds a vulnerability for for one module uh for one plug-in sorry well modules uh this the owner of the registry will be able to block this uh module for all the users for all the accounts and nobody would be be able to explo to exploit this vulnerability this is quite an improvement because in the past uh in the safe smart account where modules are enabled to save directly if there's a vulnerability found then every account
should be uh responsible of disable their module individually while here the owner of the registry could help do that with just one action one once we check if the the manager checks in the registry if the plugging is in the registry and then also is usable and not flagged the manager will ask the plugin if the plug-in requires root access or not or not to uh store this information in the manager so the manager will end up with information like this uh account has enabled this uh one or multiple modules with this uh type of permissions
for now we just have root access will be yes or no but in the future different kind of uh permissions could be defined as well and now we have uh added a plugin to the registry enable it into the into a an account and we will see how to execute a transaction via the plug-in so here uh somebody will call a plugin the method exec for example that will send a transaction to the manager two things can happen here depending on the permissions uh the plug-in has the plugin can call the manager one of these two functions execute root access or
execute transaction passing the safe address they want to send this transaction to and the transaction and here this transaction object uh can also have some uh metadata of the plug-in so uh later when the transaction ction is executed some events can be emitted with this metadata and uh the applications in the front ends will be able to add more to be richer with more information and with more context about the plugin and the transaction the manager once uh it receives the transaction and the save the plugin wants to call it will check if the if the plugin is enabled in that
save it will add the it will uh ask ask the registry if the plugin is added and also not flagged so it's usable it will check the plugin if the plugin requires root access or not and it will compare that with the information it was stored in the manager before to make sure that the function that was called it's okay and makes sense and if everything is correct then the manager will tell the safe to execute the transaction that was initiated in the plug-in is it clear or do you have any question so far yes great um for all these components we
have interfaces and there could be multiple implementations for them so for example uh the registry we provided code or one implementation for it and then uh many people can deploy their own registry with that implementation or even with a different one as long as it uh implements the required interface that is provided and ideally we will see in the future um lots of Registries uh in different contexts so they list all the relevant uh modules on that uh topic yes and
then okay uh I will repeat the question just in case uh so you asking if this uh replaces the old setup we have and the answer is no this doesn't replace the old um the old setup is just an addition an improvement but both will coex exist uh well let's see how the how the next versions of the safe um evolve but for now uh both can coexist and in fact uh this one will still uses the smart account to uh connect the manager to the safe we can
see that later in the demo but uh yeah we have another question there yeah sure um is it always a onetoone relationship between safe and manager or can it be many saves for one manager uh technically uh one safe could have multiple managers um yeah this is getting complex um in theory it's just a one andone relation where a save has a manager that has access to a registry but technically you could have multiple managers it's manager accessing to one registry or even depending on the implementation of the manager the one we have just has
access to one registry so one manager one registry but depending on the implementation of the manager it could access to multiple Registries so this can really get more complex but uh yeah to understand it it's like one safe one manager and one registry but this can grow let's continue and then if you have more questions uh we can answer them so as I said before these uh components have an interface each of them that need to needs to be implemented and I will uh talk a bit about the plug-in and the manager ones which are the more interesting ones if
you are implementing a implementing a plug-in so for the for the plug-in one there are for functions that uh you would need to implement like name version metadata provider this uh will will tell the one calling this method where to find the structure of the metadata for the plugin and this can be different things like the name of the plugin the version or whatever and then if the plugin requires root access or not regarding the manager there are two functions that that must be implemented execute transaction and execute root
access as we saw before in the diagram one difference between this uh is that for the root access transactions you just uh you can just send one transaction at a time however for the execute uh transaction uh function you can send a batch of transactions and all of them will be executed in the in the same transaction also uh in the safe protocol manager implementation we added uh more methods apart the ones defined defined in the interface like some uh management for for the plugin you can enable and disable plugins get information from a
plugin and so on let's see now some resources we have with some repositories there are uh three repositories about the safe core protocol and the last one is a demo uh the first one the safe core protocol it is in the safe Global organization in GitHub and there you can find the contracts uh we implemented like the manager and the registry like the safe protocol manager and safe protocol registry also the interfaces for the different components that you would need to implement if you want to have your own
implementation then we have the safe C protocol spec repo also in the safe Global organization in GitHub there you can find documentation about it some diagrams flows that are very uh interesting also I I forgot to say in the safegard protocol you will find tests that are very useful to see how that works and then we have uh another organization in GitHub uh that is five a like safe for more more experimental things and there is a uh a demo app save core protocol demo that we will see in a bit where you can play around there are some examples for
plugins and there is a a save up that you can try with some front end uh there's a registry and you can play enabling and disabling modules from there uh the last one is the is the URL for this demo but uh we will check it in a bit also uh if you have your laptop today and want to do the demo with me we have a a poop you can get to be a kind of protocol tester at Berlin block week 2023 there are some requirements you need to meet like fill a survey to collect some feedback from your experience here and what you think about the documentation we
have and also enable a plugin in your safe if you want to scan this survey uh uh to participate you can do it now and well maybe at the end if you don't have time now I'll be happy to to provide this QR code again okay so now it's the demo time if you have your laptop uh let's open the the save up I have it open
here you can go to app. save. Global and we can create a save in Girly H if you um if you have any issue just raise your hand and we can uh check it together or feel free to interrupt me if you don't understand anything so let's create a new account that I will call uh save workshop on gly I'm very happy that we have a relay
working on on gly so you don't need funds to deploy it and even to execute transactions we have five transactions for every hour so right now the transaction is being executed and I will have my safe deployed on girly very soon and without funds from my side is it all good from the computers are you deploying a safe yes okay great if you also have some funds on gurly uh once you get
the the safe deployed and the safe address H it it would be great if you can send just a little bit to your safe not to pay for transactions but to be able to execute a transaction that sends something otherwise you won't be able to create a transaction if there are no funds there that is not mandatory for the demo as uh it's only required that you enable the plugin and not execute a transaction via the plugin where you would need some funds there to send something but uh if you are able to execute the transaction then that would be funnier so I will do that I have my save
here and I will send uh some funds if you don't have funds to send I can give you some girly e uh I will send a little bit uh I know what happened I don't have funds in my metam mask but I have another safe with some funds
okay uh yeah the thing is that I have fans in a save and I want to send them to the other save but you the relay would be fine right sorry yeah yeah yeah
yeah I'm for
no it was fine I I don't know what uh what I did wrong I I had a a save with ether enough to send it but I guess I I I was confused with something it should work okay do you have your safe deployed can you raise your hand yes okay do you have some funds on it yes yes okay now let's see the the code of the repos that were shared before I have them here I can share the the links again with
you these ones if you want to take a picture uh to have them later uh well there's no need to open any of them but uh because we don't need to program anything but uh I I I will show them a little bit yes so in the safe core protocol we have different folders uh we have some contracts with uh what what I said before the safe protocol manager you can see the implementation we have for now again expect things uh to change in the
coming weeks and months also the registry you can find it here with the implementations of the functions from the interface there are also some tests for [Music] the well for plugins there's a registry that is unrestricted so anybody can add a plugin in there without the the action of the of the owner of this registry Etc then in the protocol specs you will have the the diagrams and flows and now we can see the safe core protocol demo here there are contracts and web folder in the
contracts you can see some implementations of different plugins for testing uh for example there is a relay plugin that works with yato that allows to uh relay transactions then we have a plug-in for uh for Recovery that replaces one of the owners of the account we have also a wh list plugin that you can check and then we have the source uh sorry the web folder here with a front end that is a save up now I remember you need to copy uh the the last the last URL here the 5 A.G
have. and then save core protocol demo that you will need to use it in your front end does everybody have it ready okay so we'll add it as a as a safe app if you go to apps in the front end then there is my custom app I just added it before but uh you can do it as well you can click on the add custom save up and provide the URL there and then click the button add all
good let me know if you have any issue with that so now if we open this it will show us uh a safe logo rotating and then there's a link show available plugins yes here if you go to the menu apps my custom apps there's a button yes the URL is the last one is five a.
github.io and then save core protocol demo with hyphens 5 f. github.io and save hyphen core hyphen protocol hyphen demo and then you will see the app added here so if we open it and click on show available plugins we will see a registry with different plugins added from a hackathon and some uh tests now
uh I want you to enable the relay plug-in this one can you see it yes is there a button Ena that will create a transaction if you see before executing this transaction it is a b transaction that will enable module and enable plugin the enable module something as somebody before asked is the manager replacing the old uh setup no the manager here is added as a module in the save up in the safe smart account so we need to First
enable the manager and then enable the plugin there so we can execute this with the relayer as well with noas needed from our side sign the transaction it failed for some reason just ating execution no but
uh okay I will try to execute it with uh funds but this is weird it looks like it's now processing yes were you able to enable the plugin to execute the transaction yes great okay now if you go to uh to the
settings and go to modules you will see the safe account modules there yes that is the manager also if you want to go to Ether scan to this contract and read it there are multiple uh methods there you can check one is is pluging enabled and there you can uh copy paste the safe address and the plug-in address the pluging address is uh in the well it doesn't matter you can take it by yourself uh if you want to play
with the contract functions more in detail but uh the plugin is added to the manager and the manager is enabled in the in the account so now we go back to the to the demo app and uh because of the metadata of the plugins we can have a link that is pointing as a metadata of the plugin we can have a link pointing to the front end for that plugin and the relay plug-in has one link here on the right that will open an interface to relay transactions so we can Define uh for
example a Max fee uh of [Music] 0.1 this is just the the logic of the of the plugin what does this plug this plugin works with gelato and will allow to uh send a transaction you can call the pluging send a transaction and it will be relayed you can have the check the code here in the safe C
protocol demo contracts plugins. so and it is this one the relay plugin so this plugin will send the transaction to the safe account and the safe account will uh send the transaction to the gelato relay so the the transaction will be executed and also the save from the funds that are inside it will repay the the executor or it will send the the fees to the fee collector from gelato how is it possible to deploy this Fe token address that only consist of sorry the token here yes has an
address that's only made up of what do you mean that that is the the token you want to use to repay the the relayer basically IND yes okay I I was not understanding the questions yes this is a list of tokens and then if it's the native token
uh so now we don't have uh pending transactions to relay but we can go to the here to create a new transaction uh to send tokens this is why you need some funds in your safe this is not required to get the poop but uh we can try this I will send it to myself and instead of executing it I will just uh sign it so we can execute it via the plug-in I'm just preparing the transaction okay it was added to the que
successfully we can see it here and now uh I guess we have to ref refresh this yes we have a a list of one items for depending transactions that we can relay so the transaction it's been relayed it will be executed by the relay and then in the in the transaction list we will see the transaction that I executed sending some funds to myself and then how we are
paying the fees to the fee collector so if we go to transactions to the history now see here we see that I was uh sending some girly to myself and then paying the the relayer so this was an example of a relay plug-in but then uh we can have many plugins implemented uh listed in a or add to our registry with the metadata we can add some uh information like a URL pointing to the front end for this plugin uh and then applications would be
able to read this metadata like this uh save up is doing and allowing users to open it and play around with the plugin how did you use the plugin now I miss that how I use the plugin yes I have the transaction prepared uh there's a button uh you need to refresh the front end okay and there at the bottom you should see one transaction yes and a button relay open the oh you need to go to the registry again
and find the this you mean okay then here no is it good it's relaying okay okay it takes uh a little bit then uh that was the the demo uh
feel free to let me know if you have any issues or your feedback as well is very welcome here you have the slides if you want to check them uh later at any time we can uh talk to us on Twitter at safe check our dogs on docs. safe. global we have Discord a forum and thank you very much for attending this workshop and well thanks and now if you have uh some more
questions uh now it's the time yes you mentioned I think it's working okay uh you you mentioned hooks in the very beginning uh uh instead of cards uh or basically the the new version of cards can we uh I understood I'm not a developer but I understood that you can only have one guard right now and can there be more hooks in the future if we will allow to have different hooks connected all at once so different checks can be executed yeah
ER there's nothing uh preventing us to do it uh I guess it's just a matter of priorities here the good good thing about the protocol is that the interfaces are defining are defined and uh sorry here for example hooks are called from the manager so the flow would be there's a plugin the plugin calls the manager the manager checks if the plugin is okay and it will also check if there are hooks that needs to be added to the registry and all of that and then if there are hooks the manager will call the hook depending on
the implementation of the manager if it allows to have just one hook or multiple um well but we are not there yet in Alpha right sorry Alpha is not there yet uh no right now there's just one one hook regarding transaction guards I know um I know a project that implemented a a guard that allows to plug multiple guards and call them in a loop uh but yeah okay like you don't have to even have a loop you can have a chain of
responsibility pattern where you basically have your guard call The Next Guard and that guard call The Next Guard and it's outside of then the safe cor protocol is just up to you how you stack them up yeah we STI stick to one it's up to you as the developer of the Guard what you how you chain them also one one interesting thing that I didn't mention in the workshop is that uh with the preview setup when you were implementing modules it there was this decision of do I implement this module just for one account or with a data storage that
allows to have multiple accounts connected for example the the allowance module we have allows to have multiple uh accounts to reuse the same deployment of that module but there were other modules where the account needed to deploy one uh instance of the module to use it here we are making mandatory to deploy uh modules that are reusable but many accounts because they will be added to the registry and then uh well that's it is there any other question also we have our booth uh
downstairs feel free to come whenever you want we will be there thank you [Applause] again