Programmable consensus method based on partitioned blockchain system

Abstract

The present invention belongs to the technical field of blockchains, and relates in particular to a programmable consensus method based on a partitioned blockchain system. The method comprises: a programmable consensus is implemented by means of a Match-Tidy-Wrap structure, the MTW structure being responsible for guiding a node within a partition to sort and process transactions; the programmable consensus mechanism of the present invention improves the consensus process in partitions and introduces the design idea of asynchronous decoupling into a blockchain system, enhancing the transaction throughput of the blockchain system and improving the scalability of the system; and an editable interface is introduced into the consensus mechanism so that a plurality of custom consensus mechanisms may be deployed in each partition. In the method, different transaction processing is implemented in each partition on the basis of the functions required by the partitions, such that different function requirements are implemented under a unified blockchain system.

Description

A programmable consensus method based on partitioned blockchain system Technical Field

[0001] The present invention belongs to the field of blockchain technology, and specifically relates to a programmable consensus method based on a partitioned blockchain system. Background Art

[0002] Consensus algorithms are fundamental to ensuring the smooth execution of transactions in blockchain systems. Using consensus algorithms in blockchain systems ensures that nodes distributed across different regions maintain consistent status. In existing blockchain systems, consensus takes on the following tasks: network establishment, transaction upload, and database synchronization.

[0003] A smart contract in the blockchain is essentially a program composed of computer code and deployed on the blockchain. Once compiled and deployed to the blockchain, a smart contract is ready to be triggered and executed at any time. During execution, it can complete its intended function without third-party intervention. Furthermore, because the contract is deployed on the blockchain, the smart contract's code and structure are accessible to every user, and the smart contract code is executed by the nodes that make up the blockchain network. Users on the blockchain initiate calls to smart contracts through transactions, which contain information such as user input data. When a node in the blockchain system packages the transaction invoking the contract into a block, and the block is successfully verified and added to the blockchain, the blockchain system executes the transaction and the corresponding operations generated. The results of the transaction are stored in the world state database synchronized across the entire network, thus completing the execution of the smart contract.

[0004] The consensus process provides the foundation for the operation of smart contracts, ensuring unified transaction selection, execution, and recording across the entire network. As the underlying network, the blockchain system provides the decentralized operation foundation for upper-layer smart contracts, while the implementation of application functions all comes from the writing of smart contracts.

[0005] When implementing application functions, existing smart contracts have the following shortcomings:

[0006] 1. Limited Performance: Because smart contracts are triggered by transactions, performance is closely related to TPS. Existing solutions include layered architecture, partitioned architecture, and improved consensus mechanisms. However, these solutions are still limited in terms of functionality, given the same number of transactions.

[0007] 2. Lack of intrinsic connection between transactions: The execution of each transaction is independent. During the execution process, a transaction will not be affected by other concurrent transactions and will not be able to know the access content of other concurrent transactions.

[0008] Summary of the Invention

[0009] To address the above technical issues, the present invention proposes a programmable consensus method based on a partitioned blockchain system. The programmable consensus is implemented through a Match-Tidy-Wrap structure, including:

[0010] The Match-Tidy-Wrap structure has three programmable interfaces: TxMatch, TxTidy, and BlockWrap;

[0011] TxMatch defines transaction screening strategies, diverting transactions into different Match-Tidy-Wrap process pools; TxTidy defines transaction selection and sorting strategies, selecting and sorting specified transactions in the transaction pool for subsequent packaging; BlockWrap defines transaction execution strategies and block packaging strategies, calling smart contracts to process transactions and packaging the processed transactions into blocks for subsequent sorting and on-chain.

[0012] When a transaction is published, it is received by the nodes in the partition and distributed to different transaction pools according to the transaction screening strategy defined by TxMatch;

[0013] When a certain number of transactions is reached in the transaction pool or after a certain time interval, the Match-Tidy-Wrap structure will initiate a round of consensus. The leader node in the partition will select and sort transactions from the transaction pool according to the transaction selection and sorting strategy defined by TxTidy. After sorting, a round of PBFT consensus will be initiated.

[0014] BlockWrap is designed into the PBFT consensus, which reaches consensus through three phases: pre-prepare, prepare, and commit.

[0015] The leader node puts the sorted transaction sequence into the pre-prepare message and broadcasts it. Each node verifies the message after receiving it and broadcasts its own prepare message after passing the verification.

