I want to introduce two kinds of malicious behavior of block proposer in Tendermint/Cosmos-SDK based blockchains and start discussion on this topic
- block proposer can censor certain transactions to exclude them in proposed block
- block proposer can include its own transactions in proposed block
Currently both behaviors are not a significant threat to the Cosmos Hub, because
- if the validator cartel does not possess majority of power, the transaction can just wait a little bit more to meet other honest proposers
- 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.