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 技术将预示著去中心化的新时代。