Update to add basic Merkle log information and update broken links (#813

)

* Update to add basic Merkle log information and update broken links

Signed-off-by: pcnorth <120174435+pcnorth@users.noreply.github.com>

* removed blockchain API page

Signed-off-by: pcnorth <120174435+pcnorth@users.noreply.github.com>

* review change request added

Signed-off-by: pcnorth <120174435+pcnorth@users.noreply.github.com>

---------

Signed-off-by: pcnorth <120174435+pcnorth@users.noreply.github.com>
Signed-off-by: Phil North <120174435+pcnorth@users.noreply.github.com>

content/glossary/common-datatrails-terms/index.md

@@ -46,7 +46,7 @@ Select a term for more information.
 | [organization](/platform/administration/verified-domain/)| any entity with a distinct DataTrails account who publishes or verifies provenance information on the platform|
 | [principal_accepted](/platform/overview/advanced-concepts/#user-principals-on-events)| the actual user principal information belonging to the credential used to access the DataTrails REST interface|
 | [principal_declared](/platform/overview/advanced-concepts/#user-principals-on-events)| an optional user-supplied value that tells who performed an Event|
-| [proof mechanism](/platform/overview/advanced-concepts/#proof-mechanisms)           | method by which information on the DataTrails blockchain can be verified; selected when an Asset is created                                                                                       |
+| [proof mechanism](/platform/overview/core-concepts/#proof-mechanisms)           | method by which information on the DataTrails blockchain can be verified; selected when an Asset is created                                                                                       |
 | [provenance](https://en.wiktionary.org/wiki/provenance) | the version and ownership history of a piece of data. With DataTrails this is an immutable audit trail to prove Who Did What When to any piece of data  |
 | [public asset](/platform/overview/public-attestation/)        | Assets that can be used to publicly assert data, accessible by URL without the need for a DataTrails account                                                   |
 | [selector](/platform/overview/creating-an-asset/#creating-an-asset)            | identifying attribute the Yaml Runner will use to check if your Asset exists already before attempting to create it  |

content/platform/overview/advanced-concepts/index.md

@@ -119,14 +119,6 @@ Once committed to the DataTrails system, each lifecycle Event record carries 2 s
 
 For more detailed information on Events, and how to implement them, please refer to the [Events API Reference](/developers/api-reference/events-api/).
 
-## Proof Mechanisms
-
-Assets and Events are core to the DataTrails platform, and being able to quickly demonstrate proof that these artifacts have not been tampered is key to being able to use them.
-
-When [creating an Asset](/platform/overview/creating-an-asset/), DataTrails uses a proof mechanism for that Asset and its Events. This determines how your data is recorded on the DataTrails blockchain.
-
-Our Simple Hash proof mechanism takes all the Events within a past time period (the default is the last 30 days) and commits them to the blockchain as one hash. This hash value can then be used to compare the current state of the Asset, and identify if any changes have occurred. With Simple Hash, you will not be able to see exactly what those changes were, only that something has changed.
-
 ## Access Policies
 
 Sharing the right amount of information with your value chain partners is critical to creating a trustworthy shared history for Assets. It is important that every participant be able to see and contribute to the management of Assets without compromising security, commercial, or private personal information. For example, competing vendors should not see each other’s information, but both should be able to freely collaborate with their mutual customer or industry regulator.

content/platform/overview/core-concepts/index.md

@@ -37,6 +37,29 @@ Events are things that happen during an Asset's lifecycle. Each Event Record con
 
 Events can never be deleted or modified. Events provide details on Asset attributes, such as updating the weight of a shipment, and/or details about the event itself, such as a recording a new document version.
 
+## Proof Mechanisms
+
+Assets and Events are core to the DataTrails platform, and being able to quickly demonstrate proof that these artifacts have not been tampered is key to being able to use them.
+
+When [creating an Asset](/platform/overview/creating-an-asset/), DataTrails uses a proof mechanism for that Asset and its Events. This determines how your data is recorded on the DataTrails blockchain. 
+
+DataTrails attestations are committed to immutable storage that is underpinned by cryptographically verifiable Merkle Mountain Range data structures for long term verifiability, even when offline.
+
+{{< img src="merkleflow.png" alt="Rectangle" caption="<em></em>" class="border-0" >}}
+
+**Four Increasing Trust Levels**
+
+In the customer's environment, data can be tampered, shredded, backdated...
+
+Once `STORED` in DataTrails and shared with partners, no party to the transaction can tamper, back-date or shred evidence. However there could be a suspicion that DataTrails (or a hacker in our systems, or Microsoft under subpœna) could tamper with the data, or make it unavailable or something.
+
+Once `COMMITTED` in the customer's Tenancy Merkle tree in public blob storage, customers can prove their Events to 3rd parties, AND any tampering by DataTrails is detectable (as long people check). Because this data is public, anyone can keep and maintain a copy just in case DataTrails' version disappears. If this checking is weak, and/or copies are not made, then in principle Data Trails could create forks.
+
+By adding all Tenancies to the Merkle Mountain Range (MMR) and signing the root, Events move to the `CONFIRMED` stage. The signature on to root holds DataTrails to account and prevents forks, and also prevents a kind of sybil attack that could otherwise be mounted by 3rd party verifiers. Even so, a tiny chance of tampering remains: DataTrails could possibly sign multiple MMRs and maintain multiple split histories, then present whichever version of the history is most advantageous.
+
+To make the whole history and individual events `UNEQUIVOCAL`, the root hash of the Committed MMR is periodically broadcast to single, well known location outside of DataTrails control (such as a smart contract address on Ethereum, or an official X account).
+
+
 ## Access Policies
 
 Sharing the right amount of information with the consumers of your data is critical to creating a trustworthy shared history for any Asset. It is important that every participant be able to see and contribute to the management of those Assets without compromising security and private information. To ensure stakeholders can access only the Assets and attributes relevant to them, transactions are private by default, unless the Asset was created as a [Public Asset](./#the-public-view). An Administrator defines how many of the Asset's attributes the Access Policy permits a user to see so that they only see what they need to complete a task.

content/platform/overview/introduction/index.md

@@ -33,3 +33,4 @@ DataTrails permanently records evidence into an **Immutable Audit Trail** to bri
 
 DataTrails delivers assured metadata in a single line of code in a way that makes recording and auditing the full lifecycle of a piece of data simple. Any authorized participant (including a user, a software agent or an endpoint device) can register the Events that they are involved in.<br> 
 Users of the data can see a full picture of the data’s origin and history and by understanding *Who Did What When*, human actors and software/AI systems can make stronger real-time judgments about the trustworthiness of your data.
+{{< img src="intro.png" alt="Rectangle" caption="<em>DataTrails Functionality</em>" class="border-0" >}}

content/platform/overview/registering-a-document-profile-asset/index.md

@@ -134,7 +134,7 @@ In the file you created earlier, begin adding metadata for your Asset:
    * `Document Type` - This is the class of the object; while it is arbitrary, it is best to have consistency amongst the type of Documents you use i.e. if it is a purchase order, the type could be `Purchase Order`, which will then be pre-populated for future Documents to use as their own types.
    * `Proof Mechanism` - The method used to commit the blockchain transaction.
 
-    Please see our [Advanced Concepts](/platform/overview/advanced-concepts/#proof-mechanisms) section for more information on selecting a Proof Mechanism for your Document
+    Please see our [Advanced Concepts](/platform/overview/core-concepts/#proof-mechanisms) section for more information on the Proof Mechanism for your Document
 {{< tabs name="add_asset_details_min" >}}
 {{{< tab name="UI" >}}
 {{< img src="RegDocAdvancedOptions.png" alt="Rectangle" caption="<em>Advanced Options</em>" class="border-0" >}}