update title format

EeSien · May 25, 2024 · 0e0eb16 · 0e0eb16
1 parent 1f5250b
commit 0e0eb16
Show file tree

Hide file tree

Showing 5 changed files with 52 additions and 15 deletions.
diff --git a/docs/SolanaDocumention/confirmation.md b/docs/SolanaDocumention/confirmation.md
@@ -11,7 +11,7 @@ Before diving into how Solana transaction confirmation and expiration works, let
 - 什么是区块哈希
 - 简要了解历史证明（PoH）及其与区块哈希的关系
 
-## 什么是交易？
+### 什么是交易？
 
 交易由两个部分组成：消息和签名列表。交易消息是神奇发生的地方，从高层次来看，它由三个组成部分组成：
 
@@ -21,7 +21,7 @@ Before diving into how Solana transaction confirmation and expiration works, let
 
 
 
-## 事务生命周期复习
+### 事务生命周期复习
 
 以下是交易生命周期的高级视图。本文将涉及除步骤 1 和 4 之外的所有内容。
 
@@ -35,11 +35,11 @@ Before diving into how Solana transaction confirmation and expiration works, let
 
 
 
-## 什么是区块哈希？ 
+### 什么是区块哈希？ 
 
 “区块哈希”是指“插槽”的最后一个历史证明（PoH）哈希（如下所述）。由于 Solana 使用 PoH 作为可信时钟，因此交易的最近区块哈希可以被视为时间戳。
 
-## 历史证明复习
+### 历史证明复习
 
 Solana 的历史证明机制使用很长的递归 SHA-256 哈希链来构建可信时钟。
 
