New Approaches to Solving Atomicity Problems in Distributed Databases and Off-Chain Networks
Look at approaches to solving the atomicity problems in up-to-date, distributed databases and off-chain implementations such as HTLC, HTLA, PM, and HTLR.
Join the DZone community and get the full member experience.Join For Free
When we make a transaction in payment networks, we want to be 100% sure that it will be fully completed and reach its final destination so no one will lose their money. To guarantee the validity, each database transaction should meet four main criteria, which form the so-called ACID model. A transaction must be A-Atomic, C-Consistent, I-Isolate, D-Durable.
We would like to speak about one of these features — atomicity. Atomicity means that a database (DB) transaction must follow “all or nothing“ rule. Atomic transactions can be either performed in whole or not at all and are crucial for ensuring data consistency. In this article, we are going to tell you about different approaches to solving the atomicity problems in up-to-date distributed databases and off-chain implementations such as HTLC, HTLA, PM, HTLR, notaries in Interledger, and observers in Geo Protocol.
Conventional solutions used in distributed databases suggest one-, two- or three-phase commit versions. The more phases, the higher security level.
Atomicity in a single DB node is implemented with the help of a feed-forward ledger. When the user requests a transaction to be reflected in the DB, the entry is first made durable and then it is written into the disk ledger. If a system fails halfway through the process, the transaction can be rolled back or restored from the disk upon restart.
Atomic Transactions in Off-Chain Networks
Lightning Network and other off-chain networks use a variety of specific solutions to prevent loss of funds during transactions through somebody’s fault.
Up-to-date solutions are mostly using HTLC (hashed timelock contracts). It allows spending funds after presenting the original secret before a preset timelock. First, the receiver node generates the secret and calculates its hash. The hash then is sent to the sender node as the basis for HTLC generation. The sender generates the contract and sends it to node1, the next node on the route that creates a new contract (using the same hash) with the decremented timelock. This newly-generated contract is further sent by node1 over the route to node2 that repeats the actions and decrements the time-lock again. It goes all the way to the receiver who signs off the funds spending (unlocks payment) using its own secret which was generated at the beginning and receives the money from the node that sent the contract.
Interledger is an open protocol suite for transfers through various ledgers. Transfers can be performed using one of the two modes: Universal and Atomic. Under Universal mode, Interledger operation of atomicity is provided by HTLA, which is an HTLC modification.
Sprite channels is a project that suggests a new version of payment channels to solve some Lightning problems related to atomicity. The HTLC has been significantly upgraded by adding the preimage manager (PM). The developers wanted to make the PM a sort of arbiter for HTLC and delegate the decision-making on contract expiry from any individual node to the software. Sprite channels should have a unified contract expiry time. If a preimage has been timely published, all disputes are accepted because it’s impossible that one party revealed preimage in time and another didn’t (both parties have the same expiration time). But if the preimage is published at the wrong time, no payment can be disputed.
Celer Network is a solution for scaling public blockchains and maximizing their performance through off-chain technologies. Here the PM has become a hashed timelock registry (HTLR) with mainly the same features. HTLR has two dependency endpoints, IsFinalized and QueryResult and the two features can eventually be merged.
In Atomic mode, Interledger uses notaries selected by the participants to coordinate transfers. A payment conducted through the notary resembles a payment in Lightning with HTLC. The only difference is that before revealing the secret, the receiver node has to transfer the contract for verification to notaries, the special entities selected randomly from their general register who have to vote on payment approval.
This role is present in the GEO Protocol concept which offers a unique approach to resolving the atomicity problem. The project team is creating a decentralized peer-to-peer off-chain network that allows exchanging assets. The observers are involved if a participant faces problems when making a transaction. The observers can’t influence the transaction direction and change anything in it. They are not used for verifying every transaction and interfere only on the user’s request.
GEO is using a framework similar to two-phase commit for regular transactions. All the participants sign something like preparedness for payment and the payment is executed if everybody has the list of signatures. The observers act between the phases if a participant states the absence of the document. In this case, the observer gets the list of signatures from any node and sends it to all the participants or does nothing if it is impossible and the transaction expires in due time.
As one can see, atomicity developments in decentralized networks have been driven by new concepts:
- The strength of the hashed timelock contracts is the mitigation of losses when a node falls offline and the security for both the sender and the receiver. The problem is that the funds have to be frozen in the channels, and the participants have to be constantly online to avoid losses.
- HTLC were modified to get HTLA which makes possible to use HTLC in different registries and HTLR which solves the node falling offline problem.
- The brand new solutions are observers and notaries. We should be careful when implementing them because centralization of observers/notaries may harm the network, but a suitably designed system may keep them decentralized.
Published at DZone with permission of Max Demyan. See the original article here.
Opinions expressed by DZone contributors are their own.