Hi @Sol I’ve moved your questions to a thread of their own — the ‘About the…’ posts are system-level posts that are just for describing the category.
There was a tech AMA on Holo TG and Philip beadle seems to have a different take (on a similar question posed) and says:
“The hash is checked when the conductor starts up the DNA and loads it into memory. The hash is the network address too so if you try to change. the code and recompile the WASM hash changes and you’re on your own network anyway.”
Ideally, yeah, that’s what would happen. You’d try to mess around with your DNA and your Holochain conductor would fork you off into your own DHT. But the problem is that there’s no way to prove to your peers that you haven’t messed around with Holochain itself to report a DNA hash that doesn’t match the DNA you’re actually using. Heck, you wouldn’t even have to use a DNA at all — you could just create a little program that talks the Holochain protocol. You’d need cryptographic signing at the hardware level to prove that you’re using an official, unmodified Holochain runtime, and technology is not at that stage yet.
But “the proof of the pudding is in the eating”: If Alice produces bad data, that’s the only proof that her peers need thta she’s modified her ‘rules of the game’ for the DHT. This is why we still need validation.
That’s not to say that the Holochain conductor’s DNA hashing is completely useless: You could be an honest user, downloading what you think is a DNA that allows you to participate in application X — and in fact what it really does is cause you to inadvertently do all sorts of evil things. But as long as you trust the Holochain conductor itself, there’s no way that a malicious third party can trick you into downloading an evil DNA. The best they can do is cause you to be in the wrong DHT, where any evil actions that your DNA takes won’t blacklist you in the right DHT.
why do holochain use libsodium for cryptographic implementation? Why not other options like Bouncy Castle, Botan, Libgcrypt etc?
As you probably know, ‘good’ cryptography happens out in the open. The robustness of an algorithm depends not on hiding its implementation but on subjecting it to as much scrutiny as possible. People recommend not ‘rolling your own’ crypto. This means:
- Don’t create your own algorithms.
- Don’t write your own implementations of trusted algorithms.
Your single-maintainer library won’t be as bug-free as one maintained and analyzed by hundreds of academics, white-hat hackers, and security professionals.
NaCl, and its daughter project libsodium, take this one step further:
- Don’t choose your own algorithms.
They have a very opinionated stance: there are a lot of crypto algorithms out there, and it’s not enough just to pick one and use it. You need to know whether it’s actually a good algorithm for for your needs. So NaCl/libsodium track the current industry ‘best practice’ recommendations and only implement one or two algorithms for any given category – key derivation, key exchange, signing vs encryption, hashing, etc.
Bouncy Castle et al are big huge toolkits that aim to provide reliable and bug-free implementations of lots of different cryptographic algorithms. But they don’t give as strong guidance as NaCl/libsodium about what algorithms you should use to get the job done.
Anyhow, that’s my limited understanding of why we went with libsodium. We can take an advantage of a whole industry’s wisdom rather than having to become deep crypto experts ourselves. That frees us up to be experts in our own domain.
When a author’s transaction start to get broadcast to random nodes in the DHT, are each transaction send directly from author straight to each of the chosen nodes?
Different DHTs use different replication models. My understanding (which may be incorrect) is illustrated in this document, complete with happy pictures tl;dr:
- An author tries their best to contact the one node that they think is ‘most responsible’ for holding their entry.
- That node either accepts it, validates it, and gives back a validation certificate (or warrant), or they point the author to the node they think is ‘more responsible’.
The author themselves contacts the ‘more responsible’ node. Steps 1 and 2 are repeated until one node finally accepts the entry.
- After validating the entry, the ‘most responsible’ node spreads the data to its neighbours. A node will always have a (nearly) complete picture of its neighbourhood, so it knows exactly who else should be holding the entry. I don’t know if it just passes it on to the next-nearest neighbours, or all of them at once, or what.
So you’ll note that the Holochain DHT design favours direct contact rather than eventual propagation. This lets us come to consistency quickly — we call it ‘fast push, slow heal’.