来自｜社区会议
翻译｜DfinitySZ
投稿、转载联系｜DfinitySZ小助手
近期集成比特币开发者社区展开了一场围绕技术问题解答、应用场景、集成测试和实现该功能所需考虑进一步要求的研讨会议，本期带各位小伙伴回顾此次会议。
比特币开发者社区研讨会2021 年 11 月 4 日14:00-16:00 CET 通过 Zoom
技术回顾
阈值 ECDSA(t-ECDSA) 密钥管理？
- t-ECDSA 主密钥管理的最终决定仍有待考虑。
- 现在明确的是，单个子网上的所有容器都从该子网上的主密钥中派生出它们的密钥。
- 我们正在考虑安全性和性能之间的权衡。
- 当在多个子网部署同一主密钥时，主密钥的安全性将是该密钥部署所在子网提供的安全性中最小的。这意味着我们需要使用足够安全的子网来托管特定的主密钥。
- 当前策略是在多个子网上部署一个主密钥以确保有一个备份。
可以签署和发送任意比特币交易吗？例如，不使用 t-ECDSA 进行签名？
是的，我们不限制可提交的交易。例如，您可以提交由其他人（例如用户）签名的交易，而不必通过带有 t-ECDSA 密钥的容器提交。
t-ECDSA 是否与比特币功能分离？
是的，它是完全分离的：t-ECDSA是作为一个单独的功能构建的，它提供了一个 API，比特币智能合约容器使用它来获取公钥和签名交易。使用 t-ECDSA 的 API 是比特币和 t-ECDSA 功能之间的整体集成。此外所有容器也可以将 t-ECDSA 签名功能用于比特币以外的任何用途。
哪些比特币 API 调用是（a）同步的？
- 根据目前的计划（暂定）所有 APl 调用都是异步的，但这不是严格要求的。有些APl 可以作为同步调用。
- 注意：在此设置中的异步调用非常快，因为比特币功能与调用容器是部署在同一子网上。
在 get_UTXO_set APl 中是否考虑了比特币最终确定性？
- 是的，您在我们 API 返回的比特币地址UTXO 集中获得作为UTXO元数据的确认计数。
- 对于我们计划构建的程序库，比特币的最终确定性可能会被进一步抽象化，因此您不需要自己处理单个 UTXO 的确认计数，而只需指定您想要的 UTXO 最小确认计数。
允许容器进行 http 调用的功能的状态是什么？
这在我们的路线图上也很重要，最终会完成该计划，但目前我们的重点是比特币集成计划。
在容器持有lCP之前，可以先持有比特币吗？
- 不，在它们持有比特币之前，将能够先持有 ICP。
- 目前正在积极开展有关容器上持有ICP的计划。我们将在 2022 年第一季度看到 IC DeFi 的V0。
互联网计算机和比特币网络之间的中继工作是如何实现的？是否有一组我们连接到的比特币节点？
- 这是由我们的 IC 节点以尽可能去中心化的方式实现：启用比特币功能的 IC 子网中每个节点都连接到整个比特币网络中的一组随机节点（从整个比特币网络中随机发现要连接的节点）。
- 这种方法允许以高度分散的方式将交易快速传播到比特币网络中的许多节点。
用例
一位论坛成员咨询我们是否需要为AMM项目封装比特币。如果没有封装比特币，需要等待比特币网络上的确认时间， 而这段确认时间太长。他假设几乎所有用例仍然需要某种形式的封装比特币，因为它们的终结时间很短。基金会是否涵盖了这种封装比特币的功能，或者社区是否希望这样做？
- 社区同意我们需要以某种形式将比特币封装在 IC 上。
- 我们（基金会）已将其列入了比特币集成计划第二阶段的议程，但如果社区能在这里提供帮助，我们也很高兴。
- 通过比特币集成（第一阶段），每个人都可构建一个封装好的比特币容器。
- 实现封装比特币的技术选择：
- Token：当用户将比特币转移到容器中时，它会铸造封装好的比特币令牌返回用户。
- Ledger：用户可以将比特币转移到Ledger容器。当有人进行转账时，容器会在Ledger中跟踪转账。我们正在构建一个开源的账本容器，可以作为实现账本选项的基础，因此实现这个选项应该不会有太多的工作。
- 我们的结论是，如果在 IC 上对封装比特币有巨大的需求，那么基金会出于信任等因素，响应该需求会更加合理。
- 社区已经创建了ICP的封装版本来摆脱账户ID的范式，因此他们可以采用以principal id 为中心的方法，这对于他们的一些用例来说可能是需要的。如果基金会在账户 id 方案中实现封装比特币功能，那么有可能会出现其他封装版本，这背后的驱动因素都可能是想采用Proncipal id，即出于与封装 lCP 相同的原因，这是上述 AMM 项目所必需的。
当在容器中本身就持有比特币时，如何访问用户的账户余额？可以使用哪些APl？由此产生的余额是否与您在任何区块浏览器中看到的余额相同？
- 可以使用程序库中的get_balance 方法或get_UTXO_set 系统 的 APl 为任何比特币地址调用获取相应的余额或UTXO 集。
- 通过此种方式获取的余额与您在比特币区块链浏览器上看到的余额完全匹配。（我们使用比特币区块来提取的交易与基于其计算余额的 UTXO ，因此它与区块链浏览器中的视图完全相同）。
如何将比特币地址链接到Principal ID？
- 您可以将比特币发送到比特币智能合约，并根据收到的资金铸造代币到比特币发送者的Principal ID。
- 这个功能可以很容易地在一个容器中实现。
容器如何验证比特币来自特定用户？
- 选项 1：给每个用户使用 BIP-32 密钥推导创建的自己的比特币地址，如果在特定地址上收到转账，可以假设它来自于与该比特币地址相关的 Principal ID。
- 选项2：或者，如果我们只想使用一个地址：我们可以使用比特币操作码对比特币交易中的相关信息进行编码。
时间线是如何安排的？
- 原计划是在2021年底发布。
- 对 t-ECDSA 的依赖将导致 ECDSA 集成发布的延迟，因为 t-ECDSA 将进入明年的第一季度。更多请参见下文，也有可能在没有 t-ECDSA 的情况下提供部分功能，以便在 t-ECDSA 准备好之前就能够促进智能合约的开发。
开发使用比特币功能容器的测试讨论： 智能合约开发人员如何在本地环境中测试其容器代码？例如，确保正确的比特币交易正在发生？
- 基金会在功能开发过程中遇到了类似的挑战，他们正在考虑如何将使用过的想法转移到容器开发中，并尝试提供一些为他们自己的测试而构建的工具，以便开发人员可以在部署之前测试他们的代码。这是一个仍有待进一步探索的领域。
- 我们能够允许与比特币测试网进行交互，以帮助社区测试运行他们的容器，而无需在比特币主网上进行交易（提供在比特币主网和测试网之间进行选择的切换）。
- 然而：获得比特币测试网代币是很棘手的，或许运行离线比特币测试网络是一种更好的方法。
- 离线集成将是有利的：例如，使用本地运行的模拟比特币网络。这与比特币测试网相比可能更容易实现且对开发人员更有用。在没有网络连接的情况下启用“海滩开发”。
比特币功能的开发者预览：我们可以在ECDSA还没有最终确定的情况下发布比特币功能（ECDSA的最终确定可以尽早促进智能合约的开发）。
- 在我们完成 t-ECDSA 之前将会推出一些供开发人员使用，这使得很多用户感到兴奋，这些用户可能会针对比特币 API 开始实施他们的智能合约容器。这将与我们为本地测试提供的其他工具齐头并进。
- N.B.：IC 没有测试网，因为在IC上计算所需的Cycles并不昂贵。
来自社区的一位参与者提到，有些项目可能不想使用跨链桥进行比特币集成，而我们直接原生集成比特币非常适合，我们发现连接到此类项目将是一个好主意。
有一个用例提到跨境支付，例如对于当地货币不是很稳定地区的商家。当人们想要持有比特币而不是本地货币时，此类集成对于这种情况是很有意义的。
- 其中一个关键是让一个容器由一群人而不是一个地址来控制：将一个容器作为一个单独的实体，由多个用户共同拥有。容器上的比特币属于那些不同的用户，并会根据定义的规则以编程方式发布。
- 这是可以在 IC 上很容易实现的事情。
比特币团队与即将进行以太坊集成的团队是同一个吗？
- 可能与该团队有较大重叠，但尚未定义。
- 我们现在已经在考虑以太坊，同时比特币的工程工作也正在进行中。
IC 上的 EVM / Solidity 支持
IC 上的 EVM / Solidity 支持
- 社区成员表达了对其强烈的感想，即不仅对于与以太坊相关的项目，甚至是对比特币相关项目，EVM 兼容性都体现出其重要性。
- 项目通常在 Solidity 中开发智能合约，而用不同的语言重新实现它们并在合理的时间范围内获得流动性是不可行的。因此通过此类项目获得流动性，与 EVM / Solidity 兼容的能力是很重要的。
- 在互联网计算机上发布此类 EVM/Solidity 兼容性以及本机集成是至关重要的。IC 将成为多数以太坊和比特币或用 Solidity 编写用例的最佳第 2 层解决方案。
- 既然社区愿意帮助实施，那么，是什么阻止了我们的社区帮助我们提供此功能？
- 了解原生以太坊集成将如何工作才能最大程度确保此 EVM 环境与其无缝结合地工作达到完美。
- 4 GB 的容器堆限制可能是一个问题，这取决于 EVM 实现的可能性多大，以及与任意正在运行的合约的状态相结合
- 拥有更稳定的内存是远远不够的，我们还需要 64 位堆寻址。
其他区块链为 EVM 兼容性采取的一些方法：
- NEAR：https://aurora.dev/about
- Solana：https://github.com/hyperledger-labs/solang
IC 上可能实现的方法
- 在 IC 上使用 EVM 兼容运行时：这会导致同步执行的问题，因为 Wasm运行时是以消息为基础的，但合约调用是同步的。
- 将 Solidity 合约编译到 WebAssembly 并将它们部署到 IC上：这需要实现相应的并发模型，以便在异步 IC 上实现 Solidity 的同步语义。
下一步
- 我们需要组织一个关于这个主题的社区研讨会
- 我们将在人与人之间协调如何保持 EVM 集成讨论的进行，例如在论坛上。
BIP-32密钥派生
BIP-32密钥派生
- 容器根密钥是使用BIP-32密钥推导的索引0派生的；
- Canister 可以使用其他索引来派生出任意数量的公钥；
- 我们使用的所有派生都是未硬化的密钥派生。
使用 BIP-32 密钥派生而不使用独立密钥对的动机是什么？
- 维护一个阈值私钥成本较高。因每个独立的私钥都是在子网的节点副本之间秘密共享的，且每隔几分钟重新共享一次以提高安全性。持有尽可能少的独立密钥是一个早期的决定。
- 密钥派生解决了密钥少的问题。
- 能够对密钥进行容错的需求也增加了成本。
- 由于这些原因我们无论如何都是需要密钥派生。
公钥地址的可链接性
- 这对匿名性有一些安全隐患：对地址的针对性攻击，我们知道子网和子网的节点运营商。
- 为了对抗这种类型的攻击，t-ECDSA将运行在拥有节点数最多且最强大的子网上。
如果子网中有太多比特币，我们可以将其分片吗？
- 这无关紧要：如果比特币子网的节点数与 NNS 网络的节点数相同，那就好办了。
- 我们可以从更多独立节点供应商处添加更多节点，以提高安全性。
其他人也使用 BIP-32 来派生密钥，这里没有问题。
从钱包的角度来看，人们期待 BIP-32 密钥的派生，所以这是我们正在做的事情。
IC上的多重签名钱包，一些提到的基本想法：
- IC 上的阈值签名将是一个很酷的功能。
- 不要认为我们需要Taproot，但可以将其抽象化。
- 可以为具有 EVM 集成的多链进行多重签名。
- 需要更多思考。
下一步
- 组织跟进。
- 在论坛中继续讨论EVM，无论是比特币还是新话题
- 开发讨论：https://forum.dfinity.org/
DfinitySZ聚焦于IC生态
专业｜深入｜全面
前沿资讯｜技术研究｜生态平台｜全面支持
