diff --git a/docs/pages/cn/explanation/core-concepts.mdx b/docs/pages/cn/explanation/core-concepts.mdx index 55e653a..b733a00 100755 --- a/docs/pages/cn/explanation/core-concepts.mdx +++ b/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)：在发布到主网之前验证集成。 diff --git a/docs/pages/cn/explanation/execution.mdx b/docs/pages/cn/explanation/execution.mdx index 271b654..d9bebca 100755 --- a/docs/pages/cn/explanation/execution.mdx +++ b/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 发布范围和发布说明。 diff --git a/docs/pages/cn/explanation/guaranteed-blockspace.mdx b/docs/pages/cn/explanation/guaranteed-blockspace.mdx index fe428a6..416f18b 100755 --- a/docs/pages/cn/explanation/guaranteed-blockspace.mdx +++ b/docs/pages/cn/explanation/guaranteed-blockspace.mdx @@ -1,49 +1,70 @@ --- source_path: explanation/guaranteed-blockspace.mdx -source_sha: e4251f3214551742d492fdfe9dfc33077cb77d76 -title: "保证区块空间" -description: "保证区块空间分配，为企业合作伙伴提供在 Stable 网络上预留的吞吐量容量。" +source_sha: 5a58c3c6715bd458c1b2a57a9130934021c66e59 +title: "有保证的区块空间" +description: "了解 Stable 如何通过二维随机数保留每个通道的 Gas 容量并识别优先级流量。" diataxis: "explanation" --- -# 保证区块空间 +# 有保证的区块空间 -**保证区块空间**是一种专用的区块空间分配模型，它为注册的企业合作伙伴预留了每个区块固定份额的容量，无论更广泛的网络条件如何。通过保证路径路由的交易以可预测的延迟和成本执行。工资支付、结算和供应商付款不会与公共内存池流量竞争。 +Stable v1.4.0 将每个区块划分成具有独立 Gas 预算的通道。符合条件的优先级交易进入 VIP 通道，因此正常的流量无法占用为其保留的容量。 :::note -**计划中。** 保证区块空间是前瞻性路线图项目。有关时间安排，请参阅[路线图](/cn/explanation/technical-roadmap)。 +有保证的区块空间已在 v1.4.0 Testnet 候选版本中上线。主网升级时间表仍在等待中。如果没有治理配置，每个交易将继续使用一个普通通道。 ::: -## 为什么这很重要 +## 区块通道 -通用链在负载下的费用可预测性方面设计不足： +提案和验证规则识别出三种通道类型： -- **以太坊**：2022 年 5 月 1 日，Yuga Labs 的“Otherside”NFT 铸造将峰值 gas 推高到 8,000 gwei 以上，并烧毁了超过 2 亿美元的费用，打破了任何需要确定性成本的工作负载。 -- **低费用网络**如 Solana 和 Base 吸引了 MEV 和套利垃圾邮件，因此合法交易与机器人流量竞争以获得包含。 +- **VIP 通道**：承载其 `NonceKey` 属于协议保留范围的交易。 +- **交易类型通道**：为配置的交易类别保留容量。 +- **普通通道**：承载不匹配其他已配置通道的标准交易。 -![来源：Flashbots 和 Robert Miller 的 MEV 和扩容限制](/images/share-of-gas.png) +每个通道都有自己的 Gas 配额。提议者在这些限制内填充通道，验证者在验证提议的区块时强制执行相同的限制。 -*来源：Flashbots 和 Robert Miller 的 MEV 和扩容限制* +这使得保留在协议层面是确定性的。它不依赖于提议者自愿不留下未使用的空间。 -企业支付流无法容忍这种差异。保证区块空间直接解决了这个问题。 +## 二维随机数 -## 保证如何工作 +以太坊账户通常有一个随机数序列。如果交易 12 缺失或卡住，交易 13 及之后的交易就无法执行。 -保证在三个层面强制执行： +**二维随机数**（或 2D 随机数）为账户提供了多个独立的序列。`NonceKey` 选择序列，交易的随机数给出其在该序列中的位置。 -- **保证内存池**：验证者从专门的内存池中提取保证交易，该内存池与公共流量隔离。 -- **验证者级别预留**：每个验证者为保证通道预留了每个区块 gas 容量的预定义部分。确定性包含由此产生。 -- **专用 RPC 节点**：保证区块空间 API 通过隔离的 RPC 端点路由交易，因此提交延迟不会随着公共 RPC 负载而飙升。 +例如，一个支付账户可以使用 `NonceKey = 1` 进行工资支付，`NonceKey = 2` 进行供应商结算。延迟的工资支付交易不会阻塞供应商序列。 -对于注册的合作伙伴，结果是： +随机数键空间有三个重要的区域： -- **独家路由路径**：提交不与公共内存池流量竞争。 -- **保证包含**：无论网络拥堵如何，每个区块都预留了容量。 -- **无去中心化权衡**：验证者开放性和网络参与性得以保留；保证与公共通道并存，而不是凌驾于其上。 -- **关键业务操作的可靠链上性能**，即使在负载下。 +- `NonceKey = 0` 保持标准的 EVM 兼容随机数行为。 +- `uint64` 范围的上半部分保留给协议使用。VIP 成员资格通过此范围传达。 +- `NonceKey = MaxUint64` 标记一个无序交易。`TimeoutTimestamp` 提供其重放保护截止日期。 -## 下一步建议 +Stable 在 `CustomTx` (交易类型 `0x3F`) 中携带这些字段。现有的 EVM 交易格式仍然可用，并且默认的随机数通道保留了它们的预期行为。 -- [**保证结算**](/cn/explanation/upcoming-use-cases)：查看依赖于保证区块空间的支付模式：具有确定性包含的定时 DvP 结算周期。 -- [**USDT 作为 gas**](/cn/explanation/usdt-as-gas-token)：了解流经保证区块空间的资产。 -- [**代币经济学**](/cn/reference/tokenomics)：审查 STABLE 质押如何支撑验证者的区块空间保证。 +## 治理和激活 + +治理通过一个 `MsgUpdateParams` 提案控制通道定义和 Gas 配额。接受的参数在下一个区块生效。 + +默认值不包含保留通道。在治理配置它们之前，链将作为单个普通通道运行。这使得通道配置是对现有交易处理的补充。 + +## 保证边界 + +当满足所有这些条件时，VIP 交易会获得确定性的下一区块包含： + +- 交易符合 VIP 通道的资格。 +- 通道有足够的为交易保留的 Gas。 +- 验证者遵循协议。 +- 网络保持足够的同步性，以便验证者在提案之前接收交易。 + +Stable 的无内存池验证者入口模型将 VIP 交易提供给验证者。保留的提案容量随后阻止了正常流量取代它们。 + +:::note +免 Gas 的交易类型通道被推迟了。一个 `gasPrice = 0` 的通道需要受信任的准入控制；否则，攻击者可以用免费交易淹没它。 +::: + +## 下一步 + +- [**有保证的结算**](/cn/explanation/upcoming-use-cases)：查看依赖于有保证的区块空间的支付模式：具有确定性包含的定时 DvP 结算周期。 +- [**网络升级**](/cn/reference/network-upgrades)：查看完整的 v1.4.0 版本及其推出状态。 +- [**执行**](/cn/explanation/execution)：了解 Stable 如何执行为每个区块选择的交易。 diff --git a/docs/pages/cn/explanation/stable-db.mdx b/docs/pages/cn/explanation/stable-db.mdx index 727d6dc..c787760 100755 --- a/docs/pages/cn/explanation/stable-db.mdx +++ b/docs/pages/cn/explanation/stable-db.mdx @@ -1,23 +1,25 @@ --- source_path: explanation/stable-db.mdx -source_sha: 1b5136d111f56a7a32bf3730d44d97755770091f +source_sha: ffbcf61705d3dbb4a82da281257a33d12e385b45 title: "存储 (StableDB)" -description: "StableDB 架构采用解耦状态提交、MemDB 和 mmap，以消除磁盘 I/O 瓶颈。" +description: "了解 MemIAVL 如何使用内存映射快照和顺序写入预警日志来存储当前状态。" diataxis: "explanation" --- # 存储 (StableDB) -端到端区块链性能的主要瓶颈之一是 **磁盘 I/O**。具体来说，在区块执行后提交和存储状态数据是关键瓶颈。Stable 通过架构创新（如 `MemDB`、`VersionDB` 和内存映射存储 (`mmap`)）解决了这个问题，从而显著提高了吞吐量。 +Stable v1.4.0 使用 MemIAVL 替代了基于 LevelDB 的状态存储。MemIAVL 将一个状态快照存储在内存映射文件中，并在顺序写入预警日志中记录每个新区块的更改。 -## 为什么磁盘 I/O 是瓶颈 +:::note +MemIAVL 已在 v1.4.0 测试网发布候选版本中上线。主网升级时间表仍在等待中。请关注[网络升级](/cn/reference/network-upgrades)以了解推出状态。 +::: -### 状态转换和持久化 +## 磁盘 I/O 为何成为瓶颈 -每当执行一个事务区块时，区块链就会从一个状态转换到下一个状态。这个过程有两个基本阶段： +每个区块都会改变应用程序状态。节点必须完成两个相关任务： -1. **状态提交**：事务执行后提交新的应用状态。 -2. **状态存储**：将提交的状态持久化到磁盘，以供长期访问和历史验证。 +1. **状态提交**：计算并提交新状态的根哈希。 +2. **状态持久化**：将更改的数据写入存储，以便节点以后可以恢复。 耦合的状态提交和存储 -在传统架构中，状态存储与状态提交是**紧密耦合**的。这意味着： +以前的 LevelDB 后端存储将这些任务耦合在一起。它还在后台压缩期间重写数据，以重新组织存储的记录，从而提高后续读取效率。 -- 节点必须等待新状态完全存储到磁盘后才能继续执行下一个区块。 -- 状态数据写入随机的磁盘位置，这些位置未映射到固定地址。这导致在执行后续事务期间检索状态数据时延迟较高。 +一次逻辑上的状态更新可能导致 10-50 倍的物理磁盘写入。这称为**写入放大**。执行必须等待一个由随机写入和压缩主导的存储路径。 -即使共识和执行层经过高度优化，这种对慢速磁盘操作的序列化依赖也会限制整个系统可实现的性能。 +## MemIAVL 如何改变存储 -## 优化数据库操作以提高吞吐量 +内存映射文件 (`mmap`) 允许操作系统通过内存地址暴露文件内容。节点可以通过指针读取状态，而操作系统将所需的页面加载到其页面缓存中。 -为了克服这些限制，Stable 提出了两项架构增强功能，重点是**解耦状态操作**和**引入内存映射数据库优化**。 +MemIAVL 结合了两种结构： -### 1. 解耦状态提交和存储 +- **快照**：持久化状态树的内存映射表示。 +- **写入预警日志 (WAL)**：快照后所做原始更改的仅追加记录。 解耦的状态提交和存储 -第一步是将状态提交与其存储解耦： +### 写入路径 -- 提交新状态后，节点立即继续执行下一个区块。 -- 状态实际持久化到磁盘是异步在后台进行的。 +每个区块按顺序将其更改集追加到 WAL 中。MemIAVL 不会将更新路由到 LevelDB 或触发压缩。因此，写入放大从 10-50 倍大约下降到一次写入。 -这种分离允许即时执行并跳过慢速磁盘写入的延迟，从而消除阻塞依赖项并最终提高端到端性能。 +MemIAVL 还将树节点分为两类： -### 2. 通过 `mmap` 引入 `MemDB` 和 `VersionDB` +- `PersistedNode` 表示已存储在快照中的未更改子树。 +- `MemNode` 表示当前更新在内存中更改的子树。 -Stable 以双数据库模型增强了这一点，该模型由 `mmap`（内存映射文件访问）提供支持： +当 MemIAVL 计算下一个根哈希时，它会停止在未更改的 `PersistedNode` 子树处。它仅哈希包含新 `MemNode` 数据的路径。 -- **MemDB（内存数据库）**： - - 存储频繁访问的最新和活动状态。 - - 通过 `mmap` 使用固定地址映射，实现快速且确定性的查找。 - - 非常适合大多数以最近修改状态为目标的事务工作负载。 -- **VersionDB（历史数据库）**： - - 在磁盘上存储旧的历史状态。 - - 针对归档和长期查询进行了优化，不用于高频访问。 +### 读取路径 -这种设计确保**热数据由快速、驻留内存的结构提供服务**，而冷数据则卸载到较慢的持久存储。通过将 `mmap` 访问与智能状态分层相结合，Stable 可以显著降低区块执行期间的数据库读/写延迟。 +当前状态读取遵循指向内存映射快照的指针。经常访问的页面保留在操作系统的页面缓存中，因此节点避免了为每个树节点进行单独的数据库查找。 -## 预期收益和先例 +## 历史状态和 VersionDB -这种架构优化不仅是理论上的。它已经被 Sei 和 Cronos 等高性能区块链实现。两者都采用了类似的解耦架构和内存映射数据库，并观察到**整体 TPS 提高了 2 倍**。 +MemIAVL 服务于当前状态和节点保留的快照。一个配套的 VersionDB 将历史版本存储在 RocksDB 副车中。 -Stable 也预期有类似的收益，因为架构将不再受存储层的瓶颈限制。相反，共识和执行性能可以扩展，而不会受到磁盘操作的限制。 +当节点必须回答比其最早保留的 MemIAVL 快照更早的历史状态查询时，您需要 VersionDB。这对于需要公开长期查询的归档节点和 RPC 服务尤为重要。 + +## 迁移注意事项 + +现有节点在采用 v1.4.0 时必须迁移其 LevelDB 状态。推荐的方法是本地快照导出和恢复。 + +基准测试显示，标准恢复每个验证器平均停机时间为 19.4 秒。并行恢复方案将平均时间缩短至约 2.6 秒。 + +验证器可以逐个以轮询方式进行迁移。保持至少三分之二的投票权在线，可以在迁移期间让网络继续生成区块。 + +:::warning +这些时间是基准测试结果，并非停机保证。请遵循特定网络的升级说明，获取最终二进制文件、升级高度、备份和恢复命令。 +::: ## 进一步阅读 -有关更多技术深入研究和实现细节，请参阅： +有关更多技术深度解析和实现细节，请参阅： - [ADR-065: Cosmos Store V2 架构](https://docs.cosmos.network/main/build/architecture/adr-065-store-v2) - [MemIAVL：实用指南](https://hackmd.io/@yihuang/rkeCvy5xh) - [Cronos MemIAVL 节点配置](https://docs.cronos.org/for-node-hosts/running-nodes/memiavl) - [Sei 的数据库设计方法](https://4pillars.io/ko/articles/sei-db) -## 下一步建议 +## 接下来去哪里 -- [**高性能 RPC**](/cn/explanation/high-performance-rpc)：了解 RPC 层如何公开状态读取而不会与写入发生冲突。 +- [**高性能 RPC**](/cn/explanation/high-performance-rpc)：了解 RPC 层如何公开状态读取，而不会与写入冲突。 - [**执行**](/cn/explanation/execution)：了解执行如何写入此处介绍的存储层。 -- [**共识**](/cn/explanation/consensus)：查看在区块到达存储之前对其进行排序的共识层。 +- [**升级节点**](/cn/how-to/upgrade-node)：在协调升级后准备备份并验证节点。 +- [**网络升级**](/cn/reference/network-upgrades)：查看完整的 v1.4.0 范围和推出状态。 diff --git a/docs/pages/cn/explanation/tech-overview.mdx b/docs/pages/cn/explanation/tech-overview.mdx index 6b07fcb..0b21c60 100755 --- a/docs/pages/cn/explanation/tech-overview.mdx +++ b/docs/pages/cn/explanation/tech-overview.mdx @@ -1,44 +1,5 @@ --- source_path: explanation/tech-overview.mdx -source_sha: d71b320a46b9bc5aa2c45ca6f25c192f0d33a2af -title: '技术概览' -description: "Stable 区块链架构、共识机制与 EVM 兼容执行层的高层概述。" ---- - -# 技术概览 - -从状态数据库、执行引擎、共识机制，到针对 USDT 的特定优化，Stable 的设计始终聚焦于性能、可扩展性与可靠性。技术栈中的每一层组件都经过专门优化，以支持高吞吐的工作负载和无缝的 USDT 原生操作。 - -Tech Overview - -## StableBFT - -Stable 区块链最初采用 **StableBFT** —— 基于 CometBFT 构建的定制化 PoS 共识协议，确保网络具备高吞吐、低延迟和强健的可靠性。为了进一步优化共识性能，Stable 计划拆解数据传播与共识流程，并实现面向区块提议者的交易直接广播机制。 - -Stable 还计划将协议升级为基于有向无环图（DAG）的 **Autobahn** 架构。在 Autobahn 上构建的 StableBFT 将带来： - -- 消除单领导瓶颈，实现提议过程的并行化； -- 通过将数据传播与排序拆解，加快最终性的达成速度； -- 借助增强的 BFT 机制提升对网络异常的鲁棒性。 - -## Stable EVM - -**Stable EVM** 是 Stable 的以太坊智能合约的兼容执行层，支持用户通过现有的以太坊工具和钱包（如 MetaMask）与链进行交互。为打通 Stable EVM 与 StableSDK 的能力边界，同时 Stable EVM 引入一系列 预编译合约，允许 EVM 智能合约安全且原子性地调用Stable底层接口。 - -Stable 计划通过引入 **StableVM++** 来进一步提升 EVM 执行性能，该模块集成了如 EVMONE 等替代 EVM 实现，以及基于 Block-STM 的 **Optimistic并行执行引擎（OPE）**。 - -## StableDB - -**状态：v1.4.0 升级时上线** - -Stable 通过解决区块执行后低效的磁盘存储这一主要瓶颈，显著提升了处理速度。它将状态提交与存储操作进行拆解，使得新区块能在无需等待数据存储的情况下迅速处理。同时，结合 `MemDB` 与 `VersionDB`，并使用 `mmap`（内存映射）技术，实现近期数据驻留内存、历史数据高效存储，大幅提升整体吞吐量。 - -## 高性能 RPC - -即使底层区块链再快，如果 RPC 反应速度缓慢，用户体验仍会大打折扣。Stable 通过彻底重构传统 RPC 架构来解决这一问题。传统的单一 RPC 模式存在资源竞争严重、扩展性差等问题，而 Stable 引入了 **路径分离架构（split-path architecture）**，根据不同功能将操作分离，部署轻量化、专业化的 RPC 节点以实现更快速响应。 - -未来计划包括为 EVM `view` 调用优化的专用 RPC 节点，以及原生集成索引器（indexer）以进一步加速 dApp 数据访问。 +source_sha: 66c5144a0a00b4fc60545e70df03a2260238b7b8 +title: "技术概述" +description: "Stable 的四层堆栈（共识、执行、存储和 RPC）如何为稳定币支付吞吐量进行端到端优化。" diff --git a/docs/pages/cn/explanation/technical-roadmap.mdx b/docs/pages/cn/explanation/technical-roadmap.mdx index 018d3d6..16c2daa 100755 --- a/docs/pages/cn/explanation/technical-roadmap.mdx +++ b/docs/pages/cn/explanation/technical-roadmap.mdx @@ -1,6 +1,6 @@ --- source_path: explanation/technical-roadmap.mdx -source_sha: 669bf747b8f3b656b8509625ece8a50946d431f8 +source_sha: e46692a227f4149b54598c9036a27e12659728ee title: "路线图" description: "Stable 的分阶段优化路线图：今日已上线、即将推出以及未来规划。" diataxis: "explanation" @@ -8,7 +8,7 @@ diataxis: "explanation" # 路线图 -Stable 将分三个阶段优化交易管道的每一层（共识、执行、存储、RPC 和 USDT 特定流程）。本页面将展示已发布、正在进行中和仍在规划中的内容。 +Stable 从三个阶段优化交易管道的每个层（共识、执行、存储、RPC 和 USDT 特定流程）。本页面标记已发布、正在进行和即将推出的功能。 有关完整的版本历史和升级详情，请参阅[版本历史](/cn/reference/testnet-version-history)。 +> 有关完整的版本历史和升级详情，请参阅 [版本历史](/cn/reference/testnet-version-history)。 ## 升级类型 @@ -17,13 +17,25 @@ diataxis: "how-to" - 向后兼容 ### 硬升级（破坏性） -- 需要在特定高度升级 +- 需要在特定高度进行升级 - 不向后兼容 ### 紧急升级 - 关键安全修复 - 需要立即采取行动 -- 可能需要停链 +- 可能需要暂停链 + +## v1.4.0 存储迁移 + +v1.4.0 将基于 LevelDB 的状态存储替换为 MemIAVL。除了正常二进制替换外，本次升级还需要数据迁移。 + +除非网络特定的升级说明选择其他方法，否则请使用本地快照导出和恢复。基准测试表明，标准恢复的平均验证器停机时间为 19.4 秒，并行恢复约为 2.6 秒。 + +以轮询方式迁移验证器，以便至少三分之二的投票权保持在线。如果您的节点必须回答早于其最早保留快照的历史查询，请配置基于 RocksDB 的 VersionDB。 + +:::warning +请勿对 v1.4.0 使用下面通用的纯二进制过程。请等待 [网络升级](/cn/reference/network-upgrades) 中的最终网络特定二进制文件、升级高度、备份路径和恢复命令。 +::: ## 标准升级流程 @@ -67,7 +79,7 @@ tar -xvzf stabled-1.2.0-rc1-linux-*.tar.gz -C /tmp/ ### 步骤 3：执行升级 -#### 软升级 +#### 对于软升级 ```bash # Stop node @@ -90,7 +102,7 @@ sudo systemctl start ${SERVICE_NAME} sudo journalctl -u ${SERVICE_NAME} -f ``` -#### 硬升级 +#### 对于硬升级 ```bash # Monitor for upgrade height @@ -135,9 +147,9 @@ watch -n 2 'curl -s localhost:26657/status | jq ".result.sync_info"' sudo journalctl -u ${SERVICE_NAME} --since "10 minutes ago" | grep -i error ``` -## Cosmovisor 设置（自动升级） +## Cosmovisor 设置（自动化升级） -Cosmovisor 可为协调升级自动化升级过程。 +Cosmovisor 自动化协调升级过程。 ### 安装 @@ -232,7 +244,7 @@ sudo mv /usr/bin/stabled.backup /usr/bin/stabled sudo systemctl start ${SERVICE_NAME} ``` -## 紧急流程 +## 紧急程序 ```bash # If chain halts unexpectedly @@ -245,6 +257,6 @@ stabled export --height > export.json ## 后续步骤 -- [版本历史](/cn/reference/testnet-version-history) - 完整的升级历史和发布说明 -- 升级后[监控你的节点](/cn/how-to/monitor-node) -- 查阅[故障排查](/cn/how-to/troubleshoot-node)了解常见问题 +- [版本历史](/cn/reference/testnet-version-history) - 完整的升级历史和发行说明 +- 升级后[监控您的节点](/cn/how-to/monitor-node) +- 查看[故障排除](/cn/how-to/troubleshoot-node)以获取常见问题 diff --git a/docs/pages/cn/reference/network-upgrades.mdx b/docs/pages/cn/reference/network-upgrades.mdx index 44da215..5bcef45 100644 --- a/docs/pages/cn/reference/network-upgrades.mdx +++ b/docs/pages/cn/reference/network-upgrades.mdx @@ -1,24 +1,24 @@ --- source_path: reference/network-upgrades.mdx -source_sha: 61ebe51988bd8aa1a4e15f0325410428a423a8b0 +source_sha: cdcb426b3580e25ac41f039bd750b4356f3803ce title: "网络升级" -description: "Stable 网络协议版本的发布说明：每个版本中更改了哪些内容以及谁需要采取行动。" +description: "Stable 网络协议版本的发布说明：每个版本更改了什么以及谁需要采取行动。" diataxis: "reference" --- # 网络升级 -以下每个条目都描述了 StableChain 版本中更改了哪些内容、其重要性以及您是否需要执行任何操作。版本按最新顺序排列。有关二进制文件、提交哈希和升级区块高度，请参阅[主网版本历史](/cn/reference/mainnet-version-history)和[测试网版本历史](/cn/reference/testnet-version-history)。 +下面的每个条目都描述了 StableChain 版本中更改的内容、重要性以及您是否需要采取任何操作。发布按最新排序。有关二进制文件、提交哈希和升级块高度，请参阅[主网版本历史记录](/cn/reference/mainnet-version-history)和[测试网版本历史记录](/cn/reference/testnet-version-history)。 ## 如何阅读这些说明 -本文档中会出现一些术语。以下是它们的含义： +以下是一些常用术语的含义： -- **状态破坏性升级**：每个节点都必须在相同的区块高度运行新的二进制文件，通过治理提案进行协调。这些版本在版本历史表中包含一个升级高度。如果您运行验证器，则必须按计划升级，否则您的节点将停止跟随链。 -- **向后兼容升级**：新二进制文件与旧二进制文件兼容，因此没有协调的切换。这些版本没有升级高度。您可以随时通过替换二进制文件进行升级。 -- **Gas 费用豁免**：StableChain 的一项功能，允许发起人支付交易费用，这样发送方无需持有 Gas 代币即可进行交易。 -- **系统交易**：协议本身发出的特殊交易，而非普通用户发出，用于运行内部操作。 -- **预编译**：内置于固定地址的合约，运行原生代码而非 EVM 字节码，用于需要快速执行的常见操作。 +- **状态破坏性升级**：所有节点必须在相同的块高度运行新的二进制文件，通过治理提案进行协调。这些版本在版本历史记录表中有一个升级高度。如果您运行验证器，则必须按计划升级，否则您的节点将停止跟随链。 +- **向后兼容升级**：新的二进制文件与旧的二进制文件兼容，因此没有协调的切换。这些版本没有升级高度。您可以在方便时通过替换二进制文件进行升级。 +- **Gas 豁免**：StableChain 的一项功能，允许赞助者支付交易费用，这样发送者就可以在不持有 gas 代币的情况下进行交易。 +- **系统交易**：协议本身（而不是普通用户）为运行内部操作而发起的特殊交易。 +- **预编译**：一个内置的固定地址合约，运行原生代码而不是 EVM 字节码，用于需要快速执行的常见操作。 要检查您的节点运行的是哪个版本： @@ -30,78 +30,115 @@ stabled version v1.3.1 ``` -## v1.4.0 (即将推出) :badge[测试网]{warning} +## v1.4.0 (即将发布) :badge[测试网]{warning} -一个性能和可预测性版本，目前作为发布候选版本在测试网上线，尚未在主网上线。它将四项更改分为两个主题：加快区块处理速度，并使优先级流量的交易包含更具可预测性。 +一个性能和可预测性版本，目前作为发布候选版本在测试网上线，尚未在主网上线。它将四个更改分为两个主题：加快块处理速度，以及使优先流量的交易包含更具可预测性。 -**即将推出：** +| **举措** | **块阶段** | **更改内容** | **预期结果** | +| :--- | :--- | :--- | :--- | +| 乐观并行执行 (OPE) | 执行 | Block-STM 替代顺序交易执行。 | 多核执行，目标是大约 10,000 TPS。 | +| 选择性重新检查交易 | 提交后内存池重新检查 | 节点仅重新检查由已提交块更改的账户的交易。 | 在最佳测量情况下，持续吞吐量可提高两倍，节点 CPU 使用率降低 31-34%。 | +| MemIAVL | 状态持久性 | 内存映射快照和预写日志 (WAL) 替代基于 LevelDB 的存储。 | 写入放大从 10-50 倍降至约一次写入。 | +| 2D nonce 和保证块空间 | 提交和块提案 | 独立的 nonce 通道与保留的每通道 gas 容量相结合。 | 符合条件的 VIP 交易的确定性下一块包含。 | -- **乐观并行执行 (OPE)**：并行执行区块中的交易，而不是逐个执行，然后协调结果。这基于 Block-STM。 -- **选择性 RecheckTx**：在新区块之后，仅重新验证实际受其影响的待处理交易，而不是整个内存池（等待包含的交易池）。 -- **MemIAVL**：一个内存映射存储层，取代了以前基于 LevelDB 的存储，减少了区块生命周期中的主要瓶颈。 -- **2D nonce 和保证的区块空间**：并行 nonce 通道允许一个账户在多个独立通道上发送交易，保证的区块空间为优先级工作负载保留区块容量，而不是将包含留给偶然。 +这些更改解决了单个块生命周期的不同阶段： + +1. **提交**：2D nonce 允许一个账户通过独立的 nonce 通道提交交易。一个通道上的卡住交易不会阻塞其他通道。 +2. **提案**：保证块空间将块划分为 VIP、交易类型和普通通道。每个通道都有一个在提案和验证期间强制执行的保留 gas 预算。 +3. **执行**：OPE 通过 Block-STM 并发运行交易，然后根据固定的块内顺序对其进行验证。每个节点仍然产生相同的状态。 +4. **提交**：MemIAVL 将更改附加到 WAL 中，与一个内存映射快照对应。这避免了 LevelDB 压缩及其重复的磁盘写入。 +5. **提交后重新检查**：选择性重新检查交易使用块的状态更改增量仅重新检查受影响的发送方，而不是扫描整个内存池。 + +### 吞吐量变化 + +OPE 将交易执行从一个 CPU 核心移到多个核心。交易乐观执行，冲突触发重新执行，固定的交易顺序保留确定性结果。 + +选择性重新检查交易在每次提交后删除工作。在包含来自唯一发送者的 10,000 个待处理交易的最佳测试中，吞吐量从 700 TPS 增加到 1,400 TPS。对于更典型的工作负载，预计改进为 1.5–1.7 倍。CometBFT 检测应用程序是否支持选择性重新检查，如果不支持，则回退到完全重新检查。 + +MemIAVL 从状态存储路径中移除 LevelDB。写入变为包含原始更改集的顺序 WAL 条目。读取变为对操作系统页面缓存的指针查找。一个单独的 VersionDB（由 RocksDB 支持）服务于早于最早保留快照的历史状态。 + +### 可预测的包含 + +2D nonce 为每个账户提供了多个独立的 nonce 通道。 `NonceKey` 选择通道。 `NonceKey = 0` 保留正常的 EVM 兼容序列，而协议保留 `uint64` 范围的上半部分供自己使用。 `MaxUint64` 标记一个无序交易，它使用 `TimeoutTimestamp` 进行重放保护。 + +该版本添加了 `CustomTx` 交易类型 `0x3F`，以及现有的 EVM 交易格式。协议保留的 `NonceKey` 范围也标识 VIP 通道交易。 + +保证块空间将每个块划分为 VIP、交易类型和具有单独 gas 配额的普通通道。治理通过一个 `MsgUpdateParams` 提案控制通道参数，接受的更新在下一个块中生效。如果没有通道配置，链将作为一个普通通道运行。 + +当验证器行为诚实且网络保持同步时，符合条件的 VIP 交易将获得确定性的下一块包含。阅读[保证块空间](/cn/explanation/guaranteed-blockspace)以了解通道和 nonce 模型。 + +### 节点部署 + +MemIAVL 改变了状态存储，因此节点操作员必须迁移其现有数据。推荐的方法是本地快照导出和恢复。基准测试显示每个验证器平均停机时间为 19.4 秒。并行恢复变体将平均停机时间缩短到大约 2.6 秒。 + +验证器可以按轮循顺序迁移，以保留至少三分之二的投票权。请遵循网络特定的升级说明，而不是将基准测试过程视为固定的运行手册。 + +### 延迟工作 + +- **Gas 豁免交易类型通道**：零 gas 通道需要受信任的内存池准入控制。如果没有它，攻击者可能会提交无限的免费交易。 +- **发送者匹配优化**：后续版本可能会让全节点发送预先计算的发送者地址，从而避免在块提案期间重复签名恢复。 :::note -v1.4.0 仍在审计和测试中。在主网升级之前，范围和时间可能会发生变化。请跟踪 [测试网版本历史](/cn/reference/testnet-version-history) 以获取最新的发布候选版本。 +v1.4.0 仍在审计和测试中。在主网升级之前，范围和时间可能会发生变化。跟踪[测试网版本历史记录](/cn/reference/testnet-version-history)以获取最新发布候选版本。 ::: ## v1.3.1 :badge[当前]{success} -一个向后兼容的补丁，也是当前的主网版本。它没有协调的升级高度，因此节点运营商可以随时通过替换二进制文件来采用它。 +一个向后兼容的补丁和当前的主网版本。它没有协调的升级高度，因此节点操作员可以随时通过替换二进制文件来采用它。 ## v1.3.0 -一个注重安全、破坏性状态的升级，也使 Gas 费用豁免功能更加灵活。Gas 费用豁免的更改允许新的合作伙伴，如钱包和交易所，稍后通过治理提案进行入驻，而不是每次都需要另一次破坏性状态升级。 +一个以安全为重点的状态破坏性升级，也使 gas 豁免功能更加灵活。gas 豁免的更改允许通过治理提案在以后引入新的合作伙伴（例如钱包和交易所），而无需每次都进行另一次状态破坏性升级。 -**谁需要采取行动**：所有节点运营商都在预定的高度升级。有关确切高度，请参阅[主网版本历史](/cn/reference/mainnet-version-history)。 +**谁需要采取行动**：所有节点操作员都在预定高度升级。请参阅[主网版本历史记录](/cn/reference/mainnet-version-history)以了解确切高度。 -**安全改进：** +**安全改进**： -- 非公共 JSON-RPC 命名空间不再注册，并且仅当 `AllowInsecureUnlock=true` 时才启用签名 API。 -- Gas 费用豁免输入已强化：地址必须使用 EIP-55 规范格式，查询输入受长度和格式限制，并且 wrapper 类型、chain-id 和 EIP-7702 内部交易验证得到加强。 -- 系统交易现在针对 `to` 地址和方法选择器进行验证，而不仅仅是 `from` 地址。这堵塞了可能触发免手续费执行的路径。 -- Prague 预编译地址范围已添加到阻塞地址列表，未知预编译方法现在需要查询 Gas。 +- 不再注册非公共 JSON-RPC 命名空间，并且只有当 `AllowInsecureUnlock=true` 时才启用签名 API。 +- Gas 豁免输入得到加强：地址必须使用 EIP-55 规范格式，查询输入受到长度和格式限制，并且加强了包装类型、链 ID 和 EIP-7702 内部交易验证。 +- 系统交易现在针对 `to` 地址和方法选择器进行验证，而不仅仅是 `from` 地址。这关闭了可能触发免手续费执行的路径。 +- Prague 预编译地址范围已添加到阻塞地址列表，未知预编译方法现在需要查询 gas。 -**错误修复和稳定性：** +**错误修复和稳定性**： -- 纠正了失败的有状态预编译调用的 Gas 核算。 -- 解决了 ERC-20 内部调用失败后出现的 refund-disable 状态泄漏。 -- 修复了预编译热集合跟踪和 `COINBASE` 操作码行为。 -- 将 EIP-7702 授权回滚与规范对齐。 -- 修复了报告 `from=0x0` 的系统交易响应、`feeHistory` 错误日志记录以及历史完整交易响应中的 chain-id 一致性。 +- 更正了失败的有状态预编译调用的 gas 核算。 +- 解决了 ERC-20 内部调用失败后的退款禁用状态泄漏。 +- 修复了预编译热集跟踪和 `COINBASE` 操作码行为。 +- 使 EIP-7702 授权回滚与规范保持一致。 +- 修复了报告 `from=0x0` 的系统交易响应、`feeHistory` 错误日志记录以及历史完整交易响应中的链 ID 一致性。 ## v1.2.2 一个向后兼容的可选升级，使 StableChain 与官方上游共识版本保持一致，并清理了两种查询行为。 -**谁需要采取行动**：没有人必须采取行动。此升级无需治理提案。节点运营商可以随时通过替换二进制文件来采用它。 +**谁需要采取行动**：没有人需要。此升级无需治理提案。节点操作员可以在方便时通过替换二进制文件来采用它。 -**更改：** +**更改**： -- 将 CometBFT 升级到官方 `v0.38.21`。这遵循了早期 v1.1.4 中发布的安全补丁，并允许外部合作伙伴验证网络运行的确切共识版本。 -- 删除了 Gas 费用豁免交易查询中的重复日志索引。 +- 将 CometBFT 升级到官方 `v0.38.21`。这遵循了 v1.1.4 中早些时候发布的安全性补丁，并允许外部合作伙伴验证网络运行的确切共识版本。 +- 移除了 gas 豁免交易查询中的重复日志索引。 - 为系统交易查询的 RPC 响应添加了安全措施。 ## v1.2.1 -一个向后兼容的热修复，解决了两个问题，这些问题如果被利用，可能会导致链停止。 +一个向后兼容的热修复，弥补了两个如果被利用可能会导致链停机的漏洞。 -**谁需要采取行动**：验证器必须升级。对于包括 RPC 提供商在内的其他节点运营商，升级是可选的。它不需要治理提案。 +**谁需要采取行动**：验证器必须升级。对于其他节点操作员，包括 RPC 提供者，升级是可选的。它不需要治理提案。 -**修复：** +**修复**： -- 堵塞了一个系统交易欺骗路径，用户可以在其中设置 `MsgEthereumTx.From == 0x1` 来绕过身份验证并调用一个仅限系统的预编译，然后使用伪造的交易重复强制 `ProcessProposal` 拒绝区块并停止共识。 -- 修复了一个内存池投毒链停止问题，其中 `ExtensionOptionsWaiver` 交易可以通过 `CheckTx` 但导致 `ProcessProposal` 拒绝整个区块。 +- 修复了系统交易欺骗路径，用户可以将 `MsgEthereumTx.From == 0x1` 设置为绕过身份验证并调用 только系统预编译，然后使用欺骗交易反复强制 `ProcessProposal` 拒绝块并停止共识。 +- 修复了内存池中毒链停机，其中 `ExtensionOptionsWaiver` 交易可以绕过 `CheckTx` 但导致 `ProcessProposal` 拒绝整个块。 -## 早期版本 +## 更早的版本 -详细的发布说明从 v1.2.1 开始。对于 v1.2.0 及更早的版本，包括创世版本，请参阅用于二进制文件、提交哈希和升级高度的版本历史表： +详细的发布说明从 v1.2.1 开始。对于 v1.2.0 和更早的版本，包括创世版本，请参阅版本历史记录表中的二进制文件、提交哈希和升级高度： -- [主网版本历史](/cn/reference/mainnet-version-history)：每个主网版本及其二进制文件和升级高度。 -- [测试网版本历史](/cn/reference/testnet-version-history)：每个测试网版本，包括发布候选版本。 +- [主网版本历史记录](/cn/reference/mainnet-version-history)：每个主网版本及其二进制文件和升级高度。 +- [测试网版本历史记录](/cn/reference/testnet-version-history)：每个测试网版本，包括发布候选版本。 ## 接下来去哪里 - [**升级节点**](/cn/how-to/upgrade-node)：按照分步过程将您的节点升级到新版本。 -- [**主网版本历史**](/cn/reference/mainnet-version-history)：查找每个主网版本的提交哈希、二进制文件和升级高度。 +- [**主网版本历史记录**](/cn/reference/mainnet-version-history)：查找每个主网版本的提交哈希、二进制文件和升级高度。 - [**主网信息**](/cn/reference/mainnet-information)：获取链 ID、RPC 端点和当前网络参数。 diff --git a/docs/pages/en/explanation/core-concepts.mdx b/docs/pages/en/explanation/core-concepts.mdx index 97f2155..45b22f6 100755 --- a/docs/pages/en/explanation/core-concepts.mdx +++ b/docs/pages/en/explanation/core-concepts.mdx @@ -28,9 +28,11 @@ Read more: [USDT0 as gas](/en/explanation/usdt-as-gas-token) · [USDT0 behavior ## Guaranteed blockspace -Stable reserves a portion of each block's capacity for pre-allocated enterprise workloads. Reserved traffic settles with predictable latency and cost even when general traffic is congested; it doesn't compete in the fee market. +Stable v1.4.0 can reserve a gas quota within each block for eligible priority workloads. Normal traffic cannot consume this VIP-lane capacity during congestion. -This behavior is transparent at the caller level. You submit transactions the normal way; allocations are applied at the protocol level for enrolled accounts. +Standard EVM transactions keep using the default nonce channel, `NonceKey = 0`. Eligible priority flows use `CustomTx` type `0x3F` and a protocol-reserved `NonceKey` that identifies the VIP lane. + +Governance configures the lanes and quotas. With no configuration, every transaction uses one normal lane. The feature is currently in the v1.4.0 Testnet release candidate, with its Mainnet schedule pending. Read more: [Guaranteed blockspace](/en/explanation/guaranteed-blockspace). diff --git a/docs/pages/en/explanation/execution.mdx b/docs/pages/en/explanation/execution.mdx index bc64781..6fd36fc 100755 --- a/docs/pages/en/explanation/execution.mdx +++ b/docs/pages/en/explanation/execution.mdx @@ -1,6 +1,6 @@ --- title: "Execution" -description: "Stable EVM parallel execution using Block-STM, Optimistic Block Processing, and future StableVM++ improvements." +description: "Understand how Stable executes transactions concurrently with Block-STM while preserving deterministic state." diataxis: "explanation" --- @@ -18,11 +18,11 @@ diataxis: "explanation" To bridge the gap between the Stable EVM and the Stable SDK, Stable EVM introduces a set of **precompiles**. These precompiles expose native Stable SDK module functionality to EVM smart contracts, enabling them to call into the core chain logic securely and atomically. Smart contracts can then perform privileged operations such as token transfers, staking, or governance participation. -## Future roadmap 1: Optimistic parallel execution +## Optimistic parallel execution in v1.4.0 Historically, blockchain systems have relied on sequential execution, where each transaction is processed one after another to ensure deterministic state across all nodes. While this design guarantees consistency, it severely limits throughput and scalability, especially as modern blockchains aim to support tens of thousands of transactions per second. -To overcome this constraint, Stable is adopting **Block-STM**, a proven parallel execution engine that enables **Optimistic Parallel Execution (OPE)**. This allows transactions to be executed in parallel while preserving determinism, significantly enhancing performance. +Stable v1.4.0 introduces **Optimistic Parallel Execution (OPE)** through Block-STM. Transactions execute concurrently across CPU cores, while a fixed in-block order keeps the final state deterministic. ### How Block-STM works @@ -75,7 +75,7 @@ Block-STM stores multiple versions of each memory key: alt="Optimistic Parallel Execution on Stable" /> -Stable will incorporate **Optimistic Parallel Execution (OPE)** as a core feature of its execution layer, in conjunction with **Optimistic Block Processing (OBP)**. Please note that OPE and OBP are complementary but fundamentally different strategies. +Stable combines OPE with **Optimistic Block Processing (OBP)**. The two optimizations address different work. ### About OBP @@ -83,20 +83,27 @@ Stable will incorporate **Optimistic Parallel Execution (OPE)** as a core featur - During the `ProcessProposal` stage, Stable pre-executes blocks while they are being gossiped to other nodes. - The resulting state is cached in memory and reused during `FinalizeBlock`, saving time and reducing duplicate computation. -By combining OPE and OBP, Stable can minimize both execution latency and resource contention, delivering superior performance under high transaction load. +OPE reduces execution time by using multiple CPU cores. OBP avoids executing the same block twice across proposal processing and finalization. -### Expected performance gains +### Post-commit recheck -Internal benchmarks suggest that with **Block-STM-based OPE** and **StableDB** integration, Stable can achieve **at least 2x throughput improvements** in end-to-end transaction processing. +After a block commits, CometBFT normally rechecks every transaction still waiting in the mempool. This repeated work can consume 31–34% of a node's CPU. -## Future roadmap 2: StableVM++ +Stable v1.4.0 adds **Selective RecheckTx**. The application returns the block's state-change delta, and the node rechecks only transactions from affected accounts. CometBFT detects application support and falls back to a full recheck when selective recheck is unavailable. + +In a best-case benchmark with 10,000 pending transactions from unique senders, throughput increased from 700 to 1,400 TPS. More typical workloads project a 1.5–1.7 times improvement. + +The CPU saved here becomes available to OPE workers. MemIAVL removes the storage bottleneck that could otherwise limit those execution gains. + +## Future roadmap: StableVM++ While efforts like Optimistic Parallel Execution (OPE) and Optimistic Block Processing (OBP) focus on optimizing *how multiple transactions are executed concurrently*, there’s another vital performance lever: **how efficiently each individual transaction is processed**. Stable is currently exploring alternative EVM implementations to boost execution speed. Among the candidates, **EVMONE**, a high-performance EVM written in C++, stands out as a strong contender to replace the existing Go-based EVM. This switch is projected to deliver up to a **6x increase in EVM execution performance** based on theoretical benchmarks. -## Next recommended +## Where to go next - [**Storage (StableDB)**](/en/explanation/stable-db): See how decoupled state commitment feeds execution without blocking on disk I/O. - [**High performance RPC**](/en/explanation/high-performance-rpc): Understand the split-path RPC that surfaces execution results to clients. - [**Ethereum compatibility**](/en/explanation/ethereum-compatibility): Port existing contracts using standard EVM tooling against Stable. +- [**Network upgrades**](/en/reference/network-upgrades): Review the complete v1.4.0 release scope and rollout notes. diff --git a/docs/pages/en/explanation/guaranteed-blockspace.mdx b/docs/pages/en/explanation/guaranteed-blockspace.mdx index e4251f3..5a58c3c 100755 --- a/docs/pages/en/explanation/guaranteed-blockspace.mdx +++ b/docs/pages/en/explanation/guaranteed-blockspace.mdx @@ -1,47 +1,68 @@ --- title: "Guaranteed blockspace" -description: "Guaranteed blockspace allocation giving enterprise partners reserved throughput capacity on the Stable network." +description: "Understand how Stable reserves per-lane gas capacity and identifies priority traffic through two-dimensional nonces." diataxis: "explanation" --- # Guaranteed blockspace -**Guaranteed Blockspace** is a dedicated blockspace-allocation model that reserves a fixed share of every block's capacity for enrolled enterprise partners, regardless of broader network conditions. Transactions routed through the guaranteed path execute with predictable latency and cost. Payroll, settlement, and supplier payments don't compete with public mempool traffic. +Stable v1.4.0 divides each block into lanes with separate gas budgets. Eligible priority transactions enter the VIP lane, so normal traffic cannot consume the capacity reserved for them. :::note -**Planned.** Guaranteed Blockspace is a forward-looking roadmap item. See [Roadmap](/en/explanation/technical-roadmap) for timing. +Guaranteed blockspace is live in the v1.4.0 Testnet release candidate. The Mainnet upgrade schedule is still pending. Without a governance configuration, every transaction continues to use one normal lane. ::: -## Why this matters +## Block lanes -General-purpose chains weren't designed for fee predictability under load: +The proposal and validation rules recognize three lane types: -- **Ethereum**: on May 1, 2022, the Yuga Labs "Otherside" NFT mint pushed peak gas above 8,000 gwei and burned over $200M in fees, breaking any workload that required deterministic cost. -- **Low-fee networks** like Solana and Base attract MEV and arbitrage spam, so legitimate transactions compete with bot traffic for inclusion. +- **VIP lane**: carries transactions whose `NonceKey` is in the protocol-reserved range. +- **Transaction-type lane**: reserves capacity for a configured transaction category. +- **Normal lane**: carries standard transactions that do not match another configured lane. -![Source: MEV and the Limits of Scaling by Flashbots and Robert Miller](/images/share-of-gas.png) +Each lane has its own gas quota. A proposer fills the lanes within those limits, and validators enforce the same limits when they validate the proposed block. -*Source: MEV and the Limits of Scaling by Flashbots and Robert Miller* +This makes the reservation deterministic at the protocol level. It does not depend on a proposer voluntarily leaving space unused. -Enterprise payment flows can't tolerate this variance. Guaranteed Blockspace addresses it directly. +## Two-dimensional nonces -## How the guarantee works +An Ethereum account normally has one nonce sequence. If transaction 12 is missing or stuck, transactions 13 and later cannot execute. -The guarantee is enforced at three layers: +A **two-dimensional nonce**, or 2D nonce, gives the account multiple independent sequences. `NonceKey` selects the sequence, and the transaction's nonce gives its position within that sequence. -- **Guaranteed mempool**: validators pull guaranteed transactions from a dedicated mempool, isolated from public traffic. -- **Validator-level reservation**: each validator reserves a predefined portion of every block's gas capacity for the guaranteed lane. Deterministic inclusion falls out of this. -- **Dedicated RPC nodes**: the Guaranteed Blockspace API routes transactions through isolated RPC endpoints, so submission latency doesn't spike with public RPC load. +For example, a payment account could use `NonceKey = 1` for payroll and `NonceKey = 2` for supplier settlements. A delayed payroll transaction would not block the supplier sequence. -The result, for an enrolled partner: +The nonce-key space has three important regions: -- **Exclusive routing path**: submissions don't compete with public mempool traffic. -- **Guaranteed inclusion**: capacity is reserved in every block regardless of network congestion. -- **No decentralization trade-off**: validator openness and network participation are preserved; the guarantee lives alongside the public lane, not above it. -- **Reliable on-chain performance** for business-critical operations, even under load. +- `NonceKey = 0` keeps the standard EVM-compatible nonce behavior. +- The upper half of the `uint64` range is reserved for protocol use. VIP membership is signaled through this range. +- `NonceKey = MaxUint64` marks an unordered transaction. `TimeoutTimestamp` provides its replay-protection deadline. -## Next recommended +Stable carries these fields in `CustomTx`, transaction type `0x3F`. Existing EVM transaction formats remain available, and the default nonce channel preserves their expected behavior. + +## Governance and activation + +Governance controls the lane definitions and gas quotas through one `MsgUpdateParams` proposal. Accepted parameters take effect at the next block. + +The defaults contain no reserved lanes. Until governance configures them, the chain behaves as one normal lane. This makes lane configuration additive to existing transaction processing. + +## Guarantee boundaries + +VIP transactions receive deterministic next-block inclusion when all of these conditions hold: + +- The transaction is eligible for the VIP lane. +- The lane has enough reserved gas for the transaction. +- Validators follow the protocol. +- The network remains synchronous enough for validators to receive the transaction before proposal. + +Stable's mempool-less validator ingress model supplies VIP transactions to validators. Reserved proposal capacity then prevents normal traffic from displacing them. + +:::note +The gas-waiving transaction-type lane is deferred. A lane with `gasPrice = 0` needs trusted admission control; otherwise, an attacker could flood it with free transactions. +::: + +## Where to go next - [**Guaranteed settlement**](/en/explanation/upcoming-use-cases): See the payment pattern that depends on guaranteed blockspace: timed DvP settlement cycles with deterministic inclusion. -- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the asset that flows through guaranteed blockspace. -- [**Tokenomics**](/en/reference/tokenomics): Review how STABLE staking underpins validator blockspace guarantees. +- [**Network upgrades**](/en/reference/network-upgrades): Review the full v1.4.0 release and its rollout status. +- [**Execution**](/en/explanation/execution): Understand how Stable executes the transactions selected for each block. diff --git a/docs/pages/en/explanation/stable-db.mdx b/docs/pages/en/explanation/stable-db.mdx index 1b5136d..ffbcf61 100755 --- a/docs/pages/en/explanation/stable-db.mdx +++ b/docs/pages/en/explanation/stable-db.mdx @@ -1,21 +1,23 @@ --- title: "Storage (StableDB)" -description: "StableDB architecture using decoupled state commitment, MemDB, and mmap to eliminate disk I/O bottlenecks." +description: "Understand how MemIAVL stores current state with memory-mapped snapshots and a sequential write-ahead log." diataxis: "explanation" --- # Storage (StableDB) -One of the main bottlenecks in end-to-end blockchain performance is **Disk I/O**. Specifically, committing and storing state data after block execution creates the key bottleneck. Stable tackles this problem with architectural innovations such as `MemDB`, `VersionDB`, and memory-mapped storage (`mmap`) to dramatically improve throughput. +Stable v1.4.0 replaces the LevelDB-backed state store with MemIAVL. MemIAVL keeps one state snapshot in a memory-mapped file and records each new block's changes in a sequential write-ahead log. -## Why disk I/O is a bottleneck +:::note +MemIAVL is live in the v1.4.0 Testnet release candidate. The Mainnet upgrade schedule is still pending. Track [Network upgrades](/en/reference/network-upgrades) for rollout status. +::: -### State transition and persistence +## Why disk I/O is a bottleneck -Every time a block of transactions is executed, the blockchain transitions from one state to the next. This process has two fundamental stages: +Every block changes the application state. A node must complete two related tasks: -1. **State Commitment**: The new application state is committed after transaction execution. -2. **State Storage**: The committed state is persisted to disk for long-term access and historical verification. +1. **State commitment**: calculate and commit the root hash for the new state. +2. **State persistence**: write the changed data to storage so the node can recover it later. Coupled State Commitment and Storage -In conventional architectures, state storage is **tightly coupled** with state commitment. This means that: +The previous LevelDB-backed store coupled these tasks. It also rewrote data during background compaction, which reorganizes stored records to make later reads efficient. -- The node must wait for the new state to be fully stored on disk before proceeding with the next block's execution. -- The state data is written in random disk locations that are not mapped to fixed addresses. This leads to high latency when retrieving state data during execution of subsequent transactions. +One logical state update could cause 10–50 times as much physical disk writing. This is called **write amplification**. Execution then had to wait for a storage path dominated by random writes and compaction. -Even if consensus and execution layers are heavily optimized, this serialized dependency on slow disk operations caps the achievable performance of the entire system. +## How MemIAVL changes the store -## Optimizing DB operations for higher throughput +A memory-mapped file, or `mmap`, lets the operating system expose file contents through memory addresses. The node can read state by following pointers, while the operating system loads the required pages into its page cache. -To overcome these limitations, Stable proposes a two-fold architectural enhancement focused on **decoupling state operations** and **introducing memory-mapped DB optimizations**. +MemIAVL combines two structures: -### 1. Decoupling state commitment and storage +- **Snapshot**: one memory-mapped representation of the persisted state tree. +- **Write-ahead log (WAL)**: an append-only record of raw changes made after that snapshot. Decoupled State Commitment and Storage -The first step is to decouple the state commitment from its storage: +### Write path + +Each block appends its change set to the WAL in sequence. MemIAVL does not route the update through LevelDB or trigger compaction. Write amplification therefore falls from 10–50 times to approximately one write. + +MemIAVL also separates tree nodes into two categories: + +- `PersistedNode` represents an unchanged subtree already stored in the snapshot. +- `MemNode` represents a subtree changed in memory by the current updates. + +When MemIAVL calculates the next root hash, it stops at unchanged `PersistedNode` subtrees. It hashes only the paths containing new `MemNode` data. + +### Read path -- After committing a new state, the node immediately proceeds to execute the next block. -- The actual persistence of state to disk occurs asynchronously in the background. +Current-state reads follow pointers into the memory-mapped snapshot. Frequently accessed pages remain in the operating system's page cache, so the node avoids a separate database lookup for each tree node. -This separation allows execution to happen instantly and leapfrog the latency of slow disk writes, thereby eliminating blocking dependencies and eventually improving end-to-end performance. +## Historical state and VersionDB -### 2. Introducing `MemDB` and `VersionDB` via `mmap` +MemIAVL serves the current state and the snapshots a node retains. A companion VersionDB stores historical versions in a RocksDB sidecar. -Stable enhances this with a dual-database model powered by `mmap` (memory-mapped file access): +You need VersionDB when the node must answer historical state queries older than its earliest retained MemIAVL snapshot. This is especially important for archive nodes and RPC services that expose long-range queries. -- **MemDB (Memory DB)**: - - Stores recent and active states that are frequently accessed. - - Uses fixed address mapping via `mmap`, enabling fast and deterministic lookups. - - Ideal for most transaction workloads which target recently modified state. -- **VersionDB (Historical DB)**: - - Stores older, historical states on disk. - - Optimized for archival and long-range queries, not for high-frequency access. +## Migration considerations -This design ensures that **hot data is served from fast, memory-resident structures**, while cold data is offloaded to slower, persistent storage. By combining `mmap` access with smart state tiering, Stable can significantly reduce the DB read/write latency during block execution. +Existing nodes must migrate their LevelDB state when they adopt v1.4.0. The recommended path is a local snapshot export and restore. -## Expected gains and precedents +Benchmarks measured an average of 19.4 seconds of downtime per validator for the standard restore. A parallel restore variant reduced the average to approximately 2.6 seconds. -This architectural optimization is not just theoretical. It is already being implemented by high-performance blockchains such as Sei and Cronos. Both have adopted similar decoupled architectures with memory-mapped DBs and have observed **up to 2x increases in overall TPS**. +Validators can migrate one at a time in round-robin order. Keeping at least two-thirds of voting power online lets the network continue producing blocks during the migration. -Stable also anticipates comparable gains, as the architecture will no longer be bottlenecked by the storage layer. Instead, consensus and execution performance can scale without being throttled by disk operations. +:::warning +These times are benchmark results, not a downtime guarantee. Follow the network-specific upgrade instructions for the final binary, upgrade height, backup, and restore commands. +::: ## Further reading @@ -78,8 +86,9 @@ For more technical deep-dives and implementation details, refer to: - [Cronos MemIAVL Node Configuration](https://docs.cronos.org/for-node-hosts/running-nodes/memiavl) - [Sei’s DB Design Approach](https://4pillars.io/ko/articles/sei-db) -## Next recommended +## Where to go next - [**High performance RPC**](/en/explanation/high-performance-rpc): See how the RPC layer exposes state reads without contending with writes. - [**Execution**](/en/explanation/execution): Understand how execution writes into the storage layer covered here. -- [**Consensus**](/en/explanation/consensus): Review the consensus layer that orders blocks before they reach storage. +- [**Upgrade a node**](/en/how-to/upgrade-node): Prepare backups and verify a node after a coordinated upgrade. +- [**Network upgrades**](/en/reference/network-upgrades): Review the complete v1.4.0 scope and rollout status. diff --git a/docs/pages/en/explanation/tech-overview.mdx b/docs/pages/en/explanation/tech-overview.mdx index d71b320..66c5144 100755 --- a/docs/pages/en/explanation/tech-overview.mdx +++ b/docs/pages/en/explanation/tech-overview.mdx @@ -7,7 +7,7 @@ diataxis: "explanation" # Tech overview :::note -**What's live today:** StableBFT consensus, Stable EVM (full EVM compatibility), and the split-path RPC layer are all production-ready. StableDB ships in the v1.4.0 upgrade. Autobahn (DAG-based consensus) and StableVM\+\+ (optimistic parallel execution) are roadmap items. See the [Roadmap](/en/explanation/technical-roadmap) for timelines. +**Release status:** StableBFT, the sequential Stable EVM, and the split-path RPC layer are live on Mainnet. OPE, Selective RecheckTx, MemIAVL, 2D nonce, and guaranteed blockspace are in the v1.4.0 Testnet release candidate. The Mainnet upgrade schedule is pending. ::: You can deploy Solidity or Vyper contracts on Stable today using Hardhat, Foundry, or any standard EVM tooling, and your contracts work without modification. What changes: gas is paid in USDT0, transactions reach single-slot finality, and every layer of the stack is tuned for stablecoin throughput. @@ -35,14 +35,16 @@ Stable Blockchain leverages **StableBFT**, a customized PoS consensus protocol b **Stable EVM** is Stable's Ethereum-compatible execution layer. Standard Ethereum tools and wallets interact with the chain unchanged. A set of **precompiles** bridges Stable EVM to the Stable SDK, letting EVM smart contracts call into core chain logic atomically. :::note -**Planned:** **StableVM\+\+** with optimistic parallel execution (Block-STM). See the [Roadmap](/en/explanation/technical-roadmap#phase-3-full-stack-optimized-layer-for-usdt). +**Included in v1.4.0:** Block-STM adds optimistic parallel execution across CPU cores. Selective RecheckTx reduces post-commit mempool work. See [Execution](/en/explanation/execution). ::: +StableVM\+\+, a possible replacement for the current Go-based EVM implementation, remains a later roadmap item. + ## StableDB -**Status: Ships in v1.4.0** +**Status: v1.4.0 release candidate on Testnet** -Stable fixes a major blockchain bottleneck: slow disk storage after each block. It separates state commitment from storage so blocks process without delay. `MemDB` and `VersionDB`, powered by `mmap`, keep recent data in memory while older data is stored efficiently, boosting overall throughput. +MemIAVL replaces LevelDB with a memory-mapped snapshot and an append-only write-ahead log. A RocksDB-backed VersionDB serves historical queries older than the retained snapshots. ## High performance RPC @@ -52,4 +54,11 @@ A slow RPC layer ruins the user experience even on a fast chain. Stable addresse :::note **Planned:** RPC nodes optimized for EVM view calls, plus a node-integrated indexer. See the [Roadmap](/en/explanation/technical-roadmap#phase-3-full-stack-optimized-layer-for-usdt). -::: \ No newline at end of file +::: + +## Where to go next + +- [**Execution**](/en/explanation/execution): Understand how OPE and Selective RecheckTx remove CPU bottlenecks. +- [**Storage (StableDB)**](/en/explanation/stable-db): See how MemIAVL changes current and historical state storage. +- [**Guaranteed blockspace**](/en/explanation/guaranteed-blockspace): Understand the 2D nonce and block-lane model. +- [**Network upgrades**](/en/reference/network-upgrades): Review v1.4.0 compatibility, rollout, and deferred work. diff --git a/docs/pages/en/explanation/technical-roadmap.mdx b/docs/pages/en/explanation/technical-roadmap.mdx index 669bf74..e46692a 100755 --- a/docs/pages/en/explanation/technical-roadmap.mdx +++ b/docs/pages/en/explanation/technical-roadmap.mdx @@ -32,23 +32,27 @@ Stable Pay is a Web2.5 UX wallet experience designed to simplify onboarding for ## Phase 2: Experience layer for USDT -Status: **In development.** State DB optimization ships in the v1.4.0 upgrade. The remaining items are still in development. +Status: **v1.4.0 release candidate on Testnet.** The Mainnet upgrade schedule is pending. The USDT Transfer Aggregator remains in development. -### State DB optimization: Ships in v1.4.0 +### MemIAVL state store: Included in v1.4.0 -Stable decouples state commitment from state storage. Validators commit the latest state in memory while historical state is deferred to disk. `MemDB` and `VersionDB` powered by `mmap` handle real-time commitment without blocking on disk I/O. See [Storage (StableDB)](/en/explanation/stable-db). +MemIAVL replaces LevelDB with one memory-mapped snapshot and an append-only write-ahead log. A RocksDB-backed VersionDB serves historical queries older than the retained snapshots. See [Storage (StableDB)](/en/explanation/stable-db). -### Optimistic parallel execution: Planned +### Optimistic parallel execution: Included in v1.4.0 -Real-world telemetry shows 60–80% of transactions interact with disjoint state and can safely execute in parallel. Stable will execute transactions optimistically under the no-conflict assumption, with rollback and sequential re-execution on detected conflicts. This preserves correctness while improving throughput. +Block-STM executes transactions concurrently across CPU cores, detects conflicts, and re-executes affected work. A fixed in-block order preserves deterministic state across validators. See [Execution](/en/explanation/execution). -### USDT Transfer Aggregator: Planned +### Selective RecheckTx: Included in v1.4.0 -Aggregating mechanism that groups USDT0 transfers and processes them collectively, reducing per-transaction overhead and improving overall throughput. See [USDT transfer aggregator](/en/explanation/usdt-transfer-aggregator). +After a block commits, the node rechecks only pending transactions from affected accounts. CometBFT falls back to a full mempool recheck when application support is unavailable. + +### 2D nonce and guaranteed blockspace: Included in v1.4.0 -### Guaranteed blockspace: Planned +Independent nonce channels prevent one stuck transaction from blocking every later transaction from the same account. Protocol-reserved nonce keys identify VIP traffic, while per-lane gas quotas reserve block capacity. See [Guaranteed blockspace](/en/explanation/guaranteed-blockspace). -Reserved block capacity for enterprise partners, enforced through validator-level reservations and dedicated RPC endpoints. Delivers predictable latency for mission-critical payment flows even under network congestion. See [Guaranteed blockspace](/en/explanation/guaranteed-blockspace). +### USDT Transfer Aggregator: Planned + +Aggregating mechanism that groups USDT0 transfers and processes them collectively, reducing per-transaction overhead and improving overall throughput. See [USDT transfer aggregator](/en/explanation/usdt-transfer-aggregator). ## Phase 3: Full-stack optimized layer for USDT diff --git a/docs/pages/en/how-to/upgrade-node.mdx b/docs/pages/en/how-to/upgrade-node.mdx index e18a088..c05435b 100755 --- a/docs/pages/en/how-to/upgrade-node.mdx +++ b/docs/pages/en/how-to/upgrade-node.mdx @@ -23,6 +23,18 @@ This guide covers the upgrade process for Stable nodes, including upgrade proced - Immediate action required - May require chain halt +## v1.4.0 storage migration + +v1.4.0 replaces the LevelDB-backed state store with MemIAVL. This upgrade requires a data migration in addition to the normal binary replacement. + +Use a local snapshot export and restore unless the network-specific upgrade instructions choose another method. Benchmarking measured 19.4 seconds of average validator downtime for the standard restore and approximately 2.6 seconds for a parallel restore. + +Migrate validators in round-robin order so at least two-thirds of voting power stays online. Configure the RocksDB-backed VersionDB if your node must answer historical queries older than its earliest retained snapshot. + +:::warning +Do not use the generic binary-only procedure below for v1.4.0. Wait for the final network-specific binary, upgrade height, backup path, and restore commands in [Network upgrades](/en/reference/network-upgrades). +::: + ## Standard upgrade procedure ### Step 1: preparation @@ -245,4 +257,4 @@ stabled export --height > export.json - [Version History](/en/reference/testnet-version-history) - Complete upgrade history and release notes - [Monitor your node](/en/how-to/monitor-node) after upgrades -- Review [Troubleshooting](/en/how-to/troubleshoot-node) for common issues \ No newline at end of file +- Review [Troubleshooting](/en/how-to/troubleshoot-node) for common issues diff --git a/docs/pages/en/reference/network-upgrades.mdx b/docs/pages/en/reference/network-upgrades.mdx index 61ebe51..cdcb426 100755 --- a/docs/pages/en/reference/network-upgrades.mdx +++ b/docs/pages/en/reference/network-upgrades.mdx @@ -32,12 +32,49 @@ v1.3.1 A performance and predictability release, currently live on Testnet as a release candidate and not yet on Mainnet. It groups four changes under two themes: making blocks process faster, and making transaction inclusion more predictable for priority traffic. -**What's coming:** +| **Initiative** | **Block stage** | **What changes** | **Intended result** | +| :--- | :--- | :--- | :--- | +| Optimistic parallel execution (OPE) | Execution | Block-STM replaces sequential transaction execution. | Multicore execution, targeting approximately 10,000 TPS. | +| Selective RecheckTx | Post-commit mempool recheck | The node rechecks transactions only from accounts changed by the committed block. | Up to twice the sustained throughput in the measured best case, with 31–34% less node CPU use. | +| MemIAVL | State persistence | A memory-mapped snapshot and write-ahead log (WAL) replace the LevelDB-backed store. | Write amplification falls from 10–50 times to approximately one write. | +| 2D nonce and guaranteed blockspace | Submission and block proposal | Independent nonce channels combine with reserved per-lane gas capacity. | Deterministic next-block inclusion for eligible VIP transactions. | -- **Optimistic parallel execution (OPE)**: executes the transactions in a block in parallel instead of one at a time, then reconciles the results. This is based on Block-STM. -- **Selective RecheckTx**: after a new block, only re-validates the pending transactions actually affected by it, rather than the entire mempool (the pool of transactions waiting to be included). -- **MemIAVL**: a memory-mapped storage layer that replaces the previous LevelDB-based store, reducing a major bottleneck in the block lifecycle. -- **2D nonce and guaranteed blockspace**: parallel nonce channels let one account send transactions on multiple independent lanes, and guaranteed blockspace reserves block capacity for priority workloads instead of leaving inclusion to chance. +These changes address different stages of one block lifecycle: + +1. **Submission**: a 2D nonce lets an account submit transactions through independent nonce channels. A stuck transaction on one channel does not block the others. +2. **Proposal**: guaranteed blockspace divides a block into VIP, transaction-type, and normal lanes. Each lane has a reserved gas budget enforced during proposal and validation. +3. **Execution**: OPE runs transactions concurrently through Block-STM, then validates them against a fixed in-block order. Every node still produces the same state. +4. **Commit**: MemIAVL appends changes to a WAL against one memory-mapped snapshot. This avoids LevelDB compaction and its repeated disk writes. +5. **Post-commit recheck**: Selective RecheckTx uses the block's state-change delta to recheck only affected senders instead of scanning the full mempool. + +### Throughput changes + +OPE moves transaction execution from one CPU core to multiple cores. Transactions execute optimistically, conflicts trigger re-execution, and the fixed transaction order preserves deterministic results. + +Selective RecheckTx removes work after each commit. In a best-case test with 10,000 pending transactions from unique senders, throughput increased from 700 to 1,400 TPS. The projected improvement for more typical workloads is 1.5–1.7 times. CometBFT detects whether the application supports selective recheck and falls back to full recheck when it does not. + +MemIAVL removes LevelDB from the state-store path. Writes become sequential WAL entries containing raw change sets. Reads become pointer lookups into the operating system's page cache. A separate VersionDB, backed by RocksDB, serves historical state older than the earliest retained snapshot. + +### Predictable inclusion + +A 2D nonce gives each account multiple independent nonce channels. `NonceKey` selects the channel. `NonceKey = 0` preserves the normal EVM-compatible sequence, while the protocol reserves the upper half of the `uint64` range for its own use. `MaxUint64` marks an unordered transaction, which uses `TimeoutTimestamp` for replay protection. + +The release adds `CustomTx`, transaction type `0x3F`, alongside existing EVM transaction formats. The protocol-reserved `NonceKey` range also identifies VIP-lane transactions. + +Guaranteed blockspace divides each block into VIP, transaction-type, and normal lanes with separate gas quotas. Governance controls the lane parameters through one `MsgUpdateParams` proposal, and an accepted update takes effect in the next block. With no lane configuration, the chain behaves as one normal lane. + +Eligible VIP transactions receive deterministic next-block inclusion when validators behave honestly and the network remains synchronous. Read [Guaranteed blockspace](/en/explanation/guaranteed-blockspace) for the lane and nonce model. + +### Node rollout + +MemIAVL changes the state store, so node operators must migrate their existing data. The recommended method is a local snapshot export and restore. Benchmarks measured an average of 19.4 seconds of downtime per validator. A parallel restore variant reduced that average to approximately 2.6 seconds. + +Validators can migrate in round-robin order to preserve at least two-thirds of voting power. Follow the network-specific upgrade instructions rather than treating the benchmark procedure as a fixed runbook. + +### Deferred work + +- **Gas-waiving transaction-type lane**: a zero-gas lane needs trusted mempool admission control. Without it, an attacker could submit unlimited free transactions. +- **Sender-matching optimization**: a later release may let full nodes send precomputed sender addresses with transactions, avoiding repeated signature recovery during block proposal. :::note v1.4.0 is still in audit and testing. Scope and timing may change before the Mainnet upgrade. Track the [Testnet version history](/en/reference/testnet-version-history) for the latest release candidate. diff --git a/docs/pages/ko/explanation/core-concepts.mdx b/docs/pages/ko/explanation/core-concepts.mdx index a59e5a4..1e3afa0 100755 --- a/docs/pages/ko/explanation/core-concepts.mdx +++ b/docs/pages/ko/explanation/core-concepts.mdx @@ -1,20 +1,20 @@ --- source_path: explanation/core-concepts.mdx -source_sha: 97f2155b7916504732f1b78674bbf3ec1909e8e2 +source_sha: 45b22f6b8de51a67dbe1ed9ffb14d57302775f8c title: "핵심 개념" -description: "Stable을 구축하기 전에 USDT0를 가스로 사용, 보장된 블록 공간, 전송 집계 및 EVM 호환성이라는 Stable의 네 가지 핵심 개념을 이해하세요." +description: "Stable을 구축하기 전에 USDT0를 Gas로 사용, 보장된 블록 공간, 전송 집계 및 EVM 호환성이라는 4가지 핵심 개념을 이해하세요." diataxis: "explanation" --- # 핵심 개념 -네 가지 개념만 알면 구축을 시작할 수 있습니다. 각 섹션에서는 개념을 정의하고, 이를 보여주며, 전체 참조로 연결합니다. +4가지 개념만 알아도 구축을 시작할 수 있습니다. 각 섹션에서는 개념을 정의하고, 보여주고, 전체 참조에 연결합니다. -## USDT0을 가스로 사용 +## Gas로 USDT0 사용 -현재 보유하고 거래하는 자산과 동일한 USDT0로 거래 수수료를 지불합니다. 자금을 조달하거나 관리해야 할 두 번째 토큰은 없습니다. +거래 수수료는 이미 보유하고 거래하고 있는 자산과 동일한 USDT0로 지불합니다. 자금을 조달하거나 관리할 두 번째 토큰은 없습니다. -USDT0는 기본 가스 자산(18진수, `address(x).balance`를 통해 읽음)이자 ERC-20 토큰(6진수, `USDT0.balanceOf(x)`를 통해 읽음)입니다. 두 인터페이스 모두 동일한 기본 잔액에서 작동하며, 프로토콜은 12자리 정밀도 차이를 자동으로 조정합니다. +USDT0는 네이티브 Gas 자산(18진수, `address(x).balance`를 통해 읽음)이자 ERC-20 토큰(6진수, `USDT0.balanceOf(x)`를 통해 읽음)입니다. 두 인터페이스는 동일한 기본 잔액에서 작동하며, 프로토콜은 12자리 정밀도 차이를 자동으로 조정합니다. ```solidity // 둘 다 동일한 잔액을 읽습니다: @@ -23,34 +23,36 @@ uint256 erc20 = IERC20(USDT0).balanceOf(user); // 6 decimals ``` :::warning -잔액 조정은 예비 주소 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5`에서 추가 `Transfer` 이벤트를 발생시킵니다. `Transfer` 이벤트를 재생하는 인덱서는 이 주소로의 전송을 필터링해야 합니다. 그렇지 않으면 잔액이 조용히 두 번 계산됩니다. +잔액 조정은 예비 주소 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5`에서 추가 `Transfer` 이벤트를 발생시킵니다. `Transfer` 이벤트를 재생하는 인덱서 (Indexer)는 이 주소로의 전송 및 이 주소로부터의 전송을 필터링해야 합니다. 그렇지 않으면 잔액이 자동으로 이중으로 계산됩니다. ::: -자세히 보기: [가스로 USDT0](/ko/explanation/usdt-as-gas-token) · [Stable에서 USDT0 동작](/ko/explanation/usdt0-behavior). +더 읽어보기: [Gas 토큰으로서의 USDT0](/ko/explanation/usdt-as-gas-token) · [Stable에서의 USDT0 동작](/ko/explanation/usdt0-behavior). ## 보장된 블록 공간 -Stable은 사전 할당된 기업 워크로드를 위해 각 블록 용량의 일부를 예약합니다. 예약된 트래픽은 일반 트래픽이 혼잡한 경우에도 예측 가능한 지연 시간과 비용으로 정산됩니다. 이는 수수료 시장에서 경쟁하지 않습니다. +Stable v1.4.0은 각 블록 내에서 적격 우선 작업 부하에 대한 Gas 할당량을 예약할 수 있습니다. 일반 트래픽은 혼잡 시 이 VIP-레인 용량을 사용할 수 없습니다. -이 동작은 호출자 수준에서 투명합니다. 거래는 일반적인 방식으로 제출되며, 등록된 계정에 대해서는 프로토콜 수준에서 할당이 적용됩니다. +표준 EVM 트랜잭션은 기본 논스 채널 `NonceKey = 0`을 계속 사용합니다. 적격 우선 흐름은 `CustomTx` 유형 `0x3F` 및 VIP 레인을 식별하는 프로토콜 예약 `NonceKey`를 사용합니다. -자세히 보기: [보장된 블록 공간](/ko/explanation/guaranteed-blockspace). +거버넌스는 레인과 할당량을 구성합니다. 구성 없이는 모든 트랜잭션이 하나의 일반 레인을 사용합니다. 이 기능은 현재 v1.4.0 테스트넷 릴리스 후보에 있으며, 메인넷 일정은 보류 중입니다. + +더 읽어보기: [보장된 블록 공간](/ko/explanation/guaranteed-blockspace). ## USDT 전송 집계기 -대용량 USDT0 전송은 MapReduce에서 영감을 받은 파이프라인을 사용하여 병렬로 일괄 처리되고 확인됩니다. 계정별 오류는 격리되므로 하나의 잘못된 전송이 일괄 처리를 중단시키지 않습니다. +대용량 USDT0 전송은 MapReduce에서 영감을 받은 파이프라인을 사용하여 일괄 처리되고 병렬로 검증됩니다. 계정별 실패가 격리되므로 하나의 잘못된 전송이 배치를 중단시키지 않습니다. -호출자 측 전송 API는 변경되지 않습니다. 코드를 변경하지 않고도 일반적인 방식으로 전송을 제출하고 처리량을 확보할 수 있습니다. +호출자 측 전송 API는 변경되지 않습니다. 코드를 변경하지 않고도 일반적인 방식으로 전송을 제출하고 처리량을 얻습니다. -자세히 보기: [USDT 전송 집계기](/ko/explanation/usdt-transfer-aggregator). +더 읽어보기: [USDT 전송 집계기](/ko/explanation/usdt-transfer-aggregator). ## EVM 호환성 -표준 EVM 툴링은 변경 없이 작동합니다. EVM 수준에서 세 가지 동작이 이더리움과 다릅니다(위에서 다룬 가스로서의 USDT0가 네 번째). +표준 EVM 툴링은 변경 없이 작동합니다. EVM 레벨에서 세 가지 동작이 이더리움과 다릅니다(위에서 다룬 Gas로서의 USDT0는 네 번째입니다). -**단일 슬롯 완결성.** 거래는 블록에 포함되면 최종적입니다. 블록은 대략 0.7초마다 생성됩니다. +**단일 슬롯 완결성.** 트랜잭션은 블록에 포함되면 최종적입니다. 블록은 약 0.7초마다 생성됩니다. -**우선순위 팁 없음.** `maxPriorityFeePerGas`는 항상 무시됩니다. 실제 가스 가격은 프로토콜에 의해 설정된 기본 수수료입니다. +**우선순위 팁 없음.** `maxPriorityFeePerGas`는 항상 무시됩니다. 유효 Gas 가격은 프로토콜에 의해 설정된 기본 수수료입니다. ```typescript import { ethers } from "ethers"; @@ -61,8 +63,8 @@ const baseFee = block.baseFeePerGas; const tx = await wallet.sendTransaction({ to: "0xRecipientAddress", value: ethers.parseEther("0.1"), - maxFeePerGas: baseFee * 2n, // 2x base fee as safety margin - maxPriorityFeePerGas: 0n, // always 0 on Stable + maxFeePerGas: baseFee * 2n, // 안전 마진으로 기본 수수료의 2배 + maxPriorityFeePerGas: 0n, // Stable에서는 항상 0 }); await tx.wait(); @@ -70,26 +72,26 @@ console.log("Included at gas price:", tx.gasPrice?.toString()); ``` ```text -Included at gas price: 1000000000 +Include at gas price: 1000000000 ``` -**이중 역할 USDT0, 포팅 위험.** 이더리움에서 포팅된 계약은 기본 잔액을 미러링해서는 안 되며, `address(0)` 전송을 거부해야 하며, 주소 재사용 감지를 위해 `EXTCODEHASH`에 의존해서는 안 됩니다. +**이중 역할 USDT0, 포팅 위험.** 이더리움에서 포팅된 계약은 네이티브 잔액을 미러링하지 않고, `address(0)` 전송을 거부해야 하며, 주소 재사용 감지를 위해 `EXTCODEHASH`에 의존해서는 안 됩니다. :::warning -내부 변수에 기본 잔액을 미러링하는 Contract를 Stable로 포팅하는 것은 안전하지 않습니다. 외부 `USDT0.transferFrom` 호출은 Contract 코드를 호출하지 않고 Contract의 기본 잔액을 소진할 수 있습니다. 전송 시 항상 `address(this).balance`로 지급 능력을 확인하십시오. +내부 변수에 네이티브 잔액을 미러링하는 계약을 포팅하는 것은 Stable에서 안전하지 않습니다. 외부 `USDT0.transferFrom` 호출은 계약 코드를 호출하지 않고 계약의 네이티브 잔액을 소진할 수 있습니다. 전송 시 항상 `address(this).balance`로 지급 능력(solvency)을 확인하십시오. ::: 더 읽어보기: [이더리움과의 차이점](/ko/explanation/ethereum-comparison) · [Stable의 계약](/ko/explanation/contracts-overview) · [USDT0 마이그레이션 체크리스트](/ko/explanation/usdt0-behavior). -## 기밀 전송 (계획됨) +## 기밀 전송 (계획 중) -Stable은 승인된 당사자가 감사할 수 있는 상태를 유지하면서 금액을 숨기는 영지식 전송을 위한 기능을 계획하고 있습니다. 아직 출시되지 않았습니다. +Stable은 승인된 당사자가 감사할 수 있으면서도 금액을 숨기는 영지식 전송을 위한 기능을 계획하고 있습니다. 아직 출시되지 않았습니다. 더 읽어보기: [기밀 전송](/ko/explanation/confidential-transfer). -## 다음 권장 사항 +## 다음 추천 항목 - [**빠른 시작**](/ko/tutorial/quick-start): 테스트넷에 연결하고 첫 번째 트랜잭션을 보냅니다. -- [**USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 문제 없이 계약을 Stable로 포팅합니다. -- [**가스 가격 책정**](/ko/reference/gas-pricing-api): Stable의 수수료 모델에서 트랜잭션을 올바르게 구성합니다. -- [**운영 준비 완료**](/ko/how-to/production-readiness): 메인넷에 출시하기 전에 통합을 검증합니다. +- [**USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 문제점 없이 Stable로 계약을 포팅합니다. +- [**Gas 가격 책정**](/ko/reference/gas-pricing-api): Stable의 수수료 모델에서 트랜잭션을 올바르게 구성합니다. +- [**프로덕션 준비 상태**](/ko/how-to/production-readiness): 메인넷에 출시하기 전에 통합을 검증합니다. diff --git a/docs/pages/ko/explanation/execution.mdx b/docs/pages/ko/explanation/execution.mdx index db98399..9a65826 100755 --- a/docs/pages/ko/explanation/execution.mdx +++ b/docs/pages/ko/explanation/execution.mdx @@ -1,8 +1,8 @@ --- source_path: explanation/execution.mdx -source_sha: bc64781e476fda556f242c5ec924b0e026a13f33 +source_sha: 6fd36fc5aba0418235d67180f61d452cae54c8a7 title: "실행" -description: "Block-STM, 낙관적 블록 처리, 향후 StableVM++ 개선 사항을 이용한 Stable EVM 병렬 실행입니다." +description: "Stable이 결정론적 상태를 유지하면서 Block-STM으로 트랜잭션을 동시적으로 실행하는 방법을 이해해 보세요." diataxis: "explanation" --- @@ -16,89 +16,96 @@ 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은 **프리컴파일** 세트를 도입합니다. 이 프리컴파일은 네이티브 Stable SDK 모듈 기능을 EVM 스마트 계약에 노출하여 핵심 체인 로직을 안전하고 원자적으로 호출할 수 있도록 합니다. 그러면 스마트 계약은 토큰 전송, 스테이킹 또는 거버넌스 참여와 같은 권한 있는 작업을 수행할 수 있습니다. -## 미래 로드맵 1: 낙관적 병렬 실행 +## v1.4.0의 낙관적 병렬 실행 -역사적으로 블록체인 시스템은 순차적 실행에 의존해 왔습니다. 각 트랜잭션은 모든 노드에서 결정론적 상태를 보장하기 위해 하나씩 처리되었습니다. 이러한 설계는 일관성을 보장하지만, 특히 현대 블록체인이 초당 수만 건의 트랜잭션을 지원하는 것을 목표로 함에 따라 처리량과 확장성을 심각하게 제한합니다. +과거에는 블록체인 시스템이 순차적 실행에 의존했습니다. 즉, 각 트랜잭션이 하나씩 처리되어 모든 노드에서 결정론적 상태를 보장했습니다. 이러한 설계는 일관성을 보장하지만, 특히 최신 블록체인이 초당 수만 개의 트랜잭션을 지원하는 것을 목표로 함에 따라 처리량과 확장성을 심각하게 제한합니다. -이러한 제약을 극복하기 위해 Stable은 **Block-STM**을 채택하고 있습니다. 이는 **낙관적 병렬 실행(OPE)**을 가능하게 하는 입증된 병렬 실행 엔진입니다. 이를 통해 트랜잭션을 병렬로 실행하면서 결정론을 보존하여 성능을 크게 향상시킬 수 있습니다. +Stable v1.4.0은 Block-STM을 통해 **낙관적 병렬 실행(OPE)**을 도입합니다. 트랜잭션은 CPU 코어에서 동시에 실행되며, 고정된 블록 내 순서는 최종 상태를 결정론적으로 유지합니다. ### Block-STM 작동 방식 -Block-STM은 낙관적 동시성 제어 메커니즘을 사용합니다. 트랜잭션은 충돌하지 않을 것이라는 가정하에 먼저 병렬로 실행됩니다. 그런 다음, 유효성 검사 단계에서 충돌이 감지되고 재실행을 통해 처리됩니다. 이 프로세스는 다음 다섯 가지 주요 기술에 의존합니다. +Block-STM은 낙관적 동시성 제어 메커니즘을 사용합니다. 트랜잭션은 먼저 충돌하지 않을 것이라는 가정하에 병렬로 실행됩니다. 그런 다음, 유효성 검사 단계에서 모든 충돌이 감지되고 재실행을 통해 처리됩니다. 이 프로세스는 다음 다섯 가지 주요 기술에 의존합니다. **1. 다중 버전 메모리 구조** Block-STM은 각 메모리 키의 여러 버전을 저장합니다. -- 각 트랜잭션은 이전 트랜잭션에서 커밋된 최신 버전을 읽습니다. -- 실행 중에는 읽기 및 쓰기가 모두 버전 관리됩니다. -- 나중에 유효성 검사 중에 이러한 버전의 일관성이 확인되어 충돌을 감지합니다. +- 각 트랜잭션은 이전 트랜잭션이 커밋한 최신 버전을 읽습니다. +- 실행 중에 읽기 및 쓰기 모두 버전이 지정됩니다. +- 나중에 유효성 검사 중에 이러한 버전이 일관성을 위해 검사되어 충돌을 감지합니다. -**2. Read-Set / Write-Set 기반 유효성 검사** +**2. 읽기-세트 / 쓰기-세트 기반 유효성 검사** -- 실행 중에 각 트랜잭션은 Read-Set에 읽는 키와 버전을 기록합니다. -- 실행이 끝나면 Write-Set을 다중 버전 메모리에 기록합니다. -- 유효성 검사 중에 다른 트랜잭션이 Read-Set의 키를 수정한 경우, 해당 트랜잭션은 충돌로 표시됩니다. 그런 다음 중단되고 증가된 버전 번호로 다시 실행됩니다. +- 실행 중에 각 트랜잭션은 읽기-세트에 읽은 키와 버전을 기록합니다. +- 실행이 끝나면 쓰기-세트를 다중 버전 메모리에 기록합니다. +- 유효성 검사 중에 다른 트랜잭션이 읽기-세트의 키를 수정한 경우 해당 트랜잭션은 충돌하는 것으로 표시됩니다. 그런 다음 중단되고 증가된 인카네이션 번호로 재실행됩니다. -**3. ESTIMATE 마커를 이용한 빠른 충돌 감지** +**3. ESTIMATE 마커를 사용한 빠른 충돌 감지** -- 트랜잭션이 실패하면 Write-Set에 ESTIMATE 플래그가 표시됩니다. -- 다른 트랜잭션이 ESTIMATE 표시된 값을 읽으면 즉시 중지하고 재실행을 기다립니다(`READ_ERROR`에 의해 트리거됨). -- 이는 전체 트랜잭션 세트를 재실행하지 않고 의존성을 빠르게 식별하여 오버헤드를 줄이는 데 도움이 됩니다. +- 트랜잭션이 실패하면 해당 쓰기-세트가 ESTIMATE 플래그로 표시됩니다. +- 다른 트랜잭션이 ESTIMATE로 표시된 값을 읽으면 즉시 중지하고 재실행을 기다립니다(`READ_ERROR`에 의해 트리거됨). +- 이는 전체 트랜잭션 세트를 재실행하지 않고도 종속성을 신속하게 식별하여 오버헤드를 줄이는 데 도움이 됩니다. **4. 사전 설정 트랜잭션 순서** -- 블록 내의 모든 트랜잭션은 사전 설정된 결정론적 순서에 따라 실행됩니다. +- 블록 내의 모든 트랜잭션은 미리 설정된 결정론적 순서에 따라 실행됩니다. - 유효성 검사 및 커밋 단계도 동일한 순서를 따릅니다. -- 이를 통해 병렬 실행에서도 모든 노드가 동일한 최종 상태에 도달할 수 있습니다. +- 이는 병렬 실행에서도 모든 노드가 동일한 최종 상태에 도달하도록 보장합니다. -**5. 협업 스케줄러** +**5. 공동 작업 스케줄러** -- 협업 스케줄러는 스레드 안전 방식으로 실행 및 유효성 검사 작업자 간에 작업을 분배합니다. +- 공동 작업 스케줄러는 스레드 안전한 방식으로 실행 및 유효성 검사 작업자 간에 작업을 분배합니다. - 조기 커밋을 가속화하고 재실행을 최소화하기 위해 낮은 인덱스 트랜잭션의 우선순위를 지정합니다. -- 스케줄러는 트랜잭션이 성공적으로 커밋될 때까지 반복 시도에 대한 트랜잭션 버전을 관리합니다. +- 스케줄러는 성공적으로 커밋될 때까지 반복되는 시도에 대한 트랜잭션 인카네이션을 관리합니다. ### Block-STM의 주요 이점 - **잠금 없는 병렬 처리**: MVCC(다중 버전 동시성 제어)를 활용하여 Block-STM은 뮤텍스 잠금 없이 여러 트랜잭션이 동시에 읽고 쓸 수 있도록 합니다. 충돌은 실행 후에만 확인되므로 초기 처리 단계에서 최대 처리량을 허용합니다. -- **ESTIMATE 마커를 통한 최소 오버헤드**: 실패한 트랜잭션은 Write-Set에 ESTIMATE 마커를 표시하여 종속 트랜잭션이 일찍 일시 중지되도록 신호를 보내 불필요한 실행을 방지합니다. 이는 유효한 실행 경로를 더 빠르게 수렴하는 결과를 가져옵니다. -- **효율적인 스케줄링 및 우선순위 커밋**: 협업 스케줄러를 사용하여 시스템은 낮은 인덱스 트랜잭션을 먼저 커밋하여 재시도를 최소화합니다. 이는 전체 처리량을 개선하고 실행 주기를 단축합니다. -- **결정론 및 합의 호환성**: 모든 트랜잭션이 고정된 순서를 따르기 때문에 재실행된 트랜잭션도 궁극적으로 동일한 순서로 커밋됩니다. 이는 병렬화된 환경에서도 합의 무결성을 유지하면서 모든 노드에서 안전하고 결정론적인 상태 합의를 보장합니다. +- **ESTIMATE 마커를 통한 최소 오버헤드**: 실패한 트랜잭션은 쓰기-세트에 ESTIMATE 마커를 표시하여 종속 트랜잭션이 조기에 일시 중지하도록 신호를 보내 불필요한 실행을 방지합니다. 이는 유효한 실행 경로를 더 빠르게 수렴하게 합니다. +- **효율적인 스케줄링 및 우선순위가 지정된 커밋**: 공동 작업 스케줄러를 사용하여 시스템은 낮은 인덱스 트랜잭션을 먼저 커밋하여 재시도를 최소화합니다. 이는 전반적인 처리량을 개선하고 실행 주기를 단축합니다. +- **결정론 및 합의 호환성**: 모든 트랜잭션이 고정된 순서를 따르기 때문에 재실행된 트랜잭션도 궁극적으로 동일한 순서로 커밋됩니다. 이는 병렬화된 환경에서도 합의 무결성을 유지하면서 모든 노드에서 안전하고 결정론적인 상태 동의를 보장합니다. ### Stable의 OPE Stable에서의 낙관적 병렬 실행 -Stable은 **낙관적 블록 처리(OBP)**와 함께 **낙관적 병렬 실행(OPE)**을 자체 실행 계층의 핵심 기능으로 통합할 예정입니다. OPE와 OBP는 상호 보완적이지만 근본적으로 다른 전략이라는 점에 유의하십시오. +Stable은 OPE를 **낙관적 블록 처리(OBP)**와 결합합니다. 두 최적화는 서로 다른 작업을 처리합니다. ### OBP 정보 -- OBP는 병렬 처리에 관한 것이 아니라 실행 타이밍에 관한 것입니다. -- `ProcessProposal` 단계 동안 Stable은 블록이 다른 노드에 가십되는 동안 블록을 사전 실행합니다. +- OBP는 병렬 처리가 아니라 실행 타이밍에 관한 것입니다. +- `ProcessProposal` 단계에서 Stable은 블록이 다른 노드에 전파되는 동안 블록을 미리 실행합니다. - 결과 상태는 메모리에 캐시되고 `FinalizeBlock` 중에 재사용되어 시간을 절약하고 중복 계산을 줄입니다. -OPE와 OBP를 결합함으로써 Stable은 실행 대기 시간과 리소스 경합을 모두 최소화하여 높은 트랜잭션 부하에서 우수한 성능을 제공할 수 있습니다. +OPE는 여러 CPU 코어를 사용하여 실행 시간을 줄입니다. OBP는 제안 처리와 최종화에서 동일한 블록을 두 번 실행하는 것을 방지합니다. -### 예상 성능 향상 +### 커밋 후 재확인 -내부 벤치마크에 따르면 **Block-STM 기반 OPE** 및 **StableDB** 통합을 통해 Stable은 종단 간 트랜잭션 처리에서 **최소 2배의 처리량 향상**을 달성할 수 있습니다. +블록이 커밋된 후 CometBFT는 일반적으로 멤풀에서 대기 중인 모든 트랜잭션을 재확인합니다. 이 반복적인 작업은 노드 CPU의 31~34%를 소비할 수 있습니다. -## 미래 로드맵 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)**](/ko/explanation/stable-db): 디스크 I/O에 의존하지 않고 분리된 상태 커밋이 실행에 어떻게 공급되는지 확인하세요. -- [**고성능 RPC**](/ko/explanation/high-performance-rpc): 클라이언트에 실행 결과를 제공하는 분할 경로 RPC를 이해하세요. -- [**이더리움 호환성**](/ko/explanation/ethereum-compatibility): 표준 EVM 툴링을 사용하여 Stable에 대해 기존 컨트랙트를 포팅하세요. +낙관적 병렬 실행(OPE) 및 낙관적 블록 처리(OBP)와 같은 노력은 *여러 트랜잭션이 동시에 실행되는 방식*을 최적화하는 데 중점을 두지만, 또 다른 중요한 성능 요소는 **개별 트랜잭션이 얼마나 효율적으로 처리되는지**입니다. + +Stable은 현재 실행 속도를 높이기 위해 대체 EVM 구현을 모색 중입니다. 후보 중 C++로 작성된 고성능 EVM인 **EVMONE**은 기존 Go 기반 EVM을 대체할 강력한 경쟁자로 두드러집니다. 이 전환은 이론적 벤치마크를 기반으로 **EVM 실행 성능에서 최대 6배 증가**를 가져올 것으로 예상됩니다. + +## 다음으로 이동할 곳 + +- [**스토리지 (StableDB)**](/ko/explanation/stable-db): 디스크 I/O에 블로킹되지 않고 분리된 상태 커밋이 실행에 어떻게 공급되는지 확인하세요. +- [**고성능 RPC**](/ko/explanation/high-performance-rpc): 실행 결과를 클라이언트에 표시하는 분할 경로 RPC를 이해하세요. +- [**이더리움 호환성**](/ko/explanation/ethereum-compatibility): 표준 EVM 도구를 사용하여 기존 계약을 Stable에 포팅하세요. +- [**네트워크 업그레이드**](/ko/reference/network-upgrades): 전체 v1.4.0 릴리스 범위 및 롤아웃 노트를 검토하세요. diff --git a/docs/pages/ko/explanation/guaranteed-blockspace.mdx b/docs/pages/ko/explanation/guaranteed-blockspace.mdx index 32aa9ea..139f887 100755 --- a/docs/pages/ko/explanation/guaranteed-blockspace.mdx +++ b/docs/pages/ko/explanation/guaranteed-blockspace.mdx @@ -1,49 +1,70 @@ --- source_path: explanation/guaranteed-blockspace.mdx -source_sha: e4251f3214551742d492fdfe9dfc33077cb77d76 +source_sha: 5a58c3c6715bd458c1b2a57a9130934021c66e59 title: "보장된 블록 공간" -description: "기업 파트너에게 Stable 네트워크에서 예약된 처리량 용량을 제공하는 보장된 블록 공간 할당입니다." +description: "Stable이 레인별 가스 용량을 예약하고 두 차원 논스를 통해 우선 순위 트래픽을 식별하는 방법을 이해합니다." diataxis: "explanation" --- # 보장된 블록 공간 -**보장된 블록 공간**은 네트워크 조건에 관계없이 모든 블록 용량의 고정된 부분을 등록된 기업 파트너에게 할당하도록 예약된 전용 블록 공간 할당 모델입니다. 보장된 경로를 통해 라우팅된 트랜잭션은 예측 가능한 대기 시간과 비용으로 실행됩니다. 급여, 결제 및 공급업체 지급은 공개 멤풀 트래픽과 경쟁하지 않습니다. +Stable v1.4.0은 각 블록을 별도의 가스 예산이 있는 레인으로 나눕니다. 자격이 있는 우선순위 트랜잭션은 VIP 레인으로 들어가므로 일반 트래픽은 이들을 위해 예약된 용량을 소비할 수 없습니다. :::note -**계획 중입니다.** 보장된 블록 공간은 미래 지향적인 로드맵 항목입니다. 시점에 대한 자세한 내용은 [로드맵](/ko/explanation/technical-roadmap)을 참조하세요. +보장된 블록 공간은 v1.4.0 테스트넷 릴리스 후보에 적용됩니다. 메인넷 업그레이드 일정은 아직 보류 중입니다. 거버넌스 구성 없이는 모든 트랜잭션이 하나의 일반 레인을 계속 사용합니다. ::: -## 왜 중요한가 +## 블록 레인 -범용 체인은 부하 시 비용 예측 가능성을 위해 설계되지 않았습니다. +제안 및 유효성 검사 규칙은 세 가지 레인 유형을 인식합니다. -- **이더리움**: 2022년 5월 1일, Yuga Labs의 "Otherside" NFT 발행은 최고 가스를 8,000 gwei 이상으로 밀어 올리고 2억 달러 이상의 수수료를 소각하여 확정적 비용이 필요한 모든 워크로드를 파괴했습니다. -- **솔라나 및 베이스와 같은 저비용 네트워크**는 MEV와 아비트라지 스팸을 유인하여 합법적인 트랜잭션이 포함을 위해 봇 트래픽과 경쟁합니다. +- **VIP 레인**: `NonceKey`가 프로토콜 예약 범위에 있는 트랜잭션을 처리합니다. +- **트랜잭션 유형 레인**: 구성된 트랜잭션 범주에 대한 용량을 예약합니다. +- **일반 레인**: 다른 구성된 레인과 일치하지 않는 표준 트랜잭션을 처리합니다. -![출처: Flashbots와 Robert Miller의 MEV와 스케일링의 한계](/images/share-of-gas.png) +각 레인에는 자체 가스 할당량이 있습니다. 제안자는 이 제한 내에서 레인을 채우고, 검증자는 제안된 블록을 검증할 때 동일한 제한을 적용합니다. -*출처: Flashbots와 Robert Miller의 MEV와 스케일링의 한계* +이는 프로토콜 수준에서 예약을 결정론적으로 만듭니다. 제안자가 자발적으로 공간을 사용하지 않고 남겨두는 것에 의존하지 않습니다. -기업 결제 흐름은 이러한 변동을 허용할 수 없습니다. 보장된 블록 공간은 이를 직접 해결합니다. +## 2차원 논스 -## 보증 작동 방식 +이더리움 계정은 일반적으로 하나의 논스 시퀀스를 가집니다. 트랜잭션 12가 누락되거나 멈춘 경우, 트랜잭션 13 및 이후 트랜잭션은 실행될 수 없습니다. -보증은 세 가지 계층에서 적용됩니다. +**2차원 논스** 또는 2D 논스는 계정에 여러 독립적인 시퀀스를 제공합니다. `NonceKey`는 시퀀스를 선택하고, 트랜잭션의 논스는 해당 시퀀스 내에서의 위치를 제공합니다. -- **보장된 멤풀**: 검증인(validator)은 공개 트래픽과 격리된 전용 멤풀에서 보장된 트랜잭션을 가져옵니다. -- **검증인 수준 예약**: 각 검증인은 보장된 레인을 위해 모든 블록의 가스 용량 중 미리 정의된 부분을 예약합니다. 확정적 포함은 이로부터 파생됩니다. -- **전용 RPC 노드**: 보장된 블록 공간 API는 격리된 RPC 엔드포인트를 통해 트랜잭션을 라우팅하므로, 공개 RPC 부하에 따라 제출 대기 시간이 급증하지 않습니다. +예를 들어, 결제 계정은 급여를 위해 `NonceKey = 1`을 사용하고 공급업체 결제를 위해 `NonceKey = 2`를 사용할 수 있습니다. 지연된 급여 트랜잭션은 공급업체 시퀀스를 차단하지 않습니다. -등록된 파트너의 결과: +논스 키 공간에는 세 가지 중요한 영역이 있습니다. -- **독점 라우팅 경로**: 제출은 공개 멤풀 트래픽과 경쟁하지 않습니다. -- **포함 보장**: 네트워크 혼잡에 관계없이 모든 블록에 용량이 예약됩니다. -- **분산화 트레이드오프 없음**: 검증인 개방성과 네트워크 참여가 유지됩니다. 보증은 공개 레인과 함께 존재하며 그 위에 군림하지 않습니다. -- **비즈니스에 필수적인 운영을 위한 신뢰할 수 있는 온체인 성능**, 부하가 걸린 경우에도 마찬가지입니다. +- `NonceKey = 0`은 표준 EVM 호환 논스 동작을 유지합니다. +- `uint64` 범위의 상위 절반은 프로토콜 사용을 위해 예약되어 있습니다. VIP 멤버십은 이 범위를 통해 신호를 보냅니다. +- `NonceKey = MaxUint64`는 순서가 없는 트랜잭션을 표시합니다. `TimeoutTimestamp`는 재생 방지 마감일을 제공합니다. -## 다음 권장 사항 +Stable은 이 필드들을 트랜잭션 유형 `0x3F`인 `CustomTx`에 포함합니다. 기존 EVM 트랜잭션 형식은 계속 사용할 수 있으며, 기본 논스 채널은 예상되는 동작을 보존합니다. -- [**보장된 결제**](/ko/explanation/upcoming-use-cases): 보장된 블록 공간에 의존하는 결제 패턴을 확인하세요. 즉, 확정적 포함이 있는 정해진 DvP 결제 주기입니다. -- [**가스로서의 USDT**](/ko/explanation/usdt-as-gas-token): 보장된 블록 공간을 통해 흐르는 자산을 이해합니다. -- [**토큰 경제학**](/ko/reference/tokenomics): STABLE 스테이킹이 검증인의 블록 공간 보증을 어떻게 뒷받침하는지 검토합니다. +## 거버넌스 및 활성화 + +거버넌스는 하나의 `MsgUpdateParams` 제안을 통해 레인 정의 및 가스 할당량을 제어합니다. 승인된 매개변수는 다음 블록에서 적용됩니다. + +기본값에는 예약된 레인이 포함되어 있지 않습니다. 거버넌스가 이를 구성할 때까지 체인은 하나의 일반 레인으로 작동합니다. 이는 레인 구성을 기존 트랜잭션 처리에 추가합니다. + +## 보장 경계 + +VIP 트랜잭션은 다음 모든 조건이 충족될 때 결정론적인 다음 블록 포함을 받습니다. + +- 트랜잭션이 VIP 레인에 적합합니다. +- 레인에 트랜잭션을 위한 충분한 예약 가스가 있습니다. +- 검증자가 프로토콜을 따릅니다. +- 네트워크가 제안 전에 검증자가 트랜잭션을 수신할 수 있을 만큼 충분히 동기화되어 있습니다. + +Stable의 멤풀 없는 검증자 인그레스 모델은 VIP 트랜잭션을 검증자에게 제공합니다. 예약된 제안 용량은 일반 트래픽이 이를 방해하는 것을 방지합니다. + +:::note +가스 면제 트랜잭션 유형 레인은 연기됩니다. `gasPrice = 0`인 레인에는 신뢰할 수 있는 입장 제어가 필요합니다. 그렇지 않으면 공격자가 무료 트랜잭션으로 플러딩할 수 있습니다. +::: + +## 다음으로 이동할 곳 + +- [**보장된 정산**](/ko/explanation/upcoming-use-cases): 보장된 블록 공간에 의존하는 결제 패턴을 확인하세요: 결정론적 포함을 갖는 DVp(Delivery versus Payment) 정산 주기. +- [**네트워크 업그레이드**](/ko/reference/network-upgrades): v1.4.0 릴리스 전체와 출시 상태를 검토하세요. +- [**실행**](/ko/explanation/execution): Stable이 각 블록에 선택된 트랜잭션을 어떻게 실행하는지 이해하세요. diff --git a/docs/pages/ko/explanation/stable-db.mdx b/docs/pages/ko/explanation/stable-db.mdx index 5d13307..bc7bee9 100755 --- a/docs/pages/ko/explanation/stable-db.mdx +++ b/docs/pages/ko/explanation/stable-db.mdx @@ -1,87 +1,96 @@ --- source_path: explanation/stable-db.mdx -source_sha: 1b5136d111f56a7a32bf3730d44d97755770091f -title: "스토리지 (StableDB)" -description: "디스크 I/O 병목 현상을 제거하기 위한 분리된 상태 커밋, MemDB, mmap을 사용한 StableDB 아키텍처." +source_sha: ffbcf61705d3dbb4a82da281257a33d12e385b45 +title: "저장소 (StableDB)" +description: "MemIAVL이 메모리 매핑된 스냅샷과 순차적 쓰기 우선 로그로 현재 상태를 저장하는 방법을 이해합니다." diataxis: "explanation" --- -# 스토리지 (StableDB) +# 저장소 (StableDB) -종단 간 블록체인 성능의 주요 병목 현상 중 하나는 **디스크 I/O**입니다. 특히, 블록 실행 후 상태 데이터를 커밋하고 저장하는 것이 핵심 병목 현상을 야기합니다. Stable은 `MemDB`, `VersionDB`, 메모리 맵 스토리지(`mmap`)와 같은 아키텍처 혁신을 통해 이 문제를 해결하여 처리량을 획기적으로 개선합니다. +Stable v1.4.0은 LevelDB 기반 상태 저장소를 MemIAVL로 대체합니다. MemIAVL은 하나의 상태 스냅샷을 메모리 매핑 파일에 유지하고 각 새 블록의 변경 사항을 순차적 쓰기 우선 로그에 기록합니다. -## 디스크 I/O가 병목 현상인 이유 +:::note +MemIAVL은 v1.4.0 Testnet 릴리스 후보에서 라이브 상태입니다. 메인넷 업그레이드 일정은 아직 보류 중입니다. 출시 상태는 [네트워크 업그레이드](/ko/reference/network-upgrades)를 확인하세요. +::: -### 상태 전환 및 영속성 +## 디스크 I/O가 병목 현상인 이유 -거래 블록이 실행될 때마다 블록체인은 한 상태에서 다음 상태로 전환됩니다. 이 프로세스는 두 가지 근본적인 단계를 거칩니다. +모든 블록은 애플리케이션 상태를 변경합니다. 노드는 두 가지 관련 작업을 완료해야 합니다. -1. **상태 커밋**: 거래 실행 후 새로운 애플리케이션 상태가 커밋됩니다. -2. **상태 저장**: 커밋된 상태는 장기적인 접근과 기록 검증을 위해 디스크에 영속화됩니다. +1. **상태 커밋**: 새 상태의 루트 해시를 계산하고 커밋합니다. +2. **상태 지속성**: 변경된 데이터를 저장소에 기록하여 나중에 노드가 복구할 수 있도록 합니다. 결합된 상태 커밋 및 스토리지 -기존 아키텍처에서는 상태 저장이 상태 커밋과 **밀접하게 결합**되어 있습니다. 이는 다음을 의미합니다. +이전 LevelDB 기반 저장소는 이러한 작업을 결합했습니다. 또한 나중에 읽기를 효율적으로 만들기 위해 저장된 레코드를 재구성하는 백그라운드 압축 중에 데이터를 다시 썼습니다. -- 노드는 다음 블록 실행을 진행하기 전에 새 상태가 디스크에 완전히 저장될 때까지 기다려야 합니다. -- 상태 데이터는 고정된 주소에 매핑되지 않은 임의의 디스크 위치에 기록됩니다. 이로 인해 후속 거래 실행 중에 상태 데이터를 검색할 때 높은 지연 시간이 발생합니다. +하나의 논리적 상태 업데이트가 10-50배 많은 물리적 디스크 쓰기를 유발할 수 있습니다. 이를 **쓰기 증폭(write amplification)**이라고 합니다. 그런 다음 실행은 무작위 쓰기 및 압축이 지배하는 저장소 경로를 기다려야 했습니다. -합의 및 실행 계층이 아무리 최적화되더라도 느린 디스크 작업에 대한 이 직렬화된 종속성은 전체 시스템의 달성 가능한 성능을 제한합니다. +## MemIAVL이 저장소를 변경하는 방법 -## 더 높은 처리량을 위한 DB 작업 최적화 +메모리 매핑 파일 또는 `mmap`를 사용하면 운영 체제가 메모리 주소를 통해 파일 내용을 노출할 수 있습니다. 노드는 포인터를 따라 상태를 읽을 수 있으며, 운영 체제는 필요한 페이지를 페이지 캐시에 로드합니다. -이러한 한계를 극복하기 위해 Stable은 **상태 작업 분리**와 **메모리 맵 DB 최적화 도입**에 중점을 둔 두 가지 아키텍처 개선을 제안합니다. +MemIAVL은 두 가지 구조를 결합합니다. -### 1. 상태 커밋 및 스토리지 분리 +- **스냅샷**: 지속된 상태 트리의 단일 메모리 매핑 표현. +- **쓰기 우선 로그 (WAL)**: 해당 스냅샷 이후에 발생한 원시 변경 사항에 대한 추가 전용 기록. 분리된 상태 커밋 및 스토리지 -첫 번째 단계는 상태 커밋을 스토리지에서 분리하는 것입니다. +### 쓰기 경로 + +각 블록은 변경 세트를 WAL에 순서대로 추가합니다. MemIAVL은 업데이트를 LevelDB를 통해 라우팅하거나 압축을 트리거하지 않습니다. 따라서 쓰기 증폭은 10-50배에서 약 1회 쓰기로 감소합니다. + +MemIAVL은 또한 트리 노드를 두 가지 범주로 나눕니다. + +- `PersistedNode`는 스냅샷에 이미 저장된 변경되지 않은 서브트리를 나타냅니다. +- `MemNode`는 현재 업데이트에 의해 메모리에서 변경된 서브트리를 나타냅니다. + +MemIAVL이 다음 루트 해시를 계산할 때, 변경되지 않은 `PersistedNode` 서브트리에서 멈춥니다. 새 `MemNode` 데이터를 포함하는 경로만 해시합니다. + +### 읽기 경로 -- 새 상태를 커밋한 후 노드는 즉시 다음 블록 실행을 진행합니다. -- 실제 상태의 디스크 영속화는 백그라운드에서 비동기적으로 발생합니다. +현재 상태 읽기는 메모리 매핑된 스냅샷의 포인터를 따릅니다. 자주 액세스되는 페이지는 운영 체제의 페이지 캐시에 남아 있으므로 노드는 각 트리 노드에 대해 별도의 데이터베이스 조회를 피합니다. -이러한 분리는 실행이 즉시 발생하고 느린 디스크 쓰기의 지연 시간을 뛰어넘을 수 있도록 하여, 차단 종속성을 제거하고 궁극적으로 종단 간 성능을 향상시킵니다. +## 기록 상태 및 VersionDB -### 2. `mmap`을 통한 `MemDB` 및 `VersionDB` 도입 +MemIAVL은 현재 상태와 노드가 유지하는 스냅샷을 제공합니다. 보조 VersionDB는 RocksDB 사이드카에 기록 버전을 저장합니다. -Stable은 `mmap`(메모리 맵 파일 접근)으로 구동되는 듀얼 데이터베이스 모델로 이를 강화합니다. +노드가 가장 이른 MemIAVL 스냅샷보다 오래된 기록 상태 쿼리에 응답해야 하는 경우 VersionDB가 필요합니다. 이는 아카이브 노드 및 장거리 쿼리를 노출하는 RPC 서비스에 특히 중요합니다. -- **MemDB (메모리 DB)**: - - 자주 액세스되는 최근의 활성 상태를 저장합니다. - - `mmap`을 통해 고정 주소 매핑을 사용하여 빠르고 결정론적인 조회를 가능하게 합니다. - - 최근에 수정된 상태를 대상으로 하는 대부분의 거래 워크로드에 이상적입니다. -- **VersionDB (히스토리 DB)**: - - 오래된 히스토리 상태를 디스크에 저장합니다. - - 아카이브 및 장거리 쿼리에 최적화되어 있으며, 고주파수 액세스에는 적합하지 않습니다. +## 마이그레이션 고려 사항 -이 설계는 **활성 데이터가 빠르고 메모리 상주 구조에서 제공**되도록 보장하며, 비활성 데이터는 더 느리고 영구적인 스토리지로 오프로드됩니다. `mmap` 액세스와 스마트 상태 계층화를 결합함으로써 Stable은 블록 실행 중 DB 읽기/쓰기 지연 시간을 크게 줄일 수 있습니다. +기존 노드는 v1.4.0을 채택할 때 LevelDB 상태를 마이그레이션해야 합니다. 권장 경로는 로컬 스냅샷 내보내기 및 복원입니다. -## 예상되는 성과 및 선례 +벤치마크는 표준 복원에 대해 검증자당 평균 19.4초의 다운타임을 측정했습니다. 병렬 복원 변형은 평균을 약 2.6초로 줄였습니다. -이러한 아키텍처 최적화는 이론적인 것만이 아닙니다. Sei 및 Cronos와 같은 고성능 블록체인에서 이미 구현되고 있습니다. 둘 다 메모리 맵 DB를 사용하는 유사한 분리 아키텍처를 채택했으며 **전반적인 TPS가 최대 2배 증가**하는 것을 관찰했습니다. +검증자는 라운드 로빈 순서로 하나씩 마이그레이션할 수 있습니다. 투표권의 최소 3분의 2를 온라인 상태로 유지하면 네트워크는 마이그레이션 중에 블록을 계속 생성할 수 있습니다. -Stable 역시 아키텍처가 더 이상 스토리지 계층에 병목 현상을 일으키지 않으므로 비슷한 성과를 예상합니다. 대신, 합의 및 실행 성능은 디스크 작업에 의해 조절되지 않고 확장될 수 있습니다. +:::warning +이 시간은 벤치마크 결과일 뿐 다운타임을 보장하지 않습니다. 최종 바이너리, 업그레이드 높이, 백업 및 복원 명령에 대한 네트워크별 업그레이드 지침을 따르세요. +::: -## 추가 자료 +## 추가 읽을거리 -더 자세한 기술 심층 분석 및 구현 세부 정보는 다음을 참조하십시오. +더 자세한 기술적 심층 분석 및 구현 세부 정보는 다음을 참조하세요. -- [ADR-065: Cosmos Store V2 Architecture](https://docs.cosmos.network/main/build/architecture/adr-065-store-v2) -- [MemIAVL: A Practical Guide](https://hackmd.io/@yihuang/rkeCvy5xh) -- [Cronos MemIAVL Node Configuration](https://docs.cronos.org/for-node-hosts/running-nodes/memiavl) -- [Sei’s DB Design Approach](https://4pillars.io/ko/articles/sei-db) +- [ADR-065: Cosmos Store V2 아키텍처](https://docs.cosmos.network/main/build/architecture/adr-065-store-v2) +- [MemIAVL: 실용 가이드](https://hackmd.io/@yihuang/rkeCvy5xh) +- [Cronos MemIAVL 노드 구성](https://docs.cronos.org/for-node-hosts/running-nodes/memiavl) +- [Sei의 DB 설계 접근 방식](https://4pillars.io/ko/articles/sei-db) -## 다음으로 추천하는 자료 +## 다음으로 이동할 곳 -- [**고성능 RPC**](/ko/explanation/high-performance-rpc): RPC 계층이 쓰기와 충돌하지 않고 상태 읽기를 어떻게 노출하는지 확인하세요. -- [**실행**](/ko/explanation/execution): 실행이 여기서 다루는 스토리지 계층에 어떻게 쓰여지는지 이해하세요. -- [**합의**](/ko/explanation/consensus): 블록이 스토리지에 도달하기 전에 블록을 정렬하는 합의 계층을 검토하세요. +- [**고성능 RPC**](/ko/explanation/high-performance-rpc): RPC 계층이 쓰기와 경쟁하지 않고 상태 읽기를 노출하는 방법을 확인하세요. +- [**실행**](/ko/explanation/execution): 실행이 여기에 설명된 저장소 계층에 어떻게 쓰는지 이해합니다. +- [**노드 업그레이드**](/ko/how-to/upgrade-node): 조정된 업그레이드 후에 백업을 준비하고 노드를 확인합니다. +- [**네트워크 업그레이드**](/ko/reference/network-upgrades): 전체 v1.4.0 범위 및 출시 상태를 검토합니다. diff --git a/docs/pages/ko/explanation/tech-overview.mdx b/docs/pages/ko/explanation/tech-overview.mdx index f084887..a133c71 100755 --- a/docs/pages/ko/explanation/tech-overview.mdx +++ b/docs/pages/ko/explanation/tech-overview.mdx @@ -1,44 +1,66 @@ --- source_path: explanation/tech-overview.mdx -source_sha: d71b320a46b9bc5aa2c45ca6f25c192f0d33a2af +source_sha: 66c5144a0a00b4fc60545e70df03a2260238b7b8 title: "기술 개요" -description: "Stable의 블록체인 아키텍처, 합의 메커니즘, EVM 호환 실행 스택에 대한 개요." +description: "스테이블의 4계층 스택(합의, 실행, 저장, RPC)이 스테이블코인 결제 처리량에 최적화된 방식입니다." +diataxis: "explanation" --- # 기술 개요 -상태 데이터베이스, 실행, 합의부터 USDT 전용 최적화에 이르기까지, Stable은 성능, 확장성, 신뢰성을 중점으로 설계되었습니다. Stable 스택의 각 구성 요소는 높은 처리량을 요구하는 워크로드 및 네트워크 전반에서 USDT 중심의 원활한 운영을 위해 최적화되어 있습니다. +:::note +**릴리스 상태:** StableBFT, 순차적 Stable EVM, 분할 경로 RPC 계층이 메인넷에 출시되었습니다. OPE, 선택적 RecheckTx, MemIAVL, 2D nonce 및 보장된 블록 공간은 v1.4.0 테스트넷 릴리스 후보에 있습니다. 메인넷 업그레이드 일정은 보류 중입니다. +::: + +Hardhat, Foundry 또는 모든 표준 EVM 툴링을 사용하여 현재 Stable에 Solidity 또는 Vyper 컨트랙트를 배포할 수 있으며, 컨트랙트는 수정 없이 작동합니다. 변경되는 점: 가스는 USDT0으로 지불되고, 트랜잭션은 단일 슬롯 완결성에 도달하며, 스택의 모든 계층은 스테이블코인 처리량에 최적화되어 있습니다. Tech Overview ## StableBFT -초기 Stable 블록체인은 CometBFT 기반의 맞춤형 PoS 합의 프로토콜인 **StableBFT**를 활용하여, 네트워크 전반에 걸친 높은 처리량, 낮은 지연 시간, 강력한 신뢰성을 보장합니다. 합의 성능을 더욱 최적화하기 위해, Stable은 데이터 전파와 합의 과정을 분리하고, 트랜잭션을 블록 프로포저에게 직접 브로드캐스트하는 방식을 도입할 계획입니다. +**상태: 라이브** -합의를 획기적으로 가속화하기 위해 Stable은 DAG 기반 **Autobahn**으로의 프로토콜 업그레이드를 계획하고 있습니다. Autobahn을 기반으로 구축된 StableBFT는 다음을 가능케 합니다: +Stable 블록체인은 네트워크 전반에 걸쳐 높은 처리량, 낮은 지연 시간 및 강력한 안정성을 위해 CometBFT를 기반으로 구축된 맞춤형 PoS 합의 프로토콜인 **StableBFT**를 활용합니다. -- 단일 리더 제한 제거를 통한 프로포절 병렬 처리 -- 데이터 전파와 트랜잭션 순서 정렬을 분리하여 더 빠른 완결성 달성 -- 강력한 BFT 메커니즘을 통한 네트워크 장애에 대한 높은 복원력 +:::note +**계획됨:** 데이터 분리를 위한 DAG 기반 **Autobahn** 합의. [로드맵](/ko/explanation/technical-roadmap#phase-3-full-stack-optimized-layer-for-usdt)을 참조하십시오. +::: ## Stable EVM -**Stable EVM**은 Stable의 이더리움 호환 실행 계층으로, 기존 이더리움 툴 및 지갑을 사용해 체인과 원활히 상호작용할 수 있도록 합니다. Stable EVM은 StableSDK와의 연결을 위해 일련의 프리컴파일을 도입하여, EVM 스마트 컨트랙트가 핵심 체인 로직에 안전하고 아토믹하게 접근할 수 있도록 지원합니다. +**상태: 라이브** + +**Stable EVM**은 Stable의 이더리움 호환 실행 계층입니다. 표준 이더리움 도구와 지갑은 변경 없이 체인과 상호 작용합니다. 일련의 **프리컴파일**은 Stable EVM을 Stable SDK에 연결하여 EVM 스마트 컨트랙트가 핵심 체인 로직을 원자적으로 호출할 수 있도록 합니다. + +:::note +**v1.4.0에 포함됨:** Block-STM은 CPU 코어 전반에 걸쳐 낙관적 병렬 실행을 추가합니다. 선택적 RecheckTx는 커밋 후 멤풀 작업을 줄입니다. [실행](/ko/explanation/execution)을 참조하십시오. +::: -Stable은 EVM 실행 성능을 극대화하기 위해 StableVM++를 도입할 예정이며, 이는 EVMONE과 같은 대체 EVM 구현체와 Block-STM 기반의 낙관적 병렬 실행 엔진을 통합합니다. +현재 Go 기반 EVM 구현을 대체할 수 있는 StableVM++는 나중 로드맵 항목으로 남아 있습니다. ## StableDB -**상태: v1.4.0 업그레이드에서 출시** +**상태: 테스트넷의 v1.4.0 릴리스 후보** -Stable은 각 블록 생성 후 디스크 저장이 느리다는 주요 병목 현상을 해결함으로써 블록체인 속도를 개선합니다. Stable은 상태 커밋과 상태 저장을 분리하여, 블록 처리를 지연 없이 진행할 수 있도록 합니다. `mmap` 기반의 `MemDB` 및 `VersionDB`를 통해 최근 데이터는 메모리에서 처리하고, 이전 데이터는 디스크에 효율적으로 저장하여 전체 처리량을 높일 수 있습니다. +MemIAVL은 LevelDB를 메모리 매핑 스냅샷과 추가 전용 쓰기 우선 로깅으로 대체합니다. RocksDB 기반 VersionDB는 보존된 스냅샷보다 오래된 기록 쿼리를 제공합니다. ## 고성능 RPC -아무리 블록체인이 빠르더라도, RPC 레이어가 느리다면 사용자 경험이 망가질 수 있습니다. Stable은 기존 모놀리틱 RPC 구조가 리소스 충돌 및 확장성 부족 문제를 일으킬 수 있다는 점을 인식하고, 이를 재설계했습니다. Stable은 기능별로 작업 경로를 분리한 split-path 아키텍처를 도입하며, 가벼우면서도 특화된 RPC 노드를 통해 응답 시간을 크게 단축합니다. +**상태: 라이브** + +느린 RPC 계층은 빠른 체인에서도 사용자 경험을 망칩니다. Stable은 함수별로 작업을 분리하는 **분할 경로 아키텍처**를 통해 이 문제를 해결하고, 더 빠른 응답 시간을 위해 경량의 전문화된 RPC 노드를 배포합니다. + +:::note +**계획됨:** EVM 뷰 호출에 최적화된 RPC 노드와 노드 통합 인덱서. [로드맵](/ko/explanation/technical-roadmap#phase-3-full-stack-optimized-layer-for-usdt)을 참조하십시오. +::: + +## 다음으로 이동할 곳 -향후 EVM 내 view 호출에 최적화된 RPC 노드 및 네이티브 인덱서를 통합하여, dApp의 온체인 데이터 접근 속도를 더욱 향상시킬 예정입니다. \ No newline at end of file +- [**실행**](/ko/explanation/execution): OPE 및 선택적 RecheckTx가 CPU 병목 현상을 제거하는 방법을 이해하십시오. +- [**저장소(StableDB)**](/ko/explanation/stable-db): MemIAVL이 현재 및 기록 상태 저장소를 변경하는 방법을 확인하십시오. +- [**보장된 블록 공간**](/ko/explanation/guaranteed-blockspace): 2D nonce 및 블록 레인 모델을 이해하십시오. +- [**네트워크 업그레이드**](/ko/reference/network-upgrades): v1.4.0 호환성, 출시 및 연기된 작업을 검토하십시오. diff --git a/docs/pages/ko/explanation/technical-roadmap.mdx b/docs/pages/ko/explanation/technical-roadmap.mdx index 009398c..0ff497e 100755 --- a/docs/pages/ko/explanation/technical-roadmap.mdx +++ b/docs/pages/ko/explanation/technical-roadmap.mdx @@ -1,14 +1,14 @@ --- source_path: explanation/technical-roadmap.mdx -source_sha: 669bf747b8f3b656b8509625ece8a50946d431f8 +source_sha: e46692a227f4149b54598c9036a27e12659728ee title: "로드맵" -description: "Stable의 단계별 최적화 로드맵: 현재 라이브 상태, 다음에 출시될 내용, 그리고 그 이후의 계획입니다." +description: "Stable의 단계별 최적화 로드맵: 현재 제공되는 기능, 다음 배송될 기능, 그 이후의 기능." diataxis: "explanation" --- # 로드맵 -Stable은 세 단계를 거쳐 트랜잭션 파이프라인의 모든 계층(합의, 실행, 스토리지, RPC, USDT별 흐름)을 최적화합니다. 이 페이지에는 출시된 내용, 진행 중인 내용, 그리고 앞으로의 계획이 표시되어 있습니다. +Stable은 세 단계를 거쳐 트랜잭션 파이프라인의 모든 계층(합의, 실행, 저장, RPC 및 USDT 특정 흐름)을 최적화합니다. 이 페이지에는 출시된 기능, 진행 중인 기능, 향후 예정된 기능이 표시됩니다. 기술 로드맵 -## 1단계: USDT를 위한 기반 계층 +## 1단계: USDT를 위한 기반 레이어 -상태: **메인넷에 라이브.** +상태: **메인넷 출시.** -### StableBFT: 라이브 +### StableBFT: 출시 완료 -CometBFT를 기반으로 구축된 맞춤형 PoS 합의 프로토콜입니다. 결정론적 완결성과 검증인의 1/3까지 비잔틴 결함 허용(BFT)을 제공합니다. 현재 구현은 [합의](/ko/explanation/consensus)를 참조하세요. +CometBFT를 기반으로 구축된 맞춤형 PoS 합의 프로토콜입니다. 검증자의 1/3까지 결정론적 완결성과 비잔틴 장애 허용을 제공합니다. 현재 구현 사항은 [합의](/ko/explanation/consensus)를 참조하세요. -### USDT를 기본 가스로: 라이브 +### USDT를 기본 Gas로 사용: 출시 완료 -USDT0는 가스 지불 및 가치 이전을 위한 기본 자산이며, 동시에 ERC-20 서명(`approve`, `transfer`, `transferFrom`, `permit`)을 지원합니다. [가스 토큰으로서의 USDT](/ko/explanation/usdt-as-gas-token)를 참조하세요. +USDT0은 Gas 지불 및 가치 전송을 위한 기본 자산이며, 동시에 ERC-20 표면(`approve`, `transfer`, `transferFrom`, `permit`)을 지원합니다. [USDT를 Gas로 사용](/ko/explanation/usdt-as-gas-token)을 참조하세요. -### Stable Pay & Stable 이름: 진행 중 +### Stable Pay 및 Stable Name: 진행 중 -Stable Pay는 기존 Web3 지갑과의 호환성을 유지하면서 신규 사용자의 온보딩을 단순화하도록 설계된 Web2.5 UX 지갑 경험입니다. Stable Name은 원시 EVM 주소를 사람이 읽을 수 있는 식별자로 대체하여 토큰을 주고받을 수 있는 사용자 친화적인 별칭 시스템입니다. +Stable Pay는 기존 Web3 지갑과 호환되면서도 신규 사용자의 온보딩을 단순화하도록 설계된 Web2.5 UX 지갑 경험입니다. Stable Name은 원시 EVM 주소를 사람이 읽을 수 있는 식별자로 대체하여 토큰을 송수신하는 사용자 친화적인 별칭 시스템입니다. -## 2단계: USDT를 위한 경험 계층 +## 2단계: USDT를 위한 경험 레이어 -상태: **개발 중.** 상태 DB 최적화는 v1.4.0 업그레이드에서 제공됩니다. 나머지 항목은 여전히 개발 중입니다. +상태: **Testnet에서 v1.4.0 릴리스 후보.** 메인넷 업그레이드 일정은 보류 중입니다. USDT Transfer Aggregator는 계속 개발 중입니다. -### 상태 DB 최적화: v1.4.0에서 제공 +### MemIAVL 상태 저장소: v1.4.0에 포함 -Stable은 상태 커밋과 상태 스토리지를 분리합니다. 검증자는 최신 상태를 메모리에 커밋하고, 이력 상태는 디스크로 지연됩니다. `mmap`으로 구동되는 `MemDB` 및 `VersionDB`는 디스크 I/O에 블로킹 없이 실시간 커밋을 처리합니다. [스토리지 (StableDB)](/ko/explanation/stable-db)를 참조하세요. +MemIAVL은 LevelDB를 하나의 메모리 매핑 스냅샷과 추가 전용 쓰기 선행 로그로 대체합니다. RocksDB 기반 VersionDB는 보존된 스냅샷보다 오래된 기록 쿼리를 처리합니다. [저장소 (StableDB)](/ko/explanation/stable-db)를 참조하세요. -### 낙관적 병렬 실행: 계획 중 +### 낙관적 병렬 실행: v1.4.0에 포함 -실제 측정에 따르면 트랜잭션의 60-80%가 분리된 상태와 상호 작용하며 안전하게 병렬로 실행될 수 있습니다. Stable은 충돌이 없는 가정 하에 낙관적으로 트랜잭션을 실행하며, 충돌이 감지되면 롤백 및 순차 재실행을 수행합니다. 이는 정확성을 유지하면서 처리량을 향상시킵니다. +Block-STM은 CPU 코어 간에 트랜잭션을 동시에 실행하고, 충돌을 감지하며, 영향을 받는 작업을 재실행합니다. 고정된 블록 내 순서는 검증자 간에 결정론적 상태를 유지합니다. [실행](/ko/explanation/execution)을 참조하세요. -### USDT 전송 집계기: 계획 중 +### 선택적 RecheckTx: v1.4.0에 포함 -USDT0 전송을 그룹화하여 일괄 처리하는 집계 메커니즘으로, 트랜잭션당 오버헤드를 줄이고 전체 처리량을 향상시킵니다. [USDT 전송 집계기](/ko/explanation/usdt-transfer-aggregator)를 참조하세요. +블록이 커밋되면 노드는 영향을 받는 계정의 보류 중인 트랜잭션만 재확인합니다. 애플리케이션 지원을 사용할 수 없는 경우 CometBFT는 전체 멤풀 재확인으로 폴백합니다. -### 보장된 블록 공간: 계획 중 +### 2D 논스 및 보장된 블록 공간: v1.4.0에 포함 -엔터프라이즈 파트너를 위한 예약된 블록 용량으로, 검증인 수준의 예약 및 전용 RPC 엔드포인트를 통해 강제됩니다. 네트워크 혼잡 시에도 중요한 지불 흐름에 대해 예측 가능한 대기 시간을 제공합니다. [보장된 블록 공간](/ko/explanation/guaranteed-blockspace)을 참조하세요. +독립적인 논스 채널은 하나의 막힌 트랜잭션이 동일한 계정의 모든 후속 트랜잭션을 차단하는 것을 방지합니다. 프로토콜 예약된 논스 키는 VIP 트래픽을 식별하는 반면, 레인별 Gas 할당량은 블록 용량을 예약합니다. [보장된 블록 공간](/ko/explanation/guaranteed-blockspace)을 참조하세요. -## 3단계: USDT를 위한 풀스택 최적화 계층 +### USDT Transfer Aggregator: 계획 중 -상태: **계획 중.** - -### Autobahn의 StableBFT - -Stable의 CometBFT 기반 합의 계층과 자연스럽게 통합되는 DAG 기반 BFT 합의입니다. 현재 프로토콜에 대해서는 [StableBFT](/ko/explanation/consensus)를, 목표 아키텍처에 대해서는 [Autobahn](/ko/explanation/autobahn)을 참조하세요. 내부 POC(개념 증명)는 통제된 환경에서 20만 TPS 이상(합의만)을 시연했습니다. +USDT0 전송을 그룹화하고 집합적으로 처리하여 트랜잭션당 오버헤드를 줄이고 전체 처리량을 개선하는 집계 메커니즘입니다. [USDT 전송 Aggregator](/ko/explanation/usdt-transfer-aggregator)를 참조하세요. -### StableVM++ +

3단계: USDT를 위한 풀 스택 최적화 레이어

-Go 기반 EVM을 C++ 구현으로 대체하는 고성능 실행 엔진입니다. EVM 실행 속도에서 최대 6배 향상이 예상됩니다. - -### 고성능 RPC - -노드 수준 개선(실시간 체인 상태 처리), 노드 통합 인덱싱(저지연 애플리케이션 API), WebSocket을 통한 확장 가능한 pub/sub, 작업 유형별로 라우팅하는 하이브리드 로드 밸런서를 포함하는 완전한 RPC 스택입니다. 현재 분할 경로 아키텍처는 [고성능 RPC](/ko/explanation/high-performance-rpc)를 참조하세요. +상태: **계획 중.** -## 다음 권장 사항 +### Autobahn의 StableBFT -- [**아키텍처 개요**](/ko/explanation/core-optimization-overview): 로드맵이 발전하는 스택의 현재 상태를 알아보세요. -- [**토크노믹스**](/ko/reference/tokenomics): 로드맵 전반에 걸쳐 검증인 인센티브에 자금을 지원하는 경제 모델을 검토하세요. -- [**기술 개요**](/ko/explanation/tech-overview): 아키텍처 요약으로 돌아가세요. +Stable의 CometBFT 기반 합의 계층과 자연스럽게 통합되는 DAG 기반 BFT 합의. 현재 프로토콜은 [StableBFT](/ko/explanation/consensus)를 참조하고, 목표 아키텍처는 [Autobahn](/ko/explanation/autobahn)을 참조하세요. 내부 POC(Proof-of-Concept)는 통제된 diff --git a/docs/pages/ko/how-to/upgrade-node.mdx b/docs/pages/ko/how-to/upgrade-node.mdx index 7b3502c..7e09311 100755 --- a/docs/pages/ko/how-to/upgrade-node.mdx +++ b/docs/pages/ko/how-to/upgrade-node.mdx @@ -1,67 +1,79 @@ --- source_path: how-to/upgrade-node.mdx -source_sha: e18a08860589cf17c4cc3abd3c3bc4df00630efb +source_sha: c05435b6446847bcf6c1ef3c51961b184f712073 title: 업그레이드 가이드 -description: "Stable 네트워크 버전 변경을 위한 노드 업그레이드 절차, 업그레이드 유형 및 롤백 전략." +description: "Stable 네트워크 버전 변경을 위한 노드 업그레이드 절차, 업그레이드 유형, 롤백 전략." diataxis: "how-to" --- -이 가이드는 업그레이드 절차와 롤백 전략을 포함하여 Stable 노드의 업그레이드 과정을 다룹니다. +이 가이드는 업그레이드 절차 및 롤백 전략을 포함하여, Stable 노드의 업그레이드 프로세스를 다룹니다. -> 전체 버전 기록 및 업그레이드 세부 사항은 [버전 기록](/ko/reference/testnet-version-history)을 참조하세요. +> 전체 버전 기록 및 업그레이드 세부 정보는 [버전 기록](/ko/reference/testnet-version-history)을 참조하십시오. ## 업그레이드 유형 -### 소프트 업그레이드 (비호환성 변경 없음) +### 소프트 업그레이드 (구조적 변경 없음) - 언제든지 수행 가능 - 하위 호환성 유지 -### 하드 업그레이드 (호환성 변경) +### 하드 업그레이드 (구조적 변경) - 특정 높이에서 업그레이드 필요 -- 하위 호환되지 않음 +- 하위 호환성 없음 ### 긴급 업그레이드 -- 중요한 보안 수정 +- 주요 보안 수정 사항 - 즉각적인 조치 필요 -- 체인 중단이 필요할 수 있음 +- 체인 일시 중지 필요할 수 있음 + +## v1.4.0 스토리지 마이그레이션 + +v1.4.0은 LevelDB 기반 상태 스토리지를 MemIAVL로 대체합니다. 이 업그레이드에는 일반적인 바이너리 교체 외에 데이터 마이그레이션이 필요합니다. + +네트워크별 업그레이드 지침에 다른 방법이 명시되지 않는 한 로컬 스냅샷 내보내기 및 복원 기능을 사용하십시오. 벤치마킹 결과 표준 복원의 경우 평균 19.4초, 병렬 복원의 경우 약 2.6초의 유효성 검사기 다운타임이 측정되었습니다. + +투표 권한의 최소 2/3가 온라인 상태를 유지하도록 라운드 로빈 순서로 유효성 검사기를 마이그레이션하십시오. 노드가 가장 오래 보관된 스냅샷보다 오래된 기록 쿼리에 응답해야 하는 경우 RocksDB 기반 VersionDB를 구성하십시오. + +:::warning +아래의 일반 바이너리 전용 절차를 v1.4.0에 사용하지 마십시오. [네트워크 업그레이드](/ko/reference/network-upgrades)에서 최종 네트워크별 바이너리, 업그레이드 높이, 백업 경로 및 복원 명령을 확인하십시오. +::: ## 표준 업그레이드 절차 ### 1단계: 준비 ```bash -# Check current version +# 현재 버전 확인 stabled version --long -# Backup critical data +# 중요 데이터 백업 cp -r ~/.stabled/config ~/stable-backup-$(date +%Y%m%d)/ -# For validators only: Backup validator state +# 유효성 검사기만 해당: 유효성 검사기 상태 백업 cp ~/.stabled/data/priv_validator_state.json ~/stable-backup-$(date +%Y%m%d)/ -# Check disk space (need 2x current data size) +# 디스크 공간 확인 (현재 데이터 크기의 2배 필요) df -h ~/.stabled ``` ### 2단계: 새 바이너리 다운로드 ```bash -# For v1.2.0-rc1 upgrade (January 22, 2026) -# Choose your architecture: +# v1.2.0-rc1 업그레이드 (2026년 1월 22일) +# 아키텍처 선택: # Linux AMD64 BINARY_URL="https://stable-data-dist.s3.us-east-1.amazonaws.com/testnet/binary/stabled-1.2.0-rc1-linux-amd64-testnet.tar.gz" -# OR Linux ARM64 +# 또는 Linux ARM64 BINARY_URL="https://stable-data-dist.s3.us-east-1.amazonaws.com/testnet/binary/stabled-1.2.0-rc1-linux-arm64-testnet.tar.gz" -# Download new binary +# 새 바이너리 다운로드 wget $BINARY_URL -# Extract to temporary location +# 임시 위치에 압축 해제 tar -xvzf stabled-1.2.0-rc1-linux-*.tar.gz -C /tmp/ -# Verify new version +# 새 버전 확인 /tmp/stabled version --long ``` @@ -70,82 +82,82 @@ tar -xvzf stabled-1.2.0-rc1-linux-*.tar.gz -C /tmp/ #### 소프트 업그레이드의 경우 ```bash -# Stop node +# 노드 중지 sudo systemctl stop ${SERVICE_NAME} -# Backup current binary +# 현재 바이너리 백업 sudo mv /usr/bin/stabled /usr/bin/stabled.backup -# Install new binary +# 새 바이너리 설치 sudo mv /tmp/stabled /usr/bin/stabled sudo chmod +x /usr/bin/stabled -# Verify installation +# 설치 확인 stabled version --long -# Start node +# 노드 시작 sudo systemctl start ${SERVICE_NAME} -# Monitor logs +# 로그 모니터링 sudo journalctl -u ${SERVICE_NAME} -f ``` #### 하드 업그레이드의 경우 ```bash -# Monitor for upgrade height +# 업그레이드 높이 모니터링 while true; do HEIGHT=$(curl -s localhost:26657/status | jq -r '.result.sync_info.latest_block_height') - echo "Current height: $HEIGHT" + echo "현재 높이: $HEIGHT" if [ $HEIGHT -ge $UPGRADE_HEIGHT ]; then break fi sleep 10 done -# Node will halt automatically at upgrade height -# Wait for halt message in logs +# 노드는 업그레이드 높이에서 자동으로 중지됩니다. +# 로그에서 중지 메시지 대기 sudo journalctl -u ${SERVICE_NAME} -f | grep "UPGRADE" -# Once halted, perform upgrade +# 중지되면 업그레이드 수행 sudo systemctl stop ${SERVICE_NAME} sudo mv /usr/bin/stabled /usr/bin/stabled.backup sudo mv /tmp/stabled /usr/bin/stabled -# Start with new binary +# 새 바이너리로 시작 sudo systemctl start ${SERVICE_NAME} ``` -### 4단계: 업그레이드 후 검증 +### 4단계: 업그레이드 후 확인 ```bash -# Check node status +# 노드 상태 확인 curl -s localhost:26657/status | jq '.result' -# Verify version +# 버전 확인 curl -s localhost:26657/status | jq '.result.node_info.version' -# Check peers +# 피어 확인 curl -s localhost:26657/net_info | jq '.result.n_peers' -# Monitor sync status +# 동기화 상태 모니터링 watch -n 2 'curl -s localhost:26657/status | jq ".result.sync_info"' -# Check for errors +# 오류 확인 sudo journalctl -u ${SERVICE_NAME} --since "10 minutes ago" | grep -i error ``` -## Cosmovisor 설정 (자동 업그레이드) +## 코스모바이저 설정 (자동 업그레이드) -Cosmovisor는 조율된 업그레이드를 위한 업그레이드 과정을 자동화합니다. +코스모바이저는 조율된 업그레이드를 위한 업그레이드 프로세스를 자동화합니다. ### 설치 ```bash -# Install cosmovisor +# 코스모바이저 설치 go install cosmossdk.io/tools/cosmovisor/cmd/cosmovisor@latest -# Or download binary +# 또는 바이너리 다운로드 wget https://github.com/cosmos/cosmos-sdk/releases/download/cosmovisor%2Fv1.7.0/cosmovisor-v1.7.0-linux-amd64.tar.gz tar -xzf cosmovisor-v1.7.0-linux-amd64.tar.gz sudo mv cosmovisor /usr/bin/ @@ -154,7 +166,7 @@ sudo mv cosmovisor /usr/bin/ ### 구성 ```bash -# Set environment variables +# 환경 변수 설정 cat >> ~/.bashrc < /dev/null < > export.json -# 3. Wait for coordinated restart instructions +# 3. 조정된 재시작 지침 대기 ``` ## 다음 단계 - [버전 기록](/ko/reference/testnet-version-history) - 전체 업그레이드 기록 및 릴리스 노트 - 업그레이드 후 [노드 모니터링](/ko/how-to/monitor-node) -- 일반적인 문제는 [문제 해결](/ko/how-to/troubleshoot-node)을 검토하세요 +- 일반적인 문제에 대한 [문제 해결](/ko/how-to/troubleshoot-node) 검토 diff --git a/docs/pages/ko/reference/network-upgrades.mdx b/docs/pages/ko/reference/network-upgrades.mdx index d6b0ea7..8e2994c 100644 --- a/docs/pages/ko/reference/network-upgrades.mdx +++ b/docs/pages/ko/reference/network-upgrades.mdx @@ -1,26 +1,26 @@ --- source_path: reference/network-upgrades.mdx -source_sha: 61ebe51988bd8aa1a4e15f0325410428a423a8b0 +source_sha: cdcb426b3580e25ac41f039bd750b4356f3803ce title: "네트워크 업그레이드" -description: "Stable 네트워크 프로토콜 버전에 대한 릴리스 노트: 각 릴리스에서 변경된 사항 및 조치 필요 여부." +description: "Stable 네트워크 프로토콜 버전에 대한 릴리스 노트: 각 릴리스에서 변경된 사항 및 조치해야 할 사용자." diataxis: "reference" --- # 네트워크 업그레이드 -아래 각 항목은 StableChain 릴리스에서 변경된 내용, 중요한 이유, 그리고 조치 필요 여부를 설명합니다. 릴리스는 최신 버전부터 나열됩니다. 바이너리, 커밋 해시 및 업그레이드 블록 높이에 대한 자세한 내용은 [메인넷 버전 기록](/ko/reference/mainnet-version-history) 및 [테스트넷 버전 기록](/ko/reference/testnet-version-history)을 참조하십시오. +아래 각 항목은 StableChain 릴리스에서 변경된 내용, 중요한 이유 및 필요한 조치 사항에 대해 설명합니다. 릴리스는 최신 버전부터 나열됩니다. 바이너리, 커밋 해시 및 업그레이드 블록 높이에 대해서는 [메인넷 버전 히스토리](/ko/reference/mainnet-version-history) 및 [테스트넷 버전 히스토리](/ko/reference/testnet-version-history)를 참조하세요. -## 이러한 노트를 읽는 방법 +## 이 노트 읽는 방법 -몇 가지 용어가 있습니다. 의미는 다음과 같습니다. +몇 가지 용어가 나옵니다. 의미는 다음과 같습니다. -- **상태를 깨는 업그레이드**: 모든 노드는 거버넌스 제안을 통해 조율된 동일한 블록 높이에서 새 바이너리를 실행해야 합니다. 이러한 릴리스에는 버전 기록 테이블에 업그레이드 높이가 있습니다. 유효성 검사기를 실행하는 경우 예정된 시간에 업그레이드해야 하며, 그렇지 않으면 노드가 체인을 따르지 않습니다. -- **하위 호환 업그레이드**: 새 바이너리가 이전 바이너리와 함께 작동하므로 조정된 전환이 없습니다. 이러한 릴리스에는 업그레이드 높이가 없습니다. 바이너리를 교체하여 원하는 시기에 업그레이드할 수 있습니다. -- **가스 면제**: 스폰서가 트랜잭션 수수료를 부담할 수 있도록 하는 StableChain 기능으로, 발신자는 가스 토큰을 보유하지 않고도 트랜잭션을 처리할 수 있습니다. -- **시스템 트랜잭션**: 일반 사용자가 아닌 프로토콜 자체가 내부 작업을 실행하기 위해 발행하는 특별한 트랜잭션입니다. -- **프리컴파일**: EVM 바이트코드 대신 네이티브 코드를 실행하는 고정 주소의 내장 계약으로, 빠르고 공통적인 작업에 사용됩니다. +- **상태를 깨는 업그레이드 (State-breaking upgrade)**: 모든 노드는 거버넌스 제안을 통해 조정된 동일한 블록 높이에서 새 바이너리를 실행해야 합니다. 이러한 릴리스는 버전 히스토리 테이블에 업그레이드 높이가 있습니다. 검증자를 실행하는 경우, 일정에 맞춰 업그레이드하지 않으면 노드가 체인을 따르지 않습니다. +- **하위 호환 가능한 업그레이드 (Backward-compatible upgrade)**: 새 바이너리가 이전 바이너리와 호환되므로, 조정된 전환이 필요하지 않습니다. 이러한 릴리스에는 업그레이드 높이가 없습니다. 바이너리를 교체하여 원하는 시점에 언제든지 업그레이드할 수 있습니다. +- **가스 면제 (Gas waiver)**: 트랜잭션 수수료를 후원자가 부담하여 발신자가 가스 토큰을 보유하지 않고도 트랜잭션을 처리할 수 있도록 하는 StableChain 기능입니다. +- **시스템 트랜잭션 (System transaction)**: 일반 사용자가 아닌 프로토콜 자체가 내부 작업을 실행하기 위해 발행하는 특별한 트랜잭션입니다. +- **프리컴파일 (Precompile)**: 고정된 주소에 위치한 내장 컨트랙트로, EVM 바이트코드 대신 네이티브 코드를 실행하여 빠르게 처리해야 하는 일반적인 작업에 사용됩니다. -노드가 실행하는 버전을 확인하려면 다음을 수행합니다. +노드가 실행 중인 버전을 확인하려면 다음을 수행하세요. ```bash stabled version @@ -30,78 +30,11 @@ stabled version v1.3.1 ``` -## v1.4.0 (예정) :badge[Testnet]{warning} +## v1.4.0 (예정) :badge[테스트넷]{warning} -현재 테스트넷에 릴리스 후보로 등록되어 있으며 메인넷에는 아직 출시되지 않은 성능 및 예측성 릴리스입니다. 블록 처리 속도를 높이고, 우선 순위 트래픽에 대한 트랜잭션 포함을 더욱 예측 가능하게 하는 두 가지 주제 아래 네 가지 변경 사항을 그룹화합니다. +성능 및 예측 가능성 릴리스로, 현재 테스트넷에서 릴리스 후보로 운영 중이며 아직 메인넷에는 적용되지 않았습니다. 이 릴리스는 블록 처리 속도 향상과 우선 순위 트래픽의 트랜잭션 포함 예측 가능성이라는 두 가지 주제 아래 네 가지 변경 사항을 그룹화합니다. -**예정된 내용:** - -- **낙관적 병렬 실행(OPE)**: 블록의 트랜잭션을 한 번에 하나씩이 아니라 병렬로 실행한 다음 결과를 조정합니다. 이는 Block-STM을 기반으로 합니다. -- **선택적 RecheckTx**: 새 블록 이후에는 전체 mempool(포함 대기 중인 트랜잭션 풀)이 아닌, 실제로 영향을 받은 보류 중인 트랜잭션만 재검증합니다. -- **MemIAVL**: 이전 LevelDB 기반 스토리지를 대체하는 메모리 매핑 스토리지 계층으로, 블록 라이프사이클의 주요 병목 현상을 줄입니다. -- **2D 논스 및 보장된 블록 공간**: 병렬 논스 채널을 통해 하나의 계정이 여러 독립적인 레인에서 트랜잭션을 보낼 수 있으며, 보장된 블록 공간은 포함을 우연에 맡기지 않고 우선 순위 워크로드에 대한 블록 용량을 예약합니다. - -:::note -v1.4.0은 아직 감사 및 테스트 중입니다. 메인넷 업그레이드 전에 범위와 시기가 변경될 수 있습니다. 최신 릴리스 후보는 [테스트넷 버전 기록](/ko/reference/testnet-version-history)을 추적하십시오. -::: - -## v1.3.1 :badge[Current]{success} - -하위 호환 패치이자 현재 메인넷 버전입니다. 조정된 업그레이드 높이 없이 출시되므로 노드 운영자는 언제든지 바이너리를 교체하여 채택할 수 있습니다. - -## v1.3.0 - -상태를 깨는 보안 중심 업그레이드로, 가스 면제 기능을 더욱 유연하게 만들었습니다. 가스 면제 변경으로 인해 지갑 및 거래소와 같은 새로운 파트너는 매번 다른 상태를 깨는 업그레이드가 필요 없이 나중에 거버넌스 제안을 통해 온보딩될 수 있습니다. - -**조치 필요 대상:** 모든 노드 운영자는 예정된 높이에서 업그레이드합니다. 정확한 높이는 [메인넷 버전 기록](/ko/reference/mainnet-version-history)을 참조하십시오. - -**보안 개선 사항:** - -- 비공개 JSON-RPC 네임스페이스는 더 이상 등록되지 않으며, 서명 API는 `AllowInsecureUnlock=true`인 경우에만 활성화됩니다. -- 가스 면제 입력이 강화되었습니다: 주소는 EIP-55 표준 형식을 사용해야 하며, 쿼리 입력은 길이 및 형식 제한이 있으며, 래퍼 유형, 체인 ID, EIP-7702 내부 트랜잭션 유효성 검사가 강화되었습니다. -- 시스템 트랜잭션은 이제 `from` 주소뿐만 아니라 `to` 주소 및 메서드 선택자에 대해 유효성 검사를 받습니다. 이는 수수료 없는 실행을 유발할 수 있는 경로를 차단합니다. -- 프라하 프리컴파일 주소 범위가 차단된 주소 목록에 추가되었으며, 알려지지 않은 프리컴파일 메서드에는 이제 쿼리 가스가 필요합니다. - -**버그 수정 및 안정성:** - -- 실패한 상태 저장 프리컴파일 호출에 대한 가스 회계를 수정했습니다. -- ERC-20 내부 호출 실패 후 환불 비활성화 상태 누출을 해결했습니다. -- 프리컴파일 웜 세트 추적 및 `COINBASE` opcode 동작을 수정했습니다. -- EIP-7702 권한 부여 롤백을 사양에 맞게 조정했습니다. -- `from=0x0`으로 보고된 시스템 트랜잭션 응답, `feeHistory` 오류 로깅 및 기록 전체 트랜잭션 응답의 체인 ID 일관성을 수정했습니다. - -## v1.2.2 - -StableChain을 공식 업스트림 합의 릴리스와 일치시키고 두 가지 쿼리 동작을 정리하는 하위 호환可选 업그레이드입니다. - -**조치 필요 대상:** 아무도 필요하지 않습니다. 이 업그레이드는 거버넌스 제안이 필요하지 않습니다. 노드 운영자는 편리할 때마다 바이너리를 교체하여 채택할 수 있습니다. - -**변경 사항:** - -- CometBFT를 공식 `v0.38.21`로 업그레이드했습니다. 이는 v1.1.4에 이전에 출시된 보안 패치를 따르며, 외부 파트너가 네트워크가 실행하는 정확한 합의 버전을 확인할 수 있도록 합니다. -- 가스 면제 트랜잭션 쿼리에서 중복 로그 인덱스를 제거했습니다. -- 시스템 트랜잭션 쿼리에 대한 RPC 응답에 안전 장치를 추가했습니다. - -## v1.2.1 - -익스플로잇될 경우 체인을 중단시킬 수 있는 두 가지 문제를 해결한 하위 호환 핫픽스입니다. - -**조치 필요 대상:** 유효성 검사기는 업그레이드해야 합니다. RPC 공급자를 포함한 다른 노드 운영자의 경우 업그레이드는 선택 사항입니다. 거버넌스 제안이 필요하지 않습니다. - -**수정 사항:** - -- 사용자가 인증을 우회하고 시스템 전용 프리컴파일을 호출하기 위해 `MsgEthereumTx.From == 0x1`을 설정할 수 있는 시스템 트랜잭션 스푸핑 경로를 닫고, 스푸핑된 트랜잭션을 사용하여 `ProcessProposal`이 블록을 반복적으로 거부하고 합의를 중단시키도록 강제하는 문제를 해결했습니다. -- `ExtensionOptionsWaiver` 트랜잭션이 `CheckTx`를 통과할 수 있지만 `ProcessProposal`이 전체 블록을 거부하게 만들 수 있는 mempool 오염으로 인한 체인 중단 문제를 수정했습니다. - -## 이전 릴리스 - -자세한 릴리스 노트는 v1.2.1부터 시작됩니다. v1.2.0 및 이전 릴리스(제네시스 릴리스 포함)의 바이너리, 커밋 해시 및 업그레이드 높이에 대한 자세한 내용은 버전 기록 테이블을 참조하십시오. - -- [메인넷 버전 기록](/ko/reference/mainnet-version-history): 모든 메인넷 버전과 해당 바이너리 및 업그레이드 높이. -- [테스트넷 버전 기록](/ko/reference/testnet-version-history): 릴리스 후보를 포함한 모든 테스트넷 버전. - -## 다음 단계 - -- [**노드 업그레이드**](/ko/how-to/upgrade-node): 노드를 새 버전으로 이동하는 단계별 절차를 따릅니다. -- [**메인넷 버전 기록**](/ko/reference/mainnet-version-history): 모든 메인넷 릴리스에 대한 커밋 해시, 바이너리 및 업그레이드 높이를 찾아봅니다. -- [**메인넷 정보**](/ko/reference/mainnet-information): 체인 ID, RPC 엔드포인트 및 현재 네트워크 매개변수를 가져옵니다. +| **구상** | **블록 단계** | **변경 내용** | **예상 결과** | +| :--- | :--- | :--- | :--- | +| 낙관적 병렬 실행(OPE) | 실행 | 블록-STM이 순차적인 트랜잭션 실행을 대체합니다. | 멀티코어 실행, 약 10,000 TPS 목표. | +| 선택적 RecheckTx | 커밋 후 멤풀 재확인 | 노드는 커밋된 블록에 의해