|
| 1 | +# Supply Verifier |
| 2 | + |
| 3 | +The Supply Verifier package provides components to ensure the integrity of an |
| 4 | +asset's supply. It includes a supply syncer for an asset issuer to publish |
| 5 | +cryptographic commitments of the asset's total supply, and a verifier for |
| 6 | +other network participants to validate these commitments. This document outlines |
| 7 | +the core workflows for publishing, syncing, and verifying supply commitments. |
| 8 | + |
| 9 | +## Core Concepts |
| 10 | + |
| 11 | +* **Supply Commitment:** A cryptographic proof representing the total supply of |
| 12 | + an asset at a specific point in time. This commitment is published by the |
| 13 | + asset issuer and anchored into an on-chain Bitcoin transaction. |
| 14 | +* **Issuer:** The node responsible for creating and issuing an asset. It is the |
| 15 | + only entity that can publish supply commitments for that asset. |
| 16 | +* **Universe:** A designated node (or set of nodes) that acts as a repository |
| 17 | + for supply commitments, making them available to the rest of the network. |
| 18 | +* **User / Verifier:** Any non-issuer node that wants to independently verify |
| 19 | + the supply of an asset. |
| 20 | + |
| 21 | +## Workflows |
| 22 | + |
| 23 | +There are two primary workflows: publishing a new commitment and syncing |
| 24 | +existing commitments. |
| 25 | + |
| 26 | +### 1\. Publishing a Supply Commitment |
| 27 | + |
| 28 | +This flow is managed by the supply commit state machine on the Issuer's |
| 29 | +node. The `supplyverifier` package provides the supply syncer component, which is |
| 30 | +used by the state machine to push the commitment proof to the default universe |
| 31 | +server as well as the canonical list of universe servers specified in the |
| 32 | +asset's metadata. |
| 33 | + |
| 34 | +1. The supply commit state machine waits for the on-chain commitment |
| 35 | + transaction to be broadcast and receive sufficient confirmations. |
| 36 | +2. Before the supply commitment creation process is considered final, the state |
| 37 | + machine uses the supply syncer to push the new supply commitment proof to the |
| 38 | + Universe for storage and distribution. |
| 39 | + |
| 40 | +#### Call Flow: |
| 41 | + |
| 42 | +* **Issuer Side (Push to Universe):** |
| 43 | + * The process starts in the `supplycommit.Manager`, which manages and |
| 44 | + multiplexes across all asset-group-specific supply commit state machines. |
| 45 | + * It calls `supplySyncer.PushSupplyCommitment` to transmit the on-chain data |
| 46 | + and supply tree proofs for the supply commitment to the designated |
| 47 | + universe server(s). |
| 48 | +* **Universe Side (Receiving the Commitment):** |
| 49 | + * The request is received by `rpcserver.InsertSupplyCommitment`. |
| 50 | + * The server then passes the commitment to |
| 51 | + `supplyverify.Manager.InsertSupplyCommit`. |
| 52 | + * Finally, the commitment is stored locally via |
| 53 | + `supplyCommitView.InsertSupplyCommit`. |
| 54 | + |
| 55 | +```text |
| 56 | +Issuer Node Universe Node |
| 57 | + | | |
| 58 | +[supplycommit.Manager] | |
| 59 | + | | |
| 60 | + v | |
| 61 | +[supplySyncer.PushSupplyCommitment] -------> [rpcserver.InsertSupplyCommitment] |
| 62 | + | |
| 63 | + v |
| 64 | + [supplyverify.Manager.InsertSupplyCommit] |
| 65 | + | |
| 66 | + v |
| 67 | + [supplyCommitView.InsertSupplyCommit] |
| 68 | +``` |
| 69 | + |
| 70 | +### 2\. Syncing Supply Commitments |
| 71 | + |
| 72 | +This flow is initiated by a User (a non-issuer node) who wants to verify |
| 73 | +the supply of a particular asset. |
| 74 | + |
| 75 | +1. The User enables issuance syncing for the target asset. |
| 76 | +2. The issuance syncer fetches the asset's on-chain data and publishes an |
| 77 | + event to the supply verifier. |
| 78 | +3. The supply verifier state machine begins the process of syncing supply |
| 79 | + commitments from the Universe. |
| 80 | + |
| 81 | +#### Call Flow: |
| 82 | + |
| 83 | +* **User Side (Fetch from Universe):** |
| 84 | + * The sync process is kicked off by the `supplyverify.Manager.SyncSupplyCommit` |
| 85 | + method. This can be triggered in two ways: either when the supply verifier |
| 86 | + receives a notification from the issuance syncer, or when a known supply |
| 87 | + commitment transaction output is spent. The user's node monitors all |
| 88 | + on-chain supply commitment and pre-commitment outputs; the expenditure of |
| 89 | + these outputs serves as a signal that a new synchronization is necessary |
| 90 | + for the corresponding asset group. |
| 91 | + * It first calls `supplyCommitView.FetchSupplyCommit` to find the last |
| 92 | + commitment it has stored locally. |
| 93 | + * It then calls `supplySyncer.FetchSupplyCommit`, which makes an RPC call via |
| 94 | + `rpc.FetchSupplyCommit` to the Universe. |
| 95 | +* **Universe Side (Serving the Commitment):** |
| 96 | + * The request is received by `rpcserver.FetchSupplyCommit`. |
| 97 | + * The server retrieves the requested commitment(s) via |
| 98 | + `supplyverify.Manager.FetchSupplyCommit`. |
| 99 | + * The data is read from local storage using |
| 100 | + `supplyCommitView.FetchSupplyCommit` and sent back to the User. |
| 101 | + |
| 102 | +```text |
| 103 | +User/Verifier Node Universe Node |
| 104 | + | | |
| 105 | +[supplyverify.Manager.SyncSupplyCommit] | |
| 106 | + | | |
| 107 | + v | |
| 108 | +[supplyCommitView.FetchSupplyCommit] | (Finds last known local commit) |
| 109 | + | | |
| 110 | + v | |
| 111 | +[supplySyncer.FetchSupplyCommit] | |
| 112 | + | | |
| 113 | + v | |
| 114 | +[rpc.FetchSupplyCommit] -------------------> [rpcserver.FetchSupplyCommit] |
| 115 | + | |
| 116 | + v |
| 117 | + [supplyverify.Manager.FetchSupplyCommit] |
| 118 | + | |
| 119 | + v |
| 120 | + [supplyCommitView.FetchSupplyCommit] |
0 commit comments