There’s a concept in DeFi called “Miner Extractable Value” aka MEV. This is where miners are able to see transactions while they are still unconfirmed in the mempool and then frontrun those transactions to realize their value potential. I’d like to open a discussion about how we can prevent this issue on the rollup that Sovryn will be migrating to.
There’s a technique called threshold encryption that can be used to protect users from MEV so long as the rollup has multiple independent operators producing rollup blocks. You can learn about this threshold encryption technique here:
Thanks for the info! Couldn’t the rollup validator still frontrun the user, for example by replacing their transaction with another transaction with the same sequence number, and then forcing the user to re-submit their transaction with a higher sequence number?
the way that it works in sovryn-rollup is aggregation is permissionless and anyone can run an aggregator. Indeed the only benefit of posting your transaction through an aggregator rather than sending it to the L1 yourself is to amortize the fixed costs (e.g. Ethereum has a 21,000 base gas cost per transaction but rolup transactions are generally in the 2,000 gas range, so by batching you can reduce the overhead).
The sovryn sequencer is a privileged aggregator that can guarantee the ordering of its transactions and thus has the ability to put them ahead in line (in a short time window) of other aggregators’ transactions. So it can slow things down but not censor as anyone can post a transaction on chain that will be included.
Fair ordering protocols come in very useful for distributing the sequencer and making sure the sequencer cannot frontrun/reorder/extract MEV.
The initial sequencer will be run by us. So there won’t be frontrunning since we won’t do that but fair-ordering BFT gives you that guarantee without having to trust us at all.
We don’t love the idea that the sequencer can reorder transactions and extract MEV and we will therefore distribute the sequencer and use a fair-ordering BFT to ensure that the Sequencer does not re-order transactions.
a) Privileged sequencer
b) Fully decentralized transaction ordering
There are significant tradeoffs between these two modes. With the sequencer mode instant confirmations allow for rapid user interfaces and oracle updates which make a large number of new use cases possible, but a central party exists that can frontrun and delay transactions. In the fully decentralized model, transactions are simply ordered by the L1