隐私保护跨链订单簿协议

Privacy-Preserving Cross-Chain Order Book Protocol

技术白皮书 — 协议流程详解

Version 1.0 | 2026

1 概述

Invisibook 是一种面向去中心化交易场景的隐私保护跨链订单簿协议。它解决了当前 DeFi 订单簿模型中交易数额透明化带来的一系列问题，包括前置交易（front-running）、流动性操纵（liquidity manipulation）、及其他 MEV 攻击与交易策略泄露等。

Invisibook 的核心设计理念是：报价公开、数额私密。链上订单簿仅暴露价格信息以供撮合引擎进行匹配，而订单的具体数额则以 Poseidon 哈希承诺（暂定poseidon，后续也可能考虑换成其他的hash，选型的关键是 哪个hash可以 在MPC电路 和 zk证明 性能 综合表现最优）的形式存储在链上，任何第三方无法获知订单的真实大小。当两笔订单被撮合成功后，买卖双方通过链下点对点的隐私结算协议完成交割，整个过程中双方的订单数额始终对外保密。

协议的安全性建立在三大密码学原语之上：Poseidon 哈希函数用于生成高效的算术友好型承诺，**零知识证明(ZK Proof)用于在不泄露私密信息的前提下验证各类约束条件，以及基于 SPDZ 的恶意安全 MPC 结合协作零知识证明(co-ZK)**用于在两方之间执行安全的数值比较并生成可验证的证明，而无需泄露私密输入。

协议整体分为以下四个阶段：

• 阶段一：跨链充值 — 用户将资产从外部链（如 Ethereum、Solana 等 L1/L2）通过对应的跨链桥存入。在 Invisibook 链上，存入的资金以私密 UTXO 票据（Zcash 风格）记录，票据承诺被追加到链上 Merkle 树中，并提交 ZK Proof 证明资金所有权。

• 阶段二：私密挂单 — 用户通过消耗私密 UTXO（通过发布 nullifier）作为抵押来创建订单。报价以明文公开，数额以 Poseidon 承诺隐藏，并附带 ZK Proof 证明所消耗的 UTXO 完全覆盖订单价值。

• 阶段三：链上透明撮合 — 撮合引擎根据明文报价执行价格优先匹配算法，将买卖双方配对。

• 阶段四：链下隐私结算 — 被匹配的订单立即在链上锁定并进入结算流程。双方运行基于 SPDZ 的 MPC 协议，共同生成比较结果的秘密分片和协作零知识证明（co-ZK）的分片。各自将分片上链，链上合成得出比较结果并验证证明后，由小订单方将明文发送给大订单方，完成差额计算、UTXO 创建与状态更新。

图 1：Invisibook 协议总体流程与系统架构

2 符号与基本定义

为保持后续描述的一致性，本节定义协议中使用的核心符号。

Poseidon 承诺的计算方式如下：

C = Poseidon( amt , r )

其中 , 表示拼接操作。Poseidon 是一种针对 ZK 电路高度优化的哈希函数，其在有限域上的算术运算效率远高于 SHA-256 或 Keccak-256，因而被广泛应用于 ZKP 系统中。致盲因子 r 确保了相同的订单数额不会产生相同的承诺值，从而防止链上观察者通过承诺碰撞推断订单信息。

3 阶段一：跨链充值与所有权证明

3.1 流程描述

用户首先在外部源链（Source Chain）上发起一笔跨链转账交易，将原生资产或代币存入 Invisibook 部署在该链上的跨链桥（Bridge）。跨链桥锁定用户资产后，通过跨链消息传递机制（如状态根锚定、中继器网络或轻客户端验证等）将存款信息同步到 Invisibook 链上。源链可以是任意受支持的 L1 或 L2 网络，如 Ethereum、Solana、Arbitrum 等。

