Holochain / Holo Training & Empowerment

Step back and ask the big question, though: why?

Why does it matter whether Fred's Lightning-network transaction buying a coffee in El Salvador came immediately before or after Yegor's transaction in Abu Dhabi selling his yacht for Bitcoin?

Does it even really makes sense to compare these transactions? Their light-cones don't even intersect for a fraction of a second – the concept of "simultaneity" between them doesn't exist. Why are all data-centric systems in the world needing to frantically (and expensively) beat out some globally agreed-upon "total order" between these events?

Every state change is established by an agent committing a chain of Actions referencing Records to an individual blockchain (we call it a Source Chain). The Action (and often the Record) are published to a DHT (Distributed Hash Table).

Every node collaborating in the decentralized computation hosts an "arc" of the DHT hash space – but only if it can independently validate it! This requires 2 things, which form the foundation of an inductive proof of correctness:

1. That the Action and/or Record N is verified to have been computed correctly by the claimed DNA/Zome code, and
2. That each predecessor state (Action and possibly Record N-1) has been hosted by the DHT, and not "Warranted" as incorrect by any node (and the warrant was correct).

If both of these things are true for state N, then by induction, all prior states N-1, N-2, … are also valid, back to the origin of each agent involved .

Once operating in a substrate of validated Actions and Records in a DHT, 2 or more agents can agree on some state change that must occur if and only if a quorum of the agents agree on it. For example,

1. They establish some base agreement about something (eg. commit some Proposal to their respective source chain and the DHT).
2. Then once they all observe that a sufficient quorum of counterparties has agreed (by examining the DHT and perhaps looking at their counterparties source chains, and observing each agreeing Proposal) – they each commit a bit-identical Transaction record to each of their individual source chains.
3. At any time before committing a Transaction, any counterparty can back out, and just leave the process, or commit a Retraction. If so, they cannot (or will not) ever commit a Transaction commit.
4. Once one agent collects a sufficient quorum of Ed25519-signed Transaction commits, they have non-repudiable proof of Consensus. Even if they received the commit out-of-band (eg. not from the DHT, but from private communications with one or more counterparty agents) – the Ed25519-signed commit is adequate for any agent to publish the Action (and Record) on behalf of the committed agent(s), even if the agent has been destroyed the instant after it produced the signed agreement.
5. Once published to the DHT and propagated, the Transaction represents a global change in state to the distributed system, that can be depended on by any other agent in computing its state changes. For example, if the Transaction represent a change in a "mutual credit" account balance between multiple agents, other agents unrelated to the Transaction can depend on it: the agent's balance is valid, and it is inductively proven that all predecessor "mutual credit" balances leading to it were also valid.

A set of rules are implemented for creating and storing data (used by every agent collaborating in the application), and other rules to validate the data (used by every agent hosting DHT Action/Record data). These are call the "DNA" of the application, and are written in Rust. They are often quite small, but can be arbitrarily large and complex, if required.

This DNA code is deployed to a constellation of Holochain agent nodes. You can run these all yourself, or (if desired) contract agents to host the DNA on your behalf (eg. via something like https://holo.host).

This decentralized fleet of Holochain agents accesses each-other as defined by your DNA code, and provides a decentralized API available to any client who wishes to execute functionality or access data available via your API.

Standard Javascript for authenticating with the Holochain-implemented API is available.

Holochain clients do not typically use centralized credentials (eg. API keys or passwords), but instead create an agent under the cryptographic control of the user. This Holochain agent is operated by the user, who always holds the Ed25519 signing keys, and interacts with other agents to execute the user's will in the system.