Blockchain Virtualization with Orbs
This is a sample section of the Orbs Position Paper. To access the entire paper, click here.
Virtual Chains and Blockchain Virtualization
Blockchain virtualization implemented over the Orbs platform provides the illusion of a dedicated blockchain while running on top of a shared physical node infrastructure, thus enjoying the same security and decentralization provided by the shared environment. Virtualization separates the resources available to applications from the underlying physical ones.
The properties of blockchain virtualization include isolation, quality of service, SLA, control, governance and elastic resource capacity.
The majority of blockchain implementations today, like Ethereum, are shared, where multiple decentralized applications run side by side without isolation, suffering from unpredictable performance. Blockchain virtualization allows us to overcome these limitations without compromising on the risks of a centralized or private infrastructure.
Almost two decades ago, the industry started to shift towards server virtualization. Today, almost every consumer application runs on virtual machines. A similar shift started a decade ago in networking, where virtualization enabled large networks with flexible topologies to run as virtual networks over an underlying shared infrastructure, providing the look and feel of a dedicated private network.
We expect the same industry shift to take place in the field of blockchain.
The term “virtualization” broadly describes a layer of abstraction that provides separation of a logical resource from the underlying physical delivery of its function. With blockchain virtualization, each component of the blockchain infrastructure, such as the consensus, the state and block storage, and the virtual machine (compute) layer are virtualized. This allows virtual consensus instances to be allocated with a desired transaction confirmation rate that can differ across virtual chains.
Moreover, different virtual consensus instances can operate concurrently, scale gracefully and provide better utilization of resources. Unlike private blockchains, virtual consensus instances enjoy the security, resilience, decentralization and compliance benefits of the underlying shared infrastructure.
Sharding via Blockchain Virtualization
In systems engineering, scaling systems cannot always be achieved by adding more resources, due to bottlenecks that cannot grow easily. Sharding is a technique for scaling out systems by dividing them into smaller, nearly-independent parts called shards, each small enough to work well despite bottlenecks.
Decentralized consensus is an unavoidable bottleneck; the Orbs platform decouples tenants to different shards allowing the network to scale out horizontally as new tenant apps are added. Contrary to centralized infrastructure solutions like AWS, simply adding resources is usually not enough to increase capacity. When the number of products that use AWS grows, increasing infrastructure capacity by adding hardware like servers and network connections, is usually enough to meet demand since separate products run completely separately.
This normally isn’t the case with blockchain.
Transactions on Ethereum, for example, even by different contracts, may affect one another and therefore must be performed in sequence. To make matters worse, the number of verifiers in PoW blockchains is related to the level of security the blockchain enjoys; reducing unit sizes by sharding is reducing the level of security in the same proportion. Significant efforts are invested in research and development of effective sharding techniques in Ethereum.
This problem is apparently much simpler to solve in the proposed architecture for Orbs. Permissioned consensus models, especially when employing consensus committees, do not weaken its security properties when sharded.
Different decentralized consumer apps are independent and work with different unrelated assets. This is particularly true if fees are paid in bulk and not per transaction. By sharding decentralized apps by default, the architecture can revolve around parallelization.
The Orbs infrastructure is designed to support a large number of independent consumer applications running on top. While applications are independent from one another by design, when running on top of a shared infrastructure they enjoy the benefits of sharing resources, but still allow the system to scale out thanks to the natural sharding of virtual chains.
The 3 types of cost factors in blockchain applications are consensus rounds, reads and writes of state storage, and compute operations. Consensus on transactions of different virtual chains can run independently as long as there are no ordering dependencies among them. Therefore, consensus of different virtual chains can be sharded and run concurrently on separate resources.
As there is no ordering requirement, the ledgers of virtual chains can also be maintained independently. Compute scheduling requires that dependent transactions will be executed in order. As virtual chains have independent ordering, their compute can be performed in parallel. Moreover, the isolation of state for each virtual chain reduces the memory requirements of its virtual machine.
To read the entire position paper, click here.
Join the Orbs community:
- GitHub: https://github.com/orbs-network
- Telegram: https://t.me/orbs_network
- Twitter: https://twitter.com/orbs_network
- Reddit: https://www.reddit.com/r/ORBS_Network/
- Read the Orbs white papers: https://www.orbs.com/white-papers
