Fixed format issues and chanegd the images routes

docs/Architecture/Core/Implementation.md

@@ -1,6 +1,12 @@
+---
+sidebar_position: 2
+title: Implementations
+description: Implementations
+---
+
 # Design Principles
 
-![image](node-archi.png)
+![image](../../../static/img/node-archi.png)
 
 The diagram above shows the conceptual structure of the node and the separation between the OS and Kernel.
 

docs/Architecture/Core/Introduction.md

@@ -1,3 +1,9 @@
+---
+sidebar_position: 1
+title: Introduction
+description: Introduction
+---
+
 # Application Pattern
 
 We follow generally accepted good practices in programming, especially those that align with our project needs. Some of these practices are specific to C#, while others pertain to general Object-Oriented Programming (OOP) principles like **SOLID** and **DRY**.

docs/Architecture/Cross Chain/Architecture.md

@@ -1,3 +1,9 @@
+---
+sidebar_position: 2
+title: Architecture
+description: Architecture
+---
+
 # Side Chain and Main Chain Node Documentation
 
 ## Overview
@@ -17,7 +23,7 @@ Through this link, messages are exchanged, and indexing is performed to ensure t
 
 In the current architecture, both the side chain node and the main chain node have one server and exactly one client. This forms the basis for AElf's two-way communication between the main chain and side chains. Both the server and the client are implemented as node plugins (a node has a collection of plugins). Interaction (listening and requesting) can start once both nodes are running.
 
-![Node Level Architecture](side-chain-nodes.png)
+![Node Level Architecture](../../../static/img/side-chain-nodes.png)
 
 The diagram above illustrates two nodes run by an entity: one main chain node and one side chain node. Note that the nodes don't have to be in the same physical location.
 
@@ -58,4 +64,4 @@ Apart from the data in blocks, most cross-chain data will be stored by the cross
 
 Conceptually, the node operates as described in the following diagram. The main/side chain node receives cross-chain data from the other side and stores it in local memory. The indexing transaction is packed by the miner, and the cross-chain data is written into the `State` through the `Crosschain Contract`.
 
-![Data Flow](architecture-node.png)
+![Data Flow](../../../static/img/architecture-node.png)

docs/Architecture/Cross Chain/Cross Chain Transfer.md

@@ -1,8 +1,15 @@
+---
+sidebar_position: 5
+title: Crosschain Transfer
+description: Crosschain Transfer
+---
+
 # Cross Chain Transfer
 
 Cross chain transfer is one of the most commonly used cases when it comes to cross chain verification. AElf already supports cross chain transfer functionality in its contract. This section will explain how to transfer tokens across chains. It assumes a side chain is already deployed and has been indexed by the main chain.
 
 The transfer process will always use the same contract methods and follow these two steps:
+
 - **Initiate the transfer**
 - **Receive the tokens**
 
@@ -14,65 +21,65 @@ Let's say you want to transfer token **FOO** from chain **A** to chain **B**. Be
 
 - **Validate `Token Contract` address on chain A**
 
-   Send transaction `tx_1` to the `Genesis Contract` with the method `ValidateSystemContractAddress`. You need to provide `system_contract_hash_name` and the address of the `Token Contract`. `tx_1` should be successfully packed in the block.
+  Send transaction `tx_1` to the `Genesis Contract` with the method `ValidateSystemContractAddress`. You need to provide `system_contract_hash_name` and the address of the `Token Contract`. `tx_1` should be successfully packed in the block.
 
-   ```protobuf
-   rpc ValidateSystemContractAddress(ValidateSystemContractAddressInput) returns (google.protobuf.Empty){}
+  ```protobuf
+  rpc ValidateSystemContractAddress(ValidateSystemContractAddressInput) returns (google.protobuf.Empty){}
 
-   message ValidateSystemContractAddressInput {
-       aelf.Hash system_contract_hash_name = 1;
-       aelf.Address address = 2;
-   }
-   ```
+  message ValidateSystemContractAddressInput {
+      aelf.Hash system_contract_hash_name = 1;
+      aelf.Address address = 2;
+  }
+  ```
 
 - **Register the token contract address of chain A on chain B**
 
-   Create a proposal for the `RegisterCrossChainTokenContractAddress` for the default parliament organization on chain B. Refer to the [Parliament contract documentation](../../reference/smart-contract-api/parliament) for more details. Apart from cross chain verification context, you also need to provide the origin data of `tx_1` and the `Token Contract` address on chain A.
+  Create a proposal for the `RegisterCrossChainTokenContractAddress` for the default parliament organization on chain B. Refer to the [Parliament contract documentation](../../reference/smart-contract-api/parliament) for more details. Apart from cross chain verification context, you also need to provide the origin data of `tx_1` and the `Token Contract` address on chain A.
 
-   ```protobuf
-   rpc RegisterCrossChainTokenContractAddress (RegisterCrossChainTokenContractAddressInput) returns (google.protobuf.Empty) {}
+  ```protobuf
+  rpc RegisterCrossChainTokenContractAddress (RegisterCrossChainTokenContractAddressInput) returns (google.protobuf.Empty) {}
 
-   message RegisterCrossChainTokenContractAddressInput {
-       int32 from_chain_id = 1;
-       int64 parent_chain_height = 2;
-       bytes transaction_bytes = 3;
-       aelf.MerklePath merkle_path = 4;
-       aelf.Address token_contract_address = 5;
-   }
-   ```
+  message RegisterCrossChainTokenContractAddressInput {
+      int32 from_chain_id = 1;
+      int64 parent_chain_height = 2;
+      bytes transaction_bytes = 3;
+      aelf.MerklePath merkle_path = 4;
+      aelf.Address token_contract_address = 5;
+  }
+  ```
 
 - **Validate `TokenInfo` of FOO on chain A**
 
-   Send transaction `tx_2` to the `Token Contract` with the method `ValidateTokenInfoExists` on chain A. You need to provide `TokenInfo` of FOO. `tx_2` should be successfully packed in the block.
+  Send transaction `tx_2` to the `Token Contract` with the method `ValidateTokenInfoExists` on chain A. You need to provide `TokenInfo` of FOO. `tx_2` should be successfully packed in the block.
 
-   ```protobuf
-   rpc ValidateTokenInfoExists(ValidateTokenInfoExistsInput) returns (google.protobuf.Empty){}
+  ```protobuf
+  rpc ValidateTokenInfoExists(ValidateTokenInfoExistsInput) returns (google.protobuf.Empty){}
 
-   message ValidateTokenInfoExistsInput {
-       string symbol = 1;
-       string token_name = 2;
-       int64 total_supply = 3;
-       int32 decimals = 4;
-       aelf.Address issuer = 5;
-       bool is_burnable = 6;
-       int32 issue_chain_id = 7;
-   }
-   ```
+  message ValidateTokenInfoExistsInput {
+      string symbol = 1;
+      string token_name = 2;
+      int64 total_supply = 3;
+      int32 decimals = 4;
+      aelf.Address issuer = 5;
+      bool is_burnable = 6;
+      int32 issue_chain_id = 7;
+  }
+  ```
 
 - **Create token FOO on chain B**
 
-   Send transaction `tx_3` to the `Token Contract` with the method `CrossChainCreateToken` on chain B. You need to provide the origin data of `tx_2` and the cross chain verification context of `tx_2`.
+  Send transaction `tx_3` to the `Token Contract` with the method `CrossChainCreateToken` on chain B. You need to provide the origin data of `tx_2` and the cross chain verification context of `tx_2`.
 
-   ```protobuf
-   rpc CrossChainCreateToken(CrossChainCreateTokenInput) returns (google.protobuf.Empty) {}
+  ```protobuf
+  rpc CrossChainCreateToken(CrossChainCreateTokenInput) returns (google.protobuf.Empty) {}
 
-   message CrossChainCreateTokenInput {
-       int32 from_chain_id = 1;
-       int64 parent_chain_height = 2;
-       bytes transaction_bytes = 3;
-       aelf.MerklePath merkle_path = 4;
-   }
-   ```
+  message CrossChainCreateTokenInput {
+      int32 from_chain_id = 1;
+      int64 parent_chain_height = 2;
+      bytes transaction_bytes = 3;
+      aelf.MerklePath merkle_path = 4;
+  }
+  ```
 
 ## Initiate the Transfer
 
@@ -82,23 +89,23 @@ On the token contract of the source chain, the `CrossChainTransfer` method is us
 rpc CrossChainTransfer (CrossChainTransferInput) returns (google.protobuf.Empty) { }
 
 message CrossChainTransferInput {
-    aelf.Address to = 1; 
+    aelf.Address to = 1;
     string symbol = 2;
     sint64 amount = 3;
     string memo = 4;
-    int32 to_chain_id = 5; 
+    int32 to_chain_id = 5;
     int32 issue_chain_id = 6;
 }
 ```
 
 ### The fields of the input:
 
-- **to**: the target address to receive the token
-- **symbol**: the symbol of the token to be transferred
-- **amount**: the amount of the token to be transferred
-- **memo**: a memo field for this transfer
-- **to_chain_id**: the destination chain ID where the tokens will be received
-- **issue_chain_id**: the chain ID where the token was issued
+- `to`: the target address to receive the token
+- `symbol`: the symbol of the token to be transferred
+- `amount`: the amount of the token to be transferred
+- `memo`: a memo field for this transfer
+- `to_chain_id`: the destination chain ID where the tokens will be received
+- `issue_chain_id`: the chain ID where the token was issued
 
 ## Receive on the Destination Chain
 
@@ -126,13 +133,13 @@ message CrossChainMerkleProofContext {
 
 ### The fields of the input:
 
-- **from_chain_id**: the source chain ID from which the cross chain transfer was launched
+- `from_chain_id`: the source chain ID from which the cross chain transfer was launched
 
-- **parent_chain_height**: the height of the block on the main chain that contains the `CrossChainTransfer` transaction (for main chain to side chain transfer). For side chain to side chain or side chain to main chain transfer, it is the result of `GetBoundParentChainHeightAndMerklePathByHeight` (input is the height of the `CrossChainTransfer`), accessible in the `bound_parent_chain_height` field.
+- `parent_chain_height`: the height of the block on the main chain that contains the `CrossChainTransfer` transaction (for main chain to side chain transfer). For side chain to side chain or side chain to main chain transfer, it is the result of `GetBoundParentChainHeightAndMerklePathByHeight` (input is the height of the `CrossChainTransfer`), accessible in the `bound_parent_chain_height` field.
 
-- **transfer_transaction_bytes**: the serialized form of the `CrossChainTransfer` transaction.
+- `transfer_transaction_bytes`: the serialized form of the `CrossChainTransfer` transaction.
 
-- **merkle_path**: obtained from the source chain. The construction of merkle path data differs among cases:
+- `merkle_path`: obtained from the source chain. The construction of merkle path data differs among cases:
   - **Main chain to side chain transfer**: merkle path from the main chain’s web API `GetMerklePathByTransactionIdAsync` (with `CrossChainTransfer` transaction ID as input).
   - **Side chain to side chain or side chain to main chain transfer**:
     - merkle path from the source chain’s web API `GetMerklePathByTransactionIdAsync` (with `CrossChainTransfer` transaction ID as input).

docs/Architecture/Cross Chain/Cross Chain Verification.md

@@ -0,0 +1,45 @@
+---
+sidebar_position: 3
+title: Crosschain Verification
+description: Crosschain Verification
+---
+
+# Cross Chain Verification
+
+Verification is the key feature that enables side chains. Because side chains do not have direct knowledge about other side chains, they need a way to verify information from other chains. Side chains need the ability to verify that a transaction was included in another side chain's block.
+
+## Indexing
+
+- The role of the main chain node is to index all the side chains' blocks.
+  - This way, it knows exactly the current state of all the side chains.
+  - Side chains also index main chain blocks, which is how they gain knowledge about the inclusion of transactions in other chains.
+- Indexing is a continuous process:
+  - The main chain permanently gathers information from the side chains.
+  - The side chains permanently gather information from the main chain.
+- When a side chain wants to verify a transaction from another side chain, it must wait until the correct main chain block has been indexed.
+
+## Merkle Tree
+
+- A Merkle tree is a basic binary tree structure.
+  - For cross-chain in AElf, the leaf value is the hash from transaction data.
+  - The node value (which is not a leaf node) is the hash calculated from its children's values up to the tree root.
+
+![Merkle Tree](../../../static/img/merkle.png)
+
+## Merkle Root
+
+- When a transaction is included in a side chain's block, the block will also include a Merkle root of the transactions in this block.
+  - This root is local to this side chain's blockchain and, by itself, of little value to other side chains because they follow a different protocol.
+  - Communication between side chains goes through the main chain in the form of a Merkle path.
+  - During the indexing process, the main chain calculates the root with the data from side chains, and side chains in turn get the root in future indexing.
+  - This root is used for the final check in cross-chain transaction verification.
+
+## Merkle Path
+
+- A Merkle path is the node collection for one leaf node to calculate to the root.
+  - A correct Merkle path is necessary to complete any work related to cross-chain verification.
+- For the transaction **tx** from chain **A**:
+  - You need the whole Merkle path root for **tx** to calculate the final root if you want to verify the existence of this transaction on other chains.
+  - Verify the root by checking whether it is equal to the one obtained from indexing before.
+
+![Merkle Path](../../../static/img/merkle-path.png)

docs/Architecture/Cross Chain/Introduction.md

@@ -1,20 +1,29 @@
+---
+sidebar_position: 1
+title: Introduction
+description: Introduction
+---
+
 # Introduction
 
 One of the major issues with current blockchain systems is scalability. This is mainly due to **congestion problems** in existing blockchains. The core problem is that when a single chain needs to sequentially order and process transactions, a popular dApp consuming a lot of resources can negatively impact other dApps.
 
 To address this issue, AElf introduced side chains in its initial design. The concept is that each side-chain handles one or more similar business scenarios, distributing different tasks across multiple chains to improve overall processing efficiency.
 
 ## Key Points:
+
 - **Independent and Specialized**: Side-chains are designed to be independent and specialized, ensuring that the dApps running on them perform efficiently and smoothly.
 - **Network Link**: There is a network link between the main-chain node and side-chain nodes, with communication indirectly facilitated through a Merkle root.
 
-![image](introduction-topology.png)
+![image](../../../static/img/introduction-topology.png)
 
-*The diagram above illustrates the conceptual idea behind side chains.*
+_The diagram above illustrates the conceptual idea behind side chains._
 
 Side chains are isolated but still need a way to interact with each other. To enable cross-chain verification scenarios, AElf introduces a communication mechanism through **Merkle roots** and **indexing**.
 
 ## Overview
+
 The following sections of this documentation will provide:
+
 - An overview of the architecture of AElf's side chains.
 - A guide explaining how to set up a main-chain and a side chain node.

docs/Architecture/Cross Chain/Verify.md

@@ -1,3 +1,9 @@
+---
+sidebar_position: 4
+title: Verify
+description: Verify
+---
+
 # Cross Chain Transaction Verification
 
 This section provides guidance on verifying transactions across different blockchain chains, assuming that a side chain has already been deployed and indexed by the main chain.
@@ -28,7 +34,7 @@ message VerifyTransactionInput {
 
 The **VerifyTransaction** method is used for verification and returns whether the transaction was mined and indexed by the destination chain. The method is the same for both scenarios; only the input values differ.
 
-### Verifying a Main Chain Transaction
+## Verifying a Main Chain Transaction
 
 To verify a main chain transaction on a side chain, use the **VerifyTransaction** method on the side chain with the following input values:
 
@@ -39,7 +45,7 @@ To verify a main chain transaction on a side chain, use the **VerifyTransaction*
 
 You can retrieve the Merkle path of a transaction in a block by using the chain's API method **GetMerklePathByTransactionIdAsync**.
 
-### Verifying a Side Chain Transaction
+## Verifying a Side Chain Transaction
 
 For verifying a side chain transaction: