BFT DPoS
liuzhiteng, ThunderDB zhiteng.liu@thunderdb.io
- Byzantine Fault Tolerance
- DPoS Block Producing
- Transaction as Proof of Stake
- EOS.IO Implementation
Oral message are characterized as follows:
- Every message that is sent is delivered correctly
- The receiver of a message knows who sent it
- The absence of a message can be detected
To tolerate m traitorous generals, requires 3m + 1 generals utilizing m + 1 rounds of information exchange.
a.k.a. Bounds on Fault Tolerance, applies to all consensus algorithms.
for i from 1 to INF
dlist_i = get N delegates sort by votes
dlist_i = shuffle(dlist_i)
for j from 1 to N * K
slot = global_time_offset / block_interval
pos = slot % N
if dlist_i[pos] exists in this node
generateBlock(keypair of dlist_i[pos])
else
skip
end
end
end
- Block producers A, B, and C take turns to produce blocks every 3 seconds
- Basic Rule: Longest Chain Wins
- Majority fork: 2 blocks / 9 secs
- Minority fork: 1 block / 9 secs
- Each block producer was isolated due to network issue
- Network connectivity is restored
- Defines longest chain
- Confirmation of irreversibility
The EOS.IO software requires every transaction to include part of the hash of a recent block header.
- Prevents replay of a transaction on different forks
- Signals the network that a particular user and their stake are on a specific fork
- Proof-of-Work Security problem: selfish mining
- DPoS: preventing secret alternative chain
- Direct connection
- Remove random shuffle
- 3s block time, confirmation time:
- Asynchronous Byzantine Fault Tolerance (aBFT) for faster achievement of irreversibility
- 500ms block time, under 1s confirmation
Q&A
Thank You!