概述：我们对IOTA 2.0的现状和下一步工作进行了详细介绍。目前的努力主要集中在优化共识和通信层，使协议更有效，更简洁。接下来的步骤包括实施主动防御和可用性功能，如本地快照。

简介

IOTA 2.0的DevNet的发布标志着IOTA基金会历史上最重要的里程碑之一。这是第一次，我们不仅能够在一个真正的、完全去中心化和无协调员的网络中展示IOTA 2.0背后的理念，而且还能够研究不同组件之间的互动。

测量和评估这些组件的性能的能力使我们能够讨论和决定一系列的优化，以使协议更加稳健、高效和不那么复杂。

大部分的变化涉及数据流的小优化和代码的简化。但我们也对通信层进行了调整，并对共识层进行了一些关键性的改变。

对共识层的改进大大简化了协议，使我们能从Tangle中获取所有信息，并以乐观的方式处理传入的交易。第一个实施方案已经完成，我们同时正在进行深入的模拟和准备研究论文。目前还剩下一些更多的调整需要实施，我们正在继续沿着清晰的道路前进。

至于通信层，目前在IOTA 2.0 DevNet中实现了一种高效的调度算法。这与一个速率设定器模块一起工作，以确保公平性和短延迟。作为下一步，我们将实施一种惩罚攻击者的机制，这已经是一种规范。此外，我们目前正在努力提供一个改进的用户体验，以促进网络的可用性。

这篇更具技术性的博文深入探讨了IOTA 2.0改进的细节，描述了当前的状态，并描绘了未来道路的总体情况。

共识层

愿景

正如之前的一篇博文中所描述的那样，现在的节点不再询问其他节点的意见来解决冲突，而是只需要通过观察Tangle来获得他们需要的所有信息。由此产生的协议与IOTA的原始愿景非常相似，它使用了一个纯粹的中本聪式风格的共识，没有额外的投票开销，节点通过在Tangle中创建消息来表达他们的意见。

在FCOB+FPC的情况下，每笔交易都有一个隔离时间，以确定最初的意见，并在冲突无法及时解决的罕见情况下从一开始就打破稳定性。相反，对共识的更改允许节点在不应用隔离时间的情况下陈述其意见。只有当冲突在一段时间内未得到解决时，像FPCS这样的亚稳态破坏机制才会被激活来决定冲突。这种乐观的过程不仅加快了确认时间，还使协议更加简单和精简。

我们现在的情况

对共识的改进的实施正在快速进行。作为模块化的冲突选择功能和类似开关的纯线上投票（OTV–On Tangle Voting）的第一个实现已经完成，我们目前正处于测试、修复错误和编写文档阶段。接下来的步骤包括简化批准权重（AW）的标记和更新工具，即GUI钱包、库和它们的文档。

我们基于FPC的亚稳态破坏器的第一个版本已经被学术界彻底验证(FPC- bi，加权投票快速概率共识)。同样的结果和概念可以扩展到我们目前的优化方案中，该方案是对原始FPC的直接修改，并将很快在严谨的科学论文中提供。我们将继续进行验证，准备一篇科研论文，证明我们改进后的共识机制的实力。

除了描述OTV的机制外，我们将通过运行基于多元宇宙模拟器的广泛模拟研究来分析其性能，该模拟器目前正被扩展为我们共识的一般模拟框架。这包括研究确认时间和各种双花情况下的抗逆力，以及对不利环境的考虑。最后，我们将把OTV与集合上的FPC（FPCS–FPC on a Set）结合在一起，并详细探讨这些共生体的影响。

前面的路

在纯粹的OTV中，节点根据他们对较重的分支的感知来设定他们对冲突的初始意见，这使得协议的行为类似于比特币的最长链规则。这意味着共识本质上是概率性的，客户端（如节点、钱包或交易所）根据他们的安全阈值决定何时将交易视为确认（这在比特币中被称为6块规则）。因此，我们将引入几个固化等级（GoF–Grade of Finality），主要基于批准权重，定义越来越高的安全阈值。等级越高，安全性就越高。然而，在罕见的情况下（例如被日蚀攻击或部分离线），节点可能会在稍后的时间点接收到丢失的信息，这可能会触发对其本地感知的重组，就像比特币一样。值得庆幸的是，高GoF设置使得这些情况几乎不可能发生。尽管如此，这种重组程序需要在节点软件中实现，以重置依赖确认的组件。

