Add missing relation for asset-id for public auditor keys, remove un-neccesary relation and update specs

Author: lovesh

.github/workflows/dart-bp-tests.yml

@@ -61,7 +61,7 @@ jobs:
         uses: dtolnay/rust-toolchain@nightly
 
       - name: Run negative tests by disabling prover's input sanitation and mocking features
-        run: cargo +nightly nextest run --package polymesh-dart-bp --features ignore_prover_input_sanitation,nightly_mocking_tests input_sanitation_disabled
+        run: cargo +nightly nextest run --package polymesh-dart-bp --features ignore_prover_input_sanitation,nightly_mocking_tests input_sanitation_disabled mocking_tests
 
   test-wasm:
     name: Build dart-bp for WASM target

Cargo.lock

@@ -62,7 +62,7 @@ cargo nextest run -r --test serialized_objects_test
 
 To create the serialized data, run
 ```
-cargo nextest run -r --test serialized_objects_test --run-ignored ignored
+cargo nextest run -r --test serialized_objects_test --run-ignored only
 ```
 
 ## Code coverage

README.md

@@ -43,6 +43,7 @@ hex = { version = "0.4.3", default-features = false, features = ["alloc"] }
 lazy_static = { workspace = true, default-features = false, optional = true }
 itertools = { version = "0.14.0", default-features = false }
 mocktopus = { version = "0.8.0", optional = true }
+creusot-std = "0.11"
 
 [dev-dependencies]
 test-log = { workspace = true }

dart-bp/Cargo.toml

@@ -316,4 +316,28 @@ The chain allows 1 public key to have only 1 account per asset-id. This is done
 This is to ensure that a public key can do an accurate proof-of-balance for that asset without hiding any amount of that asset. In the future, we might support asset-id privacy during registration by the chain keeping a commitment of the assets per public key 
 and during registration, a proof of uniqueness of the new asset-id against the committed set is provided (likely using a linear cost non-membership proof).
 
