1

I have an Ethereum chain running on my local host via geth and i am using the clique PoA Algorithm. I have 4 authority nodes so the number of Nodes allowed to sign a block should always be 1 because of ( N - (N/2 + 1)) with N being the number of authority nodes. I also have a Node.js script that is syncing with the events happening in the chain. I am using an eventListener like this:

AboStoreContract.events.allEvents({fromBlock: "latest"})
    .on('data', (event) => { handleEvent(); }).on("error", console.error);

The connection between node.js and my node running on localHost is made through the geth.ipc file like this:

const web3 = new Web3("\\\\.\\pipe\\geth.ipc", net);

Now my issue is that often the same event gets duplicated. its always 3 times if duplicated. I started inspecting the transactionHash and blockHash and it seemed like 2 duplications have the same transactionHash + blockHash and then the 3rd duplication has the same transactionHash but a different blockHash.

The only reason how i can explain this is due to a chainreorganization going on, but as i only have 4 authority/signing nodes there can, due to clique consensus algorithm, at all times be only one node allowed to sign. So there cant be a race going on that leads to making use of the GHOST protocol to see which fork has the higher "value"

I know that i am supposed to wait for a certain number of Blocks so i can be sure that the events are not lying in a forked chain that gets thrown away, but in my usecase blocks are only created when a transaction happens, so i have to react to events right away.

So the question is: why do i get duplicated events, when chain reorg is impossible? or is it still possible and i dont understand the clique algorithm?

thanks in advance

Improve this question

1 Answer 1

Reset to default
1

Unless you have a single authority reorganizations are still possible in a PoA.

The authority in turn has to sign and send the block on time to the rest of network. If the next authority fails to receive the block on time it has to produce a new block and propagate it to the network. Until the consensus is resolved some nodes might see different chains.

In a network with N authorities to be sure a block is confirmed you need to wait for a simple majority. For N=4 you have to wait 3, for N=5 you have to wait 3.

Improve this answer
4
  • Thanks for the answer! is there a way so i can increase the time it takes for a node that is not in position to propose a block as it failed to receive the expected block on time?
    – Henk van der Sloot
    Sep 25, 2019 at 8:59
  • I don't think there's a high level switch for that option, you can always modify geth source code an deploy your own version.
    – Ismael ♦
    Sep 25, 2019 at 12:59
  • Sorry, i still don't understand how these reorganization can happen. in my Network when i have 2 out of 5 signing nodes active, the transactions stall because one node is only allowed to sign every 3 blocks. so when i have 5 authority/signing nodes i need at least 3 of them active so the network doesn't freeze. Now if i have 3 Nodes active, there should be only 1 node allowed to sign. If i run it like this, the duplication of events still happens 3 times even though there can't be reorganization :/
    – Henk van der Sloot
    Oct 1, 2019 at 9:43
  • Nevermind. using only 3 nodes in a network with 5 authorities leaves no room for forks. You were right. thanks !
    – Henk van der Sloot
    Oct 1, 2019 at 10:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.