MEV (6): A Fairer MEV Ecosystem (middle)

Reading Tips

· Before reading this article, you need to have a basic understanding of MEV

· Be familiar with Ethereum transactions and understand what a transaction contains and how it is eventually included in the block

· Know Merkle Tree and the role of zero-knowledge proof

· click to read: MEV (5): A fairer MEV ecosystem (Part 1)

The previous article introduced (1) the Flashbot SGX Builder design, which increases the fairness of Block Builder through trusted hardware, and (2) the Chainlink FSS design, which prevents MEV by decentralizing transaction ordering roles.

This article will discuss (3) the design of Encrypted Mempools, which aims to reduce or eliminate MEV by providing privacy for transactions through cryptographic methods.

Encrypted Mempools

Two goals: MEV protection and censorship resistance

If there is a tool that allows users to encrypt their transactions before broadcasting them, and decrypt them only when they are included in the block, users will not have to worry about being affected by MEV. The MEV Searcher cannot see the transaction content at all, and users do not need to worry about their transactions being denied income due to being targeted by proposers or violating government sanctions. The cornerstone of building this tool is cryptography.

Encrypted Mempools utilize cryptography to (1) encrypt the user’s transaction content to protect their privacy, and (2) verify the validity of the transaction when it is encrypted, preventing attackers from generating a bunch of invalid but encrypted transactions. This prevents them from launching a DoS attack on the chain, as the Proposer would waste block space by including a bunch of invalid transactions that are only discovered at the last moment.

Reading tip: Mere encryption cannot fully ensure resistance to censorship, because the Proposer who wants to censor can still refuse to accept any encrypted transactions, so encryption only increases the cost of censorship (the Proposer gives up the handling fees for all encrypted transactions). To achieve better anti-censorship protection, you need to use an Inclusion List such as PBS.

Ensure transactions can be decrypted (Guaranteed Decryption)

After encrypting the transaction, it is important to ensure that it can be decrypted. Failure to do so can create a vulnerability in a Denial of Service (DoS) attack. In such an attack, the attacker repeatedly sends encrypted transactions that cannot be decrypted. As a result, the node must retain these transactions until they expire, leading to a buildup of these useless transactions in the node’s transaction pool.

There are some ways to ensure that transactions can be decrypted:

1. Pure trust (In-flight)

2. Trusted Hardware, Enclave

3. Threshold Encryption/Decryption

4. Delay Encryption/Decryption

5. Witness Encryption/Decryption

△ Several ways to ensure that transactions can be decrypted and their examples. The complexity increases from left to right, with pure trust being the simplest and witness decryption being the most difficult.

Image source:https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

Can the commit-reveal mechanism also achieve the same purpose? The user begins by inputting their transaction content into a hash function to obtain a hash value, known as the commitment. Once the proposer guarantees the inclusion of the user’s transaction commitment in the block, the user proceeds to disclose the complete transaction content.

Reading tip: The way of commitment can be like the Proposer in PBS promising that it will be included in the Builder block through signature. It is a guaranteed commitment. If the Proposer violates the promise, it will be punished.

△ Proposer promises to receive the Commitment of Alice’s transaction

Although Commit-reveal and encryption can serve the same purpose of hiding user transaction content and preventing MEV extraction and censorship, Commit-reveal cannot guarantee decryption since the power lies in the user’s hands. The user has the choice to not reveal the content, whether intentionally or unintentionally.

Requiring users to attach a deposit and forfeiting the deposit when they end up with no Reveal can worsen the already poor user experience of Commit-reveal.

△ Alice does not need to reveal her transaction

1.Pure trust (In-flight)

The user encrypts the transaction and sends it to the centralized role. The centralized role then decrypts the transaction and ensures that it will not be leaked before being included in the block. Users generally trust the centralized role and consider transactions as encrypted until they are included in the block, even though the centralized role decrypts the transaction immediately after receiving it.

Reading tip: This centralized role would be, for example, PBS’s Builder, Proposer, or Rollup’s Sequencer/Operator.

2.Trusted Hardware, Enclave

It works the same as pure trust, but better than pure trust because users trust a trusted hardware and the program code it executes, rather than trusting a person, an organization or a company.

3.Threshold Encryption/Decryption

Chainlink FSS also uses threshold encryption and decryption, but in Chainlink FSS the managers of the threshold keys are Oracles of Chainlink, while in Encrypted Mempools the managers (called Keypers) may be Validators of L1 or L2 (assuming L2 also has In the case of decentralized Validator).

Threshold encryption/decryption has several disadvantages:

• Strong honest majority assumption: It must be assumed that more than half of the Keypers are honest. If they are dishonest, they can decrypt and see user transactions at will, review the transactions, or extract the MEV of the transactions.
• Lack of accountability: As long as a sufficient number of Keyper participants collaborate, they can decrypt the information. However, when Keyper participants conspire, we have no way of knowing which ones are involved in the conspiracy. Without being able to identify the malicious actors, it is impossible to design a punishment mechanism for Keyper. Therefore, we must rely on the assumption that the majority of Keyper participants are honest.
• Weakened liveness: Excessive Keyper offline will result in insufficient online Keyper count, which will prevent decryption and block production. This will cause the chain to come to a halt. This conflicts with the Ethereum PoS mechanism, which emphasizes that the chain will continue to produce blocks even in the event of a third world war, and eventually achieve finality. It can be inferred that the probability of Ethereum PoS using decryption with a threshold is not high.

Because threshold encryption and decryption requires a lot of changes, L2 is more suitable for this approach than L1.

This article proposes the design and considerations for implementation in L1. Projects that are testing this design can refer to Shutter Network. For more information, please check:https://ethresear.ch/t/shutterized-beacon-chain/12249

4.Delay Encryption/Decryption

Delay encryption ensures that the ciphertext can be automatically decrypted after a certain period of time. However, the decryption process is not truly automatic and requires someone to act as the decryptor and perform continuous computations. After a certain period of time, determined by the difficulty of the encryption, the computations can be completed and decryption can be successfully achieved.

The concept behind delay encryption is similar to Verifiable Delay Function (VDF), both of which belong to the family of Time-release Cryptography.

VDF allows us to quickly verify F(x): a “time-consuming sequential computation” result. This is similar to Proof of Work (PoW), but VDF’s computation is a sequential process, unlike PoW, which can be accelerated through parallel computing. The decryptor of VDF can only perform repeated computations step by step.

△ With VDF you can verify the result of a calculation that took me 10 seconds to complete in, say, 0.01 seconds, and I had no way to parallelize my calculation. Image source:https://techtelegraph.co.uk/verifiable-delay-functions-on-bitcoin

Delayed encryption and decryption are also continuous calculations like VDF, and cannot be accelerated through parallel operations. However, it must be considered that someone will speed up the decryption process through hardware optimization. Therefore, if you want to adopt this technology and apply it in an actual public environment, you must ensure that no one has a huge hardware gap and can complete the decryption in advance (and the decryption is done in private, so it is difficult to detect).

Currently, Ethereum Foundation and Protocol Labs are already collaborating on VDF ASIC chip research, hoping to export the most advanced computing hardware to the market, so that no one can have disparate hardware advantages and secretly decrypt in advance. To learn more, please check: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

Reading tip: VDF can also be used to increase the unmanipulability of Ethereum’s random numbers.

The advantage of delayed encryption and decryption compared to threshold encryption and decryption is that it does not need to trust or rely on the normal operation of a group of Keypers, and it will automatically decrypt when the time is up. However, this imposed decryption time is also a disadvantage of delayed decryption: encrypted transactions must take a period of time to be decrypted, which means that there is a fixed delay time for user transactions to be uploaded to the chain. In addition, hardware competition is also a risk that cannot be ignored in this method. It is difficult to know whether anyone has developed a faster chip to decrypt.

5.Witness Encryption/Decryption

Imagine that a ciphertext is not decrypted by a key or sequential computation, but can only be decrypted when a certain “condition” is met, such as “when this equation is solved” or “when this equation is solved” Once the ciphertext is included in the block, the ciphertext can be decrypted and so on.

Reading tip: “Knowing the key to decrypt a ciphertext” or “knowing the results of continuous calculations” is actually a condition.

