Original postLessons Learned from the Babylon Protocol Upgrade: A Retrospective” published by Awa Sun Yin from Cryptium Labs on 30th Oct, 2019 at Medium

原文于由Cryptium Labs的Awa Sun Yin于2019年10月30日发表于Medium
转载请注明出处及添加原文链接

Nomadic LabsCryptium Labs共同开发的第二个Tezos协议修订版 — 巴比伦(又称005协议)已在655361区块上成功激活。之后,我们一方面对新功能进行持续分析与监控,另一方面也从协议的开发阶段、预注入阶段一直到激活后的阶段对升级流程进行了更深入的反思。

本文总结了五个阶段的经验教训:巴比伦开发阶段、提案阶段、链上测试期间的持续测试阶段、激活阶段和激活后的阶段。对于每个阶段,我们都将找出过去几个月中出现的失误,为当前和以后的的核心开发人员提供经验教训,以改进未来协议升级流程。

巴比伦的发展历程有许多开创性的历史。这是两个独立的核心开发团队首次就一项提案进行合作,也意味着实现核心开发去中心化的一次重大进步。此外,巴比伦功能众多,相对于雅典协议是一次巨大的飞跃。雅典协议证明了实时升级的有效性,而巴比伦协议则表明,为了实现有实质意义的改进,代码库中的大部分内容都可以进行修改。

太长了,不想读:少一些仓促,多一些测试,多一些文档,多一些社区参与。

Blues of Babylon
巴比伦的忧郁:来自《每日艺术》杂志的《伊什塔尔之门》

巴比伦的开发阶段

问题:控制变更集与时间线

巴比伦开发过程中出现的一个问题是:尽管事先商定了一系列功能,但开发过程中还是进行了增添。一方面是因为来自雅典协议的一些积压工作,另一方面是因为我们收到了大家对某些功能的要求,而我们不希望把这些要求再拖上三个月。此外,我们还要竭尽全力去遵守明确的注入时间表,因为我们担心开发周期因为不断产生的新变化而被一直拖延下去。

在固定的时间轴上实现一个不断变化的目标极大增加了内部开发的复杂度,并使发布的最后阶段变得十分仓促,从而影响了测试以及与社区的沟通。

如何改进

在将来的升级中,我们会尽早编撰功能列表并广泛收集来自生态系统的建议。我们将把开发限制在特定的功能上,以使我们更清晰的制定可能的时间轴;如果有必要,该时间轴还可被延迟直到我们完成所有应有的检查、测试和沟通。

巴比伦提案阶段

首个提案(巴比伦 PsBABY5n)于2019年7月26日被注入。此后不久,我们在同一提案期内提出了新的更新版本(巴比伦PsBABY5H)。

问题:背书的二进制格式

第二次注入是对来自钱包开发人员反馈的回应,这促使我们恢复了对背书的二进制格式的更改。管理者交易的二进制格式被保留了下来,以确保不能从005执行来自004的用户交易。

提案阶段的确构想过可能会有一系列提案、反提案和迭代出现。

然而,这种额外注入意味着更多的链下协调。如果在首个提案之前我们收集了受二进制操作格式影响的开发人员的反馈,就能够避免这种情况发生。

如何改进

我们可以从三个方面进行改进:

  1. 在注入之前,确保二进制格式文件记录完整对于Tezos代码库中使用的任何编码,协议的所有二进制格式都可以使用新的二进制tezos-codec获取。我们还在开发一种新工具,以解析并显示特定操作的二进制格式。通过提案引入的任何重大变更都会在每次发布的更新日志中进行强调。并且,每次的发布都有关于如何处理迁移的具体指导。我们将继续提高本文档的质量和可访问性,并确保在提案前几周对第三方开发人员开放。
  2. 允许开发人员在注入之前进行完全地测试使用简单的bash沙盒通常足以与Tezos节点和客户端进行交互,并可以快速进行手动测试。另外,可以使用代码库中存在的两个框架FlextesaPython测试框架其中之一来自动化许多更复杂的端对端测试。这些框架供核心开发人员使用,意味着它们可以在将来被维护;并且有许多现有的测试可以为第三方开发人员提供启发。我们相信,通过使用所提供的工具,可以在开发过程的早期无需通过测试链而独立地检测到任何未来操作中的不兼容。但是,这些工具可能尚未向第三方开发者进行足够的推广。我们将努力更好地文档化它们并鼓励大家积极使用与反馈。
  3. 在注入之前发布代码和更新日志对于巴比伦,我们发布了这些功能的描述以及我们逐步构建出的实现链接,例如法定人数限额使隐性帐户可委托。然而,对于雅典和巴比伦,更新日志和最终代码仅在提案被注入的同时发布。在未来,我们将确保在发布与注入之间留出几周时间,以为最后的更改备有充足的时间。

