One article to understand the latest research and development progress of Ethereum, zero knowledge proof, sharding and other topics

Written in front: The original text was jointly completed by 14 research and development teams funded by the Ethereum Foundation (EF). , Solidity, ZoKrates and other subdivision research and development work were summarized.

friends:

During this complex period, we hope that everyone will be safe and secure. While stuck at home, we once again update the community on the progress made by the Ethereum R & D team. Although we just released the winter summary a few months ago, since the Istanbul network upgrade was completed, we have come a long way, and many teams have made new progress to share with you.

• Topaz, the first testnet with Eth2.0 Phase 0 mainnet configuration, has been released
• The central bank's digital currency is ready: the wallet is undergoing internal testing, and related concept stocks have risen collectively
• The central bank's DC / EP beta is out, and we guessed about these functions …

As always, this update focuses on the teams and projects supported by the Ethereum Foundation (EF), who are working hard to develop and improve Ethereum.

Enjoy!

table of Contents

1. Aleth / C ++ Ethereum client

2. Applied Zero Knowledge Proof (Applied ZKP)

2. 1 Powers of Tau trusted initial setting ceremony

2, 2 Semaphore

2, 2, 1 Security audit and code release

2, 2, 2 Second stage ceremony

2, 3 Semaphore RLN

2, 4 MACI

2, 4 and 1 Future work: Add anonymity to MACI

2, 5 MiMC rewards

2. 6 Optimistic Rollup Hub + ZK Optimistic rollup

2, 7 PeekABook

2, 8 Experimental direction

3. Ecosystem Support Plan

4. Ewasm

4. 1 Ethereum 1.x / Stateless Ethereum

4, 2 Ethereum 2.0

4, 2, 1 cross-shard design

4, 2, 2 speed

4, 3 WebAssembly

5. Formal verification

5, 1 Act

5, 2 SMTChecker

5, 3 Verified ABI encoder / decoder

5, 4 Ethereum 2.0

5, 5 Hevm

6. Geth

6. 1 DNS discovery

6. 2 Transaction broadcast

6.3 Dynamic snapshot

6, 4 Discovery v5

7. The Javascript team

7, 1 Ethers.js

7, 2 Web3.js

7, 3 EthereumJS

7, 4 Grid

8. Python ecosystem (PyEVM / Trinity / Web3.py / Vyper)

8. 1 Web3.py

8, 2 Trinity

8, 3 EthPM

9. Remix

9, 1 Remix IDE-live and desktop applications

9, 2 Remix plugin

9, 3 External plug-ins

9, 4 Remix simulator

9, 5 Remix static analyzer

9, 6 Remix test

9, 7 blog posts and reach communities

9, 8 E2E test

10. Ethereum 1.x research (stateless Ethereum)

11. Serenity research (Ethereum 2.0)

11.1 Ethereum 2.0 quick update

11.2 Staking for Ethereum 2.0

12. Security and consensus testing

13. Solidity

13. 1 SMT checker

13. 2 Solidity Summit

14. ZoKrates

1. Aleth / C ++ Ethereum client

Author: Paweł Bylica

In December 2019, we released version 1.8.0 of Aleth, which contains many fixes and improvements on C ++ Ethereum node functionality. In particular, we have improved the RPC interface, blockchain synchronization, network protocols, and test tools (testeth, aleth-vm). For more details, see the change log.

This version also contains a lot of work related to the consensus mechanism:

1. Support Moore Glacier network upgrade;
2. Implementation of EIP-1380;
3. Perform EIP-2046;
4. Support single EIP activation to promote EIP-centric network upgrade process;

Aleth 1.8.0 is the last planned version. From now on, we are only committed to the basic maintenance of the code, PR review, and meeting the remaining needs of testing and EIP review. Here, I would like to thank all Aleth contributors, especially Nils-Erik Frantzell, who have put a lot of effort into the project in the past year.

Also worth mentioning is the maintenance version of the brother project:

1. EVMC 7.1.0;
2. evmone 0.4.0 and 0.4.1;

Finally, we published an article about EVM's efficient gas calculation algorithm and the EVM implementation optimization technology shown in the Devcon 5 presentation.

Second, apply zero-knowledge proof

Authors Koh Wei Jie and Kobi Gurkan

The application ZKP team is committed to bringing cutting-edge zero-knowledge proof research into Ethereum's application development.