一旦我们有了一个稳定的纯OTV版本，并且能进行重组，我们就可以把注意力转移到实现一个与纯OTV并行的破坏性机制上，如果冲突长时间得不到解决，就会启动。具体来说，我们将首先实现快速概率共识集（FPCS）作为一个亚稳态破坏机制，利用以前的积极研究成果。模块化的冲突选择功能允许我们轻松地交换设置初始意见的方式；因此，即使实验其他达成共识的方法，也只涉及代码的微小调整。

作为对Sybil的保护，投票是由cMana加权的。然而，绝对的cMana值可能不会产生足够的信息。相反，我们使用“活跃”的cMana来表达一个节点与所有最近活跃节点之间的权重。因此，活跃的cMana是一个重要的组成部分，需要严格的研究以了解它的边界和局限性。

通信层

愿景

在传统的基于工作证明的分布式账本技术（DLT）中，在账本上添加新消息的权利是由采矿过程保证的，其中一个节点在完成一些计算昂贵的任务后被选出。作为执行这种任务的激励措施，获胜的节点会获得交易费和区块奖励。在这样的DLT中，费用作为一个过滤器来选择哪些信息应该被添加到分类帐中：因此，在网络拥挤的时期，费用的数额会变得很大。

而IOTA旨在成为新兴数字经济的骨干，特别是机器经济。因此，一个需要付费和高配置设备的协议是不可行的，也是不可持续的。然而，取消收费需要采用一个明确的机制来处理大流量的突发事件。

在IOTA基金会中，我们采取了一种受 “标准互联网 “启发的方法来定义IOTA拥堵控制算法（ICCA）。与基于工作证明的DLT不同，我们的方法允许优化利用网络资源，只受网络在带宽和交易处理能力方面的物理限制。此外，ICCA可以被低端节点有效利用，因为它不需要任何昂贵的任务或费用。我们的解决方案还提供了其他几个基本特征。

• 一致性：所有节点最终都会将相同的信息写入他们的本地账本。
• 公平性：网络访问被按比例授予 “稀缺资源”，即访问Mana（见下文）。
• 效率：如果需求存在，网络的全部潜力将被使用。

我们现在所处的位置

本小节描述了一个节点在创建新消息和收到邻居的消息时必须执行的动作，这些动作目前已在IOTA 2.0 DevNet中实现。

消息的生成

保有一定数量的access Mana可以为节点提供了写入的权利。从用户的角度来看，access Mana转化为节点的某种吞吐量。有趣的是，这个吞吐量与当前的流量条件相适应：节点逐步增加他们的消息生成率（吞吐量），直到检测到拥堵；一旦发生这种情况，吞吐量就会减少。节点通过查看其发件箱缓冲区中自己的搁置的消息数量来检测拥堵。

消息接收

在新收到的固化消息（见下一段）通过某些验证过滤器（如签名检查和语法验证）后，它被添加到本地账本。之后，消息被添加到由调度器管理的发件箱缓冲区中，以决定哪条消息必须被添加到提示集中并向邻居八卦。调度器使用一个轻量级的轮询算法来有效地同时处理大量的消息。最近，我们将调度器移到消息预订之后，以优化重新同步的程序。

固化

固化是请求消息的过程，其过去的锥体还不为一个节点所知。同样，在处理交易时，交易的消耗输出（输入）需要被一个节点知道，以便正确验证交易。在过去，协议要求一个交易的所有输入都在其包含消息的过去锥体中。验证某样东西是否在过去的锥体中可能需要在Tangle中遍历，这是一个昂贵的操作，在DevNet中被证明是不可行的。因此，一个不同的固化方法的第一版已经被实施，它不仅取消了过去锥体的要求，而且简化了数据流，并允许更多的并行化。

前方的道路

抵御攻击

在DLT中，恶意节点对影响网络的运作有很大兴趣。出于这个原因，每个解决方案都必须对所有潜在的威胁进行验证。正如我们已经实验证明的那样，ICCA对攻击有弹性：当攻击者试图获得比允许的吞吐量更快的速度时，他们的消息会被诚实的节点延迟，因为他们不会根据当前的访问Mana向量进行调度。因此，攻击者发出的消息将在诚实节点的发件箱中停留很长时间。虽然这并不影响诚实信息的性能，但出于两个原因，识别这种恶意行为很重要。

