Peer discovery issues with private blockchains

Trying to make your own cryptocurrency and running into issues with your peer nodes not discovering each other? In this blog post you will learn how to make an altcoin built on the Ethereum protocol connect to other peers, and what was done to automatically work around these limitations for cryptocoins generated on Coinpress.cc.

Ethereum bootnodes do not share peers as expected on a private blockchain

When started with the “–bootnodes” flag, Ethereum nodes in a private blockchain might be expected to connect to the bootnode and get a list of peers to connect. From Microsoft’s developer blog:

“Bootnode is a lightweight application used for the Node Discovery Protocol. Bootnodes do not sync chain data. Using a UDP-based Kademlia-like RPC protocol, Ethereum will connect and interrogate these bootnodes for the location of potential peers. The Ethereum Foundation maintains several bootnodes for the public Ethereum networks; the endpoints of which are hard-coded in the Geth source code. The default list can be configured using the –bootnodes option”

https://www.microsoft.com/developerblog/2018/06/01/creating-private-ethereum-consortium-kubernetes/

Instead you may find, even under ideal circumstances, it only connects to the eNodes specified by the bootnodes flag as echoed by this unanswered Reddit post from early 2018. I contacted the author of the post and it remains a known issue at the time of this post’s authoring.

Which leads us to…

Ethereum peer discovery protocol does not work properly on private blockchains

The existence of the “–nodiscover” flag in most guides on setting up your own Ethereum-based crypto coin may give you false hope that omitting that flag might enable peer discovery on your private blockchain. Instead, this flag controls the p2p discovery protocol to discover other nodes for the Ethereum Mainnet (https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the-network#common-problems-with-connectivity), and leaving that feature on will only result in wasted bandwidth as your nodes continually try to discover peers on the Mainnet that are incompatible with your coin.

Coinpress works around the broken peer discovery protocol by implementing its own P2P communication layer on top of geth that automatically exchanges peer node information with connected peers. Standalone servers respond to these requests on port 3908 so make sure that port is forwarded on your router for best results.

If you’re not using Coinpress.cc to make your own cryptocurrency, you’ll need to manually exchange node information somehow, which is complicated by the fact that…

Running admin.Peers returns the wrong ports for peer nodes

The problem is that Ethereum’s admin.peers command gives you the UPNP port of the connected peer node, and using that port is going to be a mixed bag in terms of how well it works. Using the UDP port may help in situations where network administrative access for enabling port forwarding isn’t available, but suffers from lack of consistency in implementation and functional status. This will be a judgment call if you’re rolling your own coin, but Coinpress software attempts to connect to peers using both a configurable port and the UPNP port for maximum chances at success.

Ethereum does not remember static nodes added via the console on private blockchains even when added with admin.addPeer()

This isn’t necessarily just an issue with private blockchains. Ethereum doesn’t have any mechanism for permanently adding peer nodes. You can work around it by manually editing the static-nodes.json file but this will require manual intervention for every single peer if some sort of scripting isn’t used. This isn’t as noticeable on the Mainnet as there are several bootnodes hard coded in, but that doesn’t help when you’re trying to make your own crypto coin that isn’t compatible with regular Ethereum peers. You might be able to get a start by swapping the bootnodes in that code file for your own known bootnodes and compiling, but this won’t give much functionality above using the static-nodes.json file or manually specifying them via the ”–bootnodes” command line flag.

Note that if you do end up using the static-nodes.json method to pass geth peer nodes, you may have to add the “–maxpeers” flag as noted on StackExchange or it may not connect at all.

The Coinpress peer discovery protocol partially mitigates this by accessing a (currently undocumented but public) API to get a list of Coinpress hosted peer nodes. These give starter nodes in the same way as the hard-coded bootnodes from Ethereum’s blockchain. Planned improvements include a mechanism for automatically keeping a list of previously seen nodes in order to provide additional redundancy if the API is unavailable.

So what are my options?

  • You’ll need to implement some sort of peer discovery protocol if you’re forging ahead on your own. If you happen to fix the issue by modifying the source code in Geth, consider submitting it back to Go Ethereum as a pull request so that you won’t have to maintain your patch.
  • Consider switching to a blockchain technology other than Ethereum that has functioning peer discovery out of the box for private blockchains. This will likely change your technology stack somewhat.
  • Use the Coinpress.cc tool to generate your cryptocurrency.
  • Instead of doing an entire blockchain that needs its own peers, do an ERC20 token. This will solve this issue at a large cost in functionality.

In conclusion

Ethereum was built for the Ethereum blockchain, and isn’t intended to be a white-label solution for altcoins. You may find that certain features don’t work as advertised, or at all, with no support and little concern from the developers. Whether you build the functionality yourself or rely on solutions or tools that bridge the feature gap for you, lack of automatic peer discovery is a show-stopper for projects with big ambitions.

Leave a Reply

Your email address will not be published. Required fields are marked *