CN114219650B - 一种低交易延迟的区块链共识方法 - Google Patents
一种低交易延迟的区块链共识方法 Download PDFInfo
- Publication number
- CN114219650B CN114219650B CN202210154103.8A CN202210154103A CN114219650B CN 114219650 B CN114219650 B CN 114219650B CN 202210154103 A CN202210154103 A CN 202210154103A CN 114219650 B CN114219650 B CN 114219650B
- Authority
- CN
- China
- Prior art keywords
- block
- transaction
- miners
- blockchain
- hash value
- 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
- 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
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明涉及信息技术领域,具体涉及一种低交易延迟的区块链共识方法,包括:设置出块周期,划分广播阶段、出块阶段和确认阶段;在出块阶段区块链矿工生成区块体,提取出块哈希值,签名出块哈希值;将区块体关联出块哈希值、钱包地址和出块哈希值签名后广播;多个区块体将在区块链网络中广播;若区块体包含其他区块体未记录的交易,则签名出块哈希值并广播,若区块体记录的交易被其他区块体记录,则签名出块时间戳较早的区块体的出块哈希值并广播;集齐预设数量签名的区块体被纳入最终区块体;分摊出块奖励,生成奖励交易;最终区块体添加区块头形成区块。本发明的实质性效果是:避免了区块链矿工之间竞争,有效降低上链延迟。
Description
技术领域
本发明涉及信息技术领域,具体涉及一种低交易延迟的区块链共识方法。
背景技术
区块链是一个分布式共享账本,具有去中心化、可追溯、不可篡改、数据透明、集体维护的特点。在区块链系统中,节点与节点之间是平等的关系,区块链节点通过共识机制达成记账的统一。共识机制即是区块链系统为维护账本的统一,区块链节点执行的一系列操作和遵循的规则。参与维护区块链系统及生成区块的区块链节点又称为区块链矿工。目前主流的区块链共识机制有工作量证明机制POW、股权证明机制POS、委托权益证明DPOS和拜占庭容错共识机制PBFT。其中工作量证明机制POW因消耗大量算力和资源被业界所诟病,且工作量证明机制POW的交易上链延迟较高,但工作量证明机制POW具有最好的安全性和去中心化特性。POS和DPOS具有较低的交易上链延迟,但具有一定的中心化,安全性有所降低。拜占庭容错共识机制PBFT具有较高的安全性,但算法效率低,不适合具有大量节点的区块链系统。因而需要研究新的区块链共识机制。
如中国专利CN111539726A,公开日2020年8月14日,公开了一种区块链共识系统及方法,系统包含共识节点和代理节点;共识节点接收的交易请求,将交易请求广播至所处子共识网络中其他共识节点和代理节点进行验证处理;接收其他共识节点广播的交易请求或代理节点提供的交易请求,将交易结果与代理节点反馈的共识结果比较验证,根据验证结果将交易结果或共识结果入链;代理节点根据所处子共识网络广播的交易请求,通过拜占庭算法将交易请求共识至主网络中其他代理节点,或,获得主网络中其他代理节点共识的交易请求,将交易请求提供至所处子共识网络供共识节点处理;获得交易请求在主网络的共识结果,将共识结果提供至所处子共识网络供共识节点比较。其技术方案规定了共识节点和代理节点,具有一定的中心化问题,同时需要借助拜占庭算法完成共识,执行效率较低,不能有效降低交易上链延迟。
发明内容
本发明要解决的技术问题是:目前缺乏兼顾安全性和低交易上链延迟的区块链共识机制的技术问题。提出了一种低交易延迟的区块链共识方法,能够提供更低交易上链延迟的区块链共识方法。
为解决上述技术问题,本发明所采取的技术方案为:一种低交易延迟的区块链共识方法,包括:设置出块周期,将出块周期划分为广播阶段、出块阶段和确认阶段;广播阶段时区块链矿工广播交易,使交易池尽可能同步;在出块阶段区块链矿工从交易池中选择若干个交易打包进区块体,在区块体内添加时间戳,提取区块体的哈希值作为出块哈希值,签名出块哈希值;将区块体关联出块哈希值、钱包地址和出块哈希值签名后广播;多个区块体将在区块链网络中广播,区块链矿工检查区块体内包含的交易是否被其他区块体包含;若区块体包含其他区块体未记录的交易,则签名出块哈希值并广播,若区块体记录的交易被其他区块体记录,则签名出块时间戳较早的区块体的出块哈希值并广播;出块阶段结束后进入确认阶段,在确认阶段区块链矿工不再接收新产生的区块体,仅签名和广播已产生的区块体;确认阶段结束时,将有若干个区块体集齐预设数量的签名;集齐预设数量签名的区块体被纳入最终区块体,将区块体按照时间戳升序排序;按照区块体包含的不被排序在前的区块体记录的交易数量作为权重比例,分摊出块奖励,生成奖励交易;将奖励交易加入最终区块体,提取最终区块体的哈希值作为根哈希值;最终区块体添加区块头形成区块,所述区块头包括区块高度、根哈希值、上一个区块的区块哈希值、时间戳和区块哈希值,所述区块哈希值为当前区块的根哈希值与上一个区块的区块哈希值和当前区块高度一起提取获得的哈希值。
作为优选,交易池中的交易均分配有交易ID,区块链矿工周期性精简最终区块体,精简最终区块体的方法为:判断交易是否在最终区块体中被重复记录,若被重复记录,则删除在后的交易记录;最终区块体经过精简后形成查询区块,全部查询区块形成查询链,区块链执行交易检索时,使用所述查询链。
作为优选,区块链矿工广播区块体时,检查当前广播的区块体是否在已广播的区块体内记录,若存在交易被已广播的区块体记录,则将当前区块体内对应交易使用交易ID替换,将完成替换后的区块体广播。
作为优选,区块链矿工广播区块体时,若区块体记录的交易被其他区块体记录,则计算区块体得分,选定确认阶段起始时间戳作为参考时间戳,计算参考时间戳与区块体关联的时间戳差值,差值与区块体内包含的交易数量的乘积作为区块体得分,区块链矿工签名并广播得分高的区块体。
作为优选,广播阶段区块链矿工接收用户提交的交易或其他区块链矿工广播的交易;判断交易是否已被打包进区块,若已被打包进区块,则丢弃交易;区块链矿工判断当前内存中交易池包含的交易占用空间是否与预设区块体大小相当,若相当,则在本广播阶段内停止参与交易的广播。
作为优选,设置出块周期调整间隔和调整公式,当到达出块周期调整间隔时,区块链矿工根据调整公式调整出块周期,所述出块阶段和确认阶段占用时长固定,所述调整公式为出块周期对最小出块周期、最大出块周期、交易池平均交易数量和最终区块体平均大小的函数。
作为优选,设置交易池交易参考数量和区块体参考大小,区块链矿工计算出块周期调整间隔内的交易池交易数量平均值和最终区块体平均大小,若交易池交易数量平均值大于交易池交易参考数量或者最终区块体平均大小大于区块体参考大小,则按步长缩短出块周期,若出块周期小于最小出块周期,则出块周期设置为所述最小出块周期。
作为优选,广播阶段若干个区块链矿工生成若干个公私秘钥对,公开公钥;部分用户提交交易时,选择一个公钥将交易时间戳加密;区块链矿工广播交易时,选择若干个交易,将交易时间戳使用若干个公钥中的一个加密;进入确认阶段时,若干个区块链矿工公开私钥;区块链矿工使用私钥解密相应的交易,获得交易时间戳;若存在区块体的时间戳早于交易时间戳,则判定区块体作弊,丢弃对应的区块体;发起针对出块区块链矿工的投诉,投诉经预设比例的区块链矿工确认后,被投诉的区块链矿工被加入黑名单。
作为替代,广播阶段若干个区块链矿工生成若干个公私秘钥对,公开公钥;若干个区块链矿工生成若干个验证时间戳,选择一个公钥将验证时间戳加密;区块链矿工广播交易时,同时广播加密后的验证时间戳;出块阶段区块链矿工随机选择若干个加密后的验证时间戳,加入到区块体末尾;进入确认阶段时,若干个区块链矿工公开私钥;区块链矿工使用私钥解密获得验证时间戳;若存在区块体的时间戳早于包含的验证时间戳,则判定区块体作弊,丢弃对应的区块体;发起针对出块区块链矿工的投诉,投诉经预设比例的区块链矿工确认后,被投诉的区块链矿工被加入黑名单。
本发明的实质性效果是:区块链矿工均有权生成区块,具有较高的去中心化特性,保证了区块链系统的安全,采用区块体共识和最终区块确认的改进方案,避免了区块链矿工之间的竞争,能够有效降低交易上链延迟;采用共识区块和查询区块分开建立的方式,降低了共识需要进行的操作,提高了区块链共识的效率,降低了交易上链延迟。
附图说明
图1为实施例一区块链共识方法流程示意图。
图2为实施例一精简区块方法示意图。
图3为实施例一区块链矿工广播区块方法示意图。
图4为实施例一广播交易方法示意图。
图5为实施例一调整出块周期方法示意图。
图6为实施例一交易时间戳验证方法示意图。
图7为实施例一添加验证时间戳方法示意图。
具体实施方式
下面通过具体实施例,并结合附图,对本发明的具体实施方式作进一步具体说明。
实施例一:
一种低交易延迟的区块链共识方法,请参阅附图1,包括:步骤A01)设置出块周期,将出块周期划分为广播阶段、出块阶段和确认阶段。受制于网络等因素,区块链系统需要一定的时间完成一个区块的同步。若出块周期短可能会出现区块来不及达成一致,出现区块链分叉,降低区块链系统的安全性。但缩短出块周期能够直接有效的提高区块链系统的TPS,即提高了区块链系统的吞吐能力。合适的出块周期根据区块链的网络带宽和交易量确定。当交易量较小时,增加出块周期能够减小区块链矿工的工作量和网络的负载。本实施例中出块周期根据实际应用确定,将出块周期划分为广播阶段、出块阶段和确认阶段,其中出块阶段和确认阶段具有固定的时长,广播阶段用于同步交易池,时长可以根据区块链系统的交易量周期性的做出调整。步骤A02)广播阶段时区块链矿工广播交易,使交易池尽可能同步。交易池是区块链矿工内存中的一个列表,记载了当前等待被打包进区块的交易。在POW共识机制中,交易被发送给任一区块链矿工后,该交易将在区块链网络中进行广播,最终传递给全部区块链矿工。而后区块链矿工在此基础上打包区块,并建立工作量证明,实现公平的出块竞争。交易最终会被打包进区块,再次进行广播,因此采用POW共识机制时,交易最终将被广播两次,浪费了部分算力和带宽。
POS和DPOS共识机制中,通过见证人机制,交易仅在见证人之间广播,如101个见证人,减少了交易需要广播的区块链矿工数量,因此节省了大量的时间。但POS和DPOS共识机制牺牲了普通区块链节点参与共识的机会,具有一定的中心化风险,系统的安全性较低。本技术方案对此进行了改进,不需要在参与出块的区块链矿工之间实现交易池的同步。牺牲了交易池的一致性,但采用后续步骤能够保证区块的一致性。步骤A03)在出块阶段区块链矿工从交易池中选择若干个交易打包进区块体,在区块体内添加时间戳,提取区块体的哈希值作为出块哈希值,签名出块哈希值。区块的大小由区块链协议确定,实际区块大小会因交易数据大小有所差异,协议限定了区块链大小的最大值。增大区块的大小也能够提高区块链的吞吐效率,降低区块链交易确认延迟,但同时会造成区块链网络传输效率下降。因此提高区块大小降低区块链延迟的效果有限。当前出块周期和区块大小均因受到网络、硬件等条件限制,已难以进一步提高区块链系统的交易确认效率。当前提高区块链系统交易确认效率的主要方向在改进区块链的共识机制。
本实施例中区块体同样具有预定的大小限制,当交易数量较多时,区块链矿工选择其中的一部分进行打包即可。在现有的共识机制中,当交易池中存在较多的交易,一个区块仅能够打包其中的一部分交易时,区块链矿工从自身利益出发,将会优先打包手续费出价较高的交易。区块链用户为了能够减少交易确认延迟,将不得不提高手续费,导致恶性循环,使交易手续费不断上涨。比特链的交易手续费就曾达到$75每笔,给区块链用户带来较大的资金压力。同时,对于手续费出价较低的交易,将不断在手续费竞争中落败,长时间得不到确认。步骤A04)将区块体关联出块哈希值、钱包地址和出块哈希值签名后广播。步骤A05)多个区块体将在区块链网络中广播,区块链矿工检查区块体内包含的交易是否被其他区块体包含。与现有技术公开的共识机制不同,本技术方案在区块链网络中广播区块体而非区块。区块中包含了出块哈希值,提取区块体的哈希值即可进行验证。关联了钱包地址和出块哈希值的签名,使用签名地址对应的公钥能够解密出出块哈希值的签名,获得出块哈希值,与区块体对比验证即可。区块体中包含了时间戳,载明了区块体被制作完成的时间。步骤A06)若区块体包含其他区块体未记录的交易,则签名出块哈希值并广播,若区块体记录的交易被其他区块体记录,则签名出块时间戳较早的区块体的出块哈希值并广播。
现有的区块链共识机制在区块链矿工生产的多个区块之间进行比较和竞争,丢弃在竞争中失败的区块,使部分区块链矿工的工作被浪费。本实施例记载方案在区块体之间进行竞争,记载了其他区块体均未记载的交易,则能够在竞争中获胜,继续被广播和传递。同时,对于记载了相同交易的区块体,则比较区块体内记载的时间戳,完成时间早的区块体将继续被传播。部分硬件条件好的区块链矿工将选择那些交易手续费较高的交易进行打包,生成区块体。硬件条件相对较差的矿工通过打包那些交易手续费较低的交易。本技术方案中,区块链矿工将有动力打包手续费较低的交易,使每笔交易的延迟都较低,降低整体上交易的延迟。步骤A07)出块阶段结束后进入确认阶段,在确认阶段区块链矿工不再接收新产生的区块体,仅签名和广播已产生的区块体。步骤A08)确认阶段结束时,将有若干个区块体集齐预设数量的签名。确认阶段的时长应使得在实际网络条件下,大部分区块链矿工能够完成竞争中获胜的区块体的传播,使在竞争中获胜的区块体大概率能够集齐预设数量的签名。步骤A09)集齐预设数量签名的区块体被纳入最终区块体,将区块体按照时间戳升序排序。在竞争中获胜的区块体,将是记录交易最早的区块体或者记录了其他区块体未记录的交易,这些区块体都将被保留到最终区块体中。步骤A10)按照区块体包含的不被排序在前的区块体记录的交易数量作为权重比例,分摊出块奖励,生成奖励交易。
若一个区块体记载的交易被排序在前的几个区块体分别记录,则应当在竞争中被淘汰。但由于网络传播并非实时传播,即使存在区块体集齐了预设数量的签名,本实施例将其纳入最终区块体,虽然增大了最终区块体的大小,但降低了区块体竞争的复杂程度,有利于维护区块链系统的稳定。且其分摊到的奖励将为0,不影响奖励交易的生成。若认为区块链网络传输效率基本均衡,则更早生成的区块体将传播到更多的区块链矿工。交易被排序在前的几个区块体分别记录的区块体,集齐预设数量签名的概率不高。同时采用进一步的改进方案,能够缩小最终区块体的体积,使交易被排序在前的若干个区块体分别记载的区块体,占用的空间有限,降低对区块链网络交易确认效率的影响。步骤A11)将奖励交易加入最终区块体,提取最终区块体的哈希值作为根哈希值。奖励交易加入最终区块体,生成奖励交易的规则是一致的,大部分区块链矿工获得的区块体基本相同,因此大部分区块链矿工生成的奖励交易也将是一致的,不需要额外对奖励交易进行共识。步骤A12)最终区块体添加区块头形成区块,区块头包括区块高度、根哈希值、上一个区块的区块哈希值、时间戳和区块哈希值,区块哈希值为当前区块的根哈希值与上一个区块的区块哈希值和当前区块高度一起提取获得的哈希值。
最终区块头记载的时间戳将是不同的,但应当是差距较小的。现有技术公开的区块链共识机制中,最终的区块内容是完全相同的。本实施例采用技术方案中,仅保证涉及交易的部分完全一致,最终区块的生产时间戳有所区别并不影响区块链系统的一致性和安全性,因此最终区块的生产时间戳并没有被纳入区块哈希值中,否则,将需要新一轮的广播共识过程,消耗大量的网络资源。
交易池中的交易均分配有交易ID,交易ID由最先接收到交易的区块链矿工添加。交易ID由区块链矿工标识开头,添加区块链矿工本地记录的交易编号组成。通常情况下区块链用户不会将交易发送给两个区块链矿工。若实际应用中,存在交易发送给两个区块链矿工情况,则根据区块链矿工的标识,维护一个区块链矿工的排序,其他区块链矿工接受标识靠前的交易ID即可。如此进行交易ID的分配不仅具有较高的效率,也能够保持交易ID的唯一性。
区块链矿工周期性精简最终区块体,请参阅附图2,精简最终区块体的方法为:步骤B01)判断交易是否在最终区块体中被重复记录,若被重复记录,则执行步骤B02)删除在后的交易记录;步骤B03)最终区块体经过精简后形成查询区块;步骤B04)全部查询区块形成查询链,区块链执行交易检索时,使用查询链。区块链矿工节点分为重节点和轻节点,重节点指保存了全部区块的区块链节点,部分区块链要求参与出块的节点必须是重节点,即只有重节点才能够成为区块链矿工,参与区块的生成。轻节点则是保存了部分区块内容的节点,轻节点不能参与生成新的区块,仅提供查询验证等服务。在此基础上,本实施例提供了新的技术改进,重节点分为完全重节点和实用重节点,完全重节点指保留了全部区块的最终区块体的节点,实用重节点指仅保留了部分最新的区块的最终区块体,但保留了全部区块的查询区块的节点。完全重节点和实用重节点均能够参与新区块的生成,即均可以作为区块链矿工。
为了提高广播区块的效率,本实施例提供了压缩区块大小的具体方案,请参阅附图3,包括:步骤C01)区块链矿工广播区块体时,检查当前广播的区块体是否在已广播的区块体内记录,若存在交易被已广播的区块体记录,则执行步骤C02)将当前区块体内对应交易使用交易ID替换;步骤C03)将完成替换后的区块体广播。
表1 区块链矿工甲接收并广播的第一个区块体
出块哈希值 | 554F1B…D0E3C5 |
时间戳 | 1644462956 |
交易1 | ID:0xB6A05CFrom:Ad1To:Ad2Num:0.2TimeStamp:1644462356Sign:Sign1 |
交易2 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
交易3 | ID:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
交易4 | ID:0x7DB9F9From:Ad5To:Ad6Num:91TimeStamp:1644462566Sign:Sign4 |
交易5 | ID:0x7DB9FAFrom:Ad5To:Ad7Num:52TimeStamp:1644462580Sign:Sign5 |
交易6 | ID:0x7DB9FBFrom:Ad5To:Ad8Num:1.2TimeStamp:1644462686Sign:Sign6 |
交易7 | ID:0x4DFF08From:Ad9To:Ad10Num:8TimeStamp:1644462806Sign:Sign7 |
如表1所示,为区块链矿工甲接收到其他区块链矿工广播的区块体,并在随后继续进行广播的第一个区块体。一段时间后又先后收到其他区块链矿工广播的第二个区块体和第三个区块体。由于第二个和第三个区块体内均记载了在先广播区块体内未记录的交易,因此区块链矿工甲对第二个和第三个区块体也进行了广播。
表2 区块链矿工甲接收并广播的第二个区块体
出块哈希值 | 40E325…4B0864 |
时间戳 | 1644463936 |
交易1 | ID:0xB6A05D |
交易2 | iD:0xB6A05E |
交易3 | ID:0x40E32BFrom:Ad11To:Ad12Num:3TimeStamp:1644463896Sign:Sign8 |
交易4 | ID:0x3AC570From:Ad13To:Ad14Num:7TimeStamp:1644463920Sign:Sign9 |
表3 区块链矿工甲接收并广播的第三个区块体
出块哈希值 | 93BAC8…B0D53E |
时间戳 | 1644464380 |
交易1 | ID:0xB6A05C |
交易2 | ID:0xB6A05D |
交易3 | ID:0xB6A05E |
交易4 | ID:0x40E32B |
交易5 | ID:0x3AC570 |
交易6 | ID:0x4B32C1From:Ad15To:Ad6Num:3TimeStamp:1644464330Sign:Sign10 |
如表2和表3所示,区块链矿工甲收到的第二个和第三个区块体就存在若干个交易同时被在先广播的区块体所记录。因此在广播第二个区块体和第三个区块体时,对已被在先区块体记录的交易进行了精简,仅记录交易ID。对于记录了4个交易的第二个区块体而言,压缩后交易信息部分占据的空间几乎压缩了一半。第三个区块则记录了6笔交易,其中仅有一笔是在先区块体未记录的交易,按照规则第三个区块体也需要被保留并进行广播。若不进行压缩,则会造成大量带宽资源的无谓消耗。表4 未进行大小压缩的第三个区块体内容
出块哈希值 | 93BAC8…B0D53E |
时间戳 | 1644464380 |
交易1 | ID:0xB6A05CFrom:Ad1To:Ad2Num:0.2TimeStamp:1644462356Sign:Sign1 |
交易2 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
交易3 | ID:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
交易4 | ID:0x40E32BFrom:Ad11To:Ad12Num:3TimeStamp:1644463896Sign:Sign8 |
交易5 | ID:0x3AC570From:Ad13To:Ad14Num:7TimeStamp:1644463920Sign:Sign9 |
交易6 | ID:0x4B32C1From:Ad15To:Ad6Num:3TimeStamp:1644464330Sign:Sign10 |
如表4所示,为第三个区块体未被压缩时,所需要占用的长度将远高于压缩的长度。压缩后其占用空间将大幅缩小,与仅广播一笔交易相比,需要增加的空间不多。以此方案来大幅减小区块体重复记录交易造成的额外空间开销。
区块链矿工广播区块体时,若区块体记录的交易被其他区块体记录,则计算区块体得分,选定确认阶段起始时间戳作为参考时间戳,计算参考时间戳与区块体关联的时间戳差值,差值与区块体内包含的交易数量的乘积作为区块体得分,区块链矿工签名并广播得分高的区块体。以创始区块的出块时间戳为基准,叠加后续每个区块的出块周期,即可获得当前高度的区块的出块周期起始时间戳。当前出块周期已知,出块阶段和确认阶段占用时长固定,因而能够计算出确认阶段的起始时间戳。选定相同的参考时间戳,计算每个区块体关联时间戳与参考时间戳之间的时间差值,而后与区块体包含的交易数量相乘,作为区块体竞争评判的标准。避免区块链矿工为尽早产生区块体,仅打包一个交易进区块体,造成效率下降。理论上通过延迟生成区块体,以等待并获得更多的交易,增加区块体内包含的交易数量,能够提高区块体得分。但实际应用时,主要考虑面对交易池内交易数量较多,区块体的大小是有限制的,即每个区块体能够容纳的交易存在上限。区块链矿工不需要等待就能够打包数量达到上限的交易。因此,提高区块体得分的最为有效和稳妥的方式,仍然是尽快完成区块体的打包。进一步的,计算区块体得分时还可以采用以差值的平方和区块体内包含的交易数量的乘积作为区块体得分,作为替代的实施方式。以进一步提高快速生成区块体对区块体得分的影响权重。
在广播交易同步交易池过程中,区块链矿工执行以下步骤,请参阅附图4,包括:步骤D01)广播阶段区块链矿工接收用户提交的交易或其他区块链矿工广播的交易;步骤D02)判断交易是否已被打包进区块,若已被打包进区块,则丢弃交易;步骤D03)区块链矿工判断当前内存中交易池包含的交易占用空间是否与预设区块体大小相当,若相当,则在本广播阶段内停止参与交易的广播。在广播区块体时,就相当于同时完成了交易的广播,当区块链矿工的交易池收到足够数量的交易时,就可以先行生成区块体。不参与交易广播的区块链矿工收到其他区块链矿工向其发送交易信息的请求时,反馈拒收。发送交易的区块链矿工收到拒收消息后,重新选择一个区块链矿工发送,直到接收交易的区块链矿工达到预设数量。此时发大量区块链矿工不再参与交易的广播时,能够使区块链网络负载下降,从而提高其他参与交易广播的区块链矿工广播交易的效率。实施时,直接接收区块链用户提交的交易时,区块链矿工需要分配交易ID,且需发送给预定数量的其他区块链矿工或者收到预设数量的拒收信息。到达下一个出块周期的广播阶段时,区块链矿工再次尝试广播交易。
设置出块周期调整间隔和调整公式,当到达出块周期调整间隔时,区块链矿工根据调整公式调整出块周期,出块阶段和确认阶段占用时长固定,调整公式为出块周期对最小出块周期、最大出块周期、交易池平均交易数量和最终区块体平均大小的函数。广播阶段的时长,使用Time1表示,出块阶段和确认阶段占用时长固定,使用常数C表示,出块周期表示为Time1+C。即调整出块周期实际是对广播阶段时长的调整。当交易池平均交易数量较多或者最终区块体平均大小较大时,表示区块链存在较多的交易需要确认。此时缩短出块周期,使广播阶段更短,交易在区块链网络中的传播更少,从而节约了区块链网络的带宽。未被充分广播的交易,将在区块体的广播过程中,完成在区块链矿工之间的传播。区块链矿工生产的区块体将更大概率包含不同的交易,在区块体竞争中胜出的区块体数量增多,最终区块体将纳入更多的交易,使交易迅速的被确认进区块中,及时减少排队的交易数量,使交易确认等待时长缩短。
请参阅附图5,调整出块周期的方法包括:步骤E01)设置交易池交易参考数量和区块体参考大小;步骤E02)区块链矿工计算出块周期调整间隔内的交易池交易数量平均值和最终区块体平均大小;步骤E03)若交易池交易数量平均值大于交易池交易参考数量或者最终区块体平均大小大于区块体参考大小,则按步长缩短出块周期;步骤E04)若出块周期小于最小出块周期,则出块周期设置为最小出块周期;步骤E05)若交易池交易数量平均值小于交易池交易参考数量的k倍或者最终区块体平均大小大于区块体参考大小的k倍,则按步长增加出块周期;步骤E06)若出块周期大于最大出块周期,则出块周期设置为最大出块周期。本实施例设置出块周期为10s,调整周期为24h,当24h内交易池交易数量平均值大于交易池交易参考数量,或者最终区块体平均大小大于区块体参考大小时,则将出块周期调整为8s。当24h内交易池交易数量平均值大于交易池交易参考数量的0.6倍,或者最终区块体平均大小大于区块体参考大小的0.6倍时,将出块周期增加回10s。若下一个24h周期内,交易池交易数量平均值大于交易池交易参考数量的0.6倍,或者最终区块体平均大小大于区块体参考大小的0.6倍,则进一步增加出块周期到12s。
本实施例中区块体被纳入最终区块体时,出块时间戳是重要的判定依据,为避免区块链矿工为了增加区块体被纳入最终区块体的概率而使用虚假的时间戳,本实施例提供了两种技术方案,进行时间戳的验证。请参阅附图6,第一种方案包括:步骤F01)广播阶段若干个区块链矿工生成若干个公私秘钥对,公开公钥;步骤F02)部分用户提交交易时,选择一个公钥将交易时间戳加密;步骤F03)区块链矿工广播交易时,选择若干个交易,将交易时间戳使用若干个公钥中的一个加密;步骤F04)进入确认阶段时,若干个区块链矿工公开私钥;步骤F05)区块链矿工使用私钥解密相应的交易,获得交易时间戳;步骤F06)若存在区块体的时间戳早于交易时间戳,则判定区块体作弊,丢弃对应的区块体;步骤F07)发起针对出块区块链矿工的投诉,投诉经预设比例的区块链矿工确认后,被投诉的区块链矿工被加入黑名单。由区块链用户将交易时间戳加密,产生用于验证出块时间戳的交易,实施时可以要求每个区块体至少带有一个时间戳被加密的交易。则当选择将时间戳加密的区块链用户较少时,提交新的交易的区块链用户可以通过将时间戳加密,来获得更多被打包进区块体的机会。当选择加密交易时间戳的区块链用户较多时,区块链矿工为保障区块体的正确性,将不会有意愿打包多个交易时间戳加密的交易信息,会导致时间戳加密的交易被延后确认。如此区块链用户和区块链矿工将形成利益平衡,形成适当数量的交易时间戳被加密的交易信息存在于区块链网络中。为复原交易时间戳被加密的交易信息,相应的私钥应当被打包进最终的区块体中。
作为替代的方案,本实施例实施例时,能够采用第二种验证出块时间戳的方案,请参阅附图7,包括:步骤G01)广播阶段若干个区块链矿工生成若干个公私秘钥对,公开公钥;步骤G02)若干个区块链矿工生成若干个验证时间戳,选择一个公钥将验证时间戳加密;步骤G03)区块链矿工广播交易时,同时广播加密后的验证时间戳;步骤G04)出块阶段区块链矿工随机选择若干个加密后的验证时间戳,加入到区块体末尾;步骤G05)进入确认阶段时,若干个区块链矿工公开私钥;步骤G06)区块链矿工使用私钥解密获得验证时间戳;步骤G07)若存在区块体的时间戳早于包含的验证时间戳,则判定区块体作弊,丢弃对应的区块体;步骤G08)发起针对出块区块链矿工的投诉,投诉经预设比例的区块链矿工确认后,被投诉的区块链矿工被加入黑名单。相对于方案一,需要在大量的交易过程中,通过部分交易被延迟确认的代价,实现系统的均衡,方案而不会牺牲部分交易的确认及时性。方案二中,由若干个区块链矿工专门生成加密的验证时间戳,不需要区块链用户参与,每个区块体必须包含一个验证时间戳。产生验证时间戳的矿工不参与本高度区块的生成。生成当前高度区块需要的区块体的区块链矿工,不能确定验证时间戳的具体值,为避免被认定为作弊,区块链矿工产生区块体时,只能将真实的时间戳纳入到区块体中。方案二会使区块链矿工为区块链系统贡献更多时间和硬件资源。产生验证时间戳的区块链矿工应轮流担任。记载方案一的步骤F01)至步骤F07)和记载方案二的步骤G01)至G08)并非本实施例的必要步骤,在区块链矿工具有一定可信度,不会对时间戳造假时,可以不实施步骤步骤F01)至步骤F07)和步骤G01)至G08)。
本实施例的有益技术效果是:区块链矿工均有权生成区块,具有较高的去中心化特性,保证了区块链系统的安全,采用区块体共识和最终区块确认的改进方案,避免了区块链矿工之间的竞争,能够有效降低交易上链延迟;采用共识区块和查询区块分开建立的方式,降低了共识需要进行的操作,提高了区块链共识的效率,降低了交易上链延迟。
实施例二:
一种低交易延迟的区块链共识方法,应用于公链。新的矿工加入公链时,需要向已有的区块链矿工验证和签名网络延迟。新矿工需要准备一个虚拟账户地址,而后和已有区块链矿工建立通信,并测试通信的网络延迟,当测试获得的网络延迟低于预设阈值时,已有区块链矿工签名新矿工的虚拟账户地址。新的矿工集齐预设数量个签名后,从已有区块链矿工处请求下载系统节点表,下载后新矿工将自己的虚拟账户地址添加到系统节点表末尾,获得在系统节点表的标识编号。将添加后的系统节点表签名广播,同时附带测试通信的网络延迟时获得的签名。其他已有矿工验证网络延迟的签名后,接受新的系统节点表,完成新矿工的加入。
公链设置初始的出块周期为10s,广播阶段占用5s,出块阶段占用1s,确认阶段新占用4s。在5s时长的广播阶段中,区块链矿工接收并转发交易,使区块链用户提交的交易信息在区块链网络中广播。广播节点结束后,区块链矿工的交易池内将有一定数量的交易。本方案中不要求交易池的同步,即不同的区块链矿工的交易池内存在的交易并不相同。广播阶段要求直接收到区块链用户提交的交易的区块链矿工将交易转发预设次数或者收到预设数量的拒收信息。因此,那些为区块链用户提供了友好交互的区块链矿工,以及积极参与交易广播的区块链矿工能够更大概率获得更多的交易信息。也就能够在出块阶段更早的将更多的交易打包进区块体,获得区块体的竞争优势。因此区块链矿工有动力建设与区块链用户之间的交互,为用户提供更方便的交互,吸引更多用户使用。
进入占用时长为1s的出块阶段时,区块链矿工生成区块体,从交易池中选择若干个交易,打包进区块体,使区块体在不超过预设大小的前提下,尽可能容纳更多的交易。在区块体内添加时间戳,完成区块体的生成,如表5所示。
表5 区块链矿工生成的区块体
时间戳 | 1644464380 |
交易1 | ID:0xB6A05CFrom:Ad1To:Ad2Num:0.2TimeStamp:1644462356Sign:Sign1 |
交易2 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
交易3 | ID:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
交易4 | ID:0x40E32BFrom:Ad11To:Ad12Num:3TimeStamp:1644463896Sign:Sign8 |
交易5 | ID:0x3AC570From:Ad13To:Ad14Num:7TimeStamp:1644463920Sign:Sign9 |
交易6 | ID:0x4B32C1From:Ad15To:Ad6Num:3TimeStamp:1644464330Sign:Sign10 |
提取区块体的哈希值,获得出块哈希值为93BAC8…B0D53E,使用私钥签名出块哈希值获得出块哈希值签名Sign(93BAC8…B0D53E)。将区块体关联出块哈希值、钱包地址和出块哈希值签名后进行广播,钱包地址用于接收区块生成奖励。
进入到确认阶段时,将有多个区块体在区块链网络中传播。当区块链矿工生成的区块体的时间戳较晚且交易数量较少时,将在区块体的竞争中落败,失去继续用在区块链网络中传播的机会。在确认阶段开始后的一小段时间后,仍然在区块链网络中传播的区块体数量将较少。这些区块体要么包含其他区块体未记录的交易,要么是最早记录这些交易的区块体。若一个区块体记录的交易被更早的多个区块体分别记录,则该区块体被称为杂凑区块体,杂凑区块体应当在确认阶段被淘汰。当一个区块链矿工已经收到并广播若干个区块后,收到杂凑区块体时,发现杂凑区块体记录的交易分别被更早的多个区块体记录,则区块链矿工直接丢弃杂凑区块体。若收到杂凑区块体的区块链矿工尚未收到全部更早的区块体时,将会签名和广播杂凑区块体。因此,杂凑区块体是有机会集齐预设数量的签名的。但杂凑区块体在获得签名的过程中,需要避开已收到分别记录全部交易的更早的区块体的区块链矿工,因此杂凑区块体集齐预设数量的签名的概率较低。即使杂凑区块体集齐预设数量的签名,在生成最终区块体时也必然会被发现。此时可以采取两种处理方法:在生成最终区块体时丢弃杂凑区块体或者将杂凑区块体纳入最终区块体,但生成奖励交易时,生成杂凑区块体的区块链矿工将不会获得任何奖励。区块链矿工需要统一对两种处理方法的选择。
确认阶段结束前,大部分区块链矿工应当收到全部竞争中获胜的区块体。本实施例中,生成某个高度区块时,能够在竞争中获胜的区块体如表1至表3所示,则生成的最终区块体如表6所示。
表6 最终区块体
区块体1 | ID:0xB6A05CFrom:Ad1To:Ad2Num:0.2TimeStamp:1644462356Sign:Sign1 |
区块体1 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
区块体1 | ID:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
区块体1 | ID:0x7DB9F9From:Ad5To:Ad6Num:91TimeStamp:1644462566Sign:Sign4 |
区块体1 | ID:0x7DB9FAFrom:Ad5To:Ad7Num:52TimeStamp:1644462580Sign:Sign5 |
区块体1 | ID:0x7DB9FBFrom:Ad5To:Ad8Num:1.2TimeStamp:1644462686Sign:Sign6 |
区块体1 | ID:0x4DFF08From:Ad9To:Ad10Num:8TimeStamp:1644462806Sign:Sign7 |
区块体2 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
区块体2 | iD:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
区块体2 | ID:0x40E32BFrom:Ad11To:Ad12Num:3TimeStamp:1644463896Sign:Sign8 |
区块体2 | ID:0x3AC570From:Ad13To:Ad14Num:7TimeStamp:1644463920Sign:Sign9 |
区块体3 | ID:0xB6A05CFrom:Ad1To:Ad2Num:0.2TimeStamp:1644462356Sign:Sign1 |
区块体3 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
区块体3 | ID:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
区块体3 | ID:0x40E32BFrom:Ad11To:Ad12Num:3TimeStamp:1644463896Sign:Sign8 |
区块体3 | ID:0x3AC570From:Ad13To:Ad14Num:7TimeStamp:1644463920Sign:Sign9 |
区块体3 | ID:0x4B32C1From:Ad15To:Ad6Num:3TimeStamp:1644464330Sign:Sign10 |
提取最终区块体的哈希值,作为根哈希值,根哈希值记为root_hash。而后将根哈希值与上一个区块的区块哈希值和当前区块高度一起提取哈希值,即block_hash=HASH(root_hash,pre_block_hash,22605),HASH()表示散列函数。22605表示当前区块的高度。高度为22605的区块头内容如表7所示。
表7 区块22605的区块头
高度:22605 | block_hash: CAFC8B…DF316B |
root_hash: AE3CDE…9C3735 | TimeStamp: 1644464390 |
pre_block_hash: E28E5C…5D9716 |
由表6所示,直接将集齐预设数量签名的区块体按照区块体包含的时间戳排序并拼合后,会导致最终区块体记载大量重复数据,增加了存储空间和网络带宽的消耗。实施例一通过仅记录重复交易的交易ID能够压缩最终区块体。本实施例提供了能够进一步压缩最终区块体大小的方案。由于区块体中交易的顺序是有生成区块体的区块链矿工,根据交易时间戳升序排列获得。而最终区块体中,将区块体按照区块体内包含的时间戳升序拼接区块体。因此竞争中获胜的区块体传播至大部分区块链矿工的情况下,大部分区块链矿工生成的最终区块体中的交易排序将是一致的。因此,按照最终区块体中交易的排序的序号指代交易。将在后的重复交易使用顺序序号表示。压缩后的最终区块体如表8所示。
表8 压缩后的最终区块体
区块体1 | ID:0xB6A05CFrom:Ad1To:Ad2Num:0.2TimeStamp:1644462356Sign:Sign1 |
区块体1 | ID:0xB6A05DFrom:Ad1To:Ad3Num:21TimeStamp:1644462372Sign:Sign2 |
区块体1 | ID:0xB6A05EFrom:Ad1To:Ad4Num:20TimeStamp:1644462490Sign:Sign3 |
区块体1 | ID:0x7DB9F9From:Ad5To:Ad6Num:91TimeStamp:1644462566Sign:Sign4 |
区块体1 | ID:0x7DB9FAFrom:Ad5To:Ad7Num:52TimeStamp:1644462580Sign:Sign5 |
区块体1 | ID:0x7DB9FBFrom:Ad5To:Ad8Num:1.2TimeStamp:1644462686Sign:Sign6 |
区块体1 | ID:0x4DFF08From:Ad9To:Ad10Num:8TimeStamp:1644462806Sign:Sign7 |
区块体2 | No.2 |
区块体2 | No.3 |
区块体2 | ID:0x40E32BFrom:Ad11To:Ad12Num:3TimeStamp:1644463896Sign:Sign8 |
区块体2 | ID:0x3AC570From:Ad13To:Ad14Num:7TimeStamp:1644463920Sign:Sign9 |
区块体3 | No.1 |
区块体3 | No.2 |
区块体3 | No.3 |
区块体3 | No.10 |
区块体3 | No.11 |
区块体3 | ID:0x4B32C1From:Ad15To:Ad6Num:3TimeStamp:1644464330Sign:Sign10 |
在压缩后的最终区块体中,仅用一个数字加一个标识符表示重复记录的交易,使得重复记录交易需要的存储空间代价和额外消耗的网络带宽极低。但能够有效的使最终区块体记录更多的交易,使区块链矿工之间由竞争争夺记账权,变为合作完成记账,减少竞争过程中的资源消耗。将在后记录的重复交易删除,即获得查询区块。区块体压缩后的区块也可以直接用作查询区块,只需要在查询时,不对被压缩的交易进行复原即可。
对比例1
采用POW共识机制时,若表1至表3分别表示三个区块链矿工生成的区块的区块体。相应的区块头按照POW共识机制添加即可。仅考虑表1至表3记载的交易,假设最早完成工作量证明的区块内记载的交易如表1所示。则最终的区块将记录表1中记载的7笔交易。仅记载在表2或表3中的交易,将不会被记录。因而这些交易将参与下一个区块的生成。区块链矿工为尽早完成工作量证明,从交易池中任意选择若干笔交易验证后,即生成区块体,并开始尝试建立工作量证明。因此,部分交易仍然有可能不会被纳入区块体中。即使被区块链矿工纳入了区块体,但若区块链矿工未及时建立工作量证明,则又会在区块竞争中落败。因此,部分交易可能再次未被区块链确认,导致部分将存在较大延迟,且延迟上限不能确定。区块链用户无法根据最大可能延迟进行后续操作,只能不断查询区块链,增加了区块链网络的负载。
对比例2
采用DPOS共识机制时,见证人轮流生成区块。假设区块大小最多容纳7笔交易,且交易池为完全同步状态。表1为轮流顺序最早的见证人生成的区块内包含的交易。下一个出块周期时,生成表2的见证人将表2中记录的已被确认的交易删除,并将仅在表3记录的交易加入区块体,生成的区块体记载3笔交易,未超过区块大小限制。最终在区块链网络中完成广播数据大小为常数和10笔交易信息占用大小的和。因此采用DPOS共识机制时,交易存在的延迟与交易池交易量和区块大小限制有关。当交易池交易量较大时,区块链矿工按自身利益选择哪些交易被纳入区块体,哪些交易仍然留在交易池中。仍然有部分交易不能及时被纳入区块体。
采用本实施例记载共识方法时,表1至表3记载的交易分别在三个交易体中,在区块链网络中传播。由于采用压缩算法,存在于已被广播的区块体内的交易,仅记录交易ID,因此造成的区块链网络带宽资源的额外开销并不显著。最终在区块链网络中完成广播的数据大小为常数和10笔交易信息占用大小的和,再加上7个交易ID。实际需要广播的数据量增加并不多,但能够在一个出块周期内就将全部交易确认,并记录在最终的区块内。因此,只要在广播阶段将交易提交给任意区块量矿工,基本就可以确认交易会在当前出块周期内完成确认。考虑到提交交易时可能处于出块阶段或者确认阶段,额外等待一个周期就可以完成完成交易的确认。本方案使得交易确认延迟低,需要额外在区块链网络中传播以及需要区块链矿工本地存储的数据量有所增加,但增加的数据量非常小,对区块链网络和存储资源开销影响不大。相对于对比例1和对比例2具有显著的有益技术效果。
以上的实施例只是本发明的一种较佳的方案,并非对本发明作任何形式上的限制,在不超出权利要求所记载的技术方案的前提下还有其它的变体及改型。
Claims (7)
1.一种低交易延迟的区块链共识方法,其特征在于,包括:
设置出块周期,将出块周期划分为广播阶段、出块阶段和确认阶段;
广播阶段时区块链矿工广播交易;
在出块阶段区块链矿工从交易池中选择若干个交易打包进区块体,在区块体内添加时间戳,提取区块体的哈希值作为出块哈希值,签名出块哈希值;
将区块体关联出块哈希值、钱包地址和出块哈希值签名后广播;
多个区块体将在区块链网络中广播,区块链矿工检查区块体内包含的交易是否被其他区块体包含;
若区块体包含其他区块体未记录的交易,则签名出块哈希值并广播,若区块体记录的交易被其他区块体记录,则签名出块时间戳较早的区块体的出块哈希值并广播;
出块阶段结束后进入确认阶段,在确认阶段区块链矿工不再接收新产生的区块体,仅签名和广播已产生的区块体;
确认阶段结束时,将有若干个区块体集齐预设数量的签名;
集齐预设数量签名的区块体被纳入最终区块体,将区块体按照时间戳升序排序;
按照区块体包含的不被排序在前的区块体记录的交易数量作为权重比例,分摊出块奖励,生成奖励交易;
将奖励交易加入最终区块体,提取最终区块体的哈希值作为根哈希值;
最终区块体添加区块头形成区块,所述区块头包括区块高度、根哈希值、上一个区块的区块哈希值、时间戳和区块哈希值,所述区块哈希值为当前区块的根哈希值与上一个区块的区块哈希值和当前区块高度一起提取获得的哈希值。
2.根据权利要求1所述的一种低交易延迟的区块链共识方法,其特征在于,
交易池中的交易均分配有交易ID,区块链矿工周期性精简最终区块体,精简最终区块体的方法为:判断交易是否在最终区块体中被重复记录,若被重复记录,则删除在后的交易记录;最终区块体经过精简后形成查询区块,全部查询区块形成查询链,区块链执行交易检索时,使用所述查询链。
3.根据权利要求2所述的一种低交易延迟的区块链共识方法,其特征在于,
区块链矿工广播区块体时,检查当前广播的区块体是否在已广播的区块体内记录,若存在交易被已广播的区块体记录,则将当前区块体内对应交易使用交易ID替换,将完成替换后的区块体广播。
4.根据权利要求1至3任一项所述的一种低交易延迟的区块链共识方法,其特征在于,
区块链矿工广播区块体时,若区块体记录的交易被其他区块体记录,则计算区块体得分,选定确认阶段起始时间戳作为参考时间戳,计算参考时间戳与区块体关联的时间戳差值,差值与区块体内包含的交易数量的乘积作为区块体得分,区块链矿工签名并广播得分高的区块体。
5.根据权利要求1至3任一项所述的一种低交易延迟的区块链共识方法,其特征在于,
广播阶段区块链矿工接收用户提交的交易或其他区块链矿工广播的交易;
判断交易是否已被打包进区块,若已被打包进区块,则丢弃交易;
区块链矿工判断当前内存中交易池包含的交易占用空间是否与预设区块体大小相当,若相当,则在本广播阶段内停止参与交易的广播。
6.根据权利要求1至3任一项所述的一种低交易延迟的区块链共识方法,其特征在于,
广播阶段若干个区块链矿工生成若干个公私秘钥对,公开公钥;
部分用户提交交易时,选择一个公钥将交易时间戳加密;
区块链矿工广播交易时,选择若干个交易,将交易时间戳使用若干个公钥中的一个加密;
进入确认阶段时,若干个区块链矿工公开私钥;
区块链矿工使用私钥解密相应的交易,获得交易时间戳;
若存在区块体的时间戳早于交易时间戳,则判定区块体作弊,丢弃对应的区块体;
发起针对出块区块链矿工的投诉,投诉经预设比例的区块链矿工确认后,被投诉的区块链矿工被加入黑名单。
7.根据权利要求1至3任一项所述的一种低交易延迟的区块链共识方法,其特征在于,
广播阶段若干个区块链矿工生成若干个公私秘钥对,公开公钥;
若干个区块链矿工生成若干个验证时间戳,选择一个公钥将验证时间戳加密;
区块链矿工广播交易时,同时广播加密后的验证时间戳;
出块阶段区块链矿工随机选择若干个加密后的验证时间戳,加入到区块体末尾;
进入确认阶段时,若干个区块链矿工公开私钥;
区块链矿工使用私钥解密获得验证时间戳;
若存在区块体的时间戳早于包含的验证时间戳,则判定区块体作弊,丢弃对应的区块体;
发起针对出块区块链矿工的投诉,投诉经预设比例的区块链矿工确认后,被投诉的区块链矿工被加入黑名单。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210154103.8A CN114219650B (zh) | 2022-02-21 | 2022-02-21 | 一种低交易延迟的区块链共识方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210154103.8A CN114219650B (zh) | 2022-02-21 | 2022-02-21 | 一种低交易延迟的区块链共识方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114219650A CN114219650A (zh) | 2022-03-22 |
CN114219650B true CN114219650B (zh) | 2022-05-20 |
Family
ID=80708937
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210154103.8A Active CN114219650B (zh) | 2022-02-21 | 2022-02-21 | 一种低交易延迟的区块链共识方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114219650B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115208898B (zh) * | 2022-03-29 | 2023-12-08 | 深圳大学 | 区块广播方法、装置、计算机设备和存储介质 |
CN117812092B (zh) * | 2024-02-28 | 2024-05-14 | 中国信息通信研究院 | 基于谓词的区块压缩传输方法和装置、设备和介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112116349A (zh) * | 2020-08-12 | 2020-12-22 | 北京智融云河科技有限公司 | 面向高吞吐率的图式账本的随机化共识方法和装置 |
CN112991068A (zh) * | 2021-05-20 | 2021-06-18 | 卓尔智联(武汉)研究院有限公司 | 股份授权证明DPoS共识方法、装置、电子设备和存储介质 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200366495A1 (en) * | 2018-01-29 | 2020-11-19 | Ubiquicorp Limited | Proof of majority block consensus method for generating and uploading a block to a blockchain |
CN108985740B (zh) * | 2018-07-07 | 2021-08-06 | 夸克链科技(深圳)有限公司 | 高性能共识算法的实现方法 |
CA3061603A1 (en) * | 2018-11-14 | 2020-05-14 | Royal Bank Of Canada | System and method for storing contract data structures on permissioned distributed ledgers |
CN109493062B (zh) * | 2018-12-29 | 2021-03-09 | 中国科学院合肥物质科学研究院 | 一种基于信誉权益证明的区块链共识方法 |
CN110580653B (zh) * | 2019-08-14 | 2022-10-11 | 长沙理工大学 | 一种基于交易的区块链共识机制 |
CN112232957A (zh) * | 2020-10-16 | 2021-01-15 | 网易(杭州)网络有限公司 | 交易共识方法、装置和电子设备 |
CN112685796B (zh) * | 2021-03-12 | 2021-06-18 | 腾讯科技(深圳)有限公司 | 一种基于区块链的区块共识方法以及相关设备 |
CN113518005B (zh) * | 2021-06-22 | 2021-11-16 | 腾讯科技(深圳)有限公司 | 一种区块共识方法、装置、设备及存储介质 |
CN114049117A (zh) * | 2021-11-01 | 2022-02-15 | 浙江数秦科技有限公司 | 一种具有高tps的区块链共识方法 |
CN113822672B (zh) * | 2021-11-22 | 2022-02-18 | 浙江数秦科技有限公司 | 一种基于零知识证明的区块链共识方法 |
-
2022
- 2022-02-21 CN CN202210154103.8A patent/CN114219650B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112116349A (zh) * | 2020-08-12 | 2020-12-22 | 北京智融云河科技有限公司 | 面向高吞吐率的图式账本的随机化共识方法和装置 |
CN112991068A (zh) * | 2021-05-20 | 2021-06-18 | 卓尔智联(武汉)研究院有限公司 | 股份授权证明DPoS共识方法、装置、电子设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN114219650A (zh) | 2022-03-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114219650B (zh) | 一种低交易延迟的区块链共识方法 | |
CN107169865B (zh) | 基于区块链技术的资产数据处理系统 | |
CN109150972B (zh) | 一种双层分片的高效区块链的共识机制的工作方法 | |
CN109255713B (zh) | 一种区块链网络中某一时间段内记账权的获取方法 | |
CN109508968A (zh) | 区块链系统以及其控制方法 | |
CN111131209B (zh) | 一种改进的高效共识方法、系统、计算机设备及存储介质 | |
CN111130790B (zh) | 基于区块链节点网络的共识出块方法 | |
CN110868441A (zh) | 区块链公链的维护方法、装置、节点及区块链公链 | |
CN110855432B (zh) | 基于可验证随机函数分配验证者奖励的异步bft&dpos共识机制 | |
CN110570202A (zh) | 一种基于分片技术的混合共识方法 | |
CN113822672B (zh) | 一种基于零知识证明的区块链共识方法 | |
CN109684519B (zh) | 一种基于区块链的去中心化芯片研发交易数据存储方法及系统 | |
CN111818181B (zh) | 基于区块链的数据处理方法、装置及计算机可读存储介质 | |
CN113157457B (zh) | 区块链分片负载均衡方法及装置 | |
CN114499890A (zh) | 联盟链中基于节点分组的Raft PBFT两阶段共识机制 | |
CN102857470A (zh) | 一种网络传输系统、服务器和客户端 | |
CN113783699A (zh) | 基于区块链的数据处理方法、装置、设备及可读存储介质 | |
CN113973021A (zh) | 一种图式区块链的网络传输优化装置及方法 | |
CN110505084B (zh) | 一种区块链打包节点共识推举方法 | |
CN114049117A (zh) | 一种具有高tps的区块链共识方法 | |
CN114143021B (zh) | 一种基于区块链的新闻信息信用积分系统 | |
CN114745131A (zh) | 一种区块链的pbft改进共识算法 | |
CN112801791A (zh) | 一种基于授权的区块链共识方法及系统 | |
CN113360569B (zh) | 基于储能参数选择与容量分解的电网区块链架构方法 | |
Pohl et al. | Proof of Provision: Improving Blockchain Technology by Cloud Computing. |
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 |