How to Secure Your Ethereum Transactions with Account Abstraction by Dmitry Mishunin
ETHDubai 2024 · 21 Apr 2024 · 13:01
Dmitry Mishunin examines account abstraction as a tool for securing Ethereum transactions. He covers token-based gas payments, recovery mechanisms and implementation risks in smart-contract accounts.
Speakers
Topics
From ETHDubai 2024, hosted by DeFi Dubai.
Transcript
my name is uh GB I am cofounder and city of CAS Bing security and today we will uh talk about uh uh account abstraction but not uh from the common point of view uh uh uh about uh uh how they call these Technologies but uh uh from the risks side so uh this is uh uh what this talk talk is about and uh uh a few words about us uh hhx is a a blockchain security company
we we focus mostly on uh the smart contracts audit one error uh in in a guest L uh uh in the library for G transactions and uh 1.5 ,000 uh projects have a vulnerability uh according to the Dune uh uh to the uh current moment uh more than 3.5 million account abstractions uh account abstraction wets are deployed and think about uh what if uh
uh vulnerability is found in one one of of the uh popular realization so uh a few words uh about uh uh a account abstraction uh what it's all about it has been talked since uh 201 16 but but uh with with a tight timeline uh it wasn't included in the first release of ethereum and uh the first uh realization
was only in 2023 it's uh uh a technology that allows for uh many POS abilities you can uh uh for example pay uh for transaction with tokens uh uh you can uh make a custom ver verification logic and this leads uh to uh Web Two experience in web 3 uh which uh can bring us uh real Mass adoption of the crypto currencies so uh uh the better name for account
abstraction is uh I think smart wallets because every wallet is uh uh in account abstraction uh is is a a smart contract with a custom logic but this uh uh uh implementing this requires consensus level changes uh uh on ethereum and uh the uh uh development on ethereum is uh uh focused on the scaling Solutions so for for for now the native account abstraction is uh uh implemented in some l2s like Zea sink and dark net and uh uh let's talk talk about uh how uh uh it
was uh made possible on ethereum without uh change making changes to the cor protocol uh there is a a offchain framework uh where a where a user or cemented uh creates transaction named a user operation in context on ERC 433 7 this uh user operation goes to to to mol and we have uh uh executors uh uh acting uh uh as B builders in ethereum uh which uh uh take these you user
operations from the the man pool they group them uh into one transaction and pass uh them to a singl tone uh uh contract named uh the entry point it's uh uh uh actually the the main contract uh of the uh uh account of action which uh uh calls the user wallets uh uh to verify uh and uh uh execute the actual transaction also uh we have optional pay masters uh uh these are uh entities that can sponsor transactions for some
reimbursement or maybe uh uh specific transaction may be sponsored even by by free and uh uh an optional entity is uh aggregators uh this uh they aggregate signatures uh it's kind of optimizations for gas cost so uh uh the technology uh is quite uh comp complex and uh uh let's talk about is limitations and the P pitfalls first of all you you need to know that that uh uh the actual call uh
of uh in the smart contract is not the the sign the eoa EXT owned account account with a private key who sends this transaction is a bundler uh and uh um uh speaking about the uh code in smart contracts uh uh uh usage of the T origin is quite restricted as it's uh uh always points to to the B to the bandler uh this lead us uh to uh limitation for for a common check uh
uh that that was uh popular not not not long not long ago uh to attack from flash La attacks to restrict calling the contract from another contracts it's uh uh T origin uh equals to to message send and uh it does not work uh uh Now with uh account abstractions we uh also need to know that uh according uh to how the uh uh Alman Pool Works uh uh uh the consecutive uh uh operations in in mol uh for one account are not
possible so the developers need to uh to to group them first into one and and uh wait until uh uh the these operations are are mind and uh an important uh thing to know uh especially uh on ethereum not notorious for its transaction cost that uh for example uh sending an ethereum from account transaction wallet may require uh more than five times more more guas than uh sending it with uh e EA and also uh speaking about the uh uh transaction
costs uh to create a wallet you you need to uh deploy a smart contract which also a very expensive operation on the ethereum so uh uh the rc4 33 s is a well designed uh uh uh system uh uh and we think that the uh most risk lie in a uh realization of its parts uh in smart contracts especially uh in uh uh with the uh using
of signatures in the wallets because replay attacks uh and uh uh uh uh mostly common and uh actually it's very difficult uh uh to uh do the uh signature verification right as that's need not only to think about the security of this but uh uh also uh they they need uh to check that uh the same signature is not used twice uh the only entity uh uh that is trusted uh in this standard is the entry
point contract uh and uh uh some wallets may want uh uh to to have a function to change it uh and this this may be the source of another vulnerability uh when uh the entry point contract uh in the wallet Chang to some malicious one and uh this is the case uh uh that was with unas wallet uh uh where the funds could be w w withdrawn from many many W account Direction uh allows uh creation of
uh uh uh allows pre-calculation addresses for not created wallets and and uh actually an attacka can uh uh if it's not done right uh can deploy uh a wallet that he can control before the uh uh at the same address uh before the user and we draw all all the funds that are already sent to to to to this address and uh speaking about the the griefing uh account uh uh this standard uh has a lot of parties that uh don't need to uh trust it each other but they
they need uh to change check the uh operations that uh everyone uh uh every entity uh uh does not uh try to to fraud it for example speaking about the pay masters uh uh uh uh uh they re reimus users for for the the paid gas and this can can also be exploited and uh speaking about uh the denial of service attacks uh uh uh uh a wallet uh uh there was a case that uh a wallet didn't handle the the
nons right and actually the uh the funds on this this Wes were blocked so here is a uh a checklist uh that developers uh can look at it uh to uh uh successfully start uh the uh project uh you you using account abstractions uh successfully thank you I I will be glad to to answer any questions