Account abstraction and Aleo

Aleo account abstraction, WalletConnect, private multisigs, fast ZK Proving & fast client syncing all on mobile (and extension).

Puzzle believes 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, opinionated design decisions for this initial release, and some history!

On Aleo Account Abstraction and the design decisions made

Puzzle base design decisions as a team on a balance of short term goals and long term goals for the company. In the long term, Puzzle 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. Puzzle willnever 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, Puzzle 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 — Puzzle 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 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 does Puzzle know? Puzzle experienced this firsthand with Nucleo private multisig and other suite of onchain org products in 2022. In order to test 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 Puzzle 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 Puzzle 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 Puzzle are so excited for Aleo Account Abstraction because it means the time for rapid iteration and product feedback loop is here.

Now Puzzle 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.

Puzzle 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. Puzzle found the multisig & seedless account creation as not a high priority for users at the moment and Puzzle even found that crypto natives would like to see their seed phrase at the onset of wallet creation. So in current implementation, Puzzle don’t abstract user accounts with MPC or private multisigs out of the gate. Puzzle 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. Puzzle 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, Puzzle 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 Puzzle 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. Puzzle are en route to get there with research we have brewing. Puzzle’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.

Puzzle have chosen to be opinionated in design with what Puzzle show and what Puzzle don’t based on this and plan on continuing to move towards abstracting the chain in most areas. If you have feedback and feel Puzzle should do otherwise or change something in existing design — drop them a line on Twitter as they’d love to hear your feedback!

Some history on how Puzzle got here

The journey to build a mobile native ZKP privacy wallet started in 2022 back in Nucleo days. At Nucleo, Puzzle 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. Puzzle built privacy infrastructure like private/public multisigs and org<>user interfacing products like payroll, NFT storefronts, fundraising campaigns. Puzzle 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 Puzzle needed to build 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. Puzzle wanted to share our experience and lessons learned for the broader industry to learn from below!

Lessons learned from private multisigs

Puzzle first product at Nucleo was the private multisig and right off the bat Puzzle noticed 4 huge problems that led us to start our mobile journey.

1. Multisig users wanted notifications when transactions were proposed.

Puzzle had a couple options Puzzle explored here. Most multisig signers had a group text, telegram, slack or discord for coordinating when they needed to sign. Puzzle 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.

2. Multisig signers predominantly used mobile to sign

Again there are a couple of options here. Puzzle 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….

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:

1. 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.
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.
3. Working with Aztec on a single user wallet 🤝
4. 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!

If you found this interesting and are interested in trying to make your own zkGame dApp on Aleo — check out starter repo here! If you’re interested in joining our dev telegram community — join here.