Disagree! I argue below that internally fork-free voting has significantly lower time to finality than forkful voting.
Forkful voting
Let’s first look at the forkful voting scheme. For concreteness we assume 2048 voters so that N = 1024. An eligible voter has the right to cast a single vote per period. Following this spec for concreteness, let’s say a period is 5 blocks in the main chain, so a vote is cast every 5*15 = 75 seconds.
To be conservative let’s assume a best-case scenario where there are:
- No gaps: The eligible voter always votes.
- No forks: The eligible voter always votes consistently with the previous voter.
- No repetitions: No two eligible voters within N periods are the same. (Notice none of the proposal mechanisms discussed so far on ethresear.ch have this property. Even perfect fairness does not guarantee no repetitions at the epoch boundaries.)
Given the above idealised setup we have achieved the following:
- Main chain overhead: The voting overhead on the main chain is 1 message per 75 seconds.
- Finality throughput: One final vote occurs every 75 seconds.
- Finality latency: From the point of view of ongoing data, finality happens in 75/2 seconds + 1024 * 75 seconds, i.e. 21.34 hours.
If gaps, forks and repetitions are taken into account, my guess is that time to finality would be over one day.
Internally fork-free voting
Let’s now look at the internally fork-free voting scheme. We set the same finality throughput of one final vote per 75 seconds, and also get the same main chain voting overhead of 1 message per 75 seconds. With such a setup what is the finality latency from the point of view of ongoing data?
Notice that in the internally fork-free scheme the casting of votes is done offchain. This has two significant messaging consequences:
- Latency: We are not constrained by the 75 seconds onchain messaging latency per vote. Instead, the gathering of N votes can be done at full wire speed.
- Parallelism: We are not constrained by the sequential nature of the forkful voting scheme. Instead, the gathering of N votes can be done in parallel.
Let’s conservatively assume that offchain latency with honest voters is as bad as onchain voting latency. That is, requesting a vote (a signature) from an honest voter and receiving the corresponding vote takes less than 75 seconds. Because of parallelism and the honest-majority assumption, a final vote can still occur in 75 seconds.
If in any given period voters finalise ongoing data from the previous period then finality from the point of view of ongoing data occurs in 1.5 * 75 seconds, which is less than two minutes.
Conclusion
We compared two honest-majority voting schemes with the same main chain overhead (1 message per 75 seconds) and the same finality throughput (1 final vote per 75 seconds). Assuming 2048 voters, the finality latency of forkful voting is on the order of one day, and the finality latency of internally fork-free voting is on the order of two minutes.