docs: document Stable v1.4.0

docs/pages/cn/explanation/core-concepts.mdx

@@ -1,56 +1,58 @@
 ---
 source_path: explanation/core-concepts.mdx
-source_sha: 97f2155b7916504732f1b78674bbf3ec1909e8e2
+source_sha: 45b22f6b8de51a67dbe1ed9ffb14d57302775f8c
 title: "核心概念"
-description: "在开始构建之前，请先了解 Stable 的四个核心概念：USDT0 作为燃料代币、保证块空间、转账聚合和 EVM 兼容性。"
+description: "在构建之前，请先了解 Stable 的四个核心概念：USDT0 作为燃料、有保障的区块空间、转账聚合和 EVM 兼容性。"
 diataxis: "explanation"
 ---
 
 # 核心概念
 
-掌握这四个概念足以开始构建。每个部分都定义了概念，展示了它的工作原理，并链接到完整的参考资料。
+掌握四个概念即可开始构建。每个部分都定义了概念，展示了它的作用，并链接到完整的参考资料。
 
-## USDT0 作为燃料代币
+## USDT0 作为燃料
 
-您可以使用 USDT0 支付交易费，这是您已经持有和交易的相同资产。无需为第二个代币注资或管理。
+您使用 USDT0 支付交易费用，这是您已经持有并正在交易的资产。无需资助或管理第二种代币。
 
-USDT0 既是原生燃料代币资产（18 位小数，通过 `address(x).balance` 读取），也是 ERC-20 代币（6 位小数，通过 `USDT0.balanceOf(x)` 读取）。这两个接口对相同的底层余额进行操作，协议会自动协调 12 位小数的精度差距。
+USDT0 既是原生燃料资产（18 位小数，通过 `address(x).balance` 读取），也是 ERC-20 代币（6 位小数，通过 `USDT0.balanceOf(x)` 读取）。这两个接口操作相同的底层余额，协议会自动调和 12 位小数的精度差距。
 
 ```solidity
-// Both read the same balance:
+// 两者读取相同的余额：
 uint256 native = address(user).balance;        // 18 decimals
 uint256 erc20  = IERC20(USDT0).balanceOf(user); // 6 decimals
 ```
 
 :::warning
-余额调节会在保留地址 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5` 发出额外的 `Transfer` 事件。重放 `Transfer` 事件的索引器必须过滤进出此地址的转账，否则它们将默默地重复计算余额。
+余额调和会在储备金地址 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5` 发出额外的 `Transfer` 事件。重放 `Transfer` 事件的索引器必须过滤进出该地址的转账，否则它们将无声地重复计算余额。
 :::
 
-阅读更多：[USDT0 作为燃料代币](/cn/explanation/usdt-as-gas-token) · [USDT0 在 Stable 上的行为](/cn/explanation/usdt0-behavior)。
+阅读更多：[USDT0 作为燃料](/cn/explanation/usdt-as-gas-token) · [USDT0 在 Stable 上的行为](/cn/explanation/usdt0-behavior)。
 
-## 保证块空间
+## 有保障的区块空间
 
-Stable 为预分配的企业工作负载保留了每个区块容量的一部分。即使在一般流量拥堵时，保留的流量也能以可预测的延迟和成本进行结算；它不参与费用市场竞争。
+Stable v1.4.0 可以为符合条件的优先工作负载在每个区块内预留燃气配额。在网络拥堵期间，普通流量无法消耗此 VIP 通道容量。
 
-这种行为在调用者层面是透明的。您以正常方式提交交易；分配在协议层面应用于注册账户。
+标准 EVM 交易继续使用默认的 nonce 通道，即 `NonceKey = 0`。符合条件的优先流使用 `CustomTx` 类型 `0x3F` 和协议预留的 `NonceKey`，用以识别 VIP 通道。
 
-阅读更多：[保证块空间](/cn/explanation/guaranteed-blockspace)。
+治理层配置这些通道和配额。如果没有配置，每个交易都使用一个普通通道。该功能目前处于 v1.4.0 Testnet 发布候选版本中，其主网计划待定。
+
+阅读更多：[有保障的区块空间](/cn/explanation/guaranteed-blockspace)。
 
 ## USDT 转账聚合器
 
