原文作者：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] 索引结构的一个简化示例

添加到这些数据消息中的是索引消息(绿色)。每个索引消息都包含指向多个数据消息的链接和最大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 更新示例

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

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

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

完整结构

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

图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