Guest blog by Mance Harmon, Co-founder and CEO, Swirlds
Marc Andreessen, an early Internet pioneer (co-founder of Netscape in the 1990s) and the co-founder of perhaps the premier tech VC fund in the world sees three major waves of technology over the past 40 years: 1) personal computers in 1975, 2) the Internet in 1993, and 3) distributed ledger technology (DLT), which gained prominence in 2014.1 More than $1.1B of venture capital was invested in DLT-related startups by May of 2016. This is on par with investment made in the Internet in the mid 1990s.2
What is it about distributed ledgers that has convinced so many that a fundamental shift in computing paradigms is taking place? It's actually pretty simple. For networked applications, distributed ledger technology (appropriately applied) practically eliminates entire categories of security attacks. What are these categories?
- Changing history (Immutability)
Attackers can't easily modify the contents of the distributed ledger (i.e., application database)
- Disruption (Denial of Service)
Attackers can't easily disrupt the flow of transactions to the intended recipients. This results in higher availability.
- Influencing transaction order (Fairness of transaction order)
Attackers can't unfairly influence the community's agreed ordering of transactions as created by the application users
The fairness property makes it possible to develop distributed applications in which members are competing to have their transactions recorded first. Examples include stock markets (fair matching of buyers / sellers), auctions (eBay), collaboration apps (Dropbox, Google Docs, Slack), registration (patent office, domain name registration), games (Minecraft, World of Warcraft, Second Life), and time-limited business transactions.
Today software is normally hosted on servers, and the servers are centrally managed by individuals or organizations. We trust those organizations to prevent the attacks listed above. For example, we trust Apple and Google to ensure the privacy, integrity and availability of the information we store in Apple iCloud and Google Drive. We trust Bank of America and Citibank to ensure the accuracy and security of the software that calculates account balances. And we trust the NYSE and NASDAQ to ensure fairness in arbitrating the order of stock trades in those markets.
DLT makes networked applications more secure by preventing individuals (or even small groups of individuals) from successfully carrying out these attacks. DLT makes it impossible for the hosting organization to unilaterally change the transaction history, disrupt the flow of transactions, or unfairly influence the final order of the application transactions. More importantly, even if an attacker successfully breaches the security infrastructure of the application host, the attacker will still be prevented from successfully executing the attacks. In this sense, users of distributed applications are no longer required to trust that the application host will protect them. Individual Trust is replaced with Community Trust. When using DLT, each community member (peer) maintains a local copy of the ledger. A successful attack requires that at least one third of the peers collude to perform the attack. This raises the complexity and cost to any would-be attackers, which is the value of DLT.
Distributed Ledger Technologies Are Not Created Equal
A distributed ledger can be implemented using an algorithm from one of several categories of distributed consensus technologies. However, not all algorithms protect equally against the attacks listed above. What's more, some algorithms are less cost effective while others have bandwidth and latency limitations.
For completeness, the use of a central server can be considered one of the distributed consensus technology categories. The server operator is trusted to ensure: 1) high availability of server resources, 2) integrity of the database, and 3) that the server operator treats all users fairly with respect to the inclusion and ordering of transactions. If the server operator is corrupt or compromised, users of the server may be damaged.
Leader-based systems (e.g., Paxos, RAFT, PBFT, RBFT, etc.) were originally designed for replicated databases managed by a single organization, not for use by a set of untrusted and potentially unknown peers. These systems choose a leader from the set of network peers. All peers send transactions to the leader, and the leader distributes the transactions received to all peers. Leader-based systems are susceptible to DoS attacks. Because there's a single leader, it's easier for an attacker to perform a Denial of Service attack on the leader, disrupting the flow of transactions. Also, leaders can unfairly influence the consensus order of transactions. One might think that having backup leaders can help with DoS and fairness of ordering, but this is not the case. For DoS, the attacker attacks the main leader, and when people switch to the new leader, the attacker then targets the new leader. For fairness, simply using multiple leaders (with responsibility for ensuring the active leader doesn't influence the order) won't work because transactions flowing from the peers will potentially reach each redundant leader at a different time and in a different order. The leader can falsely claim to have received the transactions in a certain order, and no backup leader can prove they're wrong.
When used in permissioned networks (networks where all peers are known and trusted), the parts of the blockchain algorithm that require expensive mathematical operations, known as Proof-of-Work (PoW), are replaced with simpler, but less secure alternatives. Non-PoW blockchain algorithms often have a leader in a way that's similar to leader-based algorithms. As a result, non-PoW blockchain is susceptible to DoS attacks. Also, the peer that publishes the block of transactions may choose to manipulate the transactions to unfair advantage by refusing to include transactions in a given block or by choosing a particular order of transactions within the block.
In open networks (networks where anyone may participate as a peer without restriction and peers are both untrusted and potentially unknown), blockchain uses Proof-of-Work that mitigates the susceptibility to DoS attacks, but results in a high cost per transaction. Also, it is still the case that the peer that publishes a block of transactions can reorder or fail to include certain transactions in the block creating an unfair advantage.
Voting-based systems historically are used for enabling a community to decide on a yes / no question. They accomplish this by multiple voting rounds, and in each round every peer has to send a vote to all other peers. Voting systems have been around for decades, and few in the industry use them because of their gross inefficiencies in bandwidth and latency. If we want to find a total order on the transactions (not just a yes / no answer for a pair of transactions, but a full ordering of all transactions), the inefficiencies are much worse. These systems are not completely fair in their ordering of transactions, and as the systems are optimized to be more efficient, they become even less fair. There's an inevitable trade-off between fairness and efficiency in voting-based algorithms.
The hashgraph algorithm provides the upsides of the other algorithm categories with none of the downsides. The hashgraph algorithm is nearly optimal in bandwidth efficiency. At no time is there a leader when using the hashgraph algorithm. Also, the mathematics of hashgraph don't require the use of expensive Proof-of-Work to ensure security when the peers are unknown and untrusted. As a result, hashgraph provides a better trust model that scales and is low cost. And at no time can the order of transactions be influenced to unfair advantage. In other words, hashgraph provides a combination of high performance, scalability, security and fairness that the other algorithms can't achieve.
The following chart summarizes the categories of distributed consensus algorithms based on the attacks they mitigate:
In other words, when using an application hosted on a central server, users must extend Individual Trust to the server operator and EVERY network participant to refrain from attempting an attack. Leader-based, blockchain, and voting-based systems have split trust models providing community trust for some of the attacks and individual trust for other categories of attacks. If using applications built on top of the hashgraph algorithm, users are no longer required to trust that individuals won't perform an attack. The hashgraph algorithm makes it impossible for individuals to successfully execute attacks. Rather, users must extend Community Trust, trusting that no large group of users are colluding to perform one of the attacks.
Hashgraph Offers the Best of All Worlds
In terms of security, hashgraph is the only algorithm that directly ensures immutability of the ledger, protects against denial of service attacks, and ensures the fair ordering of transactions. In terms of performance, hashgraph is near optimal in bandwidth efficiency, and within seconds of submitting a transaction to the network, users can be 100% certain that the order of transactions will not change. In contrast, blockchain with proof-of-work can require more than an hour to provide users with high assurance that the order of transactions will not change, and it never achieves 100% certainty.
In short, hashgraph provides a better set of security properties than those found in the public networks that use proof-of-work (i.e., Bitcoin, Ethereum, etc.), and better performance characteristics than those provided by leader-based and voting-based systems in private, permissioned networks. Hashgraph combines the best of both, and then raises the bar again by uniquely ensuring fairness in the ordering of transactions.
To learn more about leveraging a next-gen hashgraph distributed consensus algorithm to enable fine-grain session management, download the white paper Distributed Session Management: Beyond the Firewall.