在 Invisibook 链上，用户的资金以 Zcash 风格的私密 UTXO 票据存储。每个票据是一个元组 (addr, v, r)，其中 addr 为所有者地址，v 为价值，r 为随机致盲因子。票据承诺 cm = Poseidon(addr, v, r) 被追加到链上的只追加 Merkle 树中。这一设计确保了即使 Merkle 树对所有验证者公开，任何第三方也无法确定任何票据的所有者或价值。

用户在完成充值后，需要在 Invisibook 链上提交一个零知识证明 π_deposit，证明自己确实是源链上该笔存款交易的发起者和资金的合法持有者，且对应的票据承诺已被正确计算并插入到 Merkle 树中。

3.2 代数描述

假设用户 Alice 向跨链桥存入金额 d。系统创建一个新的私密 UTXO 票据 note_new = (addr_Alice, d, r)，其承诺为 cm_new = Poseidon(addr_Alice, d, r)。则需满足：

π_deposit: {

  cm_new = Poseidon(addr_Alice, d, r)

  ∧  deposit_tx ∈ source_chain_tx_root

  ∧  sender(deposit_tx) = addr_Alice

}

其中第一项约束保证了票据承诺的正确形成，第二项约束保证了存款交易确实被源链区块链确认，第三项约束保证了交易发起者与 Invisibook 账户的绑定关系。验证通过后，cm_new 被追加到链上 Merkle 树中。

4 阶段二：私密订单提交

4.1 流程描述

当用户希望在 Invisibook 的订单簿上挂出一笔订单时，需要构造一个私密订单（Private Order）。订单是一个具有以下元组结构的特殊链上对象：

Order = (oid, τ, d, p, cm_q, pk, f)

其中 oid 为唯一订单 ID，τ ∈ {BUY, SELL} 为订单方向，d 为交易对标识，p 为明文报价，cm_q = Poseidon(q, r_q) 为订单数量 q 的承诺，pk 为创建者公钥，f 为明文费用。

创建订单时，用户必须消耗一个或多个私密 UTXO 票据（通过在链上发布其 nullifier），使消耗的票据总价值覆盖 p · q + f。这一机制确保了完全抵押：被消耗的票据作为订单的锁定抵押物。

用户需要生成并提交一个零知识证明 π_order，该证明需满足以下约束：

• 每个被消耗的票据存在于链上 Merkle 树中（Merkle 成员证明）

• 每个 nullifier 正确地从对应票据派生

• 被消耗票据的总价值 ≥ p · q + f（完全抵押）

• 承诺格式正确性：cm_q = Poseidon(q, r_q)

• 数额正值性：q > 0

4.2 代数描述

Order = (oid, τ, d, p, cm_q, pk, f)

其中 τ ∈ {BUY, SELL} 表示订单方向。ZK Proof 的完整陈述如下：

π_order: {

  ∃ q, r_q, {note_i, path_i, nf_i}  s.t.

  ∀i: MerkleVerify(root, cm_i, path_i) = true

  ∧  ∀i: nf_i = DeriveNullifier(note_i)

  ∧  Σ note_i.v ≥ p · q + f

  ∧  cm_q = Poseidon(q, r_q)

  ∧  q > 0

}

此证明确保了用户不可能在没有足够抵押的情况下挂单（被消耗的 UTXO 必须完全覆盖订单价值加费用），同时也不可能提交非法的零数额或负数额订单。由于证明在链上被验证，任何不满足上述约束的订单都将被拒绝。接受后，被消耗票据的 nullifier 记录在链上，防止双重花费。

4.3 安全性分析

通过将数额隐藏在 Poseidon 承诺中，Invisibook 实现了订单数额的隐私性。链上的撮合引擎、验证者、以及其他交易者只能看到订单的价格和方向，无法得知订单的具体数量。这一设计有效抵御了以下攻击向量：

• 前置交易（Front-running）: 攻击者无法通过观察大额订单来抢先交易。

• 流动性操纵(Liquidity Manipulation): 攻击者看到大额市价单时，可能抢先撤除低价位挂单并在更高价位重新挂出，迫使受害者在更差的价格成交。由于数额不可见，攻击者无法判断订单规模，也就无法判断操纵是否有利可图。

• 策略推断: 做市商或竞争对手无法通过订单数量推断用户的交易策略和仓位信息。

5 阶段三：链上订单撮合

5.1 撮合机制

Invisibook 链上的撮合引擎基于**价格优先（Price Priority）**的核心原则运作。由于所有订单的报价均以明文公开，撮合引擎可以正常执行标准的订单匹配逻辑。

具体而言，撮合引擎维护一个标准的双向订单簿：

• **买单簿（Bid Book）：**按价格从高到低排列。

• **卖单簿（Ask Book）：**按价格从低到高排列。

当一个新的买单报价 ≥ 当前最优卖单报价时（或反之），撮合引擎将这两笔订单标记为已匹配（matched），并触发后续的链下结算流程。

5.2 撮合优先级规则

当多笔订单的报价处于可成交区间时，撮合引擎按照以下四级优先级依次排序，确定撮合的先后顺序：

• **第一优先级 — 价格最优（Price Priority）：**买单中报价最高者优先成交，卖单中报价最低者优先成交。这是所有订单簿的基本原则，确保市场的价格发现功能正常运作。

• **第二优先级 — 区块高度最早（Block Height Priority）：**当多笔订单报价相同时，以订单被打包进入的区块高度作为时间排序依据。区块号更低（即更早上链）的订单享有更高的撮合优先级。这一规则保证了先到先得的公平性，避免后来者在相同价格上挤占先行者的成交机会。

• **第三优先级 — 费用最高（Fee Priority）：**若多笔订单报价相同且处于同一区块内（即区块高度相同），则按照订单的明文费用字段 f 从高到低排序。支付更高费用的订单将被优先撮合。这一规则在区块内部提供了一种市场化的排序机制——当用户希望在同一价格水平上获得更高的成交优先级时，可以通过提高订单费用来表达这一意愿。

• **第四优先级 — 区块内交易索引（Index Priority）：**若订单的报价、区块高度和费用均相同，则按照其在区块内的交易索引升序排列。这提供了一个确定性的平局打破机制，确保完全确定的排序。

上述优先级规则可形式化表示为：

Priority(order) = ( price, block_height↑, fee↓, tx_index↑ )

即：首先按价格排序（买单降序、卖单升序），价格相同时按区块高度升序排列（越早越优先），区块高度也相同时按费用降序排列（越高越优先），最后按区块内交易索引升序排列作为确定性平局打破。

严格配对匹配：由于订单数额是隐藏的，撮合引擎无法聚合多个订单。每次匹配严格地将一个买单与一个卖单配对。匹配后，两笔订单立即在链上锁定：它们不能再被取消，并被强制进入结算流程。

5.3 重要设计权衡

由于订单数额是密文形式，撮合引擎在匹配阶段无法知晓两笔被匹配订单的真实数量是否相等。因此，Invisibook 的撮合结果只是一个**「价格匹配」**，而非传统意义上的「完全成交匹配」。真正的数量对比和差额处理需要在阶段四的链下结算中完成。

这一设计是 Invisibook 与传统订单簿撮合引擎最本质的区别：传统引擎在撮合时即可完成精确的数量匹配与部分成交处理，而 Invisibook 将数量相关的计算推迟到了链下隐私结算环节。此外，匹配严格为配对形式（一买一卖），因为链上无法聚合多个隐藏数额的订单。

6 阶段四：链下隐私结算

阶段四是 Invisibook 协议中最复杂也最关键的环节。当撮合引擎将两笔订单配对后，两笔订单立即在链上锁定并进入结算流程。订单的持有者（以下简称 Alice 和 Bob）需要通过链下的点对点隐私协议完成结算。

图 2：阶段四 — 链下隐私结算详细流程

6.1 安全数额比较：恶意安全秘密分片 MPC（SPDZ）

结算的第一步是确定哪一方的订单数额更小。但由于双方的订单数额都是私密的，任何一方都不能直接将自己的数额明文发送给对方（否则在比较阶段即泄露了隐私）。

