Hashgraph has been getting some press and many are excited about the speeds they promise and some of the videos and demonstrations they’ve shared. It is one of the closest innovations to Holochain that I’ve seen come out by people starting from a blockchain mindset. However, from my completely biased perspective, there are still a few gaps.

Hybrid of Data & Agent Centrism

Notice that all Hashgraph’s examples show the agents (labeled as A B C D E) and who is committing, sending, and receiving what transactions. Normally in blockchain explanations, they only focus on the chain of blocks, and maybe some info about the nonces needed from miners or stakers, but the data is never presented showing how every node actually receives transactions in a different order. This might cast doubt on the use of the word “consensus” when really blockchain just takes one node’s sequence as reality and drops all the others.

However, in Hashgraph, you can see how different agents are each building a different “reality.” Then they use some metadata about each agent’s state to enable them to build consensus based on gossip about gossip. Their algorithm looks at things from the perspective of EACH AGENT and then they somewhat arbitrarily say: “the median timestamp for a data element across agents shall be its official time.”

In the shift from data-centric blockchain toward agent-centric holochain, they are hybridizing.

The creators of Hashgraph made a partial mindshift from data-centric to agent-centric. And you can see how on Holochain, an app could also use exposed data about gossip and DHT timestamps to do its own variant of hashgraph consensus (except beware their patent).

A Fixation on Consensus

If you hear blockchain people talk about distributed computing, it is all about consensus. In fact the Hashgraph folks even claim Byzantine Fault Tolerance is about consensus (and not the ability to tolerate a Byzantine Fault — actions from corrupt or malicious nodes). Why such a fixation on consensus?

Why should you have just one algorithm for manufacturing that consensus for ALL dApps on a platform? Aren’t there many contexts where no consensus is needed? Or where it would be valuable to engage in different social processes around disagreement? In fact, why limit yourself to only one reality when in some cases information about differences of timing could be valuable data?

In Holochain, you have implicit or soft consensus when a data element saturates a majority of the DHT neighborhood where that data element resides. A later attempt to PUT that data to the DHT will produce a collision. But what if it is okay to have the collision, and just say “Okay, two people have now invented the Calculus.” or whatever. So now you have two authors, with different timestamps, and histories, and so what?

Well the “so what” comes into play when the data is a rival resource — like a Twitter handle, a domain name, or a cryptocoin. In this case, you want to handle a collision differently and block the later addition telling them the name is taken or the coin is spent. For general computing on distributed apps, this covers 99.9% of use cases. And on Holochain, the way we recommend implementing currencies using agent-centric crypto-accounting instead of data-centric coins means you don’t use rival coins at all.

So the only remaining case not handled by the soft consensus of the DHT, is when the collision happens before the DHT neighborhood can get saturated by an entry from one author. So if two people try to register the same name at the same time, how do you resolve it?

Paths to Many Consensi

We could pretend there’s just one absolute answer like what the Hashgraph algorithm produces using median time of gossip signatures. Or we could recognize the importance of choice and let the app builder decide.

• Maybe you start an auction and it goes to the highest bidder.
• Maybe you look at their reputation for community contribution and let the greatest contributor have it.
• Maybe you send them each a message to resolve the conflict with each other.
• Maybe you vote on it.

The point is, that for the very small percentage of times you could even have this kind of collision for most distributed computing apps, why would you want to swallow that computational overhead for ALL OTHER non-colliding bits of data? Why rule out the possibility of context-appropriate consensus solutions by hard-coding in only one arbitrary approach?

If 99.9% of data in distributed apps is non-rival, or non-conflicting, shouldn’t we just trigger special consensus resolution on that .1% of the cases and bear the (computational or social) cost of that overhead only on those cases?

However, since Blockchain grew up with its ONE APP being about managing rival coins, everyone thinks consensus is at the heart of the matter of distributed computing. Maybe this is also why blockchains don’t scale for doing generalized computation for dApps. If blockchains can’t even scale coin transactions, which are kind of a ridiculously simple app (Basically: Do you have the key? Okay, then you can write new coins up to the total value of the old coin. Repeat.), how do they ever expect to run things at true Internet scales like Facebook with 520k likes per second?

My answer: Holochain — for lightweight, scalable, P2P dApps which actually get more efficient as more users join.

Some rights reserved

The post Holochain vs. Hashgraph …and when is consensus needed in distributed computing appeared first on P2P Foundation.

Let me say that differently. Since past software has been centrally controlled and administered, it was assumed, that the license-holder of a database owns the data in the database, as well as controlling whatever user accounts and permissions exist for accessing it. Even the most open of organizations (like Wikipedia, who lets you download copies of their databases) can still terminate user accounts or purge spammy advertisements from their database, because it runs on their centrally controlled servers.

Think of your corporate email account. The company you work for can change your password, lock you out of your own email, and they own messages sitting on their server. They control both the identity and the data.

However, what happens when software no longer runs on a central server, but each person publishes data to their own local storage first? Then when that data is intended to be shared, gets published to a shared space (DHT) from your local store. Since Holochain is structured this way, by default each user controls their own data, and via our key management app, they control their own identity, even across any and all Holochain applications. So if a corporation wanted to run a Holochain application under centralized control, instead of generating your own app keys and revocation keys, a corporation would do that and maintain control the revocation keys, so that they could kick you off the system at any time.

On Holochain, to accomplish the old pattern of centralized control that is assumed by software licenses of the past, you essentially have to strip away each user’s control of their own cryptography by owning their keys. This seems like a very different category of USAGE of the software, than Holochain’s native design where users control their own data and identity, thus it merits a different class of license. This isn’t about whether you can copy or change the software, but about how you structure the cyrptographic relationship to users and data generated by the software.

Introducing the Human Commons License

If people run your Holochain app as network of autonomous humans, where each one manages the keys that control their data and identity, then you are operating a “human commons” and operate under that classification as Holochain apps are intended to operate.

However, If you structure the management of keys for the people running your hApp such that you can revoke their keys to the hApp or if you have required them to agree to be stripped of their ownership of data they’ve authored, then this is a commercial classification of the software (not autonomous humans, not a shared commons among them).

We’re still sorting out some of the details for each classification. For example, in the Human Commons case, the software license may be fully free and permissive (like MIT license?), where the commercial usage may be more restrictive (like GPL) such that you’re at least contributing new code back into the commons if you’re taking away people’s identity and data.

However, this classification may be more important to the apps running on top of the Holochain software, than the effect it has on your rights to Holochain. Distinguishing these different usage types at the underlying level lets apps more effectively choose how they want to charge customers. Consider an app like P2P Slack where everyone controls their own data and identity, in contrast to one where a corporation owns the data and user accounts. The builder of that hApp may want to give it freely to those operating a commons, and charge for usage in the corporate case.

New Distinctions in Licensing

Whether you agree with our explorations of increasing restriction on commercial use or not, the point of this article is to call out the importance of distinguishing the fundamentally new patterns of data ownership and identity as part of software licensing concerns for truly P2P software.

In addition to the topic of control of your own data and identity, authored by you and stored on your own device, is the matter of data shared to into a shared space (in Holochain this means published to that apps DHT). For this we look to licenses like Open Data Commons for models there.

What else should we be considering to get licensing of P2P apps right?

Thanks to Eric Harris-Braun. Some rights reserved

The post Licensing needs for Truly P2P Software appeared first on P2P Foundation.