Decentralized order flow distributer (DOFD)

Research
1

Abstract
It seems that the prevailing thought is that the order-flow network effects can not allow a fair builder’s market, as the order-flow network effects will quickly create advantages for single block builders that will rule the market. Many people conclude that the only solution is a decentralized builder (like SUAVE). This write-up argues that there is a better way: Only decentralize the order-flow-management, but still keep the performance and sophistication of centralized block builders.

Introduction:
Decentralized block builder is a highly anticipated and discussed topic. Likely, they will enable the following advantages:

  • Solution to order-flow centralization
  • Pre-confirmations features for users
  • In-protocol front-running protection
  • Being a decentralized infrastructure itself

But likely, decentralized block builders will be accompanied by the following disadvantages:

  • Developing decentralized system is generally hard
  • Evolution of the decentralized block builder will be slower than many competing centralized block builders
  • Decentralized system have performance trade-offs that may hinder the best UX for Ethereum users - e.g., revert protection for txs might require very performant builders.
  • Support for custom transaction patterns: Applications like (McAMMs) need custom patterns to enable their full potential.

Given this situation, the following will describe another idea how we can ensure a non-centralised builder ecosystem by controlling only the order-/tx-flow by a decentralized entity - the decentralized order flow distributor (DOFD). This has the potential to lift all the disadvantages for a decentralized block builder mentioned above.

Idea:
The core idea is to build a decentralized order flow distribution system: User post transactions encrypted into an encrypted mem-pool. They use public DKGs-public-keys to encrypt their order/tx flow. The distributed keys are managed by a network of DOFD nodes. Every user will publish 3 pieces of information: the transaction without signature encrypted by a first DKG public key, the signature of their tx encrypted by a second DKG public key and a zk-proof that the encrypted signature is valid for the encrypted transaction.
The DOFD will select per block a small subset of all allowed-listed builders to see the encrypted transactions without signatures, such that this subset can build blocks. The DOFD nodes will make the order-flow visible for the selected builders by publishing the private DKGs-keys encrypted with the public keys of each of the selected builders. These selected builders can then decrypt the private DKG keys, and hence they can also decrypt the encrypted transactions without signatures. With this order-flow, the builders will participate in the usual MEV boost auction. One of the selected builders should win this MEV boost auction against normal/non-participating builders, as the order-flow gives the selected builders a huge advantage. This will result in a final optimized block - minus the signatures. The signatures will be made visible to the block proposer, after they committed to use the winning block. Once the block-proposer has made its commitment to the DOFD network, the DKG nodes will publish their secrets that allow the block-proposer to build the final block with signatures.

If a builder misbehaves, for example, allows sandwiching attacks, then they will be slashed by the DOFD-network and will not get any future order-flow.
This might be implemented via “eigen layer staking mechanisms”.
These rules enable an equal playing field for block builders and hence, could serve as a foundation for a healthy competition between builders, as everyone has access to the same order flow. Note that fancy techniques like pre-confirmations or in-protocol front-running protections can be implemented as well:

  • Pre-confirmations:
    • If every one of the block-builders of the next turn - the block-builders who will be able to decrypt the order-flow of the public mem-pool - give pre-confirmations to a user, then the user would know that his transaction will be included as pre-defined. If pre-confirmation are an important tool, the allow-list of builders could only contain builders that are actually providing this feature.
  • In protocol front-running protection:
    • If the builders have to be in an allow-list and if they have to provide collateral ( maybe via eigen layer-systems), then one can easily slash them, if they misbehaved or disregard some rules during block-building.

Discussion:
Allowing builders to only see the transactions without the signatures prevents them from publishing the transactions to other builders. But still the trade intends are visible to them and could disclose valuable information. Hence, traders would have to split their trades into smaller pieces, such that the pure information is not very valuable. (If one really does want to prevent the orderflow information from leaking, SGX might be the needed)
Another main disadvantage of the proposed solution is that the list of allow listed builders needs to be maintained by governance. The system is not permission less and will also require security deposits from builders and validators. A more governance minimized system would be preferred. But - for comparison - also a decentralized builder would need some degree of governance to decide about features likes reconfirmation techniques, etc.
Also, another disadvantage is that certain block-builders can still try to gain more influence by temporary operating non-profitable and thereby trying to make in unattractive for others to join.
But maybe all these disadvantages are outweighed by the faster evaluation of builders. Also, block builders can quicker support more sophisticated applications like MEV capturing AMM (McAMMs), etc.
I could also imagine that short-term the DOFD is more valuable for the eco-system as a decentralized block builder - especially due to the fact of its faster evolution and not having SGX as a trust assumption.

