1  We are going to walk through a simple contract that uses ZK.
  2  
  3  ## Problem
  4  
  5  Suppose you want to build a name registry.
  6  
  7  You want this to be:
  8  * resistant to any coercion
  9  * leaving no trace of who owns a name
 10  
 11  Because the users intend to use it for critical things that they like privacy for.
 12  Say naming their wallet address e.g. anon42's wallet address -> 0x696969696969.
 13  
 14  Getting a wrong wallet address means, you pay a bad person instead of anon42.
 15  Revealing who owns the name reveals information on who might own the wallet.
 16  Both are unacceptable to your users.
 17  
 18  Upon examination we see backdoor in many solutions.
 19  
 20  1. If you run a database on a "cloud", the provider has physical access to the machine.
 21  1. Domain owners can change what the domain name resolves to.
 22  
 23  ## Solution: Darkmap
 24  
 25  An immutable name registry deployed on Darkfi.
 26  
 27  * names can be immutable, not even the name registry owner can change the name
 28  * there is no trace of who owns the name
 29  
 30  ### API: Get
 31  
 32  From an end user perspective, they provide a dpath and get a value back.
 33  
 34  ```
 35  provide: darkrenaissance::darkfi::v0_4_1
 36  get:     0766e910aae7af482885d0a5b05ccb61ae7c1af4 (which is the commit for Darkfi v0.4.1, https://codeberg.org/darkrenaissance/darkfi/commit/0766e910aae7af482885d0a5b05ccb61ae7c1af4)
 37  ```
 38  
 39  ### Syntax
 40  
 41  ```
 42    Colon means the key is locked to particular value.
 43    For example, the key v0_4_1 is locked to 0766e910aae7af482885d0a5b05ccb61ae7c1af4
 44    in the name registry that darkrenaissance:darkfi points to.
 45    Helpful to that a tag always means the same commit.
 46                    v
 47  darkrenaissance:darkfi:v0_4_1
 48     ^               ^ 
 49     |                \
 50     |                 \
 51     |                  \
 52  top level registry    sub registry
 53  
 54  
 55    Dot means the key is not locked to a value. 
 56    It can be locked to a value later or be changed to a different value.
 57    For example, master (HEAD) currently maps to 85c53aa7b086652ed6d2428bf748f841485ee0e2,
 58    Helpful that master (HEAD) can change.
 59                    v
 60  darkrenaissance:darkfi.master
 61  
 62  
 63  All parts except the last resolve to a name registry.
 64  * darkrenaissance is a top level registry, it resolves to an account controlled by an anonymous owner
 65  * darkfi is a sub registry, for example darkrenaissance:darkfi resolves to an account
 66  * there can be multiple paths to a name registry, for example, dm:darkfi can resolve to the same account as above
 67  ```
 68  
 69  ## Implementation
 70  
 71  ```
 72  # Let's begin by building the zkas compiler
 73  git clone https://github.com/darkrenaissance/darkfi
 74  cd darkfi && make zkas
 75  PATH="$PATH:$PWD"
 76  
 77  # Pull down the darkmap contract for our learning
 78  cd ../ && git clone https://github.com/darkrenaissance/darkmap
 79  ```
 80  
 81  ## Tool 1: `ZKAS`, `ZKVM`
 82  
 83  We want a way for someone to control an account and account to control one name registry. 
 84  You could use public key cryptography.
 85  But in here, we will use ZK to accomplish the same thing for our learning.
 86  
 87  In Darkfi, circuits are programmed in `ZKAS` (ZK Assembly) and later run in `ZKVM` for generating proofs.
 88  
 89  There is one circuit that Darkmap uses, which is the `set` circuit for gating the `set` function.
 90  
 91  Let's see what it does and start reading `<darkmap>/proof/set_v1.zk`.
 92  
 93  ### `zkrunner`, `darkfi-sdk-py`
 94  
 95  We mentioned ZKAS circuits are "run inside" ZKVM. How?
 96  
 97  There is a developer facing CLI zkrunner. The CLI allows you to interact with ZKVM in Python.
 98  
 99  Let's see how to run the set_v1.zk by reading `<darkfi>/bin/zkrunner/README.md`.
100  
101  ### Outcome
102  
103  Good job! Now you have learned how to prove and run using a ZKAS circuit.
104  
105  ## Tool 2: WASM contract
106  
107  In Darkfi, a contract is deployed as a wasm module. 
108  Rust has one of the best wasm support along with C and C++, so Darkmap is implemented in Rust.
109  In theory, any language that compiles to wasm can be used to make a contract.
110  
111  Let's learn about the contract by reading `<darkmap>/src/entrypoints.rs`.
112  
113  ## Deploying, testing and client
114  
115  FIXME: perhaps more detailed explanation
116  
117  ## Deploying 
118  
119  Currently, the infrastructure for deploying non-native contracts is being worked on. 
120  So Darkmap was tested by modifying the darkfi validator to deploy it as native contract.
121  
122  If you like to try it out, take a look at the [pull request draft](https://codeberg.org/darkrenaissance/darkfi/pulls/170/files#diff-1592d061816d5a4da17e089758e15df75ae1ab963b2288e6d84b8f29b06f7d4f).
123  
124  In particular:
125  * `src/consensus/validator.rs`
126  * `sdk/src/crypto/*`
127  
128  ## Testing and client implementation
129  
130  For now, the best place to learn is to learn from the darkmap pull request draft or `src/contract/money`.
131  
132  ## Notes
133  
134  * Where are the states stored?
135  * What are the host-provided functions you can call from within the contract?
136  	* https://codeberg.org/darkrenaissance/darkfi/src/branch/master/src/runtime/import
137  * What are the tools?
138  	* zkas
139          * zkvm
140          * the host-provided imports
141  	* wasm
142  	* client
143  	* transaction builder
144  	* testing libraries and functions
145