rewrite the learn docs

docs/website/pages/_meta.en-US.json

@@ -55,5 +55,15 @@
       "timestamp": false,
       "typesetting": "article"
     }
+  },
+  "archives": {
+    "type": "page",
+    "display": "hidden",
+    "theme": {
+      "sidebar": false,
+      "timestamp": false,
+      "typesetting": "article"
+    },
+    "title":"Archives"
   }
 }

docs/website/pages/archives/multi-chain-settlement/_meta.en-US.json

@@ -0,0 +1,14 @@
+{
+  "multi-chain-settlement": {
+    "title": "Multi-Chain Settlement",
+    "display": "hidden"
+  },
+  "l1-to-l2-messaging": {
+    "title": "L1 to L2 Messaging",
+    "display": "hidden"
+  },
+  "l2-to-l1-messaging": {
+    "title": "L2 to L1 Messaging",
+    "display": "hidden"
+  }
+}

docs/website/pages/learn/in-depth-tech/session-key.en-US.mdx → docs/website/pages/archives/session-key.en-US.mdx

@@ -1,20 +1,14 @@
 # Session key
 
-## What is the session key?
-
 Rooch's Session Key is a temporary key that facilitates users to interact with the chain.
 
-## What is the session key used for?
-
 When interacting with Rooch applications, each application generates a session key. It has an expiration time and will become invalid if there is no interaction for a long time.
 
 The purpose of the session key is to simplify the interaction process between the wallet and the DApp. The session key is generated during the first interaction. As long as the session key has not expired in subsequent operations, the DApp does not need to call the wallet again for signature.
 
-## Advantage
-
 Rooch's session keys provide several advantages:
 
-1. Shorten the complicated signing steps of chain game interaction. Taking the 2048 mini-game as an example, each step needs to send a transaction to the chain. The client will frequently call the wallet to sign, which is a very time-consuming process. Some wallets may use a delegation agent, which means prepaying a portion of Gas, and when the budgeted Gas is exhausted, a one-time signature transaction will be uploaded to the chain. This form of custody involves financial risks and game cheating. When using a session key, you only need to sign a transaction once when you start the game. During subsequent game executions, as long as the session key has not expired, the Rooch system will automatically sign the transaction on the chain at each step.
+1. Shorten the complicated signing steps of chain interaction. Taking the 2048 mini-game as an example, each step needs to send a transaction to the chain. The client will frequently call the wallet to sign, which is a very time-consuming process. Some wallets may use a delegation agent, which means prepaying a portion of Gas, and when the budgeted Gas is exhausted, a one-time signature transaction will be uploaded to the chain. This form of custody involves financial risks and game cheating. When using a session key, you only need to sign a transaction once when you start the game. During subsequent game executions, as long as the session key has not expired, the Rooch system will automatically sign the transaction on the chain at each step.
 2. Provide better permission management. Which functions can be used for different account addresses can be determined when signing for the first time.
 3. It is more user-friendly and provides end users with the same smooth experience using Web3 as Web2.
 

docs/website/pages/learn/_meta.en-US.json

@@ -1,9 +1,8 @@
 {
-  "introduction": "Introduction",
-  "architecture": "Architecture",
+  "welcome": "Welcome",
+  "overview": "Overview",
+  "in-depth-tech": "In-Depth Tech",
   "core-concepts": "Core Concepts",
-  "in-depth-tech": "In-Depth-Tech",
-  "user-guides": "User guides",
-  "contribution-guides": "Contributing Guides",
-  "miscellaneous": "Miscellaneous"
+  "miscellaneous": "Miscellaneous",
+  "contribution-guides": "Contributing Guides"
 }

docs/website/pages/learn/_meta.zh-CN.json

