If block producers do not know the nature of a transaction, it’s harder for them to discriminate against it. This is one of the reasons privacy-preserving transactions help with censorship resistance. However, these currently only really work for simple transfers and not for complex interaction with smart-contracts.
One way to take this idea and apply it to arbitrary transactions is to allow for encrypted transactions which block producers must later decrypt for the chain to advance.
This works as follow:
- A user picks uses RSA timelock encryption to encrypt a transaction and publishes the transaction.
- Block producers include the encrypted transaction, which has, at this point no effect.
- Block producers start cracking the timelock encryption.
- During that time, the user can submit of factoring of the RSA modulus and, absent censorship, it gets included, and the transaction can be decrypted and executed.
- After some configurable delay, say an hour, the block that appears on the chain must contain a the cracked key as well as a VDF proof that it is correct. At this point, the transaction is executed.
There are application to DEXes for this as well.
One variant is to not let the user chose the RSA modulus, which requires them to spend sometime computing the key. While this might seem strictly inferior, if ASICs appear that work with a fix RSA modulus, then that method will be applicable while the previous one wouldn’t.