WO2019019056A1 - 前置机参与区块链共识的方法 - Google Patents

前置机参与区块链共识的方法 Download PDF

Info

Publication number
WO2019019056A1
WO2019019056A1 PCT/CN2017/094517 CN2017094517W WO2019019056A1 WO 2019019056 A1 WO2019019056 A1 WO 2019019056A1 CN 2017094517 W CN2017094517 W CN 2017094517W WO 2019019056 A1 WO2019019056 A1 WO 2019019056A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
consensus
transaction
height
block
Prior art date
Application number
PCT/CN2017/094517
Other languages
English (en)
French (fr)
Inventor
吴思进
王志文
Original Assignee
杭州复杂美科技有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 杭州复杂美科技有限公司 filed Critical 杭州复杂美科技有限公司
Priority to PCT/CN2017/094517 priority Critical patent/WO2019019056A1/zh
Publication of WO2019019056A1 publication Critical patent/WO2019019056A1/zh

Links

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators

Definitions

  • the present invention relates to blockchain technology.
  • the present invention provides a consensus method for a front-end machine to participate in a blockchain, and receives transaction data through a front-end machine of a partitioned slice, thereby ensuring an attack situation. Underneath, there are multiple channels that can enter the consensus node. The consensus node only needs to receive the front-end machine to send the verified transaction data, and the consensus nodes only need to transmit the verification result, which greatly reduces the data transmission and improves the blockchain consensus. s efficiency. Problem solution
  • Step Sl the front machine takes the maximum height H of the consensus node of 2/3 and above, and the force is the latest block height;
  • Step S2 the front-end machine receives the transaction instruction, verifies whether the transaction signature is correct and whether the transaction condition is met, for example, the payment cannot exceed the balance of the payment address, and the block height H+1 determined by the step S1 is added after the verification is passed, after the signature Sended to all other consensus nodes, the front-end machine determines the new H+1 height as the block height of the current round of consensus, and can agree on a super-timer tl.
  • Block height sends transaction data
  • Step S3 If the consensus node verifies that the transaction signature meets the condition, the verification result is sent to all other consensus nodes, and after receiving the first data of the H+1 height, the consensus node agrees to a super-timer t2. No more H+1 height data will be received after exceeding the time limit;
  • Step S4 each consensus node receives the verification result sent by other nodes, and the cumulative voting reaches a certain level. After the number of votes, a new block with a height of H+l is generated, and the new H+1 block header hash calculation includes the header hash value of the block with the previous height H;
  • Step S5 each consensus node sends a new block with a height of H+1 to the pre-node, which may include a balance state f ⁇ ;
  • Step S6 the front-end machine compares the transaction data of the transaction data of the H+l height that has not been written into the consensus block H+l, as the data of the H+2 height, together with the newly received data. Send to all consensus nodes, which can specify the upper limit of data sent by each block. The transaction data exceeding the upper limit will be returned to the H+3 height data until the next round of transmission.
  • the front-end machine can partition the expenditure address, such as the first two digits of the payment address 00, 01, 10, 11 points and 4 areas, each payment address is partitioned and then the transaction hash is fragmented, according to the drawing 2 steps are as follows;
  • Step S1 the user sends the transaction to the front-end machines where the partition of the payment account address is located, and each front-end machine can specify the maximum number of times each block height is transmitted, and the more the number of partition users is allocated.
  • the more machines, the modality of the number of users according to the transaction hash value, such as Beijing 3 front-end machines, each Beijing payment address transaction, according to different transaction hash value 3, can correspond Different front-end machines, even if some front-end machines are damaged or attacked, the user can change the transaction hash value to enter the blockchain consensus node through other front-end machines;
  • Step S2 the transaction data of the transaction hash slice under each payout address partition is completely independent. After verifying the signature and correctly calculating the balance, the data may be packaged in sequence or according to the same height. All blockchain consensus nodes;
  • Step S3 all the consensus nodes receive the same height but completely independent transaction data sent by all the front-end machines, and the multi-thread checksum can be used to calculate the balance, and the transaction result of the partitioned slice can be distributed to other All consensus nodes vote. If the verification result of the consensus node is consistent with the pre-machine verification result, add a private key signature of the consensus node. If there is inconsistent data, it needs to be eliminated, and the rejected data and consensus will be rejected. The hash value of the result is passed to other consensus nodes for comparison voting;
  • Step S4 after the consensus node votes on the data of the partitioned slice to reach a consensus result, the packet is sent to the corresponding pre-segment node, and the pre-segment node compares the data of the slice to the previous time. The data sent but not written to the block is verified again, and the verified transaction data is sent to all consensus nodes by a height. [0017] 3.
  • the front-end machine For each height of transmitting transaction data, write some bits of the transaction hash value into the bit chart, so that the user can provide different transaction hash values, and the front machine selects one to make it not Overlap with bitmaps of other transactions, or put a bitmap of the height of several blocks behind or behind, the front-end machine can place the transaction hash value according to the position of the bitmap, and calculate the hash value of the Merkel tree. After the front-end machine transmits the data to the consensus node, it can quickly compare the data consistency through the bitmap and the hash value of the Merkel tree to obtain missing data or eliminate inconsistent data.
  • the beneficial effect of the present invention is that the transaction data is received by the front-end machine of the partitioned slice, and it can be ensured that in the case of attack, multiple channels can enter the consensus node, and the consensus node It only needs to receive the front-end machine to send the verified transaction data, and only the verification results need to be transmitted between the consensus nodes, which greatly improves the consensus efficiency.
  • 1 is an explanatory diagram of a front-end machine participating in a blockchain consensus method
  • FIG 2 is an explanatory diagram of front-end machine partitioning and fragmentation verification and transmission transaction data.
  • the front-end machine can partition the expenditure address, such as the first two digits of the payment address 00, 01, 10, 11 into 4 zones, and each transaction address is partitioned and then the transaction hash is segmented, as shown in FIG. 2, Beijing (3 front-end machines), Shanghai (4 front-end machines), Hangzhou (2 front-end machines), Shenzhen (3 front-end machines);
  • Step S1 the user sends the transaction to the front-end machines where the partition of the payment account address is located, and each front-end machine can specify the maximum number of times each block height is transmitted, and the more the number of partition users is allocated.
  • the more machines, the modality of the number of users according to the transaction hash value, such as Beijing 3 front-end machines, each The transaction of Beijing payment address, according to the different transaction hash value of 3, can correspond to different front-end machines, even if some front-end machines are damaged or attacked, the user can also change the transaction hash value through other front-end machines.
  • Step S2 the front-end machine takes the maximum height H of the consensus node of 2/3 and above, and the force is used as the latest block height, and the front-end machine receives the transaction instruction, verifies whether the transaction signature is correct and whether the transaction condition is met, such as The payment cannot exceed the balance of the payment address. After the verification is passed, the block height H+l is added, and the signature is sent to all other consensus nodes. The front-end machine determines the new H+1 height as the block height of the current round of consensus. It is agreed that a super-time interval tl, after exceeding the time limit, no longer send transaction data with H+1 block height;
  • Step S3 all the consensus nodes, B, and C receive the same height H+1 but completely independent transaction data sent by all the front-end machines, and the multi-thread checksum can be used to calculate the balance summary, and the partition can be divided.
  • the transaction result of the film is distributed to all other consensus nodes for voting. If the verification result of the consensus node is consistent with the verification result of the front-end machine, a private key signature of the consensus node may be added. If there is inconsistent data, it is required. Exclusion, the hashed data and the hash value of the consensus result are transmitted to other consensus nodes for comparison voting. After the consensus node receives the first data of H+1 height, it agrees that a super-timer t2 exceeds the maximum No more H+1 height data will be received after the interval;
  • Step S4 each consensus node receives the verification result sent by other nodes, accumulates the vote, and after reaching a certain number of votes, generates a new block with a height of H+1, and a new H+1 block header hash calculation ⁇ The header hash value of the block with the previous height H is included, and the consensus node votes for the partitioned piece data to reach a consensus result, and then sends the packet to the corresponding slice front node, which may include the balance status information.
  • Step S5 after the data of the fragmentation node is compared with the data of the fragment, the data of the previously sent but not written block is verified again, and the verified transaction data is sent to all the consensus by pressing a height.
  • Node for each height transfer transaction data, write some bits of the transaction hash value into the bit chart, so that the user can provide different transaction hash values, and the front-end machine selects one to make it not match other transactions.
  • the bitmaps overlap, or put into the bit chart of the height of the block behind or behind.
  • the front-end machine can place the transaction hash value according to the position of the bit chart, and calculate the hash value of the Merkel tree. After the machine transmits the data to the consensus node, You can quickly compare data consistency with bitmaps and hashes of Merkel trees to get missing data, or to eliminate inconsistent data.
  • the front-end machine compares the transaction data of the H+1 height transaction data that has not been written into the consensus block H+1, and sends the data as the H+2 height data, together with the newly received data, to all
  • the consensus node can specify the upper limit of data sent by each block, and the transaction data exceeding the upper limit will be returned to the H+3 height data until the next round of transmission.
  • the purpose of the present invention is to introduce a front-end machine to perform partitioned pre-processing on the consensus transaction data, and then send the verified data to the consensus server, and the consensus server mainly transmits the consensus result.
  • the method preferably disperses the load of processing transaction data, and improves the consensus efficiency of the blockchain.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种前置机参与区块链共识的方法，包括：前置机取2/3及以上的共识节点的最大高度H，加1作为最新的区块高度，将新的交易数据发送给其他所有的共识节点，共识节点验证后将验证结果发送给其他所有的共识节点，通过投票共识后，各共识节点再将达成共识的新区块发送给前置节点，前置节点将未写入区块的交易数据以更新的高度发送给共识节点。

Description

技术领域
[0001] 本发明涉及区块链技术。
背景技术
[0002] 现有区块链技术数据传输冗余多， 共识效率氐。
技术问题
[0003] 为了克服上述现有技术的不足， 本发明提供了一种前置机参与区块链的共识方 法， 通过分区分片的前置机来接收交易数据， 可保证在受攻击的情况下， 有多 个通道能进入共识节点， 共识节点只需接收前置机发送经过验证的交易数据， 而共识节点之间只需要传输验证结果即可， 大幅度减少数据传输及提高区块链 共识的效率。 问题的解决方案
技术解决方案
[0004] 本发明所采用的技术方案是：
[0005] 1、 前置机参与区块链共识的方法， 区块链生成新区块的步骤如下；
[0006] 步骤 Sl， 前置机取 2/3及以上的共识节点的最大高度 H， 力 作为最新的区块 高度；
[0007] 步骤 S2， 前置机接收交易指令， 验证交易签名是否正确及是否符合交易条件， 如支付不能超过该支付地址余额， 验证通过后附加步骤 S1确定的区块高度 H+1， 签名后发送给其他所有的共识节点， 前置机在确定新的 H+1高度作为本轮共识的 区块高度， 可以约定一个超吋吋间 tl， 超过超吋吋间后不再以 H+1区块高度发送 交易数据；
[0008] 步骤 S3， 若共识节点验证交易签名符合条件， 则将验证结果发送给其他所有的 共识节点， 共识节点收到 H+1高度的第一个数据后， 约定一个超吋吋间 t2， 超过 超吋吋间后不再接收任何 H+1高度的数据；
[0009] 步骤 S4， 每个共识节点收到其他节点发过来的验证结果， 累计投票， 达到一定 的票数后， 生成高度为 H+l的新区块， 新的 H+1区块头哈希计算吋包含前一高度 为 H的区块的头哈希值；
[0010] 步骤 S5， 每个共识节点将高度为 H+l新区块发送到前置节点， 可包括余额状态 f π息；
[0011] 步骤 S6， 前置机比较出已发送的 H+l高度的交易数据中未被写入共识区块 H+l 的交易数据， 作为 H+2高度的数据， 连同新收到的数据发送给所有的共识节点， 可规定每个区块发送数据的上限， 超过上限的交易数据会归到 H+3高度的数据等 到下一轮发送。
[0012] 2、 前置机可将支出地址分区， 如支付地址的前二位 00、 01、 10、 11分 4个区， 每个支付地址分区后再将交易哈希分片， 按附图 2步骤如下；
[0013] 步骤 Sl， 用户将交易发送给支付账户地址的分区所在的那些前置机， 每台 前置机可以规定每个区块高度传送的最大笔数， 分区用户数量越多分配的前置 机越多， 可按交易哈希值来对用户数量的级别来取模， 比如北京 3台前置机， 每 个北京支付地址的交易， 根据不同的交易哈希值取 3的模， 可以对应不同的前置 机， 即使部分前置机损坏或被攻击， 用户还可以变换交易哈希值通过其他前置 机进入区块链共识节点；
[0014] 步骤 S2， 每个支出地址分区下的交易哈希分片的交易数据都是完全独立的， 在 对签名进行校验及正确计算余额后， 可依次或按同一高度的数据打包发送给所 有的区块链共识节点；
[0015] 步骤 S3， 所有的共识节点收到所有前置机发送的同一高度的但完全独立的交易 数据， 可以多线程校验及计算余额， 可以将分区分片的交易结果分送给其他所 有的共识节点进行投票， 若共识节点的验证结果和前置机验证结果一致， 再加 一个本共识节点的私钥签名即可， 若有不一致的数据， 则需要剔除， 将剔除的 数据及共识结果的哈希值传送给其他共识节点， 以便对比投票；
[0016] 步骤 S4， 共识节点对分区分片的数据分别投票达成共识结果后， 打包发给对应 的分片前置节点， 分片前置节点对该分片的数据对比后， 把前次已发送但未写 入区块的数据再次验证， 通过验证的交易数据按下一个高度发送给所有的共识 节点。 [0017] 3、 对于每个高度传送交易数据的吋候， 把交易哈希值的某几位写入位图表， 让用户同吋提供不同的交易哈希值， 前置机选一个使之不与其他交易的位图重 叠， 或者放入后面或后面几个区块高度的位图表， 前置机可以按位图表的位置 来放置各交易哈希值， 并计算梅克尔树的哈希值， 前置机把数据传送给共识节 点后， 可以通过位图表和梅克尔树的哈希值快速对比数据的一致性， 获取遗漏 数据， 或剔除不一致的数据。
发明的有益效果
有益效果
[0018] 与现有技术相比， 本发明的有益效果是通过分区分片的前置机来接收交易数据 ， 可保证在受攻击的情况下， 有多个通道能进入共识节点， 共识节点只需接收 前置机发送经过验证的交易数据， 而共识节点之间只需要传输验证结果即可， 大幅度提高共识效率。
对附图的简要说明
附图说明
[0019] 图 1为前置机参与区块链共识方法的说明图；
[0020] 图 2为前置机分区和分片验证和传输交易数据的说明图。
实施该发明的最佳实施例
本发明的最佳实施方式
[0021] 下面结合附图 1和附图 2对本发明进一步说明。
本发明的实施方式
[0022] 前置机可将支出地址分区， 如支付地址的前二位 00、 01、 10、 11分 4个区， 每 个支付地址分区后再将交易哈希分片， 如附图 2， 北京 （3个前置机） 、 上海 （4 个前置机） 、 杭州 （2个前置机） 、 深圳 （3个前置机） ；
[0023] 步骤 Sl， 用户将交易发送给支付账户地址的分区所在的那些前置机， 每台 前置机可以规定每个区块高度传送的最大笔数， 分区用户数量越多分配的前置 机越多， 可按交易哈希值来对用户数量的级别来取模， 比如北京 3台前置机， 每 个北京支付地址的交易， 根据不同的交易哈希值取 3的模， 可以对应不同的前置 机， 即使部分前置机损坏或被攻击， 用户还可以变换交易哈希值通过其他前置 机进入区块链共识节点；
[0024] 步骤 S2， 前置机取 2/3及以上的共识节点的最大高度 H， 力 作为最新的区块 高度， 前置机接收交易指令， 验证交易签名是否正确及是否符合交易条件， 如 支付不能超过该支付地址余额， 验证通过后附加区块高度 H+l， 签名后发送给其 他所有的共识节点， 前置机在确定新的 H+1高度作为本轮共识的区块高度， 可以 约定一个超吋吋间 tl， 超过超吋吋间后不再以 H+1区块高度发送交易数据；
[0025] 每个支出地址分区下的交易哈希分片的交易数据都是完全独立的， 在对签名进 行校验及正确计算余额后， 可依次或按同一高度的数据打包发送给所有的区块 链共识节点；
[0026] 步骤 S3， 所有的共识节点 、 B、 C收到所有前置机发送的同一高度 H+1的但完 全独立的交易数据， 可以多线程校验及计算余额汇总， 可以将分区分片的交易 结果分送给其他所有的共识节点进行投票， 若共识节点的验证结果和前置机验 证结果一致， 再加一个本共识节点的私钥签名即可， 若有不一致的数据， 则需 要剔除， 将剔除的数据及共识结果的哈希值传送给其他共识节点， 以便对比投 票， 共识节点收到 H+1高度的第一个数据后， 约定一个超吋吋间 t2， 超过超吋吋 间后不再接收任何 H+1高度的数据；
[0027] 步骤 S4， 每个共识节点收到其他节点发过来的验证结果， 累计投票， 达到一定 的票数后， 生成高度为 H+1的新区块， 新的 H+1区块头哈希计算吋包含前一高度 为 H的区块的头哈希值， 共识节点对分区分片的数据分别投票达成共识结果后， 打包发给对应的分片前置节点， 可包括余额状态信息。
[0028] 步骤 S5， 分片前置节点对该分片的数据对比后， 把前次已发送但未写入区块的 数据再次验证， 通过验证的交易数据按下一个高度发送给所有的共识节点， 对 于每个高度传送交易数据的吋候， 把交易哈希值的某几位写入位图表， 让用户 同吋提供不同的交易哈希值， 前置机选一个使之不与其他交易的位图重叠， 或 者放入后面或后面几个区块高度的位图表， 前置机可以按位图表的位置来放置 各交易哈希值， 并计算梅克尔树的哈希值， 前置机把数据传送给共识节点后， 可以通过位图表和梅克尔树的哈希值快速对比数据的一致性， 获取遗漏数据， 或剔除不一致的数据。
[0029] 前置机比较出已发送的 H+1高度的交易数据中未被写入共识区块 H+1的交易数 据， 作为 H+2高度的数据， 连同新收到的数据发送给所有的共识节点， 可规定每 个区块发送数据的上限， 超过上限的交易数据会归到 H+3高度的数据等到下一轮 发送。
工业实用性
[0030] 本发明的目的是引入前置机对共识交易数据进行分区分片预处理， 将校验过的 数据再发送到共识服务器， 共识服务器之间主要传送共识结果。
序列表自由内容
[0031] 本方法较好地分散了处理交易数据的负荷， 提高了区块链的共识效率。