• (i) 攻击者可以夸大其邻居的发件箱中的消息数量，使其资源耗尽；
• (ii) 诚实的节点可能在恶意的消息上面有附加，导致各节点的账本不一致。

为了克服这些问题，我们将通过丢弃恶意节点的消息而将其列入黑名单。当他们在发件箱中的消息数量超过一个给定的阈值时，恶意流量就会被发现。这个阈值的设置方式（这对于快速检测恶意行为同时不把诚实的节点列入黑名单至关重要）已经在最近的一篇论文中描述过，并将很快在我们的DevNet中实现。

对信息中的时间戳的有效性进行准确的估计也很重要。例如，旧的消息不应该被添加到调度器中，因为它们很可能已经被邻居收到。另外，附加到旧消息是不可取的，因为这将增加新消息的确认时间（我们假设旧消息已经被验证）。此外，需要准确的时间戳来保证快速重新同步并阻止攻击者损害协议的性能。我们目前正在研究一个指标，称为包容分数(inclusion score)，它评估一个消息被认为是 “最近的 “并准备被调度的可能性：这个指标考虑到消息的时间戳和来自发布节点的消息的调度器占用情况。

用户体验

节点的吞吐量是由速率设定器算法调节的。这意味着节点在拥堵的情况下不能连续产生消息，因为它们会受到ICCA的惩罚。我们目前正在努力提供作为访问Mana向量的函数计算的节点吞吐量的估计。有了合理的猜测，就有可能回答以下问题：假设一个用户（钱包或节点）有一个新的消息要发布：应该选择什么样的节点，以便这个消息被快速添加到IOTA账本中？这个研究方向试图将新消息分配给在某一时间点不太忙的节点。我们将这一挑战制定为一个优化问题，并正在测试一些基于消息创建者占用率或每个节点延迟的拟议政策。

另一方面，请记住，一个消息传递到所有节点所需的时间（几乎）与发布节点的访问Mana无关。这意味着访问Mana矢量只调节新消息的创建速度，但它不影响网络的可用性。平均而言，延迟预计会相当低：我们估计，在正常情况下，消息在调度器中只停留几分之一秒；在交通繁忙的情况下，这种延迟会略有增加。在目前的建议中，我们通过设置节点能够发布消息所需的最低法力阈值来处理大流量问题：简单地说，如果这样的阈值较低，更多的节点能够发布消息，可能会造成拥堵。我们目前正在努力根据当前的交通情况，适时地调整这个阈值。

快照

Tangle可能会变得非常大，而且不是每个用户都能跟踪它的整个历史，并追溯到起源阶段。因此，本地快照应该允许节点安全地修剪他们的数据库；也就是说，足够老的数据可以被删除而不损害网络的安全。快照依赖于协议的许多部分，并对分区容忍度有直接影响，因为分区不能在本地快照之外被合并。它也与无信任同步密切相关，因为没有延伸到创世的整个历史的节点，如果没有额外的机制，如Merkle树或多项式承诺，就不能轻易验证分类账的状态。这些课题目前正在研究中。

总结

IOTA 2.0 DevNet为我们的团队提供了宝贵的见解，使我们能够通过一个无领导、无手续费和无许可的分布式账本协议来完全去中心化IOTA网络。

我们在GoShimmer的实施中取得了很大的进展，增加了一些最近的改进（尤其是共识），并开始重构代码库。虽然我们很高兴看到这种朝向稳定的网络实施的迭代进展，但仍有几个关键的研究问题需要我们的团队去评估，去验证，然后在GoShimmer中实施。我们相信，这些变化将使协议整体上更加安全，实施起来更加简单，使用起来更加快捷。

一旦我们实现了所有需要的改变，我们将升级IOTA 2.0 DevNet，并邀请IOTA社区与我们的团队和研究伙伴一起参与并实验改进后的协议。基于该网络的结果和反馈，我们的团队将致力于最终确定IOTA 2.0的规范，并开始开发Go和Rust中的稳定实现。这将导致一个激励性的测试网络的启动，并最终实现IOTA主网的 “协调”。

原文链接：https://blog.iota.org/iota-2-0-details-on-current-status-and-outlook/