Saturday, November 10, 2018

After a Decade of Bitcoin, the Next Wave: Stochastic Crypto-networks

Have you heard of... The blockchain? Cryptocurrencies? Digital currency Exchanges? Miners? Tokens? Smart contracts? ICOs? STOs? Blockchain applications? Jobs in the blockchain industry?
None of the above would exist without a crypto-network infrastructure that securely exchanges transactions, guarantees the reliability of the network and the integrity of the replicated data (the blockchain). This technology, introduced by Bitcoin, is now ten years old.
The original goal of Bitcoin was to create a secure method of trading among peers using a currency that could not be controlled by any person, company or institution. It was then discovered that the blockchain concept it employed was extremely useful for many applications.
However, current crypto-networks providing a blockchain infrastructure, including Bitcoin itself, have morphed into networks that rely on special intermediate nodes.
In addition, the established crypto-networks are limited, costly and cannot support the many applications we envision for the blockchain.
The fixes proposed for these problems are complex and are often applied to the side or on top of existing networks none of which is fully distributed.
Other solutions also exist, that have abandoned the blockchain concept altogether.
In the last few years the idea of a scalable network of peers securely guaranteeing replicated data has been a challenge for the research community. Decades of research on Byzantine Fault Tolerant solutions (BFT) has produced only one practical (PBFT) solution, Bitcoin. But Bitcoin delivered on its promise only until its own success substantially changed its nature.

The good news is that research did not stop and new approaches for building the blockchain infrastructure are on the horizon.

