New Approaches to Solving Atomicity Problems in Distributed Databases and Off-Chain Networks
HodlX Guest Blog Submit Your Post
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 could 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.
Let’s start with solutions used in distributed databases.
- One-phase commit is the most straightforward way to accomplish atomicity. The transaction manager sends and the participants follow the instruction to make changes. This model is inefficient and has a lot of inherent threats and pitfalls.
- The two-phase commit is more comprehensive as each transaction is divided into two phases. First, the transaction manager queries each participant to determine whether a transaction should be committed. They create the necessary provisional entries and vote to commit. If all the participants agree to make a payment, the manager sends them the commit request.
- The three-phase commit version divides the first stage in two and has a higher security level. The manager also starts with querying the participants for their votes to commit, but he gives the prepare instruction only when all participants give their consent. Then, the participants create entries (make allocations) and confirm their preparedness for the next stage. The last phase is performed only after the manager receives all the confirmations.
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. Let’s take a look at the transaction process flow at the Lightning Network. 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. HTLA can be used even if the blockchain does not support HTLC. In this case, the connectors (special Interledger nodes that are responsible for routing) can replicate HTLC using alternative methods – Conditional Payment Channels (with HTLCs), On-Ledger Holds/Escrow (using HTLCs), Simple Payment Channels, Trustlines etc., – to ensure that all contract requirements (e.g. payment time, amount, payment unlock conditions) are met.
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 new 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.
Atomicity developments in decentralized networks have been driven by new concepts which have their advantages and drawbacks.
- 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 extremely careful when implementing them because centralization of observers/notaries may harm the network, but a suitably designed system may keep them decentralized.
CEO at the GEO Protocol
Max has an intensive experience in the field of real business (he is an owner of one of the retail chains) and trading on traditional and crypto stocks. His financial education allows him to analyze and predict the situation, and develop new disrupting products for the future. Max is an ideologist, visionary and CEO of the GEO Protocol – the technology for decentralized P2P exchange of value that is not based on a common ledger.