{"id":18403,"date":"2026-03-18T04:46:14","date_gmt":"2026-03-18T04:46:14","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/18\/ef-supported-teams-research-development-update-4\/"},"modified":"2026-03-18T04:46:14","modified_gmt":"2026-03-18T04:46:14","slug":"ef-supported-teams-research-development-update-4","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/18\/ef-supported-teams-research-development-update-4\/","title":{"rendered":"EF-Supported Teams: Research & Development Update"},"content":{"rendered":"


\n
<\/p>\n

\n

Friends,<\/p>\n

Since the last EF-Supported Teams report, progress has been made across the board. From improved network conditions, to the coming Istanbul release and Eth1.x and Eth2 development, all areas core to the functionality and sustainability of Ethereum are advancing.<\/p>\n

This series focuses on teams and efforts from the Foundation and larger Ethereum ecosystem that are working to grow and improve Ethereum as a whole. In this edition, we’re covering updates from many teams highlighted in the previous report<\/a>, fully supported projects that are core elements of the Ethereum ecosystem like Eth2.0 Research, Geth and Solidity, and other ecosystem efforts.<\/p>\n

Enjoy!<\/p>\n

<\/g><\/svg><\/a>Aleth \/ C++ Ethereum<\/h2>\n

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

The Aleth team was one of the client teams working on Istanbul upgrade to the Eth1.x chain, and Aleth 1.7.2<\/a> was released with full support for Istanbul.<\/p>\n

<\/g><\/svg><\/a>EVM & other consensus<\/h3>\n

Important milestones for the evmone project:<\/p>\n

After the initial release of this experimental fast EVM implementation, we focused on squeezing even more performance out of it. The 0.2.0<\/a> release is ~66% faster than the previous one. Following this, the 0.3.0<\/a> release brought evmone to compatibility with the Istanbul spec. For those more interested in the concepts evmone tries to explore and for more information about optimizing EVM, please see the slides from the Optimization techniques for EVM implementations<\/a> Devcon5 presentation and the Efficient gas calculation algorithm for EVM<\/a> article.<\/p>\n

The EVMC project (the cross-language API for EVM implementations) has received required updates with support for Istanbul. All this is packaged as the EVMC 7.0.0<\/a> release.<\/p>\n

There were a number of optimizations in the aleth-interpreter to get rid of unnecessary state access in the implementation of some opcodes. These inefficiencies become apparent thanks to the great EVM test suite provided by evmone project<\/a>.<\/p>\n

The aleth-interpreter also switched from using boost::multiprecision to intx library<\/a>. This is a step towards shipping aleth-interpreter without boost dependency, but also allowed to do some interesting benchmarks to see how inefficient boost implementation of 256-bit integer was for our needs.<\/p>\n

After Istanbul, we opted to implement a couple of EIPs proposed for the future hard fork (Berlin): EIP-1380<\/a> Reduced gas cost for call to self and EIP-2046<\/a> Reduced gas cost for static calls made to pre-compiles. These implementations now can be activated in the testeth tool, see below<\/p>\n

<\/g><\/svg><\/a>Networking<\/h3>\n

We have implemented an optimization that has for a while been adopted by other mainnet clients: propagating new blocks to peers immediately after PoW check instead of waiting for a full validation and execution. We’ve also set a cap on the number of previously dropped transactions that are remembered by the transaction pool (now it’s 1024 such transactions).<\/p>\n

The client version reported during devp2p handshake was fixed, and allowed Aleth’s version to be correctly shown on ethernodes<\/a>.<\/p>\n

<\/g><\/svg><\/a>RPC<\/h3>\n

We’ve made a number of fixes to better conform to input\/output formats used in RPC interfaces of other clients. Many methods got a significant performance boost thanks to a fix getting rid of unnecessary block transaction re-executions. This may be noticed in use cases with many frequent RPC requests, for example when using retesteth<\/a> with aleth.<\/p>\n

<\/g><\/svg><\/a>Database<\/h3>\n

Rebuilding the indices from existing blocks database was fixed and optimized, this will allow us to optimize and modify the layout of the index database in the future.<\/p>\n

<\/g><\/svg><\/a>Testeth tool<\/h3>\n

Consensus tests folder structure was reorganized by the testing team, and testeth now supports it – all the tests covering fork rules before Istanbul are in LegacyTests suite.<\/p>\n

State tests can now be generated and run with a string like “ForkName+EIP_number” in place of a regular fork name in expect section. This allows for anyone planning to prototype new EIPs in aleth to generate tests for them before EIP is accepted for the fork – this is the basic idea of the EIP-centric forking process<\/a>, being adopted currently by All Core Devs community. As an example of the mechanism, two new EIPS mentioned above (EIP-2046 and EIP-1380) can be activated in testeth, and we’ve created a couple of state<\/a> tests<\/a> to illustrate this feature.<\/p>\n

We’ve also fixed and streamlined the feature of testeth to run any custom test file (outside of predefined consensus test structure) and made it’s output to be more conformant with the evm tool of go-ethereum. This allowed us to integrate testeth into goevmlab<\/a> project, and now aleth’s EVM implementation is participating in cross-fuzzing effort alongside 3 other major clients’ EVMs.<\/p>\n

Among other improvements:<\/p>\n

<\/g><\/svg><\/a>Ecosystem Support Program<\/h2>\n

Authored by ESP Team<\/em><\/p>\n

<\/g><\/svg><\/a>Taiwan-Specific Grants<\/h3>\n

We recently awarded<\/a> a round of five grants of 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 is the most recent in a series of local-specific waves intended to recognize the contributions of communities around the world.<\/p>\n

<\/g><\/svg><\/a>Growing Non-Financial Support<\/h3>\n

We’re continuing to expand our definition of “support” for projects where a regular grant is not the right fit. Some of the non-financial support we’ve provided is feedback rounds with expert advisors, connecting teams that are working on similar things, AWS credit, invitations to participate in events and more.<\/p>\n

<\/g><\/svg><\/a>Website Improvements<\/h3>\n

Our new website https:\/\/Ecosystem.Support\/<\/a> is growing! We’ve started small with a FAQ section and some changes to the front page – we’ll follow with a grants showcase and dedicated blog for regular updates.<\/p>\n

We don’t want valuable skills going to waste, so we’ve revamped our inquiry forms to be a bit more open-ended, including a dedicated pathway<\/a> for people who are interested in contributing to the ecosystem but aren’t sure yet where they fit. Feel free to take a look around, and to apply!<\/p>\n

<\/g><\/svg><\/a>Ewasm<\/h2>\n

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

Since the last update, the Ewasm team’s focus has shifted towards research on Eth 2.0, working in close collaboration with other teams.<\/p>\n

As the launch of Eth 2.0 phase 0 approaches, the phase 2 execution layer is under active development, in parallel with the development of phases 0 and 1. Multiple proposals have been made for the architecture of phase 2. The Ewasm team has been working on informing designs with prototypes and benchmarks, building upon a minimal foundation in Scout.<\/p>\n

<\/g><\/svg><\/a>Scout<\/h3>\n

The Scout specification<\/a> is a minimal interface for EEs (Execution Environments). This minimal interface is just enough to prototype stateless EEs, which are needed to validate the stateless model, and to inform the design of Ewasm and phase 2.<\/p>\n

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