1. 首页
  2. 业界观点

机器数据在IOTA网络的存储和更新

原文作者:Stefan Künne

掩码认证消息传递机制(short MAM)允许在IOTA网络(Tangle)上发布传感器数据。这些数据存储在所谓的“消息Message”中,IOTA事务集能自动分布在IOTA网络的节点上,并以不可篡改的形式存储。

MAM专注于消息传递,这意味着最新的数据被发送到IOTA网络环境中以供进一步使用,比如即将推出的智能合约。由于这些数据已经发布在不可变的IOTA网络-Tangle中,所以它也可以作为长期文档。这将有助于在合作伙伴或客户对数据感兴趣的过程中引入透明度。例如通过对生产和供应链过程的跟踪,客户可以获得关于其产品的来源和生产环境的可靠信息。

因此,本文主要关注数据的长期存储和使用,并引入了新的概念来改进MAM功能,以便更好地为所描述的示例提供服务。虽然当前的MAM侧重于消息传递,但是可以使用其他特性来检索和处理数据。

MAM的使用体验

在前一篇文章中,我们介绍了一个传感器站监测堤坝(也包括堤坝、堤防等)的原型。这个传感器站点可以测量不同的示例下的环境条件,并使用隐秘验证消息(MAM)将它们发布到IOTA网络上。我们利用传感器站了解了IOTA MAM的使用情况。

除了因为快照和永久节点当前不可用的原因,导致事务和数据在iota网络上保持有限的可用时间之外,还需要注意两点:

#1: 链式列表无法提供随机访问

MAM通道的数据采集的直接结果是一组链式列表。如果客户端始终与通道保持同步并始终读取最新信息,则此结构可以很好地工作。如果客户机只需要对特定信息的零星访问,这种结构的访问效率就相当低了。当永久节点和长时间运行的传感器通道相结合时,会产生很长的列表。假如一个传感器站每10秒发布一次数据,一年就会产生52000多条信息。搜索特定日期的传感器读数需要遍历这些所有的消息,直到找到所需的消息。

#2: 错误数据处理

传感器站在运行过程中可能会多次产生错误数据。这些错误的范围包括硬件损坏(水温传感器失败并给出相当随机的结果)到人为错误(譬如在启动传感器站操作系统应用更改时,没有事先禁用传感器功能)。这些错误的传感器读数都会自动上传到IOTA网络中,错误的数据和正确的数据混杂在一起。

虽然在生产环境(非原型)下的传感器站和已建立的正规的操作程序中,这种错误概率很低,但一个现实的场景可能包括大量并行的传感器站,低概率但多样本依然很可能产生网络中的错误数据。

这些错误的记录与正确的记录混合在一起,降低了后者作为长期文档的价值,和将其作为进一步开发标准化系统的基础。

优化提案

MAM(及其后续的MAM2)专注于IOTA网络上发布的数据的加密和身份验证。在本文中,我们建议在MAM的基础上构建另一个层,对发布的数据进行结构化,以提高可用性。

该方法有两个主要目标,解决了前面描述的限制:

为消息中的记录建立索引,以允许快速访问

允许记录可以被纠正或声明无效,同时为数据完整性保留历史记录

其核心思想是像MAM那样将消息链接在一起,但使用更复杂的结构,将一些额外的消息附加到元数据上。

这种方法对MAM和MAM2都很适用,只是需要做一些适当的调整。

数据的索引

要查找包含特定记录的消息,需要遍历消息或附带的元数据。假设每个记录都有一个惟一的ID,新记录的ID值更大。一个简单的例子是时间戳,其形式为Unix epoch。一个可能的搜索要求就是返回两个时间戳之间的所有内容。

虽然索引的元数据可以存储在网络之外,但这可以通过引用其他消息来实现操作,这些消息也可以在网络中发布。本文介绍的方法示例中,是在通道上发布所有元数据,来保证数据的完整性。

图[1]显示了建议的索引结构的一个简化示例。黑色块表示入口点,通道上的第一个消息。黄色块从那里形成一个链表。块中的数字表示包含的最高记录id。

图[1] 索引结构的一个简化示例

图[1] 索引结构的一个简化示例

