突破 BTC 10 分钟魔咒： RichSwap 乐观执行+批量结算方案

[biteaglelabs]

作者：比特鹰蛋挞

一、简介

RichSwap 是世界上第一个基于 REE （ Runes Exchange Environment ）的无信任 Runes AMM DEX ，由 Omnity Network 构建。它允许在 Bitcoin Layer 1 上进行快速、无桥接、无托管的原生资产交换，支持 Runes-to-Runes 和 Runes-to-BTC 交易。

REE 是一个 Bitcoin 可编程扩展协议，利用 ICP （ Internet Computer Protocol ）提供去中心化执行层，实现图灵完备智能合约，而不依赖跨链资产。

二、优缺点

亮点

• 支持 Runes 原生交易，无需桥接、包装或托管，相比 Stacks 或 Rootstock 等协议更原生和去中心化。
• 交易速度快（ 5 秒执行），利用 REE 的乐观执行和批量结算，远超 Bitcoin 主网的 15 分钟确认时间。
• 开源代码，促进社区贡献和透明度。
• 与 Xverse 等 Bitcoin 钱包集成，提升用户体验。
• 价值捕获机制，如协议费用捐赠到 $HOPE•YOU•GET•RICH 池，支持代币价值。 相对于其他 BTC 可编程协议（如 Ordinals 或 BRC-20 ），RichSwap 提供真正的 AMM 流动性池和智能合约驱动交易，而非依赖多签名或中心化解决方案。

缺点

• 依赖 ICP 链执行合约，可能引入额外依赖和潜在单点故障，尽管结算在 Bitcoin 上。
• 定期维护中断服务（如安全和性能升级），可能影响用户体验。
• 作为新兴项目，流动性池可能初始较浅，导致滑点较高。
• Bitcoin 网络费用仍是主要成本，尽管优化了交易大小。

三、技术架构

RichSwap 是跑在 ICP 上的一个 Exchange （ canister 智能合约），维护若干 池（ Pool ）；每个池对映比特币上一笔/一组 UTXO （ Runes 为主）。撮合与风控在 ICP 上完成，产出 PSBT v2 ，谁的输入谁签（用户签用户的、池子由 ICP 的 Chain-Key 阈值签名签），合并后广播为原生 BTC L1 交易完成结算。

核心技术包括：

• Exchange （ RichSwap canister ） ：AMM/DEX 业务逻辑，维护多池；每个池绑定到 BTC UTXO （典型为 Runes 资产）。这是 REE 里的标准“Exchange”实现。

• REE Orchestrator （编排器） ：把各协议/池给出的路径与状态“收束”为一份 PSBT v2 ，协调多方签名、复核与广播（ REE 的通用能力，被 RichSwap 复用）。

• DPS （ Decentralized PSBT Signing ） ：去中心化 PSBT 签名机制——把签名流程本身搬到 ICP 上，透明地收集/验证/合并签名。

• Runes/UTXO Indexer：在 ICP 侧读取 BTC 区块 /UTXO 并提供 Runes 元数据给合约做风控、余额与所有权校验。

• Bitcoin L1 （结算层） ：所有交易最终都是原生比特币交易，上链确认后才算落地。

• ICP 底座能力（给上面组件用） ：

  • Canister 智能合约执行/存储；
  • Chain-Key 阈值签名（ tECDSA/tSchnorr ） ：canister 能生成外链原生签名；
  • Bitcoin 集成：提供读取 UTXO / 发送原生 BTC 交易的接口。

四、RichSwap 与 Saturn DEX 对比

RichSwap 和 Saturn DEX 都是新兴的 Bitcoin Layer 1 (L1) Runes AMM (Automated Market Maker) DEX ，旨在实现无桥接、无托管的原生资产交换，支持 Runes-to-Runes 和 Runes-to-BTC 交易。两者均利用扩展协议（如 REE 和 Arch Network ）在 Bitcoin 主网上引入 DeFi 功能，避免侧链或 L2 的复杂性。

