decred.org/dcrdex@v1.0.5/tatanka/spec/intro.md (about)

     1  # Introduction to Tatanka Mesh
     2  
     3  Tatanka Mesh (TM, or just "the mesh") is a multi-blockchain mesh network offering a suite
     4  of services for clients. This initial specification version may reference the
     5  "toy mesh", which is a proof-of-concept implementation of Tatanka Mesh. 
     6  
     7  ### Services
     8  
     9  1) Reputation services. The mesh will handle client bonds and reputation in
    10  a fashion similar to a dcrdex server. Bonds provide network access, increased
    11  network usage limits, and can offset penalties for high-volume users. Clients
    12  self-report successes and failures, which are used to build a reputation score.
    13  If a clients reputation score drops too low, they can have their usage limited
    14  or outright suspended.
    15  
    16  1) Subscription channels, or "apps", perform a function similar to a chat room.
    17  Clients subscribe to "topics", which can also have more narrow "subjects" to
    18  which the client might subscribe. Subscription channels can be used to construct
    19  various applications, such as a peer-to-peer decentralized exchange. The mesh
    20  does not prescribe protocols for communications on a topic or subject. Such
    21  protocols are defined by the client software.
    22  
    23  1) Client message routing. The mesh can route messages from client to client,
    24  even when those clients are connected to different mesh nodes. Client messaging
    25  is end-to-end encrypted, so the mesh network itself cannot read the contents.
    26  The encrypted messaging primitive is called a "tankagram". Clients connected
    27  to the same subscription channel might send one another tankagrams to, for
    28  instance, communicate details about an ongoing atomic swap.
    29  
    30  1) Oracle services. The mesh will coordinate distribution of network transaction
    31  fee rates that might be used as part of validation for app actions. The mesh
    32  could potentially distribute fiat exchange rates as well, although such
    33  functionality is not implemented in the toy mesh. See also the
    34  [Outstanding Questions](#oustanding_questions) section.
    35  
    36  ### Other Important Features
    37  
    38  - Although the toy mesh uses WebSockets for communications, there is no
    39  prescribed transport protocol, and other communication backends are planned,
    40  especially BisonRelay. If clients are using compatible protocols with the
    41  requisite features (e.g. BisonRelay), client communications (tankagrams) can be
    42  taken out-of-band.
    43  
    44  - Version 0 of Tatanka Mesh will be whitelist-only. This means that the mesh
    45  network itself is a network of trusted nodes. By using a whitelist, we can
    46  initially forego implementation of what will inevitably be a complicated mesh
    47  node reputation system.
    48  
    49  - Tatanka Mesh does not maintain a global state. Mesh nodes need not agree on
    50  client reputation, and the ability to synchronize reputation is extremely
    51  limited. See the [Outstanding Questions](#oustanding_questions) section for more
    52  discussion.
    53  
    54  ### Why?
    55  
    56  The mesh architecture is designed in this way specifically to move all DEX
    57  operations to the clients. In the litany of proposed U.S. legislation aimed at
    58  regulating cryptocurrencies, even the most favorable bills indicate that
    59  operating an order book would compel the server operator to collect
    60  know-your-customer (KYC) and anti-money-laundering (AML) information from users.
    61  This is going to be the case regardless of the (non-custodial, trustless) nature
    62  of the underlying exchange protocol. While we believe that the trustless nature
    63  of atomic swaps should preclude an order book operator from these regulations,
    64  that is simply not going to be the case. As such, we're moving towards a fully
    65  P2P model. Tatanka Mesh does not even know what a market is.
    66  
    67  ### Outstanding Questions<a name="oustanding_questions">
    68  
    69  - Clients will self-report successes and counter-party failures, but who is in
    70  charge of auditing these reports before inclusion into reputation? For example,
    71  the mesh does not know what an atomic swap is, so how can a mesh node validate a
    72  reported swap failure? Two possiblities are...
    73      1) The server could audit the reports, but do so in terms of blockchain
    74      primitives that exist outside of the context of particular applications. For
    75      example, the server could audit reports in terms of "HTLC pairs". The
    76      important thing is that the server does not even appear to participate in
    77      any way in the maintenance of an exchange market.
    78      1) The server could outsource auditing to clients, and accept the majority
    79      result. This might require the server to expose some blockchain functionality
    80      to clients who may not have e.g. txindex enabled on their UTXO-based
    81      blockchain. This also creates perhaps more questions than it answers. What
    82      if there aren't enough clients connected? How do we account for the report
    83      while we are still waiting for client audits?
    84  
    85  - Since the mesh network does not maintain a global state, what happens if a
    86  client is suspended on one node but not another? For the toy mesh, reputation
    87  is only checked by the node(s) to which the client is directly connected. This
    88  simple system might work for a whitelisted network, but is not a long-term
    89  solution.
    90  
    91  ### More Info
    92  
    93  [Introduction to Mesh DEX](meshdex.md)