Holochain DNAs specify validation rules for every type of entry or link. This empowers end-users to check the integrity of the data they see. When called upon to validate data, it allows them to identify corrupt peers and publish a warrant against them.

Holochain is a framework for building apps that let peers directly share data without needing the protective oversight of a central server.

How does it do this? You may recall from the beginning of this series that Holochain’s two pillars are intrinsic data integrity and peer replication/validation. The first pillar defines what valid data looks like, while the second pillar uses the rules of the first pillar to protect users and the whole network.

We said that each type of app entry can contain any sort of string data whose correctness is determined by custom validation rules.

We then showed how peer validators use those rules to analyze entries and spread news about bad actors.

Holochain is the engine that moves data around, validates it, and takes action based on validation results. Your DNA is simply a collection of functions for creating data and validation rules for checking that data. Those two things are critical to the success of your app because they define the membranes of safety between the user and DHT. Well-designed validation rules protect everyone, while buggy validation rules leave them vulnerable.

Some entries can be computationally expensive to validate. In a currency app, for example, the validity of a transaction depends on the account balances of both transacting parties, which is the sum of all their prior transactions. The validity of each of those transactions depends on the account balance at the time, plus the validity of the account balance of the people they transacted with, and so on and so on. The data is deeply interconnected; it could take forever to call up every single transaction and validate it, which is inconvenient when all you want to do is buy a cup of coffee and get to work.

The DHT offers a shortcut—it remembers the validation results of existing entries. You can ask the validators of the parties’ previous transactions if they detected any problems. You can assume that they have done the same thing for the transaction prior to those and so on. As long as you trust a significant portion of your peers to be following the same rules as you, the validitation result of the most recent entry ‘proves’ the validity of all the entries before it.

A validation function returns either true or false, with an optional error description. It’s called in two different scenarios, each with different consequences. We’ll carry on with the DHT illustrations from chapter 4, but let’s add a simple validation rule: there’s an entry of type word whose validation rule says that it can only contain one word.

When you commit an entry, your Holochain conductor is responsible for making sure you’re playing by the rules. This protects you from publishing any invalid data that could make you look like a bad actor.

Alice calls the same zome function with the string "orca whales". Again, the function calls commit.

Again, the conductor calls the validation function for the word entry type.

This time, the validation function sees two words. It returns an Err containing the message "Must contain only one word".

Instead of committing the entry, the conductor passes this error message back to the waiting zome function.

You can see that author-side validation is similar to how data validation works in a traditional client/server app: if something is wrong, the business logic rejects it and asks the user to fix their data.

When your node receives an entry for validation, the flow is very different. Your Holochain node doesn’t just assume that the author has already validated the data; they could easily have hacked their conductor to bypass validation rules. It’s your duty and right to treat every piece of data as suspect until you can personally verify it. Fortunately, you have your own copy of the validation rules.

Here are the two scenarios above from the perspective of the validators.

The purpose of validation is to empower a group of individuals to hold one another accountable to a shared set of rules. This is a pretty abstract claim, so let’s break it down into a few categories. With validation rules, you can define:

Access membranes—validation rules on the agent ID entry govern who’s allowed to join a DNA’s network and see its data.

The validation rule for any entry or link type is simply a function that takes a string, analyzes it, and returns a result (Ok or an error message).

If your entry holds structured data such as JSON, however, it’s annoying to hand-roll your own parsing code. The HDK lets you write a validation function that accepts a typed struct rather than a string. It’ll automatically assume that the entry content is JSON and try to deserialize it into an instance of that struct. If it can’t make the conversion, validation fails before your function is even called. This lets you forget about the low-level details and work with the native types that you’ve defined in your app.

Validation functions return a boolean value, meant to be used as clear evidence that an agent has tampered with their Holochain software. This means they aren’t appropriate for soft things, like codes of conduct, which usually require human approval. They should be deterministic and pure so that the result for a given commit doesn’t change based on who validated it, when they validated it, or what information was available to them at validation time.

Nothing can be invalidated once it’s been published and validated, but just as with updating or deleting entries, you can write new data that supersedes existing data.