Top Tweets for #Merm

《一文读懂sat20协议对闪电网络核心合约的取舍》 RSMC与HTLC：闪电网络的双核引擎 作为比特币闪电网络（Lightning Network）的核心协议， RSMC（可撤销序列成熟合约）和HTLC（哈希时间锁合约）共同构建了链下支付的信任与效率基础。尽管二者目标一致（实现快速、低成本的微支付），但其技术原理与应用场景存在显著差异。以下从技术机制、功能定位及SAT20协议的设计取舍三方面展开分析。 一、RSMC：支付通道的安全基石 1.1 核心机制 RSMC（Revocable Sequence Maturity Contract）是闪电网络中管理单个支付通道状态的核心协议，其核心逻辑围绕承诺交易与惩罚机制展开： 承诺交易（Commitment Transaction）：通道参与方（Alice与Bob）每次更新通道余额时，需共同签署一份反映最新余额状态的交易。该交易包含两个输出： 即时输出：双方可立即取回的资金（需对方签名）。 延迟输出：需等待时间锁（如144区块）到期后单方可取的资金。 私钥交换：每次更新状态时，双方交换旧的私钥（Revocation Key），用于构造惩罚交易。 惩罚交易（Penalty Transaction）：若一方试图广播过时的承诺交易（如Alice作弊广播对自己有利的旧状态），另一方可使用旧私钥立即没收作弊方的全部通道资金。 1.2 功能定位 状态更新安全：确保通道内的多次链下交易可逆且防篡改。 用户掌控权：用户可随时单方面关闭通道，无需依赖对方合作。 资金效率：通过延迟输出设计，减少链上结算的频率。 1.3 示例流程 Alice与Bob开设通道，各存入0.5 BTC。 Alice向Bob支付0.1 BTC，双方签署新承诺交易（Alice余额0.4 BTC，Bob余额0.6 BTC）。 若Alice试图广播初始状态的承诺交易（双方各0.5 BTC），Bob可通过惩罚交易没收Alice的0.5 BTC。 二、HTLC：跨通道支付的路由协议 2.1 核心机制 HTLC（Hashed Timelock Contract）是支持多跳支付（Multi-hop Payment）的协议，其核心依赖哈希锁与时间锁： 哈希锁（Hashed Lock）：支付方生成随机数R并计算哈希值H=Hash(R)，设定支付条件为“接收方提供R以解锁资金”。 时间锁（Timelock）：设定资金退回的等待时间（如12小时），若超时未解锁，资金自动返回发起方。 路由嵌套：HTLC可跨多个通道串联，形成支付路径（如Alice→Carol→Bob）。 2.2 功能定位 跨节点支付：允许资金通过中间节点路由，无需直接开设通道。 条件支付：支持原子化交换（如闪电网络与原子交换协议结合）。 抗审查性：中间节点仅传递哈希值，无法知晓支付的具体内容。 2.3 示例流程 Alice想通过Carol向Bob支付0.1 BTC。 Alice与Carol建立HTLC，要求Carol在12小时内提供R才能解锁0.1 BTC。 Carol与Bob建立HTLC，同样要求Bob提供R。 Bob提供R获得资金后，Carol使用R从Alice处解锁资金，完成支付。 三、SAT20协议的设计取舍：为何放弃HTLC？ 在SAT20协议的聪网（SatoshiNet）设计中，HTLC被明确放弃，仅保留RSMC作为核心协议。这一选择基于以下考量： 3.1 简化架构，专注资产流动性 目标差异：HTLC的核心是路由支付，而SAT20更关注主网资产在二层网络的自由流通（如Ordinals NFT、BRC20代币）。 复杂性规避：HTLC的多跳逻辑需维护复杂的路由节点与流动性平衡，增加协议实现难度。 3.2 平行网络的替代方案 状态记录替代：聪网通过平行BTC网络记录通道状态变更，取代HTLC的多跳验证需求。 动态通道扩容：采用Splicing技术调整通道容量，减少对跨通道路由的依赖。 3.3 安全与效率权衡 攻击面缩减：HTLC可能面临哈希碰撞攻击或路由劫持，放弃HTLC可降低潜在风险。 主网结算保障：所有资产最终回归比特币主网结算，无需依赖中间节点的可信性。 四、总结：互补与演进 RSMC与HTLC的关系： RSMC确保单个通道的安全，HTLC扩展支付网络的连通性，二者共同构成闪电网络的“安全+路由”双引擎。 SAT20的范式创新： 通过放弃HTLC、强化RSMC与平行网络，SAT20将比特币二层网络的定位从“支付加速器”升级为“资产流通基座”，更贴合聪本位生态的需求。 未来，随着比特币生态的多元化发展，协议设计需在安全性、效率与功能扩展间持续平衡。 SAT20的选择为这一探索提供了重要样本。