Menu
x

The vDLT Approach

To address these issues, we present vDLT -- a service-oriented blockchain system with virtualization and decoupled management/control and execution. The distinct features of vDLT are as follows.

  • Unlike most existing DLT systems that do not distinguish different services and applications, vDLT explicitly considers the QoS requirements of different services and applications. Specifically, services and applications are classified into different classes according to their QoS requirements, including confirmation latency, throughput, cost, security, privacy, etc.
  • This is a paradigm shift from the existing "blockchain-oriented" DLT systems to next generation "service-oriented" DLT systems.
  • Different QoS requirements are fulfilled by advanced schemes inspired by the development of the traditional Internet, including classification, queuing, virtualization, resource allocation and orchestration, and hierarchical architecture.
  • Management/control (e.g., governance, smart-contract-execution nodes selection, and resource allocation) and execution of smart contracts are decoupled to support QoS provisioning, improve decentralization, and facilitate evolution in vDLT.
  • With virtualization, different virtual DLT systems with widely varying characteristics can be dynamically created and operated to accommodate different services and applications.

Classification

Different services and applications built on DLT have widely varying QoS requirements. In vDLT, services and applications are classified into different classes according to their QoS requirements, including confirmation latency, throughput, cost, security, privacy, etc.

A class of service (CoS) byte is defined for each transaction in vDLT, as shown in the following figure and table. Due to the fact that it is difficult to predict future services and applications in DLT systems, we focus on the existing representative services and applications in the current design. Specifically, the three most significant bits of the CoS byte are used to indicate different classes. The rest bits in the CoS byte will be used for future extensions, which will be compatible with the current design.

Class of Services

Class of Services Table

Class of service (CoS) in vDLT


  • Fast confirmation applications require instant confirmation for the transaction. Confirmation latency is the main concern of these applications, e.g., finance and retail applications.
  • Computation-intensive applications require extensive computational resources. Decentralized machine learning and artificial intelligence applications are examples of this class.
  • Storage-intensive applications require extensive storage resources. Decentralized storage and content distribution applications are examples of this class.
  • Low cost applications are sensitive to the cost. Internet of things (IoT) and social media applications are examples of this class.
  • Private applications require privacy guarantee.
  • Management/Control class is used the control functions (e.g., resource allocation), management and governance functions of vDLT.
  • Best effort describes a service in which the system does not provide any guarantee that service is delivered or that delivery meets any quality of service.
  • Scavenger applications are those ones that are not desirable in the system.

Decoupling Management/Control from Execution

The classified transaction will be sent to a group of management/control nodes, who are responsible for the management/control functions, including the prioritization of transactions, resource allocation, and the decisions on which nodes should execute the smart contract in the transaction. This group of management/control nodes conduct a blockchain consensus mechanism, and manage the health of the participants. After the consensus is reached, the transaction is sent to a group of execution nodes, who are responsible for the execution of smart contacts. Similarly, this group of execution nodes conduct a blockchain consensus mechanism to produce user transaction blocks. Please note, unlike some other blockchain systems (e.g., EOS and Dash), the management/control nodes do not produce user transaction blocks, which will be produced by the execution nodes in vDLT. This will improve decentralization of vDLT, and address the centralization issues criticized by the community. The following figure shows the architecture of decoupling management/control from execution in vDLT.

Decoupled Management/Control from Execution

Decoupling management/control from execution in vDLT


Virtualization

With virtualization, the underlying system resources (e.g., hardware, compute, storage, network, etc.) are abstracted. A virtual DLT system is a combination of system resources on top of a substrate DLT system, as shown in the following figure. To accommodate different QoS requirements of different services and applications, multiple virtual DLT systems with widely varying characteristics can be created and co-hosted on the same substrate DLT system.

Virtual DLT systems mapped onto one substrate DLT systems

Virtual DLT systems mapped onto one substrate DLT systems


Some existing DLT systems, e.g., EOS, have made fine steps in this direction. For example, a user of EOS can "stake" his/her EOS tokens to reserve the resources (RAM, CPU, bandwidth, and storage) in the blockchain and is granted access to the reserved resources based on the amount of the staked tokens. Compared with EOS, the abstraction introduced by the virtualization mechanism allows vDLT to manage the resources in the system in a more flexible and dynamic way.

Dynamic Resource Allocation

Dynamic resource allocation is an important component in "service-oriented" vDLT, will will satisfy the service-specific needs and at the same time optimize the use of scarce networking, storage, and computational resources. When making the decision on resource allocation and which nodes should execute the smart contact, the QoS class of the transaction and the state of the available execution nodes will be carefully considered. The algorithm is described as follows.

Dynamic Resource Allocation