search

serai-dex / serai

Other
263 stars 49 forks source link

Remove Substrate-level MEV via a threshold encryption scheme #94

Open kayabaNerve opened 2 years ago

kayabaNerve commented 2 years ago

We cannot prevent MEV on external TXs. If it sits in BTC for 20 minutes, anyone can frontun you. We can prevent MEV for pure-Substrate TXs with threshold encryption. Crypto2022 had the following paper on the topic:

https://eprint.iacr.org/2022/1066

I have yet to read it, and won't endorse it, yet wanted to note it.

While I don't care to do this at launch, I appreciate Substrate's modularity here and think a general pallet for it would be great.

kayabaNerve commented 2 years ago

https://eprint.iacr.org/2022/1002 as well which had similar properties, yet focused more on privacy overall than privacy until it hit the block (yet also offering order aggregation which was great).

Mikerah commented 1 year ago

There's also Ferveo that accomplishes the similar goals as the other constructions: https://github.com/anoma/ferveo

kayabaNerve commented 1 year ago

Mangata recently wrote a post about their own work, https://blog.mangata.finance/blog/2021-10-10-themis-protocol/

Their blog post is incomplete, leaving several questions. Security-wise:

The collusion of both Block builder and Block executor together. What is the direction of a solution for this problem?

Collusion should either introduce a direct punishment for the colluding parties or be detectable by any user. The exact solution will be introduced in a future protocol version.

They also detail some transactions being encrypted, and some not. If non-encrypted transactions have immediate execution, they may not be able to sandwich encrypted transactions yet MEV via:

is still possible. MEV solutions in general require in-protections TXs be ordered with non-in-protection protocols to prevent that.

I am still interested in the idea of non-encrypted solutions however.

If we solely accumulate transactions on chain over n blocks, where n is the amount of blocks for 34% of validators (by weight) to have participated in block production, we can use the BABE VRF (required to produced a block, not omittable) to then shuffle the accumulated transactions.

This would have a notable latency increase, and with it potentially notable economic impact, yet would potentially eliminate almost all MEV.

kayabaNerve commented 1 year ago

@Mikerah ferveo seems to be on a similar level of our DKG lib + theory of https://github.com/serai-dex/serai/issues/267 + basic code to that effect. Not to dismiss it, to note I'm unsure we have much to take from it.

It actually may have a slight issue from what I'm seeing... I'll have to spend a bit more time on their formalization to check if said issue exists.