key mesh design decisions

[chappjc]

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.

[JoeGruffins]

On reputation:

I think the easiest solution is the one you suggest about keeping a list of bad actors. Before servers agree to form a mesh they also must agree on the bad actors. They can even combine lists.

I think the bond system lends itself to this because, the user will get the original "fee" back eventually anyway. If a malicious server wants to ban them for not a great reason, it's only a loss of time for having the funds and they only lose the two transaction fees for creating and redeeming the bond. It prevents spamming the ban list because each banned user would need to have submitted a bond which has value. The bond has a lifespan which prunes the ban list naturally.

In this scenario a server can either simply trust other servers, or attempt to validate infractions.

An obvious problem with trusting could be a malicious server that bans everyone. I think a quick and easy solution to this could be to also give servers a reputation. Operators could choose not to trust other servers with no or bad reputation. It would also be relatively easy to purge all ban info that came from a certain server, if we later decide they were acting in bad faith.

Maybe the ban list could also be just bans, and we could keep all the current per-dex user ban score accounting. User's only make it to the ban list if they were really bad.

This is a brainstorm so could be some major logical flaws.

[chappjc]

Interesting points. I think I'm warming to the idea of a network that simply gossips account history sets around, although it raises a number of questions about their storage, transmission, and acceptance. Still, maybe this doesn't have to be so rigid and formal as I let on. Mmmm, yes, if the transmitted account data is just the violations that are weighed against continuously-pruned on-chain bonds, that seems reasonable. (referring to the concept in the "Another vision" paragraph of the issue)

---

On a different note, I think that for a decently size mesh to have any chance of forming, nodes will need to be able to choose any set of markets they like, where a single market with a certain core definition would form a subset of the mesh as a whole. Any given market would be opt-in. If that means gossiping which nodes support which markets, that might be ok.

[buck54321]

Thinking about restoration. Maybe something like this?

• Bonder interface gets a new method

DiscoverBonds(bondKey *secp256k1.PrivateKey, birthday time.Time) ([]*Bonds, error)

Asset backends must be able to satisfy the interface. For Decred, it would look something like...

• Bonds MUST get a change output paying to public bondKey, the "tracking output".
• The tracking output SHOULD be spent immediately to a wallet address.
• Internally, we will perform a filter scan from the birthday, similar to account discovery but with the bondKey instead.

This should work for discovering and refunding even if the wallet is not the same wallet that created the bond, i.e. RPC-created -> SPV-restored or vice versa.

It does, obviously, add a transaction. That said, I'm starting to think that using a high-fee asset like Bitcoin or Ethereum would be ill-advised anyway, just because of the unpredictability of fee rates at renewal time. If we're not using one of those assets, the extra transaction doesn't really matter.

---

Seeing restoration through to the UI, and with multiple assets in mind, I think the user will just have to select which assets to search, as part of the registration process when restoring from seed.

[buck54321]

Closing this for now, and we can open new planning issues as needed.