tl;dr (1) mev-commit introduces two novel cryptographic primitives ARUBE and DPCOM that together provide end-to-end privacy in mev-commit. (2) ARUBE provides privacy and anonymity for bidders against all third-parties. (3) DPCOM provides privacy and anonymity for providers issuing commitments to bids. Combined, these mechanisms create a robust privacy framework that prevents bidders and providers from unintentionally disclosing information about their actions and intentions. Additionally, both bidders and providers can benefit from this privacy framework today, which is already live on mev-commit!

In permissionless blockchains, users only learn the outcome of their submitted transactions once the block containing the transaction is confirmed. However, during the period between submission and confirmation, valuable information can leak, which other actors may exploit for profit, such as in arbitrage opportunities. The mev-commit protocol addresses this issue by utilizing commitment games, enabling blockchain participants to create and secure credible commitments tailored to the specific execution requirements of their transactions.

More specifically, commitments can be leveraged by execution service providers (such as block proposers or builders) to offer users real-time guarantees about their transactions. To enhance the credibility of these commitments, providers can combine their reputation with staked economic collateral. They can then gather bids from users for more precise execution requirements—whether related to time, state, or specific expressions—that the blockchain itself may not natively support.

To protect participants from losses incurred by information leakage, e.g., by transactions getting frontrun, it is crucial to ensure the privacy of the commitments and the corresponding bids from the users. In its initial version, the mev-commit protocol focused solely on protecting the privacy of providers. However, in this updated version, the protocol has been extended to offer end-to-end privacy. This enhancement ensures that both bidders and providers can preserve their privacy while participating in the protocol. In the remainder of this document, we will explain how mev-commit achieves this enhanced level of privacy.

The mev-commit protocol is run between a set of bidders and a set of providers. Each bidder can send bids to a subset of the providers representing some intention of the bidder. The intention can vary from simple transaction inclusion to complex execution strategies. Providers can accept these bids by committing to them. The providers are responsible for fulfilling the bids they committed to. Bidders are parties seeking commitments on specific aspects of their transaction execution (these aspects are referred to as bids). These bidders may include mev searchers and solvers. Providers, on the other hand, are entities capable of guaranteeing certain aspects of transaction execution and are therefore able to issue credible commitments to the bidders. Providers typically include block proposers and block builders.

The mev-commit protocol proceeds in rounds and is executed between a set of bidders $$\mathcal{B}$$ and a set of providers $$\mathcal{P}$$. In each round bidders can send bids to providers, where a bid consists, among other things, of the amount the bidder is willing to pay for a corresponding commitment. Each bidder $$B \in \mathcal{B}$$ can define and regularly update a set of providers $$\mathcal{R} \in \mathcal{P}$$ to which they wish to send their bids. The bids are then received by the providers in $$\mathcal{R}$$. Providers can then commit to bids by sending cryptographic commitments to the bidders and adding the commitments to the mev-commit chain. An illustration of an honest execution of the mev-commit protocol is shown below.

The mev-commit protocol provides privacy for both bidders and providers. This privacy is achieved by combining two novel cryptographic primitives, Anonymous Receiver-Updatable Broadcast Encryption (ARUBE), and Dual-Phase Commitments (DPCOM). The former is used to disseminate bids from bidders to providers of their choice, and the latter is used to commit to those bids and later open the commitments. We describe both primitives in detail next.

Anonymous broadcast encryption [1, 2] already allows bidders to privately send bids to a subset of providers without revealing what the subset is. However, broadcast encryption in general allows a new set of recipients to be specified for each message that is encrypted. In the mev-commit use-case, the set of recipients (i.e., providers) for a given bidder typically remains stable, since bidders usually send their bids to the same set of providers and only occasionally add or remove a provider from this set. To be able to leverage this for more efficient schemes, we refine the notion of anonymous broadcast encryption by adding an algorithm for updating the set of recipients, while the encryption algorithm encrypts a message for a previously determined recipient set. We call this notion Anonymous Receiver-Updatable Broadcast Encryption (ARUBE).

ARUBE provides two security properties: anonymity and confidentiality. Anonymity ensures that for every provider $$P$$, nobody except $$P$$ learns whether $$P$$ is in the set of recipients $$\mathcal{R}$$. Confidentiality ensures that eavesdroppers and providers not in $$\mathcal{R}$$ cannot learn anything about the bid.

