万字长文详解以太坊最新研发进展

编译：洒脱喜

写在前面：本文由20位专业以太坊研发者撰写的15篇子文章组成，他们分别就不同客户端、Ewasm、形式化验证、Remix、Plasma、ETH 2.0 、Solidity、状态通道、ZoKrates等细分研发工作进行了总结，原文发布在以太坊基金会（EF）官网。

以下是译文：

朋友们，

自上次发布报告以来，以太坊研发已取得了全面的进展。从改善网络条件，到接下来的伊斯坦布尔硬分叉发布，以及Eth1.x和Eth2.0的开发，以太坊功能性和可持续性的所有核心领域都在进步。

本系列文章的重点，在于覆盖以太坊基金会及更广泛的以太坊生态系统的团队及尝试，这些团队和尝试正致力于改进以太坊，让其作为一个整体发展。在这篇文章中，我们将介绍上一份报告中重点介绍的很多团队的最新情况，以及以太坊生态系统的核心要素，如Eth2.0研究、Geth、Solidity以及其他生态系统工作。

Enjoy!

内容目录

一、Aleth / C++ 以太坊

1. EVM & 其它共识

2. 网络（Networking）

3. RPC

4. 数据库（Database）

5. Testeth工具

二、生态支持项目（Ecosystem Support Program）

1. 台湾专项拨款

2. 不断增长的非财务支持

3. 网站改进

三、Ewasm

1. Scout

2. 执行环境（EE）

3. 快速密码学（Fast Cryptography）

4. 速度、计量、大小（Speed, Metering, Size）

5. 工具

四、形式化验证

五、Geth

六、Javascript团队

1. Web3.js

2. Ethers.js

3. EthereumJS

4. Grid

七、Python生态系统[PyEVM/Trinity/Web3.py/Vyper]

1. Web3.py

2. Trinity

3. EthPM

八、 Remix

九、研究 [CBC]

十、研究 [Plasma]

十一、 研究[Serenity / Eth2]

十二、安全性 [安全性 / 共识测试]

十三、Solidity

1. Webassembly

2. Solidity 0.6.0

3. SMT Checker

4. Yul Optimizer

十四、状态通道研究

1. 状态通道的下一步该怎么走？

十五、ZoKrates

一、Aleth / C++ 以太坊

作者：Andrei Maiboroda

Aleth团队是在跟进伊斯坦布尔升级以及Eth1.x链开发的客户端团队之一。Aleth 1.7.2 版本客户端对伊斯坦布尔升级是完全支持的。

1.1 EVM & 其它共识

evmone项目的重要里程碑：

在这个实验性快速EVM项目的初始版本发布之后，我们集中精力从中压榨出更多的性能。0.2.0版本要比前一版本快66%。随后，0.3.0版本使evmone与伊斯坦布尔升级规范相兼容。对于那些对evmone试探索概念感兴趣的人以及关于优化EVM的更多信息，请参阅Devcon5大会演讲上提供的EVM实现的优化技术幻灯片以及关于EVM的高效gas计算算法的文章。

EVMC项目（EVM实现的跨语言API）在伊斯坦布尔的支持下得到了所需的更新。它们都被打包到EVMC 7.0.0当中。

在aleth解释器中，开发人员也进行了一些优化，以消除某些操作码实现中不必要的状态访问。由于evmone项目提供的EVM测试套件，这些无效访问变得显而易见。

aleth解释器也从使用boost::multiprecision切换到intx库。这是在不依赖于boost的情况下发布aleth解释器的一个步骤，但也允许做一些有趣的基准测试，看看256位整数的boost实现对我们的需求而言是有多低效。

在伊斯坦布尔升级完成之后，我们为未来的硬分叉柏林（Berlin）选择了几个EIP：其中EIP-1380会降低自我调用的gas成本，EIP-2046则降低了预编译静态调用的gas成本。这些实现可在testeth工具中进行激活，参见下面的内容：

1.2 网络（Networking）

我们实施了一个已被其它主网客户端采用的优化措施：在PoW检查之后立即将新区块广播至对等节点（peer），而不是等待完全验证及执行。我们还对交易池记住的先前丢弃交易数设置了上限（现在是1024笔这样的交易）。