[0016] When a node receives enough prepare messages from other nodes, BlockWrap will call the smart contract engine to process the transaction and generate a result-commit transaction. The node will package the result-commit transaction generated after processing the transaction into a block, put it into the commit message and broadcast it;

[0017] When the leader node receives enough valid commit transactions, it confirms the validity of the block and broadcasts it to the upper layer for subsequent block sorting and chaining.

[0018] Beneficial effects of the present invention:

[0019] The programmable consensus mechanism of this invention introduces an asynchronous decoupling design concept for the blockchain system by improving the consensus process within the partition. First, the transaction screening strategy defined by TxMatch is used to distribute transactions to different transaction pools, allowing different transaction pools to carry out consensus in parallel. Before each consensus begins, the TxTidy strategy is used to select transactions that meet the transaction selection strategy and package them into blocks for sorting. Then, BlockWrap, embedded in the PBFT consensus process within the partition, executes transactions within the block that meet the execution strategy and generates RC transactions. The newly generated transactions are then reprocessed to form blocks for subsequent upper-layer consensus sorting, thereby enhancing the transaction throughput of the blockchain system and improving the system's scalability.

[0020] The present invention introduces an editable interface into the consensus mechanism, so that each partition can deploy multiple customized consensus mechanisms. Through this method, each partition can implement different transaction processing according to the required functions of the partition, realizing differentiated functional requirements under a unified blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] FIG1 is a schematic diagram of a programmable consensus method based on a partitioned blockchain system according to the present invention;

[0022] FIG2 is a schematic diagram of a programmable consensus embodiment of the present invention. DETAILED DESCRIPTION

[0023] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0024] A programmable consensus method based on a partitioned blockchain system, as shown in Figure 1, includes:

[0025] Programmable consensus is achieved through the Match-Tidy-Wrap (MTW) ​​structure. MTW is responsible for guiding nodes within a partition to sort and process transactions. Each MTW structure has three programmable interfaces: TxMatch, TxTidy, and BlockWrap. Specifically, the functions of the MTW structure are as follows:

[0026] First, TxMatch defines a transaction screening strategy to divert transactions into different MTW process pools; second, TxTidy defines a transaction selection and sorting strategy to select and sort specified transactions in the transaction pool for subsequent packaging; BlockWrap defines a transaction execution strategy and a block packaging strategy to call smart contracts to process transactions and package the processed transactions into blocks for subsequent sorting and on-chain.

[0027] TxMatch: Each MTW structure has a transaction pool for collecting transactions related to it. When a transaction is published, it is received by nodes within the partition and then assigned to different transaction pools through TxMatch. This classification is determined based on information such as the sender, smart contract address, function address, and timestamp. A transaction will only enter one transaction pool.

[0028] TxTidy: When conditions are met, the MTW structure initiates a consensus round. The leader node in the partition selects and sorts transactions from the transaction pool according to the TxTidy strategy. After sorting, a PBFT consensus round begins. A consensus round begins when the transaction pool reaches a certain number of transactions or after a certain time interval. In practice, the number is generally set to 1024 and the time interval is set to 1 second. Each MTW can conduct multiple consensus rounds simultaneously, and each partition can deploy multiple MTW structures simultaneously.

[0029] BlockWrap: BlockWrap is designed into the PBFT consensus. PBFT consensus reaches consensus through three phases: pre-prepare, prepare, and commit. BlockWrap occurs between the prepare and commit phases, executing between them. First, the leader node places the sorted transaction sequence in a pre-prepare message and broadcasts it. Each node verifies the message and, upon successful verification, broadcasts its own prepare message. When a node receives a sufficient number of prepare messages from other nodes, it performs a BlockWrap operation. BlockWrap then invokes the smart contract engine to process the transactions and generate a result-commit (RC) transaction. RC transactions are used only to modify the world state database after being uploaded to the blockchain. After processing transactions, nodes package them into blocks, place them in commit messages, and broadcast them. Once the leader node receives a sufficient number of valid commit transactions, it confirms the validity of the block and broadcasts it to the upper layer for subsequent block sorting and on-chain uploading.

[0030] The transaction selection and sorting strategy involves the transaction data structure, which contains the following properties:

[0031] TxID: 256-bit hash value, representing a unique transaction number;

[0032] Sender: 160-bit hash value, representing the address (public key) of the account initiating the transaction;

[0033] Nonce: uint64 type character, used to distinguish transactions with identical other attributes, usually used to store timestamps;

[0034] Version: 256-bit hash value, representing the world state version number of the sender when initiating the transaction. If the version number is too low, the transaction will be discarded in subsequent executions;

[0035] LifeTime: uint8 type character, used to specify the number of versions behind before the transaction will become invalid;

[0036] Signature: string type, used for authentication;

[0037] Contract: 160-bit hash value, used to specify the address of the smart contract being called;

[0038] Function: 160-bit hash value, used to specify the address of the function in the contract;

[0039] Args: string array, used for parameter input of Function;

[0040] CheckList: An array that specifies the specific data in the world state that this transaction involves reading and writing, and is used to check whether this transaction may conflict with other transactions.

[0041] The transaction selection and sorting strategy involves Version, Lifetime, Contract, Function, and Checklist, and is performed according to the user-specified strategy. When selecting transactions, the difference between the Version and the current version is compared. If the difference is greater than the Lifetime, the transaction is discarded. When sorting transactions, the Contract, Function, and Checklist are used to arrange the transactions in a conflict-free order.

[0042] TxMatch defines transaction screening strategies and diverts transactions into different MTW process pools, including:

[0043] Based on the sender, contract, function, and nonce information of each transaction, a transaction will only enter one transaction pool.

[0044] Each MTW structure contains a transaction pool, and a transaction can only be assigned to one transaction pool.

[0045] TxTidy defines transaction selection and sorting strategies, selecting and sorting specified transactions in the transaction pool for subsequent packaging, including:

[0046] Based on the difference between the Local Write (LW) type and the Global Write (GW) type in the transaction information's attributes, select the Local Write (LW) type transactions and send them to BlockWrap for processing. Then, the processed Local Write (LW) type transactions and Global Write (GW) type transactions are reordered.

[0047] The transaction execution strategy and block packaging strategy defined by BlockWrap include:

[0048] LW type transactions will call the smart contract execution during transaction execution, and integrate the execution results into the transaction information, rewriting them into Result-Commit (RC) type transactions; GW type transactions will not be processed during transaction execution and remain unchanged. The transactions sorted by the TxTidy node will be packaged into a block for subsequent block sorting and chain upload.

[0049] Multiple MTW structures are deployed simultaneously in each partition. When one MTW structure is running, other MTW structures can be started asynchronously and run in parallel, which can effectively improve the system throughput.

[0050] Each node in the blockchain is manually divided into different zones during deployment, based on the differences in the organizations to which it belongs. Each zone is assigned a leader node, which is responsible for initiating the MTW consensus within the zone, communicating between zones, and participating in the consensus on subsequent blocks.

[0051] The result-commit (RC) transaction is only used to modify the world state database after being uploaded to the chain.

[0052] In a blockchain system, all transactions are recorded in the blockchain, and the results of all transaction execution are recorded in the world state database. For example, in previous blockchain systems, such as Ethereum, transactions were first packaged into blocks, which were then added to the blockchain after consensus. Subsequently, transactions within the on-chain blocks were executed sequentially, involving running smart contract code and modifying the state of data in the relevant world state. In programmable consensus methods, for a special type of transaction, LW, the contract execution step is pre-placed in the consensus process. The subsequent RC transaction contains the execution results and is used only to update the data state after the block is on-chain.

[0053] Considering the application scenario of a sharded blockchain divided by organization, consensus on block packaging occurs within a partition, while consensus on block on-chain and block execution occurs between partitions. Without programmable consensus, contract execution would occur across the entire blockchain system. The nature of sharding, which is divided by organization, makes it pointless for other partitions to participate in contract execution within their own partition and wastes computing and communication resources. Therefore, programmable consensus is a highly effective improvement for sharded blockchain scenarios.

[0054] Figure 2 shows an example of programmable consensus. The scenario involves building a blockchain system across different organizations in a supply chain. Due to business needs, suppliers, manufacturers, and banks require a blockchain system to provide more efficient information sharing and trust transfer. However, due to the diverse business requirements within organizations, each zone deploys a different MTW architecture to facilitate transaction consensus and execution within the organization while also achieving data synchronization across the entire network. First, the blockchain system partitions nodes, assigning them to different zones based on their respective organizations. The requirement within a zone is transaction execution and consensus, while the requirement between zones is synchronization of transaction records and execution results across zones—the aforementioned blockchain and world state. Therefore, intra-zone consensus, or consensus under the MTW architecture, occurs within each zone and is used to select, process, and package transactions into blocks. After this, the blocks are transferred to the upper-level network, comprised of each zone's leader nodes, for consensus on the block's inclusion on the blockchain. Once the lower-level blocks are generated, a round of MTW consensus concludes. Once the upper-level blocks are included on the blockchain, each node updates the world state based on the on-chain blocks, ultimately recording the MTW execution results.

[0055] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A programmable consensus method based on a partitioned blockchain system, characterized in that, The programmable consensus is implemented through the Match-Tidy-Wrap structure, including: The Match-Tidy-Wrap structure has three programmable interfaces: TxMatch, TxTidy, and BlockWrap; TxMatch defines the transaction screening strategy and diverts transactions into the process pools of different Match-Tidy-Wrap processes; TxTidy defines the transaction selection and sorting strategy, selects specified transactions in the transaction pool and sorts them for subsequent packaging; BlockWrap defines the transaction execution strategy and the block packaging strategy, calls the smart contract to process the transactions and packages the processed transactions into blocks for subsequent sorting and chain-up; When a transaction is published, it is received by the nodes in this partition and is assigned to different transaction pools through the transaction screening strategy defined by TxMatch; When the number of transactions in the transaction pool reaches a certain amount or after a certain time interval, the Match-Tidy-Wrap structure will start a round of consensus. The leader node in this partition will select and sort transactions from the transaction pool according to the transaction selection and sorting strategy defined by TxTidy. After sorting, a round of PBFT consensus will be started; BlockWrap is designed in the PBFT consensus. The PBFT consensus reaches consensus through three stages: pre-prepare, prepare, and commit; The leader node puts the sorted transaction sequence into the pre-prepare message and broadcasts it. After receiving the message, each node verifies it. After passing the verification, it broadcasts its own prepare message; When a node receives a sufficient number of prepare messages from other nodes, BlockWrap will call the smart contract engine to process the transactions, generate result-commit transactions. The node packages the result-commit transactions generated after processing the transactions into blocks, puts them into the commit message and broadcasts them; When the leader node receives a sufficient number of valid commit transactions, it confirms the validity of the block and broadcasts it to the upper layer for subsequent block sorting and chain-up.

2. The programmable consensus method based on a partitioned blockchain system according to claim 1, wherein, TxMatch defines the transaction screening strategy and diverts transactions into the process pools of different Match-Tidy-Wrap processes, including: Judgment is made based on the sender, contract, function, and nonce information of each transaction. A transaction will only enter one transaction pool.

3. A programmable consensus method based on a partitioned blockchain system according to claim 1, wherein, TxTidy defines the transaction selection and sorting strategy, selects specified transactions in the transaction pool and sorts them for subsequent packaging, including: According to the differences in the Local Write type and Global Write type in the attributes carried by the transaction information, select the Local Write type of transactions for BlockWrap to process, and re-sort the processed Local Write type of transactions and Global Write type of transactions.

4. A programmable consensus method based on a partitioned blockchain system according to claim 1, wherein, The transaction execution strategy and block packaging strategy defined by BlockWrap include: Transactions of the LocalWrite type will call the smart contract for execution during transaction execution, and the execution results will be integrated into the transaction information and rewritten into transactions of the Result-Commit type; transactions of the Global Write type will not be processed during transaction execution and remain unchanged. The transactions sorted by the TxTidy node will be packaged into a block for subsequent block sorting and chain upload.

5. A programmable consensus method based on a partitioned blockchain system according to claim 1, wherein Multiple Match-Tidy-Wrap structures are deployed in each partition simultaneously. When one Match-Tidy-Wrap structure is running, other Match-Tidy-Wrap structures can be started asynchronously and run in parallel; Each node of the blockchain is manually divided into different partitions during deployment according to the differences of its affiliated organizations; a leader node is designated for each partition to initiate the Match-Tidy-Wrap consensus within the partition, communicate between partitions, and participate in the consensus chain upload of subsequent blocks.

6. A programmable consensus method based on a partitioned blockchain system according to claim 1, characterized in that, The result-commit transaction is only used to modify the world state database after chain upload.

Images