The meaning of the words permission and consensus
To fulfill its original goal the blockchain infrastructure had to be free from a central authority, or unpermissioned (permission-less). Transactions had to occur between peers, without intermediate participants, in a fully-distributed network. Every node had the same responsibility for securing the network from attacks, for the verification of transactions, and had a similar probability of getting rewards.
Bitcoin started out as a distributed network - each and every node, usually PCs with fairly equivalent processing power, was able to securely exchange and validate transactions and mine rewards.
However, the Bitcoin "consensus" process (called Proof of Work) was leader-based. One node, the node that won a random computing challenge, acquired the right to dictate the composition of the block to all other nodes in the network. The addition of a block to the blockchain came with the opportunity for that winner node to create a substantial reward for itself.
The word "consensus" was not used by Bitcoin to reflect a general or unanimous agreement, but to express almost the opposite: the requirement for every node to adopt the winner's block composition. By broadcasting the winner's block to every other node Bitcoin guarantees that the blockchain replica is identical on every node.
Tendency towards centralization
In this scenario, every node has an interest in becoming the winner and cash in their reward.
Many entrepreneurs saw the opportunity and acquired powerful specialized processors in order to
increase their probability of winning the rewards. New manufacturers specialized in the production of fast hashing processors emerged and a new mining industry was born.
It became a question of return on investment: how much it would cost to acquire and run many specialized processors versus the average amount that could be earned in rewards.
This led to mining farms and mining pools, with large conglomerates of specialized processors becoming associated with one Bitcoin node. Some nodes became more and more powerful. Their influence on the network was only limited by their self-restraint. If one mining farm acquired more than half of the network's computing power, user's trust in the network would evaporate.
As a result of these developments, the infrastructure, for the Bitcoin crypto-network, soon morphed from fully distributed (all nodes are miners) to de-centralized (a much smaller number of nodes are miners).
Other crypto-networks
It was soon recognized that Bitcoin had a high cost, several problems and limitations. Many developers cloned the Bitcoin open source code, made improvements, and then released new crypto-networks.
The number of crypto-networks has proliferated to several thousands.
Permissioned networks and De-centralized Ledger Technologies
After the success of blockchain technology, spearheaded by Bitcoin, some financial sector companies realized that the blockchain concept could be integrated with their various proprietary approaches to share financial data. This technology is sometimes called Distributed Ledger Technology (DLT), but more correctly it is called Decentralized Ledger Technology.
Financial institutions, by nature, want to own assets (traditionally financial assets). By using DLT technology they may also profit by controlling and selling access to other types of assets. These networks are permissioned.
In permissioned crypto-networks, a set of special nodes act as intermediate nodes, verifying and adding transactions to their replica of the ledger. These nodes maintain the consistency of their replica of the ledger and must be trusted by all other nodes. The requirement to trust an intermediate node, a verifier, is the key distinction between a permissioned network and a fully distributed, unpermissioned network, where there are no privileged nodes with the responsibility of approving transactions. We will come back to trust in the next section.
De-centralized network designs have the advantage of higher throughput, since large resource investments can be made on a limited number of special nodes. The rest of the network nodes do not need to address and exchange data directly with each other, but only exchange data through specific, trusted nodes.
Needless to say, the original cryptocurrency users did not think much of the massive effort by software industry leaders in permissioned networks.
A real distinction?
As we mentioned, Bitcoin started as a distributed network but, because of the appeal of the reward created by its leader-based consensus mechanism, it now relies on a set of miner nodes.
Because of the high cost in electrical power required to run mining processors, many successful Bitcoin clones have adopted, or are migrating to, less costly leader-based consensus mechanisms, such as Proof of Stake, Proof of Authority, Proof of Capacity, etc.
However, while the Proof of Work mechanism was originally designed to achieve equal probability for every node to gain the reward, leader-based mechanisms today are not as democratic.
In essence, Proof of "something" mechanisms require that some uncommon property be proven before the node acquires the right to participate in rewards.
In Bitcoin, that "something" was the ability to perform computational tasks, to prove in real time that the node ran on a real computer and not on a simulated or virtual one.
For networks adopting "Proof of Stake", that "something" means proving the ownership of a large amount of the network's currency.
In all cases, only a limited number of nodes are accredited and trusted as verifiers.
In unpermissioned networks, the tendency towards centralization causes a continuous drop in the number of verifier nodes.
When the number of verifier nodes becomes small, it would be much easier for an attacker to take over the network, thus verifier nodes must be trustworthy. The distinction between unpermissioned, leader-based consensus networks and permissioned networks is therefore fading.
No distributed consensus mechanism has been implemented yet that resists the trend towards centralization.
This is not just an academic or philosophical discussion. Ethereum, after its success as an unpermissioned network used for the development of tokens, is moving towards a Proof of Stake design, with a limited number of verifier nodes. Several newer clones of Ethereum, such as Tezos, EOS and TELOS describe themselves euphemistically as "substantially decentralized".
Other networks, such as Ripple and Stellar, are popular because of their speed, even if they are the product of permissioned designs.
Has the original goal of Bitcoin has been abandoned? Do all current crypto-networks need intermediate nodes to verify end-user transactions and add blocks to the blockchain?
Furthermore, is there a solution to cost and limitations of the original networks? Those networks that claim to have fixed such problems are creating complex solutions at higher layers.
Continuing research
As I mentioned, blockchain research is continuing. The goal is still the same: to provide people with the ability to trade and exchange data directly without having to trust an intermediate entity.
When exploring the idea of fully distributed crypto-networks without intermediate nodes the following questions arise:
  • Is it possible to eliminate miners/verifiers, eliminate their rewards and fees, and still ensure the integrity of transactions?
  • How can such a network protect itself from majority, Sybil and DoS attacks?
  • Is it possible to eliminate the network tendency towards centralization?
  • Is it possible to completely abandon the idea of leader-based protocols and achieve majority agreement without ever broadcasting blocks?
  • Could such a leaderless network securely guarantee a correctly replicated blockchain on every node?
  • Could a mobile phone act as a node of this type of crypto-network?
  • Can the blockchain be stored on a mobile or wearable device?
  • Can a mobile device participating as a network node keep up with the traffic generated by all the transactions in the network?
  • Can user wallets be secured when the nodes where wallets are stored are all verifiers?
Stochastic, fully distributed networks
The vision of a fully distributed crypto-network with no special intermediate nodes and not owned by any entity is much closer than you may think. All of the above questions happen to have a positive answer when the crypto-network is based on stochastic logical environs.
The research work on distributed stochastic crypto-networks started in 2016. A new truly distributed consensus agreement has been developed, which is called the Majority Agreement Recursive Protocol based on Logical Environs (MARPLE).
Each node can find agreement with a random set of physically remote but logically connected nodes (environs). These are dynamically and continuously re-configuring. The nodes in these environs recursively and synchronously share their current block outline by using very short hash packets. When disagreements occur, they can resolve them without broadcasting to the whole network.
Because the size of each node's environs is small and does not depend on the size of the network, stochastic distributed crypto-networks are scalable and can handle a much higher volume of transactions.
The stochastic crypto-network design can guarantee application data integrity, as the consensus is reached synchronously for each block and forks disappear.
The costs associated with mining and verifying (rewards and fees) also disappear.
As an incentive to become a node of the network, users can issue free financial transactions, receive a secure wallet acting as an interest-bearing savings account, and may run highly scalable blockchain applications on their device.
At least one stochastic unpermissioned network (GNodes by Gorbyte) plans to be operational by the end of 2019 with:
  • a fully functional downloadable client code on desktops, laptops or mobile phones
  • a replica of blockchain on each and every node
  • high performance and scalability, as part of a truly distributed, unpermissioned network
  • guaranteed blockchain integrity, network security and transaction verification
  • zero network operation cost, providing no-fee financial transactions
  • a rebased, non volatile currency for practical utility
  • a distributed operating environment for scalable blockchain applications

Stochastic, fully-distributed crypto-networks will soon revitalize the blockchain industry, disrupt crypto-mining industries, reduce energy utilization, provide an alternative to current crypto-networks and effectively revolutionize the distributed application world.
Giuseppe Gori is the CEO of Gorbyte ( The company is currently raising private funds through a security token offering and will raise public funds in an STO early next year in partnership with DealBox (Carlsbad, CA, USA) and TokenIQ (Scottsdale, AZ). The funds are being used for the development of GNodes, Gorbyte's vision for a stochastic, fully distributed network featuring no-fee basic transactions with a non-volatile currency.

Sunday, June 24, 2018

New-Gen Crypto-Networks: What Can We Achieve?

Current crypto-networks are plagued with limitations, high costs and lack of functionality. New generation crypto-networks will fix those problems and provide users with the services, security and convenience expected from the blockchain technology.
The following diagrams are only part of the story, but address the specific problems of today’s crypto-networks.
  • The first diagram shows how current crypto-networks are constrained in solving their current limitations: Scalability, throughput, high cost of network operation, blockchain space limitations, volatility of prices in their currency, hard forks, lack of security of user keys, lack of user identification, etc.
  • The second diagram shows how new generation crypto-networks may solve those limitations.
  • The third diagrams is an overlap the previous two, to highlight the differences.
LEGEND: See bottom-right of each diagram.
  • The objectives and requirements are in the ellipses at the top.
  • The basic functions are the dark rectangles.

Current Crypto-networks Functional Diagram:

New-gen Crypto-networks Functional diagram:

Composite Dependencies Diagram:

Friday, May 11, 2018

How the Blockchain Can Ensure Virus-free Devices

One of the advantages of the blockchain concept is the capability to register objects on the blockchain, through smart contracts on Ethereum, or entity registration objects on Gorbyte.
Such ability allows for a novel approach to guarantee a virus-free, malware-free software environment on a user device running blockchain applications.
The objects or entities we are talking about can be software programs, or applications, or components of applications, or parts of an operating system environment.
These software entities can be registered and signed on the blockchain by the company that developed the software using a unique identifier. Known companies, who have a reputation to defend, would guarantee that their software registered on the blockchain is virus-free, just as currently happens when we buy and download a software application from a reputable source.
In addition to the unique identifier, and the developing company’s signature, these entities will also contain a hash of the object code.
This hash can then be used to verify a software component loaded in the memory of a device. The hash in memory can be checked against the hash registered on the blockchain for that component.
Because we can trust the blockchain as being secure, and unchangeable, we can then guarantee a virus-free environment on a device using a new approach: We can check for the integrity of the software components running on the device, instead of using the classic anti-virus approach of testing for every possible virus that can penetrate the device. Our object code integrity checker (OCIC) would be faster and require only information about the software we intend to run.
More importantly, the classic anti-virus approach requires a database of virus signatures and can never guarantee that all possible viruses signatures are included in the database.
Our approach instead would guarantee a virus-free environment, at least with the same level of confidence as we trust the original companies we buy our system and applications from.
The conditions for this approach to work are:
  • Software development companies must develop a version of their software for the specific operating system of the target blockchain devices;
  • Software development companies must register and sign their software on the blockchain, providing the hash of the object code for their software module;
  • The target device must include specific firmware and run software, including the OCIC, designed specifically for the device;
  • The target device must run the client code and be a full node of the crypto-network sustaining the blockchain.
Implementation Details
If our system contained a virus, our OCIC code itself could be compromised.
How can our code integrity checker itself run securely in a hostile environment, such as an operating environment of a generic device? How can we make sure that a virus cannot infiltrate the system even before the OCIC code is loaded? How can we make sure that an attacker will not change our loading tables, the OCIC relies on?
The blockchain comes again to our help, when our device is a node of the crypto-network (i.e.: it contains a blockchain replica).
Gorbyte, for example, will release wearable devices that will participate in sustaining a blockchain replica on every user device.
In this case, our OCIC can rely on registration object information because this information is in the device itself as part of the device’s verifiable blockchain replica, before any communication with the outside world is initiated.
Having a positive and secure way to test the integrity of software components, we can apply the test to every component in the system from the time the device is switched on. Note that the blockchain itself, up to the last verified block, has a unique verifiable hash, just like any registered component.
When a device is switched on, the first running code is a bootstrap loader in firmware. This firmware loader can do a first verification of the initial software components when it loads them in memory. It will include a small loading table in firmware with the unique version numbers and hashes of the initial software components, namely:
  • A software bootstrap loader, taking over the bootstrap loading procedure from the firmware loader.
  • The last verified version of the component loading table (saved in storage before the device was switched off), or an initial registered software loading table provided by the device manufacturer, when the device is new.
  • Our Object Code Integrity Checker (OCIC).
The software bootstrap loader will then take over, using the verified loading table. It will load each of the following modules, and run our OCIC to verify them:
  • The required basic communication modules (e.g., for Wi-Fi and internet access).
  • The blockchain, up to the block before the device was previously switched off, or the address of the reliable source of the blockchain genesis block, when the device is new.
  • The client code of the crypto-network (e.g., Ethereum or Gorbyte), or the address of a reliable source where to find this code, when the device is new.
From then on, any new component needed in the system can be verified by OCIC at the time the new component is first loaded.
Our device will then go through the normal initialization procedures: loading and initializing system components, requesting the blocks it is missing on its blockchain replica, etc. until the desired running environment is established.
At this point, only trusted verified software will run in our system (RAM).
This does not exclude that malware software could find its way into the device storage, but it would be discovered and prevented from being loaded in RAM by the (verified) loader.
No other loader can be used, to load software in RAM.
For further insurance, our OCIC could remain running in the background, verifying the loaded components at regular intervals, to guarantee that all the components running in the system have not changed due to unpredictable events. At the same time it can also scan the device storage to detect and flag any object code that is not in the loading table.

Friday, January 5, 2018

Blockchain: What Are the Fundamentals?

I enjoyed reading the article: “2018's Resolution? Revisit Blockchain's Fundamentals” by William Mougayar on Coindesk.
The author warns us that when a new technology comes along, we are often too eager to quickly implement some of the pieces we need, without a vision and an understanding of the full potential of the technology.
We have seen this happen in part with the Internet. It was quickly adopted, even though many designers at the time could already see the lack of those security features that had to be added almost as an afterthought. The whole world still suffers the consequences of the lack of a well designed security architecture for the Internet.
We are now facing similar design choices with the blockchain technology.
As a coach warning us to “stick to the fundamentals”, the author lists some of what he considers the blockchain fundamental innovations, or “fundamental outcomes”.
But are we sure we understand what the blockchain fundamental blocks are?
For example, the first fundamental in his list is “replacing intermediaries”. This objective is definitely important, for applications running on unpermissioned (or public) crypto-networks.
I agree with the author. But the designers and investors of Ripple and Hypercom could argue otherwise. It depends on what the target applications are.
We do not really know what problems future applications will need to solve.
Looking at the following “fundamentals” in the author’s list, his suggestions seem to be somehow limited to the current state of the art.
By looking at what we currently understand as innovations, we risk, as the author says “copying what we already see instead of inventing what we don’t discern yet”, that is, we may miss the full potential of blockchain technology.
For example, we cannot limit our thinking to today’s smart contracts running on today’s crypto-networks as the only engine to run blockchain applications.
If we do so, we may miss 97% of future general distributed applications that will use the blockchain, but will run on different engines, off-the-blockchain.
If we want to create an environment able to support the distributed application of the future, without knowing what they will be, we may need not just a better engine, but a multitude of better engines.
The ability for general distributed applications to use the blockchain functionality without having to run a smart contract on-the-blockchain is a top requirement on my list.
Millions of concurrent distributed applications will need to process and securely exchange many terabytes of information per second among identifiable, unique parties.
Current crypto-networks do not begin to solve the problem. Public crypto-networks do not even contemplate the problem of identifying who the users are: people, IoT objects, vehicles, autonomous robots or something else.
We could describe many characteristics of the blockchain and things that we will be able to do using the blockchain, but we would never finish: any imaginable distributed application should be able to use the blockchain, just as today any App on a cell phone can use the cell phone communication ability.
So what are the fundamentals?
Is the ability of the blockchain to support communication between a person and IoT objects a fundamental?
Is the ability of the blockchain to support Virtual Private Blockchains a fundamental?
Is the ability for autonomous robots to trade assets using their personal accounts a fundamental?
The fundamentals are not what future blockchain applications will do, but what these applications will not do.
We can use the following analogy: An iOS allows the development of Apps without these having to solve the problems of memory management, or using storage commitment techniques, or even be dependent on the CPU instruction set.
In a similar way, a Distributed Operating Environment (DOE) for the blockchain will allow the development of General Distributed Applications (GApps) without these having to solve the basic problems of communication, addressability and unique identification, replication of data, and security.
These seem to be the main requiements of any distributed application. How much easier would it be, for example, to design an airline reservation system if the DOE already solved for us the problems of system security, verification of the passenger identity, and ticket purchase transaction? How faster would the check-in and boarding processes be for the public?
The blockchain technology has been rightfully compared to the introduction of communication technology. Mostly this is because they complement each other.
With the Internet we have solved the problem of communication among any two parties. Now, with first-generation crypto-networks, how close are we to a DOE for general distributed applications?
Which fundamental blocks are still missing?

Our efforts should concentrate in establishing at least these fundamental blocks by developing second-generation crypto-networks, that will create a DOE for future distributed applications.
The longer term goal for application designers is to solve any OTHER imaginable problem, easily and transparently.
A DOE that proves those fundamental blocks will truly add value to what started as a distributed ledger for financial transactions.
Future generation crypto-networks will go even further in doing what future applications will not need to do.

Giuseppe Gori is the designer and CEO of Gorbyte, a new-generation crypto-network that uses a cooperative consensus mechanism replacing miners/verifiers. He has over thirty years experience in the design and development of computer networks.