A blockchain consensus protocol method easy to expand supervision

Abstract

The application discloses a kind of easily scalable regulatory blockchain consensus protocol methods, comprising the following steps: S1) two account nodes are as transaction participation party and self-organizing transaction Tx;And submit transaction to consensus network;S2) consensus node packs the transaction collected in this period to the latest stateless block, and the Merkle tree path proof is sent to the initiator of corresponding transaction party;S3) transaction participation initiator updates own local database accordingly, and local transaction record is sent to another transaction participation receiver along with witness information;S4) transaction participation receiver verifies transaction Tx and updates own local database.The application simultaneously satisfies to reach mainstream centralized transaction system absolute throughput and linear scalability;It can guarantee that the on-line time of account device is controllable;The practicality and decentralization of system are guaranteed by the dispersed state data storage, user-friendly, and easy to regulate.

Description

TECHNICAL FIELD

[0001] The present application relates to a blockchain consensus protocol method, in particular to an easy-to-expand, user-friendly and convenient-to-supervise blockchain consensus protocol method. BACKGROUND

[0002] Blockchain is a distributed and tamper-proof ledger technology. Its core idea is to link data in the form of blocks, each block containing the hash value of the previous block, forming a chain structure. The security of blockchain relies on cryptographic algorithms and consensus mechanisms to ensure data integrity and tamper resistance.

[0003] With the continuous development of blockchain applications, the amount of on-chain data has grown rapidly, leading to increasingly prominent performance bottlenecks of blockchain, mainly in low throughput, high transaction delay, high storage cost, etc. This limits the widespread application of blockchain technology.

[0004] Stateless blockchain is a solution to the problem of blockchain expansion. Its core idea is to separate the state information of the blockchain (such as account state, smart contract state, etc.) from the main chain, and only provide it when needed by the transaction initiator, so that the main chain nodes do not need to store complete state information, thereby reducing the burden of the main chain and improving throughput.

[0005] One of the key challenges faced by stateless blockchain is data availability. Since state information is not stored on the main chain, it is necessary to ensure that this data can be accessed when needed. To this end, stateless blockchain usually adopts some data availability solutions, such as:

[0006] Fraud Proofs: Allow any node to challenge invalid blocks or transactions and provide proof.

[0007] Data Availability Sampling: Nodes randomly sample a portion of block data to verify whether the data is available.

[0008] Erasure Coding: Divide data into multiple fragments and generate redundant fragments, so that even if some fragments are lost, the original data can be recovered.

[0009] Current technical solutions mainly include the following stateless blockchain solutions:

[0010] 1. Ethereum Stateless Client;

[0011] The Ethereum community is actively exploring the implementation of stateless clients, aiming to enable light clients to verify transactions without storing the complete state. This approach mainly relies on witness proofs, which contain all the necessary state information for verifying specific transactions. However, this approach has the following problems:

[0012] Witness updates frequently: Each state change requires an update to the witness, resulting in a large volume of witnesses and frequent updates, increasing network bandwidth consumption and storage pressure.

[0013] Dependence on third-party storage: Due to the large volume of witnesses, users often need to rely on third-party storage services to store witnesses, introducing centralization risks and potential security vulnerabilities.

[0014] 2、Celestia;

[0015] Celestia is a modular blockchain network that decouples the functions of a blockchain and focuses on providing a data availability layer. Celestia uses Data Availability Sampling (DAS) to ensure block data availability and allows other blockchains to build on its foundation, enabling off-chain storage of state. However, Celestia mainly focuses on data availability and does not provide a complete stateless blockchain solution, such as handling transaction execution and state updates.

[0016] 3、LazyLedger;

[0017] LazyLedger is a stateless blockchain solution based on "lazy verification". Its core idea is to delay transaction verification until it is needed, and nodes only need to verify transactions related to themselves, thereby reducing verification workload. LazyLedger uses erasure coding to ensure data availability and uses fraud-proof mechanisms to ensure the correctness of the state. However, the lazy verification mechanism of LazyLedger may cause transaction confirmation time to be prolonged, and the efficiency of its fraud-proof mechanism needs to be improved.

[0018] From the above, for end-to-end stateless blockchains, there are mainly three major challenges:

[0019] Main chain block size scalability problem: In traditional stateless blockchain design, the size of the main chain block will increase with the number of transactions, causing performance bottlenecks and scalability problems.

