There are three separate issues to consider:
- Data synchronisation in a distributed system
- Logical ordering of events
- Linking events that happen on the computer to events that happen in real life
1. Data synchronisation in a distributed system:
There are a lot of ways for a distributed system to reach consistency, but they can all be sorted into two broad categories.The nodes can either synchronise updates and resolve conflicts by using some sort of coordination protocol, or they can avoid conflicts altogether by using the Consistency as Logical Monotonicity (CALM) Principle. It states that as long as updates add to and never subtract from (or change) the existing data set, conflicts will never occur and coordination protocols are not needed. Nodes don’t necessarily have up-to-date data, but they never have incorrect or conflicting data. Here’s a brief look at how CALM guarantees this:
“…non-monotonic programs are order-sensitive: the order in which they receive information determines how they toggle state back and forth, which in turn determines their final state. By contrast, monotonic programs simply accumulate beliefs; their output depends only on the content of their input, not the order in which is arrives.”
Blockchain has chosen the first approach. In its synchronisation protocol, each addition to the data set must be included in a block that is compiled by a lottery winner (the ‘miner’) and accepted by all parties. Holochain has chosen the second approach, along with Git, IPFS, and Secure Scuttlebutt.
2. Logical ordering of events:
When people talk about timestamping things, there certainly are situations where actual time matters (e.g. deadlines), but real-world time is often less important than simply figuring out whether event A happened before or after event B. This is true of data sync strategies that rely on coordination protocols, but it’s also true of application-level concerns, such as financial transactions or legal contract effects. Real-world timestamps are unreliable, which is where logical clocks come in. If you can draw a meaningful correlation between A and B, such that you can show A ‘caused’ B, then logically, A happened before B. This can be seen in Bitcoin’s blockchain structure and UTXO ledger, as well as in Holochain’s source chains, HoloFuel’s countersigned transactions, and Git histories.
3. Linking to real-life events:
When you truly need to anchor data to something that happens in the real world, then timestamps are appropriate. But because time is relative to the observer, in both the scientific sense and in the sense of imprecise clock machinery, you must choose one individual or an aggregate perspective as canonical. Depending on the need for precision, this may be the data author’s system clock, the average of a group of nodes’ system clocks, or a trusted timestamping service. If data is related—in a set of interacting transaction ledgers, for instance—timestamps on the data produced by less trusted agents can be compared with those on data produced by more trusted agents.