Hey there!

Since last time, I've mostly been reading, researching and writing, with the end result being two relatively long pieces:

• Thoughts on Address Space Extension (ASE)
• Mitigating Sandwich Attacks at the Protocol Level

Address Space Extension

As I said last, address space extension is the first step in the proposed state expiry scheme. I'd assumed, without thinking too hard about it, it was a relatively simple affair. But people had started looking at it, and it seemed there were quite a few issue. So I reviewed quite a few notes on the subject (listed at the top of my own note) to try to synthesize the state of things.

In particular, the key issue with extended addresses is interoperability. How can we ensure that either extended addresses can use old contracts designed for short addresses, or that it is a least possible to build bridges that enable interactions between both address spaces. The prime example here are ERC-20 tokens contract — it would be very inconvenient if long addresse were locked out of ERC-20 token ownership.

The first proposal was the translation map proposal, made by Vitalik. It enables seemless interoperability between long addresses and legacy contracts, but comes with a number of pitfalls. My post attempts to make those clear, as well as what the possible mitigations are.

Some feel ther eare too much issues with translation maps, and argue for not making legacy contracts interoperable with extended addresses, but allowing bridge contracts which are extendende-address-space contracts that can call out to legacy contracts.

The trade-off, as I note, is that bridges would make the migration to the extended address space slower — but it would avoid polluting with a lot of logic (and data — the translation map could be consequent in size) supporting backwards compatibility.

Mitigating Sandwich Attacks

Since I read so much about MEV, and found myself thinking about potential ways to mitigate it, I thought it would be a good use of my time to clarify my thoughts on the topic and share them.

I'll be lazy and copy the conclusion to my piece, you can read the whole thing here (if you have comments, send them here):

So, this was quite a bit of text. Besides brushing up on MEV basics, here’s what I hope to have accomplished:

• Made the point that sandwich attacks are the worst kind of commonly occurring MEV.
• Shown that there are many ways to mitigate against sandwich attacks today. Those might not necessarily be long-term stable, but it shows that the urgency of the problem might have been overstated.
• Proposed using a prioritized list of transaction along with a shuffled list of transactions as one idea on how to mitigate sandwich attacks.
  • Shown that this scheme can never truly avoid all sandwich attacks, although it effectively bounds the number of sandwich attacks per block, and make those attacks much more costly.
• Proposed using threshold encryption under PoS as one way to mitigate sandwich attacks
  • Here the concern is that of feasibility, given my relative ignorance of the details of PoS and threshold cryptography. Input greatly appreciated.
  • Go check Marcellus’ post for a similar idea with a bit more details: MEV mitigation protocol based on SSS
• Made the point that MEV democratization and minimization efforts are orthogonal.