今年 IC 即将完成和 BTC 的集成，AstroX 作为长期关注 IC 生态发展进度的项目，Research 团队近期整理了大量与此功能相关的资料，部分资料来自 Dfinity 官方论坛和官方提供的资料。希望以独立研究分析报告的方式为对区块链技术和发展形势感兴趣的朋友们深度解读该功能。我们将分几篇系列文章阐述所有分析和开发细节。

Internet Computer (IC) 是由 2016 年创立的 Definity Foundation 开发建设的 Layer 1 公链，IC 于 2021 年 Q2 发布主网上线，其代表代币为 ICP 和 Cycles（燃烧 ICP 生成的代币用来支付，与 1 SDR 锚定，算法稳定币）。IC 的主要优势是建立在其密码学和工程学领先技术上的快速异构处理，较低的 Gas 费用以及隐私安全的转账和存储。IC 生态致力于为加密世界提供用户体验感更好的服务解决方案，更安全快速的转账，更易用便于存储的应用层 Dapp，为非加密世界用户和行业进入加密世界铺平道路。

Big News

这篇报告主要整理了开发者社区关于集成 BTC 功能讨论的一些问题，目录如下：

01 IC 与 BTC 跨链集成功能简述

02 关于 IC 与 BTC 集成功能，开发者讨论的技术问题

        和其他加密货币的集成和转账

        包装 BTC

        BTC Gas Fee 计算 及 ZkBTC Canister

        机制层面

        安全问题——外部女巫攻击

        存储和运行性能

        开发者预览版中提供 BTC API 涵盖的功能范围

        开发编程语言及其 library

03 结语

IC 将通过专有的密码学技术 Chain Key 和 Threshold ECDSA 加密技术应用，直接完成与 BTC 的跨链集成，IC 生态可以为 BTC 添加智能合约。通过 IC 子网节点复制 BTC 链状态并共享 Threshold ECDSA 私钥完成联合签名以及系统组件验证区块和传送检索 UTXO，IC 上的智能合约将能够持有、发送和接收原生的比特币，智能合约不需要自己揭露私钥，无需中间件如桥合约，极有效地提升了安全性。

集成方案：

1. 桥接已经存在于以太坊中的 ERC-20 币：弱信任模型，因为依赖桥，但很快就可以使用(例如，通过 Terabethia 桥)

2. 桥接个人硬币:信任桥，社区可以做到

3. 基于中继的集成:通过基于中继的集成集成加密货币，其中依赖外部操作的中继主要是为了可用性。使用阈值 ECDSA 确保了仍然相当强的信任模型，因为没有一方持有转账加密货币的签名密钥;这将不需要对 IC 合约栈进行扩展，可以由社区完成

4. 直接集成:像比特币一样集成，最强信任模型，只能由基金会来做，可以重用比特币实现参数化每个货币，并在给定的子网上启用它

直接集成的情况下，智能合约可以直接持有比特币，因为它们可以拥有自己的阈值 ECDSA 私钥，该私钥在一个大子网的副本之间秘密共享。因此，直接集成具有比基于桥的解决方案更强的信任模型。

与以太坊的集成将允许将以太坊的 ERC-20 代币带入互联网计算机。然而，以太坊上的 ERC-20 代币是封装的比特币类加密货币代币，它们都被桥接到以太坊，也就是说，需要额外对桥信任。原生集成可以在没有那些额外的信任假设的情况下运行，更加安全。此外，使用直接集成将 ERC-20 代币从以太坊转移到 IC 将承担以太坊 Gas Fee 成本，这将通过直接集成其他加密货币来避免。

使用包装版本而不是原生版本的唯一风险是持有令牌的储存罐中的潜在漏洞或 NNS 决定关闭储存罐的远程可能性。这与以太坊上的 WBTC 形成了鲜明的对比，在以太坊上，制造新代币所需的私钥由一个集中的托管人持有，即 BitGo。

包装 BTC 创建 wBTC 的需求是因为 BTC 上的确认时间比较长。BTC 包装罐是自治的，wBTC 仍是去中心化的，会使用到比如 SNS 技术并确保可以使用代币治理。

问题 1: 包装容器的工作机制