devp2p handshake期间报告的客户端版本已得到了修复，并允许在ethernodes上正确显示Aleth的版本。

1.3 RPC

为了更好地符合其他客户端RPC接口中使用的输入/输出格式，我们做了很多修改。由于解决了不必要的区块交易重新执行问题，很多方法获得了显著的性能提升。这在很多频繁的RPC请求的用例中，可能会被注意到，例如在aleth中使用retesteth时。

1.4 数据库（Database）

从现有区块数据库重建索引工作已经完成，并且得到了优化，这将允许我们在未来优化和修改索引数据库的布局。

1.5 Testeth工具

测试团队对共识测试文件夹结构进行了重组织，现在Testeth工具已经支持了它，伊斯坦布尔升级之前所有涉及fork规则的测试都在LegacyTests套件中。

现在可以生成状态测试，并使用“fork name+EIP_number”之类的字符串代替expect部分中的常规fork名称来运行。这允许任何计划在aleth中创建新EIP原型的人，在分叉接受EIP之前为它们生成测试（这是以EIP为中心分叉过程的基本思想，目前被所有核心dev社区所采用）。作为机制的一个例子，上面提到的两个新EIP（EIP-2046和EIP-1380）可以在testeth中激活，我们创建了两个状态测试来说明这个特性。

我们还修复并优化了testeth的特性，以运行任何自定义测试文件（超出预定义的共识测试结构），并使其输出更符合go-ethereum的evm工具。这使我们能够将 testeth集成到goevmlab项目中，现在aleth的EVM实现与其他三个主要客户端的EVM一起参与了交叉模糊化（fuzzing）工作。

其它的改进：

1. 为那些从头建造aleth的人提供了更好的构建过程；

2. docker图像的改进；

二、生态支持项目

作者：ESP团队

2.1 台湾专项拨款

最近，我们给Crosslink Taipei项目发放了5笔2000-5000美元的补助金，这些是一系列旨在表彰世界各地社区贡献的补助计划的其中一个案例。

2.2 不断增长的非财务支持

我们正继续扩展我们对项目“支持”的定义，在这些项目中，定期拨款并不合适。我们提供的一些非财务支持，包括专家顾问的反馈、连接正在进行类似工作的团队、AWS信用、参加活动的邀请等等。

2.3 网站的改进

（注：意义不大，省略不译）

三、Ewasm

作者：Alex Beregssaszi和Paul Dworzanski

自上一次更新以来，Ewasm团队的重点已经转向了Eth 2.0的研究，以及与其它团队进行密切合作。

目前，Eth 2.0 的第2阶段（phase 2）执行层开发工作正在积极进行，它是与第0阶段（phase 0）和第1阶段（phase 1）的开发工作并行的。关于第2阶段（phase 2），研发者已提出了多项提议，Ewasm团队一直致力于将有原型和基准的设计，建立在Scout的最低基础上。

3.1 Scout

Scout规范是执行环境（EE）的最小接口。这个最小的接口足以对无状态EE进行原型化，而无状态EE是验证无状态模型所必需的，并且可以为Ewasm和第2阶段（phase 2）的设计提供信息。

Scout有三种实现方式：

1. 用Rust语言写的scout，专为快速原型开发和协作而设计（它使用支持分析的Wasm解释器）；

2. 用Typescript写的scout.ts，用于快速原型开发和浏览器支持；

3. 用C++写的ScoutOne，为性能和生产使用而设计，可嵌入到Eth 2.0客户端；

3.2 执行环境（EE）

与Eth 1.0 有状态模型不同，Eth 2.0的设计是无状态的，因为状态存储在链外，而只有表示状态的哈希存储在链上，而验证内容（witnesses）作为交易的一部分进行传递。

无状态模型提出了新的挑战，这需要原型和测量来验证它的可行性。

Ewasm团队在原型设计及测量无状态EE方面付出了巨大努力，我们将其分类成：

1、必须与Eth 1数据结构和执行兼容的执行环境（EE）；

1. SMPT（无状态默克尔Patricia树）使用RLP序列化验证内容（witness）及交易数据，并使用 Eth1签名方案。

