如何用去中心化的方式把比特币引入以太坊：读懂 tBTC 资产跨链方案与漏洞补救-链嗅网

撰文：潘致雄，链闻研究总监

以去中心化实现 比特币资产跨链 的方案中， tBTC 是近期最受瞩目的项目。当 BTC 可以安全且无需信任地迁移到以太坊网络之后，相当于 BTC 能享受到图灵完备的 智能合约 ，想象空间更大。比如，这样一来，比特币资产可以应用在 去中心化金融 （DeFi）生态中——毕竟比特币拥有最多的用户、最高的市值、最显著的网络效应。

tBTC 是由 Thesis 公司旗下 Keep Network 开发的一个子项目，这甚至有点像是他们「不务正业」推出的实验项目。原本 Keep Network 是一个为以太坊提供 隐私层 的方案，利用链下的容器存放隐私数据；而 tBTC 则是一个比特币跨链方案，听起来好像与 Keep 本身的方向毫无关联。不过，两者还是存在一些交集的，比如利用了相同的代币 KEEP 和 多签名机制 等。

另外 Summa 和 Cross-Chain Group 也是 tBTC 项目的参与方。按照介绍，这些合作方是这样分工的：

Keep 将 ECDSA 门限签名 运用在比特币去中心化托管的逻辑中，且 tBTC 的原生代币使用的是 KEEP；
Summa 专注 跨链解决方案 ，也就是 tBTC 协议中负责如何在以太坊区块链中验证比特币交易的部分（SPV 方案）；
Cross-Chain Group 则负责 跨链技术 的研究、设计和实施。

Keep 的投资者包括了数家美国的主流机构，如 Polychain Capital、a16z、Draper Associates、Fabric Ventures、Distributed Capital Partners 等。其中 a16z 还是多家 DeFi 协议的投资者，包括稳定币协议 Maker、借贷协议 Compound、交易协议 dYdX 等，这三家也是目前 DeFi 协议中的头部项目 ，如果他们后续能集成 tBTC，或许是一个双赢的策略：比特币可以支持 DeFi，DeFi 可以使用比特币。

目前集成 tBTC 的项目

在 tBTC 之前，加密资产的跨链、尤其是比特币资产的跨链方案，绝大多数都是通过 中心化机构托管 方式实现的，比如 WBTC、imBTC 或 HBTC。虽然这些方案也考虑到了安全性和透明度，但对于加密货币社区而言，人们更想要一个完全去中心化、非托管、无准入门槛、无需许可的资产跨链基础设施。毕竟，资产从一个地方挪到另一个地方是一个很基础的权利，不应该牵扯到其他因素、不应该增加额外风险、也不应该牺牲隐私。

虽然 tBTC 已完成审计并 上线主网 ，但项目仍处于早期阶段，仍有很多未知风险等待早期用户探索。而且 tBTC 的整套机制也存在一些争议，比如 引入了预言机 这个外部不可控的因素。此外，tBTC 网络的参与者的质押率较高资金效率较低，这也会带来参与者的参与动机较弱。不过 tBTC 项目还是有机会对这些现有的问题进行优化和调整的。

总体而言，tBTC 的两个最重要的优势为：

由 原资产 抵押：由于 tBTC 通过 质押比特币 而跨链生成的等价 TBTC 代币，所以不会产生额外的比特币。相反的，像 Synthetix 这类资产合成协议，是通过其他代币铸造出「模拟」比特币价值的代币 sBTC，事实上增加了比特币的流通量。
由 去中心化协议 托管：在 tBTC 协议内的比特币资产是被去中心化的协议托管的，而且也设置了一系列的安全机制确保整个流程 无法作恶 。

从上述两个角度来看，目前与 tBTC 类似的项目可以这么分类：

tBTC 是如何运作的？

像稳定币协议 Maker 为了维持价格所设计的各种机制一样，tBTC 在整套方案中也考虑到了各种可能会对 系统安全 带来的特殊情况，如果将这些模块一一拿出解释或辅以案例说明，可能是一篇论文的长度，或不亚于白皮书。

毕竟对于大多数 tBTC 系统或者是 TBTC 代币的使用者而言，并不需要接触到这么多繁杂的逻辑。只有对于系统的深度参与者或者原生代币的交易者而言，才应该彻底了解整个系统的运作机制，就算很费时间也需要仔细读一读他们的白皮书。

