Design considerations for elimination of MEV on Dynamo blockchain

Maximal Extractable Value (MEV) is widely considered by crypto developers and users to be a “bad” thing. MEV as a technology or technique by itself is neutral; it’s a programming construct which allows some users to gain efficiencies, primarily on a DEX, for trade execution. Some experts in the field consider it an “art form”, as a way of squeezing every last technical detail out of a system to force chain developers or other MEV users to a net zero. However, for the average user on a DEX, MEV represents an “unfair” practice within the general understanding of what the DEX should be doing.

MEV takes two predominant forms as of Jan 2023 — front running and sandwiching. Both of these algorithms rely on the public nature of the pending transactions in the mempool and their interaction with a DEX and specifically the Automated Market Maker (AMM) logic. This typically involves a user making a swap on the DEX, say (WETH for WBTC on Uniswap). Because the purchase will raise the price of WBTC due to the way the AMM works, a miner who is listening in on the mempool can identify the trade and then insert their own WETH/WBTC buy order right before the victim’s trade, then insert their sell order right after the victim’s trade. Assuming sufficient gas is remaining in the block, this is a riskless arbitrage and the victim paid a higher price than they would have if not for the MEV user. Highly centralized ecosystems have emerged on several blockchians which seek to address this issue, with varying degrees of success. However none of them are in-protocol or on chain as of the writing of this article.

There are two main schools of thought on how to address MEV: forced ordering of transactions and transaction hiding.

Idea #1 involves forcing an order of transactions based on a non-deterministic and unknowable identifier. This requires a two step process where the block is first assembled, the hash is created and then the block is reordered based on the hash or some other random data. For sandwiching, this means that it’s still possible, but the MEV user only has a 1/6 chance for the order of the execution to occur correctly — e.g. all three transactions have to come out as: MEV buy, victim buy, MEV sell. Any other order results in failed transactions and lost gas or even a loss by the MEV user. For pure frontrunning the MEV user has a 1/2 chance for the order to come out correctly, which could be net positive depending on the trades. So, re-ordering doesn't fully address the issue in the context of DEX trading and doesn’t cover other kinds of front running like NFT sales, lotteries, online games, etc.

Idea #2 is more complex, but does fully address all MEV attacks. This involves encrypting the transaction in the mempool upon submission, so that miners do not know the contents of the smart contract execution instruction. Encryption eliminates any “unfair” optimizations on a DEX, NFT marketplace or anywhere else. The miner simply doesn't have the information to take advantage of. Of course the transaction needs to be decrypted to execute the contracts in the block, however that does not happen until the POW puzzle is solved. In this design, the smart contract execution is encrypted in the wallet and sent to the mempool. Symmetric encryption is used with a one-time random key. The key is released via a gossip protocol some number of seconds after the transaction, which is then broadcast throughout the network. Miners can attempt to wait for keys before assembling a block, however they will be at a very significant disadvantage and likely lose most or all block rounds. After assembling the block of encrypted transactions the miner submits it to the full node for acceptance to the chain. Everything is pretty much as-is for a standard POW chain. The second step involves stakers decrypting and processing the blocks. Because Dynamo will be a hybrid POW/POS system, it is uniquely positioned to leverage stake operators as smart contract executors. As staking full nodes ingest new blocks, they will be tasked with decrypting and executing the contracts in the prior blocks.

Smart contract execution results in two general categories of updates: internal state update and external coin transmission. Internal state update occurs when the contract updates a stored value in the contract or accepts coins sent to it. An example would be when a user sends coins to a deposit contract which then stores the value of the coins for future use. External coin transmission occurs when a smart contract sends coins to a target address.

The internal state of smart contracts will be stored on staking nodes. Nodes will be responsible for keeping track of all smart contract balances and internal variables. Transmission of coins from smart contracts will be handled by miners when generating the coinbase transaction. When smart contracts determine that coins must be sent, entries will be generated in the mempool by staking nodes which miners will receive when solving the POW block. These special transactions will be generated by miners as a coinbase output.

Consensus on smart contracts will be maintained so long as 2/3 of the staking nodes, by staked coins, are honest. Sybil attacks are not possible, because the weight of a single node with 1,000 coins is the same as 1,000 nodes with 1 coin.

As each full node receives new blocks, the transactions in the block will be decrypted and executed in the order they are mined in the block. If a decryption key has not yet been received, the full node will wait for at most one more block before discarding the transaction. Disparities may arise in the number of transactions which were processed by full nodes, which can be resolved by consensus based on the number of smart contracts processed in a block (block with the most number of smart contracts executed becomes the winner), however all contracts must be executed within 2 blocks of being mined, so transaction submitters have an incentive to timely submit their release keys to have their smart contracts included in the chain.

This design attempts to account for all possible DOS attack vectors, however there is inherent complexity in any smart contract platform, and in particular, a smart contract platform based on a bespoke hybrid POW/POS system. Comments, thoughts and critiques are always welcome on our Discord at https://discord.gg/PxXxh8tGKj