用户将比特币转移到指定的包装比特币容器 canister 的地址。一旦收到比特币网络的交易，canister 就为用户 principal 输入收到的余额。wBTC 在 IC 上被铸造时，它们被记录在 canister 里的 ledger 上。用户可以通过指示 canister 相应地更新 ledger，将包装好的比特币转移给其他用户。

这个 canister 容纳了一个与发行的 wBTC 数量相同的真实比特币池，所以就有 1:1 的支持，就像以太坊的包装比特币一样。

问题 2: Canister 操作机制

用户不仅可以通过存入真实的比特币来获得包装好的比特币，还可以用 ICP 支付包装好的比特币，从而拥有一个完全去中心化和不需信任的 ICP/wBTC 交易所。使用 ICP 支付比特币时，发行的 wBTC 需要有 canister 中可用的真实 BTC 的流动性池作担保，以达到 1:1 的担保。

每一个用户可以自己指定地址或者转账到包装比特币的 canister 指定的一个 BTC 地址，使用 BIP-32 派生密钥为资金转移到的每个用户主体派生一个密钥，这使得关联 Principal 和转账变得重要。每个用户都可以将资产转移到相同的地址的 canister 和使用比特币操作码编码的主体交易。

问题 3: 操作流程

用户调用比特币网络将他们的比特币转移到包装比特币容器。

Wrapped Bitcoin Canister 使用 BTC 系统组件的 API 来了解发送到比特币地址的 utxo。一旦收到 UTXO，Wrapped Bitcoin Canister 通过在其 ledger 中做一个相应的条目发行 wBTC，用户在 IC 上获得 wBTC。交易的终端性：每笔比特币交易或可以将 BTC 或 ETH 通过本地集成一次转移到 IC，然后将其包装在 IC 上，并使用包装好的 BTC 或 ETH 令牌在 IC 上实现 2 秒交易终端性。

Exchange Canister 是一个去中心化的交易所(DEX)，wBTC 的一个应用。DEX 可以使用不同的技术来实现，例如，订单簿 Ledger 或自动做市商 AMM。用户调用 Exchange Canister 将 wBTC 转换为 ICP，将 wBTC 转移到 Exchange Canister。从本质上讲，我们需要交易所提供的货币配对的流动性(这里只要求 ICP/BTC)，以履行对货币配对的订单，并拥有一个流动性市场。

问题 1: Ethereum Gas Station 分三档分别是 safe low、 standard 和 fast，IC 上 BTC 交易的 Gas Fee 怎么计算和设置？

挑战在于大多数钱包依赖于内存池的状态(当内存池大小较小时，费用通常较低)，费用是通过测量特定费用的交易在内存池中停留的时间来估计的(使用某种回归模型，上面提到的以太坊也是如此)。

IC 不能使用这种方法，因为没有任何关于比特币容器中内存池的信息。相反，我们计划仅依靠最近区块的观察费用，并以一下 API 的形式提供这些事实信息:

get_current_fees(step_size: u64) -> currentfeerresponse

其中 currentfeerresponse 将包含在最近 10,000 个事务(通常大约 4 个块)中以 Satoshi/byte 为单位的百分比。

例如，步长为 10 的响应将包含第 10、20、……、100 百分位。如果步长是 25，响应将包含第 25、第 50、第 75 和第 100 百分位。开发人员可以自行选择适合他们的应用程序的费用水平。

实验表明，这种(简单的)机制产生了当前费用的一个很好的近似。有两种方法可以获得三个 Gas Fee 费用选项：首先，您可以使用第 25(慢)、第 50(标准)和第 75(快)百分位。在数字上，当考虑到块 724881 及其前身时，这将是 1.9 中本聪 / 字节(慢)，3.2 中本聪 / 字节(标准)，和 5.3 中本聪 / 字节(快)。

问题 2: IC 上 BTC 交易的 Gas Fee 怎么支付？

Canister 需要先有一定量的 ETH 和 BTC 来准备支付 Gas Fee，建议准备一种方法用 cycles 支付 Gas Fee。一旦 HTTP 调用功能准备好，可以构建一个 canister，与此类收费计算器或 mempool 直接交互，以提供与任何比特币钱包相同的估计费用。

