Account Abstraction in Starknet

Transcript

[Music] hello hello hello everybody how's it going um hey there my name is Martin I lead the chiraganda Clary at open sapling uh open sibling is a security company we make open source tooling we do Audits and all things security um today we're going to be talking about a kind of fraction in starting up specifically um so yeah let's begin but before we begin I'd like to know who in here has a

good idea what account attraction is raise your hands okay on whole view is familiar with 4337 eip4337 okay and uh who of you have ever used a gun abstraction in any form for 337 okay pretty much the same group um okay that's good because today we're going to be talking about weather abstraction is how counts login starnet a brief comparison with eap4337 and then a few updates on the state of the art of things and some challenges the future what not

so let ah there's lots of pictures of my guts I hope you enjoy them uh so um what is a kind of traction basically it means abstracting a few aspects of accounts like um signatures this means validation of transactions we send through abstracting fees this is paying with any token letting someone else pay transactions for you and abstracting nonsense nonsense this is to prevent replays today we have sequential nonsense for example in ethereum in many other networks and the idea is to have different strategies to prevent these replays but um in many different ways you can have parallel nonsense non-sequential nonsense whatever you want as long as it

protects you um what this gives us is first very Security in the form of prevention we can set limits on our transactions like maximum amounts of funds we can send daily we cannot restrict transactions to be sent to just a set of other addresses we deem secure we can have multi-signature approvals this is for example having um traffic having your for example be have you who have you have ever used nosy safe or any other multicing that's better okay it's basically the same having multiple signers or maybe having your phone on your Ledger uh send out approval before a signal transaction you can have Guardians this is someone else

that's helping you with this process an alert system say that there's a monitoring system telling users um our vulnerability or some suspicious activity on a given contract it can alert you and prevent you from sending them to section you can always send it through but it gives you an extra set of um warnings you also can have security this could be uh freezing your account if something is going wrong you can have social recovery having someone else help you recover your account if you lost your keys or whatever and this could be a key rotation which is you lost your keys instead of migrating all assets and privileges to a new account you can simply change the key and you're done this also gives us a better ux we're going to have session Keys custom

digital signature algorithms pay with any tokens getting sponsoring on your token on your transactions having expiring transactions recurring payment for subscriptions lots of things now starting it specifically the first thing we should know about uh transactions in starnet is that all of them are targeting an account contract there's no EOS so you're always sending a transaction that starts in an account and the flow is usually like this uh the user sends the transaction to the sequencer node the sequencer node checks uh that analysis are valid that you have enough funds for to pay for this transaction and then it runs the valid

function the valid function is to tell the sequencer whether it can't charge gas on this account or not usually this has in order to avoid um transactions that are not valid taking too many resources from the node and prevent denial of service what we do is to limit what this value function can do for example it has a hard has limit hard gas limit this is uh the just a given set of steps you can execute before um getting out of gas but without paying it and if everything goes well you can execute the executive function which is the actual um transaction another limitation that

it has is that you cannot read storage from other contracts but the specific account you're dealing with um so this was the question if every transaction starts with an account how do you deploy that an account in the first time uh well there's two ways of doing this uh the first one is to you deploy a transaction an account from another existing account that's very valid but another way is to do counterfactual deployments counterfactual deployments are basically you can predict what address you're going to get when you deploy your account and so you can send funds to this address first and then you can call a specific transaction on this send a

specific transaction to the sequencer that can run the validated plug function and if everything goes well then it charges gas from the account you previously funded and uh there you go one thing to note is that this is very similar to EOS external Leon accounts also require you to send funds before you execute your first transaction so with this in mind we can talk about the specific interface of how accounts are installing today we start by defining a scroll struct with a two selector wrinkle data that represents a cold specific contract and with this we can build our execute amalliate functions that take an array of this call so we have built-in batching transactions this is multiple and we

also have an is valid signature method that is used to verify that message has been signed with the signature that it's on with the practice that are on the representing this account and even though this is like the minimal interface you can have on your account there's another set of functions that you may want to have like value deploy which I just mentioned for contractual deployments we'll have supports interface which is like ERC 165 this is an introspection mechanism we used to ask an account whether an it's an actual account there's many use cases to these for example EIP 721 the safe transfer function uses asks a receiver contract whether it's an account or not before

sending the nft we also have the value declare function that's related to how uploading bytecode works on starnet we won't cover that and the functions we saw before so now we can compare how erc4337 Compares uh looks in front of um staring at a kind of traction so first the main pool in 457 we have an alternative separate and parallel um network of Anglers so we have a different main pool on top of the existing ethereum's main pool while in starnet we have a single native sequencer mample which is simpler on validation on 457 we have the bundlers

which are on chain nodes off-chain notes there are receiving user operations bundling them together into a transaction and then send that transaction to the ethereum's main pool then the validator is validating that transaction while installing it we simply have a sequencers checking the valid function of accounts there are some similarities between these two which is the separation between validation and execution steps and the constraints we have in the evaluation step not reading from external storage limited set of steps or gas you can execute on this valuation function this is because 4337 was a huge inspiration for staring at model so it's no surprise that they're

similar then on execution on 437 we have a single a single tone entry point contract where all bundlers are sending their transactions uh their bundles while installing it each transaction is targeting a different account contract so by now you might see that erc437 and I got a council's Target are very very similar but starting at scene has since has been influenced by 437 has the opportunity that we have it simpler it doesn't have an alternative Network it has less layers and also transactions are easier to decipher and inspect by users blogs blog explorers front ends whatever because they're a bit more

explicit on what they are so the state of the art right now there's a living standard that it's still in development this is being developed jointly by open sabling urgent and recently Bravos also joined the discussion and we have a standard implementation on the open sampling contract for Cairo library that you can use for development deployed or you can also use the library to extend it and build your own account contracts based on it we are still missing at the network level known as Russian at this point it's still sequential and managed by the broader goal we don't have via a construct fee abstraction uh on the protocol there's uh I think last week

someone sent me an app level um implementation of pay masters but this is not at the protocol level yet which is better and we are still working on improving the account detection mechanism today we are using snip 5 which as I mentioned before is like ERC 165 for introspection but we are discussing whether it makes sense to have a protocol level mechanism to ask a contract whether it is an account or not so that's pretty much it you can give it a try on that link you can scan the QR code which goes there it's repository with the Cairo contracts library that has the account one year C20 721 and all other contracts you know from open supply for solidity um yeah Implement your own account tell me how it goes and ask me any questions

you have finally there's a pop-up so if anyone wants this gun there you go yeah I mean if anyone has some questions we have some minutes to answer those so feel free to ping me oh sorry sorry go ahead any question guys okay so I guess the speech was clear thank you and thank you very much [Applause] [Music]

[Music] [Music]