Through witness encryption, we can not only achieve the effects of threshold encryption and delayed encryption, but we can also combine these two decryption methods. For example, we can set the conditions as “Condition 1: ‘A group of Keypers agree to decrypt this ciphertext’ or Condition 2: ‘After five minutes’”: If all Keypers are online, we can quickly meet Condition 1 to decrypt the ciphertext. However, if there are not enough Keypers online, we can at least ensure that we can meet Condition 2 and decrypt by proving through VDF that “five minutes have passed”.

△ Enough Keypers can be decrypted online (above) or after enough time (below)

As long as the conditions are proven to be met, decryption can be achieved. The proof can be done through methods such as zero-knowledge proofs, which can efficiently verify complex computations (assuming the operations required for proving the conditions are complex) or hide information (assuming the prover does not want to reveal certain information during the proof process). However, although witness encryption is very powerful, current technology is not sufficient to provide any practical use.

△ The maturity of different encryption and decryption technologies. Witness encryption and decryption (Witness) is not mature enough. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Manipulate and perform operations on ciphertext through homomorphic encryption

The previous paragraphs introduced different ways to ensure that transactions can be decrypted, but when can transactions be decrypted? The answer is: after the transaction is included in the block and the order is determined. But how does Block Builder assemble a block from a bunch of gibberish, or even efficiently assemble a highly profitable block? The answer is: Homomorphic Encryption (HE).

△ Example of homomorphic encryption used for voting: The content of the vote has been encrypted, but the ciphertext can still be summed and decrypted after the result is calculated. Image source:https://twitter.com/khushii_w/status/1660278622291210242

Reading tip: If encryption and decryption are performed through pure trust (in-flight) or trusted hardware, it does not actually wait until the transaction is included in the block and the order is determined before decryption. After all, everyone trusts the other party, so it will decrypt and sort the transaction immediately after receiving it. This can speed up the formation of blocks and does not require additional resources to perform homomorphic encryption operations.

Through homomorphic encryption, we can perform operations on ciphertext without decrypting the transaction. We can apply the operation process of arranging transactions and forming a legal block to these encrypted transactions without decrypting the transaction, and obtain an encrypted transaction. block. When the block is decrypted, we will get a complete and legal block, in which the transactions are decrypted and sorted in the order before encryption.

△ Through homomorphic encryption, Block Builder can assemble a complete and legal block from encrypted transactions

Reading tip: There are levels of homomorphic encryption, such as partially homomorphic encryption (Partially HE) and fully homomorphic encryption (Fully HE). Partially homomorphic encryption can only add or multiply ciphertext, while fully homomorphic encryption can add and multiply ciphertext (basically, any operation can be performed).

△ The third column: The maturity of different encryption and decryption technologies supporting FHE. Except for in-flight and enclave, which do not require HE and are therefore considered supported, the others are not yet available. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

The above introduces different mechanisms for encrypting and decrypting transactions. Each of them has different advantages and disadvantages, but in the end, all they can do is hide the transaction content and ensure that it can be decrypted when the conditions are met. Once the transaction content is hidden, it can avoid being decrypted. Extraction of MEV and risk of censorship.

But the transaction data itself will have relevant metadata, such as the initiator of the transaction, the transaction fee or signature, which are used to verify the validity of the transaction. Additionally, the initiator’s IP address is also a form of metadata, and even the data size of the transaction. All of these metadata have the potential to leak user privacy, so we must also protect this metadata.

Ensure Metadata does not leak privacy

The following lists the various metadata of encrypted transactions and the corresponding protection measures, which will require cryptographic techniques such as homomorphic encryption and zero-knowledge proofs.

1. IP address

2. Transaction signature

3. Transaction fees

4. Transaction initiator and its Nonce value

5. Transaction size

△ Different metadata of transactions may leak user privacy. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

IP address

The network a user connects to to send encrypted transactions may reveal the user’s identity based on the user’s IP address and may be censored. Privacy protection at the network level relies on technologies such as Tor.

Transaction signature, handling fee, transaction initiator and its Nonce value

