The public blockchain landscape is fragmented into different categories based on the features that a project prioritizes. Major high-performance projects like Ontology and EOS have been operating a stable infrastructure for over a year and provide tools for building applications. Across the business agnostic infrastructures, the single most important challenge today is to onboard real-world business and accommodate associated requirements. This is the first article in a series of four focusing on the technology that makes Ontology a public blockchain network with solutions ready for all businesses.

1 of 4: Scalability and performance

2 of 4: Interoperability and customization

3 of 4: Security

4 of 4: Distributed storage

Before taking a dive into the concepts, it is essential to understand what Ontology is and why it is ready for all businesses.

To put it simply, Ontology is a high-performance chain network developed to accommodate two pain points which withhold businesses from building their business scenarios on a blockchain. First, when replacing legacy infrastructure with blockchain infrastructure, a blockchain must meet similar performance with high throughput and little to no downtime. Second, the infrastructure must be flexible and allow customization so that different businesses can implement their business requirements and work compliantly.

Ontology reaches 4,000 TPS (transactions per second) on public MainNet, 12,000 TPS for certain test environments, and has sharding and side-chains for scalability, all with little to no downtime. The architecture is customizable with development components and tools in order to meet different business requirements and allow for interoperability. Along with these features, Ontology has a core technology team of over 100 individuals to maintain the infrastructure and develop industry-specific enterprise-grade solutions. This same team delivers professional services and service-level agreements for businesses.

Roadmap towards 2020

Ontology has delivered on the promises drawn out in the original roadmap and now operates a stable infrastructure with many tools for developers and businesses. During late 2018 and early 2019, the core tech team has been testing scalability solutions in POC (proof of concept) and on TestNet, along with performance tuning. The scalability solutions include sharding and side-chains, which currently both run on TestNet and will be available on MainNet in early 2020 or earlier if business cases require it.

Scalability

Blockchain network scalability is solutions to improve the speed of transactions, often measured in TPS. Scalability is different from performance tuning because it achieves higher TPS by sharding or side-chains, whereas performance tuning is about optimizing the virtual machine, for example for smart contract execution. Scalability solutions is a critical component for mass adoption of blockchain because businesses can start operating at the same level as with traditional IT. A classic example is traditional payment services vs blockchain networks, for example, Visa can handle tens of thousands of TPS in a centralized system and Ontology can handle 4,000 TPS (without scalability solutions) on a single chain in a decentralized system. With the use of scalability solutions, blockchain networks can handle the same volumes as Visa with all the added benefits of distributed ledger technology.

Sharding and side-chains enable horizontal and vertical scaling (multi-layer). Sharding is one multi-layered blockchain, whereas the concept of side-chains is multiple parallel blockchains. Shards can exist parallel in the same layer and act as parent shards for multiple layers of shards below. Side-chains are often referred to as layer 2 solutions and is a result of multiple blockchains, generally of same the protocol, which exists separately but are linked to the root chain (original main chain) with a third cross-chain solution (for example Cosmos).

So, when to use shards and when to use side-chains? Overall, it will be determined by the decision as to whether the project wants to be under the governance of the Ontology MainNet (shards) or have its own governance (side-chains). However, there is no simple answer to this. Further considerations include requirements for customization, performance, privacy and control, and network security. Several of these will be addressed in the upcoming articles about interoperability and customization and security.

Sharding

Ontology has its own sharding design and this article will address some conceptual questions for a better understanding of its implementation. For a deep dive into the technology, shard management, and cross-shard interaction, please refer to the Ontology Sharding paper.

Sharding is a type of partitioning which exists in the same blockchain network. The Ontology Sharding design adopts a hierarchical design, which means that the first layer of shards under the root chain (Ontology Main Chain) act as parent shard for the ones below, hereinafter referred to as “multi-layer sharding”. Likewise, any given shard that has shard(s) below will act as a parent shard. A shard is a subset of nodes from the root chain which maintains its own ledger through consensus, either dBFT or VBFT. Each node participating in the governance of the root chain + shard(s), must keep the state of each ledger. If a node participates in the governance of shards below a parent shard it must keep the state of that shard + all above parent shards + the root chain.

