Feb 1, 2024
Aleo account abstraction, WalletConnect, private multisigs, fast ZK Proving & fast client syncing all on mobile (and extension).
Give it a try and click the quest in the app to earn with our quest campaign!
For those without iOS — you can also complete the quest on extension here.
We believe mobile and Aleo Account Abstraction as described below is essential for ZK and privacy tech adoption. Read the rest of this article to learn more about what Aleo Account Abstraction is, why it's import for UX, our opinionated design decisions for this initial release, and some history for how we got here!
On Aleo Account Abstraction and the design decisions made
We base our design decisions as a team on a balance of short term goals and long term goals for the company. In the long term, we are focused on building a more dynamic collective capitalism for the masses and that means building products at the intersection of users and onchain orgs in a way that can reach the masses. We'll never reach the masses with seedphrases and bridging and gas and slow ZK proving speeds — the masses just want a frictionless experience to a product and service they want.
Because of this, we built Aleo Account Abstraction and a zkGame bot so users don’t have to go through the pain of bridging or paying gas or slow ZK proving to be able to play a zkGames or use Aleo. With Aleo Account Abstraction — we have delegated proving, transaction bundling, and fee paymasters so you don’t need to acquire Aleo credits as a user or wait on slow ZK proving or worry about transactions not hitting the chain. With our implementation of Aleo Account Abstraction, the wallet recognizes programmable private multisigs on Aleo and is capable of MPC private multisigs so that you don’t need seed phrases on top of public multisig functionality you'd expect based on existing account abstraction works.
So why do all this?
Without this — you can't get user feedback. Without feedback, you can't build great products. How do we know? We experienced this firsthand with our Nucleo private multisig and other suite of onchain org products in 2022. In order to test our products, a user would have to bridge tokens over, wait long prover times, and maneuver around gas payments. Their neurons would be deactivated by the time they finally got to what we considered the main product.
As a company that's focused on making products for people at the intersection of users<>onchain orgs, it means that we had to innovate at the underlying infrastructure layer before we could even nail the products that users & onchain orgs alike will love. That's why we are so excited for Aleo Account Abstraction because it means the time for rapid iteration and product feedback loop is here.
Now we can experiment with the user<>onchain org products rapidly to find the best game and mechanics that each party desires.
As a user — that means you can just create a keypair, receive some game tokens, and start doing.
We have been able to iterate rapidly on our user flow and we wanted to make some quick notes about our Aleo Account Abstraction implementation and design decisions for account creation. We found the multisig & seedless account creation as not a high priority for users at the moment and we even found that crypto natives would like to see their seed phrase at the onset of wallet creation. So in our current implementation, we don’t abstract user accounts with MPC or private multisigs out of the gate. We have also chosen to show the seed phrase to users on account creation.
Despite this lack of need, the multisig capability is very useful for users to play simple multiparty hidden information games between untrusted parties. We chose to label these in the extension as “shared state” accounts as zkGame developers use the extension frequently for development (if you are interested — check out our repo here). In iOS, we have chosen to not show these accounts entirely unless you visit the developers tab in settings. See below for examples.
Last but not least on design decisions is how we indicate to users that the wallet is creating zero knowledge proofs or syncing state. Long term, this should be on par with the existing web2 experience for async awaits on user data or posts on data requests like ChatGPT. We are en route to get there with research we have brewing. We’ve found that even crypto natives are unfamiliar with the zero knowledge proving process and the state syncing process because this is atypical outside of ZKP privacy chains. Accordingly, we simply show transactions as “Creating” when proofs are being generated and show state sync as just a small subfont of an update percentage.
We have chosen to be opinionated in our design with what we show and what we don’t based on this and plan on continuing to move towards abstracting the chain in most areas. If you have feedback and feel we should do otherwise or change something in existing design — drop us a line on Twitter as we’d love to hear your feedback! Sorry but no Discord communities for now — that will come later as a special surprise though 😊
Some history on how we got here
The journey to build a mobile native ZKP privacy wallet started in 2022 back in our Nucleo days. At Nucleo, we did early experiments in Noir & Leo for general programmable private smart contract programs with multiparty applications like voting or hidden information games but mainly built products for onchain orgs. We built privacy infrastructure like private/public multisigs and org<>user interfacing products like payroll, NFT storefronts, fundraising campaigns. We are still building for bringing orgs onchain and soon you'll see how the pieces of the puzzle fit together 🙂.
From the products we built in 2022, it was apparent that we needed to build our own mobile and extension clients for a great user experience. This was driven by feedback from 3 products and their associated user personas — Private Multisigs, dApps at the intersection of onchain orgs & consumers, and individual user's interaction with both (which I already touched on above). We wanted to share our experience and lessons learned for the broader industry to learn from below!
Lessons learned from private multisigs
Our first product at Nucleo was the private multisig and right off the bat we noticed 4 huge problems that led us to start our mobile journey.
Multisig users wanted notifications when transactions were proposed.
We had a couple options we explored here. Most multisig signers had a group text, telegram, slack or discord for coordinating when they needed to sign. We explored making bots to automatically notify these groups when someone had proposed a transaction and transaction rules to help handle things automatically. This is useful but it’s not good enough. Why? Well that takes us to point #2.
Multisig signers predominantly used mobile to sign
Again there are a couple of options here. We explored transaction rules to help handle things automatically as to avoid needing to build a mobile client, but this ran into technical solutions that would introduce additional trust assumptions that were non-negotiable. From a first principles perspective, the best choice in the long run was to go through the pain of building a mobile client. But why build a native mobile client? That then takes us to point #3….
Multisig chain syncing performance is a problem
The chain syncing performance stems from two user-related issues moreso than it stems from technical issues (although these are abound). The main two issues being:
Multisig users were crypto power users and often had multiple multisigs they were a part of and multiple personal accounts on a wallet. This posed many technical issues with syncing multiple accounts from the chain at once. This would blow wasm threading limits out because we had to manage individual user account syncing as well as multisig account syncing on too many accounts. A natural question is "why do we, as a multisig, need to handle a user's individual accounts?" Well that brings us to point #2.
Multisig users were accustomed to the Safe user experience wherein they can have individual extension, hardware or mobile wallets to use and just connect to their multisig. They are used to a Safe being able to access keys and wallet history for the existing wallet that is connected to the Safe. In our time working on Aztec Connect — there was only zkMoney for individual wallet usage. There was no way to easily match the Safe experience without running zkMoney style single user wallets in the background to sync. This takes us to the final issue —why we built a native mobile client for individuals for ZKP privacy chains.
Working with Aztec on a single user wallet 🤝
By the end of 2022, the Aztec Connect SDK was being picked up by a number of different teams and people to build their own Aztec Connect products. There was a couple of big issues though — keys were generated from metamask signatures in dApp and stored in a dApp site. This posed a big security risk if nefarious dApp devs could get you to try their dApp then they could steal your keys generated from metamask via a standard signature. Additionally, performance was poor if caches were cleared because the entire chain history would have to be re-synced again. Due to the security risk and our existing work on a individual user wallet to make a better private multisig experience — we began working with the Aztec team to build an individual user wallet. This does not have to be mobile native. We originally tried iFrame based with them, looked at Snaps, and then ultimately landed on building our own extension and mobile native clients due to performance bottlenecks in each!
Lessons learned from dApps
Next consideration that went into why we built a native mobile and extension product was our experience with dApps at the intersection of organizations and users. Here there were 2 big buckets we had to knock out if we were to build a mobile and extension client.
Connecting to users as an org using a dApp
dApp audience reach for onchain orgs
When building the wallets, we thought about rolling our own connection kit and optimizing for privacy specific features. We found this would cause an issue — onchain orgs didn’t want to use a dApp that would limit reach of users. If we rolled our own dApp<>wallet connection kit or went injected with ethers/metamask style, we’d have a competing standard that wallets would have to adopt in order to broaden the dApp audience or require adding a flask plugin for users to download not to mention company implications to support such efforts.
We ended up with WalletConnect as it was growing in popularity as a standard connection kit included in all connection kits, standardizing adding new chain support, and it was adding decentralized features to help solve the other problem we were seeing in org<>user dApps — 1:n communication to users.1:N Communication to users
At Nucleo, we ran 2 fundraising campaigns and 1 NFT storefront campaign before Aztec Connect shutdown with many more campaigns in the pipeline with other onchain orgs. At the time — DAOs were starting to shut down and the campaigns we ran were with DAOs that ended up winding down. In the products — users contributed funds or purchased membership passes that could be refunded to the DAO should it have not hit its targets Kickstarter style. However — they required contributors to go and redeem their funds themselves as neither the dApp nor the onchain org was authorized to spend the funds if targets were not met based on the smart contracts.
Communication to users to come and claim their funds is still an ongoing issue. At the time of this writing — there still is over $65,000 waiting to be claimed by users from these campaigns. We could have required emails on contributions so we can notify, but at the time we did not anticipate this and we only have wallet addresses that we can’t communicate 1:N to notify users to go claim funds. The only channels of communication we have to users was Discord, Twitter and Telegram — often infrequently checked after initial interaction. As previously mentioned, WalletConnect was building out functionality for this to be as a decentralized service and thus it made WalletConnect and easy decision.
Building for generalized ZKP privacy chains and a wider variety of zk circuits for smart contracts on these chains.
After building more ZK-dApps with Leo and Noir, we found a number of different bottlenecks that dApps would experience around data & CPU consumption for a wallet on SRS strings, key synthesis, and witness generation. Our iOS lead gave a talk at ZK Summit 10 on this! Github repo is here if you're interested in giving it a whirl.
If you found this interesting and are interested in trying to make your own zkGame dApp on Aleo — check out our starter repo here! If you’re interested in joining our dev telegram community — join here.