We describe a generic instantiation of ARUBE using an anonymous public-key encryption scheme [3] and a symmetric encryption scheme.

• Setup. When providers join the network, they generate a public/private key pair $$(pk, sk)$$ for the anonymous public-key encryption scheme. The public key $$pk$$ also serves as the public key of the ARUBE scheme and is shared with all bidders. The providers keep their secret key $$sk$$ private.

• Setting and updating recipients. Bidders can define the set of providers $$\mathcal{R}$$ they wish to send their bids to. To do so, they generate a secret key $$k$$ for the symmetric encryption scheme and encrypt it under the public keys of the providers in $$\mathcal{R}$$. The obtained ciphertexts are then concatenated (in random order) and sent to the providers. To prevent replay attacks and to allow the providers to learn which of the ciphertexts is intended for them, the bidder also sends an encryption of the current system’s timestamp under the key $$k$$. The providers then try to decrypt all public-key ciphertexts to obtain secret keys $$k'$$ and decrypt the timestamp with $$k'$$. If a valid and recent timestamp is obtained, the provider stores the corresponding key $$k'$$.

DPCOM is a two-party protocol that allows a message to be committed in two distinct phases. In the first phase, the bidder “precommits” to a message and receives both a precommitment and an opening key. In the second phase, the provider commits to the precommitment generated by the bidder in the first phase, receiving a decommitment information as the output.

A key feature of a dual-phase commitment scheme is its flexibility in opening the resulting commitment using either the opening key or the decommitment information. This is especially useful in the context of the mev-commit protocol, where the bidder generates a precommitment to its bid, after which the provider commits to that precommitment. This process ensures that both parties can open the commitment: the bidder obtains the opening key when generating the precommitment, and the provider obtains the decommitment information when committing to the precommitment. Consequently, both parties can later prove the content of the committed message to third parties. Crucially, if the provider misbehaves and refuses to publicly open the commitment, the bidder can independently open it without needing assistance from the provider.

Like a traditional commitment scheme, dual-phase commitment schemes must satisfy two security properties, namely hiding and binding. Hiding means that one cannot learn anything about the bid locked into the commitment without knowing either the opening key or the decommitment information. In particular, this means that only the provider committing to a bid and the bidder who generated it learn anything about the bid from the commitment. Binding means that a commitment to a bid cannot be opened to reveal a different bid. This holds for both the bidder and the provider opening and even if they collude to open the commitment together.

We instantiate DPCOM generically from a Non-Interactive Key-Exchange (NIKE) scheme —a cryptographic primitive that allows parties to agree on a common secret key without any interaction— and a (hash-based) non-interactive cryptographic commitment scheme.

• Setup. Each provider samples a NIKE key pair $$(\mathsf{NIKE}.pk, \mathsf{NIKE}.sk)$$ and publishes the public key.

• Sending bids. To send a bid to the providers, the bidder generates a NIKE key pair $$(\mathsf{NIKE}.pk', \mathsf{NIKE}.sk')$$ and sends the public key $$\mathsf{NIKE}.pk'$$ together with the signed bid to the providers. The secret key $$\mathsf{NIKE}.sk'$$ serves as the DPCOM opening key and the public key $$\mathsf{NIKE}.pk'$$ together with the signed bid correspond to the precommitment.

In the future, we hope to extend the privacy and security properties of the mev-commit protocol to support the following additional features:

Conditional disclosure of transaction payload data. The transaction payload itself is attached to a mev-commit bid and encrypted together with the bid, inheriting the bid’s privacy guarantees. We plan to investigate ways to increase the flexibility of this mechanism such that certain aspects about the payload (e.g., the transaction signature) can be disclosed to certain parties only under certain conditions. This allows for bidders to sell or auction off different parts of the transaction payload, leading to granular order flow mechanisms.

Extending dual-phase commitments. Our dual-phase commitments allow two distinct parties to open a commitment. However, there are situations in which additional providers need the ability to open a commitment, e.g., for validity checks or when multiple providers are involved in building a block. In particular, these parties may include Trusted Execution Environment (TEE) based systems, where a commitment can be opened inside a TEE and be checked for validity or used to perform a set of operations. To facilitate such use cases, we plan on extending the dual-phase commitment to allow for multiple parties to open a commitment.