2. 1 Powers of Tau trusted initial setting ceremony

In September 2019, we launched the Powers of Tau (PPOT) Trusted Initial Setup Ceremony. PPOT aims to partially reduce the burden of the Trusted Setup Ceremony to benefit the zero-knowledge ecosystem (especially for zk built on Ethereum -SNARK project). Each zk-SNARK project requires two stages of parameter generation, and PPOT replaces the first stage, so all circuits can share and use it. Each team can choose any contribution from the ceremony, expand it and execute its second stage setup.

This ceremony supports up to 2 ^ 28 constrained circuits, which means that each contribution requires 97G downloads, one day of calculation, and 49G downloads. At the time of writing, we collected 29 contributions from 28 independent individuals. All contribution files can be downloaded and verified independently according to the transcript of the public ceremony.

2, 2 Semaphore

Launched in mid-2009, Semaphore is a flagship project developed by the Applied ZKP team. It is a general-purpose privacy gadget that supports applications such as currency mixer, anonymous login, and anonymous voting. One Semaphore application that Chih-Cheng Liang is developing is Semaphore authentication, which enables anonymous logins to resist witch attacks. Readers are encouraged to read this popular science article to understand what Semaphore is and how it works.

2, 2, 1 Security audit and code release

We hired ABDK Consulting to conduct a security review of Semaphore's zk-SNARK circuit code and Solidity contract, and then fixed some of the discovered issues and released the final source code. It contains many components in the circom standard library, thus providing a more toolset for the SNARK developer community using circom.

2, 2, 2 Second stage ceremony

At the time of writing, we are performing a circuit-specific multi-party trusted setup ceremony. The process we followed is documented here . We collaborated with VDF alliance member Supernational to run a verifiable delay function (VDF) on the pre-announced Ethereum block hash, and applied the output of the VDF to PPOT ceremony challenge document # 25, and in April 2020 The circuit-specific ceremony was launched on the 6th.

Thanks to Brian Gu for his excellent work, we were able to use the ignition software of the Aztec protocol for our ceremony. Please read the participant's guide to learn more about the ceremony.

2, 3 Semaphore RLN

Semaphore RLN provides a method of performing rate limiting in P2P settings. We use the Shamir secret sharing algorithm to expose a subset of the broadcaster's private key, rather than relying on the nullifier map on the chain to prevent double signals.

2, 4 MACI

MACI was originally proposed by Vitalik Buterin in a post on ethresear.ch. The system built using MACI can make it difficult for participants to collude, while retaining the benefits of smart contract review resistance and correct execution. Although MACI can provide the ability to resist collusion only when the coordinator is honest, the dishonest coordinator can neither review nor tamper with its execution.

At the end of 2019, we began technical specifications and implementation work , and we were about to complete a minimum viable product.

2, 4 and 1 Future work: Add anonymity to MACI

MACI uses the coordinator to process, and the coordinator uses SNARK to prove the integrity, so the malicious coordinator will only damage the anti-collusion attribute. A disadvantage of the current method is that when the coordinator sees all key changes, it can link each user's original key to their final key. We hope to further improve the privacy of the coordinator by allowing users to change keys anonymously. For more detailed content on this topic, you can read this ethresear.ch article ;

2, 5 MiMC rewards

Due to its good performance, MiMC has become a popular cryptographic hash function in SNARK. Although it is the oldest function in the "low multiplication complexity hash function" family, we think it deserves more attention. We launched a collision bounty program about the MiMC hash function and plan to extend the bounty campaign to the Poseidon hash function.

2. 6 Optimistic Rollup Hub + ZK Optimistic rollup

Optimistic Rollup can achieve better layer 2 scalability by using on-chain data availability and fraud proofs. This Hub chain also allows easy mass migration between different rollups.

ZK Optimistic Rollup is based on the same idea, but its purpose is for anonymous transmission. Each transaction in rollup is not transparent transaction metadata, but 2-to-2 anonymous transmission.

2, 7 PeekABook

PeekABook allows two users to match orders privately, so that unless they have a fulfillable order, no user can find more information about the order placed by another user.

2, 8 Experimental direction

Up to now, we have described the released projects with mature codes, specifications or specific plans. We are constantly exploring new experimental areas and expect them to grow into mature projects. These include: verification of STARK in SNARK (allowing some form of layer 1 recursive blind search ), construction based on MPC, proving that there is a path between users in the p2p network without exposing the path itself, etc.

3. Ecosystem Support Plan

On April 1, we released the ESP distribution update, and then shared a list of projects to improve the process and receive financial support in 2019.

You can also follow the Foundation's twitter number to learn about the latest progress of related support projects.

4. Ewasm

Author: Alex Beregssaszi

Since the update was released in December last year, the team has been committed to the second phase of Ethereum 2.0 development work, and began actively participating in Ethereum 1.x research.

Our intuition is that some of the research content is needed by both parties and can be shared between the two.

4. 1 Ethereum 1.x / Stateless Ethereum

In the stateless model, we don't want everyone to keep a copy of the entire state of the blockchain. Instead, each block comes with a proof of the affected state part (so-called witness ). And the best creation, distribution and verification of witness has become a key component of this new stateless system.

Developers already have a lot of ideas about how to reduce the witness's size, and Paul has collected them in a survey. The first thing we have to consider is to reduce the code size. This is important because the witness also needs to include code. At present we think of two methods: compression and Merkelization. Experiments in the early stages show that we can reduce the amount of code transmission as a part of block witness by 40-60%.

We plan to explore further:

1. Reduce the storage size of witness;
2. About the exact measurement of witness size;
3. Participate in the creation of the witness specification;

4, 2 Ethereum 2.0

It must be noted that since the execution model of Ethereum 2.0 is also stateless, part of the research work of Ethereum 1.x is also applicable here.

4, 2, 1 cross-shard design

Without the ability to effectively transfer Ether (and possibly other tokens), performing payments and transactions will become complicated. Last year, researchers proposed many models, including receipts, queues, and balance graphs with accumulators. Casey proposed an alternative solution called EthTransfer objects .

In addition to Ethereum transmission, the contract may want to be able to communicate with other contracts on different shards, and may perform atomic operations. All of these have provided a broad design space for the second stage. As of now, we have been exploring.

As an experiment, starting a few weeks ago, we started to study Eth1x64 , which can reduce the design space and should allow rapid iteration of different designs.

Under Eth1x64, each shard is homogeneous and runs an instance of Eth 1.x, where shard 0 is the current Ethereum 1.0 mainnet. We are working on several small proposals, all of which focus on various ways to implement cross-shard communication.

This work will allow us to understand the complexity of introducing sharding in Ethereum 1.0, allowing us to gather broader feedback from Dapp developers, and we can use the results to improve the second phase of WebAssembly-based (Phase 2 )design.

4, 2, 2 speed

Zero-knowledge protocols have become increasingly important, and we must ensure that they are effectively supported on Ethereum 2.0 . To this end, we have developed an optimized implementation of the SNARK-friendly MiMC hash function in AssemblyScript, and a token example based on zkSNARK. The example works well in the execution environment (EE), and the benchmark test shows that both can achieve comparable performance to the compiler engine and EVM (precompilation assistance) based implementation. Regarding the specific numbers of the test, interested readers can see the summary written by Jared.

This work also guided a further review of the large integer API, which is an important element of secure implementation based on WebAssembly.

4, 3 WebAssembly

In recent months, we have released the stable version 1.0 specification of WebAssembly, which is a fruitful period for WebAssembly. Some new promising interpreter projects also appeared during the period, and we are paying close attention to them and intend to include them in our benchmark test report.

In January, we started to study Fizzy , which is a new Webassembly engine. Features such as support for integers only (floating point operations are not supported) and execution of interpreters only make it ideal for blockchain applications. In addition, the concise code base written in modern C ++ 17 and the goal of easy embedding make Fizzy a viable modular component suitable for Ethereum 2.0 client implementation. As of press time, Fizzy was able to pass almost all official test cases (except Wasm verification, which has not yet been implemented), and has a good performance in terms of speed benchmarks.

V. Formal verification

Author: Leo Alt and Martin Lundfall

5, 1 Act

Act is a simple and effective specification language for writing formal specifications. It was developed in cooperation with several teams. We hope that the Act language will be widely used in the future.

By allowing attributes to be expressed at different levels, the main goal of the Act tool is to achieve modular verification. The specification can be verified as an independent document, in which the contract invariants can be checked from the pre / post conditions of the specified function, or the post conditions can be checked from the storage update of the function. Ideally, this modular verification will make it easier for other tools to verify the correctness of source code and bytecode.

