Ethereum synchronisation with single miner on a private network
Posted By : Amit Kumar | 10-Apr-2017
WORKING WITH SINGLE MINER ON ETHEREUM PRIVATE NETWORK
We at some time face a scenario when we have to work with a single miner , let it be for testing or non mining access to other users . So in those cases we are mining only a single node with other nodes simply broadcasting their transactions and unable to mine.
In this scenario what happens is when a transaction is generated by a client node , it simply gets broadcasted or propogated to another nodes , which are it's peers.
In this way all other nodes become aware about the transaction and as soon as they get the transaction, they start working on mining a new block including that transaction into that block (based on gasPrice that the transaction sender provides).
This works fine when there are more than one miners on your private network , but in case of a single miner private network , this broadcasting of transaction is not possible initially and thus the miner never becomes aware of the transaction thus rendering this transaction as unconfirmed forever which also results in the future transactions from this account to stay unconfirmed as well due to the transaction nonce ordering.
There are two workarounds to properly allowing the broadcast of the transaction from client node to the miner node -
1) MAKING CHANGES TO GETH SOURCE CODE AT MINER SIDE
First thing you can do is making some changes to the go-ethereum client source code . So clone the latest stable version of geth and make the following change to /eth/handler.go and then build geth and use that executable to run your miner. You need to comment the following line -
if atomic.LoadUint32(&pm.synced) == 0 {
break
}
2) ADDING A MINER FOR A SMALL AMOUNT OF TIME
The other workaround for the propogation issue is that you need to add another miner as a peer to the main miner node you are using , for enough time that the main miner and other miner are able to sync with each other at least once . Once this initial sync cycle completes , your main miner will be able to fetch transaction from other nodes too anfd you can stop the other miner.
You have to take care that if you have to restart the miner node you will have to repeat the whole step , if your main miner just keeps running this is it.
HOW AND WHY DO THE ABOVE CHANGES WORK
The two very different methods described above start working for pretty much the same exact reason . In geth versions released later than 1.4.5 , it was introduced that nodes will be not able to fetch transactions from other nodes until they complete their initial sync i.e. their state is very much similar to that of the whole network .
What the first method stated above does is that removes this condition by commenting that code and hence the initial sync is not necessary after the build.
The second method workss because it tries to satisfy the above condition . When the main miner is mining along with the other miner , it is able to synchronise with the other minar and
it is assumed safely that it's chain state is fresh too . Thus it is allowed to fetch transactions from a remote node.
GITHUB ISSUE LINK
Here is the github issue detailing the above changes - https://github.com/ethereum/go-ethereum/issues/2769
Cookies are important to the proper functioning of a site. To improve your experience, we use cookies to remember log-in details and provide secure log-in, collect statistics to optimize site functionality, and deliver content tailored to your interests. Click Agree and Proceed to accept cookies and go directly to the site or click on View Cookie Settings to see detailed descriptions of the types of cookies and choose whether to accept certain cookies while on the site.
About Author
Amit Kumar
Amit has years of software development experience. He has experience working on platforms like Ethereum, BigchainDB, and more. Also, he works on ERC token contracts with Solidity. He has expertise in Java, Solidity, Python, Spring Boot, NodeJS, MySql,