[0020] Coupling problem between user data updates and on-chain data updates: In traditional stateless blockchain design, users need to constantly monitor changes in the global ledger state and update their local data, which leads to coupling between user data updates and on-chain data updates, increasing the burden on users.

[0021] The problem of independent verification by regulators: In traditional stateless blockchain designs, it is difficult for regulators to independently verify the integrity and correctness of transaction history, and they need to rely on third-party storage services or other auxiliary means. Summary of the Invention

[0022] The technical problem to be solved by this invention is to provide a blockchain consensus protocol method that is easy to expand and regulate, has good scalability, is user-friendly, and is easy to regulate.

[0023] The technical solution adopted by this invention to solve the above-mentioned technical problems is to provide an easily scalable and regulated blockchain consensus protocol method, including the following steps: S1) Two account nodes, as the two parties involved in the transaction, self-organize to generate a transaction Tx and submit the transaction to the consensus network; S2) The consensus node packages the transactions collected in the current period into the latest stateless block and sends the Merkle tree path proof to the initiator of the corresponding two parties involved in the transaction; S3) The initiator of the transaction updates its local database accordingly and sends the local transaction record along with witness information to the receiver of the other party involved in the transaction; S4) The receiver of the transaction verifies the transaction Tx and updates its local database.

[0024] Furthermore, in step S1, one transaction is submitted within a block period; when the initiator of a transaction needs to submit multiple transactions, the multiple transactions are packaged and submitted, and the candidate block number is marked in each transaction to prevent malicious consensus nodes from submitting repeatedly.

[0025] Furthermore, step S2 generates a new stateless block. , Includes The addresses of both parties involved in all transactions during this period; It is by The roots of the Merkel tree, which represents all the transactions during that period; For other necessary block information.

[0026] Furthermore, the aforementioned This includes digital signatures, timestamps, block numbers, and nonce numbers.

[0027] Furthermore, in step S2, after sufficient transaction commits are collected in the consensus network's cache transaction pool, the transactions are packaged and uploaded to the blockchain; and the collected transactions are validated using a double Bloom filter.

[0028] Furthermore, in step S2, the consensus node verifies and obtains the Merkle tree path proof, and the initiator of the transaction quickly verifies the correctness of the new witness list through the main chain and sends it to the corresponding transaction recipient for verification.

[0029] Further, the verification of the receiving party of the transaction participation in step S4 includes whether the provided witness list meets the corresponding block's Merkle tree root, whether the witness and the transaction record of the initiator of the transaction participation completely match, and whether the current state of the initiator of the transaction participation is sufficient to support the transaction.

[0030] Further, it also includes a regulatory node for requesting all transaction histories of any node within any time period and verifying the integrity and correctness thereof.

[0031] Further, it also includes dividing the information of all account nodes into independent subsets, reading and modifying the local state only when two accounts conduct a transaction; and using a Bloom filter to record the set of account addresses whose states change within each block period after each successful transaction.

[0032] Further, the information of the account node includes transaction storage and Merkle tree proof storage . is divided into two parts and , represents the transaction data recorded when the account is the initiator of the transaction participation, represents the transaction data recorded when the account is the receiving party of the transaction participation.

[0033] is set .

[0034] For , first calculate the average number of transactions contained in the submitted single , which is , then calculate the number of transactions in which the account is the receiving party of the transaction participation, which is :

[0035] .

[0036] .

[0037] .

[0038] For , the number of unit witnesses is , and the size of a Merkle tree proof is , so we have:

[0039] .

[0040] n is the number of account nodes, t is the system running time, γ is the number of transactions per second of an account node; Δ is the system block interval, Stg( ) represents storage space.

[0041] The present application has the following beneficial effects compared with the prior art: the easy-to-expand and supervised blockchain consensus protocol method provided by the present application meets the absolute throughput and linear scalability of mainstream centralized transaction systems, can guarantee controllable free online duration of account devices, and the decentralized state data storage guarantees the practicability and decentralization of the system, is user-friendly, and is easy to supervise. BRIEF DESCRIPTION OF DRAWINGS

[0042] Figure 1 is a transaction flow chart of the easy-to-expand and supervised blockchain consensus protocol of the present application.

[0043] Figure 2 is a transaction verification flow chart of the supervisory node of the present application. DETAILED DESCRIPTION

[0044] The present application will be further described below in combination with the drawings and embodiments.

