Vision for OpenEthereum (ex-Parity client)
We are committed to focusing 100% of our efforts to provide resilience to Ethereum mainnet
Direction of OpenEthereum
We’re here to share recent changes in the direction of OpenEthereum and shed light on our decision to further diverge from Parity’s original vision for the client. For many years, the Parity client served as a playground for experimentation on custom blockchains and different consensus mechanisms, while slowly developing into an increasingly complex, multi-purpose tool. However, as the ecosystem has grown considerably since, it has become clear that the most important goals for the client have shifted. As the former Parity client, OpenEthereum’s top priority today is to improve the diversity of client functionality on Ethereum mainnet by building resilient and efficient infrastructure. As such, our roadmap includes deprecating some functionalities that add complexity and do not align with this primary aim.
In the short term, we will maintain the most stable and lean version of OpenEthereum with the highest degree of confidence, and upgrade all EIPs required for the Berlin hardfork.
Our main objective in the medium- to long-term is to continue exploring solutions that will improve gas usage and efficiency. If you are curious about some of these efforts, see the 1.x client research on ethereum-magicians.org and our Discord server. We are tremendously excited by the present opportunities to improve this aspect of client and user experience on Ethereum.
Status of the Latest Updates
Throughout recent years, some parts of the client’s legacy codebase were not allocated adequate attention and support to fully address requirements of a project at this scale. The 2.7 version was released shortly before we took over and introduced some severe issues affecting memory and disk usage, resulting in most users not upgrading to the latest version and instead relying on the 2.5.13 release database.
After a series of helpful discussions between the two teams, Parity agreed with OpenEthereum that the best move forward is to backport to the 2.5.13 database version, which is the last stable version that does not include any of the new issues mentioned above. Most of the current OpenEthereum users, including Etherscan, are still using the 2.5.13 version, so this does not mean that any of the nodes are forced offline. In fact, the reported issues represent a small percentage of OpenEthereum nodes, and the majority of them remain stable in the latest 3.0.1 version.
The decision to revert several refactoring commits between releases 2.5 to 3.1 is critical to fulfill our vision of a stable and light client and ensure the viability of our long term aim to keep clients on Ethereum diverse. The downside is that the 2.5.13 version database format is incompatible with 3.x, which means that some users will have to resynchronize the client. We will seed the database file to facilitate the migration.
Next Steps
OpenEthereum 3.1 version will be based on 2.5.13, with maximum guarantees for the Berlin hardfork on mainnet, EIPs, and improvements to support monitoring via Prometheus.
We have decided to remove non-core features that lack advocates willing to maintain them, meaning OE3.1 will remove the deprecated features for:
Private Transactions, Light Client, Updater, IPFS and Swarm support, currently deprecated flags such as callisto, ellaism, expanse, kotti, mix, morden, mordor and musicoin testnets. We are open to include them if there are volunteers. OE3.1 will not support ETC.
For current 2.5.13 users: The internal database structure will not change so you will not need to sync from the scratch.
For current 3.0.1 users: The internal database structure will change for these users. We expect to deliver a migration utility; nonetheless, we recommend to start syncing a 2.5.13 node to perform an update later, specially if you are running an archive or a fatdb node.
If you have questions or want to join us to help build the client, reach out on the OpenEthereum Discord server, follow us on Twitter and Github.
We look forward to hearing your feedback, and we welcome offers of support!
Edit: Due to high demand from the community, we decided to continue giving support to Kovan testnet to make it compatible with the upcoming Berlin Fork.
