{"id":7811,"date":"2025-01-27T04:03:40","date_gmt":"2025-01-27T03:03:40","guid":{"rendered":"https:\/\/wsj-crypto.com\/?p=7811"},"modified":"2025-01-27T04:03:40","modified_gmt":"2025-01-27T03:03:40","slug":"innovative-insights-a-progress-report-on-ef-backed-research-development-teams","status":"publish","type":"post","link":"https:\/\/wsj-crypto.com\/index.php\/2025\/01\/27\/innovative-insights-a-progress-report-on-ef-backed-research-development-teams\/","title":{"rendered":"Innovative Insights: A Progress Report on EF-Backed Research & Development Teams"},"content":{"rendered":"\n
\n

Comrades,<\/p>\n

<\/p>\n

Since the previous EF-Supported Teams update, advancements have been observed throughout. From enhanced network conditions to the upcoming Istanbul launch and the development of Eth1.x and Eth2, all critical areas fundamental to the functionality and longevity of Ethereum are progressing.<\/p>\n

<\/p>\n

This edition emphasizes teams and initiatives from the Foundation and the broader Ethereum ecosystem that are striving to expand and enhance Ethereum as a whole. In this issue, we will discuss updates from several teams featured in the prior report<\/a>, fully endorsed projects that are integral components of the Ethereum ecosystem such as Eth2.0 Research, Geth, and Solidity, along with additional ecosystem initiatives.<\/p>\n

<\/p>\n

Have fun!<\/p>\n

<\/p>\n

Aleth \/ C++ Ethereum<\/h2>\n

<\/p>\n

Written by Andrei Maiboroda<\/em><\/p>\n

<\/p>\n

The Aleth group was among those client teams developing the Istanbul upgrade for the Eth1.x chain, and Aleth 1.7.2<\/a> has been released with complete support for Istanbul.<\/p>\n

<\/p>\n

EVM & other consensus<\/h3>\n

<\/p>\n

Key achievements for the evmone project:<\/p>\n

<\/p>\n

Following the initial launch of this experimental rapid EVM implementation, we concentrated on extracting even greater performance from it. The 0.2.0<\/a> version is approximately 66% quicker than its predecessor. Subsequently, the 0.3.0<\/a> release extended evmone’s compatibility with the Istanbul specifications. For those intrigued by the concepts that evmone explores and for further details on optimizing EVM, please refer to the slides from the Optimization techniques for EVM implementations<\/a> presentation at Devcon5, as well as the Efficient gas calculation algorithm for EVM<\/a> article.<\/p>\n

<\/p>\n

The EVMC project (the cross-language API for EVM implementations) has undergone necessary updates incorporating support for Istanbul. All of this is included in the EVMC 7.0.0<\/a> release.<\/p>\n

<\/p>\n

Several improvements have been made in the aleth-interpreter to eliminate unnecessary state access in the execution of certain opcodes. These deficiencies were identified thanks to the excellent EVM test suite provided by evmone project<\/a>.<\/p>\n

<\/p>\n

The aleth-interpreter has also transitioned from utilizing boost::multiprecision to the intx library<\/a>. This signifies a movement towards delivering the aleth-interpreter without a boost dependency, and it has also permitted us to conduct intriguing benchmarks to assess how inadequate the boost implementation of 256-bit integers was for our objectives.<\/p>\n

<\/p>\n

Post-Istanbul, we chose to incorporate several proposed EIPs for the forthcoming hard fork (Berlin): EIP-1380<\/a> Reduced gas expenses for self-calls and EIP-2046<\/a> Reduced gas expenses for static calls made to pre-compiles. These implementations can now be activated in the testeth tool, details below.<\/p>\n

<\/p>\n

Networking<\/h3>\n

<\/p>\n

We have integrated an optimization that has long been utilized by other mainnet clients: immediately disseminating new blocks to peers following the PoW check rather than awaiting full validation and execution. Furthermore, we established a maximum limit on the number of previously discarded transactions retained by the transaction pool (now set to 1024).<\/p>\n

<\/p>\n

The client version reported during devp2p handshake was rectified, thus enabling Aleth’s version to be accurately displayed on ethernodes<\/a>.<\/p>\n

<\/p>\n

RPC<\/h3>\n

<\/p>\n

A series of corrections have been implemented to better align with the input\/output formats utilized in the RPC interfaces of other clients. Numerous methods have experienced a substantial performance enhancement due to a fix that removed unnecessary transaction re-executions. This may be evident in scenarios involving frequent RPC requests, such as when utilizing retesteth<\/a> with aleth.<\/p>\n

<\/p>\n

Database<\/h3>\n

<\/p>\n

Reconstructing the indices from the existing blocks database has been corrected and optimized, allowing for improved optimization and modification of the index database structure in the future.<\/p>\n

<\/p>\n

Testeth tool<\/h3>\n

<\/p>\n

The structure of the consensus tests folder has been reorganized by the testing team, and testeth now accommodates it – all tests addressing fork rules prior to Istanbul are categorized in the LegacyTests suite.<\/p>\n

<\/p>\n

State tests can now be generated and executed using a string format like “ForkName+EIP_number” instead of a traditional fork name in the expect section. This facilitates anyone intending to prototype new EIPs in aleth to create tests for them before the EIP is validated for the fork – this is the fundamental concept behind the EIP-centric forking process<\/a>, which is currently being embraced by the All Core Devs community. As an illustration of this mechanism, the two new EIPs mentioned earlier (EIP-2046 and EIP-1380) can be activated in testeth, and we’ve produced a few state<\/a> tests<\/a> to demonstrate this functionality.<\/p>\n

<\/p>\n

We have also rectified and optimized the functionality of testeth to execute any custom test file (beyond the established consensus test structure) and enhanced its output to be more aligned with the EVM tool of go-ethereum. This enabled us to incorporate testeth into goevmlab<\/a> project, where aleth’s EVM implementation is now partaking in a cross-fuzzing initiative alongside three other prominent clients’ EVMs.<\/p>\n

<\/p>\n

Among other advancements:<\/p>\n


\n<\/p>\n

Ecosystem Support Program<\/h2>\n

<\/p>\n

Written by the ESP Team<\/em><\/p>\n

<\/p>\n

Taiwan-Specific Grants<\/h3>\n

<\/p>\n

We have recently bestowed<\/a> a series of five grants ranging from 2<\/mn>,<\/mo>000<\/mn>\u2212<\/mo><\/mrow>2,000-<\/annotation><\/semantics><\/math><\/span>2<\/span>,<\/span>000<\/span>\u2212<\/span><\/span><\/span><\/span><\/span>5,000 at Crosslink Taipei<\/a>. This represents the latest in a series of locality-focused waves aimed at highlighting the contributions of communities globally.<\/p>\n

<\/p>\n

Increasing Non-Financial Support<\/h3>\n

<\/p>\n

We are persistently broadening our understanding of “support” for initiatives where a traditional grant may not be suitable. Some of the non-financial support we’ve offered includes rounds of feedback with expert advisors, linking teams working on similar projects, AWS credits, invitations to events, and other forms of assistance.<\/p>\n

<\/p>\n

Enhancements to the Website<\/h3>\n

<\/p>\n

Our newly revamped website https:\/\/Ecosystem.Support\/<\/a> is evolving! We began modestly with a FAQ section and modifications to the homepage – we plan to follow this up with a grants showcase and a dedicated blog for regular updates.<\/p>\n

<\/p>\n

We aim to ensure valuable skills are utilized, hence we’ve overhauled our inquiry forms to be somewhat more open-ended, featuring a designated pathway<\/a> for individuals keen on contributing to the ecosystem but uncertain about their role. Feel free to explore and apply!<\/p>\n

<\/p>\n

Ewasm<\/h2>\n

<\/p>\n

Authored by Alex Beregszaszi and Paul Dworzanski<\/em><\/p>\n

<\/p>\n

Since the previous update, the focus of the Ewasm team has transitioned towards research on Eth 2.0, collaborating closely with other teams.<\/p>\n

<\/p>\n

As the launch of Eth 2.0 phase 0 approaches, the development of the phase 2 execution layer is actively ongoing, concurrently with the progression of phases 0 and 1. Multiple proposals have emerged concerning the architecture of phase 2. The Ewasm team has been working on refining designs through prototypes and benchmarks, building upon a minimal base in Scout.<\/p>\n

<\/p>\n

Scout<\/h3>\n

<\/p>\n

The Scout specification<\/a> serves as a minimal interface for EEs (Execution Environments). This simplified interface is sufficient to prototype stateless EEs, which are necessary for validating the stateless model and informing the design of Ewasm and phase 2.<\/p>\n

<\/p>\n

Scout comprises three implementations:<\/p>\n

<\/p>\n