[0045] In the system model of the present application, the hash function is regarded as a random oracle, and the standard cryptographic assumptions in the system model (including but not limited to: public key signature, collective signature, hash function) are all mathematically secure. Any node in the system can obtain a correct genesis block. All nodes in the system model of the present application have a public-private key pair (VK, SK), and the public key VK of any node is public to other nodes.

[0046] The consensus network model of the present application is composed of consensus nodes, which generally have good communication links between them. The present system does not restrict the underlying consensus algorithm, but requires that its block data structure can meet (or be changed to) the design of the present system. The security analysis of the present system is based on the theoretical security of the selected consensus algorithm (for example, the proof-of-work (PoW) type blockchain tolerates at most half of the malicious computing power, and the Byzantine fault tolerance (BFT) type blockchain tolerates 1 / 3 malicious nodes).

[0047] There is no fixed network link topology between the account (Account) nodes of the present application, but any two nodes trying to transact can communicate. Accounts are generally only online when they need to transact and perform necessary processing, and will not be online for a long time. Account devices are usually consumer-grade personal computers, mobile phones and tablet computers.

[0048] For the adversary model, malicious nodes can corrupt any consensus node, but cannot exceed the tolerance limit of the consensus algorithm. Malicious nodes can perform any behavior that deviates from the original protocol, but cannot break the cryptography tools used by the system within a polynomial time.

[0049] Blockchain currently still faces many challenges, which are summarized as the "blockchain impossible triangle", that is, a blockchain system is difficult to meet: high scalability, security and decentralization. Earlier blockchain systems (layer-1) focus on security and decentralization, and are generally poor in performance. The currently active blockchain layer-2 is considered to be a solution to greatly improve scalability, and one of the important design paradigms is stateless blockchain (Stateless Blockchain, SBC). Unlike traditional blockchains, SBC removes most of the state information (such as transactions, contract execution, account status, etc.) from the main chain and transfers it to external storage or verification nodes for management. Its core is to improve the throughput and performance of the chain by reducing the amount of information that full nodes must store and verify (that is, only stateless information needs to be maintained). The stateless data on the chain generally includes commitments, which require users to store the corresponding witnesses. When submitting a transaction, the witness helps the verifier verify the legality of the transaction. The current mainstream SBC cryptography foundation includes: Merkle tree, RSA accumulator, vector commitments, etc.

[0050] But they all face a serious challenge: frequent witness updates. For a stateless account-based blockchain system implemented using a Merkle tree, the global state maintains a list of (account-balance pairs) account-balance pairs, and users need to store state proofs. When a user wants to transact, they need to provide proof that the state they provide exists in the global state (i.e., a Merkle tree path proof). However, when other nodes transact, the state of the Merkle tree will also be changed and affect most nodes that do not participate in the transaction, which requires them to also update the witness. From the user's perspective, they have to stay online all the time to deal with frequent witness updates, otherwise they will not be able to use their wallet. A compromise is to use a proof-serving node (PSN), which receives user-delegated update monitoring tasks. But this undoubtedly introduces additional devices (PSN generally requires server-level), and may introduce some delay and complexity, which puts higher requirements on the real-time performance and availability of the system. In addition, SBC weakens the ability of regulatory nodes. In traditional blockchains, regulatory nodes can obtain the complete transaction history by synchronizing full node data. But the SBC main chain only contains part of the transaction history information, and is non-plaintext (such as digest), which is anti-regulatory. And as mentioned earlier, the state plaintext data is stored in a third-party server, which further increases the difficulty of regulation.

[0051] After the above analysis, the challenges faced by the present application are as follows:

[0052] 1. Scalability: Ensure the lightweight of on-chain stateless data, reduce the storage and transmission cost of consensus network, and improve system efficiency;

[0053] 2. User-friendly: A large amount of complete state data is stored and transferred to the off-chain account node, which improves the utilization rate of user equipment. And the system does not violate the usage habits of ordinary users (users only need to be online when transacting) without introducing additional third-party storage services;

[0054] 3. Regulatory-friendly: Any regulatory node has the ability to independently verify the integrity and correctness of any account data combined with the main chain information, that is, any account cannot hide transaction history or provide false transaction history to the regulatory node.

