CN112286963A - 一种区块链终端数据可信查询***及其实现方法 - Google Patents
一种区块链终端数据可信查询***及其实现方法 Download PDFInfo
- Publication number
- CN112286963A CN112286963A CN202011283224.XA CN202011283224A CN112286963A CN 112286963 A CN112286963 A CN 112286963A CN 202011283224 A CN202011283224 A CN 202011283224A CN 112286963 A CN112286963 A CN 112286963A
- Authority
- CN
- China
- Prior art keywords
- node
- mcv
- nodes
- scv
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24549—Run-time optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Data Mining & Analysis (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Finance (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Accounting & Taxation (AREA)
- Computing Systems (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种区块链终端数据可信查询***,包括:全节点、MCV(Merkle‑Root Calculation Verification,默克尔树计算验证)节点及SCV(Simplified Comparison Verification,简单对比验证)节点,该区块链终端数据可信查询***的实现方法通过数据同步模型、层次化验证机制模型和数据解析模型进行。针对区块链查询场景中缺乏数据验证的问题提出区块链终端数据可信查询***,采用层次化的验证机制,提高数据可信度和查询效率,提前完成复杂且耗时的计算验证工作,当收到查询请求时,只进行简单快速的对比验证工作即可。所以,层次化验证机制可以减少查询时需要等待验证的时间,即查询方等待数据的时间不包含耗时的计算验证时间,而只包含对比验证以及后续的数据解析所消耗的时间。
Description
技术领域
本发明涉及区块链技术领域,特别涉及一种区块链终端数据可信查询***及其实现方法。
背景技术
随着人们对数据可信查询的需求日益增长,传统数据库由于其中心化、以及可能遭到网络攻击而导致数据被篡改的问题也成为大众关注的焦点。随着科技的发展,区块链技术应运 而生,由于其自身的一些特点,可以更好地实现数据的可信查询。区块链可看作一个分布式 的共享数据库,存储的数据具有不可篡改、公开透明等特征。传统分布式存储就是将数据分 散地存储在多台物理位置相互独立的数据库设备中,分担存储负荷,相比于集中式的存储系 统,不存在单存储服务器的瓶颈问题、损坏情况,提高了存储***的扩展性、可靠性以及数 据的传输效率。但传统的数据库无论是分布式的还是集中式的,都需要管理员进行控制。区 块链概念下,除了传统的物理分布式的特点,还具有分布式共治的特征,主要体现在其对数 据的写入权限是每个节点所有的,不存在单一中心节点的控制,任意节点存储的数据都要经 过区块链网络下所有节点的共识,达成一致才会将此数据保存在区块链。
从行业领域的角度来看,目前区块链在全球范围内的金融、存证、保险、供应链、溯源、 知识产权等多个领域都有落地的成功案例,部分现已进入实践阶段。区块链可应用于征信、 交通、溯源等多种行业,目的是利用区块链分布式、公开透明、不可篡改等特性,保证存储 数据的真实可信。在以上众多成功的落地案例中,区块链的主要作用是提供了一个可信、公 开、透明的数据库平台,用户在查询时可以从中获取数据。相比于传统的数据库,作为分布 式数据库的区块链技术可以提高查询数据的可信度,但是,现有的区块链查询***缺乏数据 验证机制,只是一味地认为区块链数据绝对可信,查询时也是直接从区块链获取数据,并未 对其进行验证。在区块链的众多应用领域中,其中,溯源被认为是区块链最适合的应用领域 之一,也是近年来区块链发展的重要方向。2018年10月中国信息通信研究院牵头发布了《区 块链溯源应用***》,明确地针对区块链溯源应用,阐述了溯源基本含义、相关技术、应 用案例以及未来展望等。同年,工信部发布的《2018年中国区块链产业***》总结了区块 链的部分应用实例:中国食品链的“链橙”***、京东品质溯源防伪联盟溯安链、基于根源 链的白酒防伪智能锁酒瓶盖。零售巨头沃尔玛利用IBM基于超级账本结构的区块链解决方案, 成功地完成了两个区块链试点,实现对***肉和美洲芒果的安全溯源。2019年4月,国内 物流领域的知名电商京东集团,再次发布《京东区块链技术***(2019)》,主要从解决 业务痛点的角度出发,深挖京东体系内外的众多业务场景,并首先将品质溯源作为典型的应 用案例进行阐述。除了以上区块链溯源具体地落地项目以外,在学术界利用区块链、物联网、 智能合约技术在物流溯源的研究也较为丰富。Galvez(2018)指出将区块链技术应用于食品供应 链,具有信息透明、交易高效以及安全等优点。伏阳阳对现有跨境电商物流模式进行了研究, 提出了基于区块链的跨境电商物流溯源的体系架构及方法,并表明区块链技术的发展可能会 助力跨境电商物流创造新的生态环境。Abeyratne(2016)、Biswas(2017)分别提出将区块链用于 纸板箱、葡萄酒的物流溯源***。郭珊珊提出了一种基于供应链的可信溯源在区块链技术上 的一种实现方法。基于区块链的食品安全溯源***通过技术架构的分析,提出将区块链恰当 植入食品溯源体系的方案。吕芙蓉提出使用区块链技术和物联网技术重构农产品质量安全追 溯体系的创新思路,并利用智能合约按照规则自动化执行指令的特点,将国家监管政策、行 业标准等重要内容写入智能合约。通过智能合约保证食品的质量安全及整个物流的可追溯性。 Lin(2018)指出未来可以利用智能合约脚本技术在食品安全溯源***中定义一套自动报警代码, 帮助工作人员及时发现问题并处理。Westerkamp(2018)进一步提出在基于区块链的供应链溯 源***中将智能合约作为产品制造的配方,生产完成后利用ERC721(Ethereum Request forComments)对产成品生成独一无二的数字标识,以此解决农产品在供应链中经过多次转换后 较难溯源的情况。Badzar旨在探索区块链技术在物流中的应用潜力,重点是提高供应商和消 费者的信息透明度,实现对物流中产品的可信溯源。Kumar提出将区块链技术用于大米的物 流溯源中,跟踪查询大米的所有状态,以此来验证大米的质量。林军等将区块链技术、物联 网技术及智能合约应用于农业中,旨在构建一个高可信、可追溯的智慧农业***,其中也包 括仓储、配送等物流环节的溯源监测。
综上,大多使用区块链技术作为溯源场景中数据查询的研究,都假设从区块链上查询的 数据真实可信,但这些假设存在一定的安全性问题。
目前区块链技术仍处于探索阶段,区块链网络带宽有限,联盟链中通常节点数量不多, 如物流溯源等存在大量终端设备同时进行查询,容易造成网络拥塞,查询效率低等问题。而 如果查询需要花费较长时间,有可能终端得到的数据与链上数据不一致,造成信息滞后、不 准确。为此,出现了一些关于提高区块链查询效率的方法:
1)外联数据库方法:在区块链***的外部设置外联数据库用以存储区块链内部的数据, 所以其查询层也位于外联数据库,此数据库可以选择关系型数据库、非关系型数据库以及具 有区块链不可篡改性的新型数据库(如BigchainDB)等。目前,区块链存储***查询功能比 较单一化、查询过程复杂且效率也相对较低,而外联数据库由于其数据库本身的特点(以上 所说的数据库类型),查询过程与区块链***互不关联,主要借助功能丰富、体系完善的API (Application Programming Interface,应用程序接口)完成,简单好操作,相比于区块链*** 大多具有查询速度快、查询效率高、查询语句丰富、查询功能多样等优点。但是,由于外联 数据库需要保存区块链***上完整的数据副本,需要占据大量额外的磁盘空间,并且由于其 位于区块链***外部,不受区块链保护,所以可能存在数据被篡改的风险,而对于篡改数据 的校验也得依赖区块链完成,需要耗费大量的计算资源;
2)内置辅助索引方法:在区块链底层数据存储***内部构建索引,并根据此索引设计查 询层。其查询过程主要分为两步:一是根据具体的请求命令确定查询结果的key集合,二是 根据以上key集合查找到所对应的value集合,且以上两步的查询过程均需借助索引来完成。 内置索引方法相比于外联数据库方法最大的优点在于:构建索引所占用的额外存储空间小, 且数据都位于区块链内部,时刻受到区块链的保护,安全性相对较高。如果数据被篡改或受 到外部攻击,也可以通过区块链***内的其他节点进行恢复。但正是由于内置索引方法是在 区块链内部进行改进,其相关查询功能也与区块链***密不可分,所以其查询性能不如外联 数据库方法。
但是,以上区块链查询方法都缺乏对数据的验证机制,即假设从区块链上查询的数据完 全真实可信。
发明内容
为了克服现有技术的以上缺陷,本发明提出一种区块链终端数据可信查询***,核心思 想是设计层次化验证机制来提高查询数据的可信度,该验证机制下保证查询到的数据是真实 可信的。具体地,用户从区块链上查询数据时,区块链不会直接将数据反馈给用户,而是增 加一部分验证工作,保证只有验证通过的数据才会被查询,以此来提高数据的可信度。但是, 验证过程复杂且会消耗大量时间,降低查询效率,相比于直接将数据反馈给用户,增加验证 机制会带来一定的时间消耗,此部分时间即为用户的等待时间,为了提高查询效率,将此验 证过程进行分离,提出层次化的验证机制,目的在减少用户的等待时间。主要的设计思想是:
(1)在数据被查询之前需要对其进行验证(验证算法主要基于默克尔树进行设计),只 有验证成功的数据才会被查询,以此提高数据可信度;
(2)验证过程包括数据同步和验证计算等工作,其间会消耗大量时间,不符合高效的特 点,所以本发明将完整的验证过程进行分离,分别交由不同的区块链节点完成,而在查询之 前只需简单验证即可,以此提高查询效率。
本发明的目的在于提供一种区块链终端数据可信查询***,包括:全节点、MCV(Merkle-Root Calculation Verification,默克尔树计算验证)节点以及SCV(SimplifiedComparison Verification,简单对比验证)节点,三种节点为三种不同层次、不同任务、不同功能的区块链节点,其中:
所述全节点遵循区块链的所有规则,保存完整的区块链数据副本,运行所述全节点需要 充足的存储资源、计算资源,所述全节点保存有整个区块链完整的数据副本,数据以区块的 形式进行存储,区块结构由块头和块体两部分组成,所述块头中保存本区块的部分数据: ReceiptRoot、ParentHash、nonce和timesStamp,所述块体包含了交易回执信息Receipt在 内的本区块的所有数据;
所述MCV节点用于从全节点同步待验证的数据,并对此数据基于默克尔树进行递归哈希 计算,得到默克尔树根,从而完成计算验证过程,所述MCV节点运行在高性能、资源充足的 服务器上;
所述SCV节点用于对比所述MCV节点经过计算验证过程得到的默克尔树根,并判断此哈 希值是否正确,从而完成对比验证过程,所述SCV节点运行在低性能、资源不足的终端设备 上,所述SCV节点也叫做终端节点;
其中,所述MCV节点和SCV节点不参与区块链共识、同步所有区块,但会同步所有块头 信息并进行区块检查,通过检查并确定无误的块头才会被存储至MCV节点和SCV节点中,如 果未通过检查则会重新同步。
优选的,所述MCV节点还用于计算验证任务,包括:首先从全节点同步待验证的数据, 即交易回执信息,并根据计算验证算法得到一个待验证的根哈希值Receipt_Root;不管 Receipt_Root是否正确,都会将其存储至MCV节点本地,另外,与其相对应的交易回执信息 也会存储到该节点本地,从而所述MCV节点会存储所有已经过区块检查并确认无误区块的交 易回执信息和对应的Receipt_Root以供SCV节点随时获取。
优选的,所述SCV节点工作流程包括当SCV节点收到查询请求时首先会对待查询的数据 进行对比验证:对比验证的数据来源于两个渠道,一是MCV节点本地存储的Receipt_Root, 二是SCV节点本地存储的ReceiptRoot,其中SCV节点本地存储的ReceiptRoot为SCV节点 从全节点同步并存储的块头信息中所得,当Receipt_Root和ReceiptRoot相等时,验证成功, 认为Receipt_Root所对应的交易回执信息是正确的,否则重新验证;确定该区块的交易回执 信息正确之后,SCV节点会从MCV节点同步此交易回执信息,并从其中提取关键数据并解析, 最终返回给查询方,查询任务完成。
本发明的目的在于提供一种区块链终端数据可信查询***的实现方法,实现方法通过数 据同步模型、层次化验证机制模型和数据解析模型进行。
优选的,所述数据同步模型包括:全节点保存有完整的区块链交易信息,MCV节点和SCV 节点连接全节点并不断同步块头信息,在同步块头信息之前进行区块检查,所述区块检查包 括区块深度检查和哈希指针检查;所述区块深度检查中所述区块深度是指区块与区块之间的 距离,即该区块块数与最新区块块数的差值,所述区块深度检查中认为所述差值大于6说明 该区块内的交易信息已经得到区块链网络的认可,否则容易造成分叉现象;所述哈希指针检 查通过表示数据的存储位置及数据的哈希值的哈希指针判断数据是否被篡改,其中所述哈希 指针的值是通过数据计算出来的,且指向数据的所在位置;区块深度检查和哈希指针检查通 过之后,MCV节点和SCV节点便可从全节点同步所有经过检查的块头信息,并保存在本地。
优选的,所述层次化验证机制模型包括:MCV节点和SCV节点同步块头信息时,通过区 块深度检查和哈希指针检查后,MCV节点进行交易回执信息的计算验证工作,一旦SCV节点 收到查询请求,则会完成对比验证工作,将同步交易回执信息和执行递归哈希算法作为一部 分任务交由MCV节点完成,将对比Receipt_Root和ReceiptRoot作为另一部分任务交由SCV 节点完成以提高查询效率。
优选的,所述计算验证工作中需要验证的数据并非整个区块的交易信息,而是交易回执 信息,包含三部分:共识内容、交易信息以及区块信息。其中,共识内容可用一个四元组表 达式表示:
R=(Rs,Rg,RL,Rb) (1)
Rs表示交易执行之后的状态;Rg表示当前区块中所有交易所消耗的Gas总值;RL表示执行 交易所创建的日志信息;Rb表示日志Bloom过滤器;每笔交易执行完成之后,以上信息都会 有所更新;计算验证过程由MCV节点完成,所述计算验证工作的过程如下:MCV节点接连全 节点并同步区块体中的所有交易回执信息,提取交易回执信息中的由式(1)表示的共识内容R,并进行RLP(Recursive Length Prefix)编码得到Rrlp数组,对此编码数据基于默克尔树进 行递归哈希计算进行计算验证过程,所有的MCV节点都会对本地保存的所有块头所对应的交 易回执信息进行计算验证,并将结果Receipt_Root以及交易回执信息保存至本地;
所述对比验证过程由SCV节点完成,当SCV节点接收到查询请求时进行对比验证,只有 验证成功的数据,才会将请求数据所在区块的交易回执信息返回给SCV节点,SCV节点进行 数据解析之后再返回给查询方;SCV节点进行对比验证的对象包括两部分:一是SCV节点本 地保存的块头信息中的ReceiptRoot,其中SCV节点本地保存的块头信息来源于全节点;二 是从单个或多个MCV节点处获取的Receipt_Root,其中MCV节点经过计算验证将结果Receipt_Root保存至本地,所述SCV节点获取的Receipt_Root的数量由SCV节点连接的MCV节点的数量所决定,进行周期性的MCV节点选择策略,所述MCV节点选择策略包含两种方式:一种是多节点选择方式,一种是单节点选择方式,且两种方式交替进行,形成周期,即每个周期分为两个阶段,第一阶段为多节点选择阶段,选出多个MCV节点共同进行验证;第二阶段为单节点选择阶段,只需特定的一个MCV节点进行验证即可,所述特定节点的选择基于上一阶段的验证情况。当SCV节点需要向MCV节点请求某一区块的Receipt_Root时,需要向MCV节点发送连接请求,此时可能会处于周期内的任意一个阶段:如果处于第一阶段,则需要连接多个MCV节点,被连接的MCV节点将本地保存的Receipt_Root同时发送给SCV节点;如果处于第二阶段,只需连接一个MCV节点,获取一个Receipt_Root即可。
优选的,所述多节点选择阶段包括:
①初始化信誉值:首先,为每个MCV节点的信誉值进行初始化操作,赋值为零,其中假 设整个网络中有m个MCV节点,且每个MCV节点命名为ni(i=1,2,...,m),用Sni(i=1,2,...,m) 表示每个MCV节点的信誉值,其默认初始值为零;
②对比验证:当SCV节点请求连接时,采用随机选择的方式选出多个MCV节点,被选中 的节点数至少为节点总数的一半,且每个MCV节点被选中的概率相等,被选中的MCV节点与 SCV节点之间建立连接,此时,SCV节点便可以向MCV节点请求获取某一区块的Receipt_Root; SCV节点从多个被选中的MCV节点中同时获取同一区块的Receipt_Root,Receipt_Root的一 致率越高,其验证正确率也就越高,为了进一步提高验证的准确性,将多个Receipt_Root与 ReceiptRoot分别进行对比,进行验证,由SCV节点进行对比验证决定验证结果是否正确, 包括:
SCV节点将获取到的多个Receipt_Root与本地保存的一个ReceiptRoot进行如表达式(2) 所示的逐一进行对比:假设有u个MCV节点被选中,其Receipt_Root用Ri来表示,Root表 示SCV节点本地保存的ReceiptRoot,当v(v>=1/2*u)个被选中的MCV节点的Ri是相等的, 并且也与Root相等,此时,表明R1-Rv所对应的Receipt_Root正确,验证成功;
当满足式(2)时,表示对比验证结果正确,即此区块的交易回执信息正确,SCV节点可 以从MCV节点处获取交易回执信息;否则验证失败,此时,会分析失败的原因,由于验证对 比的对象来源于SCV节点和MCV节点,故MCV节点、SCV节点中可能存在错误的节点,并对可能存在错误的节点重新建立连接,对验证失败的区块重新进行验证;
③信誉值更新:每个区块验证成功之后,会根据被选中的MCV节点的Receipt_Root正确 与否进行信誉值的更新,当Receipt_Root正确时,该MCV节点的信誉值增加一个单位;错误 时,信誉值减少一个单位;未被选中的MCV节点信誉值不变,如式(3)和(4),用result(ni)表示第ni个MCV节点的Receipt_Root,True(result(ni))表示Receipt_Root结果 正确,进行信誉值加值,False(result(ni))表示Receipt_Root结果错误,信誉值减值:
Sni+1|True(result(ni)) (3)
Sni-1|False(result(ni)) (4)
④归类和排序:经过数轮多节点的选择,每个MCV节点的信誉值都会不断更新,等到该 周期内多节点选择阶段结束时,为每个节点的信誉值进行排序和归类:当多节点选择阶段结 束时,可能会产生信誉值为正值、零值,甚至是负值的结果,此时,根据该周期内本阶段最 终的信誉值的正负进行节点归类,将信誉值为正值和零值的节点暂时归类为高信誉MCV节点, 用G1表示高信誉MCV节点的集合,如式(5),G1集合中的MCV节点会根据信誉值的高低进 行排序,用于单节点选择阶段;而信誉值为负值的节点暂时归类为低信誉值MCV节点,用G2 表示低信誉值MCV节点的集合,如式(6),且不再参与下一阶段,即在单节点选择阶段不会 被SCV节点选择,需等到下一周期进行信誉值的重新排序,才有可能被SCV节点选择;
G1={Ni|Sni>=0(i=1,2...,m)} (5)
G2={Nj|Snj<=0(j=1,2...,m)} (6)
优选的,所述单节点选择阶段在执行步骤①-④后还包括:
⑤对比验证:SCV节点从G1集合中优先选择信誉值最高的节点,当信誉值最高的节点正 连接到其他的SCV节点时,则会选择信誉值次高的MCV节点,以此类推,直至找到在空闲的MCV节点中信誉值最高的节点。但考虑到MCV节点的数量一定是少于SCV节点的情况,所以, 如果所有的MCV节点都处于忙碌的状态,则不再考虑MCV节点的连接状态,而是只根据信誉 值的高低进行MCV节点的选择;
⑥信誉值更新,G1重新排序:根据验证结果不断地对每个MCV节点的信誉值进行更新, 等到下一个SCV节点需要验证时,则会根据最新的排序结果进行MCV节点的选择。
优选的,所述数据解析模型包括:SCV节点对比验证成功之后,从MCV节点处同步该区 块的交易回执信息并从交易回执信息中提取关键数据并解析,包括:
由式(7)知:交易回执信息Receipt中的RL表示该笔交易中的所有日志信息,假设此日 志集合中有n个日志信息,则可表示为:
RL=(L1,L2,...,Li,...,Ln) (7)
其中每个日志信息L如式(8):
L=(La,(Lt0,Lt1,...,Lti,...,Ltm),Ld,Lb) (8)
La表示每个日志记录器的地址;Lt表示此日志所包含的一系列日志主题,共m个;Ld表示 一些字节数据,即为本文最终需要存储的关键数据;Lb表示一些必要的区块信息,包括块高、 交易哈希、日志索引和交易索引;由每个日志信息L可知:Log日志中包含了字节数据Ld, 其数据形式表现为以太坊ABI编码,交易执行过程中由原始的智能合约经过一系列的ABI编 码规则处理之后,得到编码数据串D,具体表现为十六进制数:假设某个智能合约方法有z 个参数,分别对各个参数进行编码并得到z个十六进制数D1-Dz,将其拼接形成最终的编码 数据串D,经过编码的数据串D没有可读性,需要对其进行解码,包括根据位数将其分离, 分别进行解码,得到原始的智能合约参数集合,表示为式(9),其中decode(Di)表示对每 个十六进制数继续解码:
Dd=(decode(D1),decode(D2),...,decode(Di),...,decode(Dz)) (9)
Dd即为关键数据,将此数据返回给查询方,查询任务完成。
本发明的有益效果:
针对区块链查询场景中缺乏数据验证的问题,本发明提出区块链终端数据可信查询***, 设计了一种层次化的验证机制,不仅可以提高数据可信度,也可以提高查询效率。其核心思 想是:提前完成复杂且耗时的计算验证工作,当收到查询请求时,只进行简单快速的对比验 证工作即可。所以,层次化验证机制的优点在于,减少查询时需要等待验证的时间,即查询 方等待数据的时间不包含耗时的计算验证时间,而只包含对比验证以及后续的数据解析所消 耗的时间。
根据下文结合附图对本发明具体实施例的详细描述,本领域技术人员将会更加明了本发 明的上述以及其他目的、优点和特征。
附图说明
后文将参照附图以示例性而非限制性的方式详细描述本发明的一些具体实施例。附图中 相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解,这些附图未必 是按比例绘制的。本发明的目标及特征考虑到如下结合附图的描述将更加明显,附图中:
图1为根据本发明实施例的***架构以及运行流程图;
图2为根据本发明实施例的节点选择策略原理图。
具体实施方式
为了使得本发明能够针对其发明要点更加明显易懂,下面将结合附图和实例对本发明作 进一步的说明。在下面的描述中阐述了很多细节和具体实例,提供这些实例是为了能够更透 彻地理解本发明,并且能够将本发明完整形象地传达给本领域的技术人员。虽然本发明能够 以很多不同于此描述的其它方式实施,但是本领域技术人员可以在不违背本发明内涵的情况 下做相应的推广,因此本发明不受下面公开的具体实例及具体附图所限制。
参见图1所示,本实施例一种区块链终端数据可信查询***,包括:全节点、MCV(Merkle-Root Calculation Verification,默克尔树计算验证)节点以及SCV(SimplifiedComparison Verification,简单对比验证)节点,三种节点为三种不同层次、不同任务、不同功能的区块链节点,其中:
全节点遵循区块链的所有规则,保存完整的区块链数据副本,运行全节点需要充足的存 储资源、计算资源;
MCV节点用于从全节点同步待验证的数据,并对此数据基于默克尔树进行递归哈希计算, 得到默克尔树根,从而完成计算验证过程,MCV节点运行在高性能、资源充足的服务器上;
SCV节点用于对比所述MCV节点经过计算验证过程得到的默克尔树根,并判断此哈希值 是否正确,从而完成对比验证过程,SCV节点运行在低性能、资源不足的终端设备上,SCV节 点也叫做终端节点。
全节点保存有整个区块链完整的数据副本,数据以区块的形式进行存储,区块结构由块 头和块体两部分组成,所述块头中保存本区块的部分数据:ReceiptRoot、ParentHash、nonce 和timesStamp等,所述块体包含了交易回执信息Receipt在内的本区块的所有数据,其中ReceiptRoot、交易回执信息Receipt对本***提出的验证机制极为重要。
由于MCV节点和SCV节点本身硬件资源的限制,不会像全节点一样参与区块链共识、同 步所有区块,但在本***中,会同步所有块头信息(如①所示)并进行区块检查(如②所示), 通过检查并确定无误的块头才会被存储至MCV节点和SCV节点中(如③所示),如果未通过 检查则会重新同步。
除了存储块头信息之外,MCV节点的任务还包括计算验证任务(如④所示):首先从全 节点同步待验证的数据,即交易回执信息,并根据计算验证算法(基于默克尔树的递归哈希 算法)得到一个待验证的根哈希值Receipt_Root。不管Receipt_Root是否正确,都会将其 存储至MCV节点本地,另外,与其相对应的交易回执信息也会存储到该节点本地。因此,MCV 节点会存储所有区块(已经过区块检查并确认无误)的交易回执信息和对应的Receipt_Root (如⑤所示),以供SCV节点随时获取。
当SCV节点收到查询请求时(如⑥所示),首先会对待查询的数据进行对比验证,(如 ⑦所示):对比验证的数据主要来源于两个渠道,一是MCV节点本地存储的Receipt_Root, 二是SCV本地存储的ReceiptRoot(ReceiptRoot为SCV节点从全节点同步并存储的块头信息 中所得)。当Receipt_Root和ReceiptRoot相等时,验证成功,认为Receipt_Root所对应 的交易回执信息是正确的,否则重新验证。
确定该区块的交易回执信息正确之后,SCV节点会从MCV节点同步此交易回执信息,并 从其中提取关键数据并解析(如⑧所示),最终返回给查询方,此查询任务完成(如⑨所示)。
本实施例的区块链终端数据可信查询***的实现方法,通过数据同步模型、层次化验证 机制模型和数据解析模型进行。
数据同步模型包括:
全节点保存有完整的区块链交易信息,MCV节点和SCV节点需要连接全节点并不断同步 块头信息,但在同步块头信息之前,需要进行区块检查,区块检查的内容主要包括两部分: 区块深度检查、哈希指针检查。
(1)区块深度检查:区块深度是指区块与区块之间的距离,即该区块块数与最新区块块 数的差值,一般认为此差值大于6,便可说明该区块内的交易信息已经得到区块链网络的认 可(SPV的验证方式就是通过参考交易在区块链的深度来验证交易),否则容易造成分叉现 象。
(2)哈希指针检查:哈希指针的值是通过数据计算出来的,且指向数据的所在位置,所 以哈希指针可以表示数据的存储位置及数据的哈希值,通过哈希指针可以判断数据是否被篡 改。区块链的结构由创世区块开始,之后每个区块通过哈希指针进行连接,每一个区块都包 含了前一个区块的哈希指针。所以,除创世区块以外,所有的区块不仅可以查找前面所有区 块,也可以验证前面区块数据是否被篡改。
区块深度检查和哈希指针检查通过之后,MCV节点和SCV节点便可从全节点同步所有经 过检查的块头信息,并保存在本地。
层次化验证机制模型包括:
MCV节点和SCV节点同步块头信息时,只要通过区块深度检查和哈希指针检查后,MCV节 点便可以进行交易回执信息的计算验证工作,一旦SCV节点收到查询请求,则会完成对比验 证工作。而设计层次化概念的原因在于:每个区块中包含多笔交易,数据量大,从全节点同 步交易回执信息会消耗一定的时间,而此时间比执行递归哈希算法以及对比Receipt_Root和 ReceiptRoot所消耗的时间多(已经过实验验证),而且,存储大量的交易回执信息需要占用 存储资源,显然适合硬件性能比较好的MCV节点,而非轻量级的SCV节点,所以将同步交易 回执信息和执行递归哈希算法作为一部分任务交由MCV节点完成,将对比Receipt_Root和 ReceiptRoot作为另一部分任务交由SCV节点完成,可以提高查询效率。
以下对两部分验证过程进行具体介绍:
(1)计算验证过程
本实施例需要验证的数据并非整个区块的交易信息,而是交易回执信息,主要包含三部 分:共识内容、交易信息以及区块信息。其中,共识内容可用一个四元组式(1):
R=(Rs,Rg,RL,Rb) (1)
Rs表示交易执行之后的状态;Rg表示当前区块中所有交易所消耗的Gas总值;RL表示执行 交易所创建的日志信息;Rb表示日志Bloom过滤器。每笔交易执行完成之后,以上信息都会 有所更新。
计算验证过程由MCV节点完成,由于MCV节点位于层次化验证模型的上层,所以也可称 为上层验证。具体的计算验证过程如下:MCV节点接连全节点并同步区块体中的所有交易回 执信息,提取交易回执信息中的由表达式(1)表示的共识内容R,并进行RLP(Recursive Length Prefix)编码得到Rrlp数组,而主要的计算验证过程便是对此编码数据基于默克尔树进行递 归哈希计算,具体的计算验证算法如算法1所示:
该算法的输入为待验证区块中的Rrlp数组,对此数组中的所有数据进行递归哈希计算,最 终算法的输出是一个根哈希值,用Receipt_Root表示;算法第2-3行判断Rrlp数组是否为空, 此数组为空时,即此区块无交易信息,所以Receipt_Root赋值为空;算法4-22行表示此集 合不为空时,对所有的交易回执信息进行默克尔树递归哈希计算:其中,算法5-7行是对Rrlp数组中的每条数据进行哈希计算,得到的哈希值存放到Hash数组当中;算法8-11行是对此 Hash数组的长度进行调整,若为奇数,则长度增加一个单位,将原Hash数组中的最后一个 数据复制到新Hash数组中的最后一个位置,即新Hash数组中最后两个数据是一样的。若长 度为偶数则不需要进行以上操作;算法12-19行主要对Hash数组中的每个哈希值进行多次递 归哈希计算,比如:算法12-14行,将Hash数组中的第一个和第二个哈希值进行哈希计算, 第三个和第四个哈希值进行哈希计算,以此类推,一直到对倒数第一个和倒数第二个哈希值 进行哈希计算,最终得到的所有哈希值的个数为之前的一半,并将以上得到的哈希值重新存 入新的哈希数组RecoverHash,完成一轮哈希计算;算法15行对此RecoverHash数组的长度 进行判断,若不为1,则继续进行下一轮的哈希计算,重复算法12-14行,将之前生成的 RecoverHash数组中的每一个哈希值再按序进行两两哈希计算得到新的哈希值,重新存入新 的哈希数组RecoverHash,又完成一轮哈希计算。如上,不断进行递归哈希计算,直到 RecoverHash数组的长度为1,如算法18行所示,递归得到最终的根值哈希Receipt_Root。 到此,返回计算验证算法的结果Receipt_Root,算法结束。
所有的MCV节点都会将本地保存的所有块头所对应的交易回执信息进行计算验证,并将 结果Receipt_Root以及交易回执信息保存至本地。但是,MCV节点并不知道Receipt_Root 及其所对应的交易回执信息是否正确,所以,SCV节点需要进行对比验证。
(2)对比验证过程
对比验证过程由SCV节点完成,由于SCV节点位于层次化验证模型的底层,所以也可称 为底层验证。
当SCV节点接收到查询请求时,需要进行对比验证,只有验证成功的数据,才会将请求 数据所在区块的交易回执信息返回给SCV节点,SCV节点进行数据解析之后再返回给查询方。 SCV节点进行对比验证的对象主要包括两部分:一是SCV节点本地保存的块头信息中的 ReceiptRoot(SCV节点本地保存的块头信息来源于全节点);二是从单个或多个MCV节点处 获取的Receipt_Root(MCV节点经过计算验证将结果Receipt_Root保存至本地)。SCV节点 获取的Receipt_Root的数量由SCV节点连接的MCV节点的数量所决定,对此,设计了周期性 的MCV节点选择策略:
该策略主要包含两种方式:一种是多节点选择方式,一种是单节点选择方式,且两种方 式交替进行,形成周期。即每个周期分为两个阶段,第一阶段为多节点选择阶段,其目的是 选出多个MCV节点共同进行验证,显然,此种方式较为复杂,但可信度高;第二阶段为单节 点选择阶段,只需特定的一个MCV节点进行验证即可(此特定节点的选择也是基于上一阶段 的验证情况而言,具体的选择方式见下文),此阶段的优缺点与上一阶段相反,降低复杂度的 同时也降低了可信度。
具体地,当SCV节点需要向MCV节点请求某一区块的Receipt_Root时,需要向MCV节点 发送连接请求,此时可能会处于周期内的任意一个阶段:如果处于第一阶段,则需要连接多 个MCV节点,被连接的MCV节点将本地保存的Receipt_Root同时发送给SCV节点;如果处于 第二阶段,只需连接一个MCV节点,获取一个Receipt_Root即可。但是,在众多MCV节点中, 针对如何有序且公平地选出一个或多个MCV节点的问题,本发明提出信誉值的概念,每个MCV 节点的信誉值都会根据SCV节点的对比验证结果进行更新。
假设整个网络中有m个MCV节点,且每个MCV节点命名为ni(i=1,2,...,m),用 Sni(i=1,2,...,m)表示每个MCV节点的信誉值(默认初始值为零)。
参见图2,节点选择策略原理图为对MCV节点选择策略在某个周期内的具体描述。
(1)多节点选择阶段(t1):
①初始化信誉值:首先,为每个MCV节点的信誉值进行初始化操作(赋值为零);
②对比验证:当SCV节点请求连接时,采用随机选择的方式选出多个MCV节点,被选中 的节点数至少为节点总数的一半,且每个MCV节点被选中的概率相等。被选中的MCV节点与 SCV节点之间建立连接,此时,SCV节点便可以向MCV节点请求获取某一区块的Receipt_Root。
SCV节点从多个被选中的MCV节点中同时获取同一区块的Receipt_Root,Receipt_Root 的一致率越高,其验证正确率也就越高,因为每个MCV节点的验证结果Receipt_Root都需要 经过数次的哈希计算(哈希算法将任意长度的二进制值映射为较短的固定长度的二进制值, 一般被称为哈希值。不同数据经过哈希计算后产生的哈希值都不相同,即使只改变其中的一 个字符,哈希值也会有所不同),所以,一旦某个Receipt_Root和ReceiptRoot相等,很大 概率认为Receipt_Root和ReceiptRoot都是正确的(Receipt_Root和ReceiptRoot都是同 一区块内的所有交易回执信息经过相同的递归哈希算法生成的根值哈希)。为了进一步提高验 证的准确性,本策略将多个Receipt_Root与ReceiptRoot分别进行对比,进行验证,具体如 何判断验证结果是否正确,由SCV节点进行对比验证决定,如下所述:
SCV节点将获取到的Receipt_Root(多个)与本地保存的ReceiptRoot(一个)逐一进 行对比,具体的如式(2):假设有u个MCV节点被选中,其Receipt_Root用Ri来表示,Root表示SCV节点本地保存的ReceiptRoot,当v(v>=1/2*u)个被选中的MCV节点的Ri是相等的,并且也与Root相等。此时,表明R1-Rv所对应的Receipt_Root正确,验证成功。
所以,当满足表达式(2)时,表示对比验证结果正确,即此区块的交易回执信息正确, SCV节点可以从MCV节点处获取交易回执信息。否则验证失败,此时,会分析失败的原因, 由于验证对比的对象来源于SCV节点和MCV节点,故MCV节点、SCV节点中可能存在错误的 节点,并对可能存在错误的节点重新建立连接,对验证失败的区块重新进行验证。以下是可 能存在错误的三种情况:
SCV节点可能存在错误:当被选中的MCV节点中有超过一半的验证计算结果Receipt_Root 相等,但与SCV节点的交易回执根值哈希ReceiptRoot不一致,则认为是SCV节点可能存在 错误,所以SCV节点将会重新连接全节点,重新获取ReceiptRoot,重新验证;
MCV节点可能存在错误:当被选中的MCV节点中,少于一半的验证计算结果Receipt_Root 相等,即使SCV节点的交易回执根值哈希ReceiptRoot与之相等(哈希唯一性原则),也认为 MCV节点可能存在错误,所以SCV节点将会重新连接其他MCV节点(只重新连接验证计算结 果Receipt_Root和ReceiptRoot不同的MCV节点),重新验证;
两者都可能存在错误:如果SCV节点的交易回执根值哈希ReceiptRoot与被选中的验证 节点中所有的验证计算结果Receipt_Root都不相等,此时无法判断可能存在错误的节点是 SCV节点还是MCV节点,因此,认为两者都可能存在错误,SCV节点与MCV节点重新向全节点 发送连接请求,重新同步数据进行验证。
③信誉值更新:每个区块验证成功之后,会根据被选中的MCV节点的Receipt_Root正确 与否进行信誉值的更新(当Receipt_Root正确时,该MCV节点的信誉值增加一个单位;错误 时,信誉值减少一个单位;未被选中的MCV节点信誉值不变)。具体的如式(3)和(4),用result(ni)表示第ni个MCV节点的Receipt_Root,True(result(ni))表示Receipt_Root 结果正确,进行信誉值加值,False(result(ni))表示Receipt_Root结果错误,信誉值减 值:
Sni+1|True(result(ni)) (3)
Sni-1|False(result(ni)) (4)
④归类和排序:经过数轮多节点的选择,每个MCV节点的信誉值都会不断更新,等到该 周期内多节点选择阶段结束时,为每个节点的信誉值进行排序和归类:
由于每个MCV节点的信誉值是基于其验证结果进行增减的,所以当多节点选择阶段结束 时,可能会产生信誉值为正值、零值,甚至是负值的结果,此时,根据该周期内本阶段最终 的信誉值的正负进行节点归类,将信誉值为正值和零值的节点暂时归类为高信誉MCV节点, 用G1表示高信誉MCV节点的集合,如式(5),G1集合中的MCV节点会根据信誉值的高低进 行排序,主要用于下一阶段的选择(单节点选择阶段);而信誉值为负值的节点暂时归类为低 信誉值MCV节点,用G2表示低信誉值MCV节点的集合,如式(6),且不再参与下一阶段,即 在单节点选择阶段不会被SCV节点选择,需等到下一周期进行信誉值的重新排序,才有可能 在单节点阶段被SCV节点选择。
G1={Ni|Sni>=0(i=1,2...,m)} 表达式(5)
G2={Nj|Snj<=0(j=1,2...,m)} 表达式(6)
(2)单节点选择阶段(t2):
以上多节点选择阶段需要选出多个MCV节点进行验证,每个MCV节点都有公平被选择的 机会,此过程虽然提高了可靠性,但复杂度却比单节点选择阶段大,因此,设计以上信誉值 的概念,为单节点选择阶段提供选择的基础,即只有G1集合中的MCV节点才有被选择的权利, 且信誉值越高,被选择的概率越大。
⑤对比验证:SCV节点从G1集合中优先选择信誉值最高的节点(如图2中的⑤所示), 当信誉值最高的节点正连接到其他的SCV节点时,则会选择信誉值次高的MCV节点,以此类 推,直至找到在空闲的MCV节点中信誉值最高的节点。但考虑到MCV节点的数量一定是少于 SCV节点的情况,所以,如果所有的MCV节点都处于忙碌的状态,则不再考虑MCV节点的连 接状态(空闲或者忙碌),而是只根据信誉值的高低进行MCV节点的选择。
⑥信誉值更新,G1重新排序:另外,此阶段也会根据验证结果不断地对每个MCV节点的 信誉值进行更新,等到下一个SCV节点需要验证时,则会根据最新的排序结果进行MCV节点 的选择。
以上,主要介绍多节点选择阶段和单节点选择阶段具体的选择方式,当SCV节点需要验 证某一区块的交易回执信息时,会判断此时的时间是处于多节点选择阶段还是单节点选择阶 段,并选择相应的节点选择方式,完成验证任务。
以下对多节点先择阶段和单节点选择阶段进行对比:
所以,根据以上表格对比,多节点选择阶段虽然较单节点选择阶段更为复杂,效率也更 低,但由于是多个Receipt_Root与ReceiptRoot共同参与对比,所以可靠性更高。
如上,主要介绍层次化验证机制的设计思想,其核心是对一个完整的验证任务(同步某 一区块的交易回执信息,并对此进行递归哈希算法生成Receipt_Root,将Receipt_Root与 块头中的ReceiptRoot进行对比,若相等,则验证结果正确,否则错误)进行层次化分离, 将同步交易回执信息和计算Receipt_Root任务分给MCV节点完成,而将对比Receipt_Root 和ReceiptRoot来判断Receipt_Root是否正确的任务交给SCV节点。
以下是MCV节点执行的计算验证过程和SCV节点执行的对比验证过程的对比:
所以,不管是MCV节点还是SCV节点,其验证的基本单位都是单一区块中的所有交易回 执信息,MCV节点的计算验证结果Receipt_Root以及同步的交易回执信息都是为SCV节点提 供便利,辅助完成SCV节点的对比验证任务,使SCV节点的查询效率更高。
SCV节点对比验证成功之后,会从MCV节点处同步该区块的交易回执信息。但是,由于 此交易回执信息是经过编码且不可读的数据,不能直接返回给查询方,所以需要从交易回执 信息中提取关键数据并解析,以下是具体过程:
由式(7)知:交易回执信息Receipt中的RL表示该笔交易中的所有日志信息,假设此日 志集合中有n个日志信息,则可表示为:
RL=(L1,L2,...,Li,...,Ln) 表(7)
其中每个日志信息L如式(8):
L=(La,(Lt0,Lt1,...,Lti,...,Ltm),Ld,Lb) (8)
La表示每个日志记录器的地址;Lt表示此日志所包含的一系列日志主题(假设有m个); Ld表示一些字节数据,即为本文最终需要存储的关键数据;Lb表示一些必要的区块信息,比 如块高、交易哈希、日志索引和交易索引等。
由每个日志信息L可知:Log日志中包含了字节数据Ld,其数据形式表现为以太坊ABI (Application Binary Interface)编码,此编码也是区块链外部与智能合约进行交互以及 多个合约之间进行交互的一种标准方式,起到了区块链***内部或跨***的交互作用。具体 地,指在交易执行过程中由原始的智能合约经过一系列的ABI编码规则处理之后,得到编码 数据串D,具体表现为十六进制数:假设某个智能合约方法有z个参数,分别对各个参数进 行编码并得到z个十六进制数D1-Dz,将其拼接形成最终的编码数据串D。但是,经过编码的 数据串D没有可读性,所以需要对其进行解码。由于经过编码的数据串D中的每一个数据Di都是32字节,所以可以根据位数将其分离,分别进行解码,得到原始的智能合约参数集合, 可表示为式(9),其中decode(Di)表示对每个十六进制数继续解码:
Dd=(decode(D1),decode(D2),...,decode(Di),...,decode(Dz)) (9)
Dd即为关键数据,将此数据返回给查询方,查询任务完成。
本实施例针对区块链查询场景中缺乏数据验证的问题,本发明提出区块链终端数据可信 查询***,设计了一种层次化的验证机制,不仅可以提高数据可信度,也可以提高查询效率。 其核心思想是:提前完成复杂且耗时的计算验证工作,当收到查询请求时,只进行简单快速 的对比验证工作即可。所以,层次化验证机制的优点在于,减少查询时需要等待验证的时间, 即查询方等待数据的时间不包含耗时的计算验证时间,而只包含对比验证以及后续的数据解 析所消耗的时间。
虽然本发明已经参考特定的说明性实施例进行了描述,但是不会受到这些实施例的限定 而仅仅受到附加权利要求的限定。本领域技术人员应当理解可以在不偏离本发明的保护范围 和精神的情况下对本发明的实施例能够进行改动和修改。
Claims (10)
1.一种区块链终端数据可信查询***,其特征在于包括:全节点、MCV(Merkle-RootCalculation Verification,默克尔树计算验证)节点以及SCV(Simplified ComparisonVerification,简单对比验证)节点,三种节点为三种不同层次、不同任务、不同功能的区块链节点,其中:
所述全节点遵循区块链的所有规则,保存完整的区块链数据副本,运行所述全节点需要充足的存储资源、计算资源,所述全节点保存有整个区块链完整的数据副本,数据以区块的形式进行存储,区块结构由块头和块体两部分组成,所述块头中保存本区块的部分数据:ReceiptRoot、ParentHash、nonce和timesStamp,所述块体包含了交易回执信息Receipt在内的本区块的所有数据;
所述MCV节点用于从全节点同步待验证的数据,并对此数据基于默克尔树进行递归哈希计算,得到默克尔树根,从而完成计算验证过程,所述MCV节点运行在高性能、资源充足的服务器上;
所述SCV节点用于对比所述MCV节点经过计算验证过程得到的默克尔树根,并判断此哈希值是否正确,从而完成对比验证过程,所述SCV节点运行在低性能、资源不足的终端设备上,所述SCV节点也叫做终端节点;
其中,所述MCV节点和SCV节点不参与区块链共识、同步所有区块,但会同步所有块头信息并进行区块检查,通过检查并确定无误的块头才会被存储至MCV节点和SCV节点中,如果未通过检查则会重新同步。
2.根据权利要求1所述的一种区块链终端数据可信查询***,其特征在于所述MCV节点还用于计算验证任务,包括:首先从全节点同步待验证的数据,即交易回执信息,并根据计算验证算法得到一个待验证的根哈希值Receipt_Root;不管Receipt_Root是否正确,都会将其存储至MCV节点本地,另外,与其相对应的交易回执信息也会存储到该节点本地,从而所述MCV节点会存储所有已经过区块检查并确认无误区块的交易回执信息和对应的Receipt_Root以供SCV节点随时获取。
3.根据权利要求1所述的一种区块链终端数据可信查询***,其特征在于所述SCV节点工作流程包括当SCV节点收到查询请求时首先会对待查询的数据进行对比验证:对比验证的数据来源于两个渠道,一是MCV节点本地存储的Receipt_Root,二是SCV节点本地存储的ReceiptRoot,其中SCV节点本地存储的ReceiptRoot为SCV节点从全节点同步并存储的块头信息中所得,当Receipt_Root和ReceiptRoot相等时,验证成功,认为Receipt_Root所对应的交易回执信息是正确的,否则重新验证;确定该区块的交易回执信息正确之后,SCV节点会从MCV节点同步此交易回执信息,并从其中提取关键数据并解析,最终返回给查询方,查询任务完成。
4.一种根据权利要求1-3任一所述区块链终端数据可信查询***的实现方法,其特征在于所述实现方法通过数据同步模型、层次化验证机制模型和数据解析模型进行。
5.根据权利要求4所述的实现方法,其特征在于所述数据同步模型包括:全节点保存有完整的区块链交易信息,MCV节点和SCV节点连接全节点并不断同步块头信息,在同步块头信息之前进行区块检查,所述区块检查包括区块深度检查和哈希指针检查;所述区块深度检查中所述区块深度是指区块与区块之间的距离,即该区块块数与最新区块块数的差值,所述区块深度检查中认为所述差值大于6说明该区块内的交易信息已经得到区块链网络的认可,否则容易造成分叉现象;所述哈希指针检查通过表示数据的存储位置及数据的哈希值的哈希指针判断数据是否被篡改,其中所述哈希指针的值是通过数据计算出来的,且指向数据的所在位置;区块深度检查和哈希指针检查通过之后,MCV节点和SCV节点便可从全节点同步所有经过检查的块头信息,并保存在本地。
6.根据权利要求4所述的实现方法,其特征在于所述层次化验证机制模型包括:MCV节点和SCV节点同步块头信息时,通过区块深度检查和哈希指针检查后,MCV节点进行交易回执信息的计算验证工作,一旦SCV节点收到查询请求,则会完成对比验证工作,将同步交易回执信息和执行递归哈希算法作为一部分任务交由MCV节点完成,将对比Receipt_Root和ReceiptRoot作为另一部分任务交由SCV节点完成以提高查询效率。
7.根据权利要求6所述的实现方法,其特征在于所述计算验证工作中需要验证的数据并非整个区块的交易信息,而是交易回执信息,包含三部分:共识内容、交易信息以及区块信息。其中,共识内容可用一个四元组表达式表示为式(1):
R=(Rs,Rg,RL,Rb) (1)
Rs表示交易执行之后的状态;Rg表示当前区块中所有交易所消耗的Gas总值;RL表示执行交易所创建的日志信息;Rb表示日志Bloom过滤器;每笔交易执行完成之后,以上信息都会有所更新;计算验证过程由MCV节点完成,所述计算验证工作的过程如下:MCV节点接连全节点并同步区块体中的所有交易回执信息,提取交易回执信息中的由表达式(1)表示的共识内容R,并进行RLP(Recursive Length Prefix)编码得到Rrlp数组,对此编码数据基于默克尔树进行递归哈希计算进行计算验证过程,所有的MCV节点都会对本地保存的所有块头所对应的交易回执信息进行计算验证,并将结果Receipt_Root以及交易回执信息保存至本地;
所述对比验证过程由SCV节点完成,当SCV节点接收到查询请求时进行对比验证,只有验证成功的数据,才会将请求数据所在区块的交易回执信息返回给SCV节点,SCV节点进行数据解析之后再返回给查询方;SCV节点进行对比验证的对象包括两部分:一是SCV节点本地保存的块头信息中的ReceiptRoot,其中SCV节点本地保存的块头信息来源于全节点;二是从单个或多个MCV节点处获取的Receipt_Root,其中MCV节点经过计算验证将结果Receipt_Root保存至本地,所述SCV节点获取的Receipt_Root的数量由SCV节点连接的MCV节点的数量所决定,进行周期性的MCV节点选择策略,所述MCV节点选择策略包含两种方式:一种是多节点选择方式,一种是单节点选择方式,且两种方式交替进行,形成周期,即每个周期分为两个阶段,第一阶段为多节点选择阶段,选出多个MCV节点共同进行验证;第二阶段为单节点选择阶段,只需特定的一个MCV节点进行验证即可,所述特定节点的选择基于上一阶段的验证情况。当SCV节点需要向MCV节点请求某一区块的Receipt_Root时,需要向MCV节点发送连接请求,此时可能会处于周期内的任意一个阶段:如果处于第一阶段,则需要连接多个MCV节点,被连接的MCV节点将本地保存的Receipt_Root同时发送给SCV节点;如果处于第二阶段,只需连接一个MCV节点,获取一个Receipt_Root即可。
8.根据权利要求7所述的实现方法,其特征在于所述多节点选择阶段包括:
①初始化信誉值:首先,为每个MCV节点的信誉值进行初始化操作,赋值为零,其中假设整个网络中有m个MCV节点,且每个MCV节点命名为ni(i=1,2,...,m),用Sni(i=1,2,...,m)表示每个MCV节点的信誉值,其默认初始值为零;
②对比验证:当SCV节点请求连接时,采用随机选择的方式选出多个MCV节点,被选中的节点数至少为节点总数的一半,且每个MCV节点被选中的概率相等,被选中的MCV节点与SCV节点之间建立连接,此时,SCV节点便可以向MCV节点请求获取某一区块的Receipt_Root;SCV节点从多个被选中的MCV节点中同时获取同一区块的Receipt_Root,Receipt_Root的一致率越高,其验证正确率也就越高,为了进一步提高验证的准确性,将多个Receipt_Root与ReceiptRoot分别进行对比,进行验证,由SCV节点进行对比验证决定验证结果是否正确,包括:
SCV节点将获取到的多个Receipt_Root与本地保存的一个ReceiptRoot进行如表达式(2)所示的逐一进行对比:假设有u个MCV节点被选中,其Receipt_Root用Ri来表示,Root表示SCV节点本地保存的ReceiptRoot,当v(v>=1/2*u)个被选中的MCV节点的Ri是相等的,并且也与Root相等,此时,表明R1-Rv所对应的Receipt_Root正确,验证成功;
当满足式(2)时,表示对比验证结果正确,即此区块的交易回执信息正确,SCV节点可以从MCV节点处获取交易回执信息;否则验证失败,此时,会分析失败的原因,由于验证对比的对象来源于SCV节点和MCV节点,故MCV节点、SCV节点中可能存在错误的节点,并对可能存在错误的节点重新建立连接,对验证失败的区块重新进行验证;
③信誉值更新:每个区块验证成功之后,会根据被选中的MCV节点的Receipt_Root正确与否进行信誉值的更新,当Receipt_Root正确时,该MCV节点的信誉值增加一个单位;错误时,信誉值减少一个单位;未被选中的MCV节点信誉值不变,如式(3)和(4),用result(ni)表示第ni个MCV节点的Receipt_Root,True(result(ni))表示Receipt_Root结果正确,进行信誉值加值,False(result(ni))表示Receipt_Root结果错误,信誉值减值:
Sni+1|True(result(ni)) (3)
Sni-1|False(result(ni)) (4)
④归类和排序:经过数轮多节点的选择,每个MCV节点的信誉值都会不断更新,等到该周期内多节点选择阶段结束时,为每个节点的信誉值进行排序和归类:当多节点选择阶段结束时,可能会产生信誉值为正值、零值,甚至是负值的结果,此时,根据该周期内本阶段最终的信誉值的正负进行节点归类,将信誉值为正值和零值的节点暂时归类为高信誉MCV节点,用G1表示高信誉MCV节点的集合,如式(5),G1集合中的MCV节点会根据信誉值的高低进行排序,用于单节点选择阶段;而信誉值为负值的节点暂时归类为低信誉值MCV节点,用G2表示低信誉值MCV节点的集合,如式(6),且不再参与下一阶段,即在单节点选择阶段不会被SCV节点选择,需等到下一周期进行信誉值的重新排序,才有可能被SCV节点选择;
G1={Ni|Sni>=0(i=1,2...,m)} (5)
G2={Nj|Snj<=0(j=1,2...,m)} (6)。
9.根据权利要求8所述的实现方法,其特征在于所述单节点选择阶段在执行步骤①-④后还包括:
⑤对比验证:SCV节点从G1集合中优先选择信誉值最高的节点,当信誉值最高的节点正连接到其他的SCV节点时,则会选择信誉值次高的MCV节点,以此类推,直至找到在空闲的MCV节点中信誉值最高的节点。但考虑到MCV节点的数量一定是少于SCV节点的情况,所以,如果所有的MCV节点都处于忙碌的状态,则不再考虑MCV节点的连接状态,而是只根据信誉值的高低进行MCV节点的选择;
⑥信誉值更新,G1重新排序:根据验证结果不断地对每个MCV节点的信誉值进行更新,等到下一个SCV节点需要验证时,则会根据最新的排序结果进行MCV节点的选择。
10.根据权利要求4所述的实现方法,其特征在于所述数据解析模型包括:SCV节点对比验证成功之后,从MCV节点处同步该区块的交易回执信息并从交易回执信息中提取关键数据并解析,包括:
由式(7)知:交易回执信息Receipt中的RL表示该笔交易中的所有日志信息,假设此日志集合中有n个日志信息,则可表示为:
RL=(L1,L2,...,Li,...,Ln) (7)
其中每个日志信息L如式(8):
L=(La,(Lt0,Lt1,...,Lti,...,Ltm),Ld,Lb) (8)
La表示每个日志记录器的地址;Lt表示此日志所包含的一系列日志主题,共m个;Ld表示一些字节数据,即为本文最终需要存储的关键数据;Lb表示一些必要的区块信息,包括块高、交易哈希、日志索引和交易索引;由每个日志信息L可知:Log日志中包含了字节数据Ld,其数据形式表现为以太坊ABI编码,交易执行过程中由原始的智能合约经过一系列的ABI编码规则处理之后,得到编码数据串D,具体表现为十六进制数:假设某个智能合约方法有z个参数,分别对各个参数进行编码并得到z个十六进制数D1-Dz,将其拼接形成最终的编码数据串D,经过编码的数据串D没有可读性,需要对其进行解码,包括据位数将其分离,分别进行解码,得到原始的智能合约参数集合,表示为表达式(9),其中decode(Di)表示对每个十六进制数继续解码:
Dd=(decode(D1),Decode(D2),...,decode(Di),...,decode(Dz)) 表达式(9)
Dd即为关键数据,将此数据返回给查询方,查询任务完成。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011283224.XA CN112286963B (zh) | 2020-11-17 | 2020-11-17 | 一种区块链终端数据可信查询***及其实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011283224.XA CN112286963B (zh) | 2020-11-17 | 2020-11-17 | 一种区块链终端数据可信查询***及其实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112286963A true CN112286963A (zh) | 2021-01-29 |
CN112286963B CN112286963B (zh) | 2023-05-26 |
Family
ID=74399023
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011283224.XA Active CN112286963B (zh) | 2020-11-17 | 2020-11-17 | 一种区块链终端数据可信查询***及其实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112286963B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112866282A (zh) * | 2021-02-10 | 2021-05-28 | 中国人民银行数字货币研究所 | 区块链中时间信息验证方法和装置 |
CN113239078A (zh) * | 2021-05-17 | 2021-08-10 | 国网河南省电力公司信息通信公司 | 一种基于联盟链的数据快速查询方法 |
CN113742384A (zh) * | 2021-09-09 | 2021-12-03 | 海南安迈云网络技术有限公司 | 一种基于区块链的数据读取方法 |
CN113761065A (zh) * | 2021-08-27 | 2021-12-07 | 河南向量智能科技研究院有限公司 | 一种网状设计节点结构的呼应设计方法 |
CN113923058A (zh) * | 2021-12-15 | 2022-01-11 | 武汉云麒联网科技有限公司 | 一种非即时能源数据分析的大数据预警方法与装置 |
CN114760073A (zh) * | 2022-06-13 | 2022-07-15 | 湖南华菱电子商务有限公司 | 基于区块链的仓储商品配送方法、装置、电子设备及介质 |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160321751A1 (en) * | 2015-04-28 | 2016-11-03 | Domus Tower, Inc. | Real-time settlement of securities trades over append-only ledgers |
US20170364699A1 (en) * | 2015-06-02 | 2017-12-21 | ALTR Solutions, Inc. | Transparent client application to arbitrate data storage between mutable and immutable data repositories |
US20190058581A1 (en) * | 2017-08-03 | 2019-02-21 | Gavin Wood | Methods and Systems for a Heterogeneous Multi-Chain Framework |
CN109885615A (zh) * | 2019-01-24 | 2019-06-14 | 华东师范大学 | 一种基于索引的面向区块链轻客户端的范围查询可验证查询方法 |
CN109919756A (zh) * | 2019-02-22 | 2019-06-21 | 西南财经大学 | 基于Merkle树回溯定位技术的转账***、查验方法及交易方法 |
CN110134671A (zh) * | 2019-05-21 | 2019-08-16 | 北京物资学院 | 一种面向溯源应用的区块链数据库数据管理***及方法 |
CN110503558A (zh) * | 2019-08-29 | 2019-11-26 | 深圳前海微众银行股份有限公司 | 一种基于区块链***的处理方法及装置 |
US20200027089A1 (en) * | 2018-07-20 | 2020-01-23 | Coral Protocol | Blockchain transaction safety using smart contracts |
CN110784346A (zh) * | 2019-10-18 | 2020-02-11 | 深圳供电局有限公司 | 一种基于信誉值的pbft共识***及方法 |
CN111507709A (zh) * | 2020-03-25 | 2020-08-07 | 农业农村部农药检定所(国际食品法典农药残留委员会秘书处) | 一种数据溯源*** |
CN111680049A (zh) * | 2020-05-15 | 2020-09-18 | 杭州趣链科技有限公司 | 一种基于区块链的物联网数据的处理方法及其处理装置 |
CN111756546A (zh) * | 2020-06-15 | 2020-10-09 | 杭州电子科技大学 | 一种车联网环境下基于动态信誉机制的区块链共识方法 |
CN111782723A (zh) * | 2020-06-05 | 2020-10-16 | 成都链向科技有限公司 | 一种基于许可链的双层产品信息追溯***架构 |
-
2020
- 2020-11-17 CN CN202011283224.XA patent/CN112286963B/zh active Active
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160321751A1 (en) * | 2015-04-28 | 2016-11-03 | Domus Tower, Inc. | Real-time settlement of securities trades over append-only ledgers |
US20170364699A1 (en) * | 2015-06-02 | 2017-12-21 | ALTR Solutions, Inc. | Transparent client application to arbitrate data storage between mutable and immutable data repositories |
US20190058581A1 (en) * | 2017-08-03 | 2019-02-21 | Gavin Wood | Methods and Systems for a Heterogeneous Multi-Chain Framework |
US20200027089A1 (en) * | 2018-07-20 | 2020-01-23 | Coral Protocol | Blockchain transaction safety using smart contracts |
CN109885615A (zh) * | 2019-01-24 | 2019-06-14 | 华东师范大学 | 一种基于索引的面向区块链轻客户端的范围查询可验证查询方法 |
CN109919756A (zh) * | 2019-02-22 | 2019-06-21 | 西南财经大学 | 基于Merkle树回溯定位技术的转账***、查验方法及交易方法 |
CN110134671A (zh) * | 2019-05-21 | 2019-08-16 | 北京物资学院 | 一种面向溯源应用的区块链数据库数据管理***及方法 |
CN110503558A (zh) * | 2019-08-29 | 2019-11-26 | 深圳前海微众银行股份有限公司 | 一种基于区块链***的处理方法及装置 |
CN110784346A (zh) * | 2019-10-18 | 2020-02-11 | 深圳供电局有限公司 | 一种基于信誉值的pbft共识***及方法 |
CN111507709A (zh) * | 2020-03-25 | 2020-08-07 | 农业农村部农药检定所(国际食品法典农药残留委员会秘书处) | 一种数据溯源*** |
CN111680049A (zh) * | 2020-05-15 | 2020-09-18 | 杭州趣链科技有限公司 | 一种基于区块链的物联网数据的处理方法及其处理装置 |
CN111782723A (zh) * | 2020-06-05 | 2020-10-16 | 成都链向科技有限公司 | 一种基于许可链的双层产品信息追溯***架构 |
CN111756546A (zh) * | 2020-06-15 | 2020-10-09 | 杭州电子科技大学 | 一种车联网环境下基于动态信誉机制的区块链共识方法 |
Non-Patent Citations (3)
Title |
---|
PARTHA PRATIM RAY等: "BLWN: Blockchain-Based Lightweight Simplified Payment Verification in IoT-Assisted e-Healthcare", 《IEEE SYSTEMS JOURNAL》 * |
乔蕊等: "基于联盟链的物联网动态数据溯源机制", 《软件学报》 * |
曹婷婷等: "面向区块链溯源应用的可信数据采集机制", 《网络空间安全》 * |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112866282A (zh) * | 2021-02-10 | 2021-05-28 | 中国人民银行数字货币研究所 | 区块链中时间信息验证方法和装置 |
CN112866282B (zh) * | 2021-02-10 | 2022-12-27 | 中国人民银行数字货币研究所 | 区块链中时间信息验证方法和装置 |
CN113239078A (zh) * | 2021-05-17 | 2021-08-10 | 国网河南省电力公司信息通信公司 | 一种基于联盟链的数据快速查询方法 |
CN113761065A (zh) * | 2021-08-27 | 2021-12-07 | 河南向量智能科技研究院有限公司 | 一种网状设计节点结构的呼应设计方法 |
CN113742384A (zh) * | 2021-09-09 | 2021-12-03 | 海南安迈云网络技术有限公司 | 一种基于区块链的数据读取方法 |
CN113923058A (zh) * | 2021-12-15 | 2022-01-11 | 武汉云麒联网科技有限公司 | 一种非即时能源数据分析的大数据预警方法与装置 |
CN113923058B (zh) * | 2021-12-15 | 2022-02-22 | 武汉云麒联网科技有限公司 | 一种非即时能源数据分析的大数据预警方法与装置 |
CN114760073A (zh) * | 2022-06-13 | 2022-07-15 | 湖南华菱电子商务有限公司 | 基于区块链的仓储商品配送方法、装置、电子设备及介质 |
CN114760073B (zh) * | 2022-06-13 | 2022-08-19 | 湖南华菱电子商务有限公司 | 基于区块链的仓储商品配送方法、装置、电子设备及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN112286963B (zh) | 2023-05-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112286963B (zh) | 一种区块链终端数据可信查询***及其实现方法 | |
US11663090B2 (en) | Method and system for desynchronization recovery for permissioned blockchains using bloom filters | |
CN110602148B (zh) | 一种区块的状态树的生成和链上数据验证的方法及装置 | |
US11265164B2 (en) | Method and system for an efficient consensus mechanism for permissioned blockchains using audit guarantees | |
CN111339106B (zh) | 一种区块链数据索引的方法 | |
CN109165224B (zh) | 一种在区块链数据库上针对关键字key的索引方法 | |
US20210243007A1 (en) | Maintaining blocks of a blockchain in a partitioned blockchain network | |
CN110599169B (zh) | 数据处理方法、装置、终端及介质 | |
CN109194646B (zh) | 一种基于区块链的安全认证数据存取方法 | |
CN109766389B (zh) | 一种基于位图索引的区块链轻客户端验证查询方法 | |
CN111444027B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
WO2021108258A1 (en) | Optimizations for verification of interactions system and method using probability density functions | |
CN111488396B (zh) | 业务数据区块链的数据同步方法及装置 | |
CN114281793A (zh) | 数据校验方法、装置和*** | |
CN114461673A (zh) | 一种基于链上-链下协同的区块链查询优化方法 | |
CN116894047A (zh) | 一种基于区块链的可验证溯源方法和装置 | |
CN114723564B (zh) | 一种区块链生成方法以及区块链结构 | |
CN116188167B (zh) | 一种基于dag结构的区块链***及共识方法 | |
CN116340418A (zh) | 一种预言机用多种账簿共识方法 | |
CN116663053A (zh) | 一种支持丰富检索的区块链高效可验证查询方法 | |
CN117931839A (zh) | 一种高效可验证地查询区块链中影响力最大交易的方法 | |
CN117931800A (zh) | 一种基于网格编码的区块链可验证reverse skyline查询方法 | |
CN114357081A (zh) | 一种网状结构的区块链构造方法 | |
CN115269586A (zh) | 一种基于多项式承诺机制的数据库索引的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |