Secure Your Nodes: Migrating From Parity To Geth
The Ethereum ecosystem primarily relies on two providers for the fundamental unit of infrastructure: nodes. One of these organizations, Parity Technologies, announced they are focusing on other initiatives and discontinuing development on their Ethereum node software. We at Alchemy have recently decided to switch from Parity to the other major option, Geth, and suggest you do the same since it is being actively developed by a dedicated team. Migrating core infrastructure is mission critical and nuanced. From our years of infrastructure experience powering top companies around the globe at Alchemy, we created this guide to migrating from Parity to Geth to share best practices and help you have a successful transition. Sharing this guide with your engineering team can help them navigate the intricacies of blockchain nodes and help make sure your core infrastructure is running smoothly.
Background
A quick summary of the basics. Blockchain applications require running servers called “nodes” that allow you to read and write to the blockchain. You can think of them as a database that stores the blockchain.
There are currently two main options for node software: Parity and Geth. Both of the teams that build and maintain this open source node client software have provided a huge service to the entire blockchain ecosystem and Ethereum would not exist without them. They both have the Alchemy team’s deep gratitude.
Recently, the Parity team, which has contributed massively to supporting the growth of Ethereum blockchain development from the very beginning, is now moving on to focus on their own chain.
Peter and the entire Geth team have done an incredible job building a stellar Ethereum client and are actively continuing development on it.
Eth node client distribution (ethernodes.org/)
Why Should You Migrate?
Nodes are the core infrastructure of every blockchain company. Every time your system needs to read or write information to the blockchain, you use your node.
Compared to traditional web infrastructure, blockchain nodes are significantly more complex and time intensive to manage. Additionally setting up a new node can take up to days or weeks due to the syncing time. This means that having problems with your node infrastructure can mean your product is non-functional for weeks.
In order to ensure you have stable, robust, and scalable infrastructure, running an actively maintained node client is essential.
Parity Technologies has graciously handed over the Parity Ethereum codebase to their newly created OpenEthereum DAO and we are excited to see the advances made to the node software in this truly decentralized medium. In contrast, the Ethereum Foundation has a full time team dedicated to continuously building and improving the software for the foreseeable future.
Using an actively developed project means that bugs, stability issues, forks and other unknown challenges will be promptly fixed and the software will continuously improve. Our recommendation is to strongly consider switching your node infrastructure to Geth.
This is a fairly involved process, so consider budgeting 2-4 weeks of engineering time to fully transition.
Finally, if you would rather just focus on building your core product and not deal with low level node infrastructure at all, give us a shout. The Alchemy Blockchain Developer Platform was architected from the ground up to make it extremely easy for everyone to build great blockchain products.
Alright, now that you’re up to speed, let’s get migrating!
How to Migrate From Parity to Geth
The 8 Steps
Remove dependence on Parity specific namespace methods
Remove dependence on Parity specific response fields
Remove dependence on API specific responses for bad requests
Remove dependence on Parity specific error codes
Set up Geth hardware
Set up Geth software
Run application specific traffic simulations on nodes
Switch over traffic and monitor the service
1. Remove Dependence on Parity Specific Namespace Methods
Parity and Geth both implement the generic JSON-RPC Ethereum protocol set forth by the Ethereum Foundation, and then their own supplemental API methods on top. There are some parity namespace methods like parity_allTransactions, which return all pending transactions from the view of a Parity node. Functionality wise, there should be Geth parallels across different packages. In terms of traffic to Alchemy, the biggest omission in Geth is the trace module, whose methods have been moved over to the debug package, where you can replicate popular trace methods like trace_replayTransaction with the analogous debug_traceTransaction.
2. Remove Dependence on Parity Specific Response Fields
Despite their best efforts of consistent implementation, there are some minor differences. Check to make sure you don’t rely on a field that is omitted in Geth Responses. We’ve seen real-time cases where people relied on certain fields, such as the transactionLogIndex field found in logs objects from eth_getLogs.
Generally we’ve seen that Geth tends to cut off and fail for longer running calls in order to preserve the health of their nodes.
3. Responses For Bad Requests Differences
Properly formatted requests that might fail in the EVM (Ethereum Virtual Machine) for whatever reason might behave differently. Check to make sure you don’t rely on VM execution errors in Parity for bad requests, as they will generally return a result of 0x on Geth. A few examples of bad requests below:
The provided eth_call block number parameter is pending.
An eth_getLogs block in range cannot be found in the node
An eth_call that runs over 5 seconds will be automatically cut off by the EVM.
4. Parity Specific Error Codes
Some client retry mechanisms rely on specific Parity error codes to inform them of specific logic. Check to ensure you don’t rely on error codes that might change in Geth. A more complete list of Parity JSON-RPC error codes can be found here. In general, there is a loss of specificity in some of these errors, so you will require some client-side logic to handle these cases.
5. Set Up Geth Hardware
Geth nodes should be able to run on the same hardware you've been using for Parity. There are a few key attributes we’ve noticed and discussed with the Geth team that will help keep your shiny new Geth node performant. There are two system metrics to monitor closely: CPU percentage and iowaits, the rate at which the system is writing to disk. We’ve seen strong correlations between these metrics for nodes in practice when they begin to error out of calls, become unresponsive, or generally move into a degraded state. The CPU percentage and iowait usage is dependent on the hardware you are using. For an EC2 m5.2x large instance, we typically see degraded performance around 65% CPU usage and 1 iowaits/second for archive nodes.
Alchemy Internal Geth Node Iowaits
6. Set Up Geth Software
Although rare, we’ve seen cases where Geth nodes get stuck syncing at random intervals (unknown block number). In such cases, patience is the key virtue and the node will eventually start syncing in a matter of hours.
Starting the Geth process has a few quirks that we’ll discuss ahead. There are a lot of flag options that Geth specifies. The --pprof flag has a lot of nice metrics that give insight into the health of the node like its peer count, the tx_pool, and loads of other useful information exposed on port 9090 by default. Another important point to note is to specify the kill signal as KillSignal=SIGINT. We found Geth had issues upon restarting where Geth would travel backward to the last block, as Geth wasn’t properly flushing in memory blocks or state to persistent disk on shutdown.
7. Run Application Specific Traffic Simulations on Nodes
We have seen a few methods in Geth that have the same request/response formats but behave slightly differently than the parity version. A real-world case we’ve seen is the following: eth_gasPrice and other methods that rely on gasPrice estimates like eth_estimateGas in Geth utilize an estimation model that tends to result in lower predictions of gasPrice than in Parity. This results in unexpected transaction failures such as: Transaction gas price supplied is too low. There is another transaction with the same nonce in the queue. Try increasing the gas price or incrementing the nonce. You can mitigate this by padding the gas price, or by using other third party sources, like the Eth Gas Station to get your price estimates.
8. Switch Over Traffic and Monitor the Service
It’s finally time to make the switch! Move your traffic over to Geth and monitor it carefully over a few days. If you run into any other unexpected issues, feel free to reach out to the Geth team or come talk to us.
Want an Easier Way to Migrate?
We hope this guide was useful in helping navigate the Parity to Geth migration process! If you have any questions or challenges, feel free to reach out to us - we’re here to help.
Additionally, if you want to turbo charge your development with a platform that makes it significantly easier to build and release blockchain applications without having to deal with low level tasks like managing nodes, come talk to us!
At Alchemy, we created the Blockchain Development Platform from the ground up to make developer’s lives easier. Now through a powerful suite of developer tools, 24/7 support, and a globally scalable novel blockchain infrastructure platform, you can save thousands of hours on development, make your application 107x more reliable, and create much better products for your users. Feel free to reach out to learn more!
Good luck with your migration to Geth.
It's 2020. Stay healthy and keep your nodes healthy!
----
Sign up for a free Alchemy account here.
About Alchemy
Alchemy provides the leading Blockchain Development Platform powering products used by millions of users in 197 countries. The Alchemy Platform's novel infrastructure engine and suite of unparalleled developer tooling enables creators to easily build great blockchain based products in a fraction of the time. Backed by Stanford University, Coinbase, the Google Chairman, Charles Schwab, and top technology and finance executives, the team brings deep expertise in blockchain development and massively scalable infrastructure through decades of experience at technology giants like Google, Microsoft, and Facebook.
Related articles
Preparing for the Agave 2.0 Upgrade
ERC-1271 Signature Replay Vulnerability
On October 27th 2023, Alchemy discovered a ERC1271 contract signature replay vulnerability that affected a large number of smart contract accounts (SCA), and led to risks when interacting with several applications.
What is RIP-7212? Precompile for secp256r1 Curve Support
RIP-7212 is a core change in the Ethereum protocol that opens up a way to have cheap, secure, and fast P256 curve verification with a precompiled contract.