In this document, we provide a detailed overview of the technical aspects underlying the privacy mechanism that powers mev-commit. We introduce two novel cryptographic primitives, ARUBE and DPCOM, which enable bidders to privately submit bids to selected providers, and allow providers to credibly and privately commit to these bids. Both the provider and the bidder can open the commitment, ensuring privacy and mutual control. Lastly, we outline future plans to further enhance the privacy features of mev-commit.

The current version of mev-commit fully supports all the privacy features outlined in this document and is available for use by both bidders and providers today.

A comprehensive explanation of the mev-commit protocol, including more technical details will be provided in the forthcoming mev-commit whitepaper. Stay tuned for its release.

[1] Barth, A., Boneh, D., Waters, B. (2006). Privacy in Encrypted Content Distribution Using Private Broadcast Encryption. In: Financial Cryptography and Data Security (FC 2006). Lecture Notes in Computer Science, vol 4107. Springer, Berlin, Heidelberg.

[2] Libert, B., Paterson, K.G., Quaglia, E.A. (2012). Anonymous Broadcast Encryption: Adaptive Security and Efficient Constructions in the Standard Model. In: Public Key Cryptography (PKC 2012). Lecture Notes in Computer Science, vol 7293. Springer, Berlin, Heidelberg.

[3] Bellare, M., Boldyreva, A., Desai, A., Pointcheval, D. (2001). Key-Privacy in Public-Key Encryption. In: Advances in Cryptology (ASIACRYPT 2001). Lecture Notes in Computer Science, vol 2248. Springer, Berlin, Heidelberg.

tl;dr (1) mev-commit introduces two novel cryptographic primitives ARUBE and DPCOM that together provide end-to-end privacy in mev-commit. (2) ARUBE provides privacy and anonymity for bidders against all third-parties. (3) DPCOM provides privacy and anonymity for providers issuing commitments to bids. Combined, these mechanisms create a robust privacy framework that prevents bidders and providers from unintentionally disclosing information about their actions and intentions. Additionally, both bidders and providers can benefit from this privacy framework today, which is already live on mev-commit!

In permissionless blockchains, users only learn the outcome of their submitted transactions once the block containing the transaction is confirmed. However, during the period between submission and confirmation, valuable information can leak, which other actors may exploit for profit, such as in arbitrage opportunities. The mev-commit protocol addresses this issue by utilizing commitment games, enabling blockchain participants to create and secure credible commitments tailored to the specific execution requirements of their transactions.

More specifically, commitments can be leveraged by execution service providers (such as block proposers or builders) to offer users real-time guarantees about their transactions. To enhance the credibility of these commitments, providers can combine their reputation with staked economic collateral. They can then gather bids from users for more precise execution requirements—whether related to time, state, or specific expressions—that the blockchain itself may not natively support.

To protect participants from losses incurred by information leakage, e.g., by transactions getting frontrun, it is crucial to ensure the privacy of the commitments and the corresponding bids from the users. In its initial version, the mev-commit protocol focused solely on protecting the privacy of providers. However, in this updated version, the protocol has been extended to offer end-to-end privacy. This enhancement ensures that both bidders and providers can preserve their privacy while participating in the protocol. In the remainder of this document, we will explain how mev-commit achieves this enhanced level of privacy.

The mev-commit protocol is run between a set of bidders and a set of providers. Each bidder can send bids to a subset of the providers representing some intention of the bidder. The intention can vary from simple transaction inclusion to complex execution strategies. Providers can accept these bids by committing to them. The providers are responsible for fulfilling the bids they committed to. Bidders are parties seeking commitments on specific aspects of their transaction execution (these aspects are referred to as bids). These bidders may include mev searchers and solvers. Providers, on the other hand, are entities capable of guaranteeing certain aspects of transaction execution and are therefore able to issue credible commitments to the bidders. Providers typically include block proposers and block builders.

The mev-commit protocol proceeds in rounds and is executed between a set of bidders $$\mathcal{B}$$ and a set of providers $$\mathcal{P}$$. In each round bidders can send bids to providers, where a bid consists, among other things, of the amount the bidder is willing to pay for a corresponding commitment. Each bidder $$B \in \mathcal{B}$$ can define and regularly update a set of providers $$\mathcal{R} \in \mathcal{P}$$ to which they wish to send their bids. The bids are then received by the providers in $$\mathcal{R}$$. Providers can then commit to bids by sending cryptographic commitments to the bidders and adding the commitments to the mev-commit chain. An illustration of an honest execution of the mev-commit protocol is shown below.