2. 用Assemblyscript实现的EVM；

3. biturbo（以前称为TurboToken），使用多证明（Multiproof）更有效地编码验证数据，还支持EVM执行；

2、不需要向后兼容的设计；

1. KMM（Katajainen Makinen Merkle）TokenEE，针对验证内容大小和执行时间进行了优化；

2. Groth16 验证程序实现，用于支持Eth 2.0的zk-SNARKs；

3. STARK验证程序实现；

值得注意的是对Eth 1和Eth 2链之间相互作用的积极研究。为了帮助评估“切换”方案，其中Eth 1被移动到Eth 2上的执行环境（EE），上述Eth 1 EE会被原型化。团队还在积极评估连接这两个网络的方案及其对EE设计的影响。

我们的最终目标，是为现有及新的DApp提供良好的开发体验。

这项EE工作已反馈到Scout及Eth 2.0的设计当中。

3.3 快速密码学（Fast Cryptography）

要想使Ewasm虚拟机成功，我们必须在链上执行昂贵的crypto。幸运的是，crypto在bigint算法中经常有runtime瓶颈。首先，我们对密码学原语的各种实现进行了基准测试，以确定瓶颈。然后我们设计了一个快速的本地bigint API来解决这些瓶颈。最后，我们在其创建者的协作下，扩展了高度优化的websnark库，以调用这个bigint API。

结果是令人鼓舞的：通过在解释器中实现这个bigint API，我们在椭圆曲线操作上接近了本机速度！我们现在可以接近本机速度执行配对，这是Ewasm研发工作中最近获得的最大成功。

这项工作允许上述EE原型在Eth 2的性能约束下运行。

3.4 速度、计量和大小（Speed, Metering, Size）

Ewasm还有很多其它与速度、计量（减少计量runtime开销和精确地接近runtime）以及和字节码大小有关的项目。从Wasm引擎优化，到计量分析，到字节码转换，Ewasm团队正努力设计尽可能最佳的执行系统。

3.5 工具

我们一直在为Ewasm的工具工作。

Eth 2和bigint API的结合，是为Assemblyscript以及Rust提供的。

如果Wasm字节码需要扩充，则开发一个名为chisel的可扩展工具来提供Ewasm和非Ewasm应用所需的各种转换（例如字节码大小缩减和导入/导出的调整）。

四、形式化验证

作者：Leo Alt

新的形式化验证团队正在开发相关工具，为基金会的其他团队提供正式的模型和证明，并与以太坊FV社区的成员共同努力。

最近的工作重点有：

1. Solidity的SMTChecker，这是一个用于Solidity智能合约的无限模型检查器；

2. KYul，Yul语义在K.KYul中被进一步用于通过计算非优化和优化Yul代码的互模拟证明（bisimulation proof）来支持Solidity编译器；

3. 在FV社区各成员的支持下，领导智能合约规范语言的开发。规范语言用于描述合约属性，旨在简单化，并得到许多FV工具的支持；

4. 在信标链（Beacon Chain）验证工作中，支持Eth2 研究团队以及Runtime验证；

5. （与Dapphub一起）维护HEVM，这是一个完全兼容的Haskell EVM实现；

6. 支持测试团队利用在不同EVM实现中发现的分歧，来扩展以太坊测试的覆盖范围；

五、Geth

作者：Péter Szilágyi

Geth团队在今年7月份发布v1.9.0版本客户端后，我们一直在忙着迭代现有的代码库、修复发现的任何问题，以及为客户端准备迎接伊斯坦布尔硬分叉。除了这些维护更改（总共8个版本）之外，Geth团队还为将来的一些新事物打下了基础。

我们已围绕用于网络和对等节点发现的ENR（以太坊节点记录）建立了一个由5个EIP组成的宝库。

fork id工作已部署到以太坊协议之上，允许Geth节点在不兼容的机器之间干净地划分网络。这些记录还被一个新的通过DNS公开的发现服务索引（尚未最终确定），这使得日蚀（eclipse）攻击变得更加困难，并将允许以太坊在UDP被锁定的环境（通过HTTPS的DNS）中运行。