Invisibook 采用基于 SPDZ 的恶意安全 MPC 协议，在不泄露任何一方输入的前提下完成承诺验证与数值比较。

SPDZ（“Speedz”） 是一种基于加法秘密分片（Additive Secret Sharing）与信息论 MAC（IT-MAC）的恶意安全多方计算框架。在 Invisibook 的结算场景中，Alice 和 Bob 各自持有秘密输入（订单数额 amt 和致盲因子 r），双方运行 SPDZ 协议执行以下逻辑：

1. 承诺验证：在秘密分片下计算 Poseidon(amt_A, r_A) 并验证其等于链上承诺 C_A；同理验证 Poseidon(amt_B, r_B) == C_B。
2. 数值比较：在秘密分片下计算比较结果 b = (amt_A ≤ amt_B)。
3. IT-MAC 恶意安全保证：SPDZ 的 IT-MAC 机制确保任何一方若试图篡改自己的输入或中间计算，都会被另一方检测到，协议将中止（abort）。

协作零知识证明（co-ZK）一体化设计：承诺验证与数值比较被纳入 MPC 协议内部作为一次原子操作执行。双方无需在比较前先各自公开自己的承诺打开（opening）。协议内部直接以秘密分片的方式计算 Poseidon 哈希并与链上承诺比对。此外，MPC 协议共同生成一个协作零知识证明（co-ZK）π_cmp，证明比较结果的正确性——任何一方都无法单独构造该证明，且在过程中双方都不会获知对方的私密输入。

分片输出：MPC 协议产生两类秘密分片：

• 比较结果分片：Alice 得到 share_b_A，Bob 得到 share_b_B，满足 share_b_A + share_b_B ≡ b (mod p)
• 证明分片：Alice 得到 share_π_A，Bob 得到 share_π_B，可在链上合成为完整证明 π_cmp

比较结果和证明均不直接揭示给任何一方。双方各自将比较分片和证明分片提交到链上，由链上逻辑完成合成。

6.1.1 链上分片合成

双方在 MPC 完成后，需在规定区块期限内（10 个区块时间）将各自的分片提交到链上。链上逻辑执行以下操作：

• 合成比较结果：计算 share_b_A + share_b_B mod p，得出 b
• 合成协作证明：组合 share_π_A 和 share_π_B，重构 π_cmp
• 在链上验证 π_cmp，确认比较结果的正确性
• b = 1 表示 amt_A ≤ amt_B（Alice 为小订单方）；b = 0 表示 amt_A > amt_B（Bob 为小订单方）
• 比较结果和证明在链上公开验证后，触发后续结算流程

链上合成确保比较结果的最终确定性不依赖于任何单方，而是通过链上证明验证获得密码学保证。

6.1.2 超时冻结机制

协议区分两种失败场景：

**情况一 — MPC 中止（Abort）：**如果 MPC 协议本身中止（例如因 IT-MAC 检测到作弊、网络故障或任一方在计算过程中离线），不施加惩罚。两笔订单均解锁并返回订单簿等待重新匹配。这是因为中止可能源于合理的网络问题而非故意的不当行为。

**情况二 — 扣留分片：**如果 MPC 成功完成但某一方超过期限（10 个区块时间）未上传分片到链上：

• 拖延方的订单被冻结 72 小时
• 已上传方的订单释放，可重新参与撮合

惩罚方式为冻结而非罚没（slash），因为未提交也可能源于网络故障而非恶意意图。此机制确保双方都有激励及时完成链上分片提交，保证结算流程的活性（liveness）。

6.2 小订单方结算（以 Alice 为例）

假设比较结果为 amt_A <= amt_B，即 Alice 持有较小的订单。此时 Alice 需要执行以下操作：

6.2.1 点对点发送明文

Alice 通过安全的点对点通信，将自己的订单数额明文 amt_A 和对应的 256-bit 随机致盲因子 r_A 发送给 Bob。此时 Bob 可以在本地验证：