Claims

权利要求书
[权利要求 1] 前置机参与区块链共识的方法， 其特征在于， 区块链生成新区块的步 骤如下；
步骤 Sl， 前置机取 2/3及以上的共识节点的最大高度 H， 力 作为最 新的区块高度；
步骤 S2， 前置机接收交易指令， 验证交易签名是否正确及是否符合交 易条件， 如支付不能超过该支付地址余额， 验证通过后附加步骤 S1确 定的区块高度 H+l， 签名后发送给其他所有的共识节点， 前置机在确 定新的 H+1高度作为本轮共识的区块高度， 可以约定一个超吋吋间 tl ， 超过超吋吋间后不再以 H+1区块高度发送交易数据；
步骤 S3， 若共识节点验证交易签名符合条件， 则将验证结果发送给其 他所有的共识节点， 共识节点收到 H+1高度的第一个数据后， 约定一 个超吋吋间 t2， 超过超吋吋间后不再接收任何 H+1高度的数据； 步骤 S4， 每个共识节点收到其他节点发过来的验证结果， 累计投票， 达到一定的票数后， 生成高度为 H+1的新区块， 新的 H+1区块头哈希 计算吋包含前一高度为 H的区块的头哈希值；
步骤 S5， 每个共识节点将高度为 H+1新区块发送到前置节点， 可包括 余额状态信息；
步骤 S6， 前置机比较出已发送的 H+1高度的交易数据中未被写入共识 区块 H+1的交易数据， 作为 H+2高度的数据， 连同新收到的数据发送 给所有的共识节点， 可规定每个区块发送数据的上限， 超过上限的交 易数据会归到 H+3高度的数据等到下一轮发送。
[权利要求 2] 根据权利 1所述前置机参与区块链共识的方法， 其特征在于， 前置机 可将支出地址分区， 如支付地址的前二位 00、 01、 10、 11分 4个区， 每个支付地址分区后再将交易哈希分片， 按附图 2步骤如下；
步骤 Sl， 用户将交易发送给支付账户地址的分区所在的那些前置 机， 每台前置机可以规定每个区块高度传送的最大笔数， 分区用户数 量越多分配的前置机越多， 可按交易哈希值来对用户数量的级别来取 模， 比如北京 3台前置机， 每个北京支付地址的交易， 根据不同的交 易哈希值取 3的模， 可以对应不同的前置机， 即使部分前置机损坏或 被攻击， 用户还可以变换交易哈希值通过其他前置机进入区块链共识 节点；
步骤 S2， 每个支出地址分区下的交易哈希分片的交易数据都是完全独 立的， 在对签名进行校验及正确计算余额后， 可依次或按同一高度的 数据打包发送给所有的区块链共识节点；
步骤 S3， 所有的共识节点收到所有前置机发送的同一高度的但完全独 立的交易数据， 可以多线程校验及计算余额， 可以将分区分片的交易 结果分送给其他所有的共识节点进行投票， 若共识节点的验证结果和 前置机验证结果一致， 再加一个本共识节点的私钥签名即可， 若有不 一致的数据， 则需要剔除， 将剔除的数据及共识结果的哈希值传送给 其他共识节点， 以便对比投票；
步骤 S4， 共识节点对分区分片的数据分别投票达成共识结果后， 打包 发给对应的分片前置节点， 分片前置节点对该分片的数据对比后， 把 前次已发送但未写入区块的数据再次验证， 通过验证的交易数据按下 一个高度发送给所有的共识节点。
[权利要求 3] 根据权利 1、 2所述前置机参与区块链共识的方法， 其特征在于， 对于 每个高度传送交易数据的吋候， 把交易哈希值的某几位写入位图表， 让用户同吋提供不同的交易哈希值， 前置机选一个使之不与其他交易 的位图重叠， 或者放入后面或后面几个区块高度的位图表， 前置机可 以按位图表的位置来放置各交易哈希值， 并计算梅克尔树的哈希值， 前置机把数据传送给共识节点后， 可以通过位图表和梅克尔树的哈希 值快速对比数据的一致性， 获取遗漏数据， 或剔除不一致的数据。
PCT/CN2017/094517 2017-07-26 2017-07-26 前置机参与区块链共识的方法 WO2019019056A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/094517 WO2019019056A1 (zh) 2017-07-26 2017-07-26 前置机参与区块链共识的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/094517 WO2019019056A1 (zh) 2017-07-26 2017-07-26 前置机参与区块链共识的方法