性能方面，我们正在多个方面开展工作。在spectrum方面，我们试图通过使交易（甚至可能是区块）更智能地传播来减少网络负载。另一方面，我们正在研究一个状态捕捉器，它可以跟踪活跃链，并作为EVM执行和状态同步的加速结构。在此期间，我们正在为Geth开发各种配置选项，允许用户丢弃数据库中对他们没有用处的部分（不影响网络健康），从而节省宝贵的SSD容量。这些都是有希望的前进路线，我们将在不久的将来分享一些数字。

我们在轻量级客户端基础设施上也投入了大量工作，允许服务器运营商通过RPC API分配和管理客户端优先级和资源许可。虽然长期而言，轻客户端的激励，计划通过点对点协议工作，但目前的功能集已允许运营商在Geth之外收取付款，并与Geth的内部会计同步。这将立即允许任何人创建付费的轻服务器服务（要注意的是，目前还处于原型阶段）。目前，我们正在为完全P2P支付层做开发工作。

六、Javascript团队

作者：Samuel Furter、 Holger Drewes、 Marc Garreau、 Everton Fraga以及 Richard Moore

你可能已经听说过了，因为这并不是什么秘密，但我们还是要利用这次EF Dev报告的机会，正式向大家宣布：EF已经组建了一只强大的新JavaScript团队，将以下已建立的项目集合在一起：

1. Web3.js；

2. Ethers.js；

3. EthereumJS；

4. Grid；

来自这些不同团队的人员，已开始跨项目线做出贡献，并讨论了互操作性问题，我们预计在中期的未来将出现强大的协同效应。在明年的第一季度，我们将作为一个新的团队共同成长，并建立起信任和必要的组织结构。期待在2020年的时候，我们将提出和执行一个连贯的战略和愿景，以最大限度地发挥我们的影响，支持以太坊JavaScript/TypeScript 开发者生态系统。这将超出以往单一项目的范围。

然而，目前的项目并不会被遗忘。我们非常清楚，我们必须关心并进一步开发在社区内被广泛使用的工具。因此，以下内容是关于各子项目的更新，以揭示在上一季度中，这些项目都发生了什么。

6.1 Web3.js

自上一篇EF博客文章发布以来，我们已经发布了多个Web3.js补丁，并切换到语义化版本控制。这些修补程序添加了TypeScript的支持，扩展了交易签名功能，添加了交易确认工作流属性，添加了JSON-RPC方法getChainId，将connected事件添加到订阅，使用方法supportsSubscription和其他效用函数扩展提供者接口，以使用bloom过滤器。

关于新特性及改进的更多细节，你可以在GitHub上的发布公告中看到。

目前，我们的重点是减少bundle（包）的大小，提高性能，为WebsocketProvider添加重连接，以及改进TypeScript DX。

除了这些改进之外，我们还有幸目睹Chris加入EF-JS团队，目前Chris在支持Web3.js开发，当然他也会参与所有其他EF-JS包的开发工作。

6.2 Ethers.js

我们已经为公共使用做好了v5准备，并且采用率一直在稳步增长。对于所有尝试它并报告相关问题的人，我们表示非常感谢。

v5的重点是为框架开发人员添加可扩展性和改进API，包括一个新的框架ethers-app，重点是dapp开发人员。

由于新问题的数量已经减少，我们预计v5将很快投入应用，只需在管道中进行一些小的更改。

6.3 EthereumJS

在EthereumJS方面，最值得注意的是针对伊斯坦布尔升级的不同组件的发布：VM在9月份得到了一个更大的v4.1.0更新，我们目前正在消除最后的bug，使VM完全符合官方测试套件。在伊斯坦布尔升级环境中要提到的其他更新，与交易、区块和公共（硬分叉和网络逻辑）库有关。

6.4 Grid

自上次EF博客文章更新以来，开发者对以太坊Grid进行了几次重大升级。该应用程序现在位于你的操作系统任务栏中，并提供一个简单的用户界面来下载、配置和运行以太坊客户端和工具。该插件系统将随着每一个新的集成而不断改进，但同样令人兴奋的是Grid应用。该应用已可用来测试RPC方法、通过Geth的GraphQL实现查询区块数据，用 Clef签署交易等等。团队一直在忙着编写使用Grid可做什么的教程，你可以在Medium上看到这些教程。

