配备专用子网，ICP 即将完成与比特币的集成

ICPL

本期概要

DFINITY 基金会这段时间以来一直致力于为互联网计算机实施阈值 ECDSA 方案。去年 DFINITY 的首席研究员 Victor Schup 就向社区介绍了阈值 ECDSA 签名的数学基础，在本文中，Andrea 与 Dieter 继续向社区介绍了更多关于阈值 ECDSA 系统集成方面的介绍。

阈值 ECDSA 系统的集成本质上是处理诸如密钥生成部署和分发之类的事情：

子网如何获得阈值 ECDSA 密钥然后部署
ECDSA 聚合签名的阈值是多少
每个密钥的复制频率
支持 ECDSA 的子网数量
如何在主网上部署阈值 ECDSA 的功能

上图可以看到一个子网，子网由许多副本节点构成，作为提供计算和存储功能的基础。在启用了 ECDSA 的子网中，节点们将持有阈值共享的 ECDSA 密钥，也就是上图的蓝绿色密钥。子网的节点会进行密钥碎片的分发，没有节点拥有完整的密钥，但每个人都拥有密钥的碎片。密钥的碎片没有关于密钥的信息，只有达到算法规定的最小人数，节点们才可以通过处理碎片密钥创建出完整的签名。这个过程中不会有原始密钥被泄漏。

密钥管理的工作原理

ECDSA 子网有一个原始的 ECDSA 密钥，这个密钥可以为每个容器派生出独立的公私钥，我们将其称为主钥、根公钥与容器私钥。现在我们可以进一步适应的 BIP32 派生密钥，以便容器根据需派生出无限数量的密钥。例如，对于比特币集成来说，容器可以获取它的公钥与派生密钥，也可以从 ECDSA 子网下派生一个密钥来请求签名，并且只有控制密钥的容器才可以请求签名。

当前所有这些通信都跨子网工作的，因为正如我们所说，所有用户容器都在其他子网上。

ECDSA 专用子网

DFINITY 计划推出一个专用子网来实现阈值 ECDSA 签名功能。除了安全考虑，这个专用子网会隔离开用户的容器。原因在于，虽然阈值 ECDSA 签名的执行是独立在底层运行，但依然存在沙盒逃逸攻击等方面的风险，所以不应该在该专用子网上存在用户的容器。因此这一阶段下容器还无法直接使用 ECDSA 签名，IC 网络将作为一个整体进行 ECDSA 签名，容器通过该子网的服务间接地调用 BTC 网络。

这个专用子网应该具备和 NNS 子网一样的安全级别，网络的节点应为不低于 34个，并且在去中心化方面也应该类似于 NNS，从不同的供应商、地理分布和数据中心里选择节点。

在更好的验证了安全性后，DFINITY 计划启动更多的 ECDSA 专用子网，并在这些子网上允许用户容器的部署。这些容器将可以直接使用底层构造符合 ECDSA 规则的签名，从而作为服务直接与 BTC 网络乃至 ETH 网络交互。

ECDSA 备份子网

在比特币或以太坊直接集成的背景下，ECDSA 密钥将控制大量资产，因此我们应该变得更加谨慎。ECDSA 子网被破坏的这种低概率事件也应该被评估，为了避免出现灾难性错误，我们需要一个备份子网。

例如，可以切换备份子网接受来自其他应用子网的 API 请求。同时，我们可以恢复损坏的子网或使用密钥分发协议建立一个新的子网，这样在 IC 上将拥有至少两份密钥的副本。

网络部署流程

我们使用三个不同的 NNS 提案来做到这一点。

提案1 让 NNS 子网为一个新子网 A 分发密钥。这会获得一个新的 ECDSA 密钥，这里就叫做“Secp256k1_key1”，Secp256k1 表示密钥所遵循的加密曲线，key1 是密钥标识符。子网 A 的节点间将运行去中心化密钥分发协议，这样就分发了密钥碎片，子网 A 现在拥有了一个阈值的 ECDSA 密钥。

提案 2 再创建一个子网 B 作为子网 A 的备份子网，通过密钥重分发，将密钥秘密地从子网 A 分发给子网 B 的节点。这样就实现了安全的备份。

提案 3 会启用子网，允许子网响应请求发送 ECDSA 签名。完成此操作后，任何子网上的用户容器都可以发送请求来检索其公钥，或使用私钥请求产出具有特定派生路径的签名。

目前进度

基金会将在几周后，也就是 6月下旬实现 Beta 测试子网，这个测试子网下包含了全部与 Bitcoin 网络集成的功能，用户可以直接从 IC 主网上调用相关 API。测试子网只会有 13 个节点，主要是为了方便开发和测试，帮助开发者进行适配。基金会将在某个时候删测试密钥。

正式版子网将在 Beta 测试后一两个月后上线。正式版子网会在测试的基础上进一步提升性能，其节点数量不会低于 34 个，具备和 NNS 一致的高安全性。NNS 子网将作为密钥备份子网，而正式版子网用法发送 ECDSA 签名。正式版子网中也会部署对应的 ckBTC 账本容器，用于承载比特币。

小助手微信号

入群请添加

联系我们