What Makes ZK Blockchain Wallet Hard to Implement?

Blockchain wallets are an important aspect of the cryptocurrency ecosystem since they enable users to safely deposit, receive, and send crypto assets, as well as serve as portals for users to develop and engage with Web 3 apps. With the continued expansion of the crypto market and the maturing of zero-knowledge technology (ZK), an increasing number of developing public chains are beginning to employ it to better security and anonymity. Creating wallets for these ZK public chains, on the other hand, is immensely complex. This is due to the fact that it not only contains numerous advanced cryptography and mathematical principles, but also high technological skills and intricate algorithm optimizations. This article will take Aleo as an example to investigate the implementation challenges of wallets for ZK public chains, as well as the rationale behind them.

What does a crypto wallet look like?

Let’s first think about what a blockchain wallet is from a low-level perspective. In a nutshell, it is a wrapper for the blockchain full node API that also provides a secure local environment for storing and using a user’s public-private key pairs. Typically, in order to facilitate development, the full node will provide a large number of APIs for developers to use, as shown in the following figure.

And what the wallet does is to hide the complexities of these APIs and create a high degree of abstraction, allowing users to interact with the blockchain through a simple user interface. While offering this high degree of abstraction, the wallet also provides security and usability.

When we initiate a transaction, the wallet actually does the following for us:

• Generates the corresponding transaction in the local environment
• Signs the transaction using the private key in the local environment
• Uses API to operate on the chain node to broadcast the transaction in the local environment
• The chain node processes the transaction and broadcasts it in the remote environment.

It’s obvious that when we process a transaction, our operations involve two environments: the unsafe remote environment and the safe local environment. The wallet encapsulates the privacy and security-related lightweight components of the full node API (such as operations involving user private keys) into a local, easy-to-use operating environment, such as a web browser or mobile app. Heavier workloads, such as those that require full node storage and a large number of p2p calls, are handled by remote servers, such as cloud service providers.

Why is it more challenging to build a ZK chain wallet?

In the ZK public chain, everything is different. Unlike mainstream chains, it broadcasts verified proofs instead of signed transactions. Here’s a brief introduction to zero-knowledge proof technology, or zkSNARK at the core. Simply put, zkSNARK is a proof system that can conceal the essence of a computation (input, process, and result) and generate corresponding verifiable proofs, proving that the input, process, and result are valid and consistent.

The computation essence here can be any programming language, but in the context of blockchain, we typically refer to the corresponding ZK smart contract programming language, such as Leo in Aleo or Cairo in StarkNet.

Everything looks great, right? Not only does it provide security but also privacy, and the succinct feature of zkSNARK can even enable Layer 2 scaling for various blockchains. However, there is no such thing as a free lunch in the world. Here come the major drawbacks.

1. The Proof Generation is too Slow

The time it takes to generate a proof is too long and requires a significant amount of computing resources to achieve a better user experience. This is because generating proof involves a lot of mathematical calculations, such as polynomial-based Number Theoretic Transform (NTT) and Multi-Scalar Multiplication (MSM) on elliptic curves. As mentioned earlier, the main operating environments for wallets are lightweight mobile apps and web browsers, which may lack the necessary proof-generation environment, such as a virtual machine (VM) for the corresponding smart contract execution, and often lack the required computing resources.

Can we compile the virtual machine into WASM and put it in a web environment? It is indeed feasible, but the draconian requirements for computing resources still remain. For a transaction, you may need to keep your mobile phone running at high load for a minute to complete.

Of course, there is an ultimate solution. The Aleo team mentioned a Delegatable Transaction solution in their ZEXE paper, which can be understood as using cryptographic methods to delegate the proof generation to a third-party computing service provider without revealing privacy and then returning the proof to the client for similar signature operations before submitting it to the chain. This allows many lightweight node devices to operate ZK smart contracts quickly without burden.

2. The Trade-off of the ZK Privacy

In order to ensure privacy, ZK public chains also need to make many changes to the underlying data model, such as Aleo’s RNK (the records nano-kernel) model designed based on Bitcoin’s UTXO model.

While ensuring privacy without sacrificing programmability, it introduces a lot of complexity. If ordinary dApp developers want to build applications on this basis, they have to be familiar with the full node development. In fact, the interfaces exposed by full nodes are often raw, and you have to consider the atomicity of transactions, more appropriate interface abstractions, and even performance optimization based on this. This is undoubtedly a burden for developers who only focus on contract development.

The solution is also similar, outsourcing this part of the service to an AaaS (API-as-a-Service) provider, who can offer a highly available and high-performance chain interaction interface. This greatly reduces the complexity of development without sacrificing performance.

ZK Future Architecture

From what we’ve discussed above, we can roughly glimpse into the possible architecture of the future ZK world. There will be a large number of service providers revolving around developers and ZK public chains, who will serve as the gateways for developers and chain interactions, just like cloud service providers in Web2. As an infrastructure service provider in the ZKP field, ZKRush’s main focus is currently on accelerating the ZKP algorithm and hardware to achieve significant performance improvements and energy consumption reduction in the proof generation process. As time goes by and with the development of the ZK ecosystem, chain services will also become our direction of construction.