[0055] Therefore, the present application proposes a new stateless blockchain framework system, called BMCHAIN. Through the redesign of on-chain stateless data and witness data, it meets the decoupling of user's local data update and on-chain data update. Users only need to be online and complete the operation when transacting, without needing to keep track of the changes in the global ledger status at all times, and they only need to store data related to their own interests, which solves challenge 2. The simple design concept of BMCHAIN is shown in Figure 1 The stateless block only records: i) the set of account addresses whose state changes in each round (within each block period) (by using a Bloom filter); ii) the tree root of the Merkle tree formed by each round of transactions and iii) other related data (timestamp, version number, height, etc.), which indicates that the size of the main chain block is almost fixed (usually controlled within 2MB) and is independent of the number of transactions, which solves challenge 1. In BMCHAIN, the order of transaction history and summary-related information are all included in the stateless information of the main chain, and the Bloom filter and the Merkle tree root can ensure the integrity and correctness of the history, respectively, so the verification of the transaction history of the account can be completed independently by any node (including regulatory nodes) combined with the BMCHAIN main chain, which solves challenge 3. In addition, the present application has carried out detailed theoretical analysis on BMCHAIN in terms of security, performance, etc., and realized a prototype system based on BMCHAIN, and detected a number of performance indicators including throughput and transaction delay. The conclusion shows that BMCHAIN can meet the following requirements at the same time: reach the absolute throughput and linear scalability of mainstream centralized transaction systems; short transaction delay ensures the controllable free online time of account equipment; decentralized state data storage ensures the practicality and decentralization of the system.

[0056] Please refer to Figure 1 The easy-to-expand regulatory blockchain consensus protocol method provided by the present application, the transaction between Alice and Bob is self-organized and submit the transaction to the consensus network (transaction pool), the consensus node will package the transactions collected in the current period (block ) into the latest stateless block , where i) contains the addresses of all payers and payees (transaction participants, payer is the initiator of transaction participation, payee is the receiver of transaction participation) during ; ii) is the tree root of the Merkle tree composed of all transactions during ; iii) is other necessary block information (e.g., digital signature, timestamp, block number, nonce random number, etc.). After the new block is confirmed, the consensus node sends the Merkle tree path proof to the corresponding transaction parties payer, payer updates its local database according to the proof, and sends the local transaction record together with the witness information (i.e., the Merkle tree path proof) to the payee. Payee verifies: i) whether the witness and payer's transaction record match completely ii) whether the current payer's state is sufficient to support this transaction. If the verification is passed, the payee also updates the local database. The main algorithm is as follows:

[0057] Step 1: payer and payee generate and send it to the consensus network.

[0058] Step 2: consensus node collects all and generates a new block

[0059] by .

[0060] Step 3. Broadcast the new block to the consensus network, and other consensus nodes verify this block by function.

[0061] Step 4: consensus node and payer

[0062] .

[0063] Step 5: payer and payee verify the witness list sent by payer by function, and update their local database according to the test result.

[0064] 1. Algorithm components;

[0065] ​: input data of arbitrary length, output hash value of data.

[0066] : input several data , output merkle tree whose leaf node is .

[0067] : input merkle tree and one of its leaf node , output path proof from to root node.

[0068] : input merkle tree , output root node of .

[0069] : input several data , concatenate these data and output.

[0070] : input message and target node , transfer to by p2p.

[0071] : input message and network , broadcast to .

[0072] : input index number , get block of height from consensus network.

[0073] : input function and parameter , send request to consensus network to get output of .

[0074] : input several numbers , output .

[0075] : access object ​variables (or methods) in .

[0076] 2. transaction submission module;

[0077] By design, payer is unable to submit more than one transaction in a block period, as the bloom filter can only prove its membership but cannot contain the number of submitted transactions. If payer needs to submit multiple transactions, it should submit these transactions in a package. In addition, payer needs to mark the candidate block number in each transaction to prevent repeated submission by malicious consensus nodes. Formally, if payer needs to submit to , then, The formalization is as algorithm 2, where is the public transaction pool.

[0078] Algorithm 2. Algorithm;

[0079] INPUT: None;

[0080] OUTPUT: None;

[0081] List ;

[0082] For do:

[0083] ;

[0084] ;

[0085] ;

[0086] ;

[0087] ;

[0088] .

[0089] 3. block generation, broadcast and verification module;

