5.4. Distributed Hash Table (DHT)
Sequentia’s hitherto described DEX capabilities mostly use technologies that assume the parties involved are already in contact when transferring money. However, to build a real marketplace, users must also be able to find one another without knowing each other in advance; a communication system is needed to allow them to choose between different orders waiting to be fulfilled in the market.
Therefore, we propose a system wherein orders are broadcast and stored by nodes in a decentralized manner using a distributed hash table (DHT). Every Sequentia user or operator can activate the DHT-DEX functionality: DHT nodes are free to sync the full DHT, prune it, and start partial sync only when they are online (starting from the most recent orders) or not sync at all. Once activated, the user’s node starts syncing the Distributed Hash Table of orders from its peers. The wallet looks at the DHT for possible matches until it finds the first user online, then initiates an atomic swap.
Not all orders broadcast in the network that reach the peer are registered on the hash table; instead, each node stores only those orders that are filtered based on their interest and will pass on to the network only what is stored, just as on BitTorrent or other similar peer-to-peer systems. A bigger DHT grants more opportunities to find a successful match but, on the other hand, requires more time and resources to be synched and stored.
This means that all nodes will never share a single, identical DHT, and also that there will likely never be any nodes who know or store the entire order book history since the complete set of orders is stored only collectively in many fragmented tables in possession of different node owners.
The filters applied in the syncing phase can be set over a chosen pair, a price range, or the amount requested in the transaction. Nodes can freely prune unwelcome orders from their DHT, also preventing them from being relayed to other nodes. Some nodes may prune the expired and closed orders; others may keep them to elaborate statistics or better recognize spam.
An anti-spam filter is necessary because an attacker could populate the DHT with fake orders. For this reason, each node can configure anti-spam filters, removing orders from nodes known to spread a suspiciously high amount of orders that are never fulfilled, closed, or canceled. If the anti-spam filters prove insufficient to manage a vast amount of fake orders or require too many resources, a third party can intermediate the synchronization of the DHT (see §5.6).
Users may rely on a price ratio suggested directly by the node wallet when creating an order. The user would then choose between two indicators:
a) the price provided by a centralized exchange/service through an API or
b) the price retrieved from the DHT, which is calculated in a fully decentralized manner.
A messaging system based on a distributed hash table (DHT) has a few drawbacks:
Speed and efficiency are far below what a centralized server can provide;
It might be too heavy and resource-draining, especially for mobile devices, considering what an average user is willing to dedicate towards this purpose;
It is impossible to know exactly when an order is closed since the atomic swap is bilateral, meaning that users cannot remove orders from the DHT unless confirmation is already provided by the order’s owner. This may lead to a huge number of message requests/responses between concurrent users that match each other even if some have already finalized the exchange transaction. Moreover, some orders might be left unmanaged by users (e.g., the user broadcasted them but went offline afterward or never finalized the atomic swap for any reason). Even if wallets can filter them, these orders can cause the DHT to become bloated with useless data;
It leaves room for spam attacks: an attacker could populate the Sequentia DEX with fake orders. This attack would be free and could disrupt the network if not promptly recognized and banned by the other nodes.
For these reasons, specialized nodes can intermediate the messaging system as described in §5.6.
Last updated