These metadata are used to prove the validity of the transaction, but they will reveal the identity of the user, so they must be encrypted. Once encrypted, we must use other tools to prove the validity of transactions without revealing this information. Otherwise, the network may be attacked by DoS and be filled with a bunch of invalid transactions that are discovered only after decryption.

When a node receives an encrypted transaction, it must (1) first confirm that the transaction initiator actually initiated the transaction, that is, verify the transaction signature, and then (2) confirm that the initiator has enough ETH to pay for the transaction (user balance ≥ gas price * gas limit), and (3) check the sender nonce value to avoid transaction replay attacks.

Zero knowledge proof

We can use zero-knowledge proofs to prove that transactions pass these checks without revealing this information. A zero-knowledge proof consists of public information (Public Input), private information (Private Witness), and the statement that the proof wants to prove (Statement).

△ For example, the public information (public input) is an encrypted transaction (tx ciphertext), the private information (private witness) is an unencrypted transaction (tx ciphertext), and the statement (zk statement) to be proved by this zero-knowledge proof is “this “Encrypted transactions are legal” (tx ciphertext valid). Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

For example, if Alice wants to prove to Bob that she has more than 10 ETH, but does not want to reveal her address, she can use a zero-knowledge proof to prove to Bob that her address really has a balance of more than 10 ETH.

“Prove that Alice’s address has a balance of more than 10 ETH” is the statement (zk statement) to be proved by this zero-knowledge proof. In order to generate this proof, Alice must provide her address and proof that she holds the private key of the address (for example, using The private key generates a signature), and she also needs to provide the ETH balance of this address, for example, use a Merkle Proof to prove how much ETH this address holds in the 1001st block.

Address, signature and Merkle Proof cannot be disclosed and are private information (private witness).

When this proof is produced, Bob can verify this proof with the Merkle Root (called State Root) of the state tree of block 1001. Anyone knows the State Root of each block, which is public information ( public input).

The only information Bob knows is the public information of State Root and the verification results. He will not know any of Alice’s private information.

△ Alice provides two private inputs: Merkle Proof and signature; Bob provides the public input of State root. The zk statement can verify that Alice has an address and the balance of the address is > 10 ETH

(1) Verify transaction signature

The verification of the transaction signature consists of two parts: (a) the transaction initiator is legitimate and (b) the transaction signature is signed by the transaction initiator.

(a) Mainly to verify that the Ethereum address of the transaction initiator is a legal address and not a random number. This will prove through a Merkle Proof that the address exists in the Ethereum state tree.

(b) Verifies that the transaction signature is signed by the private key of the transaction initiator.

△ This proof verifies (a) the address of the transaction originator (via sender pubkey Merkle proof) and (b) the signature within the transaction is legitimate (the signature will be included in the tx plaintext). tx plaintext is the raw unencrypted transaction data, which is the private information provided by the transaction initiator.

Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Reading tip: The red text in the picture above refers to what this certificate means after passing the verification (that is, “the signature of the transaction is legal”). It is not part of the zk statement. The blue part is information related to the transaction itself, including encrypted (public) transaction data and unencrypted (private) transaction data. The green part is the additional data required to complete the proof, both public and private.

△ Prove that the address of the transaction initiator exists in the Ethereum state tree and that the transaction initiator really has the private key of the place

(2) Confirm that the transaction initiator has enough ETH to pay the handling fee

Just like the previous example of Alice and Bob proving that the balance is > 10 ETH, the transaction initiator needs to provide the Merkle Proof of the balance of his own address, and the statement to be proved is “the balance of the address ≥ the transaction fee.” The transaction fee is equal to the gas price multiplied by the gas limit. Both gas price and gas limit information are included in the original unencrypted transaction data (tx plaintext). tx plaintext is private information provided by the transaction initiator.

△ This proof verifies that the balance of the transaction initiator’s address (via sender balance Merkle proof) is greater than or equal to the transaction fee (the transaction fee information is included in tx plaintext). Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Prove the balance of the transaction initiator’s address > gas price

(3) Verify the Nonce value of the transaction initiator

Because the Nonce is also recorded in the Ethereum state, Merkle Proof is also used to prove the current Nonce value of the transaction initiator, and then compare it with the Nonce value specified in the transaction to confirm that the transaction has not been replayed.

