Solving the Scalability Problem of Unpermissioned Crypto-networks

How are current crypto-networks going to cope with increased application demand?

Bitcoin’s demand is generated mostly by financial transactions. These are an important, but small fragment of all distributed applications. Ethereum’s demand, in addition to financial transactions, is generated mostly by smart contracts used to generate tokens for ICOs.

Although ICOs are becoming very popular, again this is just a fragment of all possible distributed applications that could take advantage of “the blockchain”.

The researchers involved with both networks are aware of their current limitations in scalability. How could these network provide for the future market of general distributed applications, several orders of magnitude larger?

The scalability problem

Scalability can be a problem when some resource requirements grow exponentially with the number of nodes in the network. For example, the time to distribute or process transactions, or the time to process a block, or the communication time to distribute a block, or the space required for storing a block, or the space/time required to store and process unconfirmed transaction, etc.

These parameters can be kept in check, to a point. However, any system will have limits, given its design and the technology at that time.

The researchers at Gorbyte, Inc. provide two answers to scalability.

1. One hundred to one thousand fold improvement in throughput, and
2. Off-loading the blockchain by supporting general distributed applications (GApps). These are applications that can use the blockchain, but run off the blockchain.

1. Improvement in throughput: Current PoW crypto-networks are not designed for efficiency and most of the above example parameters will tend to grow faster than the number of miners in the network. One of the reasons is that the PoW system is not truly decentralized, but randomly centralized. Another reason is that most of the miners’ processing power is used for a conceptually simple task: to select a random “real” miner. PoS systems should do better, but are as yet unproven.

Gorbyte uses a more decentralized design for its consensus process:

• Every node participates in the consensus agreement process.
• Every node communicates only with a small number of random logical neighbors.
• The reconciliation communication among all nodes happens in parallel.

• Several precautions are taken in order for blocks to be similarly assembled by every node, at the start of reconciliation (e.g.: synchronous operation, canonical ordering of transactions, no picking and choosing of transactions by miners).
• Only in a small percentage of cases a node will require information from outside its logical neighborhood.

Thus the agreement process requires a small amount of time and much less processing power.

If a node cannot reach an agreement within a predefined time (e.g.: delay or malfunction), it will have to reinitialize and get the last block from an active peer node.

For the above reasons, Gorbyte is not bound by processing power, but by communication broadcasting and downloading times.

Considering also the exponential improvements in new technologies, we predict that the Gorbyte architecture will remain scalable. That is, the increased demand for new resources (e.g. bandwidth, memory, processing power) is expected to continue to be satisfied as the number of nodes in the network grows.

2. Off-loading the blockchain: The second answer to the problem of scalability is provided by Gorbyte’s BRUD device architecture.

Gorbyte, in addition to supporting smart contracts (DApps), will support general distributed applications (GApps) that are able to use the blockchain for critical events and historical data, but run off the blockchain. For most applications, this greatly reduces the amount of processing and storage requirements on the blockchain, thus allowing the blockchain to be usable by the much larger market of general distributed applications without the limitations imposed by smart contracts.

Smart contracts are objects stored on the blockchain, running on the blockchain and producing results on the blockchain. Thus any input, execution or output event on such objects involves the blockchain and, by definition, it is replicated on all the network nodes.

While there is a need for smart contracts for critical applications, the majority of general distributed applications (an estimated five sixths of the total software market) will need to store only critical events and information on the blockchain, but can do most of their processing and data manipulation using resources off the blockchain.

The availability of GApps will reduce the requirement to develop every blockchain application using the only tool currently available (smart contracts), thus at the same time it will:

• reduce the throughput and storage requirements of the crypto-network, and
• allow for an expansion of the type and range of general distributed applications taking advantage of the blockchain.