今日閱讀towards the temporal streaming of graph data on distributed ledgers.

概要

這篇文章解決一部分使用Ethereum區(qū)塊鏈技術(shù)處理temporal RDF 圖數(shù)據(jù)的工作。這個工作的motivation是在對于流數(shù)據(jù)的使用者來說，他們可能需要驗證數(shù)據(jù)是否被篡改。這個系統(tǒng)會將時間標注、可以驗證的信息存儲到區(qū)塊鏈中，與數(shù)據(jù)存儲時執(zhí)行的固定SPARQL查詢的結(jié)果一起存儲。模型實現(xiàn)了一個基于圖數(shù)據(jù)存儲的時序RDF。時間間隔被已經(jīng)命名的圖數(shù)據(jù)表示，與leger中的entry相對應，還存在一些未解決的問題和未來的方向。

介紹

本文介紹了使用分布式賬本區(qū)塊鏈進行的持續(xù)工作，以驗證從傳感器硬件收集的基于時間圖的數(shù)據(jù)。使用了Ethereum智能合約來實現(xiàn)基于named-graph的時序模型，用于RDF的數(shù)據(jù)流。之前的區(qū)塊鏈技術(shù)有些是解決多方之間的不信任問題。在GreenDATA項目中，它關(guān)注從國內(nèi)發(fā)電系統(tǒng)收集能源發(fā)電數(shù)據(jù)。 這些數(shù)據(jù)是來自于不同大學中的老師、同學和其他對這個項目感興趣的人。國內(nèi)生產(chǎn)商可能會利用區(qū)塊鏈上的加密貨幣交易直接向國內(nèi)消費者出售剩余能源。在這種情況下，當錢轉(zhuǎn)手時，當然需要代表交易雙方驗證數(shù)據(jù)。因此，我們尋求允許學生使用私有區(qū)塊鏈對此場景進行建模，以便為他們提供探索如何工作的方法。第二個應用場景是對于移動車輛傳感器數(shù)據(jù)的收集，傳感器的網(wǎng)絡連接和計算資源都是有限的。在實際情況下，以下方向也涉及驗證數(shù)據(jù)的需求：運輸環(huán)境敏感的材料（視頻或藥品），救災、長距離賽車，這幾種情況都可能因為不正確數(shù)據(jù)導致金錢或人體健康的問題。數(shù)據(jù)會在一些傳感器上以每秒鐘的速度進行生成，會被以RDF的流數(shù)據(jù)根式進行處理，后續(xù)可以進行數(shù)據(jù)分析，包括事件偵測。本文試圖使用Ethereum的輕量級客戶端在一個資源有限的設計空間數(shù)據(jù)的設備中使用。

有關(guān)于Temporal Graphs 和RDF 流數(shù)據(jù)

Resource Description Framework (RDF) 資源描述框架是一個可以靈活表示數(shù)據(jù)的模型，他是一個三元組（subject predicate object）主謂賓。每個位置可以被URL或者實際的文本數(shù)據(jù)所填充。RDF的主要目標之一是允許使用URL將數(shù)據(jù)整合和連接在一起，已經(jīng)被廣泛使用。查詢RDF的語言通常是SPARQL。在某種意義上，由RDF三元組代表的“事實”是沒有時間限制的。關(guān)于數(shù)據(jù)的時間和有效期是在RDF模型之外。近年來，人們越來越關(guān)注使用RDF來表示時間標注的數(shù)據(jù)流，允許使用時間戳或時間間隔和RDF對應。時間對于流數(shù)據(jù)十分重要。

在Ethereum 區(qū)塊鏈上使用Temporal Graph

以太坊區(qū)塊鏈不適合存儲大量數(shù)據(jù)，執(zhí)行速度不可能足夠快以支持高容量數(shù)據(jù)流。 然而，為了支持數(shù)據(jù)完整性，不必將數(shù)據(jù)都完整存放在區(qū)塊鏈上，我們所需要的只是存儲足夠的元數(shù)據(jù)，以允許任何擁有大量數(shù)據(jù)的人進行驗證它的內(nèi)容完好無損即可。因此，我們需要一個可重復散列數(shù)據(jù)的規(guī)范表示，以提供驗證 - 例如源的RDF序列化 - 以及可靠的符號形式數(shù)據(jù)流，用于標識要用于散列的完整數(shù)據(jù)塊。

用于序列化的符號取決于數(shù)據(jù)的時序模型。已經(jīng)有一些方法可以表達時序RDF 流數(shù)據(jù)模型。廣泛地說，它們在時間信息是否和每個三元組或與RDF圖相關(guān)聯(lián)而不同。一個圖可以對應一個時間區(qū)間（time interval）。另一種方法是時間信息是一個時間戳。因此，我們確保傳感器生成的數(shù)據(jù)流在源處分割為與時間間隔相對應的命名圖形，并且間隔的長度也在源處確定，并在數(shù)據(jù)本身內(nèi)指示。變化的時間區(qū)間比靜態(tài)的提供了更多的靈活性。

運行在私有Ethereum上的智能合約已經(jīng)被寫好來接受數(shù)據(jù)，每個客戶在調(diào)用時都提供合約對應的地址來觸發(fā)。每一次數(shù)據(jù)被發(fā)送，合約都會從數(shù)據(jù)源識別出圖數(shù)據(jù)，然后計算對應的驗證哈希，從每個圖中獲取start和end的時間。對于數(shù)據(jù)項：圖數(shù)據(jù)的URI，哈希，開始和結(jié)束時間，被存儲在新的智能合約的狀態(tài)中。其對應合約的地址唄存儲在一個主“master”合約中，原始數(shù)據(jù)被傳到傳統(tǒng)的RDF存儲中。
同時，執(zhí)行事件檢測的客戶端構(gòu)造檢測到的每個事件的RDF表示，并將其與相關(guān)時間圖的名稱和散列一起發(fā)送到單獨的智能合約。散列的重復為每個圖提供了一個單獨的有效性信息源。

為了支持在標準SPARQL查詢中的數(shù)據(jù)驗證，一個自定義的SPARQL斷點（在區(qū)塊鏈外）用SERVICE關(guān)鍵字被寫入，用來相應聯(lián)合SPARQL請求。
傳遞到此端點的任何triple模式將被指定為位于區(qū)塊鏈中已知為散列的時間圖中，并從整個數(shù)據(jù)集中查詢，并將每個相關(guān)圖進行散列，并與流式數(shù)據(jù)合同中存儲在區(qū)塊鏈中的條目進行比較，以及來自事件檢測的任何相關(guān)合同。自定義端點返回三元組，說明驗證是否成功，在SPARQL中至少允許基本級別的驗證。

【個人看法】
原文并非完整實現(xiàn)整個系統(tǒng)，但其核心思想還是可以參考。畢竟區(qū)塊鏈的存儲開銷很大，存儲哈希到區(qū)塊鏈上已經(jīng)是常見做法。問題的關(guān)鍵是如何利用這些哈希輔助off-chain來進行一系列的操作，這是問題的關(guān)鍵。文章中問題有很多，不必追求每個細節(jié)，只看其核心思想即可。