巴比伦的探索与测试阶段

问题:Big Maps与热修复补丁问题

在巴比伦PsBABY5H的测试期间,我们发现了一个影响big maps的错误。更多详细信息请参阅文档记录。该错误特别难以发现,因为它是一个大补丁中的单列,并且它没有破坏任何功能而仅仅是导致性能下降。

尽管存在上述情况,我们相信通过更严格的审查程序与更多的自动化测试,能够在将来避免这种情况发生。

针对这种情况,正常的做法是在升级投票中投反对票,并提出巴比伦补丁版本PsBabyM1。然而,这将导致投票程序的完成被推迟3个月。

考虑到智能合约开发人员对多种big maps(以及入口)的强烈要求,我们感到部分社区成员对该功能需求的紧迫性。

因此,我们决定增加下载Tezos节点新版本的选项,以应对巴比伦PsBABY5H投票能够通过而激活修补版本PsBabyM1的情况,相关博客文章中已有所表述。

增加这种选项并没有引导的意思,而只是作为社区成员的附加选项。大多数节点都同意此选项,因而PsBabyM1被成功激活。

我们一直认为用户激活更新是用于紧急和重要热修复补丁治理过程中的正当部分,就如同我们在过去所做那样以及“工作修正”博客文章中所述。

从积极的方面来说,此热修复补丁可以解锁big maps提供的许多新机会。我们正为智能合约作者们准备有关该主题的博客文章。

如何改进

目前有这几个问题:

为了更快地对提案的多个改进版本进行迭代,我们讨论了几种方法以缩短出现反对票时的投票进程时间。

此热修复补丁还使我们对用户激活的更新机制进行了反思。由于当前实施中的技术限制,只能通过发布新的二进制或重新编译代码来引入用户激活更新,此过程可使得非开发人员退出。我们正在实施一个用户可以无需依赖主网发布,而在配置文件中可轻松设置用户激活更新的节点。

至于big map本身,可以在开发过程中通过更全面的测试和更严格的审核要求来监测此类错误。随着负责协议开发的人员数量增加,每个合并请求的审阅数量也会相应增加。

另外,在注入之前,能够有更多的开发人员活跃在测试网上是非常有帮助的。实现这一目标的一种方法是研究如何通过奖励鼓励大家参与。还有一种已经实施的方法是,始终让一个测试网运行当前正在投票的提案。

巴比伦激活阶段

问题:激活时内存池故障

巴比伦在刚刚被激活后,由于某些节点受到阻塞,导致网络中的区块生成速度减缓。这些节点已被正确迁移到巴比伦,但依然能够接收雅典协议的操作指令;由于它们不再能够反序列化,从而导致内存池和节点故障。

幸运的是,通过简单地重新启动节点从而消除旧操作即可解决这个问题。然而在一个小时之内,这些操作仍能够通过网络传播,导致对节点的多次重启。在我们意识到问题所在的几分钟后,便准备好了修复内存池的补丁,从而使烘焙师们迅速更新了他们的节点。

内存池的故障是由一个已知​​的错误引起的,该错误已在Tezos代码库的主分支上进行修复,但被错误地转移到了主网分支上。

如何改进

这种错误可通过使用我们目前正在实施的、更简单的发布过程避免,该发布过程将在下一个版本发布之前就位。目的是将从主开发分支开始发布主网所需的步骤减到最小。这将简化测试,并减少出现错误的概率。

以后,我们会在注入之前运行测试网,以模拟状态机从旧状态到新状态的迁移。这种情况意味着把正在004上运行的测试网升级到005上运行,同时通过随机发送交易来产生负载。这种测试网能够监测到之前的错误。

巴比伦被激活后阶段

问题:区块奖励公式

在巴比伦被激活后,用户意识到奖励的计算与博客中所描述的改进共识算法Emmy +的公式略有不同。

造成这种差异的原因是公式实现中存在错误从而导致计算烘焙奖励时的精度下降。

