Zeeve
The concept of decentralization that established a financial system which is worth roughly $2 Trillion in just over a decade sounds simply majestic. However, the rate of adoption has triggered the need for alternate scaling solutions to help match the demand. That’s how layer2s like rollups came into the picture.
But, in doing so, the ecosystem has been exposed to an erstwhile risk termed MEV attacks, which are compromising the ethos of decentralization yet again. In this article, we will dive deep to understand what MEV is and what the way out is to deal with the same for Layer2s.
This is quite important to discuss as the risk of MEV extraction is higher in layer2s compared to what it is in L1s.
In its erstwhile pristine form, MEV stood as Miner Extractable Value, where the miners would request transaction fees and block rewards as their motivation to mine the blocks. However, over time, the concepts were rescripted in a manner that compromised decentralization principles of transparency, privacy, and trustlessness when miners/validators (In PoS) started to arbitrarily reorder transactions by resequencing them in a manner that could trigger front-running and back-running, which caused serious harm to the users.
Hence creating negative sentiments around MEV even though blockchains shifted from PoW to PoS. But can’t we not just do away with the MEV? Why embrace it if it is evil?
Because MEV is a necessary evil that cannot be ignored. Why? Despite many MEV attacks like this one that happened in 2023, which had cost users a loss of $20 million, it is turning out into a necessary evil because a permissionless blockchain to prevent spamming on its network which might significantly increase the network activity and prohibit transactions, MEVs play a key role. Without an MEV, we might see the problem of Priority Gas Auction.
Yuga Labs OtherDeed’s Land Sale is a perfect example to quote here. In the absence of a specific sale format, the users had inundated the network with spammy transactions requesting inclusion for a gas fee of 2 ETH; however, all those transactions failed eventually, which significantly impacted the UX on the Ethereum blockchain. MEV averts this but it creates more problems than it solves in a rollup environment. How?
In the rollup environment, the core objective of the ecosystem is to provide near-infinite scalability to the network. However, to do that, they have to settle for a single operator/sequencer, which should ideally arrange all the transactions as they occur. However, instead of that, what the Bots do is sniff out the possibility of a profit since they can easily see the content of the transaction, whether it is a buy or a sell. Now, what the bot would do is place a transaction immediately before or after the transaction to extract maximum value.
For example, if there’s a huge purchase of an asset x for example which will increase the price. The bot would place a transaction immediately before that transaction to maximize bulk purchases and sell the token thereafter. So, a transaction is placed before the victim transaction and after the victim transaction. In this way, the user might lose a lot of money and opportunity if the rollup continues to do that. We have already seen such happenings where the users have lost over $25 M in funds due to the sandwich attack.
What if the roll-up environment wishes to avert the same through a FIFO approach? It will be a two-edged sword for the rollup ecosystem because while using the FIFO method, the rollup must include all transactions as they occur. Now, the drawback of this approach is that ideally, it is not necessary that all the transactions that are ordered in a sequence would help extract maximum value. So, it might be the case that the rollups blockspace might remain underutilized while it has to process the transaction. In this way, it will make the efforts of sequencing disincentivizing. The need of the hour, as a result of rollups is to devise a solution that safeguards the interest of the chain along with the users.
Through decentralized sequencers, it is possible to arrange transactions, restoring trust and transparency based on consensus instead of centralized sequencers dominating the array of arrangements of the transactions. Along with this, decentralized sequencers also protect the rollup environment against single point of failures and malicious intrusions which protects the network against the MEV attacks.
As you can see from the above image, decentralized sequencers impart a trustless environment, immutability, censorship resistance, resistance to a single point of failure, and reduced intermediaries, which establishes a very high trust element but ideally achieves the same. They also expose one key point of failure, which is high latency and increasing cost because consensus from multiple nodes participating in the auction to finalize an order might slow down the process and compromise the scalability. Plus, a decentralized sequencer might not be necessary for all applications.
There are many tools that can help you deal with MEV attacks, like TX Relay APIs and RFQs, but what Shutter is doing is something that one should look forward to. Let’s see how Shutter is helping deal with the MEV attacks on rollups without using any decentralized sequencer sets.
Shutter Network is all set to provide MEV protection to all the rollups on the Ethereum chain through its Distributed Key Generation (DKG) scheme in its rollup sequencer mechanism. With this upgrade, all the information passed to the sequencers through the mempool by the searchers is encrypted through Dark Forest until it passes the sequencer step. The Dark Forest will run all the transactions in the order of the encryption-proof keys in the following manner.
Source: Shutter Network
Now, these encrypted keys will be shared with the Keypers responsible for assessing the authenticity of the order of the transactions. If they find that any transaction is off-track or not in order, they will run the proofs and match the same with the Merkle Hash and followed by that, it will be added to the block. Now, the rollup environment will check the batches and match the same with the DKG or Distributed Key Generation Protocol, and if they are in order, it will trigger the state change on the rollup. Now, if some of the rollups, if they are using a different sequencer set, they will have to decentralize their sequencer sets using the Shutter DKG else they will have to compromise on latency because shutterized rollups give the privilege of using a centralized rollup solution without compromising on security and privacy.
Want to integrate tools like Shutter Network with your Optimistic or ZK Rollups chain? Zeeve integration partners let you do that. Instead of building naked rollups, you can augment your rollup capabilities with easily pluggable components like Alt data availability layers, shared sequencers, decentralized oracles, account abstraction SDKs, indexers, and many more additional integrations. You can choose to build with any rollups framework using Zeeve Rollups-as-a-Service, including Polygon CDK, zkStack from zkSync, Arbitrum Orbit, or OP Stack, and choose your other modular components. Zeeve also offers a 1-click sandbox and fully managed deployments for rollups and appchains.
Have further questions? Not quite sure what infrastructure might suit your needs? Reach out to us. Our experts can help you decide based on your needs.
