Shardeum 推出：突破性的成就
2024 年 1 月 27 日星期一，web3 世界发生了一件开创性的事件，这可以比作航天器在首次飞行测试任务后完美返回发射台的历史性壮举。在这个非凡的场景中，Shardeum不仅面临严峻的挑战，而且取得了胜利，其网络弹性标志着分片网络首次在分布式账本技术领域实现自我修复。
正如宇宙飞船之旅需要缜密的规划、精密的工程和复杂操作的无缝执行一样，Shardeum 遭受严重事故的 Sphinx betanet 的恢复也需要同等水平的技术掌握和创新。在网络上保留所有数据的能力，尤其是使用动态分片运行的数据，是开创性的。
当我们踏上这一探索之路时，我们不仅庆祝 Shardeum 具有里程碑意义的落地，还认识到它是 web3 技术发展的分水岭时刻，这一飞跃可能会重新定义 IT 网络弹性和数据完整性的界限。
第一个独立恢复和保留数据的分片网络
动态维护和恢复分片网络（例如 Shardeum）包含一系列复杂的技术挑战，这使其与比特币或以太坊等传统区块链网络不同。在具有自动扩展功能的动态表达分片环境中，跨不同分片的节点和资源的持续重新分配和平衡对于优化性能和可扩展性至关重要。网络架构的不断变化增加了维护数据一致性、确保网络稳定性和促进有效故障恢复的复杂性。
在将 Shardeum 对节点波动的响应与比特币进行比较时，强调了这一挑战的重要性。即使节点数量很少，比特币网络也能保持功能，因为每个活动节点都有完整的状态和交易历史。相比之下，由于 Shardeum 分片网络的原因，Shardeum 上的每个活跃节点都没有完整的状态和交易历史记录，并且每个验证器仅拥有整体状态的一部分。这种分片的结果是所有验证器节点都变得非常轻量级。因此，这创造了大量的工程机会和挑战。如果一个节点宕机了，我们如何保证所有数据得到维护？ Shardeum 有两种主要方式。
首先，Shardeum 使用动态分片，整个地址空间根据活动节点的数量进行分区（或划分）。每个节点负责其分配的分区，以及其周围一定的半径（R）和与其相邻的附加分区（E），确保网络框架内的动态适应性和强大的数据冗余。因此，即使某个节点发生故障，网络仍然连续，不会丢失数据。
其次，Shardeum使用归档节点来存储整个网络的完整状态。这是通过活动节点将部分存储的状态流式传输到存档器进行收集来实现的。由于这两个因素和设计优化，必须以新的方式设计恢复此类网络，以仍然促进自动缩放和线性缩放等有益功能。
了解崩溃
现在我们了解了动态分片的基础知识以及归档器节点以某种方式参与其中，让我们更深入地分解一些附加组件并解释它们。要了解 Shardeum betanet 崩溃和恢复，我们必须首先了解以下内容：
归档器节点
检测丢失的归档器
网络模式
恢复模式
在我们深入研究所涉及的错误之前，了解其中每一个的基础知识非常重要，所以让我们来看看！
存档节点：星际存储
在Shardeum中，归档器节点也称为归档器，是非常重要的一类节点，其任务是存储网络的整个状态和历史记录。与主动节点不同，归档者不参与共识过程；其主要功能是全面归档所有网络数据，包括交易和收据。存档节点的贡献对于维护网络的完整性并确保其运行顺利运行至关重要，从而确认了 Shardeum 作为一个强大、完整和可靠的网络的地位。由于存档器是其网络的组成部分，Shardeum 必须制定协议来检测无响应的存档器（和验证器）。
丢失档案检测：外星技术揭晓
Shardeum 有一个称为丢失节点检测协议的协议，用于检测活动节点何时变得不工作 ——这仅适用于活动节点。然而，Shardeum 也有一个用于归档器的协议，它可以执行类似的操作，称为丢失归档器检测。丢失存档器检测是一种特殊协议，旨在处理一个或多个存档器无法运行并被标记为丢失的罕见情况。由于归档节点对于维护网络中历史数据的完整性和可访问性至关重要，因此至关重要的是，如果它们变得无响应或发生故障，可以捕获这些关键事件以减轻下游影响。尽管丢失的归档程序不会导致这种特定的崩溃，但丢失的归档程序检测协议和特定网络模式之间的交互会导致这种崩溃。现在我们来看看Shardeum有哪些网络模式。
Shardeum 上的网络模式：无需 NASA
Shardeum 底层 Shardus 协议支持的旗舰创新是网络模式框架。这些模式超越了基本的运行条件，实现了各种节点活动、数据同步方法和交易管理系统的复杂协调。这种网络配置在维护网络运行完整性方面发挥着重要作用，尤其是在节点和数据丢失的场景中——因为 Shardeum 是一个分片网络。
在更简单的层面上，了解 Shardeum 网络模式的最佳方法是制定一个编码良好的应急计划，即使在网络崩溃或网络范围降级等不太可能发生的情况下，也能实现整个网络的连续运行。这种预先编程的操作弹性和弹性确保 Shardeum 始终保持活力 ——无论网络面临什么困难。
虽然理解错误并不需要了解网络模式框架的每个方面，但了解基础知识会很有帮助。网络模式框架的核心是几个不同网络阶段的结合：建立、处理、安全、恢复、重启、恢复和中断。这些模式经过精心设计，可以解决各种网络情况和紧急情况。然而，我们在本文中关注的模式是恢复模式。
逆向工程恢复模式：Rosewell 重温
恢复模式是上述7种网络模式中的一种。当网络活动节点的数量低于预定的临界阈值（当前配置为 75% 或更低）时，启动恢复模式。该阈值可以根据网络需求进行调整。在此模式下，网络暂停应用程序事务处理和应用程序数据同步。该策略旨在通过无缝循环空闲节点作为节点轮换的一部分来促进网络扩展，从而使活动节点数量恢复到最佳水平，理想情况下高于 100%。
在恢复模式下，Shardeum 的网络架构允许逐步进行节点升级，每个周期的增长限制为 20%（每个周期大约为 60 秒）。这种受控的增长率对于维持网络稳定性和确保新节点的顺利集成至关重要。节点数量的快速增加，例如 50% 的峰值，有可能破坏网络的稳定性并使集成过程复杂化。
每个新添加的节点都需要网络资源来进行同步和集成。通过将每个周期的升级限制在 20%，网络可确保其基础设施能够充分支持新节点的添加，而不会造成压力。这种方法不仅可以保持网络稳定性，还可以最大限度地降低同步过程中数据不一致或错误的风险，从而保持循环链数据的完整性。
崩溃的根本原因：事件视界
值得注意的是，存在两个不同的错误。 Neon 库错误 —导致验证器随机崩溃，以及缺失存档器检测协议中的错误 — 不接受空验证器列表。虽然是缺少归档器检测协议错误导致当前版本的 Betanet 崩溃，但我想邀请您首先讨论 neon 库错误。
在 Sphinx 版本 1.9.1 中，我们集成了对库的更新，该更新使用 Neon binder 链接 Rust 和 TypeScript 函数，因为 Shardeum 主要是用 TypeScript 构建的。 Neon 以其创新的、实验性的方法而闻名，这种方法经常突破传统软件开发实践的界限。这种集成旨在提高这两种语言之间的互操作性，从而在我们的软件架构中实现更高效、更直接的通信。然而，这会导致一个错误，导致节点随机退出网络。
其次，在最近导致 Shardeum 测试网崩溃的事件中，根本原因被确定为源于上述两个不同子系统之间交互的严重异常：缺失的存档器检测机制和网络恢复模式协议。
这次短暂的崩溃是由这两种机制同时激活触发的，这是以前从未遇到或测试过的场景。丢失存档过程与网络恢复模式一起触发，并且由于丢失存档模式中的错误不接受活动节点的空列表而触发。这会导致网络崩溃。
恢复编年史：从系统性休克到恒星觉醒
那么究竟发生了什么以及何时发生？围绕网络崩溃的事件及其解决方案的时间表如下：
漏洞和初始升级：网络存在由 npm (neon) 库中的 1.9.1 linting 过程标记的漏洞。已实施一项改进来解决此问题。然而，这一改进无意中引发了一个异常，该异常在本地测试期间并未重现。
间歇性库异常导致验证器中断：neon 库遇到零星异常，导致周期性网络验证器中断。尽管网络设计允许通过重新填充这些验证器来实现弹性，但不幸的是，多个验证器之间同时发生故障会触发网络恢复模式。
触发网络恢复模式：一旦进入网络恢复模式，协议必须清理并重新创建活动节点列表。丢失的文件系统中的并发错误（不容纳空的验证器列表）是网络崩溃的主要原因。
网络解决和恢复：崩溃已修复，网络已使用存档器中存储的数据成功恢复。这是历史上第一次崩溃的第1层分片网络被成功恢复，网络上的所有数据都完好无损地保存下来。这在任何网络上都从未做过，更不用说具有动态分片的网络了。这一成果标志着网络恢复的“火箭着陆”成功。
已完成的修复：实施了初步修复以解决库问题，但为了不断提高网络稳定性，发布了 1.9.5 版本。此更新引入了一个重要的错误修复，该修复解决了 neon 绑定崩溃的另一个实例，无需进行网络范围的升级即可查明并修复特定漏洞。最初，使用 1.9.4 版本的用户可以根据对网络性能和稳定性偏好的评估灵活地保留当前版本或选择升级到 1.9.5。但最终决定，为了提高网络稳定性并解决与 neon 绑定相关的持续问题，验证器所需的最低版本应增加至 1.9.5。此更新旨在系统地排除在 1.9.4 版本上运行的验证器，该版本已被确定由于上述 neon 绑定复杂性而容易崩溃。这是确保霓虹灯错误已被完全删除并完全修复所必需的。
现在我们已经知道了时间线和重大事件是如何发生的，让我们来看看到底发生了什么，以便网络能够快速恢复。
迈向复苏
敏捷恢复
网络恢复由很多部分组成，但其中主要的部分之一是Shardeum恢复模式。如前所述，当网络活动节点的数量低于预定的临界阈值时，恢复模式就会启动，并允许以安全的方式快速、受控和有效的网络增长来恢复网络。需要强调的是，如果没有网络模式设计者和开发者的技术独创性，Shardeum 不可能如此轻松地从崩溃中恢复过来，也不会展示其创新能力。
此外，Shardeum 的技术团队做出了重大努力，立即采取了行动。第一步涉及彻底分析，以确定崩溃的根本原因，可追溯到网络丢失存档检测与其恢复模式系统之间的交互异常。了解问题的复杂性后，团队迅速实施了多方面的方法来解决直接影响和潜在的漏洞。
Shardeum 技术团队的反应不一
从技术上讲，反应不一：首先，研究小组隔离了受影响的成分，以防止组织进一步退化。与此同时，他们应用了补丁来修复丢失的文件系统中的错误，确保它可以处理空的验证器列表——这是触发网络故障的严重错误。为了将网络恢复到完全运行能力，存储在存档中的数据将被激活并用于重建崩溃前的网络状况，确保在此过程中不会丢失任何数据。
从逻辑上讲，该团队跨时区和学科进行协调，利用基于云的工具进行协作和实时监控。这种协调一致的工作不仅有助于修复的快速开发和实施，而且还确保所有团队成员在恢复过程和后续步骤上保持一致。
此次事件是对 Shardeum 事故管理协议的严格考验，凸显了敏捷和创新应对意外挑战的重要性。这强调了该团队致力于维护一个有弹性和安全的网络，准备克服出现的复杂技术障碍。
安全和太空着陆创新
综上所述，Shardeum分片网络的成功恢复标志着网络技术的重大转变，对行业具有深远影响的里程碑。虽然目前鲜为人知，但网络模式等创新最终将为 web3 制定新的行业标准。
我一直相信Shardeum的核心创新很有可能影响未来的技术发展，激发创新和新一代账本技术。作为第一次 Shardeum 网络恢复的第一手见证者，我知道这将成为重新评估行业标准的催化剂，有可能导致在网络设计和架构中采用更严格的协议和方法。
此次活动不仅展示了Shardeum团队的技术实力和创新，还标志着去中心化网络在灾难恢复规划方面变得更加强大、适应性更强并能够应对不可预见的挑战的时代的开始。最终，Shardeum 技术将预示着去中心化的新时代。