Enhancing AA with on-chain hierarchies: A New Approach

Transcript

[Music] hi everybody let's settle down um I hope you're enjoying this talk so far so for the next one please welcome Jose Ramirez from pomea with a talk enhancing AA with onchain hierarchies hello everyone Thanks for uh staying this talk so the topic of the day is enhancing account abstraction we don't change hierarchies what's our new approach but first we need to start thinking about how it how it arrive account obstruction and smart accounts so we're going to go a delve into like a

history of smart accounts how you can optimize it how you can customize it with modules plugins and then what's our approach for that just a quick intro about myself Jose computer scientist of Parera been in the crypto ecosystem since 2017 building uh different things but most relevant I was on the dark side a little bit uh building a custody system for a bank in a crypto bank so I'm quite familiar with multis since 201920 and now on palir with within the same topic so let's talk about the smart account Evolution what do we need why do

we need smart accounts we we want to customize the behavior on of a transfer of anything that is besides the EA so the first one that came around was lagnosis safe just it was a smart contract that it was just a basic multi that means that you have multiple signers that need to approve any transaction that going through the smart contract right right but that was the main and the only feature but it was enough for that time then there was the next version like save the spin-off of nois save they generalized a little bit this smart contract that they created

and now you could like kind of attach other logic other smart contract to your original multi in order to have more customizable ways to do it and that that was enough but still tied to the safe ecosystem to just one type of contract one type of interfaces so the next step was okay how everyone can benefit from this approach in like smart account using smart accounts with custom ability and that's where 4327 arrive like this standard that allows anyone that is building a smart account to just comply

with a set of rules to to have this generalized behavior on what we do so now let's talk a little bit I was I mentioned before like a lot of time like how can you customize your smart account and that's the one that's one of the main um uh subject of this topic no say was just multis save has like the multisig modules that are like smart contract that you attach to the save to Smart contract that going to bypass the multisig logic it's going to be a Rite like they have guards that is uh basically a smart contract that is going to do pre-checks and pro checks before

the execution and in for7 of course following that that um that same idea you have some validation modules some execution modles and some hooks that are basically the equivalents of save has but in a standardized way but what were the the problems that the ecosystem was facing like first fragmentation because every smart account protocol was having their own interfaces was having their own way to to create that vendor lock in is tied to that like how you can achieve interoperability that's what like 4337 tried to achieve instead of mitigate security risk and also like trust signaling to Which smart contracts do

you want to attach to to your smart smart account but why do we really want smart accounts like basis use cases right we want to improve the better ux from any dap that means that you don't need to always sign with your EA you can just attach like a keypass to your smart account and uh sign I mean approve the transaction with your face ID you can set up like session keys so you can give a speciic specific dap the authorization to run and use the funds from your smart account you can create B bat transactions and another side regarding

also to gas that is a constraint with OS that you always need to have gas in this case with smart accounts you can just don't you don't need that there is another entity that we're going to see later on that is in charge of paying for that cost and that is embedded Within the smart contract customization and in terms of security also EA is problematic as we all know you just need the private key to to move everything in this case with a smart account save was using multi6 you have already can have like a social social recovery mechanism setting up different signers that can be your friends or

other other entities with attaching new contracts new custom logic we can also use new graphic Primitives like that will be very useful for Quantum resistance and like hybrid custody setups basically the same thing as um probably as social recovery but using a entity as a third party ER delegate delegation third party for your for your thing and the operational part that's also like more on the spending limits World BAS as his control and we're arriving a little bit on our main subject that is like the

hierarchical structures that we were focusing on let's have an overview of for7 so the main components here are like the user is going to create a new set of transaction a new type of transaction that is the user operations there's going to be another roles that are the bundler that is grabbing all these user Ops coming from different users and like batching it and send it to the entry point the entry point is like the SM contract account where everything is going and it's going to be processed so there you have like concrete account the pay Master as I mentioned before is the entity who is going to pay for for the gas consumed by the transaction and the

