DHT operations

An agent receives DHT operations, which are requests for them to transform their slice of the DHT in some way. A DHT operation must be validated before it’s applied. For this reason it’s the input parameter to the validate callback.

Validating actions instead of DHT operations

This is an advanced topic. Writing validation rules that checks DHT operations requires understanding Holochain’s data model. Until you have a reason to write validation rules at this level of granularity, we recommend letting the scaffolding tool generate a validate callback for you, which calls out to stub functions that validate the actions that create, update, or delete your application’s entry and link types, and makes opinionated but sensible choices about which groups of authorities should validate what portions of the op data. The following information is presented for people who have a specific need to further reduce overall validation overhead across the network.

What is a DHT operation?

When an agent writes an action, its data gets added to the shared database by being transformed into multiple DHT operations which the author sends to various authorities — agents in the network who have taken responsibility to validate, store, and serve all data that belongs to a range of basis addresses. Each operation represents a request to add the action data to the primary content or metadata stored at that address.

Choosing validation tasks for operations

All the DHT operations for an action get stored at different basis addresses, and you’re free to write different validation logic for each of them.

Writing good validation code means considering what effect an operation has on the DHT, and how it impacts those who end up validating it. DHT agents don’t choose what types of operation they validate — they simply assume authority for a range of basis addresses, and are expected to process whatever operations they receive.

It’s usually okay to let the scaffolding tool decide how to break up the work. It contains sensible defaults that balances network integrity with performance. However, if your validation logic is computationally costly, or if you have higher security needs, you may want to write different validation logic for different operations.

As an example, you may choose to reduce compute demands by splitting up validation between StoreRecord and StoreEntry operations for a given entry creation action; the former could check the agent’s write privileges while the latter could check the structure of the entry data or the existence of the data it references.

Or you may choose to increase data integrity by having authorities treat every operation the same and execute all the logic necessary to validate the action.

How actions translate to DHT operations

Here are all the DHT operations produced for all the actions, along with their contents and the effect of applying them after validation.

This behavior is under review

While the following info describes the way Holochain should work as formally specified, it’s currently being audited for fidelity to that spec. In the meantime, you may see behavior that differs slightly.

It looks like you are using Internet Explorer. While the basic content is available, this is no longer a supported browser by the manufacturer, and no attention is being given to having IE work well here.