We are currently developing three types of certification backends for intermediate certification:

1. Coq definition;
2. K norm;
3. SMT theorem;

Each backend has its own advantages and disadvantages, and we hope to achieve good performance and coverage by developing all frontends simultaneously.

We hope to release each prototype that proves the backend by June 2020, and study how to express circular invariants.

We will soon publish a detailed technical article about Act, and everyone is welcome to contribute to its code base!

5, 2 SMTChecker

SMTChecker is a static analysis module based on model checking in the Solidity compiler. It attempts to verify the assertion of the source code at compile time. Last year, developers added a new engine based on Constrained Horn Clauses . The main function of this engine is to automatically find the inductive invariants used to prove assertions, thereby supporting loop and state attributes.

We have also recently added internal function calls to the engine and continuously improved support for Solidity language. In the next 3 months, we will continue to work on adding language support, counterexample generation / demonstration, and external function calls, which will hopefully transform SMTChecker from an experimental version into a useful and powerful tool.

In the future, we also hope to:

1. Combine SMTChecker and Act to study some amazing things;
2. Create a Remix plugin for SMTChecker, which will greatly improve usability;

5, 3 Verified ABI encoding / decoding

We are working with ConsenSys R & D department, they are using Yul Isabelle to develop a proven ABI encoder / decoder. This idea and related discussions started at the Devcon V conference. Since then, the related research and development has made good progress, and we have almost completed the prototype.

Initially, we intended to use it with Solidity Fuzzer to find errors related to optimization and ABI encoding / decoding. Our ultimate dream is to use the proven ABI encoder / decoder as part of the Solidity compilation process. This means that a large part of code generation is verified!

5, 4 Ethereum 2.0

We have always supported Runtime verification in maintaining KEVM formal semantics, verifying deposit contracts and beacon chain specifications. The deposit contract is also one of our main benchmarks when developing the Act language. We hope to provide alternative specifications for deposit contracts and proof of incremental Merkle tree attributes through Act language before July, and we also intend to study the attributes that must be proved in the first and second phases of Ethereum 2.0.

5, 5 Hevm

Hevm , this EVM evaluation program and debugger written in Haskell language, can now be used for property testing . Users of dapp development tools can now write Solidity tests. The parameters of these tests are randomly generated and will be run multiple times according to the correctness criteria. This provides a relatively straightforward way for smart contract developers to significantly increase test coverage.

Next, we will also explore the use of symbolic execution to extend Hevm, so that Hevm can be used to officially verify the EVM bytecode.

Six, Geth

Author: Péter Szilágyi

In the past quarter, the Geth team has been busy with network testing and laying the foundation for future releases. This article will only list some main features. For detailed points, please refer to our release notes .

6. 1 DNS discovery

We focused on a feature two years ago and officially released it last quarter. It is a peer discovery feature based on DNS. Next, Geth v1.9.11 + nodes will have two independent mechanisms to find peer nodes. When the peer node cannot be found through DHT, the DNS list will be used as a fallback mechanism. They may also eventually become the starting point for Tor integration.

The discovery function based on DNS is a centralized mechanism, but we try to make the operation of the mechanism as transparent as possible and without permission. The public list used by default is generated by searching DHT. Any Ethereum client node that users run to implement EIP-868 and EIP-2124 will automatically appear in the public list. If you want to create a list of DNS-based nodes for your private or public network, please check our DNS Discovery Setup Guide .

Currently, there are about 1150 public routing Ethereum mainnet nodes in the default list, and our public list also serves Ropsten, Goerli, and Rinkeby test networks. The network currently generates about 8 million DNS queries for this discovery mechanism every day.

6. 2 Transaction broadcast

For a long time, most of the network bandwidth used by Ethereum nodes was used to transfer transactions. Unfortunately, this mechanism has never been optimized since its birth and is therefore very wasteful. In the most recent quarter, we have updated the specifications of the Ethereum protocol ( EIP 2464 ) to optimize bandwidth consumption.

This new protocol has been implemented in Geth v1.9.11, Nethermind has also been implemented, and the Open Ethereum client is also following up. Since only about 30% of the nodes in the network support it, the global saving of bandwidth is still a problem, but the comparative experiments using eth/64 and eth/65 have already had good results.

Based on the traffic last week, eth / 65 able to reduce the bandwidth used by transaction broadcasts by approximately 75%. For a boot node with 250 peer-to-peer full nodes, this saves 750KB / s, or about 1.8TB of bandwidth per month. We are convinced that there is still room for improvement, but we need to move forward step by step.