The mev-commit protocol provides privacy for both bidders and providers. This privacy is achieved by combining two novel cryptographic primitives, Anonymous Receiver-Updatable Broadcast Encryption (ARUBE), and Dual-Phase Commitments (DPCOM). The former is used to disseminate bids from bidders to providers of their choice, and the latter is used to commit to those bids and later open the commitments. We describe both primitives in detail next.

Anonymous broadcast encryption [1, 2] already allows bidders to privately send bids to a subset of providers without revealing what the subset is. However, broadcast encryption in general allows a new set of recipients to be specified for each message that is encrypted. In the mev-commit use-case, the set of recipients (i.e., providers) for a given bidder typically remains stable, since bidders usually send their bids to the same set of providers and only occasionally add or remove a provider from this set. To be able to leverage this for more efficient schemes, we refine the notion of anonymous broadcast encryption by adding an algorithm for updating the set of recipients, while the encryption algorithm encrypts a message for a previously determined recipient set. We call this notion Anonymous Receiver-Updatable Broadcast Encryption (ARUBE).

ARUBE provides two security properties: anonymity and confidentiality. Anonymity ensures that for every provider $$P$$, nobody except $$P$$ learns whether $$P$$ is in the set of recipients $$\mathcal{R}$$. Confidentiality ensures that eavesdroppers and providers not in $$\mathcal{R}$$ cannot learn anything about the bid.

We describe a generic instantiation of ARUBE using an anonymous public-key encryption scheme [3] and a symmetric encryption scheme.

• Setup. When providers join the network, they generate a public/private key pair $$(pk, sk)$$ for the anonymous public-key encryption scheme. The public key $$pk$$ also serves as the public key of the ARUBE scheme and is shared with all bidders. The providers keep their secret key $$sk$$ private.

• Setting and updating recipients. Bidders can define the set of providers $$\mathcal{R}$$ they wish to send their bids to. To do so, they generate a secret key $$k$$ for the symmetric encryption scheme and encrypt it under the public keys of the providers in $$\mathcal{R}$$. The obtained ciphertexts are then concatenated (in random order) and sent to the providers. To prevent replay attacks and to allow the providers to learn which of the ciphertexts is intended for them, the bidder also sends an encryption of the current system’s timestamp under the key $$k$$. The providers then try to decrypt all public-key ciphertexts to obtain secret keys $$k'$$ and decrypt the timestamp with $$k'$$. If a valid and recent timestamp is obtained, the provider stores the corresponding key $$k'$$.

• Sending bids. To send a bid to the providers in $$\mathcal{R}$$, the bidder encrypts the bid under the secret key $$k$$ and sends the ciphertext to all providers. The providers in $$\mathcal{R}$$ can decrypt the ciphertext using the previously obtained secret key $$k$$.

DPCOM is a two-party protocol that allows a message to be committed in two distinct phases. In the first phase, the bidder “precommits” to a message and receives both a precommitment and an opening key. In the second phase, the provider commits to the precommitment generated by the bidder in the first phase, receiving a decommitment information as the output.

A key feature of a dual-phase commitment scheme is its flexibility in opening the resulting commitment using either the opening key or the decommitment information. This is especially useful in the context of the mev-commit protocol, where the bidder generates a precommitment to its bid, after which the provider commits to that precommitment. This process ensures that both parties can open the commitment: the bidder obtains the opening key when generating the precommitment, and the provider obtains the decommitment information when committing to the precommitment. Consequently, both parties can later prove the content of the committed message to third parties. Crucially, if the provider misbehaves and refuses to publicly open the commitment, the bidder can independently open it without needing assistance from the provider.

Like a traditional commitment scheme, dual-phase commitment schemes must satisfy two security properties, namely hiding and binding. Hiding means that one cannot learn anything about the bid locked into the commitment without knowing either the opening key or the decommitment information. In particular, this means that only the provider committing to a bid and the bidder who generated it learn anything about the bid from the commitment. Binding means that a commitment to a bid cannot be opened to reveal a different bid. This holds for both the bidder and the provider opening and even if they collude to open the commitment together.

