You are viewing a single comment's thread from:

RE: Response to Cosmos white paper's claims on DPOS security

in #steem8 years ago

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 witness Y1, 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 transaction VT, then it's included in block B21, produced by X21. Under normal circumstance, the next block should be produced by one of the Y's.
  • due to network issue or whatever reason, the first Y, we assume it's Y0, missed its first block.
  • due to network issue or censorship, neither VT nor B21 was received by X1, then it produced another block B21' without VT, so the active witness set is not changed according to this block. We assume the next witness is Xn. Note that the next block of B21 and B21' will have same timestamp.
  • due to coincident or collusion, Xn decided to build a block following B21', and other X's followed this chain. In the meanwhile, the Y'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?

Sort:  

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.

Coin Marketplace

STEEM 0.24
TRX 0.26
JST 0.041
BTC 98769.41
ETH 3492.31
USDT 1.00
SBD 3.36