-大批量 USDT0 转账通过 MapReduce 启发的管道进行批处理和并行验证。每个账户的故障都是隔离的，因此一个错误的转账不会中止批处理。
+大批量的 USDT0 转账通过 MapReduce 启发的管道并行批处理和验证。每个账户的失败是隔离的，因此一个不良转账不会中止整个批次。
 
-调用者侧的转账 API 保持不变。您以正常方式提交转账，无需更改代码即可提高吞吐量。
+调用方转账 API 保持不变。您以正常方式提交转账，无需更改代码即可获得吞吐量。
 
 阅读更多：[USDT 转账聚合器](/cn/explanation/usdt-transfer-aggregator)。
 
 ## EVM 兼容性
 
-标准 EVM 工具无需修改即可工作。在 EVM 层面，有三种行为与以太坊不同（上面介绍的 USDT0 作为燃料代币是第四种）。
+标准 EVM 工具无需修改即可工作。在 EVM 层面，有三种行为与以太坊不同（USDT0 作为燃料，如上所述，是第四种）。
 
-**单槽最终性。** 交易一旦包含在区块中即为最终交易。区块大约每 0.7 秒产出一次。
+**单槽最终性。** 交易一旦包含在区块中即为最终交易。区块大约每 0.7 秒产出一个。
 
-**无优先级小费。** `maxPriorityFeePerGas` 始终被忽略。有效的 Gas 价格是协议设置的基础费用。
+**无优先小费。** `maxPriorityFeePerGas` 始终被忽略。有效的燃气价格是协议设定的基础费用。
 
 ```typescript
 import { ethers } from "ethers";
@@ -73,23 +75,23 @@ console.log("Included at gas price:", tx.gasPrice?.toString());
 Included at gas price: 1000000000
 ```
 
-**双重角色 USDT0，移植风险。** 从以太坊移植的合约不应镜像原生余额，应拒绝 `address(0)` 转账，并且不应依赖 `EXTCODEHASH` 进行地址重用检测。
+**USDT0 双重角色，移植风险。** 从以太坊移植的合约不应镜像原生余额，应拒绝 `address(0)` 转账，并且不应依赖 `EXTCODEHASH` 进行地址重用检测。
 
 :::warning
-在 Stable 上移植在内部变量中镜像原生余额的合约是不安全的。外部 `USDT0.transferFrom` 调用可以在不调用任何合约代码的情况下耗尽合约的原生余额。始终在转账时使用 `address(this).balance` 进行偿付能力检查。
+在 Stable 上，移植一个在内部变量中镜像原生余额的合约是不安全的。外部的 `USDT0.transferFrom` 调用可以在不调用任何合约代码的情况下耗尽合约的原生余额。在转账时务必通过 `address(this).balance` 进行偿付能力检查。
 :::
 
 阅读更多：[与以太坊的区别](/cn/explanation/ethereum-comparison) · [Stable 上的合约](/cn/explanation/contracts-overview) · [USDT0 迁移清单](/cn/explanation/usdt0-behavior)。
 
 ## 机密转账（计划中）
 
-Stable 有一个针对零知识转账的计划功能，可以隐藏金额，同时允许授权方审计。该功能尚未上线。
+Stable 有一个计划中的零知识转账功能，它可以隐藏金额，同时允许授权方进行审计。该功能尚未上线。
 
 阅读更多：[机密转账](/cn/explanation/confidential-transfer)。
 
-## 建议阅读
+## 接下来建议
 
 - [**快速入门**](/cn/tutorial/quick-start)：连接到测试网并发送第一笔交易。
 - [**USDT0 行为**](/cn/explanation/usdt0-behavior)：将合约移植到 Stable，避免双重角色陷阱。
-- [**Gas 定价**](/cn/reference/gas-pricing-api)：在 Stable 的费用模型上正确构建交易。
+- [**燃气定价**](/cn/reference/gas-pricing-api)：在 Stable 的费用模型上正确构建交易。
 - [**生产就绪**](/cn/how-to/production-readiness)：在发布到主网之前验证集成。

docs/pages/cn/explanation/execution.mdx