这种精度的损失不会影响到Emmy+ 的安全性,且能够在接下来的协议升级中被修复。

如何改进

此类错误能够比较容易被发现与避免,我们在这里总结了两个教训。

  1. 将来我们能够减少错误吗?我们将通过全面的单元测试改进协议发布过程:
    — 更清晰,更严格的代码审查政策
    — 注入前有更清晰的冻结和复查期
  2. 如果依然存在错误,我们如何确保能发现它们?尽管巴比伦网络从9月27号开始已经开始运行,我们没有充分发动大家参与其中。因此网络上的流量不能实际反映主网的情况。此外,由于区块浏览器缺乏对测试网的支持,从而严重限制了用户和开发人员检查测试网络数据的能力。在上个月,我们对测试网络基础设施进行了重组,以改善服务并吸引更多社区成员参与其中。另外,诸如TzStats之类的一些区块浏览器正为巴比伦网络提供支持,并将继续支持未来的测试链。

问题:限制原始(KT1)合同支付交易费用

随着委托流程的简化,原始帐户(KT1)不再需要支付交易费用。这一变更的目的是确保所有交易费用始终由tz1地址支付,并消除通过KT1帐户支付的费用所产生的计算开销。因为智能合约需要被完全执行,以验证其有效性。这可能会极大地优化内存池,并增加吞吐量。

但是,现在的遗留的多步骤委托流程导致了一种普遍的情况,tz1帐户的所有资金都被转移到KT1帐户,以最大程度地委托金额。在巴比伦之前,因为KT1帐户能够支付交易费用,因此不存在这样的问题。

由于巴比伦和KT1帐户不再能够支付交易费用,因此在协议升级之前余额为零的隐式帐户需要存入1µꜩ(0.000001ꜩ)的资金,以防止对新配置消耗的要求。

这导致了两个问题。首先,这些账户的创建及1µꜩ的存入没有记录,这给区块浏览器带来了麻烦。其次,1µꜩ的余额不足以支付一笔交易。

为了帮助受影响的帐户,Cryptium Labs为所有处在这种情况的隐式帐户提供了0.01ꜩ的资金,这足以使该帐户支付至少一笔转帐交易(例如,为tz1地址提供足够的费用来支付若干笔转账交易)。

如何改进

关于协议迁移期间创造代币的影响以及区块浏览器对其解释的方式,我们认为最干净、最连贯的方法是在迁移区块上附加一张收据,以显示由迁移引起的所有余额更新。但是,这需要对Tezos环境进行更改,而不仅仅是协议更改。协议环境随着时间变化被改编与设计(例如,以适应新的密码库)。

关于交易费用的影响,在协议升级之外直接为帐户注资是一种简单可行的原始科技方案。但是,如果将来再次出现任何此类事件,则应与受影响的用户进行更清晰的沟通,以确保每个人都能顺利升级。

取得的成果

这是首次一条正在运行的去中心化、无需许可且抗审查的区块链协议以一种有意义的方式进行进化。巴比伦为可以逐渐进化并能适应整个生态系统中最佳技术的区块链的发展铺平了道路。

此外,对于Tezos来说,这是两个独立的核心开发团队首次合作开发同一协议。虽然一路挫折无数,但最终取得了成功。这表明核心开发在去中心化的同时也可以快速升级协议。

最后,我们一起回顾下许多有效的功能:

结束语

总的来说,我们认为以下内容为提案流程改进的关键领域:

  • 提前简要列出所需功能并将开发重点严格集中在这些功能上,然后等待完成所有审查、测试和文档记录。
  • 提前使功能文档和变更日志更易于访问和查看,以使社区有更多时间参与其中。
  • 发布测试网络的独立功能,以便生态系统开发人员可以提前访问与反馈。
  • 测试网络重组与维护。
  • 对每个合并请求的更多审查以及更多的单元与集成测试。

最后,一定要记住Tezos此次的更新范围。从功能上讲,巴比伦协议相对雅典协议是一次重大飞跃,它几乎触及了协议的所有主要领域:Michelson、投票程序、账目和共识。随着巴比伦的升级,Tezos社区向全世界证明了我们是首个可以显著改善运行协议的区块链。尽管依然存在着很多障碍,但这不能阻止我们随着时间的推移对Tezos进行改进,因为现在正是为一个持久且有重大意义的区块链协议打好基础的时期。