account itself let's see how which types of modules as we already mentioned before the three different types but are attached to this 4337 standard so we have the validators like a validation logic that is running within the entry point when every user operation goes there is a validation step that you can add a module to to make it custom on the execution side the same after validation step has been accepted and approved you can enforce like different execution Flows In this case you can maybe a good example is like uh intent based

system when you want to have like a token to a to c you have to pass to two three different steps before and you can enforce this flow to be within the execution uh module and the hooks that's mostly like post and execution checks before the transaction is going to be executed right and now let's let's see how this is plugged Within the four Trier 7 in more detail so here we have like the the whole High overview about the account exraction users sending the user Ops the bond link submitting the transaction and then the entry point of course is doing

like the one step one is like 4337 validation then you can add the plugin so that's where the plug-in is coming in Second Step the pay Master it's going to validate approve good and within the thir third Point as you can see there then there's going to be involved the plugin for the hooks and the execution that you can add this custom loging within the system to make the state the state change and the last part the pay Master Okay so this is like high overview ERC 4237 and custom logic and what do but we need a standard right because that logic that is presented with the schema has to be understood by the smart

account implementation and also by the developers of the plugins so we need a specific interface for how we can St this this module this plugin how we're going to manage that module how it's going to be like this execution of the logic of the custom loging being implemented within the smart account and the same for the logic so the question is here like is there a standard for customization as a builder you always want to follow standard why I mean it's it's quite easy you want interop interoperability you want to go where the markting is going where the builds are going in this case I mean in my case it was quite difficult because there is two standards for

custom logic so it's like how do you decide which way to go at the end these two standards wants to do the same thing is just standardize the custom modules within the 4327 standard but uh they have different approaches in a really really high level like ERC 6900 wants to keep all the permissions within the module and in the other side ERC 7579 they want to give that permission control over the users so it's two different ways to to see the same same

problem and we want to get into each of them to understand what what's going on there so as I mentioned before here see 6900 a permission system is embedded that has to be supported by by the smart account with a specific rules and which kind of address do you want to interact how do you need to interact with between the smart account and the custom logic so they have a configuration file they have a manifest that both entities understand ADV antage is that the plug-in functionality is very isolated the disadvantage is you have less flexibility it's here the control is really over the developer or the

plugin itself in the other in the other side you have the RC 7579 that is like as the name say a minimal standard for modular smart account supported by uh quite a big Community like B economy rhinestone ether sport zero Dev okx they are pushing this this standard that has the benefits on making the user the main one who set the permissions and with that you can make modules inter interoperable they want to create this module store concept where as each plugin really doesn't need like any specific permission they can all work

together as a as a app store right the module they have also same a module installation and a management system they support in all the different types that we we've discussed before and also like just a mention on another ERC 7484 that is about registry how another entity can kind of vetted some some specific smart accounts that you can install it but now okay now we have the big overview about okay whats smart accounts 4337 the different customization standards we're going to talk about Pala just a quick uh intro about we are an

aggregation layer for chain organizations we are supporting web3 organization to manage multiple saves multiple smart accounts the Integrations and their automations and in this case we're just we're going to focus on the pal module so the Palmer module is a specific way to enhance smart accounts using hierarchies but before going deep into that just a little question who who who here thinks that we went with ERC 16900 no one okay with the RC 7579 okay two good and none nothing okay I will say that

everyone said none and you were right we we didn't go to any of those why because as a as a builder we started also like a little early before the standards and we want like adoption of of the module and this right now is really tied to the safe ecosystem safe has like 10 million of safe deployed they have the most tvl between all the chains and as we're targeting more onchain organization that are managing this multiple save we want them to use it and we know that the switching cost for a save user to like a new 4237 is smart account that has been just

released like one year ago it hasn't been fully battle tested by the time it's very difficult so we say okay we're going to just go with a safe standard safe module and now we're going to get deep into the functionalities so basically our module is like a Unix file system for a smart account you can you can think about it as creating a hierarchical tree when you have like the root folder is your root save or root smart account and then the sub save Subs smart account are going to be under the control of the root one on the parent one this add this helps to maintain like a different

