|
@@ -0,0 +1,59 @@
|
|
|
|
|
+# 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.
|
parazyd