[0090] After the consensus network's cache transaction pool collects enough transactions, it is packaged and chained. In the broadcast and verification phase of the block, the transactions are not verified by the consensus nodes for legality except for the signature, that is, the data in the block actually allows the existence of illegal transactions such as double spending. But the consensus nodes need to ensure that payer does not submit more than one To the block, so some extra messages need to be broadcast to assist the verification of the block. In addition, BMCHAIN adopts the design of double Bloom filter in practice, which will obtain the advantage in the communication cost and practicability. Then The algorithm is formalized as follows:

[0091] Algorithm 3. Algorithm;

[0092] INPUT: ;

[0093] OUTPUT: None;

[0094] List ;

[0095] Bloom filter ;

[0096] For do:

[0097] If :

[0098] Continue;

[0099] For do:

[0100] If :

[0101] ;

[0102] else:

[0103] Continue;

[0104] ;

[0105] ;

[0106] ;

[0107] ;

[0108] ;

[0109] ;

[0110] .

[0111] Algorithm 4. Algorithm;

[0112] INPUT: ;

[0113] OUTPUT: None;

[0114] detect , if not pass then reject and return.

[0115] ;

[0116] If :

[0117] reject and return;

[0118] add to the local blockchain.

[0119] 4, update witness module;

[0120] The updated witness is generated by consensus nodes through (algorithm x) and transmitted to the corresponding payer, where and represent verification and obtaining merkle tree path proof respectively. The payer can quickly verify the correctness of the new witness through the main chain, and send it to the corresponding payee for verification.

[0121] Algorithm 5. algorithm;

[0122] INPUT: ;

[0123] OUTPUT: None;

[0124] For do:

[0125] ;

[0126] ;

[0127] ;

[0128] If :

[0129] ;

[0130] ;

[0131] For do:

[0132] ;

[0133] Preferably, the Merkle tree and its path proof algorithm used by the present application A Verkle tree (Kuszmaul, John. "Verkle trees." Verkle Trees 1.1 (2019)) and its path proof algorithm can be used instead. The Verkle tree is a data structure designed to improve the efficiency and scalability of the Merkle tree, which optimizes the traditional Merkle tree structure by introducing vector commitments (specifically, Pedersen commitments based on elliptic curves), thereby significantly reducing storage and computing requirements while ensuring security.

[0134] In the present scheme, the use of the Verkle tree can make the account provide a much smaller proof when providing a path proof. Specifically, the prover no longer needs to provide all the neighbor nodes at all levels on the path, but only needs to provide an evidence of the parent-child relationship between all commitment values on the path from the root node to the target leaf node. Just this one thing can reduce the size of the evidence by about 6-8 times (compared to the ideal Merkle tree), and this advantage will further expand as the number of transactions increases.

[0135] 5. Payee verification module;

[0136] The payee verifies the legality of the witness list provided by the payer, specifically: i) whether the provided witness (W) satisfies the Merkle tree root of the corresponding block; ii) whether the transaction (T) corresponds to the leaf node of (H(W, T)) and whether the content of (T) is correct.

[0137] Algorithm 6. Algorithm;

[0138] INPUT: ;

[0139] OUTPUT: verification result (Boolean value);

[0140] ;

[0141] ;

[0142] ;

[0143] If :

[0144] Return False;

[0145] If :​​​​

[0146] Return False;

[0147] If :

[0148] Return False;

[0149] ;

[0150] Return True.

[0151] 6、Supervision verification module;

[0152] The supervision node can inquire all transaction histories of any node within any time period and verify its integrity and correctness (its flow is shown in Figure 2 . In algorithm 7, the supervision node queries the detection result to the consensus network. In fact, the supervision node can run the BMCHAIN full node (without participating in the consensus) to independently complete all verification operations.

[0153] Algorithm 7. Supervision verification algorithm;

[0154] INPUT: / / Detect All transactions of the node from block to interval.

[0155] OUTPUT: None;

[0156] The supervision node asks the account for all transaction histories between and .

[0157] ;

[0158] ;

[0159] ;

[0160] If :

[0161] Handle according to the supervision requirement.

[0162] else:

[0163] Reject .

[0164] Algorithm 8. Algorithm;​

[0165] INPUT: ;

[0166] OUTPUT: Verification result (Boolean value);

[0167] ;

[0168] ;

[0169] ;

[0170] ;

[0171] By detecting and , if failed, return False.

[0172] For do:

[0173] If :

[0174] Return False;

[0175] Return True.

[0176] The technical innovation points of the application mainly include the following:

[0177] 1. A new block data structure is used, and the core components are: Merkel tree + Bloom filter, the former contains the necessary information of all transactions during this block period, and the latter contains the necessary information of the accounts participating in the transaction. Because the storage space of these two core components is (almost) fixed size, this innovation solves the problem of storage pressure on the chain, that is, the storage of the block on the chain will only increase linearly with the running time of the system, but will not be affected by the number of system nodes, the number of transaction processing, etc. This provides the possibility for the horizontal expansion of the blockchain system.

[0178] 2. A new on-chain and off-chain joint transaction verification algorithm (algorithms 2~8) is designed. Thanks to these algorithms, the system meets: 1) Users can independently control online time without worrying about the monitoring pressure of the whole network caused by frequent witness updates; 2) Consensus nodes do not need to bear the storage pressure of state data, because these state data are completely stored locally by users; 3) A regulatory interface is provided for regulatory nodes, which can ensure high performance while also enabling precise traceability and supervision.

[0179] The innovative achievements of the application have the following beneficial effects:

[0180] 1. Support users to choose online time arbitrarily;

[0181] In addition to the stateless main chain, the BMCHAIN model divides all account information into independent subsets. Most of the time, the BMCHAIN account is static, and only when two accounts transact, the local state of the account needs to be read and modified. Therefore, the BMCHAIN account node can freely choose the transaction and online time without monitoring the state changes of the global network at all times, which well solves the problem of account offline. Even if the payee is offline, the payer can still complete the transaction and chain operation alone, and then complete the transmission and verification of the witness when the payee is online, which also conforms to the normal user's transaction habits.

[0182] According to the proof of "witness change" and inference 1 (No useful trade-offs) in the literature M. Christ and J. Bonneau, "Limits on revocable proof systems, with applications to stateless blockchains," Cryptology ePrint Archive, Paper 2022 / 1478, 2022, when deleting elements (for example, spending unspent transaction outputs (UTXOs) in a block), most existing stateless blockchains cannot achieve a favorable trade-off between the global state size and the frequency of proof changes. That is, the global state size must be linearly related to the size of the storage set, or the number of proofs needs to be updated orders of magnitude, where is the number of accounts. In addition, these updates are unpredictable and random for accounts. This conclusion shows that as the amount of submitted transactions increases, the online frequency required by all accounts is almost linear. However, under the BMCHAIN model, the frequency of account online is independent of the overall transaction frequency, but is positively related to its own transaction frequency.

[0183] 2. The storage costs of users and consensus nodes are balanced and dispersed;

[0184] The storage cost of the account, i.e. , is mainly composed of transaction storage and Merkle tree proof storage , that is, . The following analyzes each item one by one. First, the invention defines some needed variables:

[0185]

[0186] For , it is mainly divided into two parts and , which respectively represent the transaction data recorded when the account is payer and payee. According to the definition, there are . For , first, the average number of transactions contained in the submitted single is calculated as , then the number of transactions of the account as payee is calculated as , so:

[0187] .

[0188] In summary, the present application has:

[0189] ;

[0190] .

[0191] For , it is known that the number of unit witnesses is , and the size of a witness (Merkle tree proof) is , so:

[0192] .

[0193] Since and are generally constants during system operation, it is obtained that:

[0194] .

[0195] This ensures that the account storage cost is only positively related to the logarithm of time and the size of the account network, which is close to the storage cost of traditional centralized transaction accounts , and reaches a practical level.

[0196] In order to intuitively show the permanent storage cost of the account of BMCHAIN, the present application makes appropriate assignment to some variables in the foregoing, which are as follows:

[0197] tps, sampled from the real daily transaction data of a number of volunteers;

[0198] sec, the average block time of Ethereum is selected;

[0199] Bytes, the transaction size without additional data of Ethereum is selected;

[0200] Bytes, the size of the Merkle tree node based on Keccak-256 algorithm (used in Ethereum) is selected.

[0201] The calculation results show that: The linear increase of does not cause the linear increase of the account storage of BMCHAIN (in fact, it is a logarithmic relationship). Compared with the traditional centralized transaction system (the account only stores the transaction data related to itself), there is no order of magnitude difference in the account storage of BMCHAIN, and in small (10000~50000), the difference between the two is not more than one time. Even in the case of super large scale (1000000), the average account storage of BMCHAIN system after one year is only about 1.7 MB, which is completely acceptable.