compiz hierarchical structure with also like Ro based AET controls baked in we're going to just mention like the couple of roles that we have embedded like after talking with the multiple organizations one of the main roles is uh of course the root save that is like the admin of the organization that has the power over the whole tree every sub save is under control the parent one like the supp safe and in terms of what they can do they can really execute anyone that is on the upper level can execute a transaction on

behalf of the Sub sub safe so the design challenges about our model where like first from a organizational point of view do we only want to give like one control one entry point control for the organization like one root account or multiple ones then on terms of okay organization they have multiple departments they they're managing multiple save each save can also can like just quit the organization can just be deleted from this hierarchical structure that is enforced by our module and what's going to be the RO assignment and on the technical side

it was also more the are we going to just have like the module as a single tone where all the mapping between the organization and their safe is going to be stored or we're going to create like more proxy proxy based uh contract gas cost of course we needed to be very mindful about how big this tree can be can get right if you have like 10 levels with like four or five sub safe can be a problem we end up doing some testing and we can support like seven seven levels when with a average of three sub saves per per level

so that's that's quite good and the logic for uninstalling and unplugging the the module so we went with a multiple rout structure to give any organization multiple ways two or three or four like root admins in this case like a very quick example can be within in the avara entity you will have like one root save for a one root save for lens and then under those you will have all the different groups that are within this organization so that that lets gives more flexibility for the organization to set it up their

structure but this also like as we were talking about trees we want to give flexibility within the organization of the of the tree system and you can like move some branches of course for this operation you need the approval of the admin account the root the roote safe in this case you can delete a branch but that's specifically for the rage quid example as a sub Branch you cannot quit just uh because you want it you need approval of the admin and more specific use cases for this hierarchical structure that I

presented like the Dow management that's the one that I think uh we can really very easily visualize when organization have multiple Department multiple groups and each one will have his own smart account with his own set of Sor and his set his own set of rules to to execute anything but with like some control from the upper level and in this case we can attach another module to make that admin part of to make the community part of the admin with like some onchain voting mechanism another use case can like Grant distribution the same idea about

Distributing different treasuries amongst different groups but within the control from the organization in this case you can also manage the expenses for each individual smart account take it the control if someone is behaving or not doing what they see they can just CL back the money and that's quite important for these types of uh organization because they don't want to just spend money like without a a real purpose an operation and in terms of Treasury man management there more on the operational part okay you can the same spend give some spending limits to some branches of

your whole organization or just a specific one a specific uh different budget allocation and another use case that is a little different is more on the like devops side let's say it when you can for example use this archiculture tree to create multiple sub smart accounts and each one is going to be like the admin of the like the deployer of your protocol smart account so in this case you you can keep this control within multiple saves to all the deployments that you're doing for your protocol in a much safer way that just

being an Nea doing the deployment I have the ownership of the smart contract and the pal module V2 that is been uh on uh we're going to start building it who thinks we're going to go again 6,900 one okay 7579 two great three none now I think none is not the option of course and we we we're thinking to adopt this 7579 standard as it will give us more flexibility

interoperability and really is what we think all the ecosystem is a little bit pushing and is gaining more tractions with more players more support and also just safe they release an adapter for for that I mean safe and rhinestone that is going to be very helpful to make all the Legacy code that is there to just with an adapter make it compatible and in our case that will solve like lots of interoperability problems so the conclusions for for this like vast topic we think with all the new use cases coming on I think like modules and

plugins are going to be like the origin for new new adopters because you make it everything easier in terms of the interaction within the contracts but at the same time Legacy sometimes Prevail because of the battle tested of the system that's what make safe like the most used smart accounts in terms of tbll because it's been there for four years no hack so yeah you can put like Millions on there with the safety and the challenge is of course like as we see every day which which standard is going to Prevail and as I talked before about the adapter development makes all these

different points like much more easier [Music] to to accept so that's that's all for it thanks for listening that's the Palmer da Twitter and my Twitter in case you want to follow us and keep us keep that date thank you very much Joseph for that exciting talk um I know we've got some burning question who wants to go first no questions no questions okay thank you very much all right thank you um please