I am really curious on your opinions. Which other disadvantages or advances for DOFD approach vs decentralized builder approach do you see?

9 Likes
2

Super cool.

How scalable is DKG here? My understanding is that there is a limit to the number of parties in the set. Are there examples of what latencies are in practice? Also I think there would be downtime every time a validator joins or leaves since keys must be regenerated.

3

How scalable is DKG here?

DKG is actively researched. I like the summary of performances from this talk:

I think for both solutions: decentralized builders or DOFD, DKG - or a similar technique - is needed to encrypt the orderflow. Hence, constraints from DKG will impact both technical solutions.

Also I think there would be downtime every time a validator joins or leaves since keys must be regenerated.

I think, we can do the key generation in parallel, while the old set of validators and keys still operate and hence avoid downtime.

4

Great, given that SUAVE (pre-spec) is out, I wanna add an elaboration how SUAVE-features can be accomplished with the upper specification:

  1. Preference expression:
    This could be done as SUAVE is intending to do it: Formulating a meta-language that allows to specify the preference of tx. The only difference is that the additional meta-language input would also be encrypted with DKG.

  2. Execution market:
    In the upper spec, builders would only optimize for the MEV extracted. But since builders are bonded, one can add any meta-game for them that benefits users and returns MEV to them.
    E.g., every selected block builder of DOFD with access to the encrypted order flow could be forced to go through a 2-step process: First build the best execution bundle for each tx with meta-preferences, compare their bundles with the ones from other builders, select the best overall best ones and then use them to build the final block. There are many different possible ways to implement the execution market.

  3. Cross-chain MEV:
    Many networks could use the upper approach of encrypting the all their order flow in one multi-blockchain-mem-pool. Then likely the winning builder has build blocks for all chain simultaneously as this allowed them to extract the most MEV and thereby win the MEV-Boost/PBS auction.

1 Like
5

hey @josojo DOFD is an interesting idea! I haven’t thought through it super deeply, but it does remind me of a general pattern of first committing to the contents of the future block then seeing them and ordering according to some predefined, falsifiable rules. It feels like what you’ve added in here is a decentralised way to do the commitments and force order flow to be shared, which is definitely a useful addition. Do you think that’s a good characterisation?

Some initial handwavy thoughts:

  • You might have a dynamic arising in which order flow is “captured” by a builder who can put down an enormous stake with many sybils
  • There may be properties of block building that you want to enforce, but aren’t falsifiable (i.e. you can’t prove someone broke the rule). Frontrunning is an example of this. How do you know if there are three unrelated orders buy-buy-selling an asset or if a user is being sandwiched by two accounts owned by the same searcher?
  • Even if you could have completely open orderflow, you may still have strong centralising forces in the builder market from other things (larger pools of capital, better building algs, OF not participating in the DOFD)
  • Although you are right that decentralisation often implies inefficiencies, this need not be the case. It may be that there is a design for a decentralised builder which enables collaboration in such a way that a very a large pool of different sets of information and strategies are merged to form more valuable blocks than any centralised party could. (I realise my point is very abstract here)
  • This may not be a big deal if the trust assumption holds (e.g. 1/3 BFT) but there is likely a lot of incentive to misbehave for the DOFD nodes both in terms of leaking OF or info about OF and in terms of withholding decryption.
1 Like
6

@Quintus

thanks for your thoughtful post!

I haven’t thought through it super deeply, but it does remind me of a general pattern of first committing to the contents of the future block then seeing them and ordering according to some predefined, falsifiable rules. It feels like what you’ve added in here is a decentralised way to do the commitments and force order flow to be shared, which is definitely a useful addition. Do you think that’s a good characterisation?

Yes, that’s a very good and succinct description.

  • You might have a dynamic arising in which order flow is “captured” by a builder who can put down an enormous stake with many sybils

Yes, this is a concern. However, with a mixture of required staked capital and anonymous reputation, it could become practically quite hard to sybil attack the system.

  • There may be properties of block building that you want to enforce, but aren’t falsifiable (i.e. you can’t prove someone broke the rule). Frontrunning is an example of this. How do you know if there are three unrelated orders buy-buy-selling an asset or if a user is being sandwiched by two accounts owned by the same searcher?

