Sui 的权益证明 (PoS) 机制集成了时代和验证器集，以确保网络安全和共识，这与 EVM 链有很大不同. 以下是根据您的开发目标量身定制的详细说明：

苏伊的时代

Sui 在称为周期的离散时间段内运行，每个周期持续约 24 小时（可配置，默认 864,000 个插槽，每个时隙约 150 毫秒）. Epochs 管理验证器集合变更和共识参数： -结构：每个纪元都以系统交易设置参数（例如赌注阈值、奖励）开始，最后以完成状态变化的检查点结束. -过渡：验证者通过系统移动调用提出一个新时代，需要 2f+1 协议（其中 f 是错误验证器的最大数量）. 这会触发重新配置时间，网络会短暂暂停止. -目的：Epoch允许在不中断链的情况下进行动态验证器集合更新、权益重新授权和参数调整.

验证器集合和 PoS

Sui 使用委托 PoS 模型，其中验证者是根据质押的 SUI 代币选举的： -选举：验证者必须投注最低金额（例如 30 SUI，可调）并吸引用户的委托. 按总赌注计算的前 N 个验证者（例如 100 个）构成活跃集合. -共识：Sui 对共享对象采用拜占庭容错 (BFT) 协议（Narwhal/Bullshark），确保总共有 3f+1 个诚实的验证者中有 2f+1 个诚实的验证者. 对于简单的交易，它使用没有完全共识的并行处理. -奖励和削减：验证者从交易费用和存储资金再分配中获得与赌注成比例的奖励. 尽管具体细节是由治理决定的，但不当行为（例如双重签名）会导致削减. -轮换：在纪元结束时，赌注变化会触发新的验证器集合，非活跃的验证者退出，新的验证者根据赌注排名进入.

这与以太坊等 PoS 链中 EVM 的静态验证器集形成鲜明对比，后者通过硬分叉或升级进行更改.

建筑概念

-系统状态对象：跟踪纪元数据（例如开始时间、验证器设置）并通过系统移动进行更新. -并行性：Sui 的对象模型允许非重叠交易绕过共识，与 EVM 的顺序执行相比，减少了与时代相关的瓶颈. -重新配置时间：纪元转换期间的短暂停顿（秒）可确保状态一致性，这是灵活性的独特折衷方案.

移动代码结构

系统移动可以管理纪元转换，但开发人员可以与纪元数据进行交互. 示例：

移动 模块 my_module:: epoch_tracker { 使用 sui:: epoch_time:: EpochTime; 使用 sui:: tx_context:: txContext;

公共结构 EpochData 有密钥，存储 { ID：UID， current_epoch：u64， }

公开报名 fun update_epoch（数据：&mut EpochData，epoch：u64，ctx：&mut txContext）{ data.current_epoch = 纪元; //基于 epoch 的额外逻辑 }

公开参赛乐趣 create_epoch_tracker (ctx: &mut txContext) { 让数据 = EpochData { id: 对象:: 新建 (ctx)， current_epoch: epoch_time:: current_epoch (ctx)， }; 传输:: 传输（数据，tx_context:: sender (ctx)）； } }

-关键点：使用 epoch_time:: current_epoch 访问当前时代. 系统移动（例如 sui_system:: request_add_validator）仅限于治理. -安全：验证纪元数据以防止在重新配置期间进行操作.

CLI 用法

通过 Sui CLI 管理验证器交互和纪元数据： -Check Epoch: 猛击 sui 客户端 get-epoch-info

-输出：当前纪元、开始时间、验证器设置. -Stake SUI（作为委托人）： 猛击 sui 客户股份--金额 100--验证器--gas-budget 1000000

-注意：余额不足或验证器地址无效. -请求添加验证器（仅限治理，在本地网络上模拟）： 猛击 sui 客户端调用--package--m odule sui_system--function request_add_validator--args--gas-bud

-注意：需要系统包 ID 和监管角色. -本地网络设置： 猛击 sui-test-validator--with-faucet

-通过调整配置（例如，缩短纪元持续时间）来模拟纪元过渡.

最佳实践和安全原则

1. Epoch-Aware Logic：设计合约来处理重新配置暂停（例如，重试交易）.
2. 权益监控：使用 CLI 或 SDK 跟踪验证者权益，确保委托给可靠节点. 3.测试：使用 sui-test-validator--epoch-duration-ms 10000 在本地网络上模拟纪元过渡来测试行为. -常见错误：重新配置期间事务已过期——延长超时时间或重试.
3. 安全性：避免在未经验证的情况下依赖特定时期的数据，因为重新配置可能会改变状态.
4. 现实条件：在测试网上使用不同的权益分配进行测试，以模仿验证器集合的变化.

与 EVM 和开发影响的区别

-动态验证器：EVM PoS（例如以太坊）在升级之前会修复验证器，而 Sui 基于时代的轮换支持适应性，非常适合需要频繁调整的 DeFi 流动性池. -并行性：与 EVM 基于区块的限制不同，Sui 的对象级并行性降低了纪元开销，有利于 NFT 铸造或钱包批量操作. -开发：与EVM的开放合约部署形成鲜明对比，Move的系统移动限制需要治理互动，因此需要仔细规划与验证器相关的功能.

常见错误和修复

-忽略重新配置：假设在过渡期间连续操作失败. 修复：实现重试逻辑. -赌注无效：投注低于最低限度会触发错误. 修复：检查 get-epoch-info 以了解阈值. -网络不匹配：在测试网上使用主网 CLI 失败. 修复：与目标网络保持一致（例如，sui 客户端交换机--env 测试网）.

这适用于智能合约（基于时代的逻辑）、NFT（依赖验证者的铸币）、钱包（股权跟踪）和DeFi（动态流动性池）. 在本地网络/测试网络上进行广泛测试，以确保跨时代边界的稳健性.

Sui 开发了一个名为 epochs 的基于时间的系统. 默认情况下，每个周期持续约24小时，但可以更改. 你可以想象游戏回合之类的时代：一开始，系统设置规则、验证器列表和奖励参数；最后，它锁定状态，为下一轮做准备. 从一个时代移动到另一个周期时，会有一个短暂的暂停，称为重新配置时间，持续几秒钟，在此期间，网络会短暂停止以安全地进行自我更新.

现在，让我们来谈谈验证器. Sui 使用委托权益证明 (PoS) 系统. 验证者需要质押最低数量的SUI（比如30个代币），并吸引更多的用户委托才能进入前N名名单，这定义了谁将进入该时代的活跃验证器. 如果你的验证器没有进入榜首，它会在下一个时代过渡时被赶出去. 因此，质押金额和委托实际上是自动决定验证者的轮换——与以太坊不同，以太坊的验证者集合几乎是固定的，除非有网络升级或某种��理提案.

在 Sui 中，权益证明 (PoS) 系统围绕着所谓的时代——可以把它们想象成时间窗口，在这个时间窗口，验证器集合处于锁定状态以运行网络. 默认情况下，每个周期持续大约 24 小时，但它是可配置的. 当一个时代开始时，系统会设置规则，例如赌注阈值以及谁在验证器集中. 当状态结束时，系统会干净地结束状态，为下一次状态做准备.

现在有趣的地方在于：在周期之间的切换期间，网络会暂停几秒钟. 这种暂停称为重新配置时间，它为系统提供了安全轮换验证器或更改内部参数的空间. 您的应用程序需要知道这一点，因为在此短暂窗口内发送的交易可能会失败或过期.

验证器选择是动态的. 如果你正在运行验证器，你需要质押一些 SUI 并让其他人委托给你. 该网络会自动按总赌注选出排名靠前的验证者，并在每个周期形成活跃集合. 如果有人获得比你更多的赌注，你可能会在下一轮被赶出局. 委托人还可以在每个周期转移赌注，因此不稳定. 与以太坊不同，在以太坊中，验证器变更需要协议升级，而Sui每天都要处理.

共识的运作方式也有所不同. Sui 使用 Narwhal 和 Bullshark 进行共享对象交易，这需要协调. 但是，如果你的应用程序处理自有对象（例如个人钱包），它会跳过完全的共识，并行处理事情. 这改变了游戏规则，因为这意味着您的交易不会像在以太坊上那样等待无关的交易.

在 Move 代码中，你可以使用 epoch_time:: current_epoch (ctx) 抓取当前纪元. 例如，如果你正在构建一个对纪元变化做出反应的模块，你可以创建自己的对象来存储和更新纪元值. 以下是外观的基本草图：

module my_module::epoch_tracker {
    use sui::epoch_time;
    use sui::tx_context::{Self, TxContext};
    use sui::object;
    use sui::transfer;

    struct EpochData has key, store {
        id: UID,
        current_epoch: u64,
    }

    public entry fun create(ctx: &mut TxContext) {
        let epoch = epoch_time::current_epoch(ctx);
        let data = EpochData { id: object::new(ctx), current_epoch: epoch };
        transfer::transfer(data, tx_context::sender(ctx));
    }

    public entry fun update(data: &mut EpochData, epoch: u64, ctx: &mut TxContext) {
        data.current_epoch = epoch;
    }
}

在Sui网络中，时代和验证器集是其委托权益证明（DPoS）共识模型的核心组成部分. Sui 中的一个周期是一个固定长度的时间窗口（例如 24 小时），在此期间，特定的验证器集负责处理交易和生成区块. 每个周期都从重新配置阶段开始，在该阶段中，验证器集可以根据前一个周期的质押输入进行更改.

1. Epochs 和验证器轮换

每个时代都有一个唯一的验证器集，由委托给每个验证者的总赌注决定.

委托人将其SUI代币质押给验证者，从而影响谁在下一个时代加入活跃集合.

在周期结束时，网络会短暂暂停以重新配置、完成该周期的检查点并过渡到下一个验证器集.

2. 验证器集合结构

验证器集存储在 Move 对象中，由系统模块 0x3:: sui_system 维护.

每个验证者都有元数据，包括其公钥、质押金额、佣金和网络地址.

结构验证器 { 元数据：验证器元数据， 投票权力：u64， gas_price: u64, 佣金率：u64， ... }

3.质押和委托

质押者通过 CLI 或 SDK 与 Sui 系统模块进行交互以委托股份：

sui 客户赌注--金额 10000000000--validator <VALIDATOR_ADDRESS>

质押的代币被锁定，会影响验证者下一个周期的总赌注.

奖励按纪元边界分配，可通过 redath_rewards 方法领取.

4. 移动互动

自动调用 sui_system:: request_epoch_change 函数来轮换验证器.

智能合约不能直接控制时代，但可以使用 sui_system 模块访问验证器信息以进行治理或质押逻辑.

5. CLI/SDK 使用情况

要查询当前的时代和验证器，请执行以下操作：

sui 客户端调用--package 0x3--模块 sui_system--function get_current_epoch sui 客户端调用--package 0x3--模块 sui_system--function get_validator_set

来自 SDK：

const Epochinfo = await provider.getLatestSuisystemState (); console.log（Epochinfo.epoch、Epochinfo.ActiveValidators）；

6. 链上治理的可能性

Sui 的结构允许使用高级质押逻辑或时代感知合约，例如划时代触发的归属或再平衡逻辑.

7. 常见陷阱

使用过时的验证器地址可能会导致质押失败.

委派时间过于接近纪元的结束可能会将效果推迟到下一个周期.

合约不能直接访问时间，但必须使用系统的时钟或纪元数据.

8. 测试和最佳实践

在本地网络上，你可以通过调用以下命令来模拟纪元转换：

sui genesis--epoch-duration-ms 10000

使用 EpochChangeEvent 事件监控重新配置.

9. 安全

确保验证器元数据已通过验证（例如，未设置 sybil 验证器）.

奖励合同应跟踪时期，以防止双重奖励.

10. 设计外卖

Sui 基于时代的 PoS 模型强制执行确定性、性能隔离和委托灵活性，这与 EVM 链持续的逐块验证器切换不同. 智能合约开发人员应将纪元转换视为逻辑的状态变化边界，这取决于时间、验证者声誉或质押流.

如果你想要一个可以读取纪元数据或验证基于权益的条件的模板Move合约，请告诉我.

在 Sui 中，时间被分成了称为纪元的块. 每个周期都像一个默认持续大约 24 小时的会话（可以更改）. 在一个时代，验证者处理交易，获得奖励并维护网络. 当一个时代结束时，系统会最终确定所有内容并进入下一个时代. 这种过渡包括短暂的暂停，称为重新配置时间，这使网络有机会安全地更新其内部状态——有点像在开始下一轮之前深吸一口气.

这些时代至关重要，因为它们是验证器集合可以更改的时候. Sui 使用委托 PoS 模型，因此验证者是根据他们持有的 SUI 数量以及其他人委托给他们的多少来选择的. 要成为验证者，您需要满足最低赌注（例如30 SUI），而要保持在顶级验证者集合中，您需要吸引足够的委托股份. 在每个周期结束时，系统会检查这些排名并自动调整验证器设置——无需硬分叉或手动升级.

为了处理共识，Sui 使用一种名为 Narwhal 和 Bullshark 的协议来进行复杂或共享状态交易. 即使少数验证者行为不当，它也能确保安全性. 但是对于不涉及共享对象的简单交易，Sui会跳过大量共识，并行运行它们，从而使一切变得更快.

验证者从交易费和存储基金中获得奖励. 如果验证者作弊（例如签署多条相互冲突的消息），他们可能会受到惩罚（削减），但其运作方式由治理决定，而不是硬编码.

在幕后，系统会在一个特殊的链上对象中跟踪纪元信息. 该对象存储诸如当前纪元、启动时间以及哪些验证器处于活动状态之类的详细信息. 开发人员无法直接控制这一点，但你可以使用epoch_time:: current_epoch（ctx）读取Move智能合约中的当前时代.

如果你想编写存储或响应时代变化的合约，你可以创建自己的对象来跟踪它. 有一个示例 Move 模块展示了如何执行此操作，包括如何更新或读取应用程序逻辑中的纪元.

要知道的重要一件事是：只有治理机构才有权调用系统级函数，例如向集合中添加新的验证器. 作为普通开发者，你无法直接从代码中触发这些操作.

要与纪元和验证器进行交互，你可以使用 Sui CLI. 你可以查看当前的时代，将你的SUI押给验证器，甚至模拟本地网络上的验证者行为. 如果您在本地运行测试网络，则可以缩短周期长度（例如，缩短到 10 秒），以查看应用程序在过渡期间的行为.

从安全和测试的角度来看，请确保您的应用程序能够处理时代转换. 这意味着重试在重新配置期间发生的失败交易，并验证时代变化时合约的逻辑是否仍然有效. 此外，还要跟踪您对哪些验证器进行质押，并避开那些正常运行时间或行为不佳的验证器.

与以太坊相比，以太坊在升级之前主要使用固定的验证器集，而Sui的验证器集是动态的，每天都在调整. 这种灵活性非常强大——尤其是对于像DeFi池这样的用例，这些用例可能需要经常更改委托——但这也意味着你需要围绕一个始终处于运行状态的系统来设计逻辑.

Sui 还支持对非重叠交易进行并行执行，从而避免了以太坊逐区块系统的瓶颈. 对于诸如NFT铸币厂或钱包交易批处理之类的大批量应用程序来说，这是一个巨大的胜利.

但是，由于 Sui 限制了对某些系统功能的访问权限，这与 EVM 的 “随时部署” 风格不同，因此，如果您的功能依赖于验证器或时代，则需要提前做好计划.

在 Sui 中，时代和验证器集是其委托权益证明 (DPoS) 共识模型的基本组成部分. 纪元是一个固定的时期，在此期间，一组特定的验证者负责验证交易和保护网络. 在每个周期结束时，可以根据质押活动和治理决策形成新的验证器集合. 验证者是根据质押的 SUI 代币的数量来选择的，委托人可以质押他们的 SUI 以参与保护网络并获得奖励. 每个验证者的投票权与其质押的总金额成正比，这直接影响共识.

Sui 的检查点机制有助于在验证者之间完成交易，并确保确定性的状态进展. 验证器变更、权益更新和协议参数修改仅在新时代开始时生效. 这个时代过渡逻辑在 Sui 的系统 Move 模块中编码，在 sui-system 包中可见. 开发人员可以使用 sui 客户端调用--function get_current_epoch 等命令通过 Sui CLI 检查纪元数据.

与 EVM 链不同，Sui 中的验证器集合更改与以对象为中心的模型和 Move 严格的访问规则紧密相关，这有助于在过渡期间保持一致性和安全性. 为避免部署问题，开发人员应在设计合约时仔细参考动态验证器信息，尤其是在治理、质押仪表板或跨时代工作流程等应用程序中.