Some key concepts of the current DEX may be difficult to translate to a decentralized config with a simple design, and we need to rethink several things, particularly regarding conduct.

Just going to a mesh configuration with the current designs increases complexity, so we should simplify things as much as possible so that it is robust and maintainable. In particular: account scoring, the registration fee, matching, and book synchronization. Mesh will be most feasible if we look at really chopping things down when it looks like something does not move from centralized -> decentralized without lots of complexity, edge cases, and assumptions. Not just complexity, but potential for loss of consensus between nodes on fundamental things like status of a user/account.

We should start with a few notable challenges in mind and build the solution up from them. Namely, replacing the reg fee, the issue of perpetual history for user scoring, the problem of consensus on the history, the matching and epoch cycle issues, etc.

Incentive Mechanism (fee -> bonds)

We will replace the registration fee with fidelity bonds to solve the issues with registration fees paid to a server operator. The general problem solved is that in mesh, if you consider a user can be running a server/node themselves, the conduct has to come from independent evidence of misconduct. A user could have paid a legacy reg fee to themselves, the operator of a server. Bonds will form the basis for new solutions in order authorization and/or account scoring/tiers. Obviously a fee paid to a third party is a blemish on dex too, but this is primarily a mesh solution for this discussion.

Conduct

As long as we keep the notion of conduct scores for each account, nodes have to agree on these scores. Challenges:

• Nodes agreeing on conduct scores for a given account would ideally avoid synchronizing lots of history (complex, error prone, resource intensive).
• How do new nodes joining the mesh trust history being provided, and how to form consensus. I believe we should avoid all solutions that lead to some kind of consensus algorithm, and ideally move away from history-based solutions as much as possible.

Our current notion of account history that we use to compute a score is unlikely to be translated unchanged into mesh. It's entirely too much state, which is baggage not only for storage and transfer to other nodes, but forming consensus on what is the true state (order and match outcomes). If a node joins the mesh, how do they get an account's state? Just get it from a peer and let it be true? After a few years, how big is this total mesh "state". e.g. 1 million accounts, N latest history items per account, etc. Since we will not be creating an auxiliary blockchain to do help with this, we need to simplify things and get clever to deal with this.

New approach with bonds. I have been thinking about penalization occurring closer to the level of a swap or a specific bond assigned to a swap. This is not a new bond per swap/order, just associated preexisting bond for a given order or swap, so that observers looking at txns can see the swap outcome, inspect the meta data in the swap, see what bond it would invalidate. In this scheme orders would still be submitted by "accounts", with associated bonds (083200d). An account has associate bonds, which are added on demand, and pruned with their inherent expiry. In that linked commit, it's still the old history based system but with an account "tier", which offsets bond total "weight". This is not solid, just a new way to start thinking about auth in DEX.

Minimizing scoring parameters is a goal too, one that could be resolved if orders or matches have associated bond (although could be not necessarily created per-order but tracked in the current account system.)

Another vision. Personally, I would love a solution where any communicated conduct data would be limited to proof of violations rather than history of success and failure that get integrated as we currently do. That is, if an account has active bonds, and no information exists that would invalidate the bonds, the user is clear to participate (although account tiering via bond strength/number can still balance against violations). Bonds txn outputs themselves have an expiry date, so this inherently prunes the accounting data as time goes by. Any bonds not yet expired would be considered active unless data is provided that shows otherwise.

Going further, it would be even better if an order were entirely standalone with respect to authorization, although that would likely mean larger transaction sizes and tricks to associate, invalidate, and carry over and reuse bonds via mechanisms directly tied to the outcome of the swap, which may or may not be possible.

Book and Matching

For book, we might reconsider if a shared synced book between servers is feasible, or do we design some kind of order relaying/broadcast system where orders go out, propagate nodes, and match candidates come back. That of course creates new questions of which one is accepted, do servers consider all matches and then agree by consensus. What is the role of the client, and do they provide input on the acceptable matches before the network commits to one?

Throw the order commitment/preimage scheme in the mix and things have the potential to be really hairy. It's not even clear to me if the current notion of an "epoch" will survive unmodified in a mesh. Epochs will likely need to be much longer to allow preimages to propagate, and with some simple form of consensus combined with resolution of conflicting states when matches actually start negotiating. Perhaps users can be part of the process by waiting for match candidates within a certain "network matching window" and they accept best matches, but of course that requires the counterparty to accept the same match. In any solution, the taker's match "ack" will now be important for the maker to receive before initiating the swap.

In short, I'm not only open to major conceptual changes to make a mesh work and work relatively simply, I'm expecting it to some extent.