Safe 🛠Developing on Safe{Core} Protocol
ETHGlobal·Mon, Oct 9, 2023, 12:00 AM
Join us for a workshop titled, "Developing on Safe{Core} Protocol". Some of the most skilled web3 developers, designers and product builders from all around the globe came together for a weekend-long hackathon at ETHGlobal New York 2023. ----------------- Follow us: https://twitter.com/ETHGlobal​ Check us out: https://ethglobal.co​m Email us at: hello@ethglobal.com
Transcript
foreign [Music] I'm developer relations at safe today I'm going to be talk talking about developing on the safe core protocol so safe core protocol does anybody know what it is can you raise your hand if you have heard of it before okay good there good there awesome there are so many questions many new terms and Concepts that were introduced in the safe core protocol in the last couple of months now I'm going to try to summarize most of them and you tell me at the end so first of all I will be talking about the safe smart account what it is and how it looks like then the safe core protocol the same but also how it is connected with the account and also I will be sharing some resources that you may find useful for the hackathon if you are hacking with us so let's start with the safer smart account the same smart account is a modular account framework so uh it's basically an account with save it allows many things execute transactions and transactions Etc but here Prima primarily we are going to be sharing how it can be the functionality can be extended via modules for example let's say a recovery module that at some points allows to execute a transaction in the safe that replaced designers so if you lose access to the account you can recover it later we also have transaction guards transaction guards are logic that can be added when the transactions are executed so they are able to parse the transaction read the destination the value the data and some other parameters and act on that for example we could have an allow list guard that has a list of addresses and then if uh if a transaction is executed they will this guard would take the destination and if it's not in the list for example the transaction would be reverted and also we have fallback handlers that would allow to add new um extra functions to the core contracts so in case there's a standard introduced that is not natively supported in the account then you could implement the required functions in this fallback Handler plugging it to the account and then everything would work so uh I guess and hope that we all agree that modular smart accounts will fail without three things interoperability Discovery and security interoperability because there is a risk of vendor locking different teams working of working on different tools and creating a fragmented ecosystem also duplicating work on the same things on tools that are not compatible regarding Discovery there's currently no uh no place to find this smart account extensions like the the ones we saw before so there's a lack of distribution and it's difficult to for users to see what the market has ready for them everybody regarding security uh we still need to make sure that the fans of the users are secure and there are no risks so uh in the last couple of months the team at safe has been working on the sidecar protocol that tries to fix these three topics I just mentioned so let's see what the Safeguard protocol is uh it is still in Alpha version version 0.1 it's ready for hacking so you can use it this uh this weekend but it's not production ready yet so aspect changes and things to break it's also designed to be account diagnostic but for now we are focusing on safe account version 1.x just to make the development processes faster and to other some feedback it's also open source and right now is the best time for you to provide feedback on the protocol if you want to give us some ideas share your pain points Etc now we are still being building on it so it's the best time for that so this is what we had for the safest smart account right the account in the middle and then different components that are enabled into the account directly so the owners of the account need to enable and disable these uh one by one what the safe core protocol introduces is a manager this manager would be another smart sorry another smart account sorry another smart contract that will be placed in the middle of the account and all these modules it will be orchestrating all the flows as well this manager like the safe protocol manager will also have access to some registries we have an implementation for the safe protocol manager and a safe protocol registry this registry will be owned by maybe a person maybe a company maybe a Dao ideally and the owners of Registries will be in charge of adding different modules there and setting the requirements for these additions for example as a as an owner of a registry I can say okay I will list in order to list some modules there they must be audited and blah blah blah different criteria that they need to uh meet and finally we have the modules modules can have can be of different types and now there will be a relation between these new ones and the ones we saw before that were enabling the account directly so first of all we have plugins like the recovery plugin if we if you remember there was a recovery module that was uh connected to the account directly and here as a plugin the functionality of this recovery plugin would be the same but plugins need to implement an interface that allows them uh to work with the manager so not directly with the account but they will be needed they should be listed in a registry and then the manager will check that the they are in the registry and they will connect it to the account same happen for hooks hooks are very similar to the transaction guards we have so for example we can have a an allow list hook they will also work with the manager and can be added to Registries we also have the functional handlers that will work very similarly as the fallback Handler that you saw before we also have signature value vectors and in the future many more kind of modules can exist so let's see uh now just focusing on a plugin how to add a plug into a registry how to enable a plugin into an account and how to execute a transaction via plugin so let's start with adding the plugin to a registry we see the four main components here and to add a plugin in the registry it is the owner of the registry the one who should call a method as module to the registry and that's it it's more bureaucratic for the owner of the plugin because they need to meet the requirements the owner of the registry defines but technically is as simple as this once up plugin is added to a registry we can see how to enable this plugin into an account as a user of of an account so for that if we have our own account we need to execute a transaction that calls the manager and in this call we are calling the the function enable plugin pass in the plugin address we want to enable and also a Boolean variable that is called allowed root access what is fruit access well we have defined two different levels of access of permission for plugins for modules and um depending on if the if a plugin has root access or not they will be able to execute certain transactions let's say a plugin does not have root access this means they cannot execute delegate calls and they cannot execute transactions where the destination is the manager or the safe why is that because if they were able to execute transactions where the destination is the manager or the safe they would be able from a plugin to add new signers in the account or or remove some signers from the account and also in the manager they will be able to add more red or add more plugins or remove some plugins so this kind of actions we are just restricting them for plugins who have root access in the future this can be also uh be more granular but for now it is like a Boolean uh once we tell the manager that we want to add a plugin with a certain permission the manager will call the registry that is attached to this manager and we'll check if the plugin exists there if that is correct then the manager will ask the plugin hey do you require root access or not and then at the end of this flow the manager will store in the in the storage okay this save or this account has enabled this plugin with this kind of permission so that's it now we just need to know how to execute a transaction from a plugin so let's see that now the flow starts from the plugin somebody is calling it a method exactly let's say and then the plugin depending on the permission it has it will call the manager one of these two functions execute root access or execute transaction it's clear which one it is I think right and we need to pass two properties two parameters save and transaction save is the account the plugin uh will be called but this transaction will be executed and the transaction is the transaction itself but also some metadata that will provide some context of the plugin and the transaction so now the manager knows uh what is the account that will be called and what is the transaction that will be executed but first it will check that uh the save has that plugin enabled and also that the plugin is added to the registry that is attached to the manager there are two conditions here in the registry that need to happens one is that the plugin is added to the registry and the other one is that the plugin is not flagged and what is being flagged that means that owners can block plugins if there's a vulnerability that is found for example the owner of a registry can say okay from now on this plugin is not usable so hackers could not exploit the plugin this is a big Advantage compared to enable enabling the plugins directly into the into the accounts because when plugins are connected to the accounts directly it's the responsibility of its owner of the account to disable the plugin before it is exploited but here is the owner of the registry who can decide to block uh like everything at once just for this plugin so then if uh in this flow where we are executing a transaction from the plugin it is added to the registry it is usable it's not blocked then the manager will check again what is the kind of permission the plugin requires will check the storage if it if it is the same then the manager will finally tell the account to execute the transaction call in the function exact transaction from module so for all of all of these four components we have defined interfaces so we are offering a main implementation but the protocol works with different implementations of these components as long as the interfaces are implemented and here for example I will be showing the interfaces for the plugin and the manager there are the most uh useful for you maybe so the plugin needs needs to have like a name a version a metadata provider so where to find this metadata structure and then also if it requires root access or not on the manager side there are two functions you need to implement so the plugin can call them execute transaction and execute root access to say something execute transaction allows to batch multiple transactions and execute all of them at once while execute root access just allows to execute one transaction at a time also in the manager as you can Implement more functions that the ones defines in the in the interface for example how to enable plugins disabled plugins get information from a plugin so you can create the storage uh now some resources you can check regarding the safe core protocol we have two organizations on GitHub the safe Dash Global and then 5A which is more of uh well you will find more experimental things there so uh in the first repository the save core protocol you can find all the interfaces and the contracts we have implemented like the registry and and the manager then there are some specs in the second one some diagrams and flows that are useful to understand how it works uh you can also find a demo which is a react application that can be used inside our our web app and you can see a registry with multiple plugins there you can enable disable them and also with the metadata you can link URLs to these plugins so you can open their interface and operate with them so the safe ecosystem Foundation has ten thousand dollars up for grabs for hackers participating and we have split this in two 5K for hackers in 5K in total for the three best projects building on top of the safe core protocol integrating or implementing any part of it and then 5K in total for the three best projects working on the safe core account abstraction SDK integrating at least one of the existing kits we have you can find us on Twitter at safe we have some dogs Discord forum so thank you very much I don't know if we have time for questions otherwise I'll be around you can find us in the booth also will be available on the Discord for the hackathon so thank you very much
Automatic transcript — names and jargon may be misspelled.