Skip to content

Commit

Permalink
Update docs [skip ci]
Browse files Browse the repository at this point in the history
  • Loading branch information
guiguan committed Sep 4, 2020
1 parent 2f81070 commit 5f8d324
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 3 deletions.
3 changes: 2 additions & 1 deletion book.toml
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,10 @@ build-dir = "docs_output/book"

[output.html]
git-repository-url = "https://github.com/SouthbankSoftware/proofable"
google-analytics = "UA-101162043-19"

[output.linkcheck]
follow-web-links = true
traverse-parent-directories = true
exclude = []
exclude = ["https://storage.googleapis.com/provendb"]
command = 'bash -c "ln -s ../../../gh-pages/node_sdk/reference ../html/node_sdk/reference && mdbook-linkcheck"'
2 changes: 1 addition & 1 deletion docs/concepts/chain_of_trust.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,4 +2,4 @@

![Chain of Trust](../images/chain_of_trust.png)

When a piece of information (data) is anchored to a blockchain using a Merkle trie, we can work backward using the corresponding Merkle path to assert that the data has existed from the time of the blockchain transaction. The Merkle path itself becomes a certificate for the data. We can generate such a certificate to prove that the data has existed from a timestamp. If the data is an image, then we can use the certificate to verify an arbitrary image and see whether someone has tampered with it. We can also use the timestamp to verify the certificate itself, such that when we trust the timestamp, we can check the validity of the certificate and then the image. In this way, the surface area for potential forgery attack is reduced to a block. Or if we remembered and trusted the transaction hash of the certificate, the attack surface is reduced to that transaction. The timestamp and transaction hash are the seed information like the [first principles](https://en.wikipedia.org/wiki/First_principle) in philosophy which we can base our trust on. In this way, a chain of trust is formed from the blockchain seeds to our image contents as in above figure. For more details, please check out our Medium post [Build Trust into Image with Blockchain](https://medium.com/@guiguan/build-trust-into-image-with-blockchain-4894c39bde7f)
When a piece of information (data) is anchored to a blockchain by Proofable using a Merkle trie, we can work backward using the corresponding Merkle trie path to assert that the data has existed from the time of the blockchain transaction. The Merkle trie path itself becomes a certificate for the data. We can generate such a certificate to prove that the data has existed from a timestamp. If the data is an image, then we can use the certificate to verify an arbitrary image and see whether someone has tampered with it. We can also use the timestamp to verify the certificate itself, such that when we trust the timestamp, we can check the validity of the certificate and then the image. In this way, the surface area for potential forgery attack is reduced to a block. Or if we remembered and trusted the transaction hash of the certificate, the attack surface is reduced to that transaction. The timestamp and transaction hash are the seed information like the [first principles](https://en.wikipedia.org/wiki/First_principle) in philosophy which we can base our trust on. In this way, a chain of trust is formed from the blockchain seeds to our image contents as in above figure. For more details, please check out our Medium post [Build Trust into Image with Blockchain](https://medium.com/@guiguan/build-trust-into-image-with-blockchain-4894c39bde7f)
2 changes: 1 addition & 1 deletion docs/concepts/trie.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ A trie is a [data structure](https://eth.wiki/en/fundamentals/patricia-tree) tha

No matter what order the key-values are put in, the same bag of key-values will always result in the same trie with the same Merkle root. This determinism is known as commutative and associative of data hashing, which allows a trie to be built incrementally with efficiency. The inserts, lookups, updates, and deletes of key-values in a trie are all in O(log(n)). Thus, a new trie can be easily derived by modifying an existing trie. In storage-wise, each trie node is stored in a key-value store with the node's hash as the key and node's data as the value. This makes the trie storage agnostic and flexible enough to support all-sorts of key-value stores, such as embedded databases like LevelDB or blob storages like S3. This also makes modifying an existing trie memory and computation efficient, because only the modified trie nodes need to be loaded from the persistent store, and new nodes need to be saved back.

In Proofable, we extended the trie to be an all-in-one solution package. When a trie is updated, a new trie root will be created, but previous trie node data are still there and immutable. The series of trie roots resembles the history of the trie data change. A trie proof can be created for each root, which means the hash of the root will be anchored to a blockchain of the user's choice permanently. Once the anchoring is confirmed, all the data contained in the trie at the given root will be mathmatically/cryptographically authenticated, i.e. it will be able to claim that the trie data exist exactly like this at the time of the confirmation. A key-values proof can be also extracted from a trie to independently prove a subset of the key-values the user is interested in, e.g. claiming that two key-values of particular interest exist exactly like this at the time of the confirmation. When all manipulations are done, the trie can be exported by the user and put in a safe place they have full control. Later on, the trie can be imported back to do further manipulations.
In Proofable, we extended the trie to be an all-in-one solution package - Proofable certificate. When a trie is updated, a new trie root will be created, but previous trie node data are still there and immutable. The series of trie roots resembles the history of the trie data change. A trie proof (anchoring trie path of the certificate) can be created for each root, which means the hash of the root will be anchored to a blockchain of the user's choice permanently. Once the anchoring is confirmed, all the data contained in the trie at the given root will be mathmatically/cryptographically authenticated, i.e. it will be able to claim that the trie data exist exactly like this at the time of the confirmation. A key-values proof (sub-certificate) can be also extracted from a trie to independently prove a subset of the key-values the user is interested in, e.g. claiming that two key-values of particular interest exist exactly like this at the time of the confirmation. When all manipulations are done, the trie can be exported by the user and put in a safe place they have full control. Later on, the trie can be imported back to do further manipulations.

Using the trie as the basis for Proofable and [ProvenDB](https://www.provendb.com/) has the following advantages over more simplistic approaches:

Expand Down

0 comments on commit 5f8d324

Please sign in to comment.