Innovations on the Horizon: Recent Developments from EF-Supported Teams

Friends,

Leaves have descended in the northern hemisphere, summer approaches in the south, and ETH is being staked worldwide. The merriest of seasons has arrived, marking the inception of the beacon chain. Furthermore, phenomenal advancements have occurred recently by all EF-backed teams. However, due to the lack of in-person interactions lately, we may have overlooked much from each other. As this distinctive year comes to a conclusion, we are thrilled to present a plethora of comprehensive updates to you from several teams contributing to the advancement of Ethereum in myriad ways. It’s an extensive read, but there’s a wealth of progress to sift through (or feel free to navigate using the table of contents).

As always, this series of updates centers on EF-supported teams whose members are dedicated to expanding and enhancing Ethereum as a whole. This edition includes updates from numerous teams featured in the prior report, along with other new and rotating groups.

Enjoy!

Applied ZKP

Written by Thore Hildebrandt

The Applied ZKP team endeavors to connect cutting-edge research in zero-knowledge proofs with application development on Ethereum.

Perpetual Powers of Tau

In September 2019, we initiated the Perpetual Powers of Tau ceremony (PPOT). PPOT is designed to support the zero-knowledge ecosystem, especially zk-SNARK projects developed on Ethereum, by alleviating some of the burdens of trusted setup ceremonies. Many zk-SNARK projects necessitate two phases of parameter generation, and PPOT substitutes the first phase, allowing it to be shared among all circuits. Individual teams can select any contribution from the ceremony to carry out their own phase 2 setup.

This ceremony accommodates circuits with up to 2 ^ 28 constraints, which implies that each contribution entails a 97G download, a computation period of one day, and a 49G upload. At the time of writing, we have gathered 63 contributions, and all contribution files can be downloaded and independently verified against a public ceremony transcript.

Initiatives that plan to utilize or have already utilized the ceremony include tornado.cash, Semaphore, Hermez, MACI, and zkopru. The simplest way to contribute is to connect with Wei Jie via Telegram @weijiek. Tune into this podcast to hear Wei Jie discuss the ceremony.

Semaphore

Semaphore is a versatile privacy tool that enables functionalities such as mixers, anonymous login, anonymous voting, and reputation systems.

Semaphore has undergone an audit and is presently conducting a phase 2 ceremony based on Perpetual Powers of Tau. So far, there are 51 participants; please get involved to enhance the security of Semaphore. Join the discussion in the Semaphore Society Telegram chat group.

MACI

Initially proposed by Vitalik Buterin, systems built with MACI hinder collusion among participants while upholding the advantages of censorship resistance and correct execution offered by smart contracts. While MACI can afford collusion resistance only if the coordinator is truthful, a dishonest coordinator cannot either censor or manipulate its execution. Watch Wei Jie explain how MACI functions on Youtube. You can utilize the MACI command-line interface to run a demonstration.

Recently, clr.fund executed a quadratic funding round where results were computed using MACI. Bribery could pose a significant challenge for Gitcoin as it scales, yet MACI can assist as it ensures that it’s impossible to prove whom one voted for. MACI 1.0 is under development; join the Telegram group to discover more and engage in discussions.

MiMC Bounty

There is a current bounty for locating collisions in the MiMC hash function.

Hubble

Optimistic Rollups (OR) facilitate enhanced layer 2 scalability by leveraging on-chain data availability and fraud proofs. Hubble enables the formation of optimistic rollup chains with a uniform interface, allowing individuals to enter the rollup space once and subsequently transition between chains seamlessly at minimal costs, thereby eliminating the necessity to ever “exit” the low-cost rollup environment.

Key attributes encompass bulk migrations and a global account registry. Burnauctions will be utilized to decentralize the coordinator and to allocate MEV to CLR’s. Transfers to novel accounts are feasible directly from L2 without the necessity to deposit on L1. With the assistance of BLS signatures, the team succeeded in achieving 2500 tps on ropsten. The Hubble BLS wallet is designed to accommodate other OR’s such as Arbitrum, Optimism, and Fuel.

Hubble’s source code can be found on Github. Contracts are currently on hold, as the team prepares for an impending audit.

zkopru

zkopru (zk-optimistic-rollup) serves as a layer-2 scaling solution for confidential transactions utilizing zk-SNARK and optimistic rollup. It facilitates private transfers and atomic swaps within the layer-2 ecosystem between ETH, ERC20, and ERC721 at minimal expense. Additionally, it offers instant withdrawals with pay-in-advance features and compliance compatibility employing spending key and viewing keys. Wanseob showcased the system at zk-summit, with the recording to be made available on Youtube shortly.
zkopru is advancing into the “Burrito” phase of its roadmap, and you can currently experiment on testnet right now. Furthermore, the UI for its trusted setup and burn auction aimed at the decentralized coordination are in development. An audit is slated to commence in January.

