区块链与图数据

今日阅读towards the temporal streaming of graph data on distributed ledgers.

概要

这篇文章解决一部分使用Ethereum区块链技术处理temporal RDF 图数据的工作。这个工作的motivation是在对于流数据的使用者来说，他们可能需要验证数据是否被篡改。这个系统会将时间标注、可以验证的信息存储到区块链中，与数据存储时执行的固定SPARQL查询的结果一起存储。模型实现了一个基于图数据存储的时序RDF。时间间隔被已经命名的图数据表示，与leger中的entry相对应，还存在一些未解决的问题和未来的方向。

介绍

本文介绍了使用分布式账本区块链进行的持续工作，以验证从传感器硬件收集的基于时间图的数据。使用了Ethereum智能合约来实现基于named-graph的时序模型，用于RDF的数据流。之前的区块链技术有些是解决多方之间的不信任问题。在GreenDATA项目中，它关注从国内发电系统收集能源发电数据。 这些数据是来自于不同大学中的老师、同学和其他对这个项目感兴趣的人。国内生产商可能会利用区块链上的加密货币交易直接向国内消费者出售剩余能源。在这种情况下，当钱转手时，当然需要代表交易双方验证数据。因此，我们寻求允许学生使用私有区块链对此场景进行建模，以便为他们提供探索如何工作的方法。第二个应用场景是对于移动车辆传感器数据的收集，传感器的网络连接和计算资源都是有限的。在实际情况下，以下方向也涉及验证数据的需求：运输环境敏感的材料（视频或药品），救灾、长距离赛车，这几种情况都可能因为不正确数据导致金钱或人体健康的问题。数据会在一些传感器上以每秒钟的速度进行生成，会被以RDF的流数据根式进行处理，后续可以进行数据分析，包括事件侦测。本文试图使用Ethereum的轻量级客户端在一个资源有限的设计空间数据的设备中使用。

有关于Temporal Graphs 和RDF 流数据

Resource Description Framework (RDF) 资源描述框架是一个可以灵活表示数据的模型，他是一个三元组（subject predicate object）主谓宾。每个位置可以被URL或者实际的文本数据所填充。RDF的主要目标之一是允许使用URL将数据整合和连接在一起，已经被广泛使用。查询RDF的语言通常是SPARQL。在某种意义上，由RDF三元组代表的“事实”是没有时间限制的。关于数据的时间和有效期是在RDF模型之外。近年来，人们越来越关注使用RDF来表示时间标注的数据流，允许使用时间戳或时间间隔和RDF对应。时间对于流数据十分重要。

在Ethereum 区块链上使用Temporal Graph

以太坊区块链不适合存储大量数据，执行速度不可能足够快以支持高容量数据流。 然而，为了支持数据完整性，不必将数据都完整存放在区块链上，我们所需要的只是存储足够的元数据，以允许任何拥有大量数据的人进行验证它的内容完好无损即可。因此，我们需要一个可重复散列数据的规范表示，以提供验证 - 例如源的RDF序列化 - 以及可靠的符号形式数据流，用于标识要用于散列的完整数据块。

用于序列化的符号取决于数据的时序模型。已经有一些方法可以表达时序RDF 流数据模型。广泛地说，它们在时间信息是否和每个三元组或与RDF图相关联而不同。一个图可以对应一个时间区间（time interval）。另一种方法是时间信息是一个时间戳。因此，我们确保传感器生成的数据流在源处分割为与时间间隔相对应的命名图形，并且间隔的长度也在源处确定，并在数据本身内指示。变化的时间区间比静态的提供了更多的灵活性。

运行在私有Ethereum上的智能合约已经被写好来接受数据，每个客户在调用时都提供合约对应的地址来触发。每一次数据被发送，合约都会从数据源识别出图数据，然后计算对应的验证哈希，从每个图中获取start和end的时间。对于数据项：图数据的URI，哈希，开始和结束时间，被存储在新的智能合约的状态中。其对应合约的地址呗存储在一个主“master”合约中，原始数据被传到传统的RDF存储中。
同时，执行事件检测的客户端构造检测到的每个事件的RDF表示，并将其与相关时间图的名称和散列一起发送到单独的智能合约。散列的重复为每个图提供了一个单独的有效性信息源。

为了支持在标准SPARQL查询中的数据验证，一个自定义的SPARQL断点（在区块链外）用SERVICE关键字被写入，用来相应联合SPARQL请求。
传递到此端点的任何triple模式将被指定为位于区块链中已知为散列的时间图中，并从整个数据集中查询，并将每个相关图进行散列，并与流式数据合同中存储在区块链中的条目进行比较，以及来自事件检测的任何相关合同。自定义端点返回三元组，说明验证是否成功，在SPARQL中至少允许基本级别的验证。

【个人看法】
原文并非完整实现整个系统，但其核心思想还是可以参考。毕竟区块链的存储开销很大，存储哈希到区块链上已经是常见做法。问题的关键是如何利用这些哈希辅助off-chain来进行一系列的操作，这是问题的关键。文章中问题有很多，不必追求每个细节，只看其核心思想即可。