/facade

Primary LanguageWebAssembly

Facade

A Zk multisig wallet which enables on chain anonymity.

Description

Smart wallets these days do not have the ability to 'hide' the owners that are responsible for making the transaction through it. This allows anyone with abit of Etherscan knowledge to track the Eoa's that are responsible for all transaction made by that smart wallet. if the smart wallet possesses a large amount of assets, this may pose a life hazard towards the real owners as malicious actors may target the owners and threaten them to obtain their assets.

These are problems that could be avoided should the owner of the smart wallet be unknown from the start. The current status quo for transferring assets anonymously will be to use Tornado Cash or similar mixer protocols to blind the traces of the transaction. This method works but only limited to asset transfers. What if, we would like to extend to that capabiliy? What if we also want to interact with various smart contract anonymously such as defi protocols....

Facade Wallet aims to achieve that. We allows owners to perform all transaction as would a normal Multisig Wallet but anonymous by default. Using the power of zero knowledge proofs, the owner will generate the proof locally, proving that the owner has signed a transaction call data correctly as well as also proving the ownership of the wallet.

The proof is then passed on to a relayer and the proof contains reveals the transaction call data which will then be executed by Facade. Inputs such as the owner of the wallet and the signature are either encrypted or passed in as private inputs to the circuit.

The wallet, upon receiving the proof, will verify the proof and if correct, execute the transaction call data as would a normal smart wallet, thereby allowing a transaction to be performed anonymously.

Architecture

On the smart contract itself, instead of the address of the owner that is being stored in the registry, we store the hashed of the address of the owners. The rationale behind doing that is to hide address in plain sight and also we will be using the hashed address as the public input to our circuit. Inside our circuit, we will recompute this hash and compare it against the signer of the transaciton, to ensure that the proof is really generated by the owner.

The transaction call data have to be public input as this will be used to execute the function call in our wallet's execute function. The signature has to be private as we will be able to retrieve the signer's address otherwise.

The circuit will then recover the addess in the circuit, compute the hash of the address and compared it against the hashed address (which is the public input of our circuit). If all the constraints are satisfied, the proof is verified and the wallet will proceed to execute the transaction call data.

A relayer is an optional addon for owners to submit proofs on chain just like how Tornado Cash does it to allow the party caling the execute function to have gas to perform this transaction

image

Future improvements

  • Proof aggregation that allows multiple owners to aggregate their proofs into one thereby reducing the gas cost to verify the proof onchain
  • Gas abstraction style relayer should the chain does not support Erc 4337 natively.