In addition to eth / 65, Geth also supported transactions larger than 32KB in January (provided by StarkWare). The initial soft limit was 64KB, which will soon be increased to 128KB (the higher limit depends largely on eth / 65 global performance).

6.3 Dynamic snapshot

A big bottleneck for running EVM and performing initial synchronization is the state model of Ethereum: MPT (Merkle Patricia Trie). Because all the status data is arranged in the form of a tree, accessing any account requires random 6-8 disk searches on the main network. During the fast synchronization process, the same random intermediate trie nodes need to be downloaded one by one to obtain the actual data.

For half a year, we have been actively researching a feature called dynamic state snapshots: in short, it is a flat acceleration structure created on disk, which allows any account or storage slot to work. Load through a disk search. This is similar to Open Ethereum's fatdb scheme, except that it is dynamic: the snapshot mechanism in Geth can update the acceleration structure in real time as the chain progresses (including mini-forks).

One benefit of dynamic snapshots is EVM state reading of size O（1） . Although this sounds like a holy grail, it is not. Most contract execution is not going crazy because of disk reading, so the benefits are limited, and most contracts also perform a large number of write operations, and these operations still need to be pushed into the Merkle-trie tree. However, dynamic snapshots do allow eth_call operations to proceed quickly, and they do make DoS transactions more difficult to complete.

A more interesting feature supported by dynamic snapshots is a new synchronization protocol, which we have tried for two years (originally called leaf sync ), and we are still developing the protocol. If our hunch is correct, it It should speed up the state synchronization of Ethereum.

6, 4 Discovery v5

The initial version of the next-generation discovery protocol has been implemented in Geth, although it has not yet been enabled. Its specifications and implementation are currently very smooth and synchronized with Eth 2.0 requirements, and its use in the final code base will be a huge milestone.

Seven, Javascript team

Author: Holger Drewes and Philipp Langhans

The last quarter was exciting for the team. In early March, we met for the first time offline during the EthCC conference in Paris, which deepened the team relationship and we also discussed some plans for the future.

7, 1 Ethers.js

Ethers v5 will go through the last beta version before final release. Many fixes and usability improvements discussed with the community (such as proper names for API calls) have been applied, which prepares for a stable and robust final version. Notable new features recently added, including WebSocketProvider and EIP-1193 .

7, 2 Web3.js

After serving as the main maintainer of the Web3.js library for more than a year, Samuel decided to start a new adventure (thanks to Samuel for everything! ♥ ️). During the days during the EthCC meeting, we had a great time. Now, the development of the library will be undertaken by other members of the team.

Currently, we will focus on stability. Team members are trying to become familiar with the technology stack and procedures, and Samuel is the first expert on this project. Therefore, regarding the recent addition of new features, please allow us to make a cautious choice. For the same reason, we will not develop on the 2.x branch.

7, 3 EthereumJS

We moved the EthereumJS virtual machine to monorepo and combined structurally related libraries (tx, block, blockchain, HF configuration (common)). This will greatly simplify the future development of virtual machines and allow integration of PR. Based on this new structural foundation, the v5 version of the VM is expected to be released soon, which will bring some breakthrough changes.

Due to the excellent work of dryajov, we now also have an effective TypeScript implementation of the devp2p stack. Relevant official news, we will announce in the near future.

7, 4 Grid

Ethereum Grid is divided into two parts: desktop applications and a core module that provides binary management outside the electronic environment.

The core goal is to provide an engine, which is small in itself, but extensible through plugins. We have implemented the necessary mechanism, which can achieve safe and stable expansion without modifying Grid in the future.

Grid can also be extended with small scripts called workflows. At the EthCC conference, we have demonstrated some Grid workflows.

8. Python Ecosystem (PyEVM / Trinity / Web3.py / Vyper)

Author: Piper Merriam

8. 1 Web3.py

Regarding the Web3.py library, we continue to work on incremental improvements and stability. Due to the contributions of some third parties, we hope to provide initial support for mnemonic phrases and HD accounts in the near future. Although a lot of basic work needs to be done in this regard, we will continue to work hard to provide comprehensive asynchronous support.

8, 2 Trinity

