OpenEthereum, Closing Shop

With OpenEthereum deprecated and Erigon spinning up as a successor, we’re here to make sure the transition is as smooth as possible! 

TL;DR

• OpenEthereum (formerly Parity Ethereum) is stopping development on their client after the London hardfork, estimated August 4, 2021

• If all goes well, OpenEthereum’s client will remain operational until the next Eth hardfork (Shanghai - expected October 2020)

• The team will shift focus to the Erigon client (formerly turbogeth) 

• Alchemy is hard at work doing everything possible to keep OpenEthereum specific functionality available to all teams during and after the fork

• Alchemy will continue to run OpenEthereum nodes for serving Kovan, trace_ and parity_ endpoints as long as possible

• In parallel, we are spinning up support for Erigon nodes, and working with their team reach feature parity on Kovan, trace_ and parity_ functionality using the new client

Summary

At the end of 2019, Parity Technologies transitioned development of the Parity Ethereum client from an in-house project to a new organization called the OpenEthereum Dao. Since then, developers at Gnosis and elsewhere have heroically kept the OpenEthereum client up-to-date, the Kovan network alive, and trace_ API endpoints available. 

Recently though, OpenEthereum announced that their client will be deprecated and succeeded by a new one built in collaboration with the team at Erigon (formerly TurboGeth). In the long term this should mean faster, more reliable, better overall experience for former OpenEthereum users.

In the short-term Alchemy is doing everything possible on behalf of our users, working with both the OpenEthereum and Erigon teams, to make sure that service of OpenEthereum-specific functionality remains uninterrupted. 

We’ll go over everything we’re doing to take care of the three major OpenEthereum functions, but feel free to skip to the section that’s relevant to you: trace_ endpoints or the Kovan testnet. 

The Fork Plan

Trace Endpoints

Currently, OpenEthereum is the only Ethereum client that supports the trace_ methods that many teams use. Since OpenEthereum is supporting London on Mainnet, we expect these methods will continue to be served from OpenEthereum nodes, with no changes necessary.

OpenEthereum, however, likely won’t be making any further changes. This means that when London goes live on mainnet, if there are consensus issues that require updates OpenEthereum nodes and their trace functionality may break.

While we expect this is a remote possibility, we will be doing everything possible on behalf of our users to keep trace methods accessible.

The Erigon team is working hard to add support for all the relevant trace endpoints and aims to have a working replacement for OpenEthereum’s versions before London is ready. Alchemy is helping give feedback and iterate on the trace_ namespace as quickly as possible to make sure that they can be drop-in (or near drop-in) replacement for OpenEthereum. 

At the same time, we will be spinning up production support for Erigon so that we can swap over trace functionality to their nodes in the event a failover from OpenEthereum is necessary because of London-related issues.

Kovan

While OpenEthereum has a new client version prepared for London on mainnet, there will not be a new client released for Kovan.

This means that Kovan will continue to run on Berlin-era OpenEthereum nodes, and will not support new features in London, like EIP-1559. That said, as far as most products are concerned London changes should be backwards compatible, and Kovan will remain usable. That said, anyone using Kovan should make sure that they can still rely on the testnet as a staging environment (and potentially consider migrating to Rinkeby or Goerli).

Over time, Erigon will be building support for Kovan, and ushering the testnet into the London Era, though there is no specific date for this yet.

Parity Endpoints

At the moment, Alchemy only supports one method in the parity_ namespace: parity_getBlockReceipts. That method will be replaced by the functionally equivalent eth_getBlockReceipts. 

When we migrate to Erigon, there will be no need to make any changes (we will treat both parity_getBlockReceipts and eth_getBlockReceipts as the same method). However, there are certain fields that will be missing - namely the Parity specific fields, transactionLogIndex + type in the logs array. These fields are not critical and not present when you call eth_getTransactionReceipt on Geth.

Conclusion

It is our greatest focus for the weeks leading up to London to make sure that our users have the  smoothest possible transition from Berlin. If you or your team has any questions at all about the transition away from OpenEthereum, or London in general, don’t hesitate to reach out directly to me at [email protected]!