Two main malicious behavior of block proposer

Archived Cosmos-SDK
1

Problem definition

I want to introduce two kinds of malicious behavior of block proposer in Tendermint/Cosmos-SDK based blockchains and start discussion on this topic

  1. block proposer can censor certain transactions to exclude them in proposed block
  2. block proposer can include its own transactions in proposed block

Currently both behaviors are not a significant threat to the Cosmos Hub, because

  1. if the validator cartel does not possess majority of power, the transaction can just wait a little bit more to meet other honest proposers
  2. there exists very little economic benefit for proposers to include their own transactions in their proposed block(except for free gas cost)

But, in a broader perspective, when many different kinds of applications are utilizing Tendermint and Cosmos-SDK, those two kinds of issues can be a critical weak point for a lot of applications.

Especially, some applications where “timing and txs information before commit” is crucial, above two issues can be critical problems to cause significant unfair advantages to block proposers.

Therefore, I want to start this thread to discuss on prevention mechanism to protect the application from such behavior of block proposers.

What I’ve imagined as a solution to these problems is “fake block proposing” for all validators.

Fake block proposing

fake block proposing is a responsibility of all validators that they have to fakely propose blocks on every block even though they are not a block proposer of the height, storing them in kvstore but fakely proposed blocks are not subject to be on consensus process.

Those proposed blocks can include only meta data and tx hashes.

Then we can compare each validator’s proposed blocks on given height so that we can see the difference of txs list between real proposer’s block and other validator’s fake blocks. Then we will possess much more objective evidence that the proposer is intentionally manipulating the contents of proposed block.

I am still not sure which specific number is adaquate to slash such proposer, but at least now we have enough data to decide whether any block proposer is doing any malicious behavior on his/her proposed blocks.

I guess this is quite performance consuming and kvstore consuming too. We can delete old data to save space on kvstore but, still all validators creating blocks on every height can be too resource costy. But still, some applications might want to adopt prevention methodologies even though it is performance costy, because of the importance of such problems.

Alternative implementation of “fake block proposing” is for all validators to do this work locally, and submit “evidence” when the proposed block content is significantly different from the node’s version of proposed block. This way, only suspisious status will be recorded on blockchain via evidence module.

1 Like
2

I do not view this as malicious behavior. The transaction is still valid and the proposer is choosing to make sure it is in the current block. If other validators are ok with this and sign the block they have signaled they too were ok with said transaction being included.

3

I agree that many applications do not need to care about this unfairness, but in some cases, it is critical.

It gives validators unfair advantages to read the list of transactions and put his/her transactions ahead them. This is more critical when it comes to DeX. It is called “front running”. Validators can read transactions to be included in his/her block, and put their own transaction in the block. But I imagine DeX is not the only application which has this critical problem.

So, to make it fair, validators should gossip their transactions sometime before block proposing, so that other validators can aware the transactions are well broadcasted before block building. Validators can simply broadcast there transactions to any public full-node.

1 Like