You are viewing a single comment's thread from:
RE: Response to Cosmos white paper's claims on DPOS security
In regards to IRB, actually I think a block accepted by majority (number) of block producers
is not enough, instead it should be a block accepted by majority of stake
.
The issue is about the stake voting process. It's a result of several factors combined.
Firstly, let's list the rules, using Steem for example:
- every account can vote for 30 witnesses
- votes are transactions, which need to be included into blocks
- witnesses schedule updates every 21 blocks
Here is a scenario:
- current active witnesses are
X1, X2, ..., X21
- one account
P
, is voting for another set of witnessY1, Y2, ..., Y21
- current active witnesses produced blocks
B1, B2, ..., B20
,B20
is the head block, so there is one block to be produced by current witnesses - the @steemit account, which has a big amount of stake, was not voting, now decided to vote and proxied to
P
, broadcast a voting transactionVT
, then it's included in blockB21
, produced byX21
. Under normal circumstance, the next block should be produced by one of theY
's. - due to network issue or whatever reason, the first
Y
, we assume it'sY0
, missed its first block. - due to network issue or censorship, neither
VT
norB21
was received byX1
, then it produced another blockB21'
withoutVT
, so the active witness set is not changed according to this block. We assume the next witness isXn
. Note that the next block ofB21
andB21'
will have same timestamp. - due to coincident or collusion,
Xn
decided to build a block followingB21'
, and otherX
's followed this chain. In the meanwhile, theY
's started producing blocks one by one. Now, both fork has same height and same HEAD timestamp, and IRB of both fork will advance. The validators will have to make a choice, but it can't be done automatically by the consensus code, instead it can only done with a checkpoint, so the automatic systems which relying on IRB will have trouble.
The reason: currently witness rescheduling is not based on IRB. But it can't be based on IRB, because in case when 1/3 of witnesses went offline simultaneously (in a same round), IRB won't advance anymore, so new witnesses can't be voted in.
Thoughts?
Witness scheduling isn't based on IRB, only the extent that a witness will roll back is. Therefore, it is possible for votes cast in the pending state to impact the pending witness schedule and ultimately advance the LIB.
Can you please review this algorithm for me: https://github.com/tendermint/tendermint/wiki/Byzantine-Consensus-Algorithm
Under the model used by tendermint, no block can contain data that changes who can confirm it.