Introducing Ako — a Hashgraph Based Consensus Engine for Ethereum Virtual Machine
We recommend reading our previous blog post Solidity based Smart Contracts Blockchains in Fulcrum ecosystem for an overview first — here.
This blog post details Ako one of the consensus algorithms used in our permissioned implementation of Ethereum blockchain.
Ako is a software component that allows many computers to behave as one; a technique known as state machine replication. This can be useful to augment the fault tolerance of a service. It also empowers applications to embrace a fully distributed architecture where computation is no longer carried on a single, centralized, server.
Ako is designed to easily plug into applications written in any programming language. Developers can focus on building the application logic and simply integrate with Ako to handle the replication aspect. Basically, Ako will connect to other Ako nodes and guarantee that everyone processes the same commands in the same order. To do this, it uses Peer to Peer (P2P) networking and a Byzantine Fault Tolerant (BFT) consensus algorithm which brings together many appealing properties, like speed, asyncronisity and leaderlessness, of which other algorithms only implement subsets.
Consensus Algorithm and Blockchain
We use the Hashgraph consensus algorithm, invented by Leemon Baird. It is best described in the white-paper and its accompanying document. While the algorithm is protected by patents in the USA, enterprise companies can either apply for a license with the Hashgraph Foundation or can use some of our blockchain tools developed on the Hedera Platform.
Hashgraph is based on the intuitive idea that gossiping about gossip itself yields enough information to compute a consensus ordering of events. It attains the theoretical limit of tolerating up to one-third of faulty nodes without compromising on speed. For those familiar with the jargon, it is a leaderless, asynchronous BFT consensus algorithm.
Ako projects the output of the consensus algorithm onto a linear blockchain which is more suitable for representing an ordered list of transactions and facilitates the creation of light-clients.
Ako is designed to integrate with applications written in any programming language.
Almost any software application can be modelled in terms of a service and a state. The service is responsible for processing commands (ex. user input), while the state is responsible for manipulating and storing the data (eg. database). Usually, when commands require updating the data, the service will invoke the state directly. In a distributed application, however, commands (referred to as transactions in this context), must be broadcasted to all replicas and put in a common order before being applied to the state. This is what ensures that all replicas process the same commands in the same order. Hence, the serviceno longer communicates directly with the state (except for read-only requests), but forwards commands to a transaction ordering system which takes care of broadcasting and ordering the transactions across all replicas before feeding them back to the application’s state.
Ako is an ordering system that plugs into any application thanks to a very simple JSON-RPC interface over TCP. It uses a consensus algorithm, to replicate and order the transactions, and a blockchain to represent the resulting list. A blockchain is a linear data structure composed of batches of transactions, hashed and signed together, easily allowing to verify any transaction. So, instead of applying commands directly to the state, Ako applications must forward the commands to Ako and let them be processed asynchronously by the consensus system before receiving them back, in blocks, ready to be applied to the state.
As Dr. Leemon Baird describes in Overview of Swirlds Hashgraph, “the Hashgraph data structure and Swirlds consensus algorithm provide a new platform for distributed consensus.” Hashgraph offers a number of technological benefits over traditional blockchain technology. Due to material data structuring differences, Hashgraph ensures that no individual can manipulate the order of transactions; no individual can stop or delay a transaction; and transaction speeds are significantly faster. Hashgraph is Asynchronous Byzantine Fault Tolerant and Atomicity, Consistency, Isolation, Durability (ACID) compliant. Podify is thrilled to be one of the first companies to develop on Hashgraph-based platform.
What is Hedera?
Hedera is both an organisation and distributed ledge platform that resolves the factors that constrain the adoption of public DLT by the mainstream.
What is hashgraph
The hashgraph data structure and consensus algorithm provides a new platform for distributed consensus. This introduction gives an overview how hashgraph works, and of some of its properties. The goal of a distributed consensus algorithm is to allow a community of users to come to an agreement on the order in which some of them generated transactions, when no single member is trusted by everyone. In this way, it is a system for generating trust, when individuals do not already trust each other. Hashgraph achieves this in a fundamentally new way
A blockchain is like a tree that is continuously pruned as it grows — this pruning is necessary to keep the branches from growing out of control. In hashgraph, rather than pruning new growth, it is woven back into the body.
In both blockchain and hashgraph, any member can create a transaction, which will eventually be put into a container (the “block”), and will then spread throughout the community. In blockchain, those containers are intended to form a single, long chain. If two miners create two blocks at the same time, the community will eventually choose one to continue, and discard the other one. It’s like a growing tree that is constantly having all but one of its branches chopped off.
In hashgraph, every container is used, and none are discarded. All the branches continue to exist forever, and eventually grow back together into a single whole. This is more efficient.
Furthermore, blockchain fails if the new containers arrive too quickly, because new branches sprout faster than they can be pruned. That is why blockchain needs proof-of-work or some other mechanism to artificially slow down the growth. In hashgraph, nothing is thrown away. There is no harm in the structure growing quickly. Every member can create transactions and containers whenever they want. So it is very simple, and tends to be very fast.
Finally, because the hashgraph doesn’t require pruning and therefore is simpler, it allows more powerful mathematical guarantees, such as Byzantine agreement and fairness. Distributed databases such as Paxos are Byzantine, but not fair. Blockchain is neither Byzantine nor fair. Hashgraph is both Byzantine and fair. The hashgraph algorithm accomplishes being fair, fast, Byzantine, ACID compliant, efficient, inexpensive, timestamped, and DoS resistant.
The hashgraph is inexpensive, in the sense of avoiding proof-of-work. Individuals and organizations running hashgraph nodes do not need to purchase expensive custom mining rigs. Instead, they can run readily available, cost-effective hardware. The hashgraph is 100% efficient, wasting no resources on computations that slow it down.
The hashgraph is 100% efficient, as that term is used in the blockchain community. In blockchain, work is sometimes wasted mining a block that later is considered stale and is discarded by the community. In hashgraph, the equivalent of a “block” never becomes stale. Hashgraph is also efficient in its use of bandwidth. Whatever is the amount of bandwidth required merely to inform all the nodes of a given transaction (even without achieving consensus on a timestamp for that transaction), hashgraph adds only a very small overhead beyond that absolute minimum. Additionally, hashgraph’s voting algorithm does not require any additional messages be sent in order for nodes to vote (or those votes to be counted) beyond those messages by which the community learned of the transaction itself.
The hashgraph is fast. It is limited only by the bandwidth. If each member has enough bandwidth to download and upload a given number of transactions per second, the system as a whole can handle close to that many. Even a fast home internet connection could be fast enough to handle all of the transactions of the entire VISA card network, worldwide.
All communications are encrypted with TLS 1.2, all events are digitally signed, and the hashgraph is constructed using cryptographic hashes. All the algorithms and key sizes were chosen to be compliant with the CNSA Suite security standard.
ASYNCHRONOUS BYZANTINE FAULT TOLERANCE
The hashgraph is asynchronous Byzantine Fault Tolerant. This is a technical term meaning that no single member (or small group of members) can prevent the community from reaching a consensus. Nor can they change the consensus once it has been reached. Each member will eventually reach a point where they know for sure that they have reached consensus.
Blockchain does not have a guarantee of Byzantine agreement, because a member never reaches certainty that agreement has been achieved (there’s just a probability that rises over time). Blockchain is also non-Byzantine because it doesn’t automatically deal with network partitions. If a group of miners is isolated from the rest of the internet, that can allow multiple chains to grow, which conflict with each other on the order of transactions.
It is worth noting that the term “Byzantine Fault Tolerant” (BFT) is sometimes used in a weaker sense by other consensus algorithms. But here, it is used in its original, stronger sense that (1) every member eventually knows consensus has been reached, (2) attackers may collude, and (3) attackers even control the internet itself (with some limits). Hashgraph is Byzantine, even by this stronger definition.
There are different degrees of BFT, depending on the assumptions made about the network and transmission of messages.
The strongest form of BFT is asynchronous BFT- meaning that it can achieve consensus even if malicious actors are able to control the network and delete or slow down messages of their choosing. The only assumptions made are that more than ⅔ are following the protocol correctly, and that if messages are repeatedly sent from one node to another over the internet, eventually one will get through, and then eventually another will, and so on. Some systems are partially asynchronous, which are secure only if the attackers do not have too much power and do not manipulate the timing of messages too much. For instance, a partially asynchronous system could prove Byzantine under the assumption that messages get passed over the internet in ten seconds. This assumption ignores the reality of botnets, Distributed Denial of Service attacks, and malicious firewalls.
Fair Access and Fair Ordering
Many applications require that the consensus order of transactions match the actual order in which the transactions are received by the network. It should not be possible for a single party to prevent the flow of transactions into the network, nor influence the order of transactions in the eventual community consensus. A fair consensus algorithm ensures that if a user can submit a transaction to the network at all, then the transaction will be received by the network and the order in which it was received will be a fair ordering. Hashgraph uniquely ensures that the actual order transactions are received by the community will be reflected in the consensus order. In other words, hashgraph ensures both Fair Access and Fair Ordering.