Block chain consensus protocol method easy to expand and supervise

Abstract

The invention discloses a block chain consensus protocol method easy to expand and supervise. The block chain consensus protocol method comprises the following steps: S1) two account nodes serve as transaction participants to generate a transaction Tx in a self-organization manner; submitting the transaction to a consensus network; s2) the consensus node packages the affairs collected in the period to a latest stateless block, and sends Merkel tree path proof to the two corresponding affair parties; s3) the initiator participating in the transaction updates the local database of the initiator, and sends the local transaction record and the witness information to the receiver participating in another transaction; and S4) the transaction participating receiver verifies the transaction Tx and updates the local database thereof. According to the method, the absolute throughput and the linear expandability of a mainstream centralized transaction system are met at the same time; the controllable free online duration of the account equipment can be ensured; the scattered state data storage ensures the practicability and decentralization of the system, and the system is user-friendly and easy to supervise.

Description

Technical Field

[0001] The present invention relates to a blockchain consensus protocol method, and in particular to a blockchain consensus protocol method that is easily expandable, user-friendly, and convenient to supervise. Background Art

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

[0003] With the continuous development of blockchain applications, the amount of data on the chain has increased dramatically, resulting in increasingly prominent performance bottlenecks in blockchain, mainly reflected in low throughput, high transaction latency, high storage costs, etc. This has limited the widespread application of blockchain technology.

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

[0005] A key challenge facing stateless blockchains 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 blockchains usually adopt some data availability solutions, such as:

[0006] Fraud Proofs: Allows 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 the original data can be restored even if some fragments are lost.

[0009] The existing 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, with the goal of enabling light clients to verify transactions without storing the full state. This solution mainly relies on witness proofs, which contain all the state information required to verify a specific transaction. However, this solution has the following problems:

[0012] Frequent witness updates: The witness needs to be updated every time the state changes, which results in a large witness size and frequent updates, increasing network bandwidth consumption and storage pressure.

[0013] Reliance on third-party storage: Due to the large size of witnesses, users usually need to rely on third-party storage services to store witnesses, which introduces centralization risks and potential security risks.

[0014] 2. Celestia

[0015] Celestia is a modular blockchain network that decouples the functionality of blockchains and focuses on providing a data availability layer. Celestia uses Data Availability Sampling (DAS) to ensure block data is available and allows other blockchains to build on it to achieve off-chain storage of state. However, Celestia focuses mainly on data availability and does not provide a complete stateless blockchain solution, for example, it does not handle transaction execution and state updates.

[0016] 3. LazyLedger

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

[0018] As can be seen above, there are three main challenges for end-to-end stateless blockchain:

[0019] Scalability issues of main chain block size: In traditional stateless blockchain designs, the size of main chain blocks will increase as the number of transactions increases, leading to performance bottlenecks and scalability issues.

[0020] The coupling problem between user data updates and on-chain data updates: In the traditional stateless blockchain design, users need to always pay attention to changes in the global ledger status and update their local data, which leads to the coupling of user data updates and on-chain data updates, increasing the burden on users.

[0021] Independent verification problem of supervision: In the traditional stateless blockchain design, it is difficult for regulatory nodes 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 the present invention is to provide a blockchain consensus protocol method that is easily scalable and regulated, with good scalability, user-friendliness, and easy supervision.

[0023] The technical solution adopted by the present invention to solve the above technical problems is to provide a blockchain consensus protocol method that is easy to expand and regulate, including the following steps: S1) two account nodes as transaction participants self-organize to generate transaction Tx; and submit the transaction to the consensus network; S2) the consensus node packages the transactions collected in this cycle into the latest stateless block, and sends the Merkle tree path proof to the corresponding transaction parties; S3) the initiator of the transaction participant updates its local database accordingly, and sends the local transaction record together with the witness information to the recipient of another transaction participant; S4) the recipient of the transaction participant verifies the transaction Tx and updates its local database.

