A secure wallet container using WASM, ZK-Snarks and smart contracts
This tecnology being introduced in this post I will label it “secure wallet container” and it uses diverse set of technologies to accomplish many things that are needed in the present.
Considering that since I started in blockchain back in 2017, the security premise around wallet has been almost the same, that is:
- Uses BIP-44 Hierarchical Derivation, that is, seed phrases
- Have them manage directly by the end user
- And then they can also be private keys, which gives a layer of complexity to users.
Of course there has been invention along the ways, like Gnosis Smart Contract wallet and latest ERC-4337 Account Abstraction, but still, there is plenty of innovation to be found in new, radical designs, and for that matter, zero knowledge proofs are useful for what we want to do.
The Solana (and Near) wallets attacks has proven that, without industry best practices (audits):
- Any startup or team can develop and be a succesful wallet provider, if there is low competition or not many options.
- And not that many wallet teams has ZK experts or advanced Solidity engineers
Given that, these last weeks wallet attack won’t be the last. It’s just starting.
Architecture
This wallet architecture design starts with a secp256k1 wallet inside a WASM container, which should be WASI compatible or similar, with access to file to stored encrypted keystores.
This wallet also hasa ZK-Snarks circom-ecdsa library that everytime a new keypair is generated, a proof of private key is created.
The seed phrase is never accessed by the user, it gets encrypted by hardware, in this case a key exchange set of keys generated by FIDO2 / WebAuthentication devices. This gets stored in decentralized storage networks like Swarm.
By using the same hardware, recovery kits are also available, an option more robust and secure than writing seed phrases on paper.
Instead of a smart contract per wallet, there is just one, the KeyController, which keeps track of the private keys sequence (ie a set of ZK proofs, hashes, ids, etc), with rotated keys revoked after an epoch.
A Keeper emits an event, that is sent to a KeySequencer offchain client, that then proposes to the user a window to rotate the key and gas costs.
User signs and a transaction is eventually executed and it updates the ENS registry with the new public key and address.
In fact, any wallet creator could decide not to use actual addresses and create a wallet that only uses ENS or similar name addressing schemes.
The onboarding process is similar to rotation but with a caveat, the smart contract must have funding to pay for the initial private key sequence.
Because we want to give wallet creators and founders a way to have income and at the same time focus on quality and security, the idea is that there is a staking pools of wallet tokens, that funds the onboarding and also the private key rotation, which is a service that users would like because you avoid using the same private key over and over.
Why would we want to rotate keys?
I would like to end this article with an easy to grasp metaphore: the credit card.
- You deposit an initial amount
- You pay an annuity for the service
- You pay a monthly insurance
- And the cards gets “rotated” by using an expiration date
- And the number gets burned, never used again (I think…. not really sure)
Because with credit cards you can do “carding” and to avoid depending on onchain data, an additional security measure is registering the revoked private key in Certificate Transparency store offchain.
And with that, wallet developers and teams, this design spec will give you the proper mechanism to good hygiene with key secrets management and to never ever display another mnemonic to users and asking to write 12 or 24 words in a paper note.
-Rogelio Morrell C.