I think this is just a question on how you stage the game. Most facts could be falsified:

  • E.g. Front-running: The execution market could require searcher to find the best execution price for a transaction. Then the final price execution price should not be worse than this price + an additional volatilty slippage margin, otherwise the blockbuilder will get slashed. This is then equal to the fact that the user was setting the slippage so tight that it can not be front-run.
    Another option is to work with pre-confirmations. E.g. the orderflow gets first shared with the builders, after they give some confirmation on the orderings. If even orderings should be irrelevant, then users should use dapps like cowswap, IMO.
  • Censoring: DOFD nodes could index transactions and function as a short term data-availablity committee. Then one could force builders to “see the transactions” and incorporate them in some way. ( Though, I don’t think this is necessary, as non-censorship comes from builder’s diversity ).

The only property that is not easy to enforce is the “leakage of private information”. E.g. a huge ETH-USDC order - signaling a falling ETH price -could be shared to arbitrageurs outside, such that they can take advantage of the information itself.

  • Even if you could have completely open orderflow, you may still have strong centralising forces in the builder market from other things (larger pools of capital, better building algs, OF not participating in the DOFD)

Agreed, but here I am proposing to share the orderflow only to a random subset of all available allowlisted builders. This will make sure even “weaker” builder win from time to time a block and hence can keep their operation ongoing.

  • This may not be a big deal if the trust assumption holds (e.g. 1/3 BFT) but there is likely a lot of incentive to misbehave for the DOFD nodes both in terms of leaking OF or info about OF and in terms of withholding decryption.

Yes, such a trust assumption is implicit given. But personally, I would prefer relying on such a trust assumption than on SXG trust.

2 Likes
7

Pretty interesting idea @josojo. I do think this fits pretty well within our mental model for how we think about SUAVE. A question I have for you: why is an allow list of selected builders chosen at random your choice of builders to see orderflow? Is that simply to make this more feasible or is that a long term goal of yours?

1 Like
8

Not sure whether my upper wording well-chosen, hence I try to give more context here:

The idea is to maintain a list of allow listed builders that are scheduled to build new blocks. We don’t share the orderflow with all of them at the same time, because then the best builders could always win and make it hard for others to continue their operations. Hence, we choose a subset of all allowlisted builders that is allowed to see the orderflow and let this subset compete in building the best blocks with it.
I don’t have a strong opinion on how the subset of builders should be chosen. But I think that it is wise to ensure that 1) sometimes only “weaker” builders are competing, such that they have also a chance to win a block and 2) no single builder is excluded for a longer time period, such that the network is maximally censorship resistant.

I think if the subsets are created via a randomizer, then the properties are fulfilled. But maybe an algorithm could do it better.

2 Likes
9

