CN111695123B - 一种面向区块链的降低冲突的乐观并发保序编码方法 - Google Patents
一种面向区块链的降低冲突的乐观并发保序编码方法 Download PDFInfo
- Publication number
- CN111695123B CN111695123B CN202010342292.2A CN202010342292A CN111695123B CN 111695123 B CN111695123 B CN 111695123B CN 202010342292 A CN202010342292 A CN 202010342292A CN 111695123 B CN111695123 B CN 111695123B
- Authority
- CN
- China
- Prior art keywords
- tree
- udz
- transaction
- node
- version number
- 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.)
- Active
Links
Images
Classifications
-
- 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/602—Providing cryptographic facilities or services
-
- 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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2246—Trees, e.g. B+trees
-
- 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
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Business, Economics & Management (AREA)
- Computer Hardware Design (AREA)
- Data Mining & Analysis (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Economics (AREA)
- General Business, Economics & Management (AREA)
- Medical Informatics (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种面向区块链的降低冲突的乐观并发保序编码方法,称为cr‑oOPE,显著降低了冲突交易数,提高了交易提交率和系统吞吐。首先本发明提出了随机化的保序编码,使得对不同明文的编码请求计算出相同编码的概率降低;其次提出一种未定区(UDZ)的结构,将编码不同但落到编码树上同样位置的树节点放到一个未定区,这样原本冲突的相关交易就可以被提交,由于未定区中的节点的编码是随机的,并不保序,因此等下一个编码请求遍历到了一个满了的未定区,再把其中的节点的编码重排,并且重组成字树插入到编码树上;然后,本发明提出了在基于未定区的编码树上进行的编码方法和执行方法;最后,本发明提出了在基于未定区的编码树上进行查询的方法。
Description
技术领域
本发明属于区块链技术领域,涉及到区块链中数据的隐私保护,具体是一种面向区块链的保序编码方法。
背景技术
区块链作为一种不可篡改、历史数据可追溯的分布式账本,具有广泛的应用领域,但在当前大多数的区块链系统(例如以太坊和Hyperledger Fabric)中,仅采用密码学签名来防止交易被篡改,交易内容仍以明文存储,所有参与者都可以看到。实际上,与其他数据共享方式相比,区块链的隐私保护问题在缺乏信任的参与者之间更为重要。
一种直接的隐私数据保护方法是直接对隐私数据加密,数据拥有者将隐私数据加密之后上传给区块链节点并转发到区块链网络中进行共识,数据在网络中得到共识之后数据以密文的形式保存在每个节点本地的区块链账本上。现有对数据加密的方式有多种,例如同态加密(HE),可搜索加密(SE)等,但这些加密方法效率较低,开销较大。
本发明采用更高效的保序加密,或者称为保序编码(OPE)。保序编码是一种编码方法,它的编码的排序顺序与相应的明文顺序相匹配,这种特性的优点是系统可以对编码执行与明文相同的排序操作,方便在编码上进行点查询和范围查询。OPE的理想安全性是IND-OCPA(indistinguishability under ordered chosen-plaintext attack,有序选择明文攻击下不可区分),即除了顺序之外,不会泄漏明文的任何信息。目前已经有很多实现这种安全性的保序编码方法。保序编码由于其具有高效,便于查询并且安全性较高的优点,被广泛应用于外包数据库中的隐私保护和加密数据库(CryptDB)等。
OPE通常被实现为一个保序的编码字典,这个字典可以存放在客户端或者服务端。传统的保序编码方法大多只适用于单客户端-单服务器模型,其中前提假设客户端是可信的,服务器是不可信的,服务器保存客户端上传的密文数据,并且除了顺序之外不知道明文的其他信息,而区块链是多客户端-多服务器模型;且传统的保序编码或者不考虑并发控制,或者建议使用细粒度的锁,这在区块链中非常低效,并且会有客户端宕机阻塞整个系统的风险;此外,与传统的数据库不同,区块链中的交易是分批执行的,所有的节点都必须执行交易,并且要获得相同的执行结果。因此现有的保序编码方法都不适用于区块链场景。
发明内容
本发明提出了一种面向区块链的降低编码冲突的乐观并发保序编码方法,该方法具体包括以下步骤:
步骤1:区块链网络中所有的节点初始化本地的ZOPE树;
步骤2:对需要上传的一条数据条目,数据拥有者将隐私字段的明文值x用密钥sk加密,将密文c发给区块链节点请求编码;
步骤3:节点对收到的密文计算保序编码;
步骤4:主节点收到数据拥有者发送的交易提案后,存储到本地的交易池中;
步骤5:主节点从交易池中取出固定数量的交易打包成区块,串行地预执行区块中的每一笔交易;
步骤6:主节点将没有冲突交易的区块在从节点之间进行投票共识,从节点对区块中的每一笔交易进行和主节点预执行一样的验证方法,如果区块链中存在有冲突的交易,就拒绝这次共识投票,否则就继续进行共识;
步骤7:经过共识的区块将被写入每个节点的本地账本,并且本地的ZOPE树也会被更新;
步骤8:授权查询用户在ZOPE树上对密文进行查询。
本发明所述步骤3具体包括:
步骤3-1:区块链节点与数据拥有者用交互式的方式遍历ZOPE树;
步骤3-2:如果遍历过程中区块链节点遇到一个满的UDZ,先用随机化的编码计算方法计算当前正在编的编码y,然后将c和y,连同这个UDZ中所有的节点一起发给数据拥有者请求排序这些节点;数据拥有者收到后重排这些节点,并且发起一笔TX_SORT类型的交易提案,其中隐私字段是密文,其他非隐私字段是明文,连同排好序的节点,ZOPE树上的路径和当前ZOPE树的版本号v_tree一起发给主节点;
步骤3-3:如果遍历过程中区块链节点发现ZOPE树需要重平衡,就将树中所有UDZ结构中的节点发给数据拥有者请求排序;数据拥有者收到后重排这些节点,并且发起一笔TX_UPD类型的交易提案,连同排好序的节点和当前的全局UDZ版本号v_udz一起发给主节点;
步骤3-4:如果最后遍历到一个空的位置,区块链节点就用随机化的编码计算方法计算当前正在编的编码y,并且发起一笔TX_ENC类型的交易提案,连同c和y,它在树上的路径和当前ZOPE树的版本号v_tree一起发给主节点。
本发明所述步骤5具体包括:
步骤5-1:如果交易类型是TX_SORT,首先获取交易中的版本号,与当前ZOPE树的版本号比较,如果不相等就直接中止这笔交易;如果相等,首先根据交易中的路径遍历到ZOPE树上的UDZ,然后根据重排好序的节点将这个UDZ重组,重组之后将全局的UDZ版本号加1;
步骤5-2:如果交易类型是TX_UPD,需要重平衡ZOPE树,首先获取交易中的UDZ版本号,与当前全局的UDZ版本号比较,如果不相等就直接中止这笔交易;如果相等就重平衡整个ZOPE树,然后全局的树版本号加1,全局的UDZ版本号加1;
步骤5-3:如果交易类型是TX_ENC,首先获取交易中的版本号,与当前ZOPE树版本号比较,如果不相等就直接中止这笔交易。如果相等,首先根据交易中的路径遍历到ZOPE树上应该写入的位置并且进行判断:如果这个位置上已经存在节点并且与要插入的编码不相等,就在这个位置创建一个UDZ,将已经存在的节点和要插入的节点放入这个UDZ中,然后全局的UDZ版本号加1;如果这个位置上已经有一个没有满的UDZ,并且其中没有编码与要插入的编码相等的节点,就把要插入的节点放入这个UDZ,然后全局的UDZ版本号加1;如果这个位置上是空,就直接将要插入的节点放在这个位置;否则就中止这笔交易。
本发明所述步骤8中包括点查询、范围查询和基于cache的范围查询;对这三种查询,区块链节点在查询过程中如果遇到了UDZ结构,不管是否已满,都需要在数据拥有者的协助下先重组UDZ,再继续查询,即在区块链节点遇到UDZ时,将UDZ发给数据拥有者,数据拥有者对UDZ中的节点重排序,将排好序的结果发回给区块链节点,区块链节点收到后重组UDZ为子树插入到ZOPE树上的对应位置,再继续查询。
本发明公开了一种面向区块链的降低冲突的乐观并发保序编码方法,称为cr-oOPE,显著降低了冲突交易数,提高了交易提交率和系统吞吐。首先本发明提出了随机化的保序编码,使得对不同明文的编码请求计算出相同编码的概率降低;其次提出一种未定区(UDZ)的结构,将编码不同但落到编码树上同样位置的树节点放到一个未定区,这样原本冲突的相关交易就可以被提交,由于未定区中的节点的编码是随机的,并不保序,因此等下一个编码请求遍历到了一个满了的未定区,再把其中的节点的编码重排,并且重组成字树插入到编码树上;然后,本发明提出了在基于未定区的编码树上进行的编码方法和执行方法;最后,本发明提出了在基于未定区的编码树(ZOPE树)上进行查询的方法。
附图说明
图1是保序编码示意图;
图2是本发明的系统架构图;
图3是本发明的保序编码方案的两个阶段;
图4是本发明中编码的两种冲突SCC和UC;
图5是和图6是本发明中乐观并发编码方案oOPE的实施例;
图7是本发明提出的ZOPE树结构;
图8是基于冲突消减方法的保序编码方案cr-oOPE的实施例;
图9是实现的不同系统下写性能与输入数据集大小的关系;
图10是实现的不同系统下写性能与区块大小的关系;
图11是实现的不同系统下写性能与编码线程数的关系;
图12是基于冲突消减的系统的写性能与未定区容量的关系;
图13是并发进行范围查询和基于cache的范围查询分别在实现的不同系统中,并且在两种结果集下的吞吐和延时。
具体实施方式
结合以下具体实施例和附图,对本方法进行详细的介绍。实施本方法的整体过程、条件、实验方法等,除以下专门提及的内容之外,均为本领域的公知常识,本发明没有对内容进行特别的限制。
本发明提出了一种针对区块链隐私保护的保序编码方法,称为oOPE。设计包括三种角色:1)数据拥有者,2)区块链节点,3)查询用户。数据拥有者维护一个安全密钥来加密数据集的敏感字段,并将加密的数据条目发送到区块链节点请求保序编码。保序编码通常被实现为一个保序的编码树,称为OPE树,存储在客户端或者服务器上,为了使得保序编码在所有的参与者之间共享,本发明将字典维护在每个区块链节点上,字典中维护了<密文,保序编码>对。本发明中将字典实现为一棵二叉排序树,称为OPE树,OPE树可以看作是区块链中交易的索引。查询用户从区块链节点查询数据,如果要在密文上查询,需要得到数据拥有者的授权,授权的查询用户与数据拥有者共享相同的密钥,用加密的密文发起查询,并解密返回的结果集。系统架构如图2所示。需要说明的是,设明文域大小为M,编码域大小为N,为了提高安全性,N要远大于M。
为了提高系统吞吐,本发明并发地进行编码,基于锁的并发控制协议较为低效,并且如果客户端宕机会导致整个系统阻塞,因此本发明提出了乐观并发编码方案,包含两个阶段,并发编码阶段和冲突消解阶段,如图3所示:
在并发编码阶段,数据拥有者和区块链节点交互式并且并发地对数据集的隐私字段进行编码,区块链节点将计算出的编码回复给数据拥有者,数据拥有者组织成一笔交易,其中隐私字段是密文,其他字段是明文,然后向主节点发起交易提案。由于编码过程依赖于OPE树中的数据项,因此冲突不可避免。冲突包括两种:1)对不同密文的编码请求在OPE树上有相同的遍历路径,因此算出了相同的编码,如图4(a)所示,这种冲突称为SCC(same codeconflict);2)在处理一个编码请求期间,或者在写入一个树节点之前,OPE树可能执行了更新操作,使得树上所有的编码都改变了,因此这个编码请求算出的编码也不正确了,如图4(b)和图4(c)所示,这种冲突称为UC(update conflict)。
因此在冲突消解阶段,主节点收集数据拥有者发起的交易,打包区块,进行预执行,检测冲突的交易并且剔除。对于第一种冲突(SCC),解决办法是检测一笔TX_ENC类型的交易应该在OPE树上写入的位置上是否已经存在了节点,如果有就中止;对于第二种冲突(UC),对OPE树设置一个全局的版本号v_tree,并初始化为0,每次重平衡就把版本号加1,在数据拥有者发送TX_ENC类型的交易提案给区块链节点的时候连同编码时的OPE树版本号一起发送,然后在执行这笔交易的时候检查这个版本号和当前树的版本号是否相等,如果不相等就中止这笔交易。然后将没有冲突的区块在所有节点中进行共识,收到区块的从节点用同样的检测方法验证区块,如果区块中仍有冲突,说明主节点是恶意节点,因此拒绝投票,否则就继续运行共识算法对这个区块达成共识,写入本地账本。
本发明提出的乐观并发保序编码方法oOPE具体包括以下步骤:
步骤1:区块链网络中所有的节点初始化本地的OPE树;
步骤2:数据拥有者将数据条目的隐私字段的明文加密,将密文发给区块链节点请求编码;
步骤3:区块链节点对收到的密文计算保序编码,由于区块链节点不能知道明文,因此在对密文数据进行保序编码需要与数据拥有者进行交互判断大小来遍历OPE树。交互式地计算保序编码的过程具体包括以下步骤:
步骤3-1:区块链节点先将OPE树根节点的密文发给数据拥有者;
步骤3-2:数据拥有者解密之后与要编码的明文比较大小,根据比较结果请求根节点的左孩子或者右孩子;
步骤3-3:循环步骤3-1和步骤3-2直到到达OPE树上的一个空位置或者在OPE树上找到了要编码的密文;
步骤3-4:取OPE树上所有节点的连续的有序序列中,计算对应的明文比x小的和对应的明文比x大的两个相邻的编码的中值作为x的保序编码,并且将结果回复给数据拥有者。如果没有整数可以作为编码,即计算两个编码中值的时候,这两个编码的差为1,说明OPE树需要更新,于是向数据拥有者发送更新消息。
步骤4:数据拥有者收到区块链节点发来的编码结果之后,发起一笔TX_ENC类型的交易提案;如果数据拥有者收到的是重平衡消息,就发起一笔TX_UPD类型的交易提案给主节点;
步骤5:主节点收到数据拥有者发送的交易提案后,存储到本地的交易池中;
步骤6:主节点从交易池中取出固定数量的交易打包成区块,串行地预执行区块中的每一笔交易,具体包括以下步骤:
步骤6-1:如果交易类型是TX_ENC,先检查OPE树的版本号从计算编码时到现在是否改变,如果改变就直接中止这笔交易,否则检查OPE树上应该写入的位置是否已经存在节点,如果是就中止这笔交易,否则就将交易中的<密文,编码>对写到树上;
步骤6-2:如果交易类型是TX_UPD,就重平衡OPE树,即更新所有树上的编码,产生(临时)平衡的树,然后全局的树版本号加1;
步骤7:主节点将没有冲突交易的区块在从节点之间进行投票共识,从节点对区块中的每一笔交易进行和主节点预执行一样的验证方法,如果区块链中存在有冲突的交易,说明主节点作恶,就拒绝这次共识投票,否则就继续进行共识;
步骤8:经过共识的区块将被写入每个节点的本地账本,并且本地的OPE树也会被更新。
针对授权查询用户在OPE树密文上的查询,本发明提出了处理点查询和范围查询方法,由于区块链节点不知道密文,因此查询过程中依然需要区块链节点和授权查询用户交互。点查询需要遍历一次OPE树,范围查询的方法是先遍历两次OPE树找到两个查询范围,然后返回之间的所有结果。为了提高范围查询的效率,本发明提出了一种基于cache的查询方法,在授权查询用户的本地维护一张cache表,表中存放若干明文-编码对,根据OPE树上的记录数,按顺序每隔固定的间隔记录一个,基于cache的OPE树上的范围查询具体包括以下步骤:
步骤1:授权查询用户先在cache中找到刚好覆盖查询范围的两条条目,之后发送两个条目对应的编码给区块链节点;
步骤2:区块链节点本地直接根据编码查询,不需要任何交互,然后把结果集返回给授权查询用户;
步骤3:授权查询用户再解密结果集,本地过滤掉不满足查询范围的交易。
为了降低上面所说的冲突,本发明提出了基于冲突消减的方案,称为cr-oOPE。主要思想如下:
首先,本发明随机化编码的计算方法,即在原来的编码方法后加上一个随机数。设x是要编码的明文值,v1和v2是遍历OPE树的路径上的有序排列的节点中使得对应的明文x1和x2满足x1≤x≤x2的两个节点,并且v1和v2的编码为y1和y2,如果y2和y1的差不为1,此时x的编码y的计算方式为:其中,ε是服从正态分布的一个随机数,且数学期望是
其次,虽然编码随机化降低了不同明文计算出相同编码的概率,但是由于OPE树是二叉排序树,因此在计算过程中用y1和y2计算编码的节点仍需要插入到OPE树中的相同位置,这并没有降低冲突。为了解决这个问题,本发明提出一种未定区(undecided zone,简称UDZ)的概念,UDZ中可以放入多个树节点,它们的编码是不保序的但都在某个范围内,即y1和y2之间。本发明将UDZ的结构放到OPE树的叶节点,并且称具有UDZ结构的OPE树为ZOPE树。ZOPE树的结构如图7所示:一个树节点的左孩子可以是一个树节点或一个UDZ,右孩子也是如此。UDZ既没有左孩子也没有右孩子,因此UDZ只能作为ZOPE树的叶子。通过UDZ这种结构,原本需要插入到OPE树中的相同位置但编码不同的树节点就可以被放入一个UDZ中,相关交易就都可以提交,不用被中止掉。
再次,UDZ中不能无限放入节点,因此需要限制容量。当一个UDZ已经放满了节点,其他落入这个UDZ的树节点相关的交易仍然需要被中止。当某个编码请求在遍历ZOPE树时遇到了一个已满的UDZ,区块链节点就需要将这个UDZ重组成子树挂到ZOPE树上,这需要数据拥有者的协助,因为UDZ中的编码是随机的且不保序,因此需要对这个UDZ中的树节点重排序,即给每个密文分配对应的编码,然后将排好序的结果发给区块链节点以进行重组。如果ZOPE树需要重平衡,区块链节点先将树上所有的UDZ中的节点重组后再重平衡,这也需要数据拥有者的帮助,即区块链节点就将所有UDZ中的节点发给数据拥有者,数据拥有者对这些节点进行排序,将排好序的节点发回给区块链节点,区块链节点再进行重组。
最后,由于在区块链节点发送所有UDZ给数据拥有者之后,并且在执行重平衡类型的交易之前,树上的UDZ结构可能会改变,比如某些重组了,某些新放入了节点,这样执行重平衡的时候,重排好的所有UDZ的节点就不正确了。因此,为了在执行时进行验证,除了上文提到的树版本号v_tree,还需要对所有的UDZ定义一个全局的版本号v_udz,并初始化为0,每次ZOPE树上有UDZ发生了改变,版本号就加1,重平衡之前先检验UDZ版本号有没有改变,如果没有变才可以重平衡。此外,为了防止多个编码请求重排同一个UDZ结构,造成执行时不必要的大量中止交易,因此在某个编码请求发现一个满的UDZ时,就锁住它的父节点,锁住期间别的编码请求不能访问这个节点,直到UDZ已经重组好再释放锁。
本发明提出的降低编码冲突的乐观并发保序编码方法cr-oOPE具体包括以下步骤:
步骤1:区块链网络中所有的节点初始化本地的ZOPE树;
步骤2:数据拥有者将数据条目的隐私字段的明文加密,将密文发给区块链节点请求编码;
步骤3:节点对收到的密文计算保序编码,编码过程具体包括以下步骤:
步骤3-1:区块链节点与数据拥有者用交互式的方式遍历ZOPE树;
步骤3-2:如果遍历过程中区块链节点遇到一个满的UDZ,先用随机化的编码计算方法计算当前正在编的编码,然后将计算的结果连同这个UDZ中所有的节点一起发给数据拥有者请求排序这些节点;数据拥有者收到后重排这些节点,并且发起一笔TX_SORT类型的交易提案给主节点;
步骤3-3:如果遍历过程中区块链节点发现ZOPE树需要重平衡,就将树中所有UDZ结构中的节点发给数据拥有者请求排序;数据拥有者收到后重排这些节点,并且发起一笔TX_UPD类型的交易提案给主节点;
步骤3-4:如果最后遍历到一个空的位置,区块链节点就用随机化的编码计算方法计算当前正在编的编码,并且发起一笔TX_ENC类型的交易提案给主节点;
步骤4:主节点收到数据拥有者发送的交易提案后,存储到本地的交易池中;
步骤5:主节点从交易池中取出固定数量的交易打包成区块,串行地预执行区块中的每一笔交易,具体包括以下步骤:
步骤5-1:如果交易类型是TX_SORT,首先检查ZOPE树的版本号从UDZ发给数据拥有者后到现在是否改变,如果改变就直接中止这笔交易,否则根据重排好序的节点将这个UDZ重组,重组之后将全局的UDZ版本号加1;
步骤5-2:如果交易类型是TX_UPD,需要重平衡ZOPE树,首先检查全局UDZ的版本号从所有UDZ发给数据拥有者后到现在是否改变,如果改变就直接中止这笔交易,否则重平衡整个ZOPE树,然后全局的树版本号加1,全局的UDZ版本号加1;
步骤5-3:如果交易类型是TX_ENC,首先检查ZOPE树的版本号从编码时到现在是否改变,如果改变就直接中止这笔交易,否则检查ZOPE树上应该写入的位置:如果这个位置上已经存在节点并且与要插入的编码不相等,就在这个位置创建一个UDZ,将已经存在的节点和要插入的节点放入这个UDZ中,然后全局的UDZ版本号加1;如果这个位置上已经有一个没有满的UDZ,并且其中没有编码与要插入的编码相等的节点,就把要插入的节点放入这个UDZ,然后全局的UDZ版本号加1;如果这个位置上是空,就直接将要插入的节点放在这个位置;否则就中止这笔交易;
步骤6:主节点将没有冲突交易的区块在从节点之间进行投票共识,从节点对区块中的每一笔交易进行和主节点预执行一样的验证方法,如果区块链中存在有冲突的交易,说明主节点作恶,就拒绝这次共识投票,否则就继续进行共识;
步骤7:经过共识的区块将被写入每个节点的本地账本,并且本地的ZOPE树也会被更新。
在ZOPE树上的点查询、范围查询和基于cache的范围查询和OPE树类似,不同之处在于,如果区块链节点在查询过程中遇到了UDZ结构,不管是否已满,都需要在数据拥有者的协助下先重组UDZ,再继续查询。
实施例1
本实施例提出的乐观并发保序编码方法oOPE具体包括以下步骤:
步骤1:区块链网络中所有的节点初始化本地的OPE树;
步骤2:对需要上传的一条数据条目,数据拥有者将隐私字段的明文值加密后,将密文发给区块链节点请求编码;
步骤3:区块链节点对收到的密文计算保序编码,由于区块链节点不能知道明文,因此在对密文数据进行保序编码需要与数据拥有者进行交互判断大小来遍历OPE树。交互式的编码过程具体包括以下步骤:
步骤3-1:如果根节点为空,直接计算-1和N的中值作为编码发送给数据拥有者;否则区块链节点将OPE树的根节点的密文c’发给数据拥有者;
步骤3-2:数据拥有者收到根节点的密文c’后,解密得到根节点的明文x’,并与要进行编码的值x进行比较,将比较结果发送给区块链节点;
步骤3-3:如果x>x’,区块链节点向数据拥有者发送OPE树中根节点的右子节点的密文;如果x<x’则发送左子节点的密文;如果x=x’,则直接将根节点的编码返回给数据拥有者,否则跳转到步骤3-4;
步骤3-4:如果OPE树中没有明文与x相等的节点,数据拥有者与区块链节点就重复步骤3-2和步骤3-3中的交互式过程,直到区块链节点遍历到OPE树中的一个空位置。设有两个节点v1,v2是遍历路径上的有序排列的节点中使得对应的明文x1和x2满足x1≤x≤x2的两个节点,设v1的编码为y1,v2的编码为y2,如果y2和y1的差不为1,就计算y1和y2的中值作为x的编码y,即并返回y给数据拥有者,否则就跳转到步骤3-5;
步骤3-5:y2与y1之差为1,说明编码域没有足够的空间进行编码,需要更新整棵OPE树使得编码分布更均匀,于是发给数据拥有者需要更新的消息。
步骤4:数据拥有者收到区块链节点发来的编码结果之后,发起一笔TX_ENC类型的交易提案,其中隐私字段是密文,其他非隐私字段是明文,包括计算好的保序编码,它在树上的路径和当前OPE树的版本号一起发给主节点;如果数据拥有者收到的是更新消息,就发起一笔TX_UPD类型的交易提案给主节点;
步骤5:主节点收到数据拥有者发送的交易提案后,存储到本地的交易池中;
步骤6:主节点从交易池中取出固定数量的交易打包成区块,串行地预执行区块中的每一笔交易,具体包括以下步骤:
步骤6-1:如果交易类型是TX_ENC,首先获取交易中的版本号,与当前OPE树的版本号比较,如果不相等就直接中止这笔交易。如果相等,首先根据交易中的路径遍历到OPE树上应该写入的位置,如果这个位置上已经存在节点,就中止这笔交易,否则就将交易中的密文-编码对写到树上;
步骤6-2:如果交易类型是TX_UPD,需要重平衡OPE树,重平衡会更新所有树上的编码,先初始化OPE树为两个边界节点,然后按顺序重新编码所有(不同的)密文,编码按照一样的计算方法,即计算连续序列中明文比当前明文小的和比当前明文大的对应的两个编码的中值,先编OPE树上所有节点中按顺序中间的值,再编左边序列中的中值,然后是右边序列中的中值,依此类推,是一个递归的过程,最后产生了(临时)平衡的树。需要说明的是,数据拥有者不需要参与重新平衡,即使区块链节点不知道明文值,也可以在不涉及任何交互的情况下执行重平衡,因为它只需要知道树节点的顺序信息,而该信息已经可以从树中获得;
步骤7:主节点将没有冲突交易的区块在从节点之间进行投票共识,从节点对区块中的每一笔交易进行和主节点预执行一样的验证方法,如果区块链中存在有冲突的交易,说明主节点作恶,就拒绝这次共识投票,否则就继续进行共识;
步骤8:经过共识的区块将被写入每个节点的本地账本,并且本地的OPE树也会被更新。
当一个授权查询用户需要在密文上进行查询时,本实施例提出了处理点查询和范围查询到方法,由于区块链节点不能知道密文,因此查询过程中依然需要区块链节点和授权查询用户交互。为了提高范围查询的效率,本方法提出了一种基于cache的查询方法。
OPE树上的点查询具体包括以下步骤:
步骤1:授权查询用户加密要查询的明文,并将密文发送给区块链节点;
步骤2:区块链节点向授权查询用户发送OPE树的根节点对密文;
步骤3:授权查询用户解密根节点的密文,并与要查询的明文值比较,将比较结果发送给区块链节点,区块链节点根据比较结果发送根节点的左孩子或者右孩子的密文。重复上述交互过程直到找到查询的值,然后将对应的交易放入结果集返回给授权查询用户;如果没有找到,返回空结果集给授权查询用户;
对于OPE树上的范围查询,方法与点查询类似,授权查询用户向区块链节点发起对两个范围边界的明文为xl和xr的查询,区块链节点用类似点查询的交互式方法查询,获得两个树节点v1和v2,使得v1对应的明文满足大于xl中最小的,v2对应的明文是满足小于xr中最大的,然后区块链节点将v1和v2之间所有的节点对应的交易放入结果集,返回给授权查询用户。
对于基于cache的OPE树上的范围查询,方法是在授权查询用户的本地维护一张cache表,表中存放着若干明文-编码对,根据OPE树上的记录数,按顺序每隔固定的间隔记录一个,基于cache的OPE树上的范围查询具体包括以下步骤:
步骤1:设范围查询的明文为[xl,xr],授权查询用户首先在本地的cache表中查找两个条记录e1和e2,使得e1的明文是满足小于xl中最大的,e2的明文是满足大于xr中最小的,然后将e1的编码和e2的编码发送给区块链节点;
步骤2:区块链节点收到两个编码后直接在OPE树上进行范围查询,不需要与授权查询用户交互,然后满足两个编码范围内的相应交易有序地放在结果集中返回给授权查询用户;
步骤3:授权查询用户收到结果集之后,解密密文,从两边开始遍历,过滤掉不满足查询范围的交易,直到遍历到满足条件的交易。
实施例2
本实施例提出的降低编码冲突的乐观并发保序编码方法cr-oOPE具体包括以下步骤:
步骤1:区块链网络中所有的节点初始化本地的ZOPE树;
步骤2:对需要上传的一条数据条目,数据拥有者将隐私字段的明文值x用密钥sk加密,将密文c发给区块链节点请求编码;
步骤3:节点对收到的密文计算保序编码,编码过程具体包括以下步骤:
步骤3-1:区块链节点与数据拥有者用交互式的方式遍历ZOPE树;
步骤3-2:如果遍历过程中区块链节点遇到一个满的UDZ,先用随机化的编码计算方法计算当前正在编的编码y,然后将c和y,连同这个UDZ中所有的节点一起发给数据拥有者请求排序这些节点;数据拥有者收到后重排这些节点,并且发起一笔TX_SORT类型的交易提案,其中隐私字段是密文,其他非隐私字段是明文,连同排好序的节点,ZOPE树上的路径和当前ZOPE树的版本号v_tree一起发给主节点;
步骤3-3:如果遍历过程中区块链节点发现ZOPE树需要重平衡,就将树中所有UDZ结构中的节点发给数据拥有者请求排序;数据拥有者收到后重排这些节点,并且发起一笔TX_UPD类型的交易提案,连同排好序的节点和当前的全局UDZ版本号v_udz一起发给主节点;
步骤3-4:如果最后遍历到一个空的位置,区块链节点就用随机化的编码计算方法计算当前正在编的编码y,并且发起一笔TX_ENC类型的交易提案,连同c和y,它在树上的路径和当前ZOPE树的版本号v_tree一起发给主节点;
步骤4:主节点收到数据拥有者发送的交易提案后,存储到本地的交易池中;
步骤5:主节点从交易池中取出固定数量的交易打包成区块,串行地预执行区块中的每一笔交易,具体包括以下步骤:
步骤5-1:如果交易类型是TX_SORT,首先获取交易中的版本号,与当前ZOPE树的版本号比较,如果不相等就直接中止这笔交易。如果相等,首先根据交易中的路径遍历到ZOPE树上的UDZ,然后根据重排好序的节点将这个UDZ重组,重组之后将全局的UDZ版本号加1;
步骤5-2:如果交易类型是TX_UPD,需要重平衡ZOPE树,首先获取交易中的UDZ版本号,与当前全局的UDZ版本号比较,如果不相等就直接中止这笔交易。如果相等就更新整个ZOPE树,然后全局的树版本号加1,全局的UDZ版本号加1。由于非UDZ中节点的序是可以知道的,所有UDZ中的节点的序根据交易中重排好的结果也是可以知道的,因此更新过程不需要再与数据拥有者进行任何交互;
步骤5-3:如果交易类型是TX_ENC,首先获取交易中的版本号,与当前ZOPE树版本号比较,如果不相等就直接中止这笔交易。如果相等,首先根据交易中的路径遍历到ZOPE树上应该写入的位置并且进行判断:如果这个位置上已经存在节点并且与要插入的编码不相等,就在这个位置创建一个UDZ,将已经存在的节点和要插入的节点放入这个UDZ中,然后全局的UDZ版本号加1;如果这个位置上已经有一个没有满的UDZ,并且其中没有编码与要插入的编码相等的节点,就把要插入的节点放入这个UDZ,然后全局的UDZ版本号加1;如果这个位置上是空,就直接将要插入的节点放在这个位置;否则就中止这笔交易;
步骤6:主节点将没有冲突交易的区块在从节点之间进行投票共识,从节点对区块中的每一笔交易进行和主节点预执行一样的验证方法,如果区块链中存在有冲突的交易,说明主节点作恶,就拒绝这次共识投票,否则就继续进行共识;
步骤7:经过共识的区块将被写入每个节点的本地账本,并且本地的ZOPE树也会被更新。
在ZOPE树上的点查询、范围查询和基于cache的范围查询和OPE树类似,不同之处在于,如果区块链节点在查询过程中遇到了UDZ结构,不管是否已满,都需要在数据拥有者的协助下先重组UDZ,再继续查询,即在区块链节点遇到UDZ时,将UDZ发给数据拥有者,数据拥有者对UDZ中的节点重排序,将排好序的结果发回给区块链节点,区块链节点收到后重组UDZ为子树插入到ZOPE树上的对应位置,再继续查询。
实施例3
本实施例是对数据集的隐私字段进行保序编码的编码方法。图5是4条数据集,其中Glucose是隐私字段。为了方便说明,设明文域大小M=8,编码域大小N=16,当前OPE树如图6(a)所示。在并发编码阶段,数据拥有者对4条记录的隐私字段的明文进行编码,以6.3为例,首先数据拥有者将6.3加密为x18ce并发送给区块链节点,区块链节点将OPE树根节点发给数据拥有者解密,数据拥有者比较解密后的4.8与6.3的大小关系,向区块链节点请求根节点的右孩子,循环这个步骤,明文6.3计算出编码14。同时,明文7.5也计算出编码14。在计算4.4的编码时,发现树需要更新。然后计算3.6的编码得出1。数据拥有者得到这些结果后发起交易提案tx1,tx2,tx3和tx4。编码阶段之后的OPE树如图6(b)所示,需要注意的是这些结果都没有写到树上,因为交易都还没有执行。
在冲突消解阶段,主节点预执行上述4笔交易,设执行顺序为tx1,tx2,tx3,tx4。tx1被成功执行后,再执行tx2时检测到应该写入的位置已经有了节点,如图6(c)所示,因此中止tx2。tx3更新树之后,树的版本号更新为1,执行tx4时检测到树的版本号改变了,如图6(d)所示,因此中止tx4。
实施例4
本实施例是基于ZOPE树的上传数据集的方法。设当前的ZOPE树如图8(a)所示,UDZ的容量为2。在并发编码阶段,对明文5.6的编码过程中,区块链节点遍历到节点<x217c,12>的左边,并且用随机化的编码计算方法得到编码11,同时,另一个对明文5.8的编码请求遍历到了同样的位置,计算出了编码9,如图8(b)所示。在冲突消解阶段,这两个节点被放入一个UDZ中,如图8(c)所示。后来在对明文4.9进行编码时,也遍历到了节点<x217c,24>的左边,并且检测到了这个满的UDZ,因此首先用随机化编码计算方法算出4.9对应的编码10,然后将三个节点<x613b,11>,<x78fa,9>和<x972e,10>发给数据拥有者请求重排序,得到正确的编码,即<x613d,10>,<x78fa,11>和<x972e,9>,在执行tx3时,将这三个树节点重组为子树插入到ZOPE树中,如图8(d)所示。
实施例5
本实施例是在OPE树上基于cache的范围查询方法。设明文域大小为8,密文域大小为16,授权查询用户本地cache的间隔大小为2,即按明文顺序每2条交易记录存一条cache条目。设区块链节点上存有8条交易记录,则授权查询用户本地cache中有3条条目,设分别为(4.2,4),(4.8,8)和(6.3,12)。此时授权查询用户需要查询明文范围在5到6的交易,首先在本地cache中查找刚好能覆盖查询范围的两条条目,即(4.8,8)和(6.3,12),于是将编码8和12发给区块链节点,区块链节点在本地查找编码范围在8到12之间的交易,且不需要任何交互,然后将结果集返回给授权查询用户,授权查询用户收到结果集后本地解密,过滤掉不在查询范围中的交易。
实施例6(实验验证)
本实施例基于Fabric0.6中使用的PBFT实现了区块链系统的原型,称为miniBC,然后本发明将串行的保序编码方案与miniBC集成,称为OPEBC,然后本发明将提出的oOPE方案与miniBC集成在一起,称为OPEBC+,最后本发明将提出的cr0oOPE方案与miniBC集成在一起,称为OPEBC++,比较这四个系统的读写性能,验证发明的有效性。在miniBC中,数据拥有者发起的所有交易都可以被提交,平均执行时间设置为与OPEBC相同。明文域大小M为65536,实际应用中,为了较好的安全性和性能,密文域大小N通常设置为远大于明文域大小,本实施例中将密文域大小设置为为655363,且实验证明基本上不会出现更新操作。在串行方案的OPEBC中,只有一个线程编码,并且只有编完一个值并且提交之后才能编下一个值,因此区块大小总是1。此外,只有OPEBC+和OPEBC++才会有中止的交易,另外两个系统中的交易都能全部提交。
图9展示了三个系统的写性能与输入数据集大小的关系,其中编码线程数固定为16,区块大小固定为600(每个区块600条交易),对于OPEBC+,固定UDZ的容量为200。额外的加解密和交互式的编码必然会对系统带来性能上的损失,因此miniBC是四个系统中吞吐最高的。但本发明提出的乐观并发编码方案还是要比串行的编码性能好得多,且性能基本满足大部分应用的需求,并且OPEBC++由于能够提交更多的交易,性能比OPEBC+好得多。此外,随着输入数据集大小的增加,OPEBC+和OPEBC++的吞吐量会先增加,然后在达到峰值后缓慢下降,这是因为编码树的高度也会增加,因此通信开销也增加了。
图10展示了三个系统的写性能与区块大小的关系,其中编码线程数固定为16,输入数据集大小固定为8192,对于OPEBC+,固定UDZ的容量为200。当区块大小较小时,共识发生的次数更多,执行交易的速度也更低,冲突也更多,因此miniBC,OPEBC和OPEBC+的吞吐量都较低。随着区块大小增加,交易执行速度也增加,三个系统的吞吐量都会提高,并逐渐趋于稳定。理所当然地,miniBC由于不需要编码,吞吐是最高的,且OPEBC++由于交易提交率高,吞吐总是比OPEBC高。
图11展示了三个系统的写性能与编码线程数的关系,其中区块大小固定为600,输入数据集大小固定为8192,对于OPEBC+,固定UDZ的容量为200。随着编码线程数的增加,编码速度加快,三个系统的吞吐量都会增加。但是,当线程数足够大时,线程切换会导致大量开销,因此吞吐量会下降。同时,miniBC的性能仍然是最好的,且OPEBC++总是比OPEBC+好。
图12展示了OPEBC++的性能与UDZ容量的关系,其中编码线程数固定为16,区块大小固定为600,输入数据集大小固定为8192。当UDZ容量较小时,可以提交的冲突交易不多,因此吞吐较低,中止交易数较多。随着UDZ容量的增加,系统可以提交更多的冲突交易,因此吞吐会更高。但是,UDZ容量的持续增加也会对性能产生不利影响,每次区块链节点重排序UDZ时,都需要先解密UDZ中所有节点的密文,然后对密文和明文进行排序,产生较大的开销,因此,随着UDZ容量不断增大,吞吐量会降低并且中止交易数会增加。
图13展示了并发进行范围查询(RQ)和基于cache的范围查询(RQC)分别在OPEBC+和OPEBC++上,并且在两种结果集(RS1=2000,RS2=4000)下的吞吐和延时。
基于缓存的范围查询由于在遍历编码树时不需要进行交互,大大降低了网络开销,因此要比没有缓存的范围查询性能好得多,同时,OPEBC+的查询性能比OPEBC++更好,这是因为在OPEBC++中,用户的查询覆盖一个满的UDZ时需要重新排列这个UDZ。
此外,随着线程数的增加,两种查询的吞吐都会增加到一个峰值,然后缓慢下降,而延时则保持增长,这是因为线程切换的开销随线程数的增加而增长。最后,当结果集大小较大时,吞吐量会降低,等待时间会增加。
注意到查询吞吐量比写入吞吐量稍差,这是因为在查询期间,树的高度始终很高,而在插入数据时,树的高度在一开始较低。并且,对于范围查询,它需要查询两个边界值,要遍历两次树,而插入只需遍历一次。
本发明的保护内容不局限于以上实施例。在不背离发明构思的精神和范围下,本领域技术人员能够想到的变化和优点都被包括在本发明中,并且以所附的权利要求书为保护范围。
Claims (2)
1.一种面向区块链的降低编码冲突的乐观并发保序编码方法,其特征在于,该方法具体包括以下步骤:
步骤1:区块链网络中所有的节点初始化本地的ZOPE树;
步骤2:对需要上传的一条数据条目,数据拥有者将隐私字段的明文值x用密钥sk加密,将密文c发给区块链节点请求编码;
步骤3:节点对收到的密文计算保序编码;所述步骤3具体包括以下子步骤:
步骤3-1:区块链节点与数据拥有者用交互式的方式遍历ZOPE树;
步骤3-2:如果遍历过程中区块链节点遇到一个满的UDZ,先用随机化的编码计算方法计算当前正在编的编码y,然后将c和y,连同这个UDZ中所有的节点一起发给数据拥有者请求排序这些节点;数据拥有者收到后重排这些节点,并且发起一笔TX_SORT类型的交易提案,其中隐私字段是密文,其他非隐私字段是明文,连同排好序的节点,ZOPE树上的路径和当前ZOPE树的版本号v_tree一起发给主节点;
步骤3-3:如果遍历过程中区块链节点发现ZOPE树需要重平衡,就将树中所有UDZ结构中的节点发给数据拥有者请求排序;数据拥有者收到后重排这些节点,并且发起一笔TX_UPD类型的交易提案,连同排好序的节点和当前的全局UDZ版本号v_udz一起发给主节点;
步骤3-4:如果最后遍历到一个空的位置,区块链节点就用随机化的编码计算方法计算当前正在编的编码y,并且发起一笔TX_ENC类型的交易提案,连同c和y,它在树上的路径和当前ZOPE树的版本号v_tree一起发给主节点;
步骤4:主节点收到数据拥有者发送的交易提案后,存储到本地的交易池中;
步骤5:主节点从交易池中取出固定数量的交易打包成区块,串行地预执行区块中的每一笔交易;所述步骤5具体包括以下子步骤:
步骤5-1:如果交易类型是TX_SORT,TX_SORT类型的交易提案是指:隐私字段是密文,其他非隐私字段是明文,连同排好序的节点,ZOPE树上的路径和当前ZOPE树的版本号一起发送的交易;首先获取交易中的版本号,与当前ZOPE树的版本号比较,如果不相等就直接中止这笔交易;如果相等,首先根据交易中的路径遍历到ZOPE树上的UDZ,所述UDZ中可以放入多个树节点,它们的编码是不保序的但都在某个范围内;然后根据重排好序的节点将这个UDZ重组,重组之后将全局的UDZ版本号加1;
步骤5-2:如果交易类型是TX_UPD,需要重平衡ZOPE树;TX_UPD类型的交易提案是指:连同排好序的节点和当前的全局UDZ版本号一起发送的交易;首先获取交易中的UDZ版本号,与当前全局的UDZ版本号比较,如果不相等就直接中止这笔交易;如果相等就重平衡整个ZOPE树,然后全局的树版本号加1,全局的UDZ版本号加1;
步骤5-3:如果交易类型是TX_ENC,TX_ENC类型的交易提案是指:隐私字段是密文,其他非隐私字段是明文,包括计算好的保序编码,它在树上的路径和当前ZOPE树的版本号一起发送的交易;首先获取交易中的版本号,与当前ZOPE树版本号比较,如果不相等就直接中止这笔交易;如果相等,首先根据交易中的路径遍历到ZOPE树上应该写入的位置并且进行判断:如果这个位置上已经存在节点并且与要插入的编码不相等,就在这个位置创建一个UDZ,将已经存在的节点和要插入的节点放入这个UDZ中,然后全局的UDZ版本号加1;如果这个位置上已经有一个没有满的UDZ,并且其中没有编码与要插入的编码相等的节点,就把要插入的节点放入这个UDZ,然后全局的UDZ版本号加1;如果这个位置上是空,就直接将要插入的节点放在这个位置;否则就中止这笔交易;
步骤6:主节点将没有冲突交易的区块在从节点之间进行投票共识,从节点对区块中的每一笔交易进行和主节点预执行一样的验证方法,如果区块链中存在有冲突的交易,就拒绝这次共识投票,否则就继续进行共识;
步骤7:经过共识的区块将被写入每个节点的本地账本,并且本地的ZOPE树也会被更新;
步骤8:授权查询用户在ZOPE树上对密文进行查询。
2.根据权利要求1中所述的保序编码方法,其特征在于,所述步骤8中包括点查询、范围查询和基于cache的范围查询;对这三种查询,区块链节点在查询过程中如果遇到了UDZ结构,不管是否已满,都需要在数据拥有者的协助下先重组UDZ,再继续查询,即在区块链节点遇到UDZ时,将UDZ发给数据拥有者,数据拥有者对UDZ中的节点重排序,将排好序的结果发回给区块链节点,区块链节点收到后重组UDZ为子树插入到ZOPE树上的对应位置,再继续查询。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010342292.2A CN111695123B (zh) | 2020-04-27 | 2020-04-27 | 一种面向区块链的降低冲突的乐观并发保序编码方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010342292.2A CN111695123B (zh) | 2020-04-27 | 2020-04-27 | 一种面向区块链的降低冲突的乐观并发保序编码方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111695123A CN111695123A (zh) | 2020-09-22 |
CN111695123B true CN111695123B (zh) | 2021-03-26 |
Family
ID=72476694
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010342292.2A Active CN111695123B (zh) | 2020-04-27 | 2020-04-27 | 一种面向区块链的降低冲突的乐观并发保序编码方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111695123B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112783976B (zh) * | 2021-01-05 | 2024-01-26 | 上海特高信息技术有限公司 | 一种联盟区块链柔性打包出块的共识系统 |
CN113516557B (zh) * | 2021-07-14 | 2022-09-23 | 桂林电子科技大学 | 一种有向无环图结构的区块链及其实现方法 |
Family Cites Families (5)
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 |
US11177961B2 (en) * | 2017-12-07 | 2021-11-16 | Nec Corporation | Method and system for securely sharing validation information using blockchain technology |
CN110263580B (zh) * | 2019-04-29 | 2021-03-23 | 创新先进技术有限公司 | 基于区块链的数据处理方法、装置和区块链节点 |
CN110275884B (zh) * | 2019-05-31 | 2020-08-04 | 阿里巴巴集团控股有限公司 | 数据存储方法及节点 |
CN110516463B (zh) * | 2019-09-02 | 2021-03-05 | 北京海益同展信息科技有限公司 | 用于生成信息的方法和装置 |
-
2020
- 2020-04-27 CN CN202010342292.2A patent/CN111695123B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN111695123A (zh) | 2020-09-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Kamara et al. | Parallel and dynamic searchable symmetric encryption | |
Ozsoyoglu et al. | Anti-tamper databases: Querying encrypted databases | |
Karp et al. | Efficient randomized pattern-matching algorithms | |
Wong et al. | Security in outsourcing of association rule mining | |
CN1828590B (zh) | 用于编码元数据的方法和系统 | |
Liu et al. | Merkle tree: A fundamental component of blockchains | |
CN111695123B (zh) | 一种面向区块链的降低冲突的乐观并发保序编码方法 | |
EP2064637B1 (en) | Method for dynamic secure management of an authenticated relational table in a database | |
Wang et al. | Forward and backward-secure range-searchable symmetric encryption | |
CN106934301B (zh) | 一种支持密文数据操作的关系型数据库安全外包数据处理方法 | |
CN109766389B (zh) | 一种基于位图索引的区块链轻客户端验证查询方法 | |
CN114153374B (zh) | 一种元数据与数据共同存储的分布式存储系统 | |
CN1466710A (zh) | 保护静态和动态数据免遭未授权操作的系统 | |
Persiano et al. | Lower bounds for differentially private RAMs | |
RuWei et al. | Study of privacy-preserving framework for cloud storage | |
EA036613B1 (ru) | Двухрежимная схема шифрования, обеспечивающая сравнение, основанное на индексировании | |
Kamel et al. | Dynamic spatial index for efficient query processing on the cloud | |
Hahn et al. | Poly-logarithmic range queries on encrypted data with small leakage | |
Wang et al. | QuickN: Practical and secure nearest neighbor search on encrypted large-scale data | |
CN109495446B (zh) | 基于平衡排序树存储结构的保序加密算法 | |
CN111680317B (zh) | 一种面向区块链的乐观并发保序编码方法 | |
Attasena et al. | fvss: A new secure and cost-efficient scheme for cloud data warehouses | |
Peng et al. | A reusable and single-interactive model for secure approximate k-nearest neighbor query in cloud | |
Lin et al. | Secure and privacy preserving outsourcing of tree structured data | |
CN105160279B (zh) | Rfid系统需要可信第三方的多所有者标签所有权转换方法 |
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 |