△ This proof compares the Nonce value of the transaction initiator’s address (through nonce Merkle proof) and the Nonce value specified by the transaction (the Nonce value specified by the transaction is included in the tx plaintext). Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Prove the nonce of the transaction initiator’s address = tx nonce

However, this check cannot prevent malicious attackers from generating multiple transactions with the same Nonce value (these transactions can all pass the Nonce value check) to conduct DoS attacks, so we need to add additional checks.

We require the transaction initiator to provide one more Replay Tag to ensure that there will only be one transaction with the same Nonce value. The Replay Tag is the hash value of the Nonce value and the transaction initiator’s private key: replay tag = H (nonce, private key ), so different Nonce values ​​of the same transaction initiator will each correspond to a unique Replay Tag.

Therefore, nodes can use the Replay Tag to identify whether a transaction initiator has initiated multiple transactions with the same Nonce value (the Replay Tags of these transactions will be the same), and reject the second transaction with the same Replay Tag.

△ This proof will calculate the replay tag and compare it with the replay tag passed in by the public input. The Nonce value of the transaction is contained in tx plaintext, and the private key is contained in private witness.

Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Prove the nonce of the transaction initiator’s address = tx nonce and replay tag = H(nonce, key)

Or if we consider that the transaction initiator may want to replace the transaction with the same Nonce value with another transaction, perhaps because he does not want to execute the original transaction, or he wants to increase the gas price so that the transaction can be collected faster .

At this time, we can introduce the Slot value of PoS into the calculation of Replay Tag: replay tag = H(nonce, private key, slot). For example, Bob sent a transaction with a Nonce of 5 in Slot 1001 but it has not been received yet, so he decided to double the gas price of the transaction while keeping other fields unchanged, and sent the updated transaction in Slot 1005. Transaction, and because the Slot has changed, the Replay Tag is different, and this new transaction will not be rejected because the Nonce value is the same.

△ Public input will pass in additional slot values ​​for replay tag calculation. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5.Transaction size

Some encryption methods will make the size of the encrypted transaction data the same as before encryption. However, there is still a chance to deduce some information through the size. For example, the transaction data of a transaction performed in Uniswap must be larger than the transaction data of a simple ETH transfer. Large, so the transaction size is the same as Metadata that may leak privacy.

An intuitive approach is to perform a padding action on the transaction data before encrypting it, such as padding a bunch of zeros until the transaction size becomes a power of two, or even padding it all until it becomes a fixed size. This reduces the chance of an observer identifying a transaction by its size. Block Builder will combine the padded transactions into a block.

△ White is Padding. The blue and orange deals are the same size, so there’s no way to tell them apart based on size. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

However, the disadvantages of this approach are that (1) it is inefficient because a lot of space in the block will be wasted on Padding, and (2) it may not provide sufficient privacy protection. For example, the size of the red transaction in the picture above (four squares) may It’s rare, so it can still be figured out. If all transactions are padded to a fixed size (such as 64 blocks), privacy will be improved, but it will become a relatively waste of block space.

△ The disadvantage is inefficiency and limited privacy protection. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

A better approach is to first pad the transactions to a fixed size, but homomorphic encryption can be used to remove the padding.

Because transactions are all padded to a fixed size, all transactions seen by observers will be the same size. The Block Builder can combine encrypted transactions through a function and remove the padding at the same time.

△ Use homomorphic encryption to remove Padding while combining encrypted transactions. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Reading tip: Block Builder with pure trust or trusted hardware can achieve the same effect without homomorphic encryption (after all, everyone trusts it).

How Block Builder builds efficient blocks

Even though we can efficiently combine encrypted transactions into a block through homomorphic encryption, there are still some problems to be solved, such as (1) different transactions may read and write the same state (for example, they all trade on Uniswap) , which may result in lower-ranked transactions being more likely to fail, and (2) Block Builder cannot collect transactions according to the level of handling fees.

The ideal solution is to run the EVM in homomorphic encryption, just like putting an EVM into a black box for execution, so that the Block Builder can simulate transaction execution through the EVM to form the most efficient and The block with the highest income. However, the technical complexity of this technology is too high, and it will take a long time to realize it.