（一） RichSwap （ REE/ICP ）

优点

• 跨协议编排强：ICP 合约层能把多步骤交易在业务上捆绑，再以单笔/一组 PSBT 落到 L1 ，适合复杂 BTCFi 组合交易。
• 桥风险低：资产始终留在 BTC L1 ，避免桥的托管/铸造风险。
• 阈值签名运营：平台侧用 Chain-Key （ t-of-n ）管理“池子输入”，便于多签风控/轮换。

缺点

• 执行层外依赖：依赖 ICP 可用性与安全假设（与 Arch 的外执行层本质相同——只是技术路线不同）。
• 生态兼容度：目前重点在 Runes，若要泛化到 Taproot Assets / 其它协议，需额外适配。
• 吞吐：若不采取像 Saturn 那样的“分片账户”设计，理论上仍会受 CPFP 25 未确认限制影响（这是任何基于 CPFP 的 L1 合约式编排都会遇到的上限）。

（二） Saturn （ Arch ）

优点

• L1 透明 AMM：原子交换 + 非托管流动性，完全公开的池子状态；文档明确“非托管且可验证”。
• MEV 防护成体系：签名域选择（ SIGHASH_ALL / SINGLE|ACP + 集体保护）、FIFO ，以及规划的 VDF ，对 mempool 狙击/夹击有针对性设计。
• 扩展性工程化：账户分片+重建状态绕过 25-CPFP 限制；初始 50 分片/池的目标 TPS 估算给出量化边界。
• Runes 预言机：解决“仅凭 tx hex 无法得知每个输出的 Runes 数量”的信息缺口。
• UTXO 管理：额外费 + 定期合并，限制池子 UTXO 膨胀。

缺点

• 操作复杂度：建池需要一次性准备 51 个 UTXO（ 1 个配置 + 50 个分片），对 LP 端“首笔操作”门槛较高。
• 费用模型：为控制 UTXO ，需要额外支付合并费用，长期是否会影响小额交易/做市，需要实测评估。
• 外执行层假设：同样依赖 Arch 网络的可用性/正确性（与 REE/ICP 的外执行层问题对称）。

RichSwap 在速度和扩展性上更具优势，适合追求高效的 DeFi 用户； Saturn 在 MEV 抵抗和状态同步上更稳健，强调 Bitcoin 纯正主义。两者互补，推动 Runes 生态成熟，但均面临 Bitcoin 固有限制（如费用和块时间）。若构建新 BTC 协议，可借鉴 RichSwap 的乐观执行和 Saturn 的分片设计。

维度	RichSwap （ REE/ICP ）	Saturn （ Arch ）
结算层	BTC L1	BTC L1 （原子交换/池子交易）
执行层	ICP （ REE Orchestrator + Chain-Key 阈值签名）	Arch VM + 去中心化验证网络
产品形态	编排型多方交易 +（当前） Runes 交易前端	Uniswap v2 风格 AMM + LP 费收取
扩展/吞吐	取决于编排与打包策略；若无额外设计会受 CPFP 25 限制	账户分片重建规避 25-CPFP ，上限可线性扩容
MEV 防护	（公开资料未见成体系披露）	SIGHASH 组合 + CPFP 集体保护 + FIFO + 规划 VDF
资产识别	Runes 起步，其他协议需适配	Runes 预言机精确识别每 UTXO 的 Runes 数
UTXO 管理	常规 CPFP/打包	额外费 + 加仓合并抑制 UTXO 膨胀

五、未来看点

作为 REE 的展示应用，RichSwap 将支持更多 BTCFi 场景，如借贷、质押和清算。Omnity 计划开放 Exchange 注册给合作伙伴，推动跨协议集成，实现图灵完备合约的更广泛应用（如原子借贷与交换） 目标是构建无桥接的 Bitcoin 原生 DeFi 生态，继承 Bitcoin 安全的同时提升可组合性。