Experimental directions

• Blind Find – a p2p network that empowers users to locate others without disclosing their identity. Following a successful search, the individual can validate that the search route exists in the network using an MPC-based construction, without revealing the route itself. For further details and discussions, please join the telegram group.
• UniRep – a confidential and non-repudiable reputation system. Users can acquire positive and negative reputation from attesters and voluntarily verify that they possess at least a certain threshold of reputation without disclosing the precise amount. Moreover, users cannot decline to accept reputation from an attester. Join the telegram channel to delve deeper and discuss!
• PeekABook – a confidential order matching system on Ethereum. It permits users to announce and search for trade orders without exposing the order price. Explore the demo. Engage in discussions by joining the telegram group.

Ecosystem Support Program

Authored by ESP Team

Delivering support

The ESP team is continuously searching for innovative ways to assist and inspire the numerous fantastic builders within the Ethereum ecosystem. We spotlighted a few teams that received support beyond traditional grants in this article.

Meanwhile, nearly $6.3 million in grants have been distributed in Q2-Q3; discover more about the 50+ beneficiaries in our Q2 and Q3 allocation updates, and stay tuned for a Q4 publication in the upcoming year!

Outreach and communication

We have endeavored to offer more resources for teams seeking support, as well as for Ethereum community members who wish to stay informed about what we’re backing.

• Events: we’ve actively engaged in (virtual) meetups and hackathons to connect in real-time with builders, disseminate information about ESP, and assist in addressing any inquiries or concerns.
• Guide to ESP: this newly established section of our website elaborates on the ESP inquiry and grant proposal process
• Expanded blogging: We’ve regularly published updates regarding newly awarded grants throughout the year, but what these teams accomplish with their grant funding is the real narrative! In November, we released the inaugural post in a new blog series aimed at highlighting grantees’ ongoing achievements.

Eth2 Research

Authored by Danny Ryan

December 1st signified the initiation of the eth2 beacon chain. This marked the bootstrap of Ethereum’s proof of stake consensus that will eventually serve as Ethereum’s new consensus foundation.

Looking beyond the launch of the beacon chain, the eth2 research group is focusing on the upcoming set of enhancements to eth2 — native light client support, the integration of eth1 into eth2, and scalable sharded data.

For the latest updates from our team, stay informed with the ‘eth2 quick updates’ on the EF blog. A few recent issues can be viewed here: #21, #20, #19.

ethereum.org

Authored by Ryan Cordell

The ethereum.org crew dedicated the latter half of 2020 to enhancing our expanding portal of Ethereum resources with additional content and features.

Onboarding

Since we frequently serve as the initial source users encounter when searching for “Ethereum” for the first time, considerable effort has been directed towards enriching the content that aids you in getting started.

Eth2

As we approached the launch of the deposit contract, Eth2 dominated headlines and occupied our backlog. It’s evidently been a priority for our users, as over the past month, traffic to our Eth2 pages has exceeded even the homepage visits.

Developers

Moreover, our other primary focus in the final months of 2020 was to enhance our developer content, thereby providing users with a reliable source of information to get initiated. While it remains a work-in-progress, we have successfully developed: ]

Post some user testing, we have amassed numerous ideas to better these aspects as we transition into the new year.

Translations

The latter part of 2020 proved to be monumental for broadening our outreach into various languages. During this time, our translator community has enriched content in:

You can explore all 33 languages now supported at ethereum.org/en/languages and discover how to join translation initiatives.

---

We can’t cover every detail, so please check out ethereum.org and our previous updates to see the other projects we’ve undertaken since your last visit.

As always, if you wish to contribute in any capacity, drop by our Discord or submit an issue/PR on GitHub.

Ewasm

Authored by Alex Beregszaszi, Paweł Bylica, and Sina Mahmoodi

As mentioned in the previous update, we have continued to engage in research concerning Eth1, Eth1.x, and Eth2.0 related subjects.

Eth1

EVM384

A primary motivating factor behind our work to identify performance constraints of various virtual machine configurations (EVM and WebAssembly) and their implementations is to enhance execution speed within Ethereum. Previously noted in a prior update, we successfully enhanced WebAssembly for efficient execution of the elliptic curve pairing operation.

In the past six months, we embarked on the EVM384 project aiming to achieve similar scalability on EVM. Initially, it started as a small proof of concept, but we have since published a detailed explanation and several updates (2, 3, and 4) throughout this process. In these updates, we present:

• an overview of the precompile issue,
• three new EVM opcodes designed for efficient 384-bit calculations,
• various design options for EVM384,
• a comparison between the languages Yul and Huff,
• and an implementation of the pairing operation over the BLS12-381 curve using the introduced opcodes.

You can keep up with updates regarding EVM384 on the relevant EthMagicians topic.

EVM subroutines

The team conducted an analysis and proposed substantial modifications to EIP-2315 “Simple Subroutines for the EVM”. The discussions that followed emphasized potential risks and possibilities, leading us to further investigate JUMPDEST analysis methods. The result of this investigation is the baseline interpreter as elaborated on subsequently.

evmone

According to our benchmarks, evmone is a remarkably fast EVM interpreter. A notable strength of evmone lies in its thorough bytecode analysis, which facilitates pre-computation of gas costs and checking stack requirements. Nevertheless, this also can lead tobe a drawback or weakness.

A fresh version of evmone referred to as the “baseline interpreter” has been developed as part of the initiative. The aim is to assess a significantly more straightforward interpreter architecture to prevent analysis weaknesses and potentially challenge the efficiency advantages of analysis. While this design is not yet field-tested, it successfully passes all of evmone’s unit tests, the Ethereum State Tests, and Solidity’s testing framework.

Unexpectedly, this simplistic design operates exceptionally well. In terms of “average” contracts, the performance variation between the baseline and the “advanced” evmone is minimal; however, on computation-heavy EVM bytecode, the “advanced” evmone can execute up to 40% more quickly.

The TurboGeth team has initiated the Silkworm project, which incorporates evmone as the EVM implementation. Additionally, they have suggested several intriguing modifications to evmone and EVMC.

EVMC

Three new iterations of EVMC have been launched: 7.2.0, 7.3.0, and 7.4.0. These releases brought various enhancements for C++, Go, and Java language compatibility, along with improvements to tooling.

Recently, the Java support has garnered significant attention due to its incorporation into Apache Tuweni. For a compilation of related modifications and dialogues, see here.

Recently, EVMC support has been adopted by several projects, including TurboGeth, Silkworm, and Second State’s SSVM.

Eth1.x / Stateless Ethereum

Within the Stateless Ethereum framework, we have engaged in numerous initiatives.

Code merkleization

Following the preliminary feasibility studies on code merkleization mentioned in the last update, we introduced EIP-2926 and implemented the specification in geth and a standalone tool in Python. Additional experiments have been conducted, including employing SSZ for merkleization and analyzing performance overheads, which can be found in the discussion thread.

Witness format

With leadership from Paul, the team has engaged in specifying and refining the witness format. The format has been implemented in Python as well as Javascript. The Python implementation has also been used to generate tests for the format.

Binarification

We have also closely monitored the binarification initiative and contributed to the design discussion. Our intention is to ensure that the design integrates seamlessly with other components of a stateless Ethereum. To achieve this, we have sought to align the code merkleization proposal with the binarification efforts.

ReGenesis

Previously, we advocated for a state cache to lessen (stateless) witness sizes within Eth2.0 Phase 2. Therefore, we view ReGenesis as an encouraging avenue. To facilitate the dialogue, Paul released an early work-in-progress version of a formal specification for a potential version of ReGenesis. The specification adheres to the notation introduced by the Yellow Paper.

Light-client sync

Light clients face limitations due to the volume of data they “retrieve” from altruistic servers. We believe that techniques initially developed for Stateless Ethereum, combined with a commitment to chain history, can alleviate pressure on the servers. As an initial step towards this goal, we have evaluated methods that minimize bandwidth needs for synchronizing the header chain. A commitment to the chain history could also be beneficial in contexts (such as ReGenesis) beyond…of illumination client synchronization.

Eth2.0

Deposit agreement

Our group spearheaded the Solidity revision of the deposit agreement, which successfully underwent audit and validation, and was integrated as a component of the Eth2.0 specification.

The validation report highlights an advantage of the revision:

In spite of the added runtime checks, the Solidity implementation is more gas-efficient (30~40% lower gas cost) than the initial Vyper execution, due to the sophisticated code optimization offered by the Solidity compiler.

Eth1x64

In the preceding update, we detailed our efforts on Eth2 Phase 2 and presented Eth1x64 as a notion.

The initial variant of Eth1x64, referred to as Apostille, defines a minimally intrusive extension to Eth1 and EVM. This extension facilitates contracts on the Eth1 chain to interact with other execution shards on Eth2.

The experiment illustrates a scenario where all 64 shards of Eth2 are uniform and executing the EVM, allowing for inter-shard communication. Moreover, the techniques introduced can be (re)utilized in the context of the Eth1-Eth2 integration.

Fizzy

Fizzy aims to be a swift, deterministic, and meticulous WebAssembly interpreter crafted in C++.

The four primary objectives of Fizzy are:

1. high code excellence and clarity
2. strict adherence to specifications
3. effectiveness
4. first-rate support for deterministic applications

Since April remarkable advancements have been achieved, with three out of four major goals already accomplished.

In comparison to other interpreters, we have intentionally limited the focus to WebAssembly 1.0, refrained from implementing any pending proposals, and resisted the temptation to create an all-inclusive library. Fizzy exclusively supports the canonical binary representation (.wasm) of WebAssembly and does not accommodate the text formats (.wat/.wast). This has enabled us to maintain simplicity and clarity in our code.

The meticulous compliance with the specification, together with comprehensive utilization of static analyzers and fuzz testing, allowed us to identify gaps in test coverage within the specification, and upstream issues in wabt and wasm3.

Although enhancing execution speed was not the primary goal, we remained aware of design choices influencing it. This has enabled Fizzy to become the second fastest interpreter available, surpassing our previous preference wabt.

Fizzy in figures:

• 5 significant releases
• ~2300 lines of well-annotated modern C++17 code
• an additional ~7300 lines of unit tests
• 99.96% code coverage
• 100% “spectest” success rate (the official WebAssembly test suite)
• the second fastest WebAssembly interpreter

We are preparing for the upcoming 0.6.0 release which will unveil a public C and Rust API, as well as provide support for WASI, enabling a wide array of applications to be executed.

Subsequently, our efforts will shift towards blockchain-specific behaviors (efficient metering) and ongoing upstream contributions to ensure specification conformance.

Formal Verification

Authored by Leo Alt, Martin Lundfall, David Terry

Act

Act 0.1 is nearing release. It is evolving as a language, and substantial effort has gone into tooling for Act over recent months, as planned:

• SMT backend. Inductive high-level properties such as contract invariants and post conditions articulated in Act can be proven automatically using the Act SMT backend. The properties are expressed as inductive theorems utilizing the requisite SMT theories and are provided to an SMT solver. This functionality enables users to validate properties in a straightforward, simple, and standalone manner, segregated from the bytecode. The SMT backend presumes that the contract’s bytecode“`html
  is accurately depicted by the storage modifications outlined in the specification. To validate this, you may employ the
• Hevm backend. Hevm currently possesses symbolic execution capabilities, which are now completely embedded into Act. Given an Act specification and the compiled bytecode, it will automatically verify whether the storage updates specified in the documentation correspond to the actions performed by the bytecode.
• Coq backend. Similar to the SMT backend, this functionality is beneficial for demonstrating inductive high-level attributes independently. SMT solvers are automatic and swift, but they cannot address every issue. Some challenges necessitate enhanced expressiveness, which is where the Coq backend comes in. It produces Coq definitions and theorems, allowing users to utilize the Coq proof assistant for validating high-level properties.

Hevm

Hevm’s symbolic execution capabilities were detailed earlier this year, and here’s an overview of the features introduced since the previous update:

• Symbolic execution. As described in the prior blog post, hevm is now equipped to analyze the various execution pathways of a smart contract, holding one or more variables in an abstract state. The resultant post conditions can be assessed for assertion violations or against a specified requirement. State can be retrieved from an rpc node or retained completely abstract. The execution trace tree can be navigated interactively in a debugger interface.
• Equivalence checking. hevm equivalence performs symbolic execution on two smart contracts and contrasts all resultant terminal states. This is particularly advantageous for verifying the safety of compiler optimizations or comparing various implementations of contracts that exhibit the same semantics.
• Decompilation of smart contracts. Initial strides have been made towards creating a symbolic decompiler. Executing hevm symbolic with the flag –show-tree presents a summary of the reachable terminal states, their path conditions, and the state modifications made. While this feature is still in its preliminary phase, the objective is to generate a set of act specifications from EVM bytecode, which could subsequently be employed to further analyze the behavior of the smart contract.
• DSTest integration. hevm’s symbolic execution abilities have been assimilated with the dapp testing framework. This implies that you can now compose properties and formally validate them in Solidity just as you would write tests! There is much more to elaborate on here, and we are preparing a detailed blog post on the subject.

SMTChecker

Numerous significant features have been incorporated into the SMTChecker since the last update, including:

• Extensive language support. The SMTChecker is now nearly capable of analyzing any syntax except for 1) certain language features that are infrequently utilized, such as function pointers and complex memory/storage aliasing; and 2) aspects that are too challenging to maintain an efficiently reasonable representation in the SMT domain, such as ABI encoding/decoding and hash functions.
• External calls to unknown code. This is a crucial enhancement! The SMTChecker’s Constrained Horn Clauses (CHC) engine abstracts external calls to untrusted contracts as an indefinite number of nondeterministic calls to the analyzed contract. By utilizing this abstraction, the CHC engine can accurately determine the state alterations that may or may not occur through this external call, enabling it to retain previously inferred inductive invariants and/or derive new ones. This allows the tool to automatically prove and identify invariants about more intricate properties that involve external calls and potential reentrancy. This also significantly diminishes the number of false positives caused by external calls.
• Multi-transaction counterexamples. Another major improvement! The CHC engine now presents the complete transaction trail from the contract’s constructor to the function triggering the verification condition. It additionally includes actual values for the function’s arguments and state variables, where relevant, for value types and arrays. Upcoming features include reporting actual values for structs and detailing reentrant calls in the transaction trace.
• Enhanced control and user experience. The user can now separately select which engine should be activated, whether it be BMC (Bounded Model Checker), CHC, or both. Additionally, a timeout in milliseconds can be set and applied to each request. This makes achieving fully deterministic reruns difficult, but is advantageous when attempting to validate complex properties that may require additional time.

Geth

Written by Péter Szilágyi

The Geth team’s main emphasis in recent months has been on establishing a foundation for several features we are progressively launching in the upcoming weeks and towards Eth1-Eth2 interoperability:

• One feature we’ve been operating ourselves for most of the year but have been delaying releasing to everyone is the snapshotter, which permits the storage of the Ethereum state in a flat format within the database. Although the primary functionality performed well, we dedicated a substantial amount of time developing various recovery features so that crashes and desynchronizations with the state trie can be managed effectively. You can already execute your node with –snapshot, but as it is consensus critical, we will only enable it by default in our upcoming major release, scheduled for early January.
• The main aim of the snapshotter was to facilitate snap sync, a successor to fast- and warp sync, boasting the advantages of both while mitigating their disadvantages. The protocol was entirely specified and published over the past few months in the
  “`devp2p repository, which contains a complete production implementation awaiting integration into the Geth repository. As a preview, the metrics from our recent benchmark: network packets decreased by 5(!) orders of magnitude, while disk IO and upload improved by 2 orders of magnitude. 5x quicker synchronization, 2x reduced download.
• A significant weakness of Geth since its launch has been the fact that once data was stored in the database, we never removed it. Over the long term, our disk usage consistently increased and became bloated with obsolete states from ancient blocks. The rapid iteration capability of the snapshotter gives us a remarkable opportunity to create a straightforward state pruner. While we won’t enable it as an ongoing process within Geth shortly, you’ll have the option to prune your database offline using geth snapshot prune-state, which should conclude within a few hours.
• In a more experimental domain, we’ve been exploring the feasibility of substituting the existing hexary state trie with a binary one, aimed at notably decreasing witness sizes (in a stateless direction) and light client proofs. Moreover, binary tries could also assist in alleviating some of the code complexity for new clients that aspire to join the Ethereum network solely from a forthcoming block, disregarding the chain history tied to the hexary tries. Completing this work is still a distant goal, as this is akin to performing open-heart surgery on Ethereum.
• With the Eth2 beacon chain now operational, we’ve been developing a potential integration of the current Ethereum chain into a shard of the beacon chain, which would consequently allow for the operation of arbitrary EVM shards on Eth2. Several components are still lacking for it to be production-ready (primarily requiring a new synchronization model, though no new protocols), yet a prototype Geth EVM shard atop Eth2 has already been demonstrated.
• We’ve come to understand that – at this point – most clients do not prioritize enhancements to network protocols, even though Geth has defined (ACD approved) and deployed quite a few recently. This situation is problematic, as it stops us from deprecating older protocol versions, leading to fragility in our code. While executing these modifications isn’t difficult, validating them is, which seems to be the main reason why other clients are hesitant to pursue it. To alleviate some of the workload, we initiated the development of a protocol tester to validate an arbitrary client’s implementations of the discovery protocol, devp2p, and higher-level overlays (eth, snap, etc).
• In a similar manner to the aforementioned protocol tester, considerable effort has been dedicated to updating hive to align with new clients and testing suites. We hope that other clients will also start contributing tests to validate each other’s code and that soon Eth2 clients will also participate in a collective effort to ensure network stability.
• Geth has implemented and operated 2 testnets for the upcoming Berlin hard fork (YOLO v1 and v2), with the 3rd one presently being prepared once all proposed EIPs are reasonably finalized. This also suggests that we’ve invested substantial time in implementing and delivering the various EIPs that will constitute the Berlin hard fork. Progress on this front is quite irregular, as the EIP process is not the most efficient and the proposals undergo significant evolution, but we remain optimistic that all details will be finalized promptly to launch YOLOv3 and subsequently Berlin.
• For a comprehensive list of security enhancements in Geth – in order to avoid repeating the same items multiple times – kindly refer to the Security section a little further down authored by Martin Holst Swende.

JavaScript Team

Authored by Holger Drewes

The JavaScript team has just released its major EthereumJS VM v5, which comprises six significant version releases:

VM v5 is the first fully-featured JavaScript EVM available with backports for all hard forks from genesis. It also includes dedicated support for EIPs, moving away from a hard fork-centric VM. These new library versions finalize our transition to TypeScript and all now offer a modern JS Promise-based API. Additionally, essential refactoring has been performed on the block and tx libraries to eliminate technical debt. More information about the release can be found in the blog post on the EF blog, which discusses things in much greater detail.

These new releases provide a foundation for us to concentrate more effectively on protocol research and development. Our @ethereumjs/client, which we have recently integrated into our monorepo, will assume a pivotal role. Building upon the new VM, Common, and Blockchain release versions allows us to finalize a conceptually straightforward full-sync implementation on the client and initiate collaborative development on developer testnets like the Yolo or EIP-1559 test networks. The client is far from mainnet readiness but will greatly assist us in various development and research contexts.

Development on Ethers continues, with @ricmoo having executed 23 (!) minor feature and bug fix releases since the significant “`html
v5 release in June 2020 (refer to earlier beta release notes for the complete overview). Significant enhancements include the added capability for EIP-712 signed typed data in v5.0.18 and new ENS resolver methods for contentHash in v5.0.10, alongside numerous minor corrections and enhancements introduced. Considerable effort has also been made on Ethers to guarantee it continues to be a dependable infrastructure element within the extensive ecosystem it is utilized. An illustration here is the work done to bolster Alchemy and Infura provider support: refer to v5.0.6 and the following releases. Check this blog post for a more detailed review of the recent highlights.

Remix

Written by Yann Levreau & Rob Stupay

Over the last 6 months, the Remix Project has experienced a substantial amount of development. We’ve enhanced the functionality, the caliber of the codebase, and the IDE’s compatibility with other projects. Additionally, we have been preparing for subsequent versions of the IDE. Nevertheless, the sum of our programming efforts would be insignificant if we did not connect to educate new users, collaborate with other organizations, and expand our community. Therefore, we did!

Remix IDE is utilized by both newcomers to Ethereum and seasoned developers. We have strengthened the tool for both categories of users. We have also been working to enhance the Developer Experience (DevX) for those creating plugins for the IDE while ensuring their plugins retain a polished appearance and function reliably.

Significant alterations are on the horizon for Remix. Currently, the IDE employs the yoyo framework, which is no longer supported. Thus, we are progressing and have initiated the transition to React and Theia – a framework designed specifically for developing IDEs. Additionally, we have completed the first version of a Remix plugin for VSCode.

For detailed information about the updates, refer to our blog post on the past six months.

Snake Charmers [Python Ecosystem: PyEVM/Trinity/Web3.py/Vyper]

Written by Piper Merriam

• Fe-Lang, a novel smart contract language, is under active development.
  
  • The language initially emerged as a rewrite of the Vyper compiler (in Rust) but has since taken its own direction. Additional details regarding the background and objectives can be found in the official announcement article.
  • We are on schedule to have a functional ERC-20 implementation in Fe before the year’s end. To clarify, the compiler will not yet be advisable for production use as an ERC20 by that time, but we anticipate showcasing Fe’s capabilities with such a well-understood working example.
  • Further information can be found at https://fe.ethereum.org/ as well as our latest development update.

• The Trinity team is concluding development on the Trinity Ethereum client to concentrate on more significant issues with the core protocols.
• We are commencing work to establish a DHT-based network for more efficiently serving the chain history, along with ongoing research on how to address on-demand state availability. The project is progressing under the name “Alexandria”. Learn more in our recent development updates.
• The Web3.py team maintains focus on the library’s stability, which has matured well over the recent years. Looking ahead, we are still progressing toward implementing native async support. Additionally, we are working to expose the Eth2 beacon chain APIs.

Stateless Ethereum

Written by Piper Merriam

The “Stateless Ethereum” initiative is ongoing. During our recent call in early November, we assessed the roadmap and objectives. Teams are actively working on converting the main Ethereum state trie from its existing hexary format to a new binary format, alongside modifications to introduce a merklization layer for how contract code is stored. These two modifications are expected to significantly reduce witness sizes. Re-genesis is also under ongoing research as it offers substantial benefits to client developers, enabling them to eliminate outdated fork rules from their codebases while facilitating an incremental path towards complete statelessness.

Security [Security / Consensus Tests]

Written by Martin Holst Swende

• We have started conducting bi-weekly cross-client fuzzing calls among client developers, where we have been refining the practicalities of evm-based fuzzing, working towards consensus on formats and chain definitions. We have executed approximately 100K fuzzed test cases focusing on YOLOv2, specifically EIP-2929, among Geth, OE, and Besu.
• Additional enhancements and expansions to Hive (https://hivetests.ethdevops.io), aimed at increasing the protocol testing capabilities and covering a broader range of the ETH/63 protocol. We are also working on improving documentation and APIs, making it easier for other eth1 teams to integrate/use for testing, and creating
  “`it feasible to utilize for eth2 clients in the future.
• Go-ethereum has recently joined OSS-Fuzz, which led to the discovery of a bug in the upstream Go-lang. Since the incorporation, we have further enhanced and widened the fuzzing targets.
• Currently in progress, we aim to implement a(n optional) vulnerability-check within Geth, fetching data from a vulnerability-feed that can verify if the client is impacted by any established vulnerability.
• The forkmon (https://forkmon.ethdevops.io) has been developed, now connecting 17 public and/or nodes. It serves as a dashboard for visualizing
  
  • if different clients are agreeing on the head block
  • if not, where the discord (fork) initiated
  • whether any specific client has become unresponsive

• Additionally, we have broadened the range of in-house clients utilized for monitoring the Mainnet, now comprising Geth, Besu, Nethermind, and OpenEthereum.

Solidity

Conceived by Franziska Heintel and Christian Reitwiessner

At the end of July, Solidity v0.7.0 was launched. You can discover a comprehensive list of all breaking changes here.

With the impending release of Solidity 0.8.0, we sought to experiment with a novel format to present the implementation specifics and alterations of breaking releases to you ahead of time. Consequently, we released a preview version. The preview release post comprises 0.8.x test binaries along with a thorough explanation of the forthcoming “Checked Arithmetic” feature (farewell SafeMath!) with its three sub-features. We anticipate that you will find these types of preview releases beneficial and welcome your feedback on the implementation of the breaking changes. Furthermore, as usual, if you’re keen on discussing language design with us, be sure to join the solidity-users mailing list!

Currently, the Solidity team is focused on the final aspects to incorporate into Solidity 0.8. Most importantly, the addition of overflow checks for arithmetic operations and enabling ABI coder V2 by default. Refer above for the preview release!

Another significant task, which is also approaching completion, involves utilizing Yul as an intermediary language in the compiler. For this purpose, we have re-implemented the majority of the code generator. You can test it by utilizing solc –experimental-via-ir or solc –ir and solc –ir-optimized –optimize. The intention behind employing Yul is to make the compiler more transparent, allowing you to actually read and comprehend the code it produces. Moreover, it presents more avenues for optimization and you may soon bid farewell to “stack too deep” errors!
Concerning features, we wish to alter the Solidity language to accommodate more items at the file-level, enabling you to better structure your code and incorporate well-isolated helper functions.
Lastly, with the introduction of error codes, you will soon possess the capability to mark issues that are comprehensible to the user while simultaneously consuming little gas.
And then there’s the language server…

Solidity Summit

The inaugural Solidity Summit occurred online on April 29-30, 2020, featuring discussions and presentations on Solidity, Yul, language design, and tools. The event stimulated conversations surrounding language design and enhancement while aiming to promote communication between teams working on related subjects. Additionally, the objective was to identify the requirements for the Ethereum smart contract environment. With abundant content and presentations for a comprehensive agenda over two days, it was a considerable success. The conference included 23 presentations and 13 open discussion sessions. To gather more information, view the recap of the event or watch the recordings of all sessions online in this playlist. We intend to organize more Solidity Summits in the future and will keep you informed regarding the when and how.

Solidity Language Portal & Domains

In October, we were thrilled to announce the unveiling of the Solidity language portal, a central hub for all essential links and high-level information regarding Solidity. Alongside the launch of this portal, we organized the domains and migrated the majority of the Solidity pages under the new soliditylang.org domain umbrella.
We have recently changed the hosting of the static builds, which are now accessible at binaries.soliditylang.org. While the transition should have been smooth for most users, please ensure to update if you are still utilizing https://ethereum.github.io/solc-bin/.

Solidity Underhanded Contest

During October, we hosted a new version of the Solidity Underhanded Contest. The purpose of the contest is to raise awareness regarding smart contract security and unveil language design flaws by authoring seemingly innocent-lookingSolidity code that contains harmful actions or hidden exploits. Submissions ended on October 31st, and we are excited to announce the winners in the following days!

Sourcify

Apart from the primary update, the Solidity team has been focusing on a project named Sourcify (previously referred to as source-verify) for some time now. Sourcify serves as a contract verification platform and metadata repository, with the objective of enhancing the safety and clarity of interactions with smart contracts on the blockchain for its users. To reach this objective, Sourcify actively supports various initiatives to promote the adoption of open-source contract verification, metadata files, and NatSpec annotations.

At its essence, Sourcify currently manages

Finally, we celebrated the 5th anniversary of Solidity version 0.1.0 with a nostalgic look back, insights on over 5 years of language evolution, and a brief glimpse into the future.

ZKP Research

Written by Dmitry Khovratovich, Mary Maller and Dankrad Feist

Enhancing STARK-based VDFs

The concept is to demonstrate a lengthy incompressible iteration utilizing a zkSTARK (Ben-Sasson et al). We proposed a new iterative design with improved efficiency and security compared to the Starkware proposal Veedo. This latest design minimizes arithmetic operations per step and lowers hardware requirements. Additionally, our analysis included:

• How time-memory tradeoffs can influence the construction and proposed secure parameters.
• Quantum threats on the function and quantum enhancements to tradeoff techniques.

Creating a more robust hash function for ZK applications

Existing ZK-friendly hash functions are overly reliant on algebraic attacks. However, the proof system UltraPLONK (which integrates the Plookup structure with PLONK) introduces a lookup table (similar to an AES S-box) as a rapid operation.
We illustrate how to merge lookups with field operations to enhance speed in both proofs and standard hashing.
The security is significantly grounded in conventional cryptanalysis rather than (less understood) Groebner basis attacks.

Innovative protocol for Single Secret Leader Election (SSLE) that can be utilized in Eth2

The consensus protocol in Eth2 operates on a leader basis. Consequently, a leader is appointed for each shard, who is tasked with proposing blocks and facilitating progress. This setup means a nefarious entity could theoretically disrupt the entire network simply by DDOSing the chosen leader. We have formulated a protective strategy against such attacks based on a Single Secret Leader Election (SSLE) proposed by Boneh and others.

The SSLE guarantees that the only individual aware of the leader’s identity is the leader themself. The leader discloses their identity solely when proposing a block, which means our malicious entity cannot determine whom to target. The SSLE is executed by shuffling encryptions in zero-knowledge. We have devised a shuffle argument inspired by Bayer and Groth’s work, but applying more contemporary inner product arguments to enhance efficiency. The argument is swift enough to fit within the Eth2 framework and does not necessitate a trusted setup. It is still pending formal audit.

ZoKrates

Written by Jacob Eberhardt

We’ve been diligently working since our previous update and are excited to unveil various new features and enhancements today.
During the last few months, we have expanded the ZoKrates language and compiler, added a new backend, and improved our documentation to make zkSNARKs more accessible to Ethereum developers.

We have extended support for unsigned integers with additional operators and performance enhancements. This allowed us to rewrite significant standard library functions, like SHA256, completely in our DSL instead of relying on imports of pre-optimized circuits for efficiency.

To elevate usability and developer experience, we integrated syntax highlighting into the ZoKrates Remix plugin, expanded input validation, and enabled user-friendly input forms for complex data types.

As foundational work for the incorporation of new proving schemes and recursive proof composition, we included support for the Arkworks zkSNARK libraries as an extra backend (this library was named ZEXE until very recently). We express our gratitude to the EY Blockchain R&D team for their significant contributions in this regard!
Building upon that, we are currently making strides towards enabling recursive zkSNARK composition within the ZoKrates toolkit.

In addition to the typical documentation updates to illustrate new features and modifications, we have included a new tutorial aimed at assisting newcomers.

We’ll conclude with a brief teaser: We are nearing the completion of support for generic ZoKrates programs that depend on compile-time constants. This will greatly enhance code reusability and simplify the usage of our standard library. Stay tuned.