@@ -1,8 +1,8 @@
 ---
 source_path: explanation/execution.mdx
-source_sha: bc64781e476fda556f242c5ec924b0e026a13f33
+source_sha: 6fd36fc5aba0418235d67180f61d452cae54c8a7
 title: "执行"
-description: "Stable EVM 并行执行，采用 Block-STM、乐观区块处理，以及未来 StableVM++ 改进。"
+description: "了解 Stable 如何使用 Block-STM 并发执行事务，同时保持确定性状态。"
 diataxis: "explanation"
 ---
 
@@ -16,58 +16,58 @@ diataxis: "explanation"
   alt="Stable EVM"
 />
 
-**Stable EVM** 是 Stable 的以太坊兼容执行层。现有的以太坊工具和钱包，如 MetaMask，无需更改即可与 Stable 交互。Stable EVM 将 EVM 的开发者体验与 Stable SDK 的模块化基础设施相结合。
+**Stable EVM** 是 Stable 的以太坊兼容执行层。现有的以太坊工具和钱包，如 MetaMask，可以直接与 Stable 交互而无需修改。Stable EVM 结合了 EVM 的开发者体验和 Stable SDK 的模块化基础设施。
 
-为了弥合 Stable EVM 和 Stable SDK 之间的鸿沟，Stable EVM 引入了一系列**预编译**。这些预编译将原生的 Stable SDK 模块功能暴露给 EVM 智能合约，使它们能够安全、原子地调用核心链逻辑。智能合约因此可以执行特权操作，例如代币转移、质押或参与治理。
+为了弥合 Stable EVM 和 Stable SDK 之间的鸿沟，Stable EVM 引入了一组**预编译（precompiles）**。这些预编译将原生的 Stable SDK 模块功能暴露给 EVM 智能合约，使其能够安全且原子地调用核心链逻辑。智能合约随后可以执行特权操作，例如代币转移、质押或参与治理。
 
-## 未来路线图 1：乐观并行执行
+## v1.4.0 中的乐观并行执行
 
-历史上，区块链系统一直依赖于顺序执行，即每个事务按顺序处理，以确保所有节点上的状态确定性。虽然这种设计保证了一致性，但它严重限制了吞吐量和可伸缩性，尤其是在现代区块链旨在支持每秒数万笔事务时。
+历史上，区块链系统一直依赖于顺序执行，即每个事务按顺序处理，以确保所有节点上的确定性状态。虽然这种设计保证了一致性，但它严重限制了吞吐量和可扩展性，尤其是当现代区块链旨在支持每秒数万个事务时。
 
-为了克服这一限制，Stable 正在采用 **Block-STM**，这是一种经过验证的并行执行引擎，可实现**乐观并行执行（OPE）**。这允许事务并行执行，同时保持确定性，显著提高性能。
+Stable v1.4.0 通过 Block-STM 引入了**乐观并行执行（Optimistic Parallel Execution, OPE）**。事务在 CPU 核心之间并发执行，而固定的块内顺序保持最终状态的确定性。
 
-### Block-STM 工作原理
+### Block-STM 如何工作
 
-Block-STM 使用乐观并发控制机制：事务首先在假设它们不会冲突的情况下并行执行。然后，在验证阶段，检测并处理任何冲突，通过重新执行来解决。该过程依赖于以下五种关键技术：
+Block-STM 使用乐观并发控制机制：事务首先在假设它们不会冲突的情况下并行执行。然后，在验证阶段，通过重新执行来检测和处理任何冲突。该过程依赖于以下五种关键技术：
 
 **1. 多版本内存结构**
 
-Block-STM 为每个内存键存储多个版本：
+Block-STM 存储每个内存键的多个版本：
 
-- 每个事务读取先前事务提交的最新版本。
+- 每个事务读取由先前事务提交的最新版本。
 - 在执行期间，读取和写入都进行版本控制。
 - 随后，在验证期间，检查这些版本的一致性以检测冲突。
 
-**2. 基于读写集的验证**
+**2. 基于读写集（Read-Set / Write-Set）的验证**
 