In terms of Ethereum 1.x and Ethereum 2.0, the Trinity client will continue to move forward. In Ethereum 1.x, we continue to work on developing a powerful mainnet client. In the past two years, our biggest work has been to develop "stateless Ethereum" solutions, which will transform the Ethereum mainnet in the next 18-24 months.

8, 3 EthPM

The EthPM team is working with the Solidity team to merge packaging standards so that the compiler can compile the resources in the package, generate a package of compiled resources, and use the EthPM specification for metadata and contract source verification.

Nine, Remix

About Remix, you can check our medium post for more details.

9, 1 Remix IDE-live and desktop applications

1. Full support for major changes and functions of Solidity 0.6.0 has been added to the Solidity plugin;
2. Low-level interaction (Solidity receive and fallback) is now possible;
3. Added light and dark theme, redesigned the UI of Solidity plug-in and Deploy & Run plug-in;
4. The latest Remix plugin engine (v0.2.0) has been successfully integrated into the Remix IDE and remix-emulator (Ethereum dev node in the browser).
5. From now on, the desktop version will be released following Remix live.

9, 2 Remix plugin

1. The latest version provides a websocket plugin, we will add more types soon (Secure Ecmascript, IPC);
2. Integrated development with VScode is currently underway, and hope to achieve it soon;
3. This is the documentation for developing plugins;

9, 3 External plug-ins

1. We support external teams to build plugins and add them to Remix IDE;
2. We have Gitter channel dedicated to Remix plugin. You can join this Gitter channel to recommend your plugin to the community;
3. If you need funds to create your plugin, you can: (1) create a Github question describing what you plan to do, (2) send us an email ([email protected]) with documentation describing the project , Links to Github questions and invoice proposals;
4. We will do our best to contact you and plan the next move;

9, 4 Remix simulator

1. The integration with Remix IDE is basically completed;

9, 5 Remix static analyzer

1. Remix Analyzer moved to typescript and now uses the latest AST (Abstract Syntax Tree);

9, 6 Remix test

We recently released some new features and contacted the Remix community for feedback and received good results. The following are medium posts: Part 1 and Part 2 ;

9, 7 blog posts and reach communities

We have started to push some new content, which will be our focus in the coming months.

9, 8 E2E test

David aka @ ioedeveloper recently joined the team. He is working on E2E testing and Remix IDE development, with the goal of consolidating our release process.

10. Ethereum 1.x research (stateless Ethereum)

Author: Griffin Hotchkiss

A series of upgrades to the existing Ethereum protocol (called Eth1.X) has been merged by researchers into a unified work to achieve and transition to "stateless Ethereum". The upgrade and query topics are not only related to improving the scalability and resilience of the current blockchain, but also related to the engineering and design challenges being solved by the Eth2.0 research team. They are complementary in many ways.

After the EthCC conference in Paris, we also held a stateless Ethereum research summit. Participants believed that this was a groundbreaking conference and had achieved great success in all aspects.

Griffin Ichiba Hotchkiss recorded the latest progress of the stateless Ethereum project in a series of articles called "The 1.X Files". In addition to summarizing the content of the monthly meeting, the series of articles also delved into the developers are studying Core concepts and the way forward.

related articles:

1. Stateless Ethereum technology tree (updated) ;
2. Summary of stateless Ethereum summit content ;
3. The State (lessness) of the Union ;
4. Research and development progress of stateless Ethereum ;

11. Serenity Research (Ethereum 2.0)

Author: Ethernet Square Foundation team

Danny Ryan, Carl Beekhuizen and the Ethereum 2.0 R & D team will regularly publish a series of articles on "Ethereum 2.0 Quick Update" and "Ethereum 2.0 Staking" on the EF blog. For the latest news and progress as we approach the start of Phase 0, please check the latest article below!

11.1 Ethereum 2.0 quick update

1. Ethereum 2.0 quick update no. 8-2020-02-04
2. Ethereum 2.0 quick update no. 9-2020-03-17
3. Ethereum 2.0 quick update no. 10-2020-03-31

11.2 Staking for Ethereum 2.0

1. Ethereum 2.0 staking # 1-incentives-2020-01-13
2. Ethereum 2.0 staking # 2 -2020-02-12
3. Ethereum 2.0 staking # 3-sharding consensus-2020-03-27

Twelve, security and consensus testing

Author: Martin Holst Swende

The health of the Ethereum main network is the top priority. We have investigated and released the EIP and proposed punishment measures for the state Trie's omission.

