Safe 🛠️ Safe{Core} Protocol Plugins 101

[Music] welcome to Safe core protocol plugins 101 my name is Herman I'm the developer relations at safe and today we are going to uh briefly explain what the safe car protocol is and uh focused specifically on plugins so uh does anybody know about safe please raise your hand awesome does any body know about the safe core protocol okay quite good uh does anybody know about safe core protocol plugins okay interesting so there are lots of questions uh lot of terms that were introduced in the safe core protocol uh a couple of months ago like there was a white paper some modules plugins uh manager Registries so what is all of these how they work together together and how can we use plugins so it all starts with uh three um facts I will say and it's or maybe premises that uh modular smart accounts will fail without three things interoperability Discovery and security interoperability it is because there's a risk of vendor locking uh with multiple uh projects bu building a smart accounts that are not uh interoperable they cannot work together creating extensions for them that cannot be reused and creating a fragmenting fragmented ecosystem Discovery because currently there's no centralized place where uh users can discover what kind of extensions can be used like plugins uh we will tell you how we try to solve this and security because uh the more uh extensions we add the more uh different parties we need to trust as users so the safe cor protocol tries to approach these three things uh but uh that we will see later uh currently it's in Alpha version it's ready for hacking but not for production use uh yet it's designed to be account agnostic but for now we are focusing on different versions of the safe like 1.x to make the development faster it's open source and we are seeking uh for Community feedback so if you have any feedback uh we are very happy to receive it uh how many people know about the safe smart account architecture which looks like this okay so the safe the account is the core contract and the functional it can be extended by using modules transaction guards and fallback handlers these different pieces add extra functionality for example modules uh can initiate transactions that are sent to the account maybe we can have a recovery module that given certain conditions we can trigger a transaction to replace the owners of the account without or bypassing the signatures of the uh of the owners transaction guards are able to check every transaction and Define certain conditions to decide if the transaction is executable or not for example we can have an allow list guard that will check the destination of the transaction and fallback handlers can add uh new uh new functions to the core contract so if there are new standards that appear in the in the ecosystem we can uh support them without upgrading our safe so this is basically how safe works now the safe core protocol is introducing the manager this is one element that will act as a uh coordinator of these previous elements as a middleware we are not replacing this this uh still exist and you can uh develop them and connect them directly to your uh account but using the manager like the safe protocol manager uh it has um it it can uh check a public registry the safe protocol registry that lists uh lots of ideally lots of uh modules that people develop the registry would have an owner that maybe can be the safe da and the safe da would request uh some certain level of security to list modules there and as a user you would go to the registry and decide which ones you want to enable in your safe because we trust them so now the manager acts as a coordinator of the registry the account and the module that can uh be of different types like plugin hooks function handlers signature validator validators maybe more in the future and now there's a similarity be be uh between plugins and the modules we saw before Hooks and the say transaction guards function handlers and the fallback Handler the difference the main difference is that these ones are connected via the manager and are listed in the registry so let's see uh focusing just on plugins how to add a plugin to a registry how to enable a plugin in an account and how to execute a transaction via a plugin so let's see how to add uh plugin to a registry as a developer uh technically you don't have to do anything it's something that the owner of the registry needs to do but will be more bureaucratic as you have to meet the the requirements they ask you to they ask uh and then the owner of the registry would call the method add module and the module would be added there simple in theory uh let's see how as a user how to enable a plugin in your account here as a user you will need to uh create a transaction from the safe that calls the manager that needs to be enabled as a module like in the previous uh slide we saw and uh execute the the function enable plugin in the manager passing the the plugin uh address that we want to enable and uh the boan variable allowed root access this variable can be true or false and uh it specifies if the plug-in will have certain kind of permissions or not for example if the plugin will be able to execute delegate calls or or if the plugin will be able to uh trigger transactions where the destination is the manager or the safe why is this because if a plug-in sends a transaction where the destination is the manager or the safe maybe the plugin will add more plugins or remove existing plugins or if calling the save the plugin will be able to add more owners or remove them so this can be done only by plugins that have certain kind of uh access then once the request is sent to the manager the manager will check if the plugin we are trying to add is already in the registry by uh calling Tech plug-in then the manager will ask the plug-in what is the the level of permission it needs and finally the manager will save in the storage a list with uh with a save the plugin that has enabled and the kind of permission and then we have uh the safe protocol manager and the safe protocol registry that will be deployed once on any network uh ideally and uh they will contain all the information between uh or about what plugins are enabled in what saves and with what kind of permissions so now that we have our plug-in enabled in the account how do we execute a transaction now the flow starts on the plug-in Side by somebody calls the plug-in and now the plugin will tell the manager to execute the transaction depending on the permissions the plugin has uh the function execute root access or execute transaction will be called passing the save we want to send this transaction and the transaction itself that will have also some metadata the manager will check in the storage if the plug-in is enabled for the safe that uh for the call Save and it will also check in the registry if the plugin is added there and if um if it's not blocked if it's not Flagg because the owners of the registry are able to block uh plugins let's say that a a vulnerability is found in a plug-in and the owner of the registry can be notified and they can block the the all the transactions coming from a specific plug-in this is a good Improvement compared with uh enabling modules directly to the save because here the owner of the registry uh could uh stopped all the transactions all the malicious transactions on the other um with the other approach it's uh the responsibility of every safe owner to disable that module so now the manager um sorry yes so the plugin the the manager will check if the plugin is enabled if it's added to the registry and not blocked it will ask the for the kind of permission it has and if everything is okay compared with the uh information that is stored in the manager then the transaction will be uh sent to the save to the method exec transaction from module so that's the the main flow between the between these components we have interfaces for uh all of all of them if you are the pl the if you are implementing a plugin the relevant ones would be the interface for the plug-in and for the manager so these are the ones that I will show regarding the plug-in there are only uh four methods that are required a name for the plugin the version metadata provider and requires root access requires root access will return uh if it requires root access or not as we saw before and metadata provider will return a provider type and allocation this is because we can add some metadata to the to the plugins that interfaces can read and can make the user experience better let's say that every plugin can has an official interface an icon or whatever or some description the provider type uh well we will see this later and uh on the manager side we have the two functions that can be called from the plugin like execute transaction uh it can receive a a batch of transactions if the plug-in does not have root access and then there is the function execute root access access that will only receive one transaction for the plugins that do have access so resources we have uh some resources on GitHub in the safe Global organization like the safe cor protocol safe cor protocol specs safe C protocol demo that is in a in a five a like safe Organization for more um experimental things and then the deployment of the demo and now we will see this repos here on the left um in the safe core protocol you will find the contract folders and there you can see the interfaces that looks like this file that is opened with interfaces for the different components here we can see the protocol plug-in that has what we said before the name version uh metadata provider and requires root access we also have uh some examples of very uh simple plugins here uh we can go to the base plugin that has a Constructor it receives the name version if it requires root access and the metadata hash metadata hash is uh an encoding of the metadata and then hashed so what is this metadata here we have an example of metadata that could be different with a name version uh the icon URL the app URL maybe a description or whatever and this uh will be stored as a metadata hash now depending on how or where we want to store this metadata for the plug-in we can have different implementations we can have a base plugin with a stored metadata maybe a base plugin with event metadata if we just focus on the event metadata here we have have a Constructor when uh and inside we are emitting an event called metadata with the metadata hash and the metadata encoded and then we have the metadata provider function that Returns the provider type and location in this case because the metadata is stored in an event that this plug-in triggers the provider type will be an event and the location will be this the address of this plug-in so the interface can go to the metadata provider function and find where this metadata uh can be found and here we have the enom it can be a story in ipfs uh in a URL like a Json uh in the contract in the in the storage or as an event now to execute the transactions from the plug-in we can also see a very simple uh test plug-in we can Define or Implement uh the execute from plugin function or whatever you want to call it passing the manager that will be called the save that ultimately will be called and the save transaction and then the plugin would need to call the manager and execute transaction if the plugin has root access then in the Constructor we would need to initialize this to true and then in the execute root root access transaction from plug-in function passing the same data instead of calling the method execute transaction you would need to call the execute root access so uh you can find us on Twitter we have some dogs Discord a forum also uh we would very welcome your feed back regarding this talk if you find it useful or not and regarding the safe core protocol as well uh we have some bounties for this weekend feel free to check them in the in the E Global dashboard and thank you very much