七、Python生态系统（PyEVM/Trinity/Web3.py/Vyper）

作者：Piper Merriam

7.1 Web3.py

最近的工作是改善稳定性和文件记录。当前的开发重点是添加对库的异步支持。

7.2 Trinity

开发者正开发一个Trinity客户端的beta版本，其中包括新开发的“Beam Sync”（https://medium.com/@jason.carver/intro-to-Beam-Sync-a0fd168be14a）。我们还专注于和更广泛的客户端团队生态系统的合作，以解决一些更大的问题（如状态爆炸），并找出Eth 1.x向2.0世界的迁移路径。

7.3 EthPM

我们继续在关注生态系统工具。ethpm-cli开发工作继续进行，允许安装来自不同来源的包，以及构建和发布包。

八、 Remix

作者：Yann Levreau

关于Remix，我们有很多更新内容要和大家分享。近几个月来，我们的团队一直在工作：

1. 改进Remix插件并以各种方式与社区合作- @GrandSchtroumpf；

2. 为Edi Sinovcic的github集成实现WebSocket插件；

3. 帮助Quorum整合他们的Remix插件；

4. 和Waffle（Ethworks）合作开发他们的插件；

5. 与VSCode以太坊团队合作，将插件引擎集成为VSCode扩展；

6. 使得加载插件资源实现完全去中心化（目前使用了IPFS技术）；

7. Remix库：@Aniket最近加入了团队，负责改进、维护和推广remix存储库 https://github.com/ethereum/Remix。这包括remix调试（交易调试）、remix测试、remix solidity以及remix analyzer中的关键工作（添加了新模块：ETH传入循环警告）；

8. Remix库：完成Remix模拟器并向Remix debug@iurimatias添加更多测试；

9. 改进IDE的文件资源管理器以支持文件夹及标准功能。与Ethworks合作开发新主题。使用Monaco 编辑器。根据Solidity pragma设置编译器版本- @Lianahus @ryestew @Aniket @GrandSchtroumpf；

10. 我们在这里介绍了Remix桌面版 https://medium.com/remix-ide/remix-desktop-8c1e9e946ee1，现在我们正在完成它。注意，很快就会正式发布！- @yann300 @lianahus

11. Remix Workshop是一个运行在Remix插件API中的插件；

它允许创建教程、注册教程，并允许学生和学习者实际运行教程。正在制作的教程范围非常广泛（例如Solidity、Vyper、常用以太坊概念等）。这取决于教程的创作者！第一个POC是成功的，我们现在正朝着在社区不同团队的帮助下发布第一个版本，以获得建议和反馈。-@granchtroumpf@ryestew

1. 社区以外的研习会及外展活动：一方面，我们也是通过各种方式为教育工作作出贡献。我们预计到2020年，这一点将变得更加重要。- @ryestew @Aniket @GrandSchtroumpf @team

2. 组织研讨会/会议（ESE、Consensys、Devcon、Dappcon）；

3. 与社区外的组织和人员会面。不一定是技术上的，但更多的是让人了解什么是区块链，什么是以太坊；

4. 为它构建一个工具（见Remix workshop）

九、研究（CBC）

作者：Aditya Asgaonkar

Casper CBC研发团队最近的工作重点是：

1. 描述最小CBC Casper协议以及统一框架（名为VLSM）中的活跃性验证策略。相关公共文档WIP即将发布；

2. VLSM的形式化验证；

3. 使用CBC Casper元素改进Eth2.0设计，如https://ethresear.ch/t/cross-shard-messaging-system/6201；

4. 社区推广工作，如这次AMA: https://www.reddit.com/r/ethereum/comments/dsiz9j/ama_we_are_the_cbc_casper_research_team/

敬请期待新的进展！

十、研究（Plasma）

作者：Plasma Group