I think one approach regarding selecting the subset of “allowlisted builders” could be based on a weighted random sampling system where the weight is determined by a reputation system (e.g., # of blocks built by each builder (after joining DOFD), total value extracted/paid to the validators, …).

Although this would favor the best builders, it is social welfare-wise better to have the builders that can provide the most value have access to the order flow than the others. I would say sampling builders in a uniformly random way bears the risk that there will be “unrealized value” left on the table.

10

Yes, I fully agree that there could be several optimization to be made. I like the proposal!

On another note:
In the last MEV-roast, you guys also talked about the different levels of privacy for the order flow. While watching the video, I realized that with the upper construction of a DOFD, one can also easily implement many levels of privacy. For each level of privacy, one could generate (1 or several) public DKG encryption keys + rules on when the private decryption key will be published via the DKG mechanism. E.g. tx-meta-information could be encrypted with one key that is published much earlier than the actual tx-payload data. The payload could even be published much later - maybe even after the builders have committed to blocks for some privacy levels.

2 Likes
12

Yes upon rereading this proposal, I think the core idea of reaching a commitment to input is what is most valuable. We could then mix this in with other SUAVE features like prog. privacy by doing what you said or perhaps having two layers of encryption where after the threshold decryption takes place we have the original SUAVE primitives which allow for certain homomorphic computation. With privacy primitives, I don’t think its necessary to have a permissioned set of builders at all.

My main concerns are with latency, advantages drawn from being the first to decrypt and changing the committee (basically, everything DKG related), but I haven’t really looked into it much.

Another problem would be with capital requirements of requiring builders to stake.

With respect to what this kind of commitment to the input to building enables, I started a thread to discuss it a bit further here.

Pre-confirmations: If every one of the block-builders of the next turn - the block-builders who will be able to decrypt the order-flow of the public mem-pool - give pre-confirmations to a user, then the user would know that his transaction will be included as pre-defined. If pre-confirmation are an important tool, the allow-list of builders could only contain builders that are actually providing this feature.

Pre-confs could maybe already be offered at the DOFD level. For example, after the reveal decryption if the total gas used by basefee paying txns (in certain orderings) is less than X million gas we preconfirm everything and force builders to include all.

1 Like
13

This is the most important innovation here IMO. You cannot get the contents ratified without claiming accountability for them - very nice. We do need to be careful that this doesn’t create any liveness issues.

I think this is the second most important innovation, and it is actually necessary if you also do something like this:

The reason is that if you add these slashing conditions then you get to a point where you must censor to win the most MEV without being slashed. Therefore the competitiveness of the auction actually becomes a liability rather than an asset for censorship resistance. So having the DOFD double as a force-inclusion list is very important.

I agree, the accountability innovation fixes this.

1 Like
14

What kind of latency does the system require?
I think latency will be good (likely good enough) as

  • During the decryption process, only the parts of the private message-keys of transactions in the block need to be sent over the network - no bigger data junks. One DKG decryption should be pretty fast and lean and the specification requires “only” 1 DKG private key generate per tx included in the block. And since DKG works with thresholds, only a certain percentage of the network needs to act fast and publish their secrets on time, such that the decryption can start on time. (If there is a small percentage of malicious DKG nodes that want to delay something, they can’t, if the threshold is reached without them).
  • the encyrpted orderflow can be continuously be published (the tx-sender can even encrypt the tx themselves with the public DKG key and send it to all builders. )

Yes, the DKG/DOFD nodes must ensure data availablity for the signatures. Otherwise, as you are saying, there would be a risk of liveness failure.

It could be that this is true for some transactions. But if someone pays a bigger eip1559 tip to be included, it’s very unlikely that the best solution would have to censor this person(assuming the tip is big enough). Or am I missing something?

1 Like
15

It depends on what type of misbehavior you can slash. For example, let’s say you make frontrunning a slashable offense. Suppose I, a regular user, offer a $1 tip and take a trade that is at a $5 discount to Binance, but I don’t care about that discount, I just want to make the trade. Now, a searcher would love to frontrun my trade and make $5, making my trade still execute, but not at a discount, which is fine for me. But if they can’t do that, then they may have to resort to censorship, giving up the $1 tip and taking the $5 profit. So the safest thing in this regard would be to have no misbehaviours be slashable.

1 Like
16

Adding a note that the ability to be able to commit to input credibly allows one to execute ~IC auctions. See Credible, Optimal Auctions via Blockchains for details

And another note that the commitment to things like bids isn’t that easy: Decentralized-Auctions/Censorship_Resistance_in_On-Chain_Auctions.pdf at main · eljhfx/Decentralized-Auctions · GitHub

1 Like
17

I am excited that the idea of a DOFD got so much love and participation.

I put in a bit more thoughts on what exactly an MVP could look like. The write-up can be found here. I primarily focused on low complexity and easy-to-code MVP.

Generally, I think if the following points come along in 2023, then the MEV landscape would already significantly improved:

  • DOFD MVP for fair MEV competition between builders
  • non-reversion guarantees for users’ transactions → This reduces the MEV and sandwiching surface, as users can choose tighter slippage
  • MEV capturing AMMs (works nicely with the DOFD concept) would remove the Loss versus rebalancing-MEV
  • And protocols with delegated trade execution - like cowswap and 1inch fusion - reduce the sandwiching risks for highly volatile assets

All these points would reduce the MEV that is captured by extractors already significantly and make ethereum a better place for trading/Defi. The DOFD could then be built out to a better system - the full SUAVE over the coming years.

5 Likes
18

What are the incentives for the DOFD nodes to act honestly, i.e., to not decrypt and extract value?

2 Likes
19

I missed this in the spec, you are right. But essentially each node holds it own part of a secrete and if the secret is shared too early, one should slash this specific node. Let me think about how its done the easiest and I will add it later to the spec.

Only if a certain number of nodes decided to collude (number must be above the threshold for the threshold signature ) and not slash each other, then they would be able to extract MEV.

2 Likes
20

Why would they not collude?

1 Like
21

Because one would set up the incentives for each node such that the most profitable strategy is to reveal the collusion and thereby get part of the slashed amounts. (Sorry, this was unclear from the upper writing and I will provide a better spec soon).

1 Like