Image by\u00a0Ideogram<\/p>\n
When I set out to create a new wallet last year, I had no idea what I was in for. I had worked in the blockchain industry in London for seven years. I liked the idea that wallets could be made more accessible with account abstraction. Private keys and passphrases are liabilities in my\u00a0opinion.<\/p>\n
I was concerned, however, with how centralised account abstraction was. Users could be provided with wallets much easier to handle but they don\u2019t have the keys. The keys are stored in a central repository somewhere. This means that anyone implementing account abstraction is essentially creating a custodial service.<\/p>\n
I wanted to make wallets that were truly decentralised, and without private keys. That was wishful thinking trying to get rid of private keys. Originally, I wanted to use zero knowledge proofs where a user could generate multiple commitments and load them into the account as a form of verification vouchers. The data size was far too large so it didn\u2019t make sense economically.<\/p>\n
This made me pivot early to using post quantum cryptography. I had considered creating my own polynomial based zero knowledge proof but decided it would be better to use something already made. I researched the different algorithms and chose Falcon for its smaller keys and signatures.<\/p>\n
I wrote a solidity contract to verify Falcon signatures. I originally only worked with the 1024 version and had made an adjustment to the message hashing to reduce gas. Eventually I would find discussion threads from other people working on the same problems and came across a function that did the correct message hashing for\u00a0Falcon.<\/p>\n
Next I started building the back-end components for my\u00a0product.<\/p>\n
Account abstraction uses bundlers to submit user operations on behalf of the wallets and it uses paymasters to pay transaction fees on behalf of the wallets. There are publicly available bundlers but I was not sure if they would handle the larger gas values that Falcon verification requires (5\u201310 million depending on whether you use the 512 or 1024 version).<\/p>\n
There was also the risk that those bundlers would not be able to verify the signature correctly. So I decided that I would create my own bundler\u00a0service.<\/p>\n
With account abstraction, a user operation can still process even if the inner call data function reverts. Bundlers have to simulate all transactions before submitting them.<\/p>\n
Bundlers also need to check that the account has a valid paymaster or enough ether to pay for the transaction.<\/p>\n
Not simulating a transaction nor checking that the fees are covered can be costly mistakes for a\u00a0bundler.<\/p>\n
I also created by own paymasters. There are paymasters available but quantum-resistant transactions use millions of units of gas which is significantly higher than most current transactions.<\/p>\n
It is possible to use account abstraction without paymasters. I plan to offer this as an option when I do make my wallet available. When a user operation is received by the entry point, if there is no paymaster provided then the contract will check if the sender account itself has deposited ether in the entry point or if the user has adequate ether held in the sender account; in either case, the wallet then pays for the transaction.<\/p>\n
I have taken to calling these self-serve accounts since anything using a paymaster is called\u00a0gasless.<\/p>\n
Image by\u00a0Ideogram<\/p>\n
With account abstraction, there are nonces but then there are also nonce keys. Nonce keys take the nonce to the next level. I defined an admin nonce key and a large gas value nonce key in my\u00a0system.<\/p>\n
If the user submits an administrative transaction such as a key rotation, the nonce must use the admin nonce key otherwise it is rejected.<\/p>\n
The large gas value key allows me to warn the user that their transaction will cost a lot more than usual and then charge them two transaction credits. If the user agrees, the user operation is updated with a nonce key signifying the larger gas acceptance. Then my paymaster contract, seeing the nonce key, knows to deduct two transaction credits instead of\u00a0one.<\/p>\n
Nonce keys are not secret so do not treat them as if they are. Think of them more as a system of organising activity and decisions.<\/p>\n
I then built a payment gateway service that creates the accounts and manages the paymasters.<\/p>\n
Once I was happy with the payment gateway and bundler, I started working on the user interface for the wallet. I wrote it in ReactJS so I could get something online and testable relatively quickly. The goal at the time was to ensure the smart account worked as expected and I needed the bundler and paymaster so I could run the ecosystem in\u00a0testnet.<\/p>\n
As I said earlier, I wanted to make the wallet truly decentralised. The thing about account abstraction is that there is normally a mechanism to recover the account; this is where it is usually centralised. I decided to go with a social recovery approach based on a smart contract I have called Recoverable.<\/p>\n
Originally, I had made the paymasters the source of truth on recoverable control. For a smart account to create a recoverable, it needed to use my paymaster. This enabled a form of gating since I would control the paymasters. The problem was two-fold: First, that made the paymaster a centralisation risk, and second, self-serve wallets would need to purchase transaction credits.<\/p>\n
This brings me to my second pivot. I had to exclude the paymaster from the recoverable model but I also had to protect the smart accounts to ensure a malicious recoverable could not be accepted.<\/p>\n
Months earlier, while I was still building the back end and constantly revising the smart contracts, I had decided to use a contract factory to make the smart accounts. By doing so, I am able to create the same wallet addresses across any EVM-chain.<\/p>\n
That approach was how I ending up addressing the recoverable risk. I created a recoverable factory and then immediately registered it in my account factory as an immutable address. Every smart account created is given the same factory address. The smart account will only accept recoverables created by the factory only. The wallet still has some centralisation risks such as my bundler service. It is possible to self-bundle user operations as well but I plan to eventually let users select their bundler service provider.<\/p>\n A year ago, I had no idea how account abstraction really worked. I originally thought that I would have to deploy entry point contracts and considered selling custom ones to manage smart account systems. I learned the hard way when the creation code failed on Sepolia because the transaction size was too\u00a0large.<\/p>\n It has been almost a year since I started this work. In that time, I have built a complete account abstraction ecosystem on multiple chains that uses falcon verified messages. It is non-custodial, there is no way I can override the keys or account. Recovery is up to the user, they may add as many addresses as they like and set the signature threshold as high as they\u00a0want.<\/p>\n One year later, I have built a decentralised account abstraction with PQC. It is not what I had planned to build this time last year but such is\u00a0life.<\/p>\n It will be coming soon to Ethereum\u00a0MainNet.<\/p>\n Lessons Learned after Building with Account Abstraction<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Image by\u00a0Ideogram When I set out to create a new wallet last year, I had no idea what I was in for. I had worked in the blockchain industry in London for seven years. I liked the idea that wallets could be made more accessible with account abstraction. Private keys and passphrases are liabilities in […]<\/p>\n","protected":false},"author":0,"featured_media":185864,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-185863","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/185863"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=185863"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/185863\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/185864"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=185863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=185863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=185863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Getting the recovery functions to work was the last feature required to make my wallet truly decentralised. The wallet I have made is non-custodial. There is a test version<\/a> available that creates free accounts on Ethereum\u00a0Sepolia.<\/p>\n