Merge pull request #268 from massalabs/fix-svg

fix names

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.

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

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)