Two main malicious behavior of block proposer
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 • 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…
Excerpt (1198 of 2889 characters). Read the whole post on the forum ↗
bharvest:block proposer can include its own transactions in proposed block
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.
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.