Scaling cryptocurrencies: Holo(chain)

David Meister
Holochain
Published in
7 min readMar 19, 2018

Disclaimer: This information is based on my own research and I make no guarantees about the correctness or fit for any particular use. Let me know in the comments if you have something constructive to add, but don’t freak out, OK?😉

The goal of bringing basic, decentralised payments to the masses remains outstanding due to Hard scaling problems. These problems are rooted in the mechanics of consensus algorithms and fundamental limits in our ability to shuttle data around a global network.

Visa is frequently referenced as the “gold standard” in scalability discussions for cryptocurrencies. The Visa network processes 150 million transactions per day — the best blockchains process around 1.5 million transactions per day.

The fundamental limit for every blockchain is:

TPS = Transactions per block / seconds per block

Increasing the transactions per block or producing more blocks makes it harder for the network to share all the relevant data globally. We must always tradeoff throughput against reliability.

Today I’m going to briefly discuss Holo(chain). I recently managed to score some 1:1 time with Arthur “Art” Brock (Holochain co-founder) while he was in Melbourne — here’s a summary of what I learned from Art, his team, and the Holo(chain) white papers.

Holo(chain)

Holochain is a novel approach to distributed ledgers that makes big tradeoffs to achieve effectively infinite scale and general-purpose decentralised compute.

Holo is the first application intended for mainstream use on Holochain.

No consensus

Like DAGs, Holochain has abandoned the blockchain, but goes a (huge) step further by abandoning consensus entirely.

The Cardano team define consensus for distributed ledgers as:

  • Stability: Everyone involved globally agrees on some historical information that is guaranteed to never change
  • Liveness: Anyone can broadcast new, valid information over a network and be guaranteed it will eventually become stable

To transform new information from “live” to “stable” reliably we need some algorithm highly resistant to manipulation and denial of service attacks. Blockchains are a great example of such an algorithm, for which Bitcoin (and friends) are the “killer apps”.

The Holochain team claim that consensus algorithms directly cause severe problems at global scale:

  • Stability creates ongoing storage costs as all data must be copied to many computers and stored forever
  • Liveness creates network costs and high latencies compared to as all data must be synced globally and funnelled through the consensus process
  • The “everyone” in stability and “anyone” in liveness make certain attacks on an anonymous network extremely difficult to mitigate

The Holochain team calls the established paradigm “data centric” thinking and is actively working on bringing their “agent centric” alternative to the mainstream.

Agent centricity

In an “agent centric” system, there is no global consensus of historical data, so no stability or liveness. Everyone (the agents) maintain their own local data and view of the world. Some data is broadcast publicly and some is private. Different agents see and work with different data at any point in time. Anyone can request any public data from the network, but nobody stores and verifies all the data all the time.

Every public transaction (white) must be signed by two parties. Private data (grey) is not countersigned.

Every transaction between multiple users is cryptographically signed and verified by everyone involved in the transaction — both agents signing a transaction agree on relevant aspects of their world views at that exact point in time. The logic follows that if everyone verifies their own data, and all data they’ve shared with someone else, then by extension all data in the network is verified by someone.

What if user B colluded with A to create a fake transaction? Honest users C and D don’t interact with or countersign this fraudulent data and so should not trust A’s transaction history. How do we alert them?

This breaks down when someone carefully constructs a blind spot in the network of honest users to gift themselves large sums using invalid, and unverified transactions. To combat this, only public data can be used in transactions between users and public data is forcibly, randomly and redundantly verified by the network. If even one honest user detects an invalid transaction a digital alarm is broadcast to the entire network for further investigation.

User A manages to hide one of the two copies of the fraudulent transaction. The other is assigned to C, an honest user, so the attack is discovered and the network alerted. A redundancy of two is a nice example but risky in real-world scenarios. Security increases rapidly with the redundancy factor and honest network size.

This still looks a lot like blockchain — public transactions redundantly verified on a decentralised network…

There are some key differences in Holochain:

  • Holochain’s “agent centric” philosophy means that identifying and tracking agents is as important as identifying and tracking data in a “data centric” system so anonymity, or even pseudonymity, is counterproductive
  • Holochain has a concept called “apps” that define dedicated, but interconnected (via. RPC) networks of decentralised ledgers and smart contracts
  • The level of storage and verification redundancy for public data is configurable for each app
  • There is access control at the app level via encryption so sensitive apps/networks can be “invite only”. RPC calls allow sensitive apps to interact selectively with less sensitive apps (e.g. anonymised reporting)