+
+### Workflows
+The system supports 3 workflows for producing the proofs described in the rest of this document. The protocols are largely the 
+same across them; the only thing that changes is how secret keys are handled (and consequently how the proving/verification work is split between 2 parties).
+The idea is to use homomorphism of Pedersen commitments, which account commitments are, and split the commitment into two parts - one part containing the secret keys 
+and other part without them. Each party does its proof over its corresponding part and the verifier "combines" these 2 parts appropriately. Sometimes the parts can 
+just be added by the verifier to form the final commitment. However, sometimes revealing the parts can leak information so both parties blind their commitment with cancelling 
+randomness, i.e. $r$ and $-r$ which hides each commitment but during "combining", it cancels out.
+
+1. **W1 (Solo)**: A single prover holds all witnesses, including the secret keys $sk$ and $ek$, and produces the whole proof on its own. The protocols in the remaining sections are written assuming W1.
+
+2. **W2 (Parallel)**: Two provers — a device (e.g. Ledger) which holds the secret keys, and a host (the user's computer) which does not. How the commitment gets split depends on whether $AK$ and $EK$ are revealed for the transaction:
+
+   - **When $AK$ and $EK$ are revealed** (account registration, minting): they become public to the verifier, so the device just proves knowledge of $sk, ek$ in $AK = sk.G_{Aff}$ and $EK = ek.G_{Enc}$, and the host's part can have these subtracted out.
+   - **When $AK$ and $EK$ stay hidden inside the account commitment** (fee payment, transparent deposit/withdraw, affirmations): the device's part carries the secret-key terms together with a share of the commitment randomness, and the host's part carries 
+     everything else with the complementary share. Leg ciphertexts in affirmations are split the same way - the device contributes the $ek^{-1}$ and its proof and the host contributes the plaintext component ($amount$, $asset\_id$), its proofs, range proofs, 
+     curve tree membership proofs and other relations which use Bulletproofs. Thus all heavy lifting is done by the host.  
+
+   The two proofs run independently and in parallel, bound together by feeding the same nonce/context and the same public inputs (account commitments, nullifier, re-randomized leaf, leg ciphertexts, etc.) into both transcripts. The exact split is described in each protocol's section.
+
+3. **W3 (Sequential)**: Same split of work as W2 between device and host, but ordered. The host runs its pre-challenge phase first: it commits to its randomness, writes its instance to the transcript and derives its challenge $c_H$. It then sends $c_H$ to the device. The device sets its $nonce$ to $c_H \| nonce$ (concatenation of the byte serialization of $c_H$ and the original $nonce$), runs its proof against that combined nonce and sends the proof back. The host appends the device's proof bytes to its transcript, derives a fresh challenge $c_H'$ and generates its responses against $c_H'$. The verifier mirrors the same ordering.
+
+   There is no technical reason to use W3 over W2, but still ....
+
 ----------------------------------------

dart-bp/docs/1.md

@@ -55,6 +55,9 @@ A successful completion of registration results in the following:
 
 
 ### Protocol
+
+_The following description is for W1 (solo) where a single prover knows both secret keys $sk$ and $ek$ along with all other witnesses. The split-prover variant used in W2/W3 is described after the Verifier section below._
+
 Here the prover (investor) wants to prove following relations:
 
 1. $State_0 = sk.G_{Aff} + at.G_3 + \rho.G_4 + \rho^2.G_5 + s.G_6 + s^2.G_7 + id.G_8 + ek.G_{Enc}$. This is equivalent to proving $State_0 = AK + EK + at.G_3 + id.G_8 + \rho.G_4 + \rho^2.G_5 + s.G_6 + s^2.G_7$ since public key $AK$, encryption key $EK$, asset-id $at$ and identity $id$ are revealed to the verifier. So only $\rho, \rho^2, s, s^2$ need to be proved.
@@ -196,7 +199,54 @@ Above are the high level instance and witness values known before the protocol s
 14. Verifier finally checks the Bulletproofs proof that verifies all constraints, i.e for Poseidon2, multiplications and range proofs
 
 
-## Encrytion key distribution
+### Split prover variant (W2/W3)
+
+In W2/W3 the work is split between a host (which does not know $sk, ek$) and a device (which holds $sk, ek$). The host runs essentially the same protocol as above except its statement excludes the secret-key components: since $AK$ and $EK$ are public, the verifier can subtract them out, so the host only proves knowledge of the remaining witnesses in
+$$
+State_{0_H} = at.G_3 + \rho.G_4 + \rho^2.G_5 + s.G_6 + s^2.G_7 + id.G_8
+$$
+i.e. $State_0$ minus $AK$ and $EK$. Everything else the host does (nullifier proof, encryption-of-$s$ and $\rho$ to $pk_T$, range proofs, Poseidon2 constraint, etc.) is unchanged. The verifier reconstructs $State_0 = State_{0_H} + AK + EK$ and uses it in the original checks.
+
+The device produces a standalone Sigma proof of knowledge of $sk$ in $AK = sk.G_{Aff}$ and $ek$ in $EK = ek.G_{Enc}$. Both relations share the same challenge (single transcript).
+
+**Instance**: $AK, EK, G_{Aff}, G_{Enc}$
+
+**Witness**: $sk, ek$
+
+#### Device prover
+1. Pick random $sk_r, ek_r \in \mathbb{Z}_p$ and compute
+   $$T_{AK} = sk_r.G_{Aff}, \quad T_{EK} = ek_r.G_{Enc}$$
+2. Hash the device's transcript to get a challenge
+   $$c = Hash(nonce, AK, EK, T_{AK}, T_{EK})$$
+3. Responses
+   $$s_{sk} = sk_r + sk.c, \quad s_{ek} = ek_r + ek.c$$
+
+The device sends $(T_{AK}, T_{EK}, s_{sk}, s_{ek})$ to the verifier (or, in W3, to the host first).
+
+#### Device verifier
+1. Recompute the challenge:
+   $$c = Hash(nonce, AK, EK, T_{AK}, T_{EK})$$
+2. Verify the affirmation key relation:
+   $$s_{sk}.G_{Aff} \stackrel{?}{=} T_{AK} + AK.c$$
+   $$\implies (sk_r + sk.c).G_{Aff} \stackrel{?}{=} sk_r.G_{Aff} + AK.c$$
+3. Verify the encryption key relation:
+   $$s_{ek}.G_{Enc} \stackrel{?}{=} T_{EK} + EK.c$$
+   $$\implies (ek_r + ek.c).G_{Enc} \stackrel{?}{=} ek_r.G_{Enc} + EK.c$$
+
+#### Binding host and device
+
+**W2 (parallel).** The device's $nonce$ is the same $nonce$ the host uses, so both proofs end up bound to the same context. The two proofs are produced independently and verified independently; nothing flows from one prover to the other during proving.
+
+**W3 (sequential).** The host first runs its pre-challenge phase of the Prover above — picking all blindings and computing all $T$ values on the host side, but dropping the parts that involve $sk$ or $ek$ (so $T_{pk}$ and $T_{EK}$ are not computed and not added to its transcript). It then derives its challenge from that transcript exactly as the W1 challenge $c$ is derived, but with $T_{pk}$ and $T_{EK}$ omitted from the hash; call this challenge $c_H$. The host sends $c_H$ to the device. The device sets its $nonce$ to
+$$nonce' = c_H \| nonce$$
+(concatenation of the byte serialization of $c_H$ and the original $nonce$), runs the Device prover above against $nonce'$ — so its challenge becomes
+$$c = Hash(nonce', AK, EK, T_{AK}, T_{EK}) = Hash((c_H \| nonce), AK, EK, T_{AK}, T_{EK})$$
+— and sends $(T_{AK}, T_{EK}, s_{sk}, s_{ek})$ back to the host. The host appends the device proof bytes to its transcript and derives a fresh challenge
+$$c_H' = Hash(c_H, T_{AK}, T_{EK}, s_{sk}, s_{ek})$$
+which it uses for its own response generation. The verifier mirrors the same ordering: derives $c_H$, reconstructs $nonce' = c_H \| nonce$, verifies the device proof against $nonce'$, then derives $c_H'$ from the device proof bytes and verifies the host's responses against $c_H'$.
+
+
+## Encryption key distribution
 When an asset has a shared encryption key, the asset issuer distributes the corresponding secret key $ek$ to the relevant auditors/mediators using Twisted Elgamal and a key-distribution proof which proves to the chain that issuer has indeed encrypted the secret key for the intended recipients and they can decrypt to get it. The issuer splits $ek$ into chunks $ek_i$ and for each chunk produces:
 - A shared ciphertext: $C_i = G_{Enc}.r_i + H.ek_i$
 - A per-recipient ciphertext: $E_{ji} = EK_j.r_i$ for each recipient $j$ with encryption public key $EK_j$