### Desirable features of a peer-to-peer network
- Scalable
- No consensus, peers can change state without having all the other peers agree
- Data availability
- Resilient to network partitions
- Consistency
- Data never reaches an irreconcilable state
- Resilient to bad actors
- If some node is not behaving according to the rules of the game, they can be easily identified and protected against
- Security and Privacy
### Hash-Table
- Key-value store that allocates a bigger chunk of memory than necessary
- To insert a value, we hash the **key**, and put the content in the position of memory that corresponds to that hash
- Constant lookup and write time
### Cryptographic Hash-Table
- Key-value store where the key is the cryptographic hash of the **value**
- After lookup, you can hash the retrieved value again, compare it to the input key, and verify that you are not being lied to
### Distributed cryptographic Hash-Table (DHTs)
- Cryptographic Hash-Table where the hash-table is spread accross many nodes
- Each node can make a get request with the hash of some value, and the network will return the value itself
- Each node may share some responsability to host data and route queries
### Agent
- Defined by a private-public key pair
- For cryptographically signing
- Others can cryptographically verify these signatures
- Action Ledger
- Sequence of all the actions that an agent has taken in a social container
- Signed by the agent
- Merkle trees can create unfalsifiable ledgers
### Merkle Trees
- A merkle tree (technically a DAG) is one where new nodes reference one or more prior nodes by its hash
- It's impossible to change a node in a merkle tree without changing all of downstream nodes as well (or else invalidating the hashes)
- Undetected tampering is impossible
- A merkle chain is a merkle tree without branching
### Integrity Code and Data
- Using cryptography to achieve a binding network integrity contract
- Unique integrity hash specifies a unique network
- The integrity hash is generated from:
- Integrity Code (shared by all peers)
- Defining Validation Rules
- Integrity Data (shared by all peers)
- Properties
- Arbitrary configuration data
- Network Seed
- Glorified property to uniquify equivalent looking networks
### Personal Code and Data
- Personal Code
- User configurable client behaviour that won't infringe on their integrity code constraints
- Private to each user unless disclosed
- Personal Data
- Items in the action ledger are private until disclosed
### DNA & Zomes
- DNA
- Holochain's implementation of integrity & personal code pattern
- Bundle of reusable source code modules
- Called "zomes" in Holochain
- Each zome is a rust crate
- Integrity Zomes
- In Holochain, your integrity code is your ticket into a unique DHT
- They define validation rules
- Coordinator Zomes
- Reusable modules of personal code
- Contains things like CRUD functions and event hooks
DNA (for A Collaborative Document Editor)
Coordinator Zome Bundle
Document Coordinator Zome
Comments Coordinator Zome
Roles Coordinator Zome
Integrity Zome Bundle
Document Integrity Zome
Comments Integrity Zome
Roles Integrity Zome
For example: an agent might only be allowed to update
the document if they have the "Editor" role
### Cell
- Unique per-agent instantiation of a DNA
- Is identified by the union of:
- Agent ID
- Integrity hash
- Called "DNA hash" throughout Holochain docs
- Has access to:
- A private data storage: the source chain
- A shared and public data storage: the DHT
- Only accessible via permissioned zome function calls:
- By an external process connected to the Conductor (eg. GUIs)
- By other cells from its network (with the same integrity hash)
- By other cells in the same conductor
- Can receive these parameters when it is instantiated:
- New properties or network seed
- Which would change the resulting integrity hash
- Membrane proof
- Which may be required to instantiate the Cell
### Source Chain
- Holochain's implementation of an agent's unfalsifiable action ledger
- Each Cell controls its own local source chain
- The chain contains all the actions that a Cell has taken
- An action is announced publicly within the scope of the network
- If any action was private, then agents would be able to fork their chain undetected
- An action may be accompanied or not by some entry (as determined by the application)
- Entries may be private or public
- The union of an action and its entry (if existent) is called a "record"
- An action contains:
- Hash of the previous action
- Author's public key
- Timestamp
- Entry hash, if it's accompanied by an entry
- An action is signed by its author
- At boot time, each source chain will be instantiated with 3 records:
- DNA: includes the integrity hash
- AgentValidationPackage: joining proof that satisfies the requirements that the validation rules declare, making the 3rd record valid
- Create record of its own agent public key
### Holochain's DHT (I)
- Two types of network queries:
- Get a value from its hash
- Get the metadata attached to a given hash
- Guarantees:
- 1st guarantee: data integrity:
- You can verify that the data is correct since you can hash it again like in any cryptographic hash-table.
- Records are guaranteed to come from its author because they are signed.
- 2nd guarantee: the DHT is resilient:
- Censorship resistance: it would be impractical for the network to selectively censor a piece of data in the hash-table
- Availability: pieces of data will likely still be in the network even in outage scenarios
### Holochain's DHT (II)
- Guarantees (continued):
- 3rd guarantee: eventual consistency
- The data state converges to being free of internal contradiction
- Relativity does not allow for a universally correct sequence of events
- So order of events in distributed systems is hard!
- The DHT is a CRDT (Conflict-free Replicated Data Types)
- Data structure that only implements commutative operations
- State machine that derives state from a series of operations
- Any agent given the same operations will arrive at the same end state (regardless of order)
### hApp (Holochain App)
- A local collection of cells, among which an agent id is shared
- Can depend on cells from other hApps
- Each cell has its own role within the hApp
- Eg: in a file storage app, you may have two cells installed:
- “main”: the DHT that everyone joins to using the app
- “file_storage_provider”: only joined by high-storage nodes
### Conductor: the Holochain node
- Local process housing all of your running happs
- Offers a sandboxed execution environment to each cell
- Provides limited capacities
- No access to OS level APIs (eg. filesystem, http)
- Provides a mechanism of communication across cells
- Manages all network communications
- Exposes two types of interface, accessible via websockets:
- App Interface
- Can route zome function calls to appropriate cell
- Can route push signals from cells to subscribers
- Admin Interface
- Cannot be accessed from an app
- Receives admin commands to manage apps (eg. install, uninstall, enable, or list apps)