-- 在执行期间，每个事务都会将其读取的键和版本记录在读写集中。
+- 在执行期间，每个事务将其读取的键和版本记录在读写集中。
 - 在执行结束时，它将其写集记录到多版本内存中。
-- 在验证期间，如果另一个事务修改了读写集中的任何键，则该事务被标记为冲突。然后它被中止并以递增的化身号重新执行。
+- 在验证期间，如果另一个事务修改了读写集中的任何键，则该事务被标记为冲突。然后它被中止并通过增加的迭代次数重新执行。
 
 **3. 使用 ESTIMATE 标记快速检测冲突**
 
 - 当事务失败时，其写集会用 ESTIMATE 标志标记。
-- 如果另一个事务读取 ESTIMATE 标记的值，它会立即停止并等待重新执行（由 `READ_ERROR` 触发）。
-- 这有助于通过快速识别依赖关系来减少开销，而无需重新执行整个事务集。
+- 如果另一个事务读取了带有 ESTIMATE 标记的值，它会立即停止并等待重新执行（由 `READ_ERROR` 触发）。
+- 这有助于通过快速识别依赖关系来减少开销，而无需重新执行完整的事务集。
 
-**4. 预设交易顺序**
+**4. 预设事务顺序**
 
-- 区块内的所有交易都按照预设的、确定性的顺序执行。
+- 区块内的所有事务都按照预设的确定性顺序执行。
 - 验证和提交阶段也遵循相同的顺序。
-- 这确保了即使并行执行，所有节点也能达到相同的最终状态。
+- 这确保了即使是并行执行，所有节点也都能达到相同的最终状态。
 
 **5. 协作调度器**
 
-- 协作调度器以线程安全的方式在执行和验证工作器之间分配任务。
-- 它优先处理低索引事务，以加速早期提交并最小化重新执行。
-- 调度器管理事务的化身，以便重复尝试直到它们成功提交。
+- 协作调度器以线程安全的方式在执行和验证工作程序之间分配任务。
+- 它优先处理索引较低的事务，以加速早期提交并最大程度地减少重新执行。
+- 调度器管理事务的迭代，以便在它们成功提交之前重复尝试。
 
 ### Block-STM 的主要优势
 
-- **无锁并行化**：通过利用 MVCC（多版本并发控制），Block-STM 允许多个事务并发读写，无需互斥锁。冲突仅在执行后检查，在初始处理阶段实现最大吞吐量。
-- **通过 ESTIMATE 标记实现最小开销**：失败的事务会用 ESTIMATE 标记来标记它们的写集，示意依赖事务提前暂停，避免浪费执行。这可以更快地收敛到有效的执行路径。
-- **高效调度和优先级提交**：使用协作调度器，系统通过首先提交低索引事务来最小化重试。这提高了整体吞吐量并缩短了执行周期。
-- **确定性和共识兼容性**：因为每个事务都遵循固定顺序，即使重新执行的事务最终也会以相同的顺序提交。这确保了所有节点之间的安全和确定性状态一致性，即使在并行化环境中也保持了共识的完整性。
+- **无锁并行化**：通过利用 MVCC（Multi-Version Concurrency Control），Block-STM 允许多个事务并发读写，无需互斥锁。冲突仅在执行后检查，从而在初始处理阶段实现最大吞吐量。
+- **通过 ESTIMATE 标记实现最小开销**：失败的事务用 ESTIMATE 标记标记其写集，信号通知依赖事务提前暂停，避免浪费执行。这导致更快地收敛到有效的执行路径。
+- **高效调度和优先提交**：使用协作调度器，系统通过首先提交索引较低的事务来最大限度地减少重试。这提高了整体吞吐量并缩短了执行周期。
+- **确定性和共识兼容性**：因为每个事务都遵循固定的顺序，即使重新执行的事务最终也会以相同的顺序提交。这确保了所有节点上的安全和确定性状态一致性，即使在并行化环境中也保持共识完整性。
 
 ### Stable 上的 OPE
 
@@ -77,28 +77,35 @@ Block-STM 为每个内存键存储多个版本：
   alt="Optimistic Parallel Execution on Stable"
 />
 