问题 3: 怎么考虑建设 ZkBTC Canister 的计划?

考虑到直接与原生 BTC 交互可能会带来比较贵的 Gas Fee，IC 官方开发了 ZkBTC 罐，以便 IC 生态用户以较低 Gas Fee 完成 BTC 转账。

问题 1: 考虑到比特币和以太坊没有 ChianKey，没有桥，比特币 / 以太坊→IC 的交互如何安全地发生？

IC 的区块副本 replicas 会直接和 BTC 的区块交互，验证正确并且在确认足够数量的认证后通过交易。安全性仅仅取决于 BTC 和 IC 网络的运行安全。独特之处是，canisters 会得到一个共享的 ECDCA key (sharing the key using threshold cryptography) ，所以 canister 可以自己安全地存放持有 BTC。比特币(和以太坊)状态主要用于跟踪持有比特币(和以太坊)的每个容器的当前余额。每一个副本 replica 能有一个比特币适配器 Adapter，验证 UTXO。

问题 2: 每个副本是否从创世以来处理每个块?

IC 的目标是不要使用常规机制吸收所有的块，因为这会给子网带来太多的负载并且需要很长时间。IC 可能会在外部将 UTXO 设置为一个定义的块进行预处理，并将这个预处理集的规范化版本的散列编码到 BTC 系统组件中，然后，将集合输入到组件中，组件就可以安全而高效地验证散列和引导的正确性。

在 Internet Computer 的执行层实现了一个 BTC 系统组件，该组件提供以下 API 来查询与请求 canister 的公钥相关的 UTXO 集，并分别向比特币网络提交交易:

get_utxo_set()函数返回与给定的 canister_id 相对应的 UTXO 集，其中 num_confirations 指定 UTXO 必须具有的最小确认数。如果确认次数为 k，则该交易有 k-1 个后续比特币区块。

put_transaction()请求将给定的交易提交给比特币网络。该响应指示 BTC 系统组件是否收到了交易，然后该交易将异步传输到比特币网络。

IC 将提供一个库，为开发人员提供以下函数:

get_balance (num_confirmations) - > BtcBalance 该函数返回给定确认次数的比特币储存罐余额。

send_bitcoin(金额，收件人)-> BtcSystemResponse 该函数将指定的比特币数量发送到提供的接收地址。

问题 1: IC 的子网因为会不断的刷新 public key 并且可以用新的 key 替换老的 key 以及 2/3 比率保证，所以是安全的。但 BTC 和 ETH 可以改动上链的内容吗？如果 1/3 的 IC 节点下线了，怎么办？有没有可能在 IC 子网刷新的时候，发生女巫攻击，因为最远的节点可能还没收到 Key 改动的版本，尤其是考虑到比如 ETH 上多签这种复杂情况。

问题 2: 在一个副本里不同的 canisters 都按相同的 OS 等级过程执行，会产生安全问题：如何保护持有高额资产的 canister 不作恶比如防止因为作恶导致 WASM 环境被破坏等？推荐做 sandbox。

现在的计划里有这部分，会考虑 sandbox code 比如解析比特币区块来减少风险，对 canister 可以做 sandboxing feature 来区别 canisters。

一旦锁定在比特币 DeFi 中的总价值(一旦集成完成)开始变得重要，可以想象，当 TVL 显著大于牺牲总节点中的 2/3 的成本时，就会有一个潜在的巨大动机去攻击那个子网。随着 TVL 的增加，子网将成为一个更有利可图的目标。因此，IC 必须设计缓解机制来保护自己避免成为公开攻击的目标。

现实中会存在多个攻击因子。一种是来自外部的攻击，而非来自节点操作符本身。这可以通过利用 canister 环境中的安全缺陷，通过部署带有漏洞的 canister 来实现。我们正在通过安全审计和罐装过程 sandbox 来防止这种情况。另一种类型的攻击是通过网络，因为节点暴露在 Internet 上。要插入这个矢量，我们必须确保节点硬件、软件、配置和数据中心以及所有与设置有关的东西都准备好了，防止被攻破。在这种情况下，攻击者将需要控制 1/3 + 1 个节点才能打破共识，开始引起问题。即便如此，阈值私钥也是安全的。攻击者需要侵入 2/3 的节点才能真正获得密钥共享或获得共识。子网的设计是为了通过多个因素包括节点运营商、数据中心和管辖权等最大限度地分散节点。