The design allows shards to do a certain level of customization in order to accommodate different business requirements, for example, a shard for financial services might want to configure a different charging structure, use dBFT consensus, and implement Merkle Patricia Tree. However, if there is a need for a different governance and economic model, it might be worth considering a side-chain. This is also where it is necessary to distinguish between shards and side-chains.

Business logic is executed in the blockchain network by smart contracts, which essentially are programs written into the ledger. Smart contracts must be deployed in the root chain but can move across shards in the same layer and may be invoked in any shard or the root chain.

The creation of a shard happens when an operator (a node from the root chain or a parent shard) initiates the shard along with some configurations written into the management contract of the shard. The operator can invite other nodes to join the shard after initiation. In some scenarios, a business needs to select a shard for smart contract execution. This will naturally raise the question of which shard to choose. There are three criteria for this:

PoS: How much ONT is staked in the shard will determine how much the shard will potentially lose for malicious activity. PoS can also be considered as the security mechanism in a shard;

Decentralization: How many nodes participate in the governance of the shard;

Reputation: How reputable are the teams behind the nodes in the network.

Ontology has a dual token model comprising of ONT, which is used in governance, and ONG, which is used for on-chain transactions. Shards can have their own token economy based on a representation of the tokens from the root chain. ONT, ONG, and all OEP-4 standard tokens from the root chain can be represented by a shadow token in a given shard, for example, ONTx and ONGx. The tokens have an equal relationship so that ONT (root chain) and ONTx (shard) are of equal worth, as well as for ONG (root chain) and ONGx (shard). It is also not possible for the shards to issue new tokens which are backed by the native OEP-4 tokens. Participants inside a shard can do commerce with ONTx and ONGx and then, based on the management contract, withdraw the shadow representations back to the root chain in exchange for ONT and ONG. Based on the root chain configurations, the ONGx transaction fees that the nodes receive as rewards will be settled at the end of each consensus round, which is every 120,000 blocks accordingly to current settings in the root chain management contract. If nodes in a shard wish to settle the state more frequently, it can be achieved by configurations in the shard’s management contract. Note that more frequent settlement will incur more fees.

Shards can also exchange shadow tokens amongst each other, but only in the same shard layer, which leads to the concept of cross-shard interaction (atomicity). For instance, shard-1 with OEP-4x and ONGx is the buyer and shard-2 with OEP-4y and ONGy is the seller. During the trade:

Shard-1 will transfer OEP-4x to shard-2 and pay ONGx in transactions fees; Shard-2 will hold OEP-4x until the next root chain consensus round;

3. Shard-2 will receive OEP-4y in exchange for the OEP-4x it holds;

4. The events will be logged on the root chain and shard-2 can withdraw the OEPy (previous OEPx) to the OPE-4 on the root chain.

Likewise, will shard-2 transfer a representation of the sale to shard-1 and the state will be settled like abovementioned procedure.

The advantages of sharding compared to a side-chain is:

It increases the security of the network because all nodes are in the same chain;

It is easy to initiate and configure a shard;

Security and protocol updates are maintained by the Ontology core team.

More on the interaction between shards and customization in the next article, which will be on interoperability and customization.

Side-chains

In contrast to a shard, a side-chain is an independent blockchain network which exists outside the Ontology MainNet network — this is also referred to as a layer 2 solution. Side-chains are highly customizable and can, in theory, be of any blockchain protocol with different configurations. However, the current state of blockchain technology only truly allows chains for homogenous protocols with different configurations to interact across each other i.e. only two Ontology protocol chains with different consensus algorithms and gas fee structures can interact with the Ontology cross-chain protocol. Ontology has already during Q1 and Q2 2019 successfully performed POC and TestNet for multi-chain, cross-chain, and side-chain, and will make it available as real business scenarios require it.