@@ -1,6 +1,6 @@
 {
   "introduction": "简介",
-  "architecture": "架构",
+  "rooch": "Rooch",
   "core-concepts": "核心概念",
   "in-depth-tech": "深入技术",
   "user-guides": "用户指南",

docs/website/pages/learn/core-concepts/_meta.en-US.json

@@ -3,7 +3,6 @@
   "transaction": "Transaction",
   "objects": "Object",
   "move-contracts": "Move concepts",
-  "client-side-validation": "Client-side Validation",
   "token": {
     "title": "Token",
     "display": "hidden"

docs/website/pages/learn/in-depth-tech/_meta.en-US.json

@@ -1,18 +1,8 @@
 {
-  "fraud-proof": "Fraud Proof",
-  "hybrid-security": "Hybrid Security with ZK Proof",
-  "multi-chain-settlement": "Multi-Chain Settlement",
-  "on-chain-indexer": {
-    "title": "On-chain Indexer",
-    "display": "hidden"
-  },
-  "decentralized-validator": "Decentralized validator",
+  "client-side-validation": "Client-Side Validation",
+  "dstp":"DSTP",
   "pipeline-transaction-processing": "Pipeline Transaction Processing",
+  "decentralized-validator": "Decentralized validator",
   "sequence-proof": "Sequence Proof",
-  "hash": "Hash",
-  "session-key": "Session key",
-  "p2p-state-channel": {
-    "title": "P2P Channel",
-    "display": "hidden"
-  }
+  "security": "Security"
 }

docs/website/pages/learn/core-concepts/client-side-validation.en-US.mdx → docs/website/pages/learn/in-depth-tech/client-side-validation.en-US.mdx

@@ -1,4 +1,4 @@
-# Client-side Validation Protocol
+# Client-Side Validation Protocol
 
 The [Client Validation Protocol][1], a concept proposed by the developers of the Bitcoin ecosystem, allow a Bitcoin transaction to commit to some data whose validity is determined separate from the validity of the transaction under Bitcoin’s consensus rules. Assets created under this protocol use Bitcoin only to ensure asset ownership and prevent double-spending, while the validity of the assets is verified off-chain. In the following text, we refer to client-side validation simply as "CSV."
 
@@ -96,7 +96,7 @@ Notes:
 1. This process is simplified and does not account for scenarios where a user's transaction fails to get on-chain, requiring asset recovery.
 2. During asset leap, the asset container is destroyed, so the container's ID cannot be guaranteed consistent, necessitating an internal business ID to identify the asset.
 
-### Reference
+## Reference
 
 - [Client-side validation protocols][1] from bitcoinops.org
 - [Client side validation][2] from rgb.info

docs/website/pages/learn/in-depth-tech/decentralized-validator.en-US.mdx

@@ -23,3 +23,11 @@ The initial design idea is as follows.
 2. Each Epoch, the smart contract on the chain randomly selects a validator as a sequencer.
 3. Nodes that are not selected as sequencer automatically become verifier.
 4. All the verifiers form a P2P network, and the transactions received by the verifier will be forwarded to the sequencer. The Sequencer will then verify and order all the transactions, as well as forward them to the other verifiers with the State Tree Root and the [Sequence Proof](/docs/tech-highlights/sequence-proof).
+
+## Sequencer Rotation Mechanism based on Bitcoin Timestamp
+
+To do
+
+## Sharded Application Subnet
+
+To do

docs/website/pages/learn/in-depth-tech/dstp.en-US.mdx

@@ -0,0 +1,3 @@
+# Distributed State Tree protocol (DSTP)
+
+to do

docs/website/pages/learn/in-depth-tech/pipeline-transaction-processing.en-US.mdx

@@ -4,7 +4,7 @@ Optimizing the transaction processing procedure and related components is the ke
 
 ![Diagram](/docs/pipeline-transaction-processing.png)
 
-The role of Sequencer and Proposer are decoupled into two different nodes:
+The role of Sequencer and Proposer are decoupled into two different processes:
 
 - Sequencer is mainly responsible for verifying and ordering all the incoming transactions; the output is formed as a transaction stream, which will then be sent to the Proposer
 - Proposer is responsible for executing all the transactions received from Sequencers, as well packing transactions into blocks and calculating the final state for each block

docs/website/pages/learn/in-depth-tech/fraud-proof.en-US.mdx → docs/website/pages/learn/in-depth-tech/security.en-US.mdx

@@ -1,8 +1,8 @@
-# Fraud Proof
+# Security
 
 Rooch Network uses the Fraud Proof based on [Optimistic Rollup](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) mechanism to ensure the security of Rooch DApps.
 
-> Rooch will also support [Hybrid Security enabled by ZK Proof](./hybrid-security.en-US.mdx).
+> Rooch will also support [Hybrid Security enabled by ZK Proof](#hybrid-security-with-zk-proof) as part of the future fowkr.
 
 ## flexEmu - A General Purpose Emulator with Per-Step Proof
 
@@ -47,3 +47,29 @@ flexEmu is designed to be a general purpose bytecode emulator with per-step stat
   Any Layer1 that supports MIPS operation code set will be able to arbitrate proofs generated by flexEmu. This enables Rooch to be Layer2 for arbitrary Layer1s.
 - **Easy for Maintenance, Debugging and Upgrades**
   If there are any major upgrades to MoveVM in the future, flexEmu can quickly accommodate them.
+
+## Hybrid Security with ZK Proof
+
+> This is a future work of the Rooch project and is not integrated in the current roadmap
+
+Rooch will leverage [zkMove](https://www.zkmove.net/) to generate ZK Proof for optimizing the challenge period of the Fraud Proof mechanism, and create a Hybrid Security mechanism with both Fraud Proof and ZK Proof.
+
+> [zkMove](https://www.zkmove.net/) is a zero-knowledge Move language runtime environment that realizes bytecode level compatibility. Rooch Network has a partnership with zkMove and the two projects will collaborate in terms of technology development as well as application scenarios.
+
+### How it works
+
+<Image
+  src="/docs/hybrid-security.png"
+  alt="Rooch Architecture"
+  width={600}
+  height={600}
+  className="mx-auto my-2"
+/>
+
+With only Fraud Proof, a user's withdraw transaction submitted at `BlockT` needs to wait for a challenge period of `N` blocks to reach finality, and only after this the user can withdraw its asset on Layer1.
+
+With ZK Proof generated by ZK Prover using zkMove, the challenge period can be optimized to a much lower amount of blocks. Here's how it works:
+
+- The proposer keeps committing blocks of state to Layer1 at its maxmium speed
+- ZK Prover generate ZK Proofs for the state blocks that have been committed to the Layer1, at a relatively slower pace, due to the considerably long proof generation time
+- For the withdraw transaction submitted at `BlockT`, it can be considered finalized when the ZK Proof of `BlockT` has been generated and verified on Layer1, instead of waiting to reach the end of the whole challenge period