Poseidon(amt_A , r_A) == C_A

其中 C_A 是 Alice 之前在链上发布的订单承诺。如果验证通过，Bob 可以确信 Alice 发送的明文数据与链上承诺一致，不存在欺骗。

6.2.2 更新链上状态

Alice 将以下更新提交到链上：

• Alice 的订单在订单簿上标记为销毁（fully filled）

• 创建一个新的私密 UTXO 票据并支付给 Bob（交易对手方），代表 amt_A 的已结算资产转移

• Alice 提供零知识证明 π_A，证明结算的一致性（UTXO 数额与已承诺的订单数量匹配）

此结果由链上分片合成和证明验证确认（见 6.1.1）。

6.3 大订单方结算（以 Bob 为例）

Bob 收到 Alice 发来的 amt_A 和 r_A 后，首先在本地验证承诺的一致性。验证通过后，Bob 在本地计算新的订单剩余数量：

amt_B’ = amt_B - amt_A

随后 Bob 选取一个新的随机致盲因子 r_B’，计算新的订单承诺：

C_B’ = Poseidon(amt_B’ , r_B')

Bob 将以下更新提交到链上：

• Bob 的原始订单在订单簿上标记为销毁

• 创建一个带有更新承诺 C_B’ 的新订单 o_B’（剩余订单继续在订单簿上挂单）

• 创建一个新的私密 UTXO 票据并支付给 Alice（交易对手方），代表 amt_A 的已结算资产转移

• 附上零知识证明 π_B，需同时证明以下三个陈述：

π_B: {

  (1)  amt_B' = amt_B - amt_A  ∧  amt_B' ≥ 0

  (2)  Poseidon(amt_A , r_A) = C_A

  (3)  新 UTXO 的数额与成交数量 amt_A 一致

}

其中第 (1) 项证明了剩余订单数额是旧订单数额减去小订单数额的正确结果，且剩余量非负（确保 Bob 没有篡改计算）。第 (2) 项证明了 Bob 所使用的 amt_A 确实与链上之前已承诺的 Alice 的订单密文 C_A 一致（防止 Bob 伪造小订单数量来获取不正当利益）。第 (3) 项确保支付给交易对手方的新 UTXO 与实际成交量一致。

**数额相等情况：**当 amt_A = amt_B 时，两笔订单均完全成交并标记为销毁。创建两个新的私密 UTXO 票据——分别支付给双方——不存在剩余订单。

6.4 质询

在链上分片合成完成、比较结果已公开确认之后，小订单方需将自己的明文数额 amt 和致盲因子 r 发送给大订单方以完成结算。若小订单方（以 Alice 为例）拒绝发送，则触发以下质询流程：

当超过 5 个区块时间 Alice 仍未发送明文后，Bob 可以向链上发起强制申请，并附带自己的一个公钥 Pub_B，强制要求 Alice 将自己的 amt_A 和 r_A 用 Pub_B 加密 (amt_A, r_A) 并发到链上。当 Alice 看到强制申请之后，需在 10 个区块时间内发送 Pub_B(amt_A, r_A) 到链上，否则 Alice 的该订单将会被直接冻结 72 小时，而 Bob 的订单可以重新与其他加密订单进行撮合。

Bob 在看到链上出现 Pub_B(amt_A, r_A) 之后下载到本地，然后解密，并按照 6.2/6.3 的步骤进行验证和结算。

**裁决（Adjudication）：**如果 Alice 发布的明文数据不正确（即与其链上承诺不匹配），Bob 可以将 Alice 声称的 (amt_A, r_A) 提交到链上。链上逻辑检查 Poseidon(amt_A, r_A) 是否等于 C_A。如果检查失败，Alice 的订单被冻结，Bob 的订单被释放以重新匹配。

7 各阶段证明义务汇总

下表汇总了协议各阶段中涉及的零知识证明及其所证明的核心陈述：

8 安全性质总结

Invisibook 协议在不同层面提供了以下安全保证：

• ← Previous Post