你们好啊,伙计们,

为了让大家了解最新开发动态,这是一系列博文的第一篇。这些博文将囊括已经提交到Tezos主代码库的更新内容。在亚瑟发布的开发视频中,他提到了每个人目前的工作内容。这些博文会有一些不同。我将进入代码的层面,谈论新的代码在审查以及提交合并之后,在zeronet上运行会有哪些效果。所以这些博文的内容往往不会和亚瑟的开发视频有所关联。我不会介绍所有的合并请求,除了那些看上去很有意思的。如果你有任何技术上的疑问,欢迎给我发Mail

这篇博文中我会提到几个可能在不久的将来没准也不会实施的合并请求,如果你在GitLab上看到它们,千万不要惊讶。

Milo

上周已完成

让协议与‘doc/whitedoc/proofofstake.rst’保持一致

这次的合并请求中还有许多内容尚未解压缩。我将重点关注两个和权益证明(POS)算法最密切也最有趣的改动。如果对完整的改动有兴趣,请自行查阅合并请求。

合并请求中加入了两个新的操作。在此之前,它包含的操作有发起合约、转账、启动升级、设置POS委托等等(你可以参阅operation_repr.mli以获取完整列表)。新的操作是为了防止烘焙人员的作弊行为(读数作弊)。POS算法委以不同的烘焙人员烘焙和验证区块的权利。然而如果没有惩罚机制,那就没有办法阻止一个烘焙人员在每个层级烘焙和验证多个的区块。一旦人们开始这样做,区块原有的机制就会失效,因为没有办法去区分两个被同一个烘焙人员烘焙并验证的区块。为了防止这样的事情,惩罚机制允许每一个人提出他人的作弊嫌疑。无论烘焙还是验证区块都需要用户对头文件进行加密签名。如果有人注意到同一层被烘焙或验证的两个区块拥有相同的签名,他就可以将这个签名播送出去。其他任何人都可以验证用户是否真实签署了这些信息。最后一旦这个惩罚操作被写入区块,那么相关的烘焙人员或者验证人员就会丢失他们的保证金。

类似的还是截取快照的情况。快照被用来计算每一个给定周期内每一个烘焙人员所持有的份额。因为作为烘焙人员来说,持有的份额越大,那么烘焙区块的机会就越多,也就可以认领更多的奖励。由此每一个人都会受到激励使得他们在截取快照的时间点想要拥有尽可能多的份额。烘焙人员可以在快照之前大量买入令牌,快照之后又快速卖掉,以此实现一个周期内他们的最大利益,以及带给市场不必要的波动和紧张。为了避免这样的策略,我们截取多个快照,然后随机选取其中一个快照作为有效参考。这样烘焙人员就无法准确知道交易的时间点,他们的策略一定程度变得无效了。在每一个区块之后都截取快照也是可行的,但是这样会占用大量的内存,所以真实截取快照的频率会有所降低。

Jbuilder beta 18

去年秋天,我们将Tezos系统切换至了Jbuilder/Dune(他们正处于修改名称的过程中)。Dune是一个基于OCaml的系统,比起基于Makefile的系统有许多的优势。在大多数情况下,他能够加速系统的构建时间,而且可以更简单地把Tezos分拆成几个包。尽管目前为止一半以上的Opam软件包都使用Dune,但是后者任然处于Beta版本,这也就意味着它仍有可能面临着重大改动。我之前就遇见了一个问题,由于Dune的改动导致它在文件库路径下搜索却无法搜索到标准的文件库。Grégoire帮忙解决了这个问题,并修正了构建和发布的流程工作方式。

自从这个合并请求创建以来,Dune的伙计们已经发布了他们的第19个beta版本,也就是Tezos目前正在使用的这个。目前看来这第19个beta版本不会对Tezos产生负面的影响。具体的改动你们都可以在这个合并请求中看到,后者已经被手动合并到了主代码库中。

Michelson: make maximum integer for gas 32 bit compatible (#169)

这里修复了一个由OCaml32位整数引发的程序错误。在32位的OCaml中,整数的最大值是2的31次方减1。由于Tezos可以同时在32位和64位的OCaml环境下编译,所以我们需要确保所有的整数都在这个范围内。这次的合并请求确保了所有的常量都处于这个范围之内。我们感谢向我们报告这个程序错误的某位社区成员。如果你发现任何Tezos的程序错误,请在我们的问题页面提交给我们。

讨论中的那些合并请求(也许将来也不会合并)

也许有人好奇这些,所以我将他们列出来谈论。他们也许存在于Tezos GitLab中有一段时间了。如果你有强烈的需求或者对这些功能的使用案例,请联系我们。我们目前依然在犹豫是否包含这些Michelson 指令,因为我们不能确定是否永远支持这些功能。

Michelson:字符串操作

大约五个月前,我们在讨论Michelson是否需要额外的字符串串联操作。更甚至我已经编写好了代码来实现它。但是最终我们决定如果有人能够提出一个很好的使用案例,我们才合并这个请求。所以如果你有,请随时告诉我们。再者,包含这个功能的合并请求现在看来已经有点陈旧了,所以如果要合并它的话可能需要一定的重建工作。

Michelson:增加CONTRACT_EQ指令

这是另外一个谈论领域。我们意识到比较两个合同的效果是很困惑的,而且在进行哈希运算之前进行操作也有些不切实际。如果你想要在一个交易发起之前通过合同来鉴别用户,那么合同效果的检查是相当重要的。在很多的方面,这种身份验证方法比起发送签名信息更具有优势,因为这样可以创建一个API(应用程序接口)以供区块链上的合约调用。包含这个功能的请求目前没有被合并,因为我们仍然在讨论实施某种无类型合约。它的代码还处于合并请求的列表中,但是我个人觉得在主网上线以前应该不会被合并。

作者:Tezos核心开发成员Milo

翻译:Tezos中文社区成员/Song.W