添加到这些数据消息中的是索引消息(绿色)。每个索引消息都包含指向多个数据消息的链接和最大ID。因此,索引消息允许确定索引的数据消息是包含所需的数据,还是可以被忽略?由于索引消息和数据消息一样不可变,所以一旦有了足够多的可用的新数据消息,新的索引消息就会被添加。在图[1]中,每个索引消息引用三个其他消息。这个小数字是为了便于理解而选择的,在实际实现中会大得多。

为了进一步加快访问速度,可以为索引再创建一层索引,形成层次结构。在此结构中进行搜索只需遵循以下步骤,直到找到搜索的ID。如果索引和数据列表在找到ID之前结束,则不可用。

具体步骤是(从第一个索引消息开始):

  • 上升到更高的索引层
  • 在相同的索引层上右转
  • 转到最近的一个索引消息

数据消息实际充当了整个索引结构的最底层。

数据的更新

该方案的第二个组件是创建一个更新机制来纠正错误数据。为了维护数据完整性,每个更新都必须是原子操作:即在一个更新发布之后,不能针对这个更新进行一次新的更新。对于文档,每个更新还包含一个正当理由,可以用一个字符串来记录,该字符串也可以包含对解释修改的文档的引用。

每个更新都有一个递增ID,表示从1开始的版本。版本0表示未更改的数据。每个单独的记录都可以在更新中独立更改,从而创建该记录的新版本。这包括声明记录无效的可能性。

搜索记录可以查找数据的最新版本,也可以指定要包含的最大更新版本。记录始终具有包含的最高版本的状态。

图[2]显示了一个例子,用单独的块表示单独的记录。更新版本1更改了记录2和3,更新版本2更改了记录2,更新版本3更改了记录4。如果需要版本2,则记录0和4到7将处于版本0的状态,而记录2位于版本2,记录3位于版本1。版本3的更改将被忽略。

图2 更新示例

图2 更新示例

在IOTA网络上,每次更新都是一条MAM消息。每个更新消息可以包含多个数据消息的更改,并且每个数据消息的内容可以受到多个更新消息的影响。这种N-to-M关系由称为“更新-指针-消息”的附加消息建模。这些“更新-指针-消息”帮助将数据消息(由索引访问)引导到对应的更新。

如图[3]所示,每个“更新-指针-消息”将一个更新连接到特定的数据消息,并将另一个潜在的“更新-指针-消息”链接到其他更新,从而形成一个链接列表。

由于单个数据消息通常只包含非常少量的数据,因此多个数据消息可以共享更新-指针-消息列表。

完整结构

图[4]显示了完整的结构,图[3]中的更新结构被镜像并添加到图[1]中所示的索引结构中。

图4. 完整结构图

图4. 完整结构图

举例

图[5]展示了索引65到80的搜索示例。从左到右搜索之后,所需数据和更新消息的选择的展示。

实施

为了评估实际的可行性,我们进行了一个原型实现。该实现基于MAM2-和cclient- APIs,可在 IOTA Entangled Monorepo代码库中找到。

之所以选择MAM2而不是MAM,是因为它是指定的继承版本。此外,它还允许发布具有多个解密密钥的单个消息,用于多个接收者。因此,即使在具有多个或多个不同授权接收方的场景中,也只需要发布一个数据流,来为他们提供文档服务。

要想实现提议的新结构,必须要对MAM2做一些更改(主要是重写message-ordinal,通道上消息的内部计数器),就可以实现索引和更新功能。

结论

本文以MAM和/或MAM2的功能为基础,以改进数据处理和流程。本文提出了一种理论方案,并通过一个原型实现进行了验证。无论如何,所提供的索引还是更新方法都可以作为有效处理IOTA网络中的复杂数据的第一步。

因此,所提出的方法是有可行的,应该进一步发展。对于许多用例(包括供应链文档流),快速访问长时间存储的数据是必要的。通过允许可多次追踪的纠正,不可避免的错误(技术上的和人为的)将可以得到有效处理。进一步的开发可以包括类似于面向对象原则的自定义数据结构。通过运行一个单一节点,来充当真相(真实数据)的来源,这个目标的实现可能会更近一步。

原文链接:https://medium.com/topocare-x-iota/efficient-use-of-iota-mam-for-storing-machine-and-sensor-data-357ee00302e2

本文原文非中文版本,由BruceX进行翻译,如若转载,请注明出处:https://www.brucex.info/201909/storage-and-update-of-machine-data-in-iota-network/