sUDT 和 Anyone-Can-Pay 的合约升级啦
2021-06-23 03:26 | 出处： Nervos
对于开发者来说，他们只需要用新的代码哈希[1]来解析 ACP 短地址[2]，必要时为用户引入一个方便的入口来迁移他们的资产。
Trail of Bits 的审计合作
基于 Docker 智能合约在构建过程依赖于 PATH 中的 moleculec
智能合约使用未更新的 ckb-c-stdlib 依赖项
目前智能合约都是静态链接的，这意味着一个智能合约必须在自己的二进制文件中打包所有的依赖库，一旦智能合约在主网上发布，它所有的依赖库将被固定，我们没有办法在不更新二进制文件的情况下改变这些库。由于这种设计，每个部署的智能合约将被锁定在一个特定版本的 ckb-c-stdlib 库中，即使我们在未来增加了新的功能，我们也不能轻易升级到新版本的 ckb-c-stdlib，二进制的稳定性以及可重复的构建，是 CKB 非常重要的基础。
但这并不意味着我们没有意识到这个问题，我们采取的策略是，我们把特定版本的 ckb-c-stdlib 库作为智能合约的一部分，当库中暴露出一些漏洞时，我们会发布一个安全补丁，并同时更新二进制文件。这样，可以确保即使开发者使用的是较旧的库时，他们仍然可以在链上正常操作。
这个问题的另一个潜在解决方案是 Nervos 基金会正在开发的 CKB 动态链接技术，一旦动态链接技术成熟，我们就可以动态链接 CKB-VM 中的依赖库。这样，当发现库中有漏洞时，我们可以只升级特定的库，而链上的二进制文件可以保持不变。
GCC 从 9.2 版本到 10.2 版本对某些 memcmp 用例进行了错误编译
sbrk 的实现没有在失败时设置 errno
未初始化的变量被读取
未定义 CKB-Only Cells 的行为
在 Anyone-Can-Pay 智能合约中的重复逻辑
mbedtls 库是在非生产环境下构建的
nervosnetwork/riscv-newlib 700 个 commits 过期
我们确实计划将工具链升级到较新版本的 GCC 以及 newlib 库，但这需要时间以及各方面的仔细测试，另外，当旧版本的工具链出现漏洞时，我们将给工具链打上补丁，并将受影响的智能合约也升级到新版本。
在未来升级智能合约
当智能合约首次部署在 CKB 上时，将有一个名为 Type ID 的特殊机制，这样每个智能合约都可以获得一个独特的名字。其中存在一个多签锁，被 Cell 用来控制智能合约，而这个多签锁目前由 CKB 核心团队和 Nervos 基金会组成的系统合约升级委员会来维护。多签的设置是 3/5，也就是说只要 5 个中的 3 个提供签名，智能合约就可以升级。 在使用智能合约时，开发者不应直接使用数据哈希，而应利用 Type ID技术。 当一个漏洞被发现时，智能合约包含的 Cell 可以被委员会解锁，并升级至漏洞修复的新版本，而通过 Type ID[9] 引用智能合约的用户，无需任何手动操作，就可以使用新版本，这样一来漏洞就可以得到顺滑处理。 在一段时间后，当委员会足够有把握认为智能合约安全时， 委员会可以通过 Cell 的多签锁升级为全零锁来最终确定智能合约 ，而这之后没有人能够改变它，这个升级过程可以在未来通过社区治理进一步去中心化，通过用治理锁取代多签锁，智能合约包含的 Cell 只能在某些特定治理结果下被解锁。 此外，如果用户不希望锁被委员会或治理自动升级，他仍然可以选择使用代码哈希的 sUDT 和 ACP lock，而不是哈希 Type，它不会受到任何升级的影响，而且没有人可以改变合约，它将继续使用创建 Cell 时指定的代码，而不是升级后的新代码。