在我们上一篇博文《最终确定性揭晓：对 F3 主网启动的被动测试》中，我们分享了快速确定性 （F3） 的潜力，并概述了以 2025 年初为目标部署的时间表。从那时起，我们的工程团队以 100% 的规模进行了密集的主网被动测试。这是 F3 首次在真实条件下以 100% 的主网规模进行测试，这揭示了令人鼓舞的结果，并揭示了有关网络行为、参与要求和一些额外优化需求的重要启示。
此博客更新有两个目的：首先，分享我们从测试工作中获得的技术见解，其次，概述对部署时间表的必要调整。这些变化反映了我们致力于确保 F3 在主网上线时的稳定性和有效性。
🔍 测试洞察：成功与改进领域
在 4 周的时间里，我们进行了 47 轮被动测试，逐渐从一小部分网络参与扩展到 100% 的完全网络参与。我们想向整个 Filecoin 社区大喊大叫，他们提出了很好的问题，通知我们过多的日志，并提出了潜在的担忧。
开发人员投入了大量精力来优化和监控指标、调整参数以及边缘情况测试以启动和停止系统。我们还在 Github Discussion 帖子中发布了每日被动测试报告。我们的测试侧重于 F3 运行的两个关键阶段：
1. The Bootstrap Phase：F3 赶上最新状态的位置
2. The Steady State Phase：在初始 Bootstrap 阶段之后链的持续最终确定
✅ Bootstrapping — 指标看起来不错
在 F3 中，网络中的节点协同工作，以赶上最近发布的 epoch。他们一次以 100 个 epoch 为一组执行此操作，直到到达最近的 epoch。当 F3 开始引导阶段时，它通常需要处理大约 900 个块才能跟上速度。下面是在我们的一轮被动测试期间发生的 Bootstrapping 阶段的图片。Bootstrap phase
Y 轴显示 F3 （Fast Finality） 落后于最新 epoch 的 epoch 数，而 X 轴表示时间。
在被动测试期间，我们对 Bootstrap 阶段的目标是调整 F3 中的参数和可用旋钮 — 例如，我们等待消息到达的时间、我们重试发送消息的频率等 — 以使此图表中的 “楼梯” 尽可能短并尽可能快地发生。但有一个很大的警告：如果我们把它设置得太陡峭，它会增加节点的带宽使用，这并不理想，并且可能会使节点承受巨大的压力——所以这里有一个微妙的平衡。
经过一段时间观察和调整这些指标后，我们成功地优化了这个阶段。在 100% 的网络规模下，我们能够在大约 1 小时 10 分钟内完成引导阶段，而节点带宽使用平均不到 10 MiB/s 的下载和 10 MiB/s 的上传。大获成功！
😬 稳态挑战
随着 F3 的引导阶段进入后视镜，我们在被动测试轮次中的下一个目标是确保 F3 的稳定状态“足够好”以在主网上激活它。我们所说的“足够好”是指最终确定进度随着时间的推移是一致的，并且最终确定链的速度相对较快。
在多轮测试的过程中，我们意识到还有一些额外的旋钮和参数，我们真的希望可以调整，这可以让我们达到这种 “足够好” 的状态。
⚠️ 第一个挑战：进度不够稳定
我们观察到，在稳态下，F3 在某些时期不够一致。这种不一致有很多缺点;在 F3 API 上构建应用程序的构建者需要 API 保持一致，否则会给人们留下事情“坏了”的印象。此外，这种不一致会导致带宽使用率较高的时期和峰值，这对于节点运营商来说并不理想。
我们需要一个更一致的 “Zig-Zag” 模式！
⚠️ 第二个挑战：稳态是否“足够快”？此外，在稳态下，我们观察到 “ZigZag” 形态的深度太大。这意味着我们没有足够快地完成链，以至于我们认为它足够好，可以在主网上激活：
虽然 70 个 epoch 的最终确定时间比目前的 900 个 epoch 要好得多，但 pattern 的深度有点太高了。
我们的目标是调整参数，使这个 ZigZag 形态的深度尽可能小，并且至少应低于 50 个时期。
这些挑战可能通过参数调整来解决。然而，我们面临着一个冲突：由于 和 phase 共享一组参数和控制;我们无法同时优化两者。试图使稳态更加一致和更快，这损害了我们有效完成 Bootstrap 阶段的能力。Bootstrap PhaseSteady State
归根结底，这些挑战的原因源于运营商在网络中需要有更高的电力参与率，以克服我们在当前主网上活动的软件在堆栈中进一步遇到的网络拥塞。
我们只需要 66% 的功率参与 F3 即可前进，但在实践中，我们遇到了消息延迟传播等问题，这意味着我们需要更高的功率参与 F3 才能向前发展。通过工程改进，我们可以优化网络拥塞路径，但进行这些改进需要时间，而提供这些改进需要每个人都升级他们的节点，这意味着提供这些优化的时间窗口仅限于网络升级。
🐾 修订后的时间表和后续步骤
虽然 F3 实现已经展示了有前景的功能，但测试阶段揭示了需要额外的优化和参数调整，例如压缩消息和对链进行哈希处理以降低带宽使用量。推迟原始部署的决定反映了我们致力于确保可靠可靠的实施，从而能够有效处理主网规模的操作。
我们现在预计在 2025 年第 2 季度激活 F3。这个延长的时间表使我们能够通过 network 25 升级提供额外的改进，这有助于优化 F3 运行时的网络拥塞，并为我们提供额外的可调旋钮和参数，使我们能够微调参数设置，以便我们可以在 nv25 中进行另一轮被动测试，并使 F3 的稳定状态足够好，以便之后激活主网。
我们将继续提供博客更新！本系列的下一篇文章将深入探讨我们将如何激励 F3 参与，以及委托设置参数以更快地激活 F3 的权限。目前，延长的时间表将允许进行全面优化，确保我们在大规模上使 F3 足够快。
往期回顾![]()
IPFS万佳社区