不过，在此之前，也可以将本文作为了解 tBTC 的入门手册，以快速建立起对 tBTC 协议的概念和系统运作的 核心工作流程 。简而言之，这里主要解答的是这个问题： 为什么 tBTC 可以安全且去中心化地进行资产跨链？

先做一些说明和解释：

tBTC 是这个项目和协议的名称，而 TBTC 是由比特币跨链后在以太坊上流通的代币名，也就是 TBTC = BTC。
在 tBTC 的方案中，涉及到这几方：

存款人 （depositor）：希望把 BTC 挪到以太坊上的用户；
验证人 / 签署人 （signer）：维护 tBTC 网络安全且能赚取收益的用户；
赎回者 （redeemer）：希望把以太坊上的 TBTC 换成真正 BTC 的用户。

BTC -> TBTC 铸造流程

对于比特币与以太坊的资产跨链解决方案，两个主要的挑战是：

用户如何确保抵押的资产 不会被盗 ：tBTC 选择的方案是将资产保存在由 3 人共同保管的 多签名地址 中（由 Keep 实现的技术），没有任何一个人可以挪动资产，且需要抵押超额资产。
如何在以太坊的链上 确认比特币的交易和所有权 ：tBTC 采用了由 Summa 设计的 SPV （简单支付验证）技术实现跨链的交易验证。

所以，从 BTC 换成 TBTC 的流程分为两大步骤：

1. 存款人 申请资产跨链 ，在 tBTC 协议的分配下由验证人辅助负责资产托管，然后存款人将比特币转至由三个人 共同托管的 比特币地址中。

2. 转账至 比特币托管地址的 6 个区块后，存款人向协议提交已完成转账的证明，然后就可以铸造相应数量的 TBTC 了。

简单介绍一下 TDT：tBTC 系统为了记录不同存款人不同的托管数量或者时间，在铸造 TBTC 之前还会发行一枚非同质化代币（NFT），称为 TDT （tBTC Deposit Token）。虽说叫代币，但其实类似于一张「凭证」，不可分割且独一无二，后续赎回 BTC 需要用到这张凭证。

当然，在协议的设计中还需要考虑其他可能的问题以及相应的处理方式，最常见的是如果 ETH 价值相比 BTC 价值贬值后，可能会产生验证人抵押不足的情况，导致验证人就有动机作恶了，所以 tBTC 设计了相应的 清算模块 以应对。

tBTC 协议包含了 预清算 和 强制清算 两个阶段，和其他的清算系统的设计目标类似，在强制清算阶段将会启动 拍卖流程 ，将 ETH 以折扣价拍卖给 TBTC 的持有者以保证抵押品 ETH 价值大于 TBTC （也就是 BTC）的价值。而如果清算后还有剩余资金，则根据不同的情况进行收益分配。

BTC -> TBTC 赎回流程

赎回流程相比较而言简单一些，当用户希望将持有的 TBTC 换回 BTC 时，只需将 TBTC 以及一小笔「费用」提交给以太坊的智能合约，同时附上收款的比特币地址，三位验证人就必须共同签署一笔比特币链上交易，将 BTC 转至规定的地址。如果有验证人不配合呢？那抵押的 ETH 就只能被清算了。

也正因为验证人提供了联合的托管业务，并付出了 ETH 抵押资产，所以赎回者需要支付一小笔额外的费用给他们作为 经济激励 。

所以作为验证人，可以将 tBTC 系统作为一种收益稳定的资产管理工具。据白皮书计算，验证人的年化收益约为 1.875%，考虑到 150% 的抵押率，真实的年化收益约为 1.25% 。这是让社区中不少人吐槽 tBTC 的地方：很多人认为目前设定的收益率较低，可能会导致验证人的参与动机不足。当然，这也就意味着目前参数设定，对于存款人和赎回者更友好一些。

KEEP 代币：付出劳动才能获得回报

在 tBTC 的系统里，原生代币 KEEP 是一种工作型代币，这也就意味着持有 KEEP 不能带来任何收益，但是在持有 KEEP 的同时又 付出劳动 ，才能因此获得收益。