自五月份以来，我们一直在努力推动扩展性技术的进步。生态系统中有4个不同的团队为多个区块链构建通用的Plasma规范，包括OmiseGO、Matic、Cryptoeconomics Lab以及Plasm。由于我们的许多同行都在支付方向进行努力开发，因此我们开始着手可扩展性研究较少的领域，比如应用开发和一般的可组合性。这方面的发展包括Optimistic虚拟机（一种用于layer2构建的通用争议语言）以及我们的Uniswap Devcon 5演示（一种可扩展的支付和交易游戏，它可以在Unipig交易所上找到）。这款游戏建立在一个optimistic rollup链上，这个设计是6月初时与Barry Whitehat以及Vitalik在以太坊扩容会议的对话中产生的。

在年底结束时，我们正准备为OVM推出一篇论文，并为Optimistic Rollup编写更深入的文档。目前，那些有兴趣了解它的人，可以在我们的博客上找到它的描述，在那里，我们描述了如何为任意智能合约构建它，以及一些概述从plasma到optimistic rollup的早期文档：

我们的论坛：https://plasma.build/t/rollup-plasma-for-mass-exits-complex-disputes/90/1

Github: https://gist.github.com/karlfloersch/1bf6ab7871f41e3a5a921c0a007ad5c6

Plasma会议视频：https://youtu.be/5RpYoU6xD_M?t=1136

十一（Serenity / Eth2）

作者：EF 团队

在Devcon5之后，Danny和Eth2研究团队开始了一个每周Eth2快速更新系列的工作，最近又开始了一个关注Eth2验证的系列工作。由于我们正接近推出阶段0，最新的新闻和进展会较多，例如下面的链接，也请保持对 EF博客的关注！

总的来说，我们正朝着阶段0测试网以及主网启动的方向继续前进。第一阶段的规范和原型工作是并行的，而第二阶段的研发工作也在积极进行当中。

验证：以太坊2.0 的Staking2019-11-27

Eth2快速更新#4-2019-11-21

Eth2快速更新#3-2019-11-08

Eth2快速更新#2-2019-10-31

Eth2快速更新#1-2019-10-23

十二 安全性（安全性/共识测试）

作者：Martin Holst Swende

在安全性方面，关于伊斯坦布尔硬分叉已经有了很多行动。例如旧的基于python的fuzzer (Evmlab) 已通过Go语言重写，并被用于创建EIP目标fuzzer。这些fuzzer用于生成测试应用（在Besu和Nethermind中发现实施缺陷），并用于运行数百万个比较Geth和Parity的测试用例——截至11月底，我们还让Aleth和Nethermind VM在同一fuzzer框架上运行。所以我们现在最多有四个EVM在做微分模糊测试（fuzzing）。

同时，我们还在Geth和Parity上运行基于libfuzzer的fuzzer，这项工作是由@cryptomental领导的。

不久前，我们在悬赏页面上宣布为EIP的安全审计拨款1.5万美元。其中，我们向Neville Gretch contract-library.com以及Hubert Ritzdorf（Chainsecurity）分别授予了5000美元，理由是他们为EIP-1884的安全影响进行的评估工作。

其他几项赏金也已经发放，其中大部分将很快公开分享。

十三、 Solidity

作者：Christian Reitwiessner

Solidity语言和编译器继续维持稳定，并添加了社区请求的一些功能。其中包括输出用于各种灵活格式、稳定性及安全性变化的Solidity代码的选项。团队正在开发一个新的0.6.0版本以及0.5.x 分支更新。

13.1 Webassembly

Solidity支持使用–ewasm开关进行webassembly代码的实验性预览输出。我们扩展了Yul优化器的大部分阶段来处理eWasm代码，目前正在研究将EVM型Yul转换为eWasm型Yul的glue代码，并拥有了一个用于生成部署合约所需的eWasm二进制代码的工作原型。

13.2 Solidity 0.6.0

我们几乎完成了突破性的更改，并有望在今年晚些时候发布Solidity 0.6.0版本。一些新的变化包括：

1. 需要显式的“virtual”和“override”关键字来重写函数；

2. ABIEncoderV2不再是实验性的；

3. 回滚函数被分为“接受以太币”函数和一个实际“回滚”函数；

4. 抽象合约必须标上“抽象”字样；

5. 结构（Struct）和枚举（enum）可以在文件级定义；