Side-chains are a powerful tool for scalability because a side-chain is a new blockchain network that delivers its own performance. For example, a side-chain of the Ontology protocol in production with the same configurations as the Ontology MainNet can deliver 4,000 TPS. This results in 2*4,000 TPS in the entire ecosystem (4,000 TPS from the Ontology MainNet and 4,000 TPS from the side-chain). A side-chain can also host shards.

The differences between shards and side-chains are:

Shards must join and stake for a node on the root chain, whereas a side-chain operates its own root chain;

Shards live under the governance of the root chain and do not have to maintain security and update themselves, whereas a side-chain must maintain its own security and network updates;

Smart contracts can move across shards in the same network, whereas smart-contracts cannot move across root chains (side-chains).

More on interaction between the side-chains (cross-chain protocol) and customization in the next article, which will be about interoperability and customization.

Performance

Performance is a widely used term in the blockchain space, but in general, it refers to the number of transactions that a network can deliver over a given time — TPS. To understand Ontology’s performance we must divide the concept into a few sections:

Performance of the current Ontology MainNet;

Performance of the open-source framework;

Performance of VBFT;

Performance with sharding.

Performance of the current Ontology MainNet

The Ontology MainNet has been running stable since it went live almost a year ago. The MainNet is the production environment where dApps and businesses can build and deploy their blockchain projects. It is, therefore, the most important benchmark for performance.

The MainNet hosts 47 nodes which comprise of 39 candidate nodes and 8 consensus nodes. The consensus, performed with VBFT, delivers 4,000 TPS at peak performance without scalability features. 4,000 TPS accommodates the performance requirements for the current 30 dApps on the network. As the continuous increase in transactions from dApps and users results in a need for higher TPS, the Ontology core team will make scalability features available on MainNet, for example, sharding, side-chains, and parallel execution.

Performance of the open-source framework

The Ontology source code is open-source and available on GitHub. This makes it 100% transparent and everyone can use it. The open-source approach is to ensure that everyone who uses the network can see what is going on behind the scenes and judge for themselves if they trust the blockchain.

The Ontology protocol has been tested several times, both by the community and official institutions. Depending on the test environment, the protocol has delivered performance from 5,000 to 12,000+ TPS.

Performance of VBFT

The performance of the VBFT consensus algorithm depends on the number of nodes in the consensus network, which is determined by a given algorithm configuration profile.

For example, if there are 900 nodes in the network and configuration profile x is implemented, then VBFT selects 150 nodes for consensus based on verifiable random function (VRF). 150 nodes in a VBFT consensus network equal to performance of approximately 1,000 TPS. Please note that this is for a single network without scalability features.

The choice of configuration profile is a security decision that the network governance participants decide. The more nodes to participate in consensus in relation to the total number of nodes in the network, the more secure that network is considered.

Performance with sharding

Sharding is one of the most promising scalability solutions for blockchain networks. The TPS can increase to accommodate even the most transaction-intensive business scenarios with appreciate number of shards in a network. The individual performance of the shards will decrease insignificantly proportional with the number of shards in the network, but the total performance of the network will increase drastically.

In the above graph it is illustrated how the individual shard’s average performance decreases proportional with the total number of shards, and the total performance increases, for example, with 50 shards the network performance equals to approximately 100,000 TPS.

Conclusion: Centralization vs decentralization and performance

The choice of consensus algorithm and level of decentralization of the network governance have a great impact on performance. As Founder of Ontology, Jun Li, says, “There is no magic in high-performance, it is a conscious design decision of algorithm and number of consensus nodes”. For example, Bitcoin is considered to have the most widely decentralized governance because hundreds of thousands of miners help produce blocks through PoW (Proof-of-Work) and tens of thousands of full nodes to maintain the ledger. This results in rather low performance of fewer than 10 TPS. In contrast, networks that operate with quick state finality algorithms like VBFT and more centralized governance models can achieve higher performance. In the end, this is a design decision and Ontology is designed to accommodate real businesses that require high performance.