GraphChain：基于区块链的分布式数据库，具有明确语义和链接RDF图的特性

11710GraphChain - 具有明确语义和链接RDF图的分布式数据库 �0米雷克∙索佩克MakoLab S.A.Łódź，波兰索佩克@makolab . com0普热梅斯瓦夫∙格拉茨基研发团队，DCLublin MakoLabS.A.，波兰卢布林普热梅斯瓦夫∙格拉茨基@makolab . com0维托尔德∙科索夫斯基研发团队，MakoLab S.A.Łódź，波兰维托尔德∙科索夫斯基@makolab . com0多米尼克∙库津斯基研发团队，MakoLab S.A.Łódź，波兰多米尼克∙库津斯基@makolab . com0拉法尔∙特罗伊查克研发团队，DCLublin MakoLabS.A.，波兰卢布林拉法尔∙特罗伊查克@makolab . com0罗伯特∙特里普兹研发团队，DC LublinMakoLabS.A.，波兰卢布林哲学学院罗伯特∙特里普兹@makolab . com0摘要0在本文中，我们提出了一种新的创造区块链兼容的分布式数据库的想法，该数据库以明确的语义公开其数据，易于访问，并直接将区块链安全机制应用于RDF图数据模型，而无需额外的打包或特定的序列化。基本上，所得到的数据库形成了命名的RDF图的链接链，并被赋予一个名称：GraphChain。然后，可以使用任何标准机制（如三元组存储或通过HTTP协议访问的链接数据对象）将这些图发布到网络上，以使其在网络上可用。还可以使用SPARQL或可用的RDF图形框架（如rdflib、Apache Jena、RDF4J、OWL API、RDFHDT、dotnetRDF等）轻松查询它们。GraphChain概念附带了一个符合OWL的本体，该本体定义了GraphChain的所有结构性、不变的元素，并定义了它们的基本语义。本文还描述了使用Java、.NET/C#和JavaScript/Node.js框架创建的一些简单的原型GraphChain实现及其示例。0CCS概念0• 信息系统 → 资源描述框架（RDF）；Web本体语言（OWL）；•计算机系统组织 → 分布式架构；0关键词0分布式数据库；语义区块链；GraphChain；链接数据0ACM参考格式：Mirek Sopek，Przemysław Grądzki，WitoldKosowski，Dominik Kuziński，Rafał Trójczak和RobertTrypuz。2018年。GraphChain -具有明确语义和链接RDF图的分布式数据库。在《会议论文集》中0� 智能增长运营计划，项目编号01.01.01-00-0982/16，由国家研究和发展中心资助0本文发表在知识共享署名4.0国际（CC BY4.0）许可下。作者保留在其个人和公司网站上传播作品的权利，并附上适当的归属。WWW'18 Compaion，2018年4月23日至27日，法国里昂。©2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可发布。ACM ISBN978-1-4503-5640-4/18/04.. https://doi . org/10 . 1145/3184558 . 319155402018年Web会议附录（WWW'18 Compaion）。ACM，纽约，美国，8页。https://doi .org/10 . 1145/3184558 . 319155401 引言0毫无疑问，区块链技术的崛起改变了现代分布式数据库的设计和实现方式。与传统的分布式数据库模型相比，区块链提供了几个重要的优势。最重要的是，区块链上存储的数据具有密码学上的不可变性和持久性，并且数据库管理完全去中心化[25]。然而，几乎所有现有的区块链实现都使用简化的数据结构，然后在其上实现密码算法。实际上，希望在区块链上存储结构化数据的开发人员需要将其数据打包或嵌入到区块中。根据具体的实现，区块可以是二进制的，也可以使用序列化的字符串数据。在其他一些区块链实现中，块数据结构相当复杂，但仍无法高效地用于结构化数据存储[1]。例如，如果开发人员需要在以太坊区块链上存储表格、基于树的或有向图的数据结构，通常会将该结构序列化为JSON对象并嵌入到Solidity脚本中。虽然这是可能的，但这种策略使得嵌入式数据难以查询：首先需要从块中提取对象，然后将其复制到适合其类型的存储中。然后才能执行所需的查询。在给定域中执行这样的操作可能需要大规模的提取操作，这将非常耗时且低效。更重要的是，在许多实际应用中，直接使用更高级的数据结构非常重要。例如，当区块链技术用于数字身份应用时，我们需要一种有效的机制来在区块链上呈现可识别对象引用数据[2]。在另一个应用中，区块链可以用于非否认性存储财务报告，这是可取的01 https://ethereum . stackexchange .com/questions/268/ethereum-block-architecture 2 Mirek Sopek，“UsingBlockchain for Digital Identifiers: Improving Data Security and Persistence for DigitalObject Identifier (DOI) and Legal Entity Identifier (LEI)”. The E-Finance Lab and DZBANK 2016 Fall Conference. Goethe University Frankfurt. September 1st, 2016.0会议：2018年4月23日至27日，法国里昂举办的第三届链接数据和分布式账本WWW 2018A single node consists of several parts: a web interface for communi-cation with clients (via the HTTP protocol), a web socket endpointfor communication with others nodes, a cryptography module forhandling of digest calculation, a triple store repository managerfor storing blocks as sets of triples and obtaining blocks from therepository, and services which bind all these parts together.In figure 1 a diagram presenting nodes interaction is depicted.Clients can connect to a node via HTTP and to a triple store viaSPARQL over HTTP. The interaction with the node itself enables aclient to create new blocks (a process of block creation is explainedbelow), add new peers, and retrieve block meta-information. Inter-action with the triple store enables reading data from it with theusage of the SPARQL query language. Interaction among nodesis implemented by means of the web sockets protocol. Nodes caninteract with their triple stores by various ways. These ways canbe determined for example on the basis of required performance.For now we use SPARQL over HTTP.The block creation process begins with an HTTP request fromthe client. The HTTP request contains a serialised RDF graph (seefigure 2). For now, we assume that this graph is serialised in theTurtle format, but it should be fairly easy to extend the application11720以将报告直接存储在区块链上。然而，技术的限制迫使这些流程的早期采用者只在区块链上存储报告的元数据，将报告本身留在受保护基础设施的范围之外[3]。在本文作者发起的项目中，我们正在为法律实体识别码（LEI）系统构建基于区块链的基础设施。最初，我们使用私有以太坊区块链构建了两个概念验证。虽然我们证明了这种方法的可行性，但我们也发现了与当前系统（如全球LEI系统）使用的大量结构化数据的区块链使用相关的重要缺点：第一个与无法高效查询“区块链化”集合有关，而第二个与复杂的寻址方案有关，这使得引用数据的检索变得困难和低效。这些发现引导我们提出了一个全新的解决方案，其中基本的底层数据模型是链接的命名RDF图的集合。然后，将区块链机制（如数据哈希、签名、图的链接、分布式数据复制（类似于标准区块链上的块链接）和达成共识）“置于”存储的图上，形成多个“站点”的分布式数据库，这些站点形成了链接的RDF命名图的链。这种方法的基本好处是，在每个站点上，用户可以使用当今完全发展和广泛使用的方法与链接的命名图一起工作：使用SPARQL进行查询，使用链接数据机制访问图的节点，使用Jena等框架进行任意操作，使用本体进行推理等等。我们将此解决方案命名为GraphChain。对于当前的用例（全球LEI系统的建议基础设施），所提出的解决方案将形成一个私有的“许可”系统，其中Proof-of-Authority是共识机制，允许在整个LEI系统参考数据集上进行无限制的查询。然而，由于本文的重点仅在于系统的底层数据模型，我们故意将共识机制的重要考虑因素留给Graphchain的未来出版物。02 GRAPHCHAIN定义0让我们从介绍与RDF图相关的几个定义开始。RDF三元组6包含三个组件：主题，它是RDF URI引用或空白节点；谓词，它是RDF URI引用；对象，它是RDFURI引用、文字或空白节点。RDF图是无序的RDF三元组集合，命名RDF图是分配了URI形式的名称的RDF图[5]。GraphChain的主要思想是在抽象的RDF图数据类型之上使用区块链机制。根据抽象数据类型（ADT）[6]的一般定义，我们通过计算机系统中的行为、可能的值集合和允许对这些值进行的操作来定义抽象RDF图数据类型。这种方法使我们能够在用于表示和公开图形的任何具体数据结构（如RDF/XML、Turtle或JSON-LD）上创建符合区块链的系统。一般来说，GraphChain不假设RDF图的任何特定序列化（如RDF/XML、Turtle或JSON-LD）或存储机制（三元组存储、文件、内存）或公开图形的机制（HTTP、文件读取等）。因此，GraphChain的定义如下：（1）由GraphChain本体指定的命名RDF图的链接链；（2）计算命名RDF图的摘要的一组通用机制；（3）负责在分布式节点之间分发命名RDF图的一组网03欧洲金融透明门户，SMART 2016，欧洲委员会，DG FISMA，Tamás Szabó 4 MirekSopek，?How Can Blockchain amplify Digital Identifiers? Improving DataPersistence, Openness, and Trust in the modern world.? DataAmplified 2016 ? XBRLand the future of Business Reporting, Singapore, Nov. 8-10, 2016. https:// www .dataamplified . org/sessions/blockchain-smart-contracts-and-efficiency/. 5 See forexample: https://lei . info. 6 https://www . w3 .org/TR/rdf11-concepts/#section-triples0定义2.2（GraphChain）。从称为创世纪单元的第一个图形开始的命名RDF图的链接链称为GraphChain。GraphChain作为一致的命名图形历史记录，所有节点最终都会同意。0定义2.1（命名RDF图的链接链）。命名RDF图的链接链是一组按功能关系排序的加密保护的命名RDF图（链）。除了链中的第一个图形外，该关系是非对称且非自反的。03 GRAPHCHAIN架构07Unit是区块链块的对应物。在第5节中，我们将准确地定义它在我们的框架中的理解。从此以后，我们将同时使用“unit”和“block”这两个术语作为同义词。与[25，定义7.20]进行比较。0跟踪：2018年4月23日至27日，法国里昂举行的第三届链接数据和分布式分类帐WWW 2018研讨会81311730图1：节点交互0图2：块创建01 POST /mammoth/block/create?graphIri=http://lei.info/6SHGI4ZSSLCXXQSBB39502 Host: localhost:888103 User − Agent: Mozilla/5.0（X11; Ubuntu; Linux x86_64; rv:58.0）Gecko/20100101 Firefox/58.004 Content − Type: text/turtle;charset=UTF − 805 Content − Length: 3626707 @base .09 @prefix rdf: .011 @prefix xsd: .012 @prefix owl: .014  0� → "2012 − 06 −015  ;016  ,017 ...列表1：带有序列化RDF图形的示例HTTP请求片段。由于论文的空间限制，大部分图形被省略。0应用程序接收到图形后，将对其进行反序列化，并使用我们将在第4.3节中讨论的方法之一计算其哈希值。然后计算以下元素的串联的字符串的哈希值：新块索引、先前块IRI、先前哈希、当前时间戳、接收到的图形IRI和上述图形哈希。哈希被视为块的哈希。计算出新块的哈希后，将创建一个新的块对象。它由对应的区块链头部和内容组成（参见第5节）。然后，将块序列化为两组三元组：头部和内容各一组。第一组0三元组的一部分存储在图形分类帐（即存储库中的命名图形）中，第二个存储在单独的命名图形中。最后，有关更改的信息被广播到其他节点。0图3：块创建04 GRAPHCHAIN实施挑战0本文中所定义和展示的GraphChain实现在提供与现有区块链实现的完全功能、生产级替代品之前，需要解决一些挑战。这些挑战包括：1）对RDF图的编程访问性能；2）用于向其他节点广播命名图形的RDF图序列化的性能和质量；3）计算RDF摘要。0跟踪：2018年4月23日至27日，法国里昂举行的第三届链接数据和分布式分类帐WWW 2018研讨会D(S) =Nh(serialisation(ti)){ _b hasLabel L.}117404.1 程序访问RDF图形的性能0虽然客户端访问形成GraphChain的图形可以使用现有的访问方法（在大多数情况下使用SPARQL）有效地实现，但这种方法对于分布式分类师应用程序所需的操作可能效率低下。高效的序列化机制（对于广播机制很重要）和快速计算摘要（这两个问题在下面进行了解决）作为第一个先决条件，需要对图形的?原子?元素（即三元组）进行极快的访问。虽然我们在本文中尚未对不同访问方法进行详细分析和比较9，但我们假设在生产级别的实现中，将使用基于内存的RDF图形表示，允许直接寻址各个三元组，而无需SPARQL查询引擎的开销。对Graphchain实现的这一方面的详细分析将是我们近期研究的主题。04.2 RDF图形序列化的性能0用于Graphchain的高效广播机制需要对RDF图形进行高效序列化，将其广播到其他节点，然后将其反序列化以形成所有网络节点上的内部表示形式。我们完全相信，实现高性能序列化的最佳方法是HDT序列化方法10。然而，在本文中介绍的当前初始实现中，我们使用了JSON-LD和Turtle序列化。在项目的后续步骤中，它将被HDT方法取代。04.3 计算RDF摘要0计算RDF摘要对于在RDF图形之上实现分布式分类师技术至关重要。RDF数据模型与标准区块链实现使用的块数据模型截然不同，所需的是对RDF摘要进行加密安全和可重复计算。在[9]中，列举了计算RDF摘要的重要问题：0（1）空白节点的标识符是与实现相关的，即在不同实现、三元组存储或其他实例化方法之间传输相同图形时，它们可能会发生变化。（2）每个RDF图形等效于一个无序的三元组集合；因此，相同的图形，即使在相同的语法中，可以以许多不同的方式进行序列化。（3）RDF图形序列化可以以不同的编码方式进行编码；哈希函数对编码敏感。0为了找到一种完整且正确的RDF图形哈希算法，已经进行了许多尝试。这些尝试的历史在[9，第2节]中有描述，并且最近在[11，第7节]中提到了以下工作：[1，4，5，8-10，12，13，19，23]。09关于三元组存储本身的效率有大量的文献。10参见：http://www . rdfhdt . org/。0对于这项工作，我们考虑了三种适用于计算图形摘要的算法：（1）?规范化?——将摘要计算为规范图形序列化的哈希值（2）?DotHash?——将摘要计算为对各个三元组的哈希值进行结合操作的结果（3）?交织的DotHash?——将摘要计算为对各个三元组和由空白节点链接的三元组的哈希值进行结合操作的结果。这些算法在提交给密码哈希函数的数据块的定义上有所不同。在所有算法中，我们使用SHA-256作为哈希函数。04.3.1规范化。这种方法代表了计算RDF图形摘要的最直接的方法。它基于在2017年10月W3C社区组的"JSON for LinkingData"草案报告中提出的规范化RDF序列化。规范化算法生成一个RDF数据集（命名的RDF图形集合）的表示，其中具有明确定义的顺序，并且空白节点由规范化标识符表示。规范化过程的设计方式使其应该为等效的RDF图形返回完全相同的文本表示。在本文中描述的示例实现中，我们使用JSON-LD进行规范化图形。04.3.2DotHash。RDF图形摘要计算的方法，本文称之为?DotHash?，最早在[18]中提出。该方法将图形的摘要定义为对图形的所有三元组的哈希值进行结合操作的结果：0结合操作是关联和可交换的，并且允许实现?增量加密?，即通过结合原始图的摘要和添加的三元组的摘要来计算由新三元组添加创建的图的摘要。根据该方法的作者的分析，最佳（在速度和安全性之间提供良好折衷的）方法基于?AdHash?算法[3]，并将结合操作定义为具有适当大的除数的模数操作。计算的增量性对于GraphChain非常有吸引力，因为它允许在链中的现有图中添加新三元组时非常低的计算开销。此外，该方法甚至可以在普通硬件上实现高效的并行化。然而，当图形包含空白节点时，该方法需要一种非常特定且非通用的方法。作者提出了一种在源端使用类似以下语句对空白节点进行标记的方法：0然后在目标端使用这些标签对空白节点进行重命名，以使其与源端的空白节点相同。当然，然后，在两端计算摘要将导致相同的摘要。虽然这种方法是实用的，但我们认为它不够通用，因此提出了修改后的DotHash方法。011参见https://json-ld.github.io/normalization/spec/0Track: 第三届链接数据和分布式分类师WWW 2018，2018年4月23日至27日，法国里昂1 function Hash(triple)2subject = subject of triple3predicate = predicate of triple4object = object of triple56if subject is BNode then7serialisation(subject) = "Magic_S"8else9serialisation(subject) = NTriples(subject)1011if object is BNode then12serialisation(object) = "Magic_O"13else14serialisation(object) = NTriples(object)1516serialisation(predicate) = NTriples(predicate)17concatenation = Concatenate(serialisation(subject), serialisation(predicate), serialisation(object))18return SHA−256(concatenation)1920 for triple in graph do21basic_triple_hash = Hash(triple)22subject1 = subject of triple23predicate1 = predicate of triple24object1 = object of triple2526if subject1 is BNode then27for all triples with subject1 in object position28compute Hash(triple)29add to total_hash3031if object1 is BNode then32for all triples with object1 in subject position33compute Hash(triple)34add to total_hashListing 2: Interwoven DotHash1 @prefix owl: .2 @prefix rdf: .3 @prefix xml: .4 @prefix xsd: .5 @prefix rdfs: .6 @prefix gc: .78 gc:b0 a gc:GenesisBlock ;9gc:hasDataGraphIRI "http://www.ontologies.makolab.com/bc"^^xsd:anyURI ;10gc:hasDataHash "7dc25665a24a48dca4c89e9ba0fe053009d1dc85eaf1fd5c8f5126aa13e3c217" ;11gc:hasHash "27f9ac0be5bd0fb1a84e74247cb6e5cbe9d49d1692e37a481d4710617cf871c6" ;12gc:hasIndex "0"^^xsd:decimal ;13gc:hasPreviousBlock gc:b0 ;14gc:hasPreviousHash "0" ;15gc:hasTimeStamp "1502269780"^^xsd:decimal .1617 gc:b1 a gc:Block ;12http://ontologies.makolab.com/bcTrack: 3rd Workshop on Linked Data & Distributed Ledgers WWW 2018, April 23-27, 2018, Lyon, France11750对于这两个图形，计算出相同的摘要。虽然这种方法是实用的，但我们认为它不够通用，因此提出了修改后的DotHash方法。04.3.3交织的DotHash。?交织的DotHash?方法的主要特点是能够在不规范化整个图形或使用附加带标签的三元组的情况下计算图形摘要。我们提出的方法在计算摘要时忽略了空白节点的实际格式，同时确保了空白节点的基本效果：将多个三元组编织在一起。与之前一样，我们假设整个图形的摘要是通过结合操作来计算的，该操作是关联的、可交换的，并支持对图形的摘要进行增量计算。同样，在最优的实现中，结合操作可以实现为三元组的哈希值的模数（具有足够大的除数）。三元组的哈希值可以通过对整个序列化的三元组进行计算，或者通过对三元组的?原子?节点（即主体、谓词和宾语）的哈希值进行组合来计算。后一种方法原则上允许使用替代的快速哈希计算来计算主体和谓词节点，因为它们代表了来自有限值空间的特定字符串集合（对于URI来说是特征的）。由于空白节点是匿名的，它们的实际形式和名称并不重要。重要的是将三元组编织到RDF文件中的特定结构中（列表、序列等）。进一步探索这些特性，我们提出了以下用于三元组计算的算法：0（1）如果三元组不包含空白节点，则将其计算为其N3序列化格式的哈希值。（2）如果三元组的主语是一个空白节点，则将其哈希值计算为N3序列化的谓词和宾语的哈希值以及所有那些三元组中非空白节点的哈希值的总和，其中空白节点出现在宾语节点中。（3）如果三元组的宾语是一个空白节点，则将其哈希值计算为N3序列化的主语和谓词的哈希值以及所有那些三元组中非空白节点的哈希值的总和，其中空白节点出现在主语节点中。（4）如果三元组的主语和宾语都包含空白节点，则使用上述规则两次，一次用于主语，一次用于宾语。0我们的算法与[10,11]中提出的算法有些相似。不同之处在于我们在三元组的级别上计算哈希的方式。算法的伪代码如下：0GraphChain本体是一个类似于原始论文[15]中Nakamoto提出的具有顺序和加密安全链结构的链式命名RDF图的本体。从本体的角度来看，GraphChain的块（单元）是一个具有7个元素的关系的实例化关系（参见[16，用例3]）。在实例化模式中，资源之间的n元关系被表示为单独的OWL类，并且关系的每个实例（n元组）被表示为类的实例加上n个附加的二元关系，这些二元关系提供到n元组的每个参数的链接。GraphChain的单元由列表5的第9-15行和18-24行中列出的元素组成。第8-15行和17-24行分别表示两个块gc:b0和gc:b1的实例以及这些块是主题的七个三元组。正如人们可以观察到的那样，GraphChain的单元具有通常构成区块链块头的元素的对应物。为了简单起见，在我们的表示中，我们没有明确区分块和其头部之间的区别。GraphChain单元旨在“存储”RDF三元组。严格来说，每个块都有一个指向命名图IRI和图的哈希的链接。创世单元是硬编码的，并包含GraphChain本体的标识符和其哈希。这意味着GraphChain的创世单元包含有关其语义结构的信息。18gc:hasDataGraphIRI "http://makolab.com/foo"^^xsd:anyURI ;19gc:hasDataHash "ea8ea1a9dade4880445bea3e7efe505276a3a0cf14b0fcddf4b5e105012d0edf" ;20gc:hasHash "d50f6fa69a7ff6e1b6cb20ecf87dfff360190c1f9b4fc7ad7f3724bc17f85664" ;21gc:hasIndex "1"^^xsd:decimal ;22gc:hasPreviousBlock gc:b0;23gc:hasPreviousHash "27f9ac0be5bd0fb1a84e74247cb6e5cbe9d49d1692e37a481d4710617cf871c6" ;24gc:hasTimeStamp "1515745336"^^xsd:decimal .Listing 3: The genesis and the first block example6EXEMPLARY IMPLEMENTATIONS1 PREFIX : 2 PREFIX bc: 3 SELECT ∗ WHERE {4GRAPH bc:GraphChainJava {5 bc:hasDataGraphIRI ?�→ dataGraphAnyURI.6BIND(IRI(?dataGraphAnyURI) as ?dataGraphIRI) .7GRAPH ?dataGraphIRI { ?sub ?pred ?obj }8}9 }1 PREFIX : 2 PREFIX bc: 3 SELECT ∗ WHERE {4GRAPH bc:GraphChainJava { ?�→ pred ?obj }5 }7RELATED WORKS14http://binsem.makolab.pl/gcgui/15The queries can be used to retrieve data from the node http://binsem.makolab.pl/gcgui/8881 by:• http://ml.ms/GraphChainQuery1• http://ml.ms/GraphChainQuery2Track: 3rd Workshop on Linked Data & Distributed Ledgers WWW 2018, April 23-27, 2018, Lyon, France11760GraphChain由2个类、1个对象属性和6个数据属性组成。它具有ALQ(D)的表达能力和11个类的限制。0我们开发了三个实现，展示了GraphChain理念的主要特点。C#实现使用.NETCore平台，以便在多个环境中轻松部署。节点本身是一个ASP.NETCore Web应用程序，具有用于客户端-节点通信的RESTAPI和用于点对点传输的WebSocket层。它使用DotHash算法进行图形摘要。图形数据本身以字符串形式通过WebSockets传输，以Base64编码的Turtle序列化形式。本地数据存储库可以是内存存储或专用三元组存储（例如AllegroGraph）。用于图形和三元组操作的中间件库是DotNetRdf。Java实现是一个基于Spring管理的Web应用程序。它使用RDF4J库处理语义相关操作。目前，该实现可以将RDF图存储在RDF4J三元组存储和AllegroGraph三元组存储中，但可以添加新的存储方法。与C#实现类似，Java实现使用DotHash算法进行图形摘要，但它还可以使用规范化方法进行图形摘要。我们还开发了第三个示例性节点实现：基于Naivechain的JavaScript实现。它提供HTTP API（https://github . com/lhartikk/naivechain#http-api）和节点之间的P2P通信（https://github . com/lhartikk/naivechain#key-concepts-of-naivechain）。我们的实现与Naivechain之间存在一些差异。我们的实现：1）具有不同的块结构：它包含引用图数据和图数据哈希的RDFURI；2）将数据存储在专用的三元组存储（例如RDF4J）中，而不是内存存储；3）在节点之间的复制过程中包括传输图数据（由IRI引用）。在所有报告的情况下，我们使用LEI参考数据表示为命名的RDF图来测试Graphchain的操作。我们能够在所有参与的节点上对整个命名图链使用SPARQL查询，得到相同的查询结果。根据存储机制的不同，我们还能够使用相应的本机访问方法访问图形（例如，在内存存储模型中迭代图形）。在所有这些初始测试实现中，我们故意忽略了区块链的其他重要特性，例如链更新策略（例如LCR -最长链规则）或共识机制（例如工作证明或权威证明）。这种省略的动机来自于这些特性的实现不依赖于链的实际数据模型，因为它们形成了区块链软件堆栈的另一层。013 Naivechain的GitHub：https://github . com/lhartikk/naivechain。0因此，在初始工作中实现这一点将使实现复杂化，而对于理解基于图形的数据模型对于技术的作用没有好处。我们还创建了一个非常简单的Web界面，用于使用前述实现中使用的简单RESTful接口浏览GraphChain的内容[14]。Web界面如图3所示。它还允许通过SPARQL查询从图形分类账中检索数据。每个节点都有自己的SPARQL端点。下面是两个示例查询[15]：0Listing 4: 选择块号为6的内容。它将是一个LEI图。0Listing 5: 选择块号为6的“metadata”。0关于如何成功地将区块链和语义Web技术相结合的许多有趣想法在[7]中进行了讨论。在本节中，我们将重点关注旨在创建语义区块链的主要尝试。BLONDiE是Héctor Ugarte在SemanticBlockchain项目中开发的本体论[24]。OWL