Publications (1)

Publication Number Publication Date
WO2019019056A1 true WO2019019056A1 (zh) 2019-01-31

Family

ID=65039954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/094517 WO2019019056A1 (zh) 2017-07-26 2017-07-26 前置机参与区块链共识的方法

Country Status (1)

Country Link
WO (1) WO2019019056A1 (zh)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110009347A (zh) * 2019-03-20 2019-07-12 深圳前海微众银行股份有限公司 一种区块链交易信息审计的方法及装置
CN110941673A (zh) * 2019-11-26 2020-03-31 中国人民解放军战略支援部队信息工程大学 区块链数据结构及任务处理方法和装置
CN111078686A (zh) * 2019-11-13 2020-04-28 上海交通大学 基于存储证明的区块链方法及系统
CN111127013A (zh) * 2019-12-24 2020-05-08 深圳大学 基于区块链的去中心化数据交易方法、装置、设备及介质
CN111405027A (zh) * 2020-03-12 2020-07-10 金蝶软件（中国）有限公司 区块链共识结果筛选方法、装置、计算机设备和存储介质
CN111415161A (zh) * 2020-04-27 2020-07-14 财付通支付科技有限公司 基于区块链的数据验证方法、装置及计算机可读存储介质
CN111427957A (zh) * 2020-03-26 2020-07-17 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质
CN111581286A (zh) * 2020-05-07 2020-08-25 成都汉为科技有限公司 一种基于一致性hash的能源区块链区块存储方法
CN111694693A (zh) * 2019-03-12 2020-09-22 上海晶赞融宣科技有限公司 数据流存储方法、装置以及计算机存储介质
CN111723406A (zh) * 2020-06-08 2020-09-29 上海朝夕网络技术有限公司 一种区块链的共识算法及系统
CN112347193A (zh) * 2020-11-27 2021-02-09 网易（杭州）网络有限公司 基于区块链的交易打包方法及装置、电子设备
CN115021945A (zh) * 2022-08-08 2022-09-06 四块科技(深圳)有限公司 区块链交易处理方法和系统
CN115293769A (zh) * 2022-10-08 2022-11-04 中铱数字科技有限公司 一种基于区块链的动态管理和校验节点系统
CN115310993A (zh) * 2022-10-12 2022-11-08 迅鳐成都科技有限公司 一种基于私有链的业务办理系统
WO2024066011A1 (zh) * 2022-09-30 2024-04-04 蚂蚁区块链科技(上海)有限公司 一种共识节点类型的转换方法和共识节点

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
CN105630609A (zh) * 2016-02-24 2016-06-01 杭州复杂美科技有限公司 区块链的打包存储方法
CN105719185A (zh) * 2016-01-22 2016-06-29 杭州复杂美科技有限公司 区块链的数据对比及共识方法
CN106296191A (zh) * 2016-08-13 2017-01-04 深圳市樊溪电子有限公司 一种区块链功耗感知的PoW共识机制
CN106445711A (zh) * 2016-08-28 2017-02-22 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
CN105719185A (zh) * 2016-01-22 2016-06-29 杭州复杂美科技有限公司 区块链的数据对比及共识方法
CN105630609A (zh) * 2016-02-24 2016-06-01 杭州复杂美科技有限公司 区块链的打包存储方法
CN106296191A (zh) * 2016-08-13 2017-01-04 深圳市樊溪电子有限公司 一种区块链功耗感知的PoW共识机制
CN106445711A (zh) * 2016-08-28 2017-02-22 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111694693A (zh) * 2019-03-12 2020-09-22 上海晶赞融宣科技有限公司 数据流存储方法、装置以及计算机存储介质
CN110009347B (zh) * 2019-03-20 2024-05-24 深圳前海微众银行股份有限公司 一种区块链交易信息审计的方法及装置
CN110009347A (zh) * 2019-03-20 2019-07-12 深圳前海微众银行股份有限公司 一种区块链交易信息审计的方法及装置
CN111078686A (zh) * 2019-11-13 2020-04-28 上海交通大学 基于存储证明的区块链方法及系统
CN111078686B (zh) * 2019-11-13 2023-06-06 上海交通大学 基于存储证明的区块链方法及系统
CN110941673B (zh) * 2019-11-26 2023-03-24 中国人民解放军战略支援部队信息工程大学 区块链数据结构及任务处理方法和装置
CN110941673A (zh) * 2019-11-26 2020-03-31 中国人民解放军战略支援部队信息工程大学 区块链数据结构及任务处理方法和装置
CN111127013A (zh) * 2019-12-24 2020-05-08 深圳大学 基于区块链的去中心化数据交易方法、装置、设备及介质
CN111127013B (zh) * 2019-12-24 2023-12-29 深圳大学 基于区块链的去中心化数据交易方法、装置、设备及介质
CN111405027A (zh) * 2020-03-12 2020-07-10 金蝶软件（中国）有限公司 区块链共识结果筛选方法、装置、计算机设备和存储介质
CN111427957A (zh) * 2020-03-26 2020-07-17 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质
CN111427957B (zh) * 2020-03-26 2021-05-11 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质
CN111415161A (zh) * 2020-04-27 2020-07-14 财付通支付科技有限公司 基于区块链的数据验证方法、装置及计算机可读存储介质
CN111415161B (zh) * 2020-04-27 2024-03-19 财付通支付科技有限公司 基于区块链的数据验证方法、装置及计算机可读存储介质
CN111581286B (zh) * 2020-05-07 2023-03-24 桂勋 一种基于一致性hash的能源区块链区块存储方法
CN111581286A (zh) * 2020-05-07 2020-08-25 成都汉为科技有限公司 一种基于一致性hash的能源区块链区块存储方法
CN111723406A (zh) * 2020-06-08 2020-09-29 上海朝夕网络技术有限公司 一种区块链的共识算法及系统
CN111723406B (zh) * 2020-06-08 2023-04-28 上海朝夕网络技术有限公司 一种区块链的共识算法及系统
CN112347193A (zh) * 2020-11-27 2021-02-09 网易（杭州）网络有限公司 基于区块链的交易打包方法及装置、电子设备
CN115021945B (zh) * 2022-08-08 2022-11-08 四块科技(深圳)有限公司 区块链交易处理方法和系统
CN115021945A (zh) * 2022-08-08 2022-09-06 四块科技(深圳)有限公司 区块链交易处理方法和系统
WO2024066011A1 (zh) * 2022-09-30 2024-04-04 蚂蚁区块链科技(上海)有限公司 一种共识节点类型的转换方法和共识节点
CN115293769B (zh) * 2022-10-08 2022-12-27 中铱数字科技有限公司 一种基于区块链的动态管理和校验节点系统
CN115293769A (zh) * 2022-10-08 2022-11-04 中铱数字科技有限公司 一种基于区块链的动态管理和校验节点系统
CN115310993A (zh) * 2022-10-12 2022-11-08 迅鳐成都科技有限公司 一种基于私有链的业务办理系统

Similar Documents

Publication Publication Date Title
WO2019019056A1 (zh) 前置机参与区块链共识的方法
CN109360100B (zh) 基于区块链技术的交易快速确认方法及装置
CN108241968B (zh) 前置机参与区块链共识的方法
CN107612973B (zh) 用于智能移动端的区块链结构、生成方法及交易验证方法
US20200259633A1 (en) Data storage and verification
US20170075941A1 (en) Consensus system and method for adding data to a blockchain
CA3037833C (en) System and method for information protection
TW202011329A (zh) 基於區塊鏈的交易共識處理方法及裝置、電子設備
US10819505B2 (en) System and method for information protection
CN112468302A (zh) 基于可验证多方秘密分享的可编辑区块链
US20240163121A1 (en) Blockchain consensus method, apparatus, and device, and storage medium
EP4191498A1 (en) Data communication method and apparatus, computer device, and storage medium
CN111092896A (zh) 基于优化paxos的食品溯源分布式数据同步方法
CN111698094B (zh) 一种基于区块链系统的共识方法及区块链系统
CN112260836A (zh) 一种基于分片技术提升区块链吞吐量的方法
CN113132401A (zh) 基于区块链的数据处理方法和装置
CN114862397B (zh) 一种基于双链结构的双解耦区块链分布式方法
CN114463009B (zh) 一种用于提高大规模能源节点交易安全性的方法
CN110505084B (zh) 一种区块链打包节点共识推举方法
US20220172180A1 (en) Method for Storing Transaction that Represents Asset Transfer to Distributed Network and Program for Same
CN112039837B (zh) 一种基于区块链和秘密共享的电子证据保全方法
CN112926983A (zh) 一种基于区块链的存证交易加密系统及方法
CN110706102B (zh) 一种用于联盟区块链的具有匿名性的多级签名方法
CN111756545A (zh) 一种基于区块链数字签名技术的合同认证方法
CN114745102B (zh) 一种基于边缘计算的轻量级且可扩展的区块链系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17918814

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17918814

Country of ref document: EP

Kind code of ref document: A1