Decentralized order flow distributer (DOFD)

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?

2 Likes

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.

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.

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.

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.

@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.

1 Like

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?

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.