According to a recent research MinerTransactions are beneficial in discovering which faulty NEO node is causing delays on the NEO ecosystem. For a new block to be approved to the chain, 66% of nodes must be in agreement before it’s accepted as a new block in the chain.
The consensus nodes in NEO take turns to act as a speaker when proposing a block. The rest of the nodes act as validators who have to make a uniformed agreement amounting to 66% for the new block to be added in the chain.
Since there are many nodes, they all take turns as speakers. However, during the block submission, a speaker might submit an invalid block or fail to send a new block request. When this happens, it results into a delay or a view change, and with each speaker on a 15-seconds time frame, a failed block submission means the next speaker in line takes the role leading to a 30 seconds delay.
The view change leads to all other speaker’s time doubling and eventually causing a finality loss. Finality occurs when a block isn’t approved. It also prevents a blockchain fork.
How to Single Out the Node Causing the View Change
To single out the speaker, Edge turned to MinerTransactions which are in every block and are in charge of sending speakers a priority fee when they take up the responsibility of being a speaker.
With each speaker being receiving, a priority fee from the MinerTransactions, it provides some wiggle room to find the public address of the speaker causing the delay. To find out the address, neo.org/consensus comes in handy. The latter is where all 33-byte public keys are located. By taking the 33-byte public key combining it with an opcode 21 and running it through NeoComplier Eco, you get the public address.
If there were ten33-byte public keys, running all of them will lead to the public addresses of each speaker (nodes). With the addresses at hand, it’s time to send priority fees transactions manually to all public addresses.
After sending priority fees transactions, check for activity on the MinerTransactions from the blocks. Results will show all nodes interacting with the MinerTransactions with the missing node being the one responsible for the delay.