We instantiate DPCOM generically from a Non-Interactive Key-Exchange (NIKE) scheme —a cryptographic primitive that allows parties to agree on a common secret key without any interaction— and a (hash-based) non-interactive cryptographic commitment scheme.

• Setup. Each provider samples a NIKE key pair $$(\mathsf{NIKE}.pk, \mathsf{NIKE}.sk)$$ and publishes the public key.

• Sending bids. To send a bid to the providers, the bidder generates a NIKE key pair $$(\mathsf{NIKE}.pk', \mathsf{NIKE}.sk')$$ and sends the public key $$\mathsf{NIKE}.pk'$$ together with the signed bid to the providers. The secret key $$\mathsf{NIKE}.sk'$$ serves as the DPCOM opening key and the public key $$\mathsf{NIKE}.pk'$$ together with the signed bid correspond to the precommitment.

• Committing to bids. When a provider wants to commit to a bid, they first generate a shared secret $$s$$ with the bidder using the NIKE scheme by combining the provider’s NIKE secret key $$\mathsf{NIKE}.sk$$ with the bidder’s public NIKE key $$\mathsf{NIKE}.pk'$$. This shared secret is then used as the randomness to commit to the bid using the hash-based commitment scheme. The obtained commitment is sent to the bidder and recorded on the mev-commit chain. The public key $$\mathsf{NIKE}.pk'$$ corresponds to the decommitment information.

• Opening commitments. Both the bidder and the provider can compute the shared secret $$s$$ using their NIKE keys, allowing them to open the commitment. No other party, however, has the ability to do so.

In the future, we hope to extend the privacy and security properties of the mev-commit protocol to support the following additional features:

Conditional disclosure of transaction payload data. The transaction payload itself is attached to a mev-commit bid and encrypted together with the bid, inheriting the bid’s privacy guarantees. We plan to investigate ways to increase the flexibility of this mechanism such that certain aspects about the payload (e.g., the transaction signature) can be disclosed to certain parties only under certain conditions. This allows for bidders to sell or auction off different parts of the transaction payload, leading to granular order flow mechanisms.

Extending dual-phase commitments. Our dual-phase commitments allow two distinct parties to open a commitment. However, there are situations in which additional providers need the ability to open a commitment, e.g., for validity checks or when multiple providers are involved in building a block. In particular, these parties may include Trusted Execution Environment (TEE) based systems, where a commitment can be opened inside a TEE and be checked for validity or used to perform a set of operations. To facilitate such use cases, we plan on extending the dual-phase commitment to allow for multiple parties to open a commitment.

In this document, we provide a detailed overview of the technical aspects underlying the privacy mechanism that powers mev-commit. We introduce two novel cryptographic primitives, ARUBE and DPCOM, which enable bidders to privately submit bids to selected providers, and allow providers to credibly and privately commit to these bids. Both the provider and the bidder can open the commitment, ensuring privacy and mutual control. Lastly, we outline future plans to further enhance the privacy features of mev-commit.

The current version of mev-commit fully supports all the privacy features outlined in this document and is available for use by both bidders and providers today.

A comprehensive explanation of the mev-commit protocol, including more technical details will be provided in the forthcoming mev-commit whitepaper. Stay tuned for its release.

[1] Barth, A., Boneh, D., Waters, B. (2006). Privacy in Encrypted Content Distribution Using Private Broadcast Encryption. In: Financial Cryptography and Data Security (FC 2006). Lecture Notes in Computer Science, vol 4107. Springer, Berlin, Heidelberg.

[2] Libert, B., Paterson, K.G., Quaglia, E.A. (2012). Anonymous Broadcast Encryption: Adaptive Security and Efficient Constructions in the Standard Model. In: Public Key Cryptography (PKC 2012). Lecture Notes in Computer Science, vol 7293. Springer, Berlin, Heidelberg.

[3] Bellare, M., Boldyreva, A., Desai, A., Pointcheval, D. (2001). Key-Privacy in Public-Key Encryption. In: Advances in Cryptology (ASIACRYPT 2001). Lecture Notes in Computer Science, vol 2248. Springer, Berlin, Heidelberg.