The alternative is to attach an encrypted handling fee and an encrypted Access List to the transaction (the Access List is used to indicate which states the transaction will read and write), and use homomorphic encryption to verify the validity. In this way, Block Builder can determine the order of transaction income through handling fees, and use Access List to prevent transactions from affecting each other and resulting in reduced transaction execution efficiency.

△ It is determined by the handling fee and the Access List which transactions are to be collected and the order in which they are collected. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

The time when the transaction occurs

If we are worried that the time at which encrypted transactions are sent to the p2p network may leak privacy (for example, Alice conducts transactions at UTC+8 00:00–04:00), we can ask the Validators to send a bunch of encrypted Dummy Transactions regularly. to confuse the observer.

Dummy Transaction will need to be attached with a zero-knowledge proof to prove that it was sent by the Validator and limit the frequency to prevent the network from being filled with Dummy Transactions (observers will not know that this is a Dummy Transaction, only that it is “legal and valid”).

Dummy Transaction will be identified and discarded during the homomorphic encryption operation of the group block.

△ Validators regularly send (grey) Dummy Transactions to confuse observers, but this will increase the burden on the network and nodes. Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Encrypted Mempools v.s. FSS

The FSS in the previous article also introduced that FSS will also encrypt transactions first and then hand them over to Chainlink Oracle for sorting. The process of FSS encrypting transactions and verifying the validity of encrypted transactions is actually the same as Encrypted Mempools, except:

• FSS’s transaction encryption does not mention the protection of Metadata, while Encrypted Mempools hides Metadata and uses zero-knowledge proof to prove the validity of the transaction.
• FSS currently uses Threshold Encryption/Decryption and is jointly decrypted by Chainlink Oracle, which means you must trust Chainlink Oracle. Encrypted Mempools does not specify how to sort, but only focuses on encrypting transactions and proving their validity with zero-knowledge proofs.
• Compared with FSS which only emphasizes “fairness”, Encrypted Mempools puts more emphasis on “how to efficiently assemble the block content and how to allow the Proposer to assemble the most beneficial block instead of just randomly deciding the order of transactions.”

In the future, FSS may also use the technology in Encrypted Mempools to enhance or replace its encryption and decryption transactions.

Tackling MEV with Cryptography

This Talk is about Encrypted Mempools, where the author shares how cryptographic techniques and improvements in the Ethereum consensus layer can help combat the issues caused by MEV. For details, please check:https://www.youtube.com/watch?v=mpRq-WFihz8

Summary and highlights

1. The purpose of Encrypted Mempools is to protect against MEV and censorship by encrypting transactions. Others can only know that your transactions are valid, but they cannot know what actions you are performing within your transactions.

2. However, to truly achieve effective resistance to censorship, a mechanism such as the PBS Inclusion List must be used. Otherwise, the Builder can still conduct censorship by refusing to receive encrypted transactions.

3. It is not easy to prove that an encrypted transaction is valid. You need multiple zero-knowledge proofs to prove the signature of the transaction, the Nonce value of the transaction initiator, sufficient handling fees, etc.

4. In addition, it is necessary to avoid metadata such as IP, transaction data size or transaction sending time from leaking the privacy of the transaction.

5. Lastly, the most important thing is to ensure that the transactions can be decrypted —— Guaranteed Encryption. There are five different methods: Pure Trust (In-flight), Trusted Hardware Enclave, Threshold Encryption/Decryption, Delay Encryption/Decryption, and Witness Encryption/Decryption. Each method has its own advantages and disadvantages.

Reference data and recommended further reading

Encrypted Mempools

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• How cryptography helps solve the problems caused by MEV from the application layer and consensus layer:https://youtu.be/jLHf6yw7b5Y?t=4139

Special thanks to Steven Wu, Kimi Wu , Kevin Mai-Hsuan Chia and Anton Cheng for reviewing and improving this post.

Disclaimer：

1. This article is reprinted from [techflowpost]. All copyrights belong to the original author [Will 阿望；Diane Cheung]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.