Decentralized order flow distributer (DOFD)

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

@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

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

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

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.

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

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

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

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

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

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

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

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

2 Likes

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

Why would they not collude?

1 Like

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

Could this not be seen as a kind of extension of Themis (leaving aside the ordering side of things)?

1 Like

Yeah, many parts are the same. Both system provide the orderflow to builders. But Themis is trying to also archive fairness of orderings by enforcing rules on the ordering of the system, while DOFD is more focused on incorporating the privacy of transactions.

I strongly believe that privacy is more important than tx ordering: Enforcing certain orderings of transactions makes the system unstable as in the MEV-boost auction validators would prefer blocks that don’t have the special ordering, but harvest the MEV best. That means if the MEV is big enough to outbid the protected order flow of the themis-system, then the system becomes unstable. Also in future AMM versions, McAMMs need the freedom to insert certain orders later to harvest the LVR for the liquidity providers. All that speaks against enforcing an ordering of the transaction unless I am overseeing something.
Privacy, on the other hand, is under certain circumstances even more effective as front-running protection than enforcing orders, as transaction can also have an impact on the market outside of the blockchain

4 Likes

I completely agree (which is why I said we should leave aside the ordering side of Themis). I moreso mean that it could be used as a consensus protocol to come to agreement on what the input for the next block ought to be and one could layer privacy on top.

4 Likes

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

Seems like it is imperative to have DOFD node set to be as decentralized as possible so as to make it very difficult to collude.

2 Likes