Holochain Forum

Public vs. Private and DHT vs. Chain


I am trying to understand how public chains related to private chains and a DHT relates to the chains.

For example, if I store something on my “private” chain, is that the same thing as storing a private entry on the public DHT?

If there is a document that describes this in detail, it would be great to get the link. Thanks


I’ll just chime in quickly…

For each “DNA” someone launches, they have exactly one chain per DNA. That chain contains public and private entries. There’s two chunks to each entry, the ‘header’ and the ‘contents’ … the ‘headers’ are the ones that actually act like a linked-list or “blockchain”, they contain pointers to the contents too.
For public entries, the header and the contents are shared to the DHT.
For private entries, only the header is shared to the DHT.
This means that each persons source chain can be validated by other peers without knowing anything about the private contents.


Thanks @Connoropolous,

So, when I think of a person’s “private chain,” is it fair to think of it as a person’s private entries on the specific DNA’s chain?

As a follow up. Say I have a DNA that has 5 agents, and the DHT is sharded across all 5 agents computers. Is an agent’s “private chain” part of that sharded DHT, or is it only on a agent’s device?

Appreciate the help here.

So, when I think of a person’s “private chain,” is it fair to think of it as a person’s private entries on the specific DNA’s chain?

Yes, the private is interwoven with the public on the chain itself… then, it is only the contents of public entries that are shared to the DHT, and not the contents of private entries. (Only the HEADERs of private entries

This may be a little much to share, but could also be useful… here is the type definition, in Rust syntax, for a “Header”. This is the metadata aspect that is shared to the DHT.

pub struct ChainHeader {
    /// the type of this entry
    entry_type: EntryType,
    /// Key to the associated contents
    entry_address: Address,
    /// Address(es) of the agent(s) that authored and signed this entry,
    /// along with their cryptographic signatures
    provenances: Vec<Provenance>,
    /// Key to the immediately preceding header. Only the init Pair can have None as valid
    link: Option<Address>,
    /// Key to the most recent header of the same type, None is valid only for the first of that type
    link_same_type: Option<Address>,
    /// Key to the header of the previous version of this chain header's entry
    link_update_delete: Option<Address>,
    /// ISO8601 time stamp
    timestamp: Iso8601,

(from https://docs.rs/holochain_core_types/0.0.44-alpha3/src/holochain_core_types/chain_header.rs.html#31-48)

This is great. So one last question on this. (OK a few.) If the contents of the private chain are not stored out to the shared DHT, are they just stored locally on my own machine? If that is the case, what happens if I have two computers running the same agent for the same DNA? How will they access the contents of the private entries?

Thanks so much.

Ah, here some of the assumptions you’re holding have to be updated.

You can’t/shouldn’t run the same agent for the same DNA on two devices. An agent is really an identity, which is really a private/public key pair.

You can/could transfer a chain from one device permanently over to another device, say you switched laptops or whatever. There’s no way to sync the chains of the two devices ongoingly, just to port.

Private entries have to stay private on a single device, that’s what ‘private’ means with Holochain.

If you use Holo to host a hApp, you won’t have to worry about any of this, since you’re using a hosting provider.

There’s also something in the works called ‘DeepKey’ which is like “distributed public key infrastructure” and I think that might be supposed to help with the multi-device situation too, but I’m less sure about that one.

1 Like

Ok, great. This makes sense to me now. Private chain is physically stored on the one device. If I want to back it up, I need to back it up as part of backing up the device.