Arweave TX
songz
Accounts are strange and complicated on blockchains. I don't think I'm anywhere near a position to claim that I know a whole lot about blockchain accounts, nor do I think there are any right answers. This post is trying to be some old-school random thoughts of an engineer talking about some not-obvious but not-trivial facts that might, hopefully, be a fun read.
I am the technical Co-Founder of an open protocol solving account management problems (AKA a Wallet) called Choko. Choko is a mixture of different technologies that aim to bring a Robinhood-like experience for users to play with Web3. We want Choko to be a product that abstract away the idea of different chains/ecosystems, seedless, secure, and non-custodian. We want to get to know our users but we don't want our machines to know our users at all. ZKP, MPC, Account Abstractions & the Lighting Network are heavy targets of research and engineering for us.
I have been obsessed with the recent zero-knowledge proof systems for the past months. Sometime last week, I might have only slept for a few hours in 3 days and rendered myself in a metastable and strange mindset. Somehow, when I was taking my breakfast tea while preparing to go to sleep, I had this epiphany moment of a very obvious fact that I overlooked - the EIP4337 alternative mempool actually gives no shit about who is submitting the transaction on chain & who is the supposing `msg.sender` in the classical EVM sense. During that time, I was also struggling for the problems of how to stick to the no-address-reuse principle of Bitcoin wallets and how we should properly implement that since our MPC node implementation does not contain a key derivation schema and some kinda off-chain nonce systems always sounds wrong. A strange idea comes to me, what if, when ZKP is significantly more efficient, we ditch the idea of the classical ECDSA altogether without changing a single code of any blockchain consensus.
It's almost becoming an indisputable fact that the EVM-style account system is the de-facto blockchain account system that people think. The Account Abstraction EIP 4337 gain attention recently because of its simplicity and non-intrusive nature onto the underlying Ethereum consensus layer. But let's take a step back to understand how Bitcoin works first. In an oversimplified sense, Bitcoin runs on a UTXO system and the Bitcoin Script governs who is able to spend each UTXO. Whenever a user is trying to send a transaction, the wallet will try to scan for the UTXOs the user owns and try to figure our which UTXOs the user is able to spend. For instance, If I'm trying to send Alice 20 BTC, and I have a bunch of 8BTC UTXOs, the wallet will spend 3 * 8BTC UTXOs, in which two of them will be drained empty and the last one will be left with a 4 BTC change, the wallet will then deposit the 4BTC to a new address of my choice, then broadcast this transaction with 3 inputs and 2 outputs. (i.e. the 3 IN UTXO, one destination TXO, one change TXO). All things sound plain and intuitive to this point but if we compare it to the Ethereum design, they are dramatically different. For Ethereum, on the same example, the EVM would check if my account balance is actually higher than 20 ETH, then subtract 20ETH from my balance ledger and add 20ETH to the destination ledger.
The Ethereum accounts are great because they are easily understandable. It's similar to how Web2 database works. Implementing a wallet for Ethereum is straight forwards. There are no UTXOs to manage. There is only one address for each private key. Even though Ethereum is compatible with the BIP39 style HD wallets, it's optionally and most users won't need them either way. It gives a wider playground for SBTs, DIDs, on-chain governance etc. And tons of innovations started and millions of developers got on board.
To set the scene for the discussion following, there are a few properties that are important to be considered for blockchain account management systems: forgiving - would a user able to send their coins if they lost their seed phrase; privacy - would it be a trivial job to understand the whole history of an address, who they are sending coins to, how many coins they own, what are their positions on DeFi, which contracts they are interacting with, and most importantly, who they are in real life; security - would it be possible for someone to troll the system as someone else and conduct malicious behaviors to the systems or the user funds; ease-of-use - would it be easy for a user themself to know their balances, their transaction history, their DeFi positions. I'm sure they are many other aspects but I'll keep it simple only discuss these four.
I believe we are at a point where blockchains are more powerful than they have ever been in the past. For one, we have solved the universal trusted setup issue for ZKP while having the proof and verifier sufficiently succinct and efficient. For two, sequencer/miner/RPC providers are turning into mature businesses, while we kinda have been running out of ideas on how to make new types of DApps (for now). Ethereum is pushing out updates faster and more powerful than it had ever been (a pretty low benchmark to compare against tho LOL); Bitcoin finally finished the Taproot updates and allow for batch signature verification.
Let's first think about the EIP4337 Account Abstractions. It's a simple idea - having a smart contract as the user account to detach the user signatures from on-chain assets. To break it down a little bit: the user owns their key pairs and product signatures on a tweaked CALLDATA to proxy the real transaction through a contract called EntryPoint and send the transaction to bundlers. The bundlers verify the transaction or even dry run the transaction first then broadcast the transaction onchain. It is forgiving - the verification logic and be customized and won't rely on a single point of failure of losing the private key. It can be private - but not realized yet. I'll talk more about this in the next section. It is secure - nothing is more secure than a well-constructed and bug-free smart contract. It is easy to use - users don't even need to pay for gas or pay with customized payment logic. Plus, because of the database-like nature of Ethereum, users can deposit assets to the smart contract address even before the contract is deployed.
On a side note, the idea of "message signatures" and "transaction signatures" are probably poorly understood by most Ethereum developers, but I think it's for the optimal strategy. We have deliberately called the same underlying method by two different names and made some developers think about transaction signatures as some magical mythical things, while might be in the trap of under-looking the security implication of message signatures. My friend, who is a successful technical founder of a blockchain startup, even fell for a sign message signature attack and lost a few hundred $. But all that aside, if I could go back to history, I believe I would still be on the side of such a division, as it hints the developers to take better care of the transaction signatures and, actually, do more protection than damage.
But we haven't talked about Seedless yet. To define the idea further, Seedless, beyond the obvious that the users don't need a seed phrase to control an account, should be a mechanism to construct alternative account systems without forking the blockchain consensus and without any security and privacy downgrades. One common approach is the MPC-ECDSA cryptography. But I feel like it is usually badly understood or misused. At Choko, we have built our own MPC implementations and we think about MPC as a stateless and trustless machine that transforms one form of authentication to another. For seedless wallets, MPC will transform a user's social login authentications to signatures verifiable on-chain. Potentially, you can plug and play with a whole lots of different kinds of transformations as you want. I won't fully dive in this topic further as there are many interesting issues on signature schema, deterministic signatures, decentralization, and key rotations that I have enjoyed a lot exploring but that would detour us from the topic.
One thing, however, worth a few words of discussion is the authentication issue on MPC-ECDSA. Imagine nodes holding private key shards of the users and the node might be managing thousands of those key shards, how are they supposed to distinguish one user from another? This is usually not much of a concern for MPC-ECDSA providers as they are traditionally serving a small batch of high-value custodian accounts and with everything to do with regulations and such, the authentication part can be handled on centralized databases and it's a very well-established field for the Web2 technology land. But things are different if a wallet is serving the wide public. It becomes a high concern for privacy and security if MPC nodes keep authenticating with the old-school approach. We will come back to this when we talk about The Future.
Now if we combine these two sets of technologies. we can see an awesome account management system. The users will be able to log in with their Google/Twitter accounts, MPC nodes will generate a key pair for the user without anyone having any knowledge of the private key t it. The users will see a smart contract address that will act as their public address. They can even send transactions without gas fee to play NFT or social games. To make it better, the user will have the same address across any EVM blockchains, and with some smart tweaks on bridges and cross-chain liquidity, we are able to deliver our initial promise of abstracting away the idea of blockchains altogether. and there is no Ethereum, Polygon or Arbitrum, just blockchains.
On a very high - philosophical level, Choko is built with three distinct layers: the credential management layer (i.e. the MPC layer for managing user EOA), the chain adapter layer (i.e. RPC of different blockchains, CALDATA encoding + Account Abstraction integrations), the application layer (i.e. Swap, Bridges, Transfers that mostly just a bunch of pre-defined CALLDATA encoding methods). It might be strange to some EIP4337 folks why we have separated the AA layer from the credential management - because AA does not contains user private information.
Choko has already delivered most of these features on a private Beta finished last month. But to this point, something is off and I think we might be missing something.
There are still a few hanging issues and a few seemingly unrelated technologies that bring inspiration to us.
The EIP4337 Mempool has not been widely discussed at all. The current paradigm is for the users to trust the bundlers to submit their transactions on-time but with few guarantees. After, it's the developers paying a centralized company for their users to get the job done. Bundlers are in a seriously advantageous position.
User authorizations. As we discussed above, this is the biggest loophole to every security guarantee offered by the rest of the stack. To boil things down, we are trying to prove some authentication token issued by the authentication providers are legit and contains the credential which the users claim they own.
MPC! MPC is one of the greatest technology innovations in the account management space but it has its weakness. We got questions like what if Choko goes under, would our users still be able to access their accounts? How do you manage and store the private key shards? Would Choko go against its users and start sending fraudulent transactions on behalf of the users?
Privacy. The account abstraction does bring major polyfill to the Ethereum account system but, so far, it has taken no effort in bring Bitcoin-like no-reuse addresses to Ethereum. A transaction that moves a large chunk of assets to CEX still has a significant price impact.
MEV. I guess MEV receives as much love as hate. If we are talking about a mempool and bundlers with almost unlimited power to user transactions without any PoW or PoS, we might be onto something both concerning and exciting.
Chains + Ecosystems. Bridging is not really our primary concern. I'm sure there are teams with a trillion times more experience in handling bridges than us. We should be concerned about the authorization part of different ecosystems and blockchains. Remember when we talked about MPC as the magical machine that turns one authorization into another? We should be concerned about the different forms of the output part of that machine. On the surface level, this is about the signature schema used by different blockchains. But this is a true rabbit hole when we dig further.
Based on what we have discussed above, there are parts of the solutions that I think we have a bigger chance of solving but, like any solution builders, there are still countless issues that we might not even know their existence yet. I will try to describe as much as I can in this section for what we think is a good direction to build further. It's not perfect and there are loopholes.
The authentication. I mentioned ZKP a couple of times, besides the simple proofs within the MPC implementations, there is much more to it. One of the experimental virgin lands is on a recursive ZKP on JWTs. JWTs and user credentials various by size & ZKP circuits are terrible at handling unknown sizes. Therefore, we take a recursive approach to build ZKP of a ZKP of a ZKP to offset the uncertainties and build smaller proofs. It's a similar idea to Account Abstraction in a weird way. I won't dive that deep into it but just to give an idea of the current performance - the end circuit contains only ~3k gates after recursion, takes about 2 minutes to build + prove with two rounds of recursion and the end proof is about 50KB long, takes 0.003 seconds to be verified.
Authentication Replay. What if a ZKP authentication is taken by a malicious user and used to replay some other transactions? One approach is to take inspiration from the ZCash design for Nullfiers but that sounds a bit too heavy for Ethereum. One simple workaround that we have in mind is to include a ZKP for the knowledge of an ephemeral private key and sign a signature of the raw transaction.
Competing Bundlers. We need bundlers to live without fenced gardens. To be more specific, there should be a market for bundling orders, while the bundlers compete for the orders. This will turn the paradigm around and encourage bundlers to behave reliably. The bundlers should be incentivized on-chain. With careful token-economic design, this should reach a parity of gas cost and incentives. While users, should hold an alternative token and stake tokens for bundlers to receive the bundling service. Such a design would, partially, remove developers from the chain of responsibility of securing bundling services for the users. For bundlers, this will be a fair game and stop the early-comer-take-all situation.
In summary, for the user land, the user produces a ZKP of their Web2 social login credentials along with a ZKP of an ephemeral private key. The user sends the ZKP and a signature of the transaction they want to send with the ephemeral private key. The bundlers will receive the ZKP, the ephemeral signed transaction and then produce a ZK verification of the ZKP as well as a signature verification on the signed transaction. If all looks good, they will sign the transaction with the bundler account and try to broadcast the transaction before anyone else does. The transaction will enter an alternative EntryPoint address for the simple purpose of counting the credit for the submitting bundler and getting into the EntryPoint to be executed.
Meanwhile, there are some potential interesting applications for such a system.
No Address Reuse: The ownership of the assets within each of the contract accounts is authenticated by the ZKP and can be masked when the bundlers execute the transactions. Therefore, it is easy to construct a Bitcoin style Non-Reusable address for the Ethereum ecosystem.
Generic Bundling For Different Chains: the underlying submission authentication is ecosystem agnostic and can be applicable to any blockchain system extremely easily - including but won't be limited to Edward Curve systems like Solana, Near, Aptos, Sui or UTXOs systems like Bitcoin, Ergo etc.
Secure Offchain Payment Channels: Similar to the Lightning Network but won't relays on wallet operators to be honest when managing the Lightning Network account for their users. This can be generically applicable to any blockchain as well.
However, a few hanging issues that I think worth discussion.
ZKP Efficiency: even though the ZKP circuit runs on the client-side and brings little to no burden to the public networks, the ZKP circuit still takes 2 minutes to run. It is obviously no trivial UX scarifies for the end users. The more common approach is to apply ZKP for critical transactions. However, there might be a better way to build a session based ZKP authorization to remove the dependency on the on-chain verification logic.
Tighter Game Design for Bundlers: designing a game theory system for bundlers to operate as expected is always hard and I believe our design is very preliminary.
Tokenconomic Design: designing the right system to encourage bundlers to compete by paying gas fee upfront is always a hard design problem. Tight calculations and regtest onto previous onchain data are of absolute necessity.
I hope you enjoy this note. Tbh, it's more like a thought dump than a real post, but I hope this post can be a great starting point for better discussions.
