Paradigms of Distributed Computing
Before divining into the technical details of the RGB, the introduction to the fundamental concepts of the technology and the study of the base terminology represent an essential step towards a thorough understanding of the subject.
Indeed RGB it's a combination of several pieces of the Distributed Computing Domain, in particular:
Commitment scheme with cryptographic hash functions.
The combination of these topics is the underlying substrate that makes RGB operational.
RGB locate itself as a new additional piece of the vast word of Distributed Computing.
Distributed computing, is a branch of Computer Science which study the protocol systems able to exchange and compute data information between a network of computer nodes: the set of computer nodes and the underlying protocol rules which allows the computation of these data are the constituents of a Distributed System.
The nodes, composing the network are able to independently verify and validate some set of data and they can construct, depending on the protocol, complete or partial snapshots of information elaborated by the network: these are called the states of the distributed system and essentially represent the expression of properties and the underlying agreement over those properties that are established during network operations.
The most important property of a distributed system is represented by the Chronological Ordering of the operations and the related data timestamp and thus the ordered sequence of state changes that take place inside the system. In fact when we talk about Consensus, we are talking about:
Recognizing the validity of the state changes by the nodes according to the protocol rules.
Establishing consensus on the order of the state changes so that every node knows which operation precedes the other and the state cannot be reversed once it has changed: the so called anti double-spend property.
The achievement of a resilient and reliable chronological ordering for distributed system, which embeds important properties such as permissiveness and censorship resistance, was reached by Satoshi Nakamoto with the invention of Bitcoin, using the blockchain data structure and a Proof-of-Work (PoW) consensus which is able to entrust different validating participants to the system according to their computational power. Indeed Bitcoin can be considered the first working example of a permissionless Distributed Consensus System.
We will discuss various kind of Distributed Consensus Systems which have some degree of hierarchy and interrelated properties between them. They are differentiated on how they determine and enforce the most updated state of the system:
Blockchain + PoW Mechanism. The sequence of state transitions is public and auditable and is organized in transactions included in ordered blocks which are added one upon the other. The security of the system lies on the amount of work required to produce an alternative chain which revert the actual greater-work chain which is considered as the valid chain. For instance Bitcoin is based on this technological stack.
State Channels. Is a system constructed between 2 (or more) parties and which depend hierarchically on the blockchain layer. The final state is represented by the last transaction out of sequence of ordered invalidating transactions, signed and agreed by the parties _off-chain_. The final state can be enforced by each parties by publishing that last valid transaction on the layer 1. The most known application of payment channels, a simplified form of state channels, is the Lightning Network.
Client Side Validated Data - Stash. Is a system that can be implemented both on top of blockchain and state channels and it is based on a certain amount of data whose validity, computation tasks and update is entrusted to a limited number nodes. Unlike layer 1, the data to be validated by each client node represent a defined subset of the entirety of all state transitions of the client-side protocol, and not every transition happened within it. This validated subset of data in possession of a client node is what is called Stash. Basically, the client needs to validate the whole history of the state transitions occurred from the start to the last transition and which relate to some digital properties exchanged among the counterparties involved. Seen as a whole, the validation mechanism of the shard which produce the stash is called Client-side Validation and is at the base of all RGB operations.
In order to precisely frame the applications of each Distributed Consensus System and their underlying data structure it's important to understand the limitations that affect each one of these technology. This condition is expressed in form of a Trilemma which is connected to an important theoretical result of Distributed Computing, known as CAP Theorem. which states that:
Any distributed system can provide simultaneously only two of the following three guarantees:
Consistency - Every node in the system agree on the current global state.
Availability - Every request to the system receives a response.
Partition Tolerance - The system continues to operate correctly despite a network partition, e.g. failures or delays between nodes.
Seen from a more consensus-focused point of view, the properties of the theorem can be reformulated in the following way:
Consistency ==> Integrity
Availability ==> Decentralization
Partition Tolerance ==> Scalability and Confidentiality
In synthesis:
Blockchain preserve Integrity and Decentralization but lacks Scalability and Confidentiality as each node need to replicate publicly and in full every state transition.
State Channels preserve Decentralization and Scalability but doesn't preserve Integrity as the state can be changed or updated asynchronously by the counterparties.
Stashes of Client Side validated data are Scalable and maintain Integrity, however they are not replicated by the vast majority of nodes of the network lacking Availability. For this reason these data are not decentralized as a single point of centralization which backup them is required to recover them in case of loss.
An important feature to take into account is the different way through which State Channel and Client-Side validation architectures update the state of the data:
Channel state must be synchronous between the counterparts.
Client side validated state update can be asynchronous.
Naturally, if the client-side validated data are embedded in the state channels, the state update will be ultimately based on an asynchronous process.
In addition to the three layers just described, a fourth layer of Bitcoin Finance (#BiFi) which leverages both state channels and blockchain can complete the whole ecosystem. The general picture and the deep interconnections of all the layers, with the blockchain layer at the base, allows to achieve all the properties of the CAP theorem in a composite way.
In the next section we will delve into Client-side Validation and its features.
Last updated