-Stable 将把**乐观并行执行（OPE）**作为其执行层的核心功能，并结合**乐观区块处理（OBP）**。请注意，OPE 和 OBP 是互补但根本不同的策略。
+Stable 将 OPE 与**乐观区块处理（Optimistic Block Processing, OBP）**相结合。这两种优化处理不同的工作。
 
 ### 关于 OBP
 
-- OBP 与并行无关，而是与执行时机有关。
-- 在 `ProcessProposal` 阶段，Stable 在区块被传播到其他节点时预执行它们。
+- OBP 与并行化无关，而是与执行时机有关。
+- 在 `ProcessProposal` 阶段，Stable 在区块被传播到其他节点时预执行区块。
 - 生成的状态被缓存到内存中，并在 `FinalizeBlock` 期间重用，从而节省时间并减少重复计算。
 
-通过结合 OPE 和 OBP，Stable 可以最大限度地减少执行延迟和资源争用，在高事务负载下提供卓越性能。
+OPE 通过使用多个 CPU 核心来缩短执行时间。OBP 避免了在提案处理和最终确定过程中两次执行同一个区块。
 
-### 预期性能提升
+### 提交后重新检查
 
-内部基准测试表明，通过**基于 Block-STM 的 OPE** 和 **StableDB** 集成，Stable 可以实现端到端事务处理**至少 2 倍的吞吐量提升**。
+区块提交后，CometBFT 通常会重新检查内存池中等待的每个事务。这种重复的工作会消耗节点 31-34% 的 CPU。
 
-## 未来路线图 2：StableVM++
+Stable v1.4.0 添加了**选择性 RecheckTx**。应用程序返回区块的状态更改增量，节点仅重新检查受影响账户的事务。CometBFT 检测应用程序支持，并在选择性重新检查不可用时回退到完全重新检查。
 
-虽然像乐观并行执行（OPE）和乐观区块处理（OBP）这样的努力侧重于优化*如何并发执行多个事务*，但还有另一个重要的性能杠杆：*每个单独事务的处理效率*。
+在最佳情况下，对来自唯一发送方的 10,000 个待处理事务的基准测试中，吞吐量从 700 提高到 1,400 TPS。更典型的工作负载预计提高 1.5-1.7 倍。
 
-Stable 目前正在探索替代 EVM 实现以提高执行速度。在众多候选者中，用 C++ 编写的高性能 EVM **EVMONE** 脱颖而出，有望取代现有的基于 Go 的 EVM。根据理论基准测试，预计这种切换将使 **EVM 执行性能提高 6 倍**。
+这里节省的 CPU 可用于 OPE 工作人员。MemIAVL 消除了可能限制这些执行增益的存储瓶颈。
 
-## 接下来推荐
+## 未来路线图：StableVM++
 
-- [**存储 (StableDB)**](/cn/explanation/stable-db)：了解分离的状态提交如何在不阻塞磁盘 I/O 的情况下馈送执行。
-- [**高性能 RPC**](/cn/explanation/high-performance-rpc)：了解将执行结果呈现给客户端的分路径 RPC。
+尽管像乐观并行执行（OPE）和乐观区块处理（OBP）这样的工作着重于优化**多个事务并发执行的方式**，但还有另一个重要的性能杠杆：**单个事务的处理效率**。
+
+Stable 目前正在探索替代的 EVM 实现，以提高执行速度。在候选方案中，用 C++ 编写的高性能 EVM **EVMONE** 脱颖而出，有望取代现有的基于 Go 的 EVM。根据理论基准测试，预计这种转换将使 EVM 执行性能**提高多达 6 倍**。
+
+## 接下来去哪里
+
+- [**存储 (StableDB)**](/cn/explanation/stable-db)：了解分离的状态提交如何在不阻塞磁盘 I/O 的情况下进行执行。
+- [**高性能 RPC**](/cn/explanation/high-performance-rpc)：了解将执行结果显示给客户端的分离路径 RPC。
 - [**以太坊兼容性**](/cn/explanation/ethereum-compatibility)：使用标准 EVM 工具针对 Stable 移植现有合约。
+- [**网络升级**](/cn/reference/network-upgrades)：查看完整的 v1.4.0 发布范围和发布说明。