A couple days ago, I asked in the SAFE forum about what happens if a section is taken over, and the responses mainly indicated that this would be a disaster for all data in the section. However, it doesn’t need to be so.
I propose a layer that you can add on top of SAFE network to make it even SAFER I wrote in the subject that this is for crypto-currency, but it can really apply to any mutable data.
First, a few definitions:
A Merkle DAG (Directed Acyclic Graph) is exactly as it sounds. Used in Git and other places to verify integrity of revisions, with data pointing backwards in time. Note that the existence of a hash only proves that someone generated the previous hashes earlier. You can verify membership in a DAG by simply having a Merkle Branch (path in the Merkle DAG from the root, including all immediate parents).
A Signed Merkle DAG would have among the parents a cryptographic signature of the other parents (i.e. signed data) using public key cryptograpy. This is proof (vulnerable to quantum computer attacks in the future) that a given participant signed the membership in the Merkle DAG, presumably after verifying some rules.
A “Merkle Head” is a hash in the DAG that doesn’t have any immediate children.
A “Merkle Stream” is a Merkle DAG which has only one “Head”. (This is the terminology we use at Qbix. In effect, it is the dual of a Tree)
Now, every Merkle Stream has a history going all the way to its first state. Let’s represent coins as Merkle Streams, and let’s put responsibility on the party holding a coin to store the entire history of the coin, up until it was transferred to them.
- “Notaries” are participants in the network which approve transactions.
Third parties – in your case, Sections in the SAFE Network running a consensus algorithm – approve transactions transferring a coin from A to B. More generally, this could be any type of stream, and approval would consist of validating certain rules for that type of stream (such as moves in a chess game).
Once the consensus process completes and a transaction is approved, it is cryptographically signed as in 2, and now the Section contains the latest information. The Section should store at least a little bit of history for this Merkle Stream, so that others can update their copy when they come online. Who are these others?
- “Watchers” are nodes which watch transactions approved and signed by the Notaries, which are appended to a given Stream. They likewise have the stream type and rules, and make sure that the transaction didn’t violate any rules.
In the case of a crypto-currency, one of the rules is that it can’t be double-spent, so the same Section MUST NOT suddenly switch to publishing a different fork than before. In the case of more complex Stream types, there may be more rules than this.
Watchers can be chosen by “close distance” from the transaction’s id. To make this group of watchers unpredictable by any one party in advance (so they can’t all be bribed), the transaction can contain random nonces contributed by the various parties in the transaction.
- A “Claim of Violation” is a claim made by a Watcher that they have cryptographic proof of a certain violation by a Notary. Perhaps a transaction was approved by a Notary but the Watcher claims it violated a rule. Or, perhaps the Notary suddenly switched to publishing another fork of the Merkle Stream, e.g. after payment was accepted.
Watchers are supposed to gossip Claim of Violation, verify it and store it (as long as they are honest). Ultimately, the Recipient of a Coin (or anyone loading the latest head of a Merkle Stream) is responsible for waiting and checking if any watchers report a Claim of Violation about this transaction. The costs of this should be covered by the Recipient of the Coin.
The Recipient checks the Claim of Violation against the Signed Merkle Tree cryptographically signed by the Section, and may agree that this Claim is legitimate. They then submit their version of the history to the Network, which may choose to have another Section become the custodian of the data. It may be that several Recipients will have competing histories, that diverge at some point.
Meanwhile, the “Watchers” in the Network are responsible for gossiping the Claims of Violation, and help reassign all the data from the provably compromised Section to a new Section.
All participants in the network who come across these Claims are supposed to check them, and if the claims are true, they start re-routing all requests to the new Section, not the compromised one.
A “Permissionless Timestamp Network” is a network where participants form a binary Merkle Tree (at most two parents per child) by timestamping their neighbors in order, if their head hashes have changed, and propagating hash chains to prove timestamps relative to a given stream. This allows anyone in order to determine which events happened first, relative to a given Stream/Watcher.
Given several Merkle DAGs that share a common history, they can be sorted relative to a Watcher as X < Y whenever X diverges from Y at a transaction X1 vs Y1, and X1 happened before Y1 relative to that Watcher. Thus we can find the “Earliest History” relative to a Watcher, of a set of Merkle DAGs sharing a common history.
Recipients still holding a Coin are responsible to listen for Claims of Violation by Watchers, and verify these claims. False claims can be submitted to the network to penalize the Watcher, and downgrade its reputation. Claims of Violation that verify as True are submitted to the new Section along with the Recipient’s history of the coin.
The earliest history is stored by the new Section.
The old Section is either decommissioned or deranked by the Network.