7: Validating data

Holochain applications 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.

You may recall, from way back at the beginning, that Holochain's first pillar of trust is intrinsic data integrity. We said that each type of app entry can contain any sort of string data whose correctness is determined by custom validation rules. Then we showed how peer validators subject entries to those same rules before accepting them.

If you're using our Rust HDK, you can create basic validation rules with built-in tools that let you define app entries as structs, which can be converted to JSON and back again. This enforces a data schema for each type of app entry. But apps can (and should) define more finely-grained rules too.

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

• The shape of valid data–-upper/lower bounds on numbers, non-empty fields, or correctly formatted email addresses
• Rules of the game–-traditional games like Chess, or socioeconomic games like currencies, supply chains, and voting systems
• Write privileges–-enforcing permissions for creating, updating, and removing entries and links
• Entry membranes–-who's allowed to join the network

Because every participant in this app holds a copy of the validation rules, everybody has the power to hold their peers to them. As a user, you can refuse to participate in a fraudulent interaction. As a peer validator, you can blow the whistle on others who are committing fraud. When all these actions are aggregated, they allow a collection of individuals to form a self-policing network–-a social organism with its own immune system.

Learn more

• Guidebook: Validate Agent

Tutorial: MicroBlog140 >
Tutorial: ForgivingMicroBlogWithWriteControl >
Next: Handling data conflicts with CRDTs or resolution callbacks >>

tags: Holochain Core Concepts

---

deleted example of validation rules…

To make it concrete, let's use a concrete example: a 'mutual credit' cryptocurrency app. Mutual credit is a big subject, but we can use it to illustrate the importance of good validation rules. Here's how this currency works:

• Everyone's account starts at zero.
• Every transaction consists of a debit from the spender's account and a credit to the recipient's account.
• A participant's account balance consists of the sum of all their debits and credits.
• Limits may be set on negative and positive balances, in order to keep currency supply within a reasonable range.

To make this work as a Holochain app, we need validation rules like:

• Every debit entry written to a spender's account must be offset by a credit entry written to a recipient's account.
• Every debit/credit pair must be signed by both parties.
• The spender's current balance minus the transaction value must not exceed the community's agreed-upon negative credit limit.
• Conversely, the recipient's current balance plus the transaction value must not exceed the positive credit limit.

If we didn't have rules like this, we would see all sorts of fraud: credits without corresponding debits (counterfeiting), unauthorized transactions, or spending past credit limits.