Create Shield CSV若干问题.md

Shield CSV若干问题.md

@@ -0,0 +1,87 @@
+ ## 1. Shielded CSV中nullifier 公钥是如何工作的？
+
+我通过一个简单的例子来解释 **Shielded CSV** 中 **nullifier 公钥** 和其他机制是如何区分不同的币并防止重复花费的。
+
+### 场景
+假设有两个用户，Alice 和 Bob。Alice 有一个账户，里面有 5 个币。她想发送 2 个币给 Bob。在 Shielded CSV 中，这个交易涉及到以下几个步骤：
+
+### 1. **初始账户**
+- **Alice 的账户** 目前包含 5 个币，这些币在她的账户状态中记录。账户状态包括：
+  - **账户 ID**: Alice 的账户唯一标识（公钥）。
+  - **余额**: 5 个币。
+  - **花费累加器**: 一个数据结构，跟踪 Alice 已经花费过的币（目前是空的，因为 Alice 还没有花费任何币）。
+  - **nullifier 公钥**: Alice 账户当前的 nullifier 公钥，用于在链上发布交易时的认证。
+
+### 2. **Alice 准备交易**
+Alice 准备发送 2 个币给 Bob。为了创建这个交易，她需要更新账户状态，并生成交易的证明。
+
+1. **选择花费的币**: Alice 从她的账户中挑选出 2 个币进行花费。
+
+2. **更新花费累加器**: Alice 把这 2 个币加入她的账户的 **花费累加器**，表示这些币已经被花费，不能再用。
+
+3. **生成新的账户状态**:
+   - Alice 创建一个新的账户状态，保持原来的 **账户 ID** 和更新后的 **余额**（5 - 2 = 3 个币）。
+   - 她生成一个新的 **nullifier 公钥**，并使用这个公钥来生成一个 **nullifier**，表示这次交易。
+
+4. **生成交易承诺**: Alice 对这次交易生成一个 **交易承诺**，这个承诺包括了交易的具体细节（比如花费的币、接收者的信息等），但这些信息是加密的，只能由相应的接收者（Bob）解锁。
+
+5. **Schnorr 签名**: 为了保证交易的安全性和唯一性，Alice 使用她的 **nullifier 私钥** 对交易进行了 Schnorr 签名。这个签名证明她是交易的合法发起人。
+
+### 3. **发布交易和 nullifier**
+Alice 将生成的 **nullifier** 和交易的承诺一起发送给一个 **publisher**（发布者）。这个发布者会收集多个用户的交易，并将它们一起发布到区块链上。
+
+- **nullifier 公钥**：这个 nullifier 由 Alice 生成，它表示 Alice 在这次交易中花费的币。这个 nullifier 会被记录在区块链上，任何人都可以看到它。
+- **交易承诺**：交易的具体细节被隐藏在承诺中，只有 Bob（接收者）能够解密这些信息。
+
+### 4. **验证过程**
+现在，Bob 收到了 Alice 发送的 2 个币，他想验证这个交易是否合法。
+
+1. **验证账户状态更新**：Bob 首先检查 Alice 的账户状态是否正确更新。Bob 会查看 Alice 的旧账户状态，并确认 Alice 的新账户状态是否遵循了规则（如余额减少，花费累加器更新等）。
+
+2. **验证 nullifier**：Bob 检查区块链上的 **nullifier**。如果 Alice 试图双重花费这 2 个币，区块链上已经存在的 **nullifier** 会与当前的交易发生冲突。因为每个 nullifier 是基于 Alice 的交易签名生成的，如果 Alice 尝试使用相同的币进行第二次交易，验证器会检测到 nullifier 的重复，并拒绝交易。
+
+3. **验证 Schnorr 签名**：Bob 确认 Alice 的 Schnorr 签名是有效的，这证明 Alice 确实是这笔交易的合法发起人。
+
+### 5. **交易完成**
+Bob 验证了所有步骤后，接受了 2 个币，这些币现在属于他的账户。他也生成了自己的 **nullifier 公钥**，并通过类似的过程保护他的账户和未来交易。
+
+---
+
+### 总结
+通过使用 **nullifier 公钥** 代替单纯的 **Coin ID**，Shielded CSV 实现了更高的隐私和安全性：
+
+- **防止双重花费**：每个 nullifier 只会对应一次合法的交易。如果尝试双花，相同的币会生成相同的 nullifier，验证器能够检测并拒绝第二笔交易。
+- **隐私保护**：通过加密承诺，交易细节（如币的数量、接收者等）对外是不可见的，只有相关方可以查看。
+- **签名保障**：通过 Schnorr 签名，只有拥有账户私钥的人才能进行合法交易，防止他人冒用。
+
+这种机制既保证了隐私性，又确保了每个币的唯一性和不可重复使用。
+
+## 2. 在Shield CSV中接受者是如何验证发送者历史状态信息的？
+
+在 Shielded CSV 协议中，Bob 实际上是无法直接检查 Alice 的旧账户状态的，因为旧账户状态对于其他用户来说是加密和私密的。这种设计是为了保护用户隐私。**但是，Bob 可以通过验证 Alice 的交易证明（coin proof）来间接确认 Alice 的旧账户状态是否有效和正确。**
+
+### 更详细的解释
+
+**1. 账户状态隐私保护**
+- Alice 的旧账户状态不会公开在区块链上，区块链只包含 Alice 发布的 **nullifier** 和 **交易承诺**。因此，Bob 无法直接访问和检查 Alice 的旧账户状态。
+- 然而，Shielded CSV 中的交易需要提交一个交易证明（coin proof），这个证明包含了 Alice 更新账户状态时的所有必要信息，但这些信息是通过零知识证明（如 zk-SNARKs）等加密技术隐匿的。
+
+**2. 零知识证明（zk-SNARKs）**
+- Alice 在创建交易时，生成了一个 **零知识证明**，这个证明能在不透露旧账户状态具体细节的前提下，证明：
+  - Alice 的旧账户状态是有效的。
+  - 旧账户的 **nullifier** 确实已正确发布，并且与对应的交易相匹配。
+  - 账户余额的更新是正确的，即 Alice 花费了她账户中的 2 个币，剩余的 3 个币保持在她的新账户中。
+
+- **Bob 检查 coin proof**：Bob 通过验证 Alice 提供的零知识证明，确认交易是有效的，即 Alice 的账户状态正确更新，且没有任何双重花费行为。这个验证过程是在链上进行的，并不需要直接查看 Alice 的账户细节。
+
+**3. nullifier 的作用**
+- Alice 的旧账户状态通过发布 **nullifier** 来标识。Bob 通过在区块链上检查 Alice 的 **nullifier**，可以确认 Alice 的账户中那些币已经被花费。Bob 也可以确保没有重复的 nullifier 存在（防止双重花费）。
+- **nullifier 的验证**：Bob 通过区块链上查询 **nullifier 累加器**，来检查 Alice 的 nullifier 是否已经发布。如果 Alice 尝试使用同一组币进行多次交易（即双重花费），区块链上只会接受第一个 nullifier，后续的 nullifier 将无法通过验证。
+
+**4. 新账户状态的验证**
+- Bob 通过验证 Alice 提供的 **零知识证明** 和交易的 Schnorr 签名，可以确保：
+  - 新账户状态是合法的，并遵循了协议中的规则。
+  - Alice 的旧账户状态已经被成功 nullify（即确认她已经正确花费了这些币），且她没有进行双重花费。
+
+### 总结
+Bob 无法直接访问 Alice 的旧账户状态，但通过验证 Alice 提供的 **交易证明（coin proof）** 和 **nullifier**，Bob 可以间接确认 Alice 的旧账户状态是否被正确更新，并确保交易的合法性。这种机制通过零知识证明保护用户隐私，同时保证交易的安全性和准确性。