Enhance documentation website

docs/docusaurus.config.js

@@ -86,37 +86,6 @@ const config = {
             label: 'About Mithril',
             position: 'left',
           },
-          {
-            type: 'dropdown',
-            label: 'Developer Docs',
-            position: 'left',
-            items: [
-              {
-                to: '/aggregator-api',
-                label: 'Aggregator Node - API Reference'
-              },
-              {
-                href: 'https://mithril.network/mithril-aggregator/doc/mithril_aggregator/index.html',
-                label: 'Aggregator Node - Rust documentation'
-              },
-              {
-                href: 'https://mithril.network/mithril-signer/doc/mithril_signer/index.html',
-                label: 'Signer Node - Rust documentation'
-              },
-              {
-                href: 'https://mithril.network/mithril-client/doc/mithril_client/index.html',
-                label: 'Client Node - Rust documentation'
-              },
-              {
-                href: 'https://mithril.network/mithril-core/doc/mithril/index.html',
-                label: 'Cryptographic Core Library - Rust documentation'
-              },
-              {
-                href: 'https://mithril.network/mithril-common/doc/mithril_common/index.html',
-                label: 'Common Node Library - Rust documentation'
-              },
-            ]
-          },
           {
             to: '/glossary',
             label: 'Glossary',

docs/root/mithril/topologies/_category_.json → docs/root/manual/developer-docs/_category_.json

@@ -1,10 +1,10 @@
 {
-    "label": "Topologies",
+    "label": "Developer Docs",
     "collapsible": true,
-    "collapsed": true,
+    "collapsed": false,
     "position": 3,
     "link": {
         "type": "generated-index",
-        "title": "Topologies Topics"
+        "title": "Developer Docs Topics"
     }
 }

docs/root/manual/developer-docs/architecture/_category_.json

@@ -0,0 +1,10 @@
+{
+    "label": "Mithril Network",
+    "collapsible": true,
+    "collapsed": false,
+    "position": 1,
+    "link": {
+        "type": "generated-index",
+        "title": "Mithril Network Architecture Topics"
+    }
+}

docs/root/mithril/topologies/aggregator.md → docs/root/manual/developer-docs/architecture/aggregator.md

@@ -1,11 +1,19 @@
-# Aggregator
+---
+sidebar_position: 2
+---
+
+# Mithril Aggregator Node
 
 The Aggregator is the central piece of the Mithril certificate creation.
 
 The first phase of the protocole is triggered when a new Epoch starts in the Cardano network. The aggregator node saves the current stake ditribution and starts performing the snapshot for this new epoch which is then stored in the cloud. A message is then created containing the current and the previous snapshots digests.
 
-### Certificate creation
+## Certificate creation
 
 During this phase, the aggregator waits to reach a stake quorum of signers. They register to be part of the lotery process of the multisignature. During all this time, the certificate is in _pending_ state. Once the quorum is reached, the aggregator issues the multisignature certificate and stores it in the certificate chain.
 
-![](images/aggregator.png)
+![](images/aggregator-workflow.png)
+
+## Runtime
+
+![](images/aggregator-runtime.jpg)

docs/root/manual/developer-docs/architecture/architecture.md

@@ -0,0 +1,49 @@
+---
+sidebar_position: 1
+sidebar_label: Architecture
+---
+
+# Mithril Network Architecture
+
+Welcome to the Mithril Network Architecture!
+
+:::tip
+
+For more information about the **Mithril Protocol**, please refer to the [About Mithril](../../../mithril/intro.md) section.
+
+:::
+
+## Introduction
+
+In its current version, the **Mithril Network** is a network of node responsible for creating **Snapshots** and **Certificates** that enable fast bootstrap of a **Cardano Node**. It runs on top of the **Cardano Network**.
+
+:::info
+
+The role of a Mithril Network is to enable end users to restore a full Cardano node in less than 2 hours!
+
+:::
+
+It is basically composed of three nodes:
+
+* [**Mithril Aggregator**](aggregator.md):
+
+> The trust less node that orchestrates the work of the MIthril Signer nodes and that gathers their individual signatures to produce Mithril multi signatures and their associated certificates. It is also in charge of creating and storing the ledger state snapshot archive.
+
+* [**Mithril Signer**](./signer.md):
+
+> The node that works transparently on top of the Stake Pool Operator Cardano nodes and which individually signs the ledger state.
+
+* [**Mithril Client**](./client.md):
+
+> The node used to restore a Cardano full node by retrieving, from a Mithril Aggregator, a remote snapshot, its certificate chain and by verifying their validity thanks to the Mithril cryptographic primitives.
+
+## Architecture Overview
+
+:::info
+
+* This document is subject to change as it is a work in progress.
+* We are currenty working on **decentralizing** further the somewhat **centralized** architecture.
+
+:::
+
+[![](images/architecture.jpg)](images/architecture.jpg)

docs/root/mithril/topologies/client.md → docs/root/manual/developer-docs/architecture/client.md

@@ -1,7 +1,11 @@
-# Client
+---
+sidebar_position: 4
+---
+
+# Mithril Client Node
 
 A client is a Snapshot consumer. It is typically a Wallet that wants to synchronize with the Cardano blockchain. When performed from the begining of the chain, it can take several days to compute all the blocks and verify everything is consistent. Snapshots act as certified savepoints, the wallet can assume all the blocks in the snapshots are consistent hence only the newer blocks are to be verified. This dramatically reduces the synchronization times.
 
 ## Topology
 
-![](images/client.png)
+![](images/client-workflow.png)

docs/root/mithril/topologies/signer.md → docs/root/manual/developer-docs/architecture/signer.md

@@ -1,7 +1,19 @@
- # Signer
+---
+sidebar_position: 3
+---
+
+# Mithril Signer Node
 
  A Signer is a participant to a Mithril Multisignature. As such, a signer contributes to signing an expected genuine message. To do so, the signer computes the digest from the information stored on a Cardano node and signs it with his secret key. This signed message is sent to the Aggregator, along with the corresponding won lottery numbers. This way, the Aggregator can assess that the Signer is identified and has signed the same message.
 
- ## Topology
+## Topology
+
+![](images/signer-workflow.png)
+
+## Process
+
+![](images/signer-workflow-2.png)
+
+## Runtime
 
-![](images/signer.png)
+![](images/signer-runtime.jpg)

docs/root/manual/developer-docs/references.md

@@ -0,0 +1,47 @@
+---
+sidebar_position: 2
+---
+
+# API References
+
+Welcome to the Mithril references docs!
+
+:::info
+
+This page gathers the developer documentations available for Mithril. They are intended for a technical audience only.
+
+:::
+
+:::tip
+
+For more information about the **Mithril Protocol**, please refer to the [About Mithril](../../mithril/intro.md) section.
+
+:::
+
+## REST API References
+
+* [**Mithril Aggregator - API Reference** :link:](/aggregator-api):
+
+> the node of the **Mithril Network** responsible for collecting individual signatures from the **Mithril Signers** and aggregate them into a multisignature. The **Mithril Aggregator** uses this ability to provide certified snapshots of the **Cardano** blockchain.
+
+## Rust Dependencies References
+
+* [**Mithril Aggregator - Rust Documentation** :link:](https://mithril.network/mithril-aggregator/doc/mithril_aggregator/index.html):
+
+> the node of the **Mithril Network** responsible for collecting individual signatures from the **Mithril Signers** and aggregate them into a multisignature. The **Mithril Aggregator** uses this ability to provide certified snapshots of the **Cardano** blockchain.
+
+* [**Mithril Client - Rust Documentation** :link:](https://mithril.network/mithril-client/doc/mithril_client/index.html)
+
+> the node of the **Mithril Network** responsible for restoring the **Cardano** blockchain on an empty node from a certified snapshot.
+
+* [**Mithril Common - Rust Documentation** :link:](https://mithril.network/mithril-common/doc/mithril_common/index.html)
+
+> this is the **common** library that is used by the **Mithril Network** nodes.
+
+* [**Mithril Core - Rust Documentation** :link:](https://mithril.network/mithril-core/doc/mithril/index.html)
+
+> the **core** library that implements **Mithril** protocol cryptographic engine.
+
+* [**Mithril Signer - Rust Documentation** :link:](https://mithril.network/mithril-signer/doc/mithril_signer/index.html)
+
+> the node of the **Mithril Network** responsible for producing individual signatures that are collected and aggregated by the **Mithril Aggregator**.

docs/root/mithril/core-concepts/mithril-protocol.md

@@ -41,8 +41,6 @@ certificate. In which case the parameters can be adapted.
 
 > Question: How is this set defined? How are parties identified by all other parties? Should be some known set of parties identified by their keys?
 
-![](images/mithril_signature.png)
-
 ## Protocol Establishment Phase
 
 * Select/fix a prime order group to be used as basis for multi-signature scheme
@@ -87,21 +85,21 @@ a quorum of `k` valid signatures must be submitted.
 * For every valid signature, it creates a proof (π) containing a signature of the message, verification key, stake and
   paths of party in the merkle-tree.
 * Then, multiple signatures can be aggregated together to form a certificate (τ) by:
-    * Verifying signatures from each party:
-        * Checking the party is authorised to sign for the given index (using the same procedure as the signing)
-        * Checking the proof is valid which means:
-            * Check the evaluation threshold is correct for party’s stake given the message, index and signature
-            * Check the provided path exists in the aggregate keys' Merkle-tree
-            * Verify the signature of the message is valid w.r.t to verification key
-    * Producing an aggregation key from all verification keys
-    * Producing an aggregate signature from all signatures μ
-    * Producing a proof using the aggregate keys, the message and the vector of individual proofs from each party:
-        * In the concatenation proof system all these values are simply packed together to form the proof,
-        * In the case of _bulletproof_ system, a more compact proof is generated.
+  * Verifying signatures from each party:
+    * Checking the party is authorised to sign for the given index (using the same procedure as the signing)
+    * Checking the proof is valid which means:
+      * Check the evaluation threshold is correct for party’s stake given the message, index and signature
+      * Check the provided path exists in the aggregate keys' Merkle-tree
+      * Verify the signature of the message is valid w.r.t to verification key
+  * Producing an aggregation key from all verification keys
+  * Producing an aggregate signature from all signatures μ
+  * Producing a proof using the aggregate keys, the message and the vector of individual proofs from each party:
+    * In the concatenation proof system all these values are simply packed together to form the proof,
+    * In the case of _bulletproof_ system, a more compact proof is generated.
 * Each certificate τ can be verified to be valid for some message, using the known setup parameters to verify the
   certificate’s proof and then verifying the aggregate signatures and verification keys.
 
 Note that if the individual signatures are broadcast to all parties, then each party can independently produce the
 certificates. In particular, the particular that performs aggregation is not required to have any particular knowledge,
 nor it is assumed to be honest. This means that _any_ third party that has access to the individual signatures can
-perform the signature aggregation. 
+perform the signature aggregation.