5

In Ethereum PoW the recommendation is to wait for 12 confirmations at least.

[Q]: What rules to apply for Geth PoA Clique algorithm?


My best guess so far:

lower limit: sum of confirmation block difficulties >= (floor(N/2) + 1) * 2

upper limit: sum of confirmation block difficulties <= N * 2

where N = number of sealers in the network

The reason that I'm multiplying with 2 is that in-order sealers are contributing 2 to the block difficulty, otherwise it's 1.


Update. After reading Castro/Liskov Paper on PBFT (http://pmg.csail.mit.edu/papers/osdi99.pdf), I beleive that the rule of 2*f + 1 confirmations for a N = 3*f + 1 applies for Clique too. At least as lower limit. Upper limit could stay as is. See the comment below.

2
  • There's an article by Vitalik blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times that examines the transaction confirmation time vs block times. It doesn't apply directly to PoA, but you can approximate it by the byzantinum fault tolerance model where the numbers of attackers is less than N/2.
    – Ismael
    Commented Sep 12, 2018 at 18:27
  • 1
    I just read the Liskov Paper on pBFT. They state that in a system with n = 3*f + 1, 2*f + 1 confirmations are needed to ensure the consistency. I beleive that this applies to Clique too. I was able to construct an example with Clique where 50% + 1 confirmations were not sufficient for avoiding transaction removal on reorg. In PoW things seem to be diferent, since there is no fixed number of nodes, but rather a computational power involved. Hence it's about the computational race between fautly and honest nodes (->51%).
    – ivicaa
    Commented Oct 1, 2018 at 11:08

1 Answer 1

3

Since nobody has provided an answer so far, I'll try to summarize my research on this. If someone is able to provide a better "story", I will switch the checkmark to it.

After reading the pBFT paper from Castor/Liskov, I believe that 66,6% + 1 rule from pBFT also applies for Clique too. Hence, 50% + 1 is not enough to be sure that the transaction can not be removed from the chain after a reorg.

So far I have only an example as a proof: In a system with 5 sealers (N = 5), I could have a dishonest sealer S3 able to divide the network into {S1,S2,S3} and {S3,S4,S5} (for instance by an DDoS attack), so that {S2,S3} are not able to communicate with {S4,S5}. Both networks will keep running their own fork as long as S3 is participating (50%+1). When he's in-turn, he could propose a valid block with a transaction TX and publish it only to {S4,S5}, while on the other side creating an alternative block with a double spend transaction TX' publishing only to {S1,S2}. After 50%+1 confirmations in {S3,S4,S5}, he could stop publishing blocks in this subnetwork and let {S1,S2,S3} get heavier. After that, he can release the blockade in communication, and the GHOST protocol would resolve the fork by selecting the heavier chain, which is the chain created by {S1,S2,S3}.

In this sense, the minimum number of confirmations will have to be: 66,6% + 1 [more precisely: N - floor((N-1)/3)] different sealers have confirmed the transaction, which is analogous to pBFT.

About "upper limit" as defined above in the question (sum of confirmation block difficulties <= N * 2). This actually makes no sense, since S3 could let the both forks run long enough to satisfy this condition and later, he could give his desired branch an advantage by halting the communication in the other branch.

1
  • I hope someone can confirm my analysis.
    – ivicaa
    Commented Oct 11, 2018 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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