Tendermint gives absolute power to the proposer for choosing which transactions to be included in the block. This mechanism provides us weakest tx censorship resistance.
Also, the choice of sorting is 100% decided by the proposer alone, which is another significant weak point of Tendermint.
Currently we do not have any application on Tendermint which demands high level of censorship resistance and prevented transaction sorting manipulation. But after time, we will have more applications, either on the Cosmos Hub or on other networks which require strong assumption on censorship and transaction manipulation, just like AMM.
So, I would like to kick off this discussion about brainstorming more decentralized block proposing process in Tendermint.
A naive approach for this is to split concensus process to two steps
- concensus on transaction list and sorting from all validators proposing txs
- concensus on execution result on states
This naive approach will make block time longer, so this might not be what we want as a side effect.
But I think there exists some design space of this where we can reduce block time length impact while achieving the decentralized transaction choosing process.
In the agoric execution model, agreement of an escalator of to be executed transactions happens in parallel to executing the next n units on the escalator on each block. The execution model in BaseApp is optimized for providing the lowest latency as possible. This model can also enable committing to an execution slot and revealing later.
A user with that prefers low latency can buy a top spot in the mempool.
This execution model is more flexible that the default model of the cosmos SDK.
There is also some additional work for MEV/ censorship countermeasures in the wider world.
-
Sikka is working on a threshold decryption execution module to enable submitting transactions that are only decrypted when 2/3rd of the validators agree on a block.
-
Injective is protocol is working a Tendermint Variant that uses VDF proofs to order transactions.
-
Timelock encryption with a VDF to enable a transaction be included in the chain and only decrypted afterwards.
It looks like very important advancement of tendermint. I think there should be some serious discussion about adopting these kinds of improvement on Tendermint master.
could you link me to the agoric’s approach on preventing censorship?
Thank you !
I’m not too sure if this is something you’re still interested in. We’re currently underway in implementing ABCI++ which I believe might unlock the potential to solve a lot of the problems around censorship resistance by allowing the application greater access to each of the consensus phases. I need to write up something that better explains this in depth. At the moment, the best I can offer is looking into this RFC: spec/004-abci++.md at master · tendermint/spec · GitHub. This will be in v0.36 of Tendermint (planned for Q1 of 2022).