By the end of 2019, we issued several bounties. ChainSecurity earned another 8,500 points in three separate reports. In early 2020, prolific bug hunter Sam Sun received another 10,000 bounty points for ENS vulnerabilities.

The Go-Evmlab repository has been updated to better integrate with Geth and provide assistance in analyzing chain operations and creating custom evm-fuzzers.

We also conducted two external audits of the upcoming Discovery v5 protocol. This protocol has been implemented in Geth (but not activated).

Consensus test:

The blockchain test generation code was rewritten and migrated to retesteth, and VMTests are now generated in the blockchain test format. The Stats web server is set at http://retesteth.ethdevops.io/

13. Solidity

Author: Franziska Heintel, Daniel Kirchner and Christian Reitwiessner

Since the last update, the Solidity team has released version 0.6.0. In addition to the large number of features that have been announced in our previous articles, it also includes "try / catch" as a high-level syntax for handling external call failures. At the same time, the 0.6 series has stabilized in multiple minor versions, and early planning for the next major version 0.7 has begun (future blog posts will announce the expected features).

In the 0.6 series, a notable new language feature is support for immutable variables. Starting from version 0.6.5, Solidity state variables can be declared as "immutable". Immutable variables can be assigned once during contract creation and can be read cheaply from runtime code. The constructor code will directly insert the specified value of the immutable object into the runtime code during construction, so that the runtime overhead of access is only the overhead of a single PUSH.

Other recent language features include interface inheritance (to be supplemented by the ERC165 interface ID in the near future), optional reason strings for internal restoration, and the ability to allocate storage pointers through inline assembly, the latter Support the construction for writing updatable contracts. In addition, we also introduced the CREATE2 syntax through the new C{salt: }() , and at the same time migrated the gas and value syntax used to set up regular function calls to a similar syntax: cf {value：10 ether}（） .

The current focus of the Solidity team is to extend new code generation with Yul as an intermediate representation. Recent notable additions include external function calls, try / catch, added array support, tuples, and more. On the back-end side, the conversion of Yul code to Ewasm is now complete and is currently waiting for some adjustments to the type, which means that through Yul-IR, a reliable Solidity version will be provided for the Ewasm compiler.

We have also continued to improve the Yul optimizer. The most significant change is the introduction of Yul Phaser, which is a tool that uses a genetic algorithm to find the optimal sequence of optimizer steps. In the future, if you want to spend more Compile more time and get a cheaper contract, you can also use it in a single contract.

Further improvements: solc js is now built on WebAssembly instead of asm.js, which will make compilation faster and improve browser compatibility. JSON AST export is now supplemented by AST import. We will continue to work on source code verification, establish an authenticated ABI through the metadata hash in the bytecode, and the source code collection of deployed smart contracts, and provide a way to retrieve authoritative ABI information from ipfs or other sources Of trustless methods.

13. 1 SMT checker

The SMTChecker module continues to add support for Solidity and improve its verification technology. The new CHC engine now also supports internal function calls and multi-transaction counterexamples (unreleased). We are currently studying support for external functions and, as usual, will support more features of the Solidity language.

13. 2 Solidity Summit!

Finally, we look forward to the online Solidity Summit from April 29th to April 30th.

This is an interactive forum event that will include discussions about Solidity, Yul, language design and tools. We aim to carry out useful discussions to propose improvements and pave the way for practical implementation. In addition, we hope to facilitate communication between teams engaged in similar topics and determine the needs of the Ethereum smart contract ecosystem.

14. ZoKrates

Author: Jacob Eberhardt

Since the last update, the ZoKrates team has designed and released the first version of ZoKrates.js, which is a library for compiling, executing, and proving ZoKrates programs. The bottom layer uses WASM and has been used to power our Remix plugin!

As part of this work, and in order to better support program interaction with ZoKrates, we have developed a new version of ZoKrates ABI.

In order to improve efficiency, we added further optimization techniques in the ZoKrates compiler: memory function calls, detection of unconstrained variables, etc. These optimizations are currently in the review and testing phase, and we hope to present them in the next version.

In addition, local verification (functions normally requested by users) has been implemented as a prototype and is currently undergoing testing.

Finally, the development of introducing unsigned integers in ZoKrates is currently underway. This is particularly useful when using common hash functions (such as SHA256) and implementing internal binary representation algorithms.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!