Table of Contents:
-
Introduction
-
Encrypted Mempools
-
What are Time Encrypted Mempools
-
Questions
-
Enshrined PBS
-
How Frontrunning Happens
-
Conclusion
-
Appendix
-
Read more
Executive Summary
MEV - or Maximal Extractable Value - has exploded on Ethereum lately. And that's bad news for fairness and security as validators exploit transaction ordering for profit.
I analyzed some of the promising mitigation strategies emerging from the Ethereum community:
-
Encrypted mempools could obscure transactions before they get mined. Stops validators from spying to manipulate orders. It's still experimental but could handle truly malicious MEV if pulled off.
-
Enshrined Proposer-Builder Separation (ePBS) formally splits up ordering transactions and assembling blocks. Stops proposers from gaming orders and limits builders' power, too.
Other angles like MEV rebates and burning also look good to reshuffle incentives. But they need serious adoption to make a dent.
No one silver bullet, however.
So, I worked around on a hypothetical Mempool Encryption Protocol that uses encryption and proofs of publication to obscure transaction details from miners until block assembly, aiming to mitigate certain forms of MEV extraction.
However, decentralized key management, performance impacts, and integration with existing protocols present challenges to realizing MEP.
No single solution is perfect.
A layered strategy combining cryptographic innovations, protocol redesign, incentive tweaks, and social coordination is likely needed to stamp out the most abusive MEV over time.
Introduction
Miners and validators have the power to mess with the order of transactions in the blocks they produce. And some of them are totally abusing that power to game the system and score massive profits, which is so not cool!
They've cooked up tricky schemes like sandwich attacks to squeeze money from other users' transactions as they pass through. The more resources these players have, the more value they can "extract", as the nerds call it.
This whole sitch with "Maximal Extractable Value" - or MEV - is letting the big miners and validators concentrate power by playing these tricks to siphon value for themselves.
It's also mucking up prices across exchanges since MEV lets them arbitrage assets. Basically, it risks the fairness and security of everything Web3 stands for!
So taming MEV is mad important for protecting the crypto ecosystem. We need to rally as a community and find solutions to shut down these greedy extraction plays. It's the only way we can keep things decentralized and achieve the dream of an open financial system.
Many are trying and expressing solutions.
-
Encrypting the pending transaction mempools is one idea being worked on. That could stop miners spying on transactions pre-block.
-
MEV rebates and burning tokens are also on the table to limit profitability. And
-
ePBS allows users to simulate proof-of-stake effects on MEV extraction and test mitigation strategies.
But it's not all figured out yet. Making these solutions actually work smoothly in the wild is still tricky. The coordination and design isn't fully optimized to prevent manipulation just yet.
Inclusion lists and some fee market changes in ETH may help a bit too, but those also have downsides like centralization risks. No silver bullet yet.
The community is putting in the brainpower, though! With enough testing and collaboration, hopefully, the brightest Ethereum minds can tame this beast.
However, challenges around optimal design, coordination, and preventing manipulation exist.
What am I thinking?
There is good reason to be optimistic that MEV will become a solved issue for Ethereum in the not-too-distant future.
While challenges remain, the brilliant minds in the Ethereum community are actively developing and testing solutions that should effectively eliminate the most harmful forms of MEV.
-
Encrypted mempools - Flashbots prevent miners from seeing the contents of transaction pools, making many toxic forms of MEV like sandwich attacks infeasible. As encrypted pools become widespread, these attacks will fade away. Users need not fear being sandwich victims.
-
MEV rebates - Services like Flashbots share extracted MEV profits with users when transactions are reordered or bundled. This provides users with near-optimal pricing and execution. More MEV recirculates rather than being extracted.
-
MEV burn - Burning a portion of extracted MEV profits can enhance Ethereum's security by directing funds to things like mining rewards. It also smooths out harmful practices by reducing MEV profitability. This harnesses MEV to benefit the network.
-
Enshrine Proposer-Builder Separation (ePBS) - separate the roles of proposers and builders, where proposers order transactions and builders execute them into blocks.
-
Mempool Encryption Protocol (MEP): (Hypothetical) Use symmetric key encryption to encrypt transactions before they enter the mempool.
I don’t have any definitive insights or suggestions on how to make encrypting mempools a reality on Ethereum, but I’ve found some great research on how to make it to reality.
-
Time Encrypted Mempool: This proposal highlights important considerations like ensuring fairness, dealing with invalid transactions, and incentivizing miner participation. This proposal by Faraz Shaikh uses practical time lock encryption to encrypt transactions in the mempool so that only the miner or validator who is selected to produce the next block can decrypt them. This proposal claims to eliminate sandwich attacks and other forms of MEV extraction by hiding pending transactions from other miners or validators. However, it also acknowledges some of the challenges and open questions that need to be addressed, such as how to ensure fairness and randomness in block production, how to deal with invalid or malicious transactions, and how to incentivize miners or validators to participate in the encrypted mempool system.
-
Mempool Encryption Protocol: A hypothetical protocol (by yours truly) that uses symmetric-key encryption to encrypt transactions in the mempool so that only the intended recipient (the miner or validator) can decrypt them. This protocol leverages a public key infrastructure (PKI) to distribute encryption keys among miners or validators and uses a proof-of-publication (PoP) mechanism to ensure that encrypted transactions are broadcast to the network. This protocol claims to provide strong privacy guarantees for transactions in the mempool while preserving network efficiency and security.
-
ePBS: separate the roles of proposers and builders, where proposers order transactions and builders execute them into blocks.
I will only go into these three topics as I believe it is a never-ending discussion on why we need strategies to overcome MEV.
In my assessment, these solutions have the potential to not just mitigate but potentially eliminate the most pernicious forms of MEV.
Ethereum developers are demonstrating tremendous creativity in designing economic systems and clever cryptographic schemes to turn MEV from a threat into a productive force for good.
While more work remains, I am confident that Ethereum has the talent and drive to make MEV a non-issue through proactive innovation. The pieces are falling into place for Ethereum to once again convert a potentially existential challenge into a springboard for changing the game.
Here are some thoughts on how I see this issue evolving:
-
Encrypted mempools and inclusion lists seem handy for reducing shady MEV stuff short term. But the incentives to keep extracting value will probably keep evolving new tricks over time that need more responses. It's a game of whack-a-mole!
-
MEV rebates and burning are still getting off the ground. Their impact depends on folks actually using those systems at scale. Still, lots of unknowns if they'll curb extraction as hoped or just be a drop in the bucket.
-
Long run, making block production itself more decentralized could be key. Ideas like proposer-builder separation, randomized production, and getting more miners in the game all make MEV harder. Less room for big players to get sneaky!
-
There's probably social and cultural shifts needed too. If the community sees certain extraction practices as totally unacceptable, that stigma could help curb things. Norms matter! But I still believe if it can be done onchain (no matter if it’s ethical or not), there’s much less you can do to culturally stigmatize it.
-
And you know regulators will come poking around at some point as crypto goes mainstream. That could limit MEV through actual laws rather than just code. A double-edged sword, though!
Basically, we need technical fixes but also coordination and shifting incentives in the community.
My thoughts are purely speculative and hypothetical at the moment and do not reflect the actual state of affairs in Ethereum or the mempool.
But anyway, let’s get into it in detail.
Encrypted Mempools Are Still Experimental…
…that aim to encrypt transactions in the mempool so that only the miner or validator who is selected to produce the next block can decrypt them.
Some initial code exists in Geth, but wider adoption requires more testing and node coordination.
The goal is to encrypt transactions in the mempool so only the selected miner can decrypt them before block inclusion. This could prevent other miners from exploiting pending transactions, eliminating certain toxic MEV strategies.
But encrypted mempools aren't a silver bullet - they can't stop all MEV alone. Other techniques like rebates, burning, and whitelists are also being explored to mitigate MEV from different angles.
A major change would be needed in how transactions are propagated and ordered if mempool encryption is implemented. Impacts on efficiency, security, fairness require evaluation.
Sandwich attacks would be prevented but miners may still find creative extraction methods even with encryption. Incentives for MEV likely remain.
Bigger miners decrypting faster could centralize power - but tricks like delayed decryption could help level the playing field.
Encrypted mempools use a verifiable delay function (VDF) to ensure that the encryption key is only known to the elected miner at the block production time.
There are nuanced decentralization tradeoffs to assess - no solution is perfect.
What is Time Encrypted Mempool?
The core idea is to use timelock encryption to encrypt transactions in the mempool.
-
When a user sends a transaction, they first encrypt it using the miner's public key and a timelock. This timelock ensures the transaction can only be decrypted after a certain point in time in the future.
-
The user sends this encrypted transaction to the mempool, where it sits opaque to other miners who cannot decrypt it before the timelock expires.
-
When the block production time comes, only the elected miner will now hold the private key required to decrypt transactions in their allotted time window.
-
This miner then decrypts transactions, produces a valid block, and publishes it to the chain. The transactions get executed without other miners seeing their contents beforehand.
-
To make this work, there needs to be a Public Key Infrastructure (PKI) that allows mapping future block times to miners' public keys. Keys can rotate as miner selections change.
-
There also needs to be a way to verify transactions have been correctly published in the encrypted mempool, even if their contents are opaque. The proposal suggests using zero-knowledge proofs for this.
-
Penalties can accrue to miners who fail to publish encrypted transactions or who decrypt them before their allotted time window. This disincentivizes ignoring or manipulating encrypted transactions.
Overall, this approach could effectively eliminate sandwich attacks and reduce extractable value by hiding mempool transaction details from all miners except the specific producer of the next block.
The key challenges are managing the PKI, ensuring miner fairness, and facilitating network propagation and verification of opaque encrypted transactions.
---
The concept of Time Encrypted Mempool was also explored in this research paper. The paper proposes and explores randomized permutations to shuffle the order of transactions in a committed block, providing multi-layer protection against MEV.
The paper also presents BlindPerm, a framework enhancing an encrypted mempool with permutation at no additional overheads.
The goal of BlindPerm is to enhance the fairness and security of the cryptocurrency ecosystem. The paper discusses the design, implementation, and evaluation of BlindPerm, as well as its potential applications and limitations.
---
Now, How can the validity of transactions be verified if the miners or validators who are supposed to include them in a block cannot see their contents due to encryption and cannot check if they comply with the ledger/settlement rules?
I thought about this a lot.
Validating encrypted transactions remains an open challenge given the inability to inspect contents pre-inclusion. Timelock encryption enables decryption later but does not itself prove validity. Approaches like zero-knowledge proofs and commit-reveal schemes show promise, but have limitations around efficiency, soundness, and fraud risks.
To supplement cryptography, new hardware solutions could help. Trusted execution environments like Intel SGX provide secure enclaves for code execution. Block producers could utilize these to validate transactions confidentially. However, potential vulnerabilities exist.
Another option is outsourcing validation via optimistic rollups. Rollups batch transactions and generate validity proofs off-chain. This reduces on-chain burden, but rollup operators must be trusted.
Shard chains in Ethereum 2.0 could also assist. Transaction validity could be confirmed on a specific shard pre-inclusion on the beacon chain. However, complexity is added with cross-shard communication.
No single solution is perfect. A hybrid model combining upfront computational checks, fraud-proof cryptography, hardware-assisted validation, and shard chain verification may provide the right tradeoffs. Continued research into stateless clients and fraud proofs can enhance efficiency and security.
Economic incentives like staking deposits for good behavior are important too. The validator reward structure could be adapted to strongly disincentivize the inclusion of invalid transactions.
A nimble, layered strategy is likely optimal vs. a single solution.
There are clear trade-offs between privacy and verifiability. An optimal solution may use a combination of pre-encryption checks, zero-knowledge proofs, post-decryption sampling, and accepting a small error rate to limit exposure of transaction data before block production.
Another question…
How would encrypted mempools impact existing protocols like gas auctions, transaction replacement, etc.?
Encrypted mempools will shake things up for some of the common transaction protocols used today.
-
Miners bidding on gas prices? Not possible if they can't peek inside transactions.
-
Users doing last-minute replacements to boost fees? Also out the window without visibility into pending txs.
Censoring transactions by analyzing their contents gets shut down too. No more blocking txs based on what they contain.
And frontrunning by inspecting transactions in the mempool? Done and done with encryption hiding the details.
Even transaction priority schemes like using account nonces go down the drain when contents are obscured. External observers lose insight into things like wallet relationships as well when encryption enters the picture.
Heck, even spam prevention gets tricky when you hide where transactions are coming from using encryption. Lotta protocols need rethinking to work properly with encrypted mempools.
But don't panic, there are fixes on the horizon! Separating out priority metadata so it's not encrypted could help. Moving sorting and inclusion logic outside the mempool is another option. Clever cryptographic schemes can allow replacement without peeking.
And you know, just tweaking fee structures to include fees upfront opens up possibilities too. Just needs some creative thinking and testing different ideas out.
The path forward may involve some trial and error, but I'm confident we'll figure out how to make these protocols mesh with mempool encryption in the end!
Another proposal that was shared was about Enshrine Proposer-Builder Separation (ePBS)
ePBS was proposed by Mike Neuder and Justin Drake to separate the roles of proposers and builders, where proposers order transactions and builders execute them into blocks.
---
Proposal:
Currently, mev-boost implements PBS out-of-protocol and relies on centralized relays. Enshrining PBS (ePBS) would evolve the consensus protocol to natively support PBS.
Arguments for ePBS:
Relays are centralized and oppose Ethereum's values of decentralization, censorship resistance, and trustlessness.
Out-of-protocol solutions like mev-boost are brittle, as shown by recent exploits and bugs.
Relays are expensive to operate as public goods without a clear funding model.
Arguments against ePBS:
mev-boost works well currently, so no need to make a big protocol change yet.
Other solutions, like transaction-level protections, may reduce need for PBS.
Many other protocol changes have higher priority than ePBS.
Unclear what exactly should be enshrined given different PBS design options.
Desirable properties of an ePBS mechanism are outlined, including security for honest builders/proposers, permissionless participation, and censorship resistance.
A sketch of a possible ePBS design called Two-Block HeadLock (TBHL) is presented, which modifies the existing two-slot PBS idea.
TBHL uses two blocks per slot - a proposer block and builder block. It aims to provide the desirable ePBS properties.
Optimistic relaying is proposed as an incremental approach to evolve mev-boost towards ePBS without needing client upgrades initially.
So, in summary:
mev-boost: Out-of-protocol PBS through centralized relays
ePBS: Baked into the protocol itself, with direct on-chain coordination
Enshrining PBS aims to move what mev-boost does off-chain into an official on-chain protocol mechanism.
---
With ePBS, the roles of transaction proposer and block builder are split between different validator nodes in Ethereum's proof-of-stake consensus protocol.
Specifically:
-
Proposers are responsible for selecting valid transactions, ordering them optimally, and passing this ordered list to the builder.
-
Builders take the proposed transaction list and assemble it into a proper block by assigning identifiers, calculating gas, finalizing headers, etc.
-
Crucially, builders have no discretion over transaction order - they must respect the sequence submitted by proposers.
This separation of duties reduces the ability of miners or validators to engage in MEV strategies since:
-
Proposers cannot bias transaction order for profit if they don't control block assembly.
-
Builders cannot shuffle transactions or censor selectively since they receive a pre-defined order.
For example, suppose a miner wants to frontrun a transaction by reordering it behind their own. They could manipulate the sequence with integrated proposing and building to enable this.
But with ePBS, the proposer would submit the frontrun transaction first. The builder must then include it in that order, eliminating the MEV opportunity.
By dividing these roles, ePBS structurally restricts the ability of miners and validators to extract value through transaction ordering. It directly closes off a key MEV vector - the ability to bias sequencing during block production.
A detailed example:
Suppose I buy 350 UNI tokens on Uniswap for 1 ETH. I send this transaction (Tx1) to the mempool with 1 ETH + gas fee.
A miner sees Tx1 and wants to frontrun it to earn arbitrage profits. So they send a transaction (Tx2) buying 350 UNI at a lower price first.
Without ePBS, here is how the miner could frontrun:
-
As both proposer and builder, the miner selects pending transactions for their block.
-
They reorder transactions, putting their Tx2 ahead of the original Tx1.
-
As builders, they assemble the block with Tx2 first, then Tx1.
-
When the block is produced, their Tx2 buys UNI before the user's Tx1, letting them profit on arbitrage.
But with ePBS, here is how frontrunning is prevented:
-
An impartial proposer selects valid transactions like Tx1 and Tx2 based on arrival time, fees, etc.
-
The proposer orders them chronologically, with Tx1 first since it arrived before Tx2.
-
This ordered list gets passed to the builder.
-
The builder must respect the sequence given by the proposer, assembling the block with Tx1 first.
-
When produced, the user's Tx1 buys UNI at the intended price before the miner's Tx2. No opportunity for frontrunning profits.
By separating proposer and builder roles, ePBS removes miners' ability to manipulate orders for profit. The builder cannot reorder, and the proposer has no incentive to sequence transactions unfairly. This prevents abusive strategies like frontrunning.
With ePBS, this kind of frontrunning attack would be much harder to execute because:
-
Proposers cannot bias transaction orders for profit if they don’t control block assembly. They would have to collude with builders to execute such an attack, increasing the cost and risk of detection.
-
Builders cannot shuffle transactions or censor selectively since they receive a pre-defined order from proposers. They would have to reject the entire block proposal or modify it significantly to execute such an attack, which would also increase the cost and risk of rejection by other validators.
-
Users can choose which proposer to submit their transactions to based on their reputation and fee policy. They can also use encryption or commit-reveal schemes to hide their transaction details from other proposers or builders until they are included in a block.
I worked around a hypothetical protocol: Mempool Encryption Protocol (MEP)
How the (hypothetical) Mempool Encryption Protocol (MEP) would work to provide privacy for transactions in Ethereum's mempool:
-
MEP uses symmetric key encryption to encrypt transactions before they enter the mempool. The encryption keys are distributed to miners through a Public Key Infrastructure (PKI).
-
When a user wants to send a transaction, they request the public encryption key for the next scheduled block producer from the PKI.
-
The user encrypts their transaction using this public key, so only the designated miner can decrypt it.
-
The user also generates a proof-of-publication (PoP) by hashing the encrypted transaction. This PoP gets broadcast to the entire network.
-
Miners see the PoP and can verify the transaction was published but cannot view the actual contents pre-decryption.
-
The scheduled block producer decrypts transactions in their allotted time window using their private key and includes them in the produced block.
-
After the block is propagated, the network can verify the PoP matches the now-revealed transactions, ensuring they were correctly published earlier.
-
Invalid transactions would show a mismatch between the published PoP and the revealed transaction at block publication time.
-
The PKI rotates encryption keys to each block between scheduled block producers to maintain privacy.
This protocol prevents mempool front-running and censorship while still allowing transaction propagation and verification of correct publication via the PoP mechanism.
The key challenges are the performance impacts of encryption and propagating opaque transactions, plus building a decentralized PKI model that resists manipulation.
The Mempool Encryption Protocol (MEP) is an important privacy innovation for blockchain networks like Ethereum.
Here are some of the key benefits that mempool encryption provides:
-
Prevents front-running - Encrypting transactions in the mempool hides their contents from other miners/validators. This prevents them from front-running trades or reordering transactions to extract value.
-
Reduces censorship - Miners cannot selectively censor or ignore encrypted transactions since they don't know the contents. All properly published transactions have to be included.
-
Enhances privacy - User balances, activity, and connections between addresses are obscured when transactions are encrypted until reveal time.
By enhancing privacy, security, and fair access to blockchain transaction ordering, the widespread use of MEP can remove major pain points and risks for users. Mempool encryption is a pivotal development for blockchain scalability, decentralization, and real-world adoption.
By the look of it, encrypted mempools are a pretty legit idea in theory. Privacy and sticking it to miners? I'm so here for that! This is complex stuff to deploy IRL.
Sure, the crypto fits on paper, but scaling encryption without choking the Ethereum VM? Beyond non-trivial.
And opaque transactions just open the door to spam-lords and trolls without hardcore improvements to block propagation tools and watchdog protocols. Not a great look.
And even if you solve all that, preventing hackers and manipulation in PKI management requires breakthroughs in decentralized identity and collective action. That level of global coordination feels aspirational, TBH.
Some questions:
-
How would the PKI distribute encryption keys among miners or validators in a decentralized and secure way? Who would run the PKI, and how would they prevent malicious actors from obtaining encryption keys?
-
How would the PoP mechanism work, and how would it prevent double-spending, replay, or invalid transactions? How would the network verify the PoP without decrypting the transaction?
-
How would the encryption affect the network efficiency and security? How would it impact the gas price, block size, and block time? How would it interact with other protocols and features of Ethereum, such as EIP-1559, sharding, rollups, etc.?
-
How would the encryption affect the user experience and privacy? How would users obtain and manage their encryption keys? How would they estimate their transaction fees and confirmations? How would they deal with errors or failures?
Building out something as complex as MEP in a decentralized way won't be a walk in the park, that's for sure! Distributing those encryption keys securely without some central authority is going to take some wizardry.
Threshold signatures, random functions, decentralized IDs - those could maybe do the trick. But we'll need air-tight policies and hardware to stop key leaks too.
And how can we prove transactions are valid before they're unveiled on-chain? ZK proofs, commit-reveal schemes, fraud proofs - those might help validate without the details getting out early. We'd need to sort out things like preventing double spends and replay attacks though.
Performance and scaling will need a deep dive too. What'll encryption do to transaction sizes, speed, fees? How does it play with rollups and shards? Testing will be crucial to get a handle on impacts.
Encryption's complicated - we need to hide that complexity behind smooth wallet integration and meta transactions. Fee estimation and confirmation times may get fuzzy, too - we'll have to get creative on new patterns there.
Lots of angles still need thoughtful minds to hash through for sure. But between the crypto masters, Ethereum geeks, and wallet hackers out there? I'm optimistic we can sort out secure and usable encryption for Ethereum's mempool. Exciting challenges ahead!
To Compare the Two Solutions:
Examples of how frontrunning happens through a flash loan attack
1. JPEG’d was exploited because of a faulty curve contract,
2. Conic Finance was Drained of $3.3M just last month
3. Themis Protocol was also Exploited
You can find many more examples of this if you go through my X profile.
Final Thoughts:
If left unchecked, MEV seriously threatens the fairness, security, and decentralization of blockchain networks like Ethereum. However, promising solutions are emerging to mitigate the risks and impacts of MEV.
Technical proposals like encrypted mempools, MEV rebates/burning, and enshrined proposer-builder separation (ePBS) aim to directly reduce the incentives and ability for miners and validators to extract profits through transaction ordering manipulation. These potential solutions require further testing and refinement to ensure optimal security, efficiency, and decentralization tradeoffs.
Beyond technical measures, community coordination and evolving social norms will likely play a key role in stamping out the most abusive MEV practices over time. If manipulation techniques become culturally unacceptable, this can disincentivize their use. Regulatory frameworks may also eventually restrict MEV as blockchain adoption grows.
A layered strategy should be pursued, combining cryptographic innovations, protocol redesign, incentive tweaks, social factors, and regulatory oversight where appropriate. Each solution will address MEV partially on its own - a holistic and nimble approach is needed.
With continued research, development, and collaboration, solutions can be devised and implemented to eliminate the most harmful forms of MEV. This will help fulfill the promise of an open, decentralized financial system where users can trust in fairness and resistance to manipulation. Taming MEV is a pivotal challenge on this journey that the Ethereum community is positioned to overcome through persistent innovation.
Appendix
-
Sandwich attacks: Sandwich attacks involve a miner or validator placing their own transactions before and after a target transaction they want to exploit. For example, suppose a user transaction will cause a token price to rise. The miner could place buy transactions before and after the user's transaction to buy the token at a lower price thanks to the user's transaction. By sandwiching the target transaction between their own, the miner profits from the price impact of the user's trade.
-
MEV rebates: It would be more accurate to say, in general, that services using MEV rebates provide users with better pricing and execution on trades rather than direct profit sharing. For example, a user submitting a trade through a relay utilizing MEV rebates may get a better token price than submitting to a regular miner pool. This comes from the relay using MEV to optimize trade sequencing. But the user does not directly receive a cut of the MEV profits - they just benefit indirectly through better pricing and execution quality.
-
ePBS background: For clarity, ePBS aims to move the existing mev-boost PBS implementation from being an off-chain coordination mechanism into an on-chain protocol mechanism. PBS itself is not a wholly new concept introduced by ePBS - services like mev-boost already exist to separate transaction proposer and block builder roles. ePBS seeks to transition this existing idea into an official protocol-level change rather than relying on external relay coordination.
-
Timelock encryption: A more precise explanation would note timelock encryption relies on verifiable delay functions (VDFs), not just generic timelocks. VDFs use sequential steps that take a predefined amount of time to compute in order to prevent early decryption. This ensures the encryption can only be decrypted after the intended delay, even if the miner uses significant computing power to try to decrypt early.
-
MEP speculative: MEP explanation is hypothetical and speculative. It would be better to focus on real existing proposals rather than outlining a speculative protocol concept. The core ideas around encryption tradeoffs and challenges are clear without the detailed MEP protocol invention.
Read more:
Thank you for reading through, and subscribe below for regular post updates.
I’d also appreciate it if you shared this with your friends, who would enjoy reading this.
You can contact me here: Twitter and LinkedIn.
You can also buy my keys at friend.tech by searching for 0xArhat.
If you find this deep dive analysis useful, please consider donating to 0x1de17b6c736bcd00895655a177535c2a33c6feba (Arbitrum, Ethereum, Optimism) and/or by minting an NFT for this & other blog posts by me.