[0202] 3、Effectively reduce the communication, calculation and cache costs of the account and the regulatory node;

[0203] According to the witness verification algorithm design of BMchain, the upper bound of the communication and calculation cache of the account node is the capacity of witness+Txs, which is , in the case of , fixed, it is only proportional to , which is completely acceptable for the current personal mobile devices and network bandwidth.

[0204] For the regulatory node, in the regulatory verification, the upper bound of the transmission and verification calculation cache is equivalent to the capacity of payer , because in the worst case, the regulatory node needs all the local data of the account (i.e. ). With the same parameters as in the last subsection, the expected value of the upper bound of the communication and calculation cache of the regulatory node is about 170 MB in a long enough time (for example: 100 years). This is completely acceptable for the current regulatory devices and network bandwidth.

[0205] Although the present application has been disclosed with the above preferred embodiments, it is not intended to limit the present application, and any person skilled in the art can make some modifications and improvements without departing from the spirit and scope of the present application, therefore the protection scope of the present application should be defined by the claims.​

Claims

1. A method for a scalable and regulated blockchain consensus protocol, the method comprising: receiving a transaction from a user; validating the transaction; and broadcasting the transaction to a plurality of nodes in a blockchain network. Comprising the following steps: S1) two account nodes as transaction participating parties self-organize a transaction ; and submit the transaction to the consensus network; S2) The consensus node packs the transactions collected in the current period into the latest stateless block and sends the Merkle tree path proof to the corresponding transaction participants; S3) The transaction participants update their local database accordingly and send the local transaction record together with the witness information to the other transaction participants; S4) The receiving party of the transaction verifies and updates its own local database. performs the verification and updates its own local database.

2. The easily scalable regulated blockchain consensus protocol method of claim 1, wherein, The step S1 submits 1 transaction in a block period; when the transaction participants need to submit multiple transactions, multiple transactions are packed and submitted, and the candidate block number is marked in each transaction to prevent repeated submission by malicious consensus nodes.

3. The scalable-governed blockchain consensus protocol method of claim 1, wherein, Step S2 generates a new stateless block. , Includes The addresses of both parties involved in all transactions during this period; It is by The roots of the Merkel tree, which represents all the transactions during that period; For other necessary block information.

4. The easily scalable regulated blockchain consensus protocol method of claim 3, wherein, The includes a digital signature, a timestamp, a block number, and a nonce random number.

5. The scalable-governance blockchain consensus protocol method of claim 1, wherein, The step S2 collects enough transactions in the cache transaction pool of the consensus network and then packs and chains them; and uses double bloom filter to verify the legality of the collected transactions.

6. The easily scalable regulated blockchain consensus protocol method of claim 1, wherein, The consensus node in step S2 verifies and obtains the Merkle tree path proof, and the transaction participants verify the correctness of the new witness list through the main chain and send it to the corresponding transaction participants for verification.

7. The easily scalable regulated blockchain consensus protocol method of claim 6, wherein, The verification of the transaction participants in step S4 includes whether the provided witness list meets the Merkle tree root of the corresponding block, whether the witness and the transaction record of the transaction participants match completely, and whether the current state of the transaction participants is sufficient to support the transaction.

8. The scalable-governance blockchain consensus protocol method of claim 1, wherein, Also includes a regulatory node for requesting all transaction histories of any node within any time period and verifying their integrity and correctness.

9. The scalable-governance blockchain consensus protocol method of claim 1, wherein, Also includes dividing the information of all account nodes into independent subsets, reading and modifying the local state only when two accounts conduct transactions; and using a bloom filter to record the account address set whose state changes in each block period after each transaction is successfully completed.

10. The easily scalable regulated blockchain consensus protocol method of claim 9, wherein, The information of the account node includes a transaction storage and a Merkle tree proof storage ; In two parts And , Transaction data recorded when the account acts as an initiator of a transaction, Transaction data recorded when the account acts as a recipient of a transaction; Set ; For , the average number of transactions contained in the submitted individual is first calculated as , and the number of transactions in which the account participated as a recipient is then calculated as : ； ； ； For , the number of unit witnesses is , and the size of one Merkle tree proof is , thus we have: ； n is the number of account nodes, t is the system running time, and γ is the number of transactions per second of an account node; Δ is the system block interval, Stg( ) represents storage space.

Images