[0024] Furthermore, step S1 submits one transaction within one block cycle; when the initiator of the 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 repeated submission by malicious consensus nodes.

[0025] Furthermore, the step S2 generates a new stateless block B i+1 =<bf,mtr,δ> , bf contains B i+1 The addresses of both parties involved in all transactions during the period; mtr is the address of B i+1 The root of the Merkle tree composed of all transactions during the period; δ is other necessary block information.

[0026] Furthermore, the δ includes a digital signature, a timestamp, a block number and a Nonce random number.

[0027] Furthermore, in step S2, after the consensus network sets up a cache transaction pool to collect enough transaction submissions, the transactions are packaged and uploaded to the chain; and the collected transactions are verified for legitimacy using a double Bloom filter.

[0028] Furthermore, the consensus node in step S2 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 recipient of the transaction for verification.

[0029] Furthermore, the verification of the recipient of the transaction in step S4 includes: whether the witness list provided satisfies the Merkle tree root of the corresponding block, whether the transaction records of the witness and the initiator of the transaction are completely matched, and whether the status of the initiator of the current transaction is sufficient to support this transaction.

[0030] Furthermore, it also includes a supervisory node for requesting all transaction histories of any node in any time period and verifying its integrity and correctness.

[0031] Furthermore, it also includes dividing the information of all account nodes into independent subsets, and only when two accounts conduct transactions, their local states are read and modified; and after each transaction is successfully completed, a Bloom filter is used to record the set of account addresses whose states have changed within each block cycle.

[0032] Furthermore, the information of the account node includes transaction storage S txs And the Merkle tree proves the storage S witness ; S txs Divided into two parts and Indicates the transaction data recorded when the account is the initiator of the transaction. Indicates transaction data recorded when an account participates as a recipient of a transaction;

[0033] set up

[0034] for First, calculate the average number of transactions contained in a single submitted Txs as γnΔ / (nn(1-2 / n) γnΔ ), and then calculate the number of transactions in which the account participates as the recipient of the transaction as γtn / (n-1):

[0035]

[0036] For S witness , the number of unit witnesses is (γt+γtn / (n-1)), and the size of a Merkle tree proof is max(1,log(nγΔ))·Stg(mtnode), so:

[0037] S witness =(γt+γtn / (n-1))·max(1,log(nγΔ))·Stg(mtnode);

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

[0039] Compared with the prior art, the present invention has the following beneficial effects: the blockchain consensus protocol method that is easily scalable and regulated provided by the present invention can simultaneously meet the absolute throughput and linear scalability of the mainstream centralized transaction system; it can ensure the controllable free online time of the account device; the decentralized state data storage ensures the practicality and decentralization of the system, is user-friendly, and easy to regulate. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a transaction flow chart of the blockchain consensus protocol that is easily scalable and regulated by the present invention;

[0041] Figure 2 This is a transaction verification flow chart of the supervisory node of the present invention. DETAILED DESCRIPTION

[0042] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0043] In the system model of the present invention, 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 the correct genesis block. All nodes in the system model of the present invention have a public-private key pair (VK, SK), and the public key VK of any node is public to other nodes.

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

[0045] There is no fixed network connection topology between the account nodes of the present invention, but any two nodes attempting transactions can communicate. Accounts are generally only online when transactions are required and necessary processing is performed, and they will not be online for a long time. Account devices are usually consumer-grade personal computers, mobile phones, and tablets.

[0046] For the adversary model, malicious nodes can corrupt any consensus node, but cannot exceed the tolerance limit of the consensus algorithm. Malicious nodes can make any behavior that deviates from the original protocol, but cannot crack the cryptographic tools used by the system in polynomial time.

[0047] Blockchain is still facing many challenges, which are summarized as the "blockchain impossible triangle", that is, it is difficult for a blockchain system to simultaneously meet: high scalability, security and decentralization. The earlier blockchain system (layer-1) focused on security and decentralization, and performed generally in terms of performance. The currently active blockchain layer-2 is considered to be a solution to greatly improve scalability. One of the important design paradigms is the stateless blockchain (SBC). Unlike traditional blockchains, SBC removes most 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 the full node must store and verify (that is, only stateless information needs to be maintained). Stateless data on the chain generally includes commitments, which require users to store corresponding witnesses. When submitting a transaction, the witness assists the verifier in verifying the legitimacy of this transaction. The current mainstream SBC cryptographic foundations include: Merkle tree, RSA accumulator, vector commitments, etc.

[0048] But they all face a severe challenge: frequent witness updates. For an account-based blockchain system that uses Merkle trees to implement statelessness, the global state maintains a list of account-balance pairs, and users need to store state proofs. When a user wants a transaction, he needs to provide proof that the state he provides exists in the global state (i.e., the path proof of the Merkle tree). However, when other nodes conduct transactions, the state of the Merkle tree will also be changed and affect most of the nodes that are not involved in the transaction, which requires them to also perform witness updates. From the user's perspective, they have to stay online at all times to cope with frequent witness updates, otherwise they will not be able to use their wallets. A compromise is to use a proof-serving node (PSN), which receives update monitoring tasks entrusted by users. But this undoubtedly introduces additional equipment (generally PSN requires server level), and may introduce certain delays and complexity, which puts higher requirements on the real-time and availability of the system. In addition, SBC weakens the ability of the supervisory node. In traditional blockchains, supervisory nodes can obtain complete transaction history by synchronizing full node data. However, the SBC main chain only contains part of the transaction history information, and it is non-plaintext (such as summary), which is resistant to supervision. And as mentioned above, the state plaintext data is stored in a third-party server, which makes supervision more difficult.

[0049] After the above analysis, it can be seen that the challenges faced by the present invention are as follows:

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

[0051] 2. User-friendly: A large amount of complete state data storage is transferred to the account node under the chain, which improves the utilization rate of user equipment. And ensure that the system does not violate the usage habits of regular users without introducing additional third-party storage services (users only need to stay online during transactions);

[0052] 3. Regulatory-friendly: Any regulatory node has the ability to independently verify the integrity and correctness of any account data in combination with the main chain information. That is, no account can hide the transaction history from the regulatory node or provide false transaction history.

[0053] To this end, the present invention proposes a new stateless blockchain framework system, called BMCHAIN. It satisfies the decoupling of local data updates from on-chain data updates by redesigning on-chain stateless data and witness data. Users only need to go online and complete operations when conducting transactions, without having to pay attention to changes in the global ledger status. They only need to store data related to their own interests, which solves Challenge 2. An example of the concise design concept of BMCHAIN ​​is as follows: Figure 1 As shown, the stateless block only records: i) the set of account addresses whose states change in each round (within each block cycle) (by using a Bloom filter); ii) the root of the Merkle tree formed by each round of transactions and iii) other related data (timestamp, version number, height, etc.), which shows that the size of the main chain block is almost fixed (generally controlled within 2MB) and has nothing to do with the number of transactions, which solves Challenge 1. In BMCHAIN, the order and summary-related information of the transaction history are included in the stateless information of the main chain. The Bloom filter and the Merkle tree root can respectively ensure the integrity and correctness of the history. Therefore, the transaction history verification of the account can be completed by any node (including the regulatory node) independently in combination with the BMCHAIN ​​main chain, which solves Challenge 3. In addition, the present invention conducts a detailed theoretical analysis of BMCHAIN ​​in terms of security and performance, and implements a prototype system based on BMCHAIN, and tests multiple performance indicators including throughput and transaction latency in detail. The conclusion shows that BMCHAIN ​​can simultaneously meet the following requirements: achieving the absolute throughput and linear scalability of mainstream centralized transaction systems; short transaction delays ensure the controllable free online time of account devices; and decentralized state data storage ensures the practicality and decentralization of the system.

[0054] See also Figure 1 , the blockchain consensus protocol method with easy scalability and supervision provided by the present invention, the two parties of the transaction Alice and Bob self-organize to generate the transaction Tx= <Addr Bob,v,sig,δ>, and submit the transaction to the consensus network (transaction pool), the consensus node will i+1 ) are packaged into the latest stateless block B i+1 =<bf,mtr,δ> , where i)bf contains B i+1 The addresses of all payers and payees (participants in the transaction, payer is the initiator of the transaction, payee is the recipient of the transaction) during the period; ii) mtr is the address of B i+1 The root of the Merkle tree composed of all transactions during the period; iii) δ is other necessary block information (for example, 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, the payer, and the payee updates its local database accordingly, and sends the local transaction record together with the witness information (ie, the Merkle tree path proof) to the payee. Payee verifies: i) whether the transaction records of the witness and the payer completely match ii) whether the current state of the payer is sufficient to support this transaction. If the verification is successful, the payee also updates the local database. The main algorithm is as follows:

[0055] Payer and payee execute Step 1: Payer and payee create tx The function generates Tx and sends it to the consensus network.

[0056] Consensus node executes Step 2: The consensus node collects all Txs and passes

[0057] Creat b;ock (Txs,Addr payer list,Addr payee list,δ), generate a new block B i+1 .

[0058] Step 3. Broadcast the new block to the consensus network, and other consensus nodes pass Verify block Function validates this block.

[0059] The consensus node and payer execute Step 4:

[0060] UpdateAndSendWitness(B i+1 ,mt).

[0061] Payer and payee execute Step 5: Payee passes Ver witness The function verifies the witness list sent by the payer and updates its local database according to the test results.

[0062] 1. Algorithm components

[0063] Hash(): Input data of any length and output the hash value of data.

[0064] MerkleTree(): Input some data {data1, data2, ...}, and output a Merkle tree whose leaf nodes are {data1, data2, ...}.

[0065] Path(): Input the Merkle tree mt and one of its leaf nodes ln, and output the path proof from ln to the root node of mt.

[0066] Root(): Input the Merkle tree mt and output the root node of mt

[0067] Cat(): Input several data {data1, data2, ...}, concatenate these data and then output them.

[0068] send(): Input message msg and target node p, send(msg,p) transmits msg to p via p2p.

[0069] Broadcast(): Input message msg and network net, Broadcast(msg,net) broadcasts msg to net.

[0070] GetBlock(): Enter index number i, GetBlock(i) gets block B at height i from the consensus network i .

[0071] Request(): Input function func and parameter parms, Request(func,parms) sends a request to the consensus network to obtain the output of func(parms).

[0072] Sum(): Input several numbers {num1, num2, ...}, output

[0073] xy: Access variable (or method) y in object x.

[0074] 2. Transaction submission module

[0075] By design, a payer cannot submit more than one transaction in a block cycle, because the Bloom filter can only prove its membership but cannot contain information about the number of transactions submitted. If a payer needs to submit multiple transactions, they should submit them in a package. In addition, the payer needs to mark the candidate block number in each transaction to prevent repeated submission by malicious consensus nodes. Formally, if a payer needs to submit Tx1, Tx2, …, Tx k Submit to B i+1 , then, CreatTx is formalized as Algorithm 2, where TxPool is the public transaction pool.

[0076] Algorithm 2. CreatTx algorithm

[0077] INPUT:None

[0078] OUTPUT:None

[0079] List

[0080] For do:

[0081] Tx′← <Tx,i+1,sig payer >

[0082]

[0083] Txs←{Tx′1,Tx′2,…,Tx′ k}

[0084] HashTxs←Hash(Cat(Txs))

[0085] msg← <Txs,HashTxs,Addr payer >

[0086] Send(msg,TxPool)

[0087] 3. Block generation, broadcasting and verification modules

[0088] After the cached transaction pool of the consensus network collects enough transaction submissions, it will be packaged and uploaded to the chain. During the broadcast and verification phase of the block, the consensus node does not verify the legitimacy of the transaction except for the signature, that is, the data in the block actually allows illegal transactions such as double spending to exist. However, the consensus node needs to ensure that the payer does not submit more than one Txs to the block, so it is necessary to broadcast some additional messages to assist in the verification of the block. In addition, in practice, BMCHAIN ​​adopts a dual Bloom filter design, which will gain advantages in communication cost and practicality. Then the CreatBlock algorithm is formalized as follows:

[0089] Algorithm 3. CreateBlock algorithm

[0090]

[0091] Algorithm 4. VerifyBlock algorithm

[0092]

[0093] 4. Update the witness module

[0094] The updated witness is generated by the consensus node through UpdateAndSendWitness (algorithm x) and transmitted to the corresponding payer, where VerifyPath() and GetPath() 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.

[0095] Algorithm 5. UpdateAndSendWitness algorithm

[0096]

[0097]

[0098] Preferably, the Merkle tree and its path proof algorithm Path() used in the present invention can be replaced by the Walker tree (Kuszmaul, John. "Verkle trees." Verkle Trees 1.1 (2019)) and its path proof algorithm. The Walker tree is a data structure that aims to improve the efficiency and scalability of the Merkle tree. It optimizes the traditional Merkle tree structure by introducing vector commitments (especially Pedersen commitments based on elliptic curves), thereby significantly reducing storage and computing requirements while ensuring security.

[0099] In this solution, the use of the Walker tree allows the account to provide a much smaller proof than the current solution when providing a path proof. Specifically, the prover no longer needs to provide all neighbor nodes at all levels on the path, but only needs to provide a proof for the parent-child relationship between all commitment values ​​on the path from the root node to the target leaf node. This alone can reduce the size of the proof by about 6 to 8 times (compared to the ideal Merkle tree), and this advantage will be further expanded as the number of transactions increases.

[0100] 5. Payee Verification Module

[0101] Payee verifies the legitimacy of the witness list provided by the payer, specifically: i) whether the provided witness (p) satisfies the Merkle tree root of the corresponding block; ii) whether the transaction Tx corresponds to the leaf node of p, and whether the content of Tx is correct.

[0102] Algorithm 6. VerWitnesss algorithm

[0103]

[0104] 6. Regulatory Verification Module

[0105] The supervisory node can obtain all transaction histories of any node in any time period and verify their integrity and correctness (the process is as follows Figure 2 As shown in Algorithm 7, the supervisory node uses Request to query the consensus network for detection results. In fact, the supervisory node can run the BMCHAIN ​​full node (without participating in consensus) to independently complete all verification operations.

[0106] Algorithm 7. Supervision Verification Algorithm

[0107]

[0108]

[0109] Algorithm 8. VerHistory algorithm

[0110]

[0111] The technical innovations of the present invention mainly include the following:

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

[0113] 2. A new on-chain and off-chain joint transaction verification algorithm (algorithms 2 to 8) has been designed. Thanks to these algorithms, this system meets the following requirements: 1) Users can independently control their online time without worrying about the pressure of network-wide monitoring 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 the user; 3) A supervision interface is provided for the supervision node, which can ensure high performance while also enabling accurate traceability supervision.

[0114] The innovative achievements of the present invention have the following beneficial effects:

[0115] 1. Support users to choose any online time

[0116] In addition to the stateless main chain, the BMCHAIN ​​model divides all account information into independent subsets. Most of the time, the BMCHAIN ​​account remains static. Only when two accounts conduct transactions, their local state (localDB) needs to be read and modified. Therefore, the BMCHAIN ​​account node can freely choose the transaction and online time without having to monitor the status changes of the global network at all times, which solves the problem of account offline. Even if the payee is offline, the payer can still complete the transaction and chain operation independently, and then complete the transmission and verification of the witness when the payee is online, which is also in line with the transaction habits of normal users.

[0117] According to the proof of "witness change" and Corollary 1 (No useful trade-offs) in the document M. Christ and J. Bonneau, "Limits on revocable proof systems, with applications to stateless blockchains," Cryptology ePrint Archive, Paper 2022 / 1478, 2022, when m elements are deleted (for example, m unspent transaction outputs (UTXO) are spent in one 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 proofs of the order of Ω(m / logn) must be updated, where n is the number of accounts. In addition, these updates are unpredictable and random for the accounts. This conclusion shows that the required online frequency of all accounts is almost linear as the number of submitted transactions increases. However, under the BMCHAIN ​​model, the frequency of account online is independent of the overall transaction frequency, but is positively correlated with its own transaction frequency.

[0118] 2. The storage costs of users and consensus nodes are balanced and distributed

[0119] The storage cost of an account, i.e., locaDB, is mainly composed of transaction storage S txs And the Merkle tree proves the storage S witness Composition, that is, S localDB =S txs +S witness The following is an item-by-item analysis. First, the present invention defines some required variables:

[0120] Variable Name Variable explanation n Number of account nodes t System running time γ Transaction frequency, that is, the number of transactions per second performed by a node Δ System block interval Stg(·) Displays the storage space

[0121] For S txs , which is mainly divided into two parts and The two represent the transaction data recorded when the account acts as a payer and payee respectively. According to the definition, for First, calculate the average number of transactions contained in a single submitted Txs as γnΔ / (nn(1-2 / n) γnΔ ), and then calculate the number of transactions in which the account acts as a payee as γtn / (n-1), so:

[0122]

[0123] In summary, the present invention has:

[0124]

[0125] For S witness , we know that the number of unit witnesses is (γt+γtn / (n-1)), and the size of a witness (Merkle tree proof) is max(1,log(nγΔ))·Stg(mtnode), so:

[0126] S witness =(γ t +γ tn / (n-1))·max(1,log(nγΔ))·Stg(mtnode).

[0127] Since γ, Δ, Stg(tx) and Stg(mtnode) are generally constants when the system is running, we can get:

[0128] S localDB =S txs +S witness =O(tlog(n)).

[0129] This ensures that the account storage cost is only positively correlated with the time and the logarithm of the account network size, which is close to the storage cost O(t) of traditional centralized transaction accounts and reaches a practical level.

[0130] In order to intuitively demonstrate the permanent storage cost of BMCHAIN ​​accounts, the present invention assigns appropriate values ​​to some of the above variables, as follows:

[0131] γ=3.8×10 -5 tps, real daily affairs data sampled from several volunteers;

[0132] Δ=15sec, using the average block time of Ethereum;

[0133] Stg(tx) = 200Bytes, using the transaction size of Ethereum without additional data;

[0134] Stg(mtnode)=32Bytes, using the Merkle tree node size based on the Keccak-256 algorithm (used in Ethereum).

[0135] The calculation results show that the linear increase of n does not cause a linear increase in BMCHAIN ​​account storage (in fact, it is a logarithmic relationship). Compared with the traditional centralized transaction system (accounts only store transaction data related to themselves), BMCHAIN ​​account storage does not have an order of magnitude difference, and when n is small (10000-50000), the difference between the two does not exceed one time. Even in the case of ultra-large scale (n = 100000000-500000000), the average account storage of the BMCHAIN ​​system after one year of operation is only about 1.7MB, which is completely acceptable.

[0136] 3. Effectively reduce the communication and computing cache costs of accounts and regulatory nodes

[0137] According to the witness verification algorithm design of BMchain, the upper limit of the communication and computing cache of the account node is the capacity of witness + Txs, which is γΔ+max(1,log(nγΔ))·Stg(mtnode). When γ and Δ are fixed, it is only proportional to lg(n), which is completely affordable for current personal mobile devices and network bandwidth.

[0138] For the supervisory node, in the supervisory verification, the upper bound of the computation cache that needs to be transmitted and verified is equivalent to the localDB capacity of the payer, because in the worst case, the supervisory node needs all the local data of the account (i.e., localDB). Using the same parameters as in the previous section, in a sufficiently long time (e.g., 100 years), the upper bound of the supervisory node communication and computation cache is expected to be about 170MB. This is completely affordable for current supervisory equipment and network bandwidth.

[0139] Although the present invention has been disclosed as above with preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art may make some modifications and improvements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be based on the definition of the claims.

Claims

1. A blockchain consensus protocol method that is easily scalable and regulated, characterized in that: The steps include: S1) Two account nodes as transaction participants self-organize to generate transaction Tx; and submit the transaction to the consensus network; S2) The consensus node packages the transactions collected in this cycle into the latest stateless block and sends the Merkle tree path proof to the corresponding transaction parties; S3) The initiator of the transaction updates its local database accordingly and sends the local transaction record together with the witness information to the recipient of the other transaction; S4) The recipient of the transaction verifies the transaction Tx and updates its local database.

2. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 1, characterized in that: The step S1 submits one transaction within one block cycle; when the initiator of the 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 repeated submission by malicious consensus nodes.

3. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 1, characterized in that: The step S2 generates a new stateless block B i+1 =<bf,mtr,δ> , bf contains B i+1 The addresses of both parties involved in all transactions during the period; mtr is the address of B i+1 The root of the Merkle tree consisting of all transactions during the period; δ is other necessary block information.

4. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 3 is characterized in that: The δ includes a digital signature, a timestamp, a block number and a Nonce random number.

5. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 1, characterized in that: In step S2, after the consensus network sets up a cache transaction pool to collect enough transaction submissions, they are packaged and uploaded to the chain; and the collected transactions are verified for legitimacy using a double Bloom filter.

6. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 1, characterized in that: The consensus node in step S2 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 recipient of the transaction for verification.

7. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 6 is characterized in that: The verification of the recipient of the transaction in step S4 includes: whether the witness list provided satisfies the Merkle tree root of the corresponding block, whether the transaction records of the witness and the initiator of the transaction are completely matched, and whether the status of the initiator of the current transaction is sufficient to support this transaction.

8. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 1, characterized in that: It also includes a supervisory node that is used to obtain all transaction histories of any node in any time period and verify their integrity and correctness.

9. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 1, characterized in that: It also includes dividing the information of all account nodes into independent subsets, and only reading and modifying their local states when two accounts conduct transactions; and after each transaction is successfully completed, using Bloom filters to record the set of account addresses whose states have changed within each block cycle.

10. The blockchain consensus protocol method for easy scalability and supervision as claimed in claim 9, characterized in that: The information of the account node includes transaction storage S txs And the Merkle tree proves the storage S witness ; S txs Divided into two parts and Indicates the transaction data recorded when the account is the initiator of the transaction. Indicates transaction data recorded when an account participates as a recipient of a transaction; set up for. First, calculate the average number of transactions contained in a single submitted Txs as γnΔ / (nn(1-2 / n) γnΔ ), and then calculate the number of transactions in which the account participates as the recipient of the transaction as γtn / (n-1): For S witness , the number of unit witnesses is (γt+γtn / (n-1)), and the size of a Merkle tree proof is max(1,log(nγΔ))·Stg(mtnode), so: S witness =(γt+γtn / (n-1))·max(1,log(nγΔ))·Stg(mtnode); n is the number of account nodes, t is the system running time, γ is the number of transactions performed by an account node per second; Δ is the system block interval, and Stg(·) represents the storage space of ·.

Images