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

PA荐读｜2020-06-09 11:02

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 个月后未发生事故，团队将禁用紧急暂停按钮，也就是保护了这次系统没有受到更多损失的预留「后门」。