diff --git a/docs/learn/architecture/architecture.drawio.svg b/docs/learn/architecture/architecture.svg similarity index 100% rename from docs/learn/architecture/architecture.drawio.svg rename to docs/learn/architecture/architecture.svg diff --git a/docs/learn/architecture/basic-concepts.mdx b/docs/learn/architecture/basic-concepts.mdx index 24ca015d9..40d1ad5a0 100644 --- a/docs/learn/architecture/basic-concepts.mdx +++ b/docs/learn/architecture/basic-concepts.mdx @@ -22,7 +22,7 @@ enabling parallelization and improved block-creation performance. Instead of one chain, there are exactly 32 **threads** of chains running in parallel, with blocks equally spread on each thread over time, and stored inside **slots** that are spaced at fixed time intervals: -![](structure.drawio.svg) +![](structure.svg) The time between two slots located on the same thread is called a **period** and lasts 16s (conventionally called $t_0$). Corresponding slots in threads are slightly shifted in time relative to one another, by one period divided by the number @@ -41,7 +41,7 @@ In traditional blockchains, blocks are simply referencing their unique parent, f Massa, each block is referencing one parent block in each thread (so, 32 parents). Here is an example illustrated with one particular block: -![](block_parents.drawio.svg) +![](block_parents.svg) Let’s introduce some relevant definitions and concepts generally necessary to understand how the Massa network operates. We will then explain the node architecture and how the whole system works. diff --git a/docs/learn/architecture/block_parents.drawio.svg b/docs/learn/architecture/block_parents.svg similarity index 100% rename from docs/learn/architecture/block_parents.drawio.svg rename to docs/learn/architecture/block_parents.svg diff --git a/docs/learn/architecture/cliques.drawio.svg b/docs/learn/architecture/cliques.svg similarity index 100% rename from docs/learn/architecture/cliques.drawio.svg rename to docs/learn/architecture/cliques.svg diff --git a/docs/learn/architecture/incompatibility_graph.drawio.svg b/docs/learn/architecture/incompatibility_graph.svg similarity index 100% rename from docs/learn/architecture/incompatibility_graph.drawio.svg rename to docs/learn/architecture/incompatibility_graph.svg diff --git a/docs/learn/architecture/node-architecture.mdx b/docs/learn/architecture/node-architecture.mdx index 75bdb816a..73cf9c3e2 100644 --- a/docs/learn/architecture/node-architecture.mdx +++ b/docs/learn/architecture/node-architecture.mdx @@ -18,7 +18,7 @@ The pool and factories, referred to as “factory”, can be potentially running Overall, each of the modules described here runs inside one or more threads attached to their respective executable process (NB: the factory/node separation is not yet implemented, but will be soon). -![](architecture.drawio.svg) +![](architecture.svg) We will explain below the different modules present in this diagram, and simulate the production of an operation to show how it navigates through the different modules to better understand how blocks are produced and propagated. @@ -85,7 +85,7 @@ weighted by the amount of stake (=rolls) they hold. The schema below illustrates are built, based on past cycles (two cycles are needed for the distribution update to ensure that the balance finalization has occurred and the amount of rolls is accurate): -![](selector.drawio.svg) +![](selector.svg) The Selector Module is in charge of computing the formula and replying to requests regarding what node is elected for any given slot in the present or the past. The Execution Module (see below) is in charge of feeding the Selector Module with @@ -114,7 +114,7 @@ Here is a simplified example of a graph of pending blocks over two threads, with as a result of a multistaking attack where the block producer decided to create competing blocks for the same slot). Here the letter of a slot identifies it, while the number refers to its thread number: -![](unfinalized_blocks_set.drawio.svg) +![](unfinalized_blocks_set.svg) In this illustration we have shown only relevant parent links in blue, to make the whole diagram more readable, but in reality, each block has 32 parents, one in each of the 32 threads. @@ -134,7 +134,7 @@ You will find a more formal mathematical definition of these incompatibility not From these definitions, you can build another graph, called the incompatibility graph, which connects any two blocks that have any form of incompatibility together: -![](incompatibility_graph.drawio.svg) +![](incompatibility_graph.svg) As you can see, some blocks are isolated and therefore compatible with any other, while some are linked, because they have a form of incompatibility. @@ -144,7 +144,7 @@ members are incompatible with each other (so, no internal link within the clique to the set without introducing incompatibilities. In the above example, there are three maximal cliques that can be built, as illustrated below: -![](cliques.drawio.svg) +![](cliques.svg) They represent candidates to extend the set of already finalized blocks into a coherent set of new blocks. All we need to add to be able to build a consensus rule now is to introduce a deterministic metric to rank those candidates so that nodes diff --git a/docs/learn/architecture/operation-lifecycle.mdx b/docs/learn/architecture/operation-lifecycle.mdx index 4395ad83a..38405da2d 100644 --- a/docs/learn/architecture/operation-lifecycle.mdx +++ b/docs/learn/architecture/operation-lifecycle.mdx @@ -20,7 +20,7 @@ Let’s assume we just got a code execution operation from an external client. L particular node, which is running its block factory on the same machine, and sends the operation to this node. These are the different steps of the operation processing that will occur, as illustrated in the schema below: -![](operation_lifecycle.drawio.svg) +![](operation_lifecycle.svg) 1. The operation enters the node via the API Module (the operation path is marked in blue) diff --git a/docs/learn/architecture/operation_lifecycle.drawio.svg b/docs/learn/architecture/operation_lifecycle.svg similarity index 100% rename from docs/learn/architecture/operation_lifecycle.drawio.svg rename to docs/learn/architecture/operation_lifecycle.svg diff --git a/docs/learn/architecture/selector.drawio.svg b/docs/learn/architecture/selector.svg similarity index 100% rename from docs/learn/architecture/selector.drawio.svg rename to docs/learn/architecture/selector.svg diff --git a/docs/learn/architecture/structure.drawio.svg b/docs/learn/architecture/structure.svg similarity index 100% rename from docs/learn/architecture/structure.drawio.svg rename to docs/learn/architecture/structure.svg diff --git a/docs/learn/architecture/unfinalized_blocks_set.drawio.svg b/docs/learn/architecture/unfinalized_blocks_set.svg similarity index 100% rename from docs/learn/architecture/unfinalized_blocks_set.drawio.svg rename to docs/learn/architecture/unfinalized_blocks_set.svg