doc: partial edit of architecture/smart_contracts.md

doc/src/architecture/smart_contracts.md

@@ -50,35 +50,33 @@ mod dao_contract {
     }
 
     // Corresponds to 2. mint()
-    mod mint {
-        // Prover specific
-        struct Builder {
-            ...
-            // secret witness values for prover
-            ...
-        }
-
-        impl Builder {
-            fn new(...) -> Self {
-                ...
-            }
+    // Prover specific
+    struct MintCall {
+        ...
+        // secret witness values for prover
+        ...
+    }
 
-            fn build() -> FuncCall {
-                ...
-            }
+    impl MintCall {
+        fn new(...) -> Self {
+            ...
         }
 
-        // Verifier code
-        struct CallData {
-            ...
-            // contains the function call data
+        fn make() -> FuncCall {
             ...
         }
     }
+
+    // Verifier code
+    struct MintParams {
+        ...
+        // contains the function call data
+        ...
+    }
 }
 ```
 
-There is a pipeline where the prover runs `Builder::build()` to create the `FuncCall` object that
+There is a pipeline where the prover runs `MintCall::make()` to create the `MintParams` object that
 is then broadcast to the verifiers through the p2p network.
 
 The `CallData` usually is the public values exported from a ZK proof. Essentially it is the data
@@ -91,13 +89,13 @@ the entire tx is rejected. Additionally some smart contracts might impose additi
 on the transaction's structure or other function calls (such as their call data).
 
 ```rust
-{{#include ../../../bin/dao/daod/src/util.rs:transaction}}
+{{#include ../../../src/tx/mod.rs:transaction}}
 ```
 
 Function calls represent mutations of the current active state to a new state.
 
 ```rust
-{{#include ../../../bin/dao/daod/src/util.rs:funccall}}
+{{#include ../../../src/sdk/src/tx.rs:contractcall}}
 ```
 
 The `contract_id` corresponds to the top level module for the contract which
@@ -185,13 +183,13 @@ The transaction verification pipeline roughly looks like this:
 Lets review again the format of transactions.
 
 ```rust
-{{#include ../../../bin/dao/daod/src/util.rs:transaction}}
+{{#include ../../../src/tx/mod.rs:transaction}}
 ```
 
 And corresponding function calls.
 
 ```rust
-{{#include ../../../bin/dao/daod/src/util.rs:funccall}}
+{{#include ../../../src/sdk/src/tx.rs:contractcall}}
 ```
 
 As we can see the ZK proofs and signatures are separate from the actuall `call_data` interpreted

src/sdk/src/tx.rs

@@ -20,10 +20,14 @@ use darkfi_serial::{SerialDecodable, SerialEncodable};
 
 use super::crypto::ContractId;
 
+// ANCHOR: contractcall
 /// A ContractCall is the part of a transaction that executes a certain
 /// `contract_id` with `data` as the call's payload.
 #[derive(Debug, Clone, Eq, PartialEq, SerialEncodable, SerialDecodable)]
 pub struct ContractCall {
+    /// ID of the contract invoked
     pub contract_id: ContractId,
+    /// Call data passed to the contract
     pub data: Vec<u8>,
 }
+// ANCHOR_END: contractcall

src/tx/mod.rs

@@ -43,6 +43,7 @@ macro_rules! zip {
     )
 }
 
+// ANCHOR: transaction
 /// A Transaction contains an arbitrary number of `ContractCall` objects,
 /// along with corresponding ZK proofs and Schnorr signatures.
 #[derive(Debug, Clone, Eq, PartialEq, SerialEncodable, SerialDecodable)]
@@ -54,6 +55,7 @@ pub struct Transaction {
     /// Attached Schnorr signatures
     pub signatures: Vec<Vec<Signature>>,
 }
+// ANCHOR_END: transaction
 
 type VerifyingKeyMap = Arc<RwLock<HashMap<[u8; 32], Vec<(String, VerifyingKey)>>>>;