DFINITY为何要集成BTC｜IC会成为多链时代的链接枢纽吗
文章来自于｜DfinitySZ
投稿、转载请联系｜DfinitySZ小助手
在这场长达数年的Web3拉力赛中，领跑者不乏少数，但随着参赛者们的不断加入，这场拉力赛也被无限期延长。笔者认为，从客观角度上来看，这种局势也形成了一种僵局，各大公链之间的互通性，仍存在一道难以逾越的鸿沟。姗姗来迟的DFINITY在这场拉力赛中崭露头角的次数并不多，但从其上线后所展示的架构和迭代路线不难看出，DFINITY正在成为这场拉力赛中链接多链的枢纽。
追溯区块链发展起源，2009年第一个基于P2P开源协议构建的去中心化数字货币上线，但基于POW的共识算法运作的BTC网络，达到了绝对的去中心化和安全性，在可扩展性选择牺牲。不具可扩展性和智能合约功能虽然大大限制了BTC的应用场景，但却没有阻挡它数字黄金的价值。
在2021年7月，DFINITY发起了一项整合BTC的提案讨论线程，通过IC的专有密码学技术Chain Key在没有其他任何信任假设的情况下为BTC添加智能合约功能，即使IC上的Canister能够持有、发送和接收真实的BTC，赋予其在应用场景上的想象空间。
注解：Canister是IC上的智能合约，它不仅拥有完整的屠灵完备功能，还拥有智能合约、Actor模型、进程、WASM模块等强大特性。
本文将从DFINITY集成BTC概述原文的底层逻辑出发，与大家一起探讨DFINITY如何能够通过底层技术成为链接多链的枢纽。
摘要
DFINITY的BTC整合方案是在没有其它受信假设情况下，使IC的Canister拥有原生处理真实BTC的交易输入、输出和检索BTC网络区块能力。没有其它受信假设也意味着除了BTC网络和互联网计算机的正确运行外，不能存在像跨链桥这种第三方信任假设。这种集成方案，纵观区块链发展历史上也是前无古人，从这里也不难看出此次集成的难度所在。
DFINITY对BTC的整合方案需要在IC协议栈的每一层的添加相应的组件实现，而能够完成此集成方案也得益于ICP链上的一个”特殊DAO治理系统“NNS，该治理系统以开放且去中心化的方式运作，所有人都通过它达成一个共识目标输出贡献，即任何人都可以向NNS发起对网络战略发展的提案，并以投票形式决定是否采纳。NNS也支持对ICP协议无缝升级，这种方式保障了既不丢失去中心化使命，也为网络提供了更多弹性空间。
集成架构
回到集成方案中，DFINITY集成BTC的方案主要实现三个功能，使IC能够原生处理BTC的交易输入、输出和检索BTC网络区块的能力。这三个功能基于以下特性完成：
Canister可以直接拥有BTC地址；
Canister可以访问控制的UTXO集；
Canister可以安全的签署BTC交易输出；
Canister可以向BTC网络提交BTC交易；
而集成的不信任方面主要依赖于门限ECDSA协议，该协议使子网能够根据Canister请求的秘密共享私钥计算 ECDSA 签名。通过该协议，每个Canister都可以“控制”大量可派生的 ECDSA 密钥并为其获取签名，从而使Canister能够以安全的方式直接在BTC区块链上接收、持有和转移BTC。但Canister必须能够检索与其BTC地址关联的 UTXO，因此，DFINITY构建了一个BTC适配器连接到BTC主网检索区块和中继由Canister发起的交易。
进一步概述
如上图所示，DFINITY在ICP协议的执行层中构建了作为副本一部分实现的虚拟Canister/BTC Canister，它公开了用于查询与请求Canister相关联公钥地址的UTXO集、余额、以及可提交交易的API。通过 get_utxos 和 get_balance 函数可查询任何固定BTC地址的UTXO集和余额，send_transaction 函数用于将BTC交易发送到BTC网络。
BTC Caniste为UTXO集提供服务时需要将BTC区块从BTC网络的节点拉入IC中，摄取区块中的交易输入和输出，并且由BTC Canister维护一组未使用的交易输出 (UTXO)，此类实现需要一个跨IC协议栈所有层的架构，且还包括副本外部的新组件。
BTC Canister维护一组最近的BTC区块（例如，宽度为144个区块的跨度）、BTC网络的UTXO 集以及Canister提交的一组的输出交易的表示。UTXO集和最近的区块用于响应Canister的UTXO 查询。
在副本之外，有一个BTC适配器，它一个沙盒操作系统级进程，它使用BTC的对等发现协议（Bitcoin's peer discovery protocol）随机连接到多个BTC网络节点。BTC适配器同步BTC网络的区块头和区块。此外，BTC适配器还维护BTC网络区块的最新视图，并根据请求向 IC 协议栈提供区块。
在每一轮IC共识轮中，作为共识层核心组件的活跃区块制造者向网络层请求新的BTC区块。网络层负责检索BTC Canister的部分状态，包括BTC Canister维护的最近BTC区块头以及输出交易。这两个项目都用作向BTC适配器发送BTC区块请求的参数。BTC适配器将接收到的区块哈希与其最近的BTC网络视图相匹配，如果它持有一个区块是通过哈希表示区块之一的后继区块，则返回该区块。此外，它还将请求中收到的交易添加到队列中，以便将输出交易异步提交到BTC网络。如果BTC适配器返回一个区块，则由区块制造者将其放入提议的IC区块中。
假设在当前的IC共识轮次中已经提出了一个包含BTC区块的IC块，这个IC区块会像往常一样被gossiped到子网节点，这需要经过共识层的公证和最终确定过程。公证过程针对BTC集成进行了扩展：每个副本会根据预期的哈希值及其时间戳对IC块中包含的BTC区块执行确定性的有效性检查。至关重要的是只有在保证区块将被所有诚实副本成功验证的情况下，区块制造者才可以提议区块，否则子网的共识可能会失败。
一旦具有BTC区块有效负载的IC区块成功被验证，最终确定过程将继续进行，且无需更改。一旦区块最终确定，BTC有效负载需要在消息路由层中提取，发布到相应的子网队列中以执行。当BTC区块到达执行层时，它由执行层的BTC Canister执行：区块被验证，其交易和交易的输入和输出被提取，BTC区块链的UTXO集和网络视图将相应更新。
创建BTC交易需要为每个用作交易输入的UTXO计算一个 ECDSA 签名。Canister可以从作为专用ECDSA签名子网的一部分实施的阈值ECDSA API请求ECDSA 签名。创世将部署一个这样的子网，如果需求增加，未来将可能会提供多个签名子网。图1以简化的方式显示了阈值ECDSA功能，它是支持Btcoin的子网中一部分，而不是位于单独的子网中。使用阈值 ECDSA API 允许Canister请求 ECDSA 签名，该签名由ECDSA子网中的副本/节点 基于秘密共享私钥联合计算。使用BIP-32密钥派生的泛化，使每个Canister都可以访问它控制的无限组阈值ECDSA密钥。
总结
在这场“无限期”的web3.0拉力赛中，领跑者也许会越来越多，但互通性的难以逾越却形成了一坐坐孤立的“江山”。从协同效应上的角度上来看，我们也能够理解DFINITY在整合这条道路上为什么选择了这条截然不同的方式，从底层架构和底层技术出发做到原生兼容其他公链，这种方式的好处不仅体现在强强结合，还满足了优缺互补需求，同时也为未来拓展更多公链奠定基础。
本文仅对整合原文中的部分内容引用，原文中更加详细的描述了整合BTC的细节，对于那些想要更全面了解整合BTC技术开发者来说，可通过下方原文链接阅读，如果您在阅读本文时遇到了问题，可通过下方二维码随时找到我们，我们将全程为您提供支持与帮助。
必看周刊
生态精选
寻宝回顾
精彩活动
联系我们
t.me/DfinitySZ
dfisz.com
twitter.com/DfinitySZ
twitter.com/DfinitySZCN
reddit.com/user/DfinityShenZhen