6. 不允许任意设置存储阵列的长度；

7. 支持push（）将新的默认初始化元素添加到动态存储阵列；

8. 将“leave”语句添加到Yul / Inline程序集（Assembly）以从当前函数返回；

9. 支持NatSpec中的多个返回值；

10. 支持命令行更好的错误消息格式；

11. 元数据哈希现在默认为IPFS，可切换到Swarm或删除；

12. 允许从二进制文件中删除 “revert reason strings” ；

13.3 SMT Checker

SMT Checker有了一个新的模型检查引擎，它支持循环，并允许在考虑无限数量的交易时检查断言。请在这里阅读有关更改的更多信息：https://medium.com/@leonardoalt/smtchecker-toward-completeness-1a99c02e0133；

我们目前正致力于在新引擎中支持函数调用，这将启用多合约分析，即使调用的代码是未知的。

13.4 Yul优化器

Yul优化器现在可考虑用户定义函数的无副作用性，从而在这些函数调用之间进行优化。它能够删除冗余的sload和mload调用，并且可以考虑变量的条件局部值。

编译器接口：

1. 如果使用标准json，则编译器仅为所选合约生成字节码，如果未请求字节码，则在作句法分析后停止。

2. 选项–error recovery可用于从大多数解析器错误中恢复，这样你就可以为无效输入创建类似AST的东西；

除了上面列出的更改之外，我们还实现了许多小错误修复以及特性。

十四、状态通道（研究）

作者：Liam Horne

在过去的几个月里，以太坊的状态通道研发团队取得了喜人的成果。

最令人兴奋的是，状态通道在以太坊主网上线了。Connext是一家建立在我们工作基础上的小额支付服务公司，其自2019年9月开始就已投入应用。状态通道带来的可扩展性和UX增强不再是理论上的，它们现在正在惠及用户。不妨去尝试一下吧！

而在幕后，研发人员在过去的6个月里一直很忙。今年夏天，两个主要的状态通道研究小组Counterfactual 和Magmo将他们的工作统一到一个单一的项目和协议中，并将其简称为“StateChannels”。这种统一使我们能够以更快的速度移动，也为以太坊的应用开发人员提供了更轻松的体验，他们不需要去考虑支持哪种通道标准了。

更具体地说，在过去几个月里，我们进行了如下这些工作：

1. 已完成合并CF和Magmo代码库；

2. 在这里实现了一个客户端API 记录，以及在这里对协议进行了文件解释；

3. 重新编写了我们的Solidity合约代码库，以便为“happy case” (612K → 165K)和“challenge case”（1100K→200K）节省大量gas；

4. 用一种称为TLA+的形式化规范语言编写ForceMove协议。这使得我们可以找到许多有趣的协议优化，并识别非主动攻击向量。你可以在我们的研究论坛上读到更多的信息。

14.1 状态通道的下一步该怎么走？

我们正在开发两个演示应用，它们完全基于客户端API构建，并通过我们的参考中心（reference hub）在浏览器中运行。

开展新项目，招募新的贡献者，并继续使状态通道对开发者友好。

十五、 ZoKrates

作者：Jacob Eberhardt

我们很高兴与大家分享ZoKrates的最新进展，其旨在成为以太坊平台上的一个功能强大并对用户友好的工具包。

针对ZoKrates开发者的好消息：浏览器内的ZoKrates代码开发，现在在Remix中得到了支持。你可以通过左边的插件管理器找到ZoKrates插件。

社区一直希望能有一个更丰富的类型系统，ZoKrates现在以结构和多维数组的形式支持复杂的用户定义类型。为了使用这些来自外部世界的新类型实现与ZoKrates程序的无缝交互，我们添加了一个JSON-ABI，它允许轻松的编程访问。

为了提高ZoKrates的可读性，我们重构了模块系统，并将ZoKrates源代码文件的文件结尾改为.zok。在内部，基于正式DSL语法的解析器重新实现（在上一篇更新文章中提到）已经成功完成。

最后，我们对编译后的程序进行了更多的优化，以减少执行和证明生成时间。为了科普工作，我们在大阪的Devcon V大会上展示了这些结果以及使用ZoKrates的应用程序！