除非每个节点都有一些常见的致命安全漏洞，否则很难从外部攻击大型子网。IC 可以通过优秀的安全实践、代码审查、安全审计等等来缓解这些问题。

IC 不同于比特币或以太坊。攻击者不能直接通过购买获得攻击(可以通过积累大量的投票权来通过 NNS)。因此，在某种程度上，安全问题与工作量证明有很大不同。最关心的是节点操作者之间的勾结。由于它们目前都是公开的，子网配置基本上是静态的，节点操作者有足够的机会相互了解，并形成关系，最终可能导致叛变。

因此，建议实施以下缓解措施:

1. 可信执行环境，它将对节点操作者隐藏容器的代码和状态。TEE 存在的主要漏洞是侧通道攻击。

2. Multi-party Computation，与 TEE 相结合，提供了对容器的代码和状态隐私的 BFT 保障。这将大大减少侧通道攻击。因为攻击者需要 1/3 + 1 个节点操作符来执行侧通道攻击，然后一起执行 MPC 自动节点旋转 / 变换，这将破坏节点操作者串连的机会。因为子网分配是随机的，一旦 IC 拥有更多的节点操作者，节点操作者之间形成关系并针对确定的容器或公钥私钥对将变得非常困难。

上述的缓解措施结合起来提供了很好的安全性，这几种缓解措施都在 IC 试探性的路线图上。

现在 Stable memory 容量是 8G，主要用 Rust，扩大的难点在于新的数据结构和状态格式自动化、透明的迁移。

问题 1: 社区有些开发者认为扩大 heap size 比较有用，stable memory 不靠谱，强调永久正交性 Orthogonal persistence 存在的重要性。

一个稳定的 Rust 数据结构 StableBTreeMap，它允许比特币 utxo 存储在稳定内存中，并让数据结构透明地管理稳定内存。由于序列化，Stable variables 仍然面临 canister8GB 的限制，直接将内容存储在稳定内存中的数据结构能够充分利用完整的 300GB 内存。简单的稳定变量意味着用户需要手动进行所有稳定内存管理。稳定数据结构抽象了稳定内存的管理。

作为副本的一部分实现，完整的 UTXO 集存储在 BTC Canister 中。IC 使用新的 StableBTreeMap 直接将 UTXO 集存储在稳定内存中。因为它是作为副本的一部分实现的，所以内存的使用没有限制，IC 保存副本的所有复制状态可以使用稳定内存而非堆栈 heap，它不计入 heap size。

当我们使用 Wasm32 时，罐堆是 32 位的，因此限制为 4GB。稳定内存寻址已经升级到 64 位，这意味着理论上我们可以从一个容器寻址所有复制状态。实际上，IC 目前对每个容器的稳定内存有 8GB 的限制，但这是人为的，可以提高。限制的原因是一开始要保守，然后随着时间的推移取消部分限制，可能在某个时候完全取消，需要进一步的测试等，以充分保证在每个容器分配大的稳定内存时一切正常。现在每个子网的复制状态已经达到了 350GB，这是随着 IC 协议栈的改进而增长的。

问题 2: 如果我们有 64 位 Wasm 堆在未来的某个时间,开发人员仍然希望操作稳定的数据结构还是放置一切到堆栈 Heap 里并且只在系统环境要升级时移动进出到内存(例如,使用稳定的记忆只是为了升级)?

开发者希望有稳定的数据结构，但同时希望其周期成本不会太高，开发速度快。

问题 3: 与 BTC 集成，复制链上状态会影响子网承接能力吗？

子网会保存，但自己不与区块交互，所以不会受很大的影响。

问题 4: 为什么比特币罐只限制 UTXO/ 余额数据?其他数据是否因为内存限制而不存储在容器中?未来有没有计划提供更多的数据，比如过去的交易?我认为这将大大提高比特币整合的效用。

