DEP 0004: Client wallet WASM modules
status: draft
Current Situation
In the current wallet implementation, we have hardcoded functionality for the native contracts such as Money and DAO. This makes it difficult to support arbitrary contracts deployed on the network within the same wallet software, as suport for any contract would have to be written upstream (in DarkFi) and maintained by the DarkFi developers.
Motivation: Limitations of Current Approach
The issue with this approach is that it is impossible to arbitrarily add support for arbitrary smart contracts deployed on DarkFi to the wallet software. Such support would have to live upstream and would have to be maintained either by the DarkFi devs, or reviewing submitted patches.
This slows down development and makes it difficult for contract devs to iterate on their designs and contract functionalities.
Proposal: Add support for plugins as WASM modules to the wallet
This proposes converting the wallet software into a standalone library that has an integrated WASM runtime supporting modules that define a client API for any smart contract on the DarkFi network (including the native network contracts).
The scope of this work would also require that the current native contract client API is rewritten in this manner as well.
The library would provide a mechanism of communication between the WASM modules (which define contract client API) and the wallet storage (which might be secret keys and other private information) in order to be able to produce transactions that call certain smart contracts.
The wallet storage implementation should be arbitrary and left to the implementors of the wallet software. The communication would be done using wasmer's host function support - much like what is currently being done in the DarkFi full-node and the deployed WASM smart contracts.
The library should also implement an object ACL (Access-control list) that WASM modules would request access to, for security reasons. This would allow a quick overview of what a client module requires from the wallet in order to operate correctly. For example it might be required to produce a signature: This means that the WASM module can export the data that needs to be signed to the wallet, the wallet can sign this data, and export back the signature to the WASM module, resulting in a valid signature without WASM ever gaining knowledge of the secret key used to produce such a signature.
Implementing such functionality could also greatly simplify the way ZK proofs are being created, as the client WASM modules can bundle the zkas circuits and define the way the proofs are to be made.