The removal of anonymity and addition of access controls to apps opens new options for preventing and dealing with spammers, fraudsters and sybil attacks.

App developers are given a dedicated network with its own rules and users per app. Developers choose their own security and scalability tradeoffs to meet their needs. Actually, every version of every app is given its own dedicated network so these tradeoffs can be tweaked over time (e.g. ramp up scalability as an app becomes popular), with users opting in to newer versions as they become available.

To keep users of an app up to date, Holochain provides the ability to copy/migrate data forward to new versions. Effectively every “new version” of an app is a “hard fork” so governance options are provided by the protocol itself to keep these forks as painless as possible (no “bitcoin X” dramas). These options range from simply letting the original app developers decide through to democratic voting systems for users.

The maximum security configuration for any app (full replication of all data to all users) is equivalent to blockchain level security (and scalability). Modest security concessions offer dramatic scalability improvements in large network. “Good enough” security enables high volume micro-payments that have been elusive on the blockchain (this is critical for Holo, see below).

Scalability

Storage and transaction verification is achieved through custom DHTs, the same basic tech behind Bittorrent, which speeds up as more users join the network (e.g. when more people seed a torrent it downloads faster).

Apps on Holochain are written in JavaScript (ES5 & ES6) or a clojuresque LISP with more language support planned. Apps run independently on each users’ computer, avoiding most scalability and performance concerns. Apps use a core API to transact with other users and broadcast public data. Dishonest users can trash their own data, but as soon as garbage (defined by the app) is broadcast to the network, honest users will simply flag and reject it.

If you want something to scale, design it like this…

Apps themselves are distributed in an “app store” app by publishing their codebase to the DHT of the app store app. Individuals and organisations can then create private app stores by renaming and reconfiguring the official app store (which gives it a new hash and dedicated network/DHT), then inviting users. It’s turtles all the way down as far as distribution goes…

Art emphasised repeatedly to me that it’s best to treat Holochain apps as decentralised micro-services, not monolithic applications. GUIs are built with standard tech, e.g. web-apps making REST calls to Holochain apps. A single GUI can support multiple compatible backing apps/networks.

By comparison, smart contracts on blockchains (e.g. Ethereum, EOS) are run redundantly by block producers and data verifiers, forcing app developers to compete on an open “gas” market for scarce compute resources. It’s impossible in general to predict the difficulty of a computation before it finishes, and impossible to predict the market price of gas — absolute dealbreakers for general-purpose on-chain computation.

Holo

Holo is selling (crowd funding) preconfigured web-hosting hardware to provide decentralised infrastructure for their upcoming alternative to Amazon AWS et al. ICO to allow users to pay for said hosting “coming soon”.

Holo is not Holochain.

Holo is simply the first app built on Holochain intended for large-scale use.

Holochain exists but Holo is still crowdfunding servers and preparing an ICO.

Holo aims to implement web hosting on Holochain. When users view a website it will be served by an available host, who receives a tiny payment for the service of delivering that page. No blockchain could track every website view globally on-chain, whereas individual web hosts can easily co-sign their own logs with visitors — Holo should be a great proof of concept for the Holochain model.

Holo is like Bittorrent + websites + micro-payments for seeders/hosts.

Fair warning for ICO speculators, Holo fuel is designed to be speculation resistant. After an initial growth period the supply of Holo fuel should fluctuate dynamically to offset network supply/demand to keep fuel prices stable.

Summary

To achieve extreme scale Holochain gives up anonymity/pseudonymity and global consensus on shared data structures.

Holochain treats data integrity implicitly as emergent behaviour of app/network rules rather than explicit guarantees enforced at the user level.

Every Holochain app is equipped with its own data and network and anonymity/consensus parameters can be tweaked (via. a YAML/JSON file and simple callback functions) to slide the network along the security/scalability axis. Ongoing research by the Holochain team provides formal mathematical clarity around what impact each of these parameters have over the network.

Holochain is the only distributed ledger technology I have seen so far with a believable model for large scale, decentralised general-purpose computation on top of that ledger.

--

--