回顾一下铸造 TBTC 的环节，在「步骤 2」中，tBTC 系统需要从包含一群验证人的池子中抽取其中的三个，是以什么作为依据抽取的？没错，就是按照 KEEP 代币持有量 作为依据的。举个例子，持有 1000 枚 KEEP 的人是持有 100 枚 KEEP 的人被抽中概率的十倍，也就是如果放在一个很长的时间跨度中，前者干活的数量是后者的十倍。

持有更多 KEEP 意味着验证人可以更多的 参与托管 BTC ，也就有机会获得更多的潜在收益。

上线两天就被发现的 Bug，怎么回事？

在 tBTC 上线的两天后，官方发现了一个协议的严重问题，于是按下了之前预留的全局开关，将整个系统的充值功能暂停 10 天。
在此之前需要先介绍一个背景知识，比特币在 10 多年的发展过程中，随着技术的演进诞生了 多种地址类型 ，由不同类型的脚本生成：

最初的比特币地址以「 1 开头 」，这类脚本称为 P2PKH （Pay to Public Key Hash）；
后来诞生了由「 3 开头 」的地址，这类脚本称为 P2SH （Pay to Script Hash），功能比较强大， 支持多签 以及可以和后来的隔离见证组合；
最后诞生的是 原生隔离见证 地址，由「 bc1 开头 」，这类脚本称为 P2WPKH （Pay To Witness Public Key Hash），也会被称为 Bech32。

最初 tBTC 在协议设计时，限定并强制要求赎回的地址必须是 P2WPKH （bc1 开头）。但是到了今年 2 月，tBTC 的工程负责人提交了一个变更， 放松了这个限制 ，也就是支持了 P2WPKH 之外的脚本（1 或 3 开头）。

这个调整可以提升用户体验，赎回者可以以任意地址赎回，毕竟 Bech32 的普及程度并不高。据 txstats 的数据显示，目前储存在 Bech32 中的 BTC 数量约 3%。但 tBTC 的系统却没有因为增加支持其他脚本而做相应的调整。

不过这样也不一定会产生问题，软件开发中设置的测试流程，就是为了及早发现这样的问题，但他们表示，测试用例中竟然 没有覆盖到「非 P2WPKH」脚本 。虽然后来在测试网中总算测试了 P2SH 地址（3 开头），但是又由于赎回 DApp 流程中的前端漏洞，导致团队误认为该测试通过了。

问题未被发现的一整个流程为：

tBTC 协议设计中仅支持 P2WPKH 地址—> 临时决定放松对 P2WPKH 限制—> 但系统未做相应调整—> 测试用例未覆盖—> 其他功能漏洞导致误认为测试通过了

这些问题堆积在一起，导致了 tBTC 带着漏洞上线主网。

后续如何改进？

在该事件的回顾报告中，tBTC 项目表示将优化他们工作流程，还将与安全团队 Trail of Bits 合作，为 tBTC 规划更多的 自动化集成测试 和系统测试。

随后，为了进一步减少项目的整体风险，tBTC 重新定义了他们的软件发布流程。原来上线主网的 tBTC「正式版」将回退至「 发布候选版 」（Release candidates），版本号为 RC0，所以下一个版本是 RC1。

补充一下，软件开发流程中，在发布某个正式版之前，通常会先发布数个版本称之为「发布候选版」（Release candidates），如果未发现任何漏洞，最后一个 Release candidates （RC）就会成为最终的正式版，比如比特币的下一个大版本 0.20.0 就已经发布了两个 RC 版本。

tBTC 认为，另外一个可以有效降低项目风险的机制是 限制整个系统的容量 。也就是他们限制了 BTC 可以换成 TBTC 的最大数量，这样就算出现严重问题，损失的也就是可控范围内的比特币或以太坊。

具体来说，在 RC1 版本中，第一个月的系统容量被设定为 100 BTC ，之后按月增加，分别是 250 BTC、750 BTC、1000 BTC，这些逻辑也都是 按照智能合约预设的执行 即可。5 个月后，该限制将自动解除，而且如果 12 个月后未发生事故，团队将禁用紧急暂停按钮，也就是保护了这次系统没有受到更多损失的预留「后门」。