第一个版本的目标是只拥有 UTXO，未来将所有事务存储在一个子网中是有用的。根据数据表示的效率，这将消耗一个子网的所有存储。IC 不希望推出的第一个版本有如此巨大的存储需求。

主要目标

        让开发者试用，促进了社区成员的智能合约开发

        获取社区对最终版本 API 的反馈

这个版本没有使用最终的集成架构，而是采用了以下简化的方式(这与本地环境和预期目标无关):

1. 目前，API 将以本地运行的常规 canister(BTC canister)的形式公开，而不是作为系统 API

2. 在 regtest 模式中使用比特币而不是比特币主网或测试网(这对最低级别的开发 / 测试阶段是有意义的)

3. IC 堆栈集成是通过进程消息和查询实现的快捷方式，完整的 IC 堆栈集成正在和 Consensus 并行完成，并将在 Q1 版本中发布

4. 用户使用脚本启动比特币适配器、集成 shim、bitcoind 和 BTC canister

5. 在这个发布版本中还没有阈值 ECDSA 技术

IC 将提供分别在 Rust 和 Motoko 中使用该功能的样本 Dapps。

以下内容不在范围内，在此版本中也不可用:

阈值 ECDSA(在这个版本中，人们现在需要使用容器中的 ECDSA 库来签署交易)

比特币测试网与比特币主网整合

方便用户使用的对界面进行抽象的 library

通过 Consensus 实现完整的 IC 堆栈集成

为 Rust 和 Motoko 提供一个图书馆。Rust 更容易，可以在大量开源库的基础上进行构建。Motoko 更具挑战性，需要自己执行一些巨大的逻辑块。因此考虑向社区寻求 Motoko library 的帮助。

library 需要的一些事物如下:

1. SHA-512：有 SHA-256 实现可以作为基础

2. RIPEMD-160(用于地址计算)

3. secp256k1 曲线上的椭圆曲线标量乘法(用于 BIP-32 密钥推导派生)

4. 比特币地址派生

5. BIP-32 非强化推导函数

6. 提供基于系统 API 的高级 API

其中一些项目是根据公钥计算比特币地址和 BIP-32 密钥派生所必需的。主要的问题是 Motoko 目前没有 FFI 来重写来自不同语言实现的逻辑。

在 RTS 中为所有罐子嵌入额外的库(C 或 Rust)是相对直接的，例如已经在 bignum 算术中做过的尝试。这是一个快捷方式，但它实际上无法伸缩，因为库集仍然会由编译器修复。

允许库的作者包含这样的代码是一个一直被回避的难题：语法是什么？类型系统如何交互？我们希望它有多安全？如何解决多语言构建的工程问题？另外，为了实现一些目标，我们必须等待新的 Wasm 特性(多内存)的出现。

通过梳理开发者的提问，我们能发现，首先 IC 生态的开发者水平不错并且非常活跃，IC 与 BTC 集成的功能开发的成功基于他们不断的开发努力，考虑并解决了很多技术问题包括从机制、性能、安全、存储、代币转账和开发语言 library，同时确保了架构的安全性、转账实际的费用成本和机制的性能问题。希望这篇汇总文章能解决一些 IC 生态中开发工程师和技术爱好者的疑问。

AstroX Network 是建立在 IC 生态中的 DID 身份管理和跨链钱包项目，得到 Dfinity 生态的大力支持，旗下多个开发者工具产品收获了多次生态基金奖励。

AstroX 致力于通过身份管理和跨链钱包产品，为加密世界用户和准备进入加密世界的用户提供能与 Web2 产品相似的用户体验，确保用户的身份钱包管理，无需 Seed Phrase，保障用户跨链转账交易的高效、隐私和安全，通过自动的代码程序将所有管理权、使用权和所有权等权利交还给用户，提供真正的、更透明公开的去中心化服务。与此同时，通过 Principal ID 加密，AstroX 在用户使用各个钱包的时候能更好地保护用户的隐私。

近期，AstroX Network 参与了 Supernova Hackthon 并有两个项目 Proof of Personhood（AI+ 区块链，真人识别）和 FoxIC（让 IC 能连接使用 Metamask）都得到了不错的名次和奖项，相关的社区奖励活动也在持续发布中，欢迎大家来玩。

✦

END

✦