@@ -76,7 +76,7 @@ PoH 可以用作可信时钟，因为每个哈希必须按顺序生成。每个
 5. 但是等等：在实际处理交易之前，验证器完成了下一个块的创建并将其添加到 BlockhashQueue 中。然后验证器开始为下一个时隙生成块（验证器为 4 个连续时隙生成块）
 6. 验证器再次检查同一笔交易，发现它现在有 152 个区块哈希值旧，并拒绝它，因为它太旧了:(
 
-### 为什么交易会过期？ 
+## 为什么交易会过期？ 
 
 实际上，这样做有一个很好的理由，它是为了帮助验证者避免处理同一笔交易两次。
 

diff --git a/docs/SolanaDocumention/lookup-tables.md b/docs/SolanaDocumention/lookup-tables.md
@@ -109,7 +109,7 @@ for (let i = 0; i < lookupTableAccount.state.addresses.length; i++) {
 
 
 
-## 如何在事务中使用地址查找表
+## 如何在交易中使用地址查找表
 
 创建查找表并将所需地址存储在链上（通过扩展查找表）后，您可以创建 v0 交易以利用链上查找功能。
 
@@ -152,6 +152,10 @@ console.log(
 >
 > 注意：将 VersionedTransaction 发送到集群时，必须在调用 sendAndConfirmTransaction 方法之前对其进行签名。如果您传递签名者数组（就像旧交易一样），该方法将触发错误！
 
+## 更多资源
+
+- 阅读 [提案](https://docs.solanalabs.com/proposals/versioned-transactions)  了解地址查找表和版本化事务
+- [使用地址查找表的 Rust 程序示例](https://github.com/TeamRaccoons/address-lookup-table-multi-swap)
 
 
 ## 地址查找表的应用

diff --git a/docs/SolanaDocumention/retry.md b/docs/SolanaDocumention/retry.md
@@ -82,7 +82,7 @@ RPC节点通过sendTransaction接收到交易后，会将交易转换为UDP数
 
 虽然 RPC 节点会尝试重新广播事务，但它们采用的算法是通用的，并且通常不适合特定应用程序的需求。为了应对网络拥塞，应用程序开发人员应该定制自己的重播逻辑。
 
-## 深入了解 sendTransaction
+### 深入了解 sendTransaction
 
 当涉及到提交事务时，sendTransaction RPC 方法是开发人员可用的主要工具。 sendTransaction 只负责将事务从客户端中继到 RPC 节点。如果节点收到交易，sendTransaction 将返回可用于跟踪交易的交易 id。成功的响应并不表明事务是否将由集群处理或完成。
 
@@ -95,7 +95,7 @@ RPC节点通过sendTransaction接收到交易后，会将交易转换为UDP数
   - (optional) `encoding`: `string` - Encoding used for the transaction data. Either "base58" (slow), or "base64". (default: "base58").（可选）编码：字符串 - 用于交易数据的编码。 “base58”（慢）或“base64”。 （默认值：“base58”）。
   - (optional) `maxRetries`: `usize` -  RPC 节点重试向领导者发送事务的最大次数。如果未提供此参数，RPC 节点将重试交易，直到交易完成或区块哈希过期。
 
-### 返回值:
+**返回值:**
 
 - `transaction id`: `string` -  嵌入交易中的第一个交易签名，作为 base-58 编码的字符串。此事务 ID 可以与 getSignatureStatuses 一起使用来轮询状态更新。
 
@@ -170,7 +170,7 @@ const sleep = async (ms: number) => {
 
 
 
-## 跳过预检的成本
+### 跳过预检的成本
 
 默认情况下，sendTransaction 将在提交交易之前执行三项预检检查。具体来说，sendTransaction 将：
 
@@ -180,7 +180,7 @@ const sleep = async (ms: number) => {
 
 如果这三个预检检查中的任何一个失败，sendTransaction 将在提交交易之前引发错误。预检检查通常是丢失事务和允许客户端优雅地处理错误之间的区别。为了确保解决这些常见错误，建议开发人员将skipPreflight 设置为false。
 
-## 何时重新签署交易
+### 何时重新签署交易
 
 尽管尝试了重播，但有时可能会要求客户端重新签署交易。在重新签署任何交易之前，确保初始交易的区块哈希已过期非常重要。如果初始区块哈希仍然有效，则两笔交易都有可能被网络接受。对于最终用户来说，这看起来就像他们无意中发送了同一笔交易两次。
 

diff --git a/docs/SolanaDocumention/state-compression.md b/docs/SolanaDocumention/state-compression.md
@@ -28,7 +28,7 @@ Solana 的状态压缩使用了一种特殊类型的默克尔树，它允许对
 
 这种特殊的树，被称为“并发默克尔树”，有效地在链上保留了树的“变更日志”。在证明失效之前，允许对同一棵树进行多次快速更改（即所有更改都在同一块中）。
 
-## 什么是默克尔树？ 
+### 什么是默克尔树？ 
 
 Merkle 树，有时称为“哈希树”，是一种基于哈希的二叉树结构，其中每个叶节点都表示为其内部数据的加密哈希。每个不是叶子的节点（称为分支）都表示为其子叶子哈希的哈希。
 
@@ -42,7 +42,7 @@ Merkle 树，有时称为“哈希树”，是一种基于哈希的二叉树结
 >
 > 使用 Merkle 树时，更改叶数据和计算新的根哈希的过程可能是非常常见的事情！虽然它是树的设计点之一，但它可能导致最显着的缺点之一：快速变化。
 
-## 什么是并发默克尔树？ #
+### 什么是并发默克尔树？ #
 
 运行时内，验证器可以相对快速地连续接收更改链上传统 Merkle 树的请求（例如在同一槽内）。每个叶子数据更改仍需要串行执行。由于根哈希和证明被槽中的先前更改请求无效，导致每个后续更改请求失败。
 
@@ -52,7 +52,7 @@ Merkle 树，有时称为“哈希树”，是一种基于哈希的二叉树结
 
 当验证器在同一槽中接收到多个叶数据更改请求时，链上并发默克尔树可以使用此“更改日志缓冲区”作为更可接受的证明的事实来源。有效地允许在同一槽中对同一棵树进行最多 maxBufferSize 的更改。显着提高吞吐量。
 
-## 调整并发默克尔树的大小
+### 调整并发默克尔树的大小
 
 创建这些链上树之一时，有 3 个值将决定树的大小、创建树的成本以及树的并发更改数量：
 
@@ -138,7 +138,7 @@ canopyDepth 值也是创建树时的主要成本因素，因为您将在创建
 
 一旦计算出所需的空间（以字节为单位），并使用 getMinimumBalanceForRentExemption RPC 方法，请求在链上分配此字节数的成本（以 lamports 为单位）。
 
-#### 在 JavaScript 中计算树成本
+### 在 JavaScript 中计算树成本
 
 在 @solana/spl-account-compression 包中，开发人员可以使用 getConcurrentMerkleTreeAccountSize 函数来计算给定树大小参数所需的空间。
 

diff --git a/docs/SolanaDocumention/versions.md b/docs/SolanaDocumention/versions.md
@@ -25,6 +25,33 @@ Solana 运行时支持两种事务版本：
 
 ## 如何设置最大支持版本
 
+您可以使用 @solana/web3.js 库和直接向 RPC 端点发送 JSON 格式的请求来设置 maxSupportedTransactionVersion。
+
+
+### 使用 web3.js
+
+Using the [`@solana/web3.js`](https://solana-labs.github.io/solana-web3.js/)
+library, you can retrieve the most recent block or get a specific transaction:
+
+```js
+// connect to the `devnet` cluster and get the current `slot`
+const connection = new web3.Connection(web3.clusterApiUrl("devnet"));
+const slot = await connection.getSlot();
+
+// get the latest block (allowing for v0 transactions)
+const block = await connection.getBlock(slot, {
+  maxSupportedTransactionVersion: 0,
+});
+
+// get a specific transaction (allowing for v0 transactions)
+const getTx = await connection.getTransaction(
+  "3jpoANiFeVGisWRY5UP648xRXs3iQasCHABPWRWnoEjeA93nc79WrnGgpgazjq4K9m8g2NJoyKoWBV1Kx5VmtwHQ",
+  {
+    maxSupportedTransactionVersion: 0,
+  },
+);
+```
+### JSON requests to the RPC
 使用标准 JSON 格式的 POST 请求，您可以在检索特定块时设置 maxSupportedTransactionVersion：
 
 ```bash
@@ -121,4 +148,10 @@ let blockhash = await connection
    console.log(`https://explorer.solana.com/tx/${txId}?cluster=devnet`);
    ```
 
-
+## 更多资源
+
+- 使用 [地址查找表的版本化事务](./lookup-tables.md)
+- 在solana浏览器查看 [ v0 交易的示例](https://explorer.solana.com/tx/h9WQsqSUYhFvrbJWKFPaXximJpLf6Z568NW1j6PBn3f7GPzQXe9PYMYbmWSUFHwgnUmycDNbEX9cr6WjUWkUFKx/?cluster=devnet)
+
+- 阅读已接受的版本化交易和地址查找表 [提案](https://docs.solanalabs.com/proposals/versioned-transactions)
+