CN113610527A

CN113610527A - Alliance chain transaction method, device, system, terminal device and storage medium

Info

Publication number: CN113610527A
Application number: CN202110974895.9A
Authority: CN
Inventors: 刘辉
Original assignee: Shanghai Dianrong Information Technology Co ltd
Current assignee: Shanghai Dianrong Information Technology Co ltd
Priority date: 2021-08-24
Filing date: 2021-08-24
Publication date: 2021-11-05

Abstract

The invention discloses a method, a device, a system, terminal equipment and a storage medium for trading of a alliance chain. The method comprises the following steps: acquiring a block from the consensus node, and sequentially executing each effective transaction in the block; according to the execution of each effective transaction and the generation of a block synchronization request, sending the block synchronization request to each slave transaction node so that each slave transaction node synchronously updates an account book state database of the slave transaction node; and generating a block archiving request, and sending the block archiving request to the archiving node so as to enable the archiving node to carry out block archiving. By the technical scheme, the verification and calculation logic of the transaction can be integrated in the main transaction node, the ledger state database of the slave transaction node is updated by the block synchronous request of the main transaction node, the calculation resource of the slave transaction node is saved, the response speed is improved, and the transaction processing performance of the system is improved; and the archiving node is introduced to realize the data backup function and reduce the storage pressure of each transaction node.

Description

Alliance chain transaction method, device, system, terminal device and storage medium

Technical Field

The embodiment of the invention relates to the technical field of block chains, in particular to a method, a device, a system, terminal equipment and a storage medium for trading of a alliance chain.

Background

The Consortium block chain refers to a block chain managed by a specific organization or group, and needs to designate some nodes as bookers in advance, and the generation of each block is determined by all the bookers. The alliance chain is composed of a plurality of organizations, one organization can internally comprise one or more block chain nodes, and the block chain nodes comprise: a consensus node and a plurality of trading nodes.

In the prior art, as shown in fig. 1A, a master trading node can be determined by election inside each organization, and other trading nodes in the organization are used as slave trading nodes of the master trading node. The master trading node within each organization synchronizes the block to the consensus node, and each slave trading node synchronizes the block to the master trading node, each trading node receiving the block from the consensus node either directly or indirectly. As shown in fig. 1B, after receiving the block, each transaction node (including the master transaction node and each slave transaction node) performs a transaction-by-transaction verification on each transaction in the block, performs a transaction execution to update the ledger state database, and stores the ledger states of all transactions and all blocks in one block chain in the local disk.

Under the condition of a large number of transactions, such as data acquisition of the internet of things, a large number of transactions are often contained in one block, and each transaction node needs to perform signature verification and transaction execution one by one aiming at each transaction, so that the transaction nodes occupy a large amount of computing resources, the transaction processing performance is reduced, the response time is slowed, and resource waste is caused. Meanwhile, each transaction node stores the full-amount book state and all blocks in a block chain, so that the storage pressure of each transaction node is huge.

Disclosure of Invention

The embodiment of the invention provides a transaction method, a device, a system, terminal equipment and a storage medium of an alliance chain, which are used for realizing that verification and calculation logic of transaction are integrated in a main transaction node, and an account book state database of a slave transaction node is updated through a block synchronization request of the main transaction node, so that the calculation resources of the slave transaction node are saved, the response speed is increased, and the transaction processing performance of the system is improved; and moreover, the filing node is introduced, and a more convenient and practical data backup function is realized through an independent storage module storage block and a block synchronous request, so that the storage pressure of each transaction node is reduced.

In a first aspect, an embodiment of the present invention provides a federation chain transaction method, which is applied to a master transaction node, and the method includes:

acquiring a block from a consensus node, and sequentially executing each effective transaction in the block, wherein the effective transaction is a transaction verified by the main transaction node;

generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node so that each slave transaction node synchronously updates an account book state database of each slave transaction node according to the block synchronization request;

generating a block archive request based on the block, the block signature for the block, and the block synchronization request, and sending the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory.

Further, generating a block synchronization request according to a transaction status update log generated by executing each valid transaction and a block header of the block, including:

determining a transaction state update log of each effective transaction, wherein the transaction state update log is obtained by combining key values of an updated account book state database;

writing each transaction state update log into a state update log queue;

obtaining a block status update log from the status update log queue, wherein the block status update log comprises: updating logs of transaction states;

and generating a block synchronization request according to the block header of the block, the block state update log and a block synchronization request signature formed by the block header and the block state update log.

Further, after each valid transaction in the block is executed in sequence, the method further includes:

storing a block header for the block in a local disk of the master transaction node.

In a second aspect, an embodiment of the present invention provides a federation chain transaction method, applied to a slave transaction node, including:

when a block synchronization request sent by a main transaction node is received, verifying a block synchronization request signature in the block synchronization request;

if the signature of the block synchronization request belongs to the signature of the main transaction node, updating an account book state database of the slave transaction node based on a block state update log in the block synchronization request;

and storing the block head in the block synchronization request in a local disk of the slave transaction node.

Further, the method further comprises:

acquiring a transaction request of an intelligent contract sent by a client;

and reading the key-value pair in the ledger state database or writing the key-value pair into the ledger state database of the slave transaction node to execute the transaction request of the intelligent contract.

Further, the method further comprises:

for the newly added slave transaction node, acquiring all block synchronization requests from the filing node;

for each block synchronization request, verifying whether a block synchronization request signature in the block synchronization request belongs to the master transaction node;

updating the account book state database of the newly added slave transaction node based on the block state update logs in the block synchronization requests passing the verification in sequence;

and writing the block head in each verified block synchronization request into the local disk of the newly added slave transaction node.

In a third aspect, an embodiment of the present invention provides a federation chain transaction method, which is applied to an archive node, and the method includes:

when a block archiving request sent by a main transaction node is received, verifying a block synchronization request signature and a block signature in the block synchronization request;

if the verification is passed, extracting a block synchronization request and a block in the block archiving request;

storing the block synchronization request and the block in a memory.

Further, the method further comprises:

analyzing the block to obtain each transaction in the block;

establishing an index based on the corresponding relation between the block number of the block and the transaction number;

binding a block synchronization request corresponding to the block with the block number;

storing the index in the memory.

Further, the storage module is a local disk or an external system database.

In a fourth aspect, an embodiment of the present invention provides a federation chain transaction apparatus integrated in a master transaction node, where the apparatus includes:

the acquisition module is used for acquiring the block from the consensus node and sequentially executing each effective transaction in the block, wherein the effective transaction is a transaction verified by the main transaction node;

a synchronization request module, configured to generate a block synchronization request according to a transaction status update log generated by executing each valid transaction and a block header of the block, and send the block synchronization request to each slave transaction node, so that each slave transaction node updates the ledger status database of the slave transaction node synchronously according to the block synchronization request;

an archive request module to generate a block archive request based on the block, the block signature of the block, and the block synchronization request, and to send the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory.

In a fifth aspect, an embodiment of the present invention provides a federation chain transaction apparatus integrated in a slave transaction node, where the apparatus includes:

the system comprises a first verification module, a second verification module and a third verification module, wherein the first verification module is used for verifying a block synchronization request signature in a block synchronization request when the block synchronization request sent by a main transaction node is received;

a first updating module, configured to update an account book state database of a slave transaction node based on a block state update log in the block synchronization request if the block synchronization request signature belongs to the signature of the master transaction node;

and the first storage module is used for storing the block head in the block synchronization request in a local disk of the slave transaction node.

In a sixth aspect, an embodiment of the present invention provides a federation chain transaction apparatus integrated in an archive node, where the apparatus includes:

the second verification module is used for verifying the block synchronization request signature and the block signature in the block synchronization request when receiving the block archiving request sent by the main transaction node;

the extracting module is used for extracting the block synchronization request and the blocks in the block archiving request if the verification is passed;

a second storage module to store the block synchronization request and the block in a memory.

In a seventh aspect, an embodiment of the present invention provides a federation chain transaction system, including: a master trading node, a plurality of slave trading nodes subordinate to the master trading node, and an archival node;

the main transaction node is used for acquiring the blocks from the consensus node and sequentially executing each effective transaction in the blocks, wherein the effective transaction is a transaction verified by the main transaction node; generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node; generating a block archiving request according to the block, the block signature and the block synchronization request, and sending the block archiving request to an archiving node;

each slave transaction node is used for verifying a block synchronization request signature in a block synchronization request when receiving the block synchronization request sent by a master transaction node; if the signature of the block synchronization request belongs to the signature of the main transaction node, updating an account book state database of the slave transaction node based on a block state update log in the block synchronization request; storing a chunk header in the chunk synchronization request in a local disk of the slave transaction node;

the archiving node is used for verifying a block synchronization request signature and a block signature in a block synchronization request when the block archiving request sent by the main transaction node is received; if the verification is passed, extracting a block synchronization request and a block in the block archiving request; storing the block synchronization request and the block in a memory.

In an eighth aspect, an embodiment of the present invention further provides a terminal device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor executes the computer program to implement the federation chain transaction method according to any one of the first embodiment, the second embodiment, or the third embodiment of the present invention.

In a ninth aspect, the embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a federation chain transaction method as described in any one of the first embodiment, the second embodiment or the third embodiment of the present invention.

In the embodiment of the invention, a block synchronization request is generated by a main transaction node executing effective transaction in a block, and the block synchronization request is sent to each slave transaction node, so that each slave transaction node synchronously updates an account book state database of each slave transaction node according to the block synchronization request; generating a block archive request and sending the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory; the problem that in the prior art, under the scene of numerous transaction amounts, each transaction node needs to perform signature verification and transaction execution one by one aiming at each transaction, so that the transaction node occupies a large amount of computing resources, the transaction processing performance is reduced, the response time is slowed, and resources are wasted, and the full-amount book state and all blocks in a block chain are stored on each transaction node, so that the storage pressure of each transaction node is huge is solved, the transaction verification and calculation logic is integrated in a main transaction node, the book state database of a slave transaction node is updated through a block synchronization request of the main transaction node, the computing resources of the slave transaction node are saved, the response speed is improved, and the transaction processing performance of a system is improved; and moreover, the filing node is introduced, and a more convenient and practical data backup function is realized through an independent storage module storage block and a block synchronous request, so that the effect of reducing the storage pressure of each transaction node is achieved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.

FIG. 1A is a schematic diagram of a prior art federation chain transaction method;

FIG. 1B is a schematic diagram of the processing logic of a prior art transaction node;

FIG. 1C is a flow chart of a method for trading in a federation chain according to a first embodiment of the present invention;

FIG. 1D is a flow chart of a federation chain transaction method according to a second embodiment of the present invention;

fig. 2A is a flowchart of a federation chain transaction method according to a second embodiment of the present invention;

FIG. 2B is a diagram of a method for executing an intelligent contract from a trading node according to a second embodiment of the present invention;

fig. 2C is a schematic diagram illustrating a block synchronization method for a newly added slave transaction node according to a second embodiment of the present invention;

fig. 3A is a flowchart of a federation chain transaction method according to a third embodiment of the present invention;

fig. 3B is a schematic structural diagram of a transaction system of another federation chain in accordance with a third embodiment of the present invention;

fig. 4 is a schematic structural diagram of a transaction device in a federation chain in the fourth embodiment of the present invention;

fig. 5 is a schematic structural diagram of a transaction device in a federation chain according to a fifth embodiment of the present invention;

fig. 6 is a schematic structural diagram of a transaction device in a federation chain according to a sixth embodiment of the present invention;

fig. 7 is a schematic structural diagram of a transaction system of a federation chain in a seventh embodiment of the present invention;

fig. 8 is a schematic structural diagram of a terminal device in an eighth embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be further noted that, for the convenience of description, only some of the structures related to the present invention are shown in the drawings, not all of the structures.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present invention, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

Example one

Fig. 1C is a flowchart of a federation chain transaction method according to an embodiment of the present invention, where this embodiment is applicable to a situation where each transaction node in a federation chain synchronizes and stores transactions in a large traffic scene; the method may be performed by a federation chain transaction device in an embodiment of the present invention, which may be implemented in software and/or hardware, and which may be integrated in a master transaction node.

As shown in fig. 1D, in the embodiment of the present invention, an organization of a federation chain, that is, a transaction system of the federation chain, includes: a master trading node, a plurality of slave trading nodes subordinate to the master trading node, and an archival node. The main transaction node is used for acquiring the block from the consensus node, verifying and executing each transaction in the block, and generating a block synchronous updating request and a block archiving request according to a state updating log generated by executing the transaction; and sending the block synchronous updating request to each slave transaction node, and sending the block archiving request to the archiving node. Each slave transaction node completes block synchronization based on the block synchronization update request without repeating transaction verification and execution operations to relieve computing resources of the transaction node. The archiving node is used for storing the block and the block synchronization request, and each transaction node only stores the block head so as to save the storage space of the node.

As shown in fig. 1C, the method specifically includes the following steps:

s110, acquiring a block from a consensus node, and sequentially executing each effective transaction in the block, wherein the effective transaction is a transaction verified by the main transaction node.

Wherein the valid transaction may be a transaction verified by data integrity and tamper resistance of the primary transaction node.

Specifically, the main transaction node acquires the block from the consensus node, and sequentially executing each effective transaction in the block comprises: acquiring a block from a consensus node, and verifying the block head in the block, the signature of each transaction in the block and the validity of each transaction data; sequentially executing valid transactions passing the verification, and updating an account book state database of the main transaction node based on key value pairs generated by the execution; invalid transactions for which the verification fails are flagged.

For example, the master transaction node obtains the block from the consensus node, and the verification of the block header in the block, the signature of each transaction in the block, and the validity of each transaction data may be performed by: the master transaction node calculates the root of the Merkel tree of the transaction one by one and compares the hash value in the block head, verifies whether the previous hash value in the block head is consistent with the hash value of the previous block which is stored locally, and verifies the signature of the brow transaction one by one, which can be one or a group of signatures.

For example, the way to sequentially execute each valid transaction in the block may be: and the main transaction node executes the effective transaction initiation state updating operation, updates the ledger state database of the block chain, namely writes the Key Value pair Key-Value into the ledger state database.

And S120, generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node so that each slave transaction node synchronously updates the ledger state database of the slave transaction node according to the block synchronization request.

The transaction state update log is a log formed by key value pairs generated by executing transactions, the key value pairs are used for updating the ledger state database, and the transaction state update log reflects the update change of the state of the ledger of the transactions.

Specifically, the main transaction node executes each effective transaction to generate a key value pair, initiates an operation of updating the state data of the account book, forms a transaction state update log based on the key value pair, and generates a block synchronization request according to the block header of the received block and the transaction state update log. And sending the block synchronization request to each slave transaction node, and returning after waiting for the response of each slave transaction node, so that each slave transaction node synchronously updates the book state database of the slave transaction node based on the key value pair written in the block state update log in the block synchronization request when receiving the block synchronization request.

For example, the way of generating the block synchronization request according to the block header of the received block and the transaction status update log may be: the master transaction node generates a block synchronization request by using a block header and a transaction status update log, and the format of the block synchronization request may be: block header, transaction status update log; further, the block header and the transaction status update log may be signed, and the block synchronization request may be generated by using the block header, the transaction status update log, and the signature of the block header and the transaction status update log, and may be in a format of: block header, transaction status update log, signature { block header, transaction status update log } ].

It should be noted that the master trading node elects from each trading node in the block, and the trading node that fails in election serves as a slave trading node subordinate to the master trading node. And if the main transaction node fails, reselecting from the slave transaction nodes corresponding to the main transaction node to generate a new main transaction node.

S130, generating a block archiving request according to the block, the block signature of the block, and the block synchronization request, and sending the block archiving request to an archiving node, so that the archiving node performs block archiving based on the block archiving request.

The archive node is used for storing related data such as blocks and block requests.

Specifically, the master transaction node signs the received block to determine a block signature, generates a block archiving request according to the generated block synchronization request, the block and the block signature, and sends the block archiving request to an archiving node, so that the archiving node stores the block and the block synchronization request in a memory.

For example, the format of the block archive request may be: [ block synchronization request, [ block, block signature ] ]. The block signature may be a public key or a public key certificate of the block, which is not limited in the embodiment of the present invention.

According to the technical scheme of the embodiment, the block is obtained from the consensus node through the main transaction node, and each effective transaction in the block is executed in sequence; generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node so that each slave transaction node synchronously updates an account book state database of each slave transaction node according to the block synchronization request; generating a block archive request based on the block, the block signature for the block, and the block synchronization request, and sending the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory. The verification and calculation logic of the transaction is integrated in the main transaction node, and the account book state database of the slave transaction node is updated through the block synchronous request of the main transaction node, so that the calculation resources of the slave transaction node are saved, the response speed is improved, and the transaction processing performance of the system is improved; and moreover, the filing node is introduced, and a more convenient and practical data backup function is realized through an independent storage module storage block and a block synchronous request, so that the storage pressure of each transaction node is reduced.

Optionally, after sequentially executing each valid transaction in the block, the method further includes:

Specifically, after the transaction verification and the transaction execution are completed, the main transaction node only stores the block header in the local disk, and the block is stored in the independent storage module through the block archiving request sent to the archiving node, so that the storage space of the disk is reduced, and the block can be used for the tamper-proof verification of the new block.

Optionally, generating a block synchronization request according to a transaction status update log generated by executing each valid transaction and a block header of the block includes:

writing each transaction state update log into a state update log queue;

obtaining a block status update log from the status update log queue, the block status update log comprising: updating logs of transaction states;

and generating a block synchronization request according to the block head of the block, the block state update log and a block synchronization request signature formed by the block head and the block state update log.

Specifically, the master transaction node executes an effective transaction initiation state updating operation, writes a key value pair into the ledger state database, and updates the ledger state database of the block chain. And merging the key value pairs to obtain transaction state update logs, and writing the transaction state update logs corresponding to each transaction into a state update log queue one by one according to the transaction sequence. And after all transactions in the block are executed, obtaining block state update logs formed by the transaction state update logs corresponding to the transactions in the block in batch from the state update log queue. The main transaction node signs a block head and a block state update log of a block to obtain a block synchronization request signature, and generates a block synchronization request according to the block head of the block, the block state update log and the block synchronization request signature.

Example two

Fig. 2A is a flowchart of a federation chain transaction method according to a second embodiment of the present invention, where this embodiment is applicable to a situation where each transaction node in a federation chain synchronizes and stores transactions in a large traffic scenario; the method may be performed by a federation chain transaction device in an embodiment of the present invention, which may be implemented in software and/or hardware, and which may be integrated in a slave transaction node subordinate to a master transaction node.

As shown in fig. 2A, the method of this embodiment specifically includes the following steps:

s210, when a block synchronization request sent by a main transaction node is received, a block synchronization request signature in the block synchronization request is verified.

In the embodiment of the invention, a main trading node is determined by election in an organization of the alliance chain, namely a trading system of the alliance chain, and other trading nodes are subordinate to the main trading node. When the slave transaction node receives the block synchronization request sent by the master transaction node, the signature of the block synchronization request in the block synchronization request is verified, and whether the signature of the block synchronization request belongs to the master transaction node in the organization is verified.

S220, if the signature of the block synchronization request belongs to the signature of the master transaction node, updating the account book status database of the slave transaction node based on the update log of the block status in the block synchronization request.

Specifically, if the signature of the block synchronization request belongs to the signature of the master transaction node, the slave transaction node trusts the master transaction node, reads each transaction update log of the block state update logs in the block synchronization request, writes each update log into the account book state database of the slave transaction node in batches, and updates the account book state database.

The account book state database of the slave transaction node is updated through the transaction update log generated by the master transaction node in the IO read-write disk, so that verification and calculation of transactions are omitted, and calculation resources are greatly saved.

And S230, storing the block head in the block synchronization request in a local disk of the slave transaction node.

Specifically, the block header in the block synchronization request is persistently stored in the local disk of the slave transaction node, so that the slave transaction node synchronizes the block of the master transaction node.

It should be noted that, after the slave transaction node processes one block synchronization request each time, a chain formed by the ledger status and the block header, which are the same as those of the master transaction node, can be established. When the master trading node fails, a new master trading node is generated in the slave trading nodes through election, and the new master trading node can seamlessly join the original master trading node to perform block verification and execution work.

According to the technical scheme of the embodiment, when a slave transaction node receives a block synchronization request sent by a master transaction node, identity verification is carried out on the master transaction node according to a block synchronization request signature in the block synchronization request; if the signature of the block synchronization request belongs to the signature of the main transaction node, updating an account book state database of the slave transaction node based on a block state update log in the block synchronization request; and storing the block head in the block synchronization request in a local disk of the slave transaction node. The verification and calculation logic of the transaction is integrated in the main transaction node; based on the block synchronization request of the master transaction node, the transaction state update log of the master transaction node is updated to the account book state database of the slave transaction node in a simple IO read-write mode, and therefore computing resources of the slave transaction node are greatly saved.

Optionally, the method further includes:

acquiring a transaction request of an intelligent contract sent by a client;

executing the intelligent contract by reading or writing key-value pairs in the ledger status database to the ledger status database of the slave transaction node.

An intelligent contract is a computer protocol that aims to propagate, verify or execute contracts in an informational manner. It allows trusted transactions to be conducted without third parties, which transactions are traceable and irreversible.

Specifically, the slave transaction node is updated synchronously with the book status database and the block header of the master transaction node, so that the slave transaction node has the capability of executing the transaction request of the functional contract. For example, as shown in fig. 2B, the slave transaction node may obtain a transaction request of the smart contract sent by the client, and execute the transaction request of the smart contract by reading or writing a key-value pair in the ledger status database of the slave transaction node.

In the embodiment of the invention, based on the block synchronization request of the master transaction node, the transaction state update log of the master transaction node is updated to the account book state database of the slave transaction node in a simple IO read-write mode, so that the computing resources of the slave transaction node are greatly saved; and the account book state database and the block header of the slave transaction node and the master transaction node are synchronously updated, so that almost all computing resources can be used for processing the transaction request of the intelligent contract by the slave transaction node, the response speed of the system is greatly improved, and the transaction processing performance of the system is improved.

Optionally, the method further includes:

Specifically, in the organization of the federation chain, if a slave transaction node needs to be added, the block of the newly added slave transaction node needs to be synchronized with the ledger state database. As shown in fig. 2C, a new slave transaction node obtains all block synchronization requests from the archive node; for each block synchronization request, verifying whether a block synchronization request signature in the block synchronization request belongs to the master transaction node; after verification, updating the account book state database of the newly added slave transaction node in sequence based on the block state update logs contained in the block synchronization requests; and writing the block head in each verified block synchronization request into the local disk of the newly added slave transaction node. After the block header archiving and the ledger status database updating of the block synchronization request are completed by the newly added slave transaction node, the new block synchronization request can be received from the master transaction node as the slave transaction node subordinate to the master transaction node.

For example, a file download interface for accessing the block and block synchronization requests may be provided in the archive node, so that for the newly added slave transaction node, the manner of obtaining all block synchronization requests from the archive node may be: and the newly added transaction node downloads all the block synchronization requests through a file downloading interface of the filing node.

In the embodiment of the invention, when the newly added slave transaction node rebuilds the local account book state database, the update log of the block state from the 0 th block to the newest block can be directly obtained from the filing node in a file downloading mode, and the state update log is directly written into the account book state database, so that the preparation time of the newly added node is greatly shortened, the data state same as that of the existing slave transaction node can be quickly synchronized, and the rapid capacity expansion is realized.

EXAMPLE III

Fig. 3A is a flowchart of a federation chain transaction method according to a third embodiment of the present invention, where this embodiment is applicable to a situation where each transaction node in a federation chain synchronizes and stores transactions in a large traffic scene; the method may be performed by a federation chain transaction device in an embodiment of the present invention, which may be implemented in software and/or hardware, and which may be integrated in an archival node.

As shown in fig. 3A, the method of this embodiment specifically includes the following steps:

s310, when receiving the block archiving request sent by the master transaction node, verifying the block synchronization request signature and the block signature in the block synchronization request.

Wherein the block archiving request is sent by the primary transaction node, and the block archiving request may include: a block synchronization request, a block, and a block signature for the block.

Specifically, when receiving a block archiving request sent by the main transaction node, the archiving node verifies a block synchronization request signature and a block signature included in the block synchronization request, and determines whether the block synchronization request signature and the block signature belong to a signature of the main transaction node. And if the block synchronization request signature and the block signature belong to the signature of the main transaction node, the verification is passed.

S320, if the verification is passed, extracting the block synchronization request and the block in the block archiving request.

Specifically, if the verification is passed, i.e., the block synchronization request signature and the block signature belong to the signature of the master transaction node, the archive node extracts the block synchronization request and the blocks from the received block archive request.

S330, storing the block synchronization request and the block in a memory.

Specifically, the block synchronization request and the block are directly stored in the memory, so that the block state update log is saved in the storage module, and data backup is realized. The block synchronization request data and the corresponding blocks are sequentially added into the storage module, and the sequential disk write IO of the large block data can achieve extremely high disk write performance.

According to the technical scheme of the embodiment, by introducing the archiving node, when receiving a block archiving request sent by a main transaction node, the archiving node verifies a block synchronization request signature and a block signature in the block synchronization request; if the verification is passed, the block synchronization request in the block archiving request is extracted, and the block synchronization request and the blocks are stored in a memory, so that the problem that in the prior art, each transaction node needs to process the transaction request and perform data backup, and the storage pressure of each transaction node is high is solved, the complete blocks which pass through the verification of the main transaction node and the generated block state update logs are stored in the archiving node, the archiving node is specially responsible for the data archiving responsibility, and the storage pressure of each transaction node is reduced because the complete blocks are not required to be stored in the storage block heads of the transaction nodes.

Optionally, the storage module is a local disk or an external system database.

Specifically, the Storage module for storing the blocks and the block synchronization request may be a local disk of the archive node, or may be an external system database other than the archive node, such as an Object Storage Service (OSS), a structured query database (SQL), and a Distributed Database (DDB).

The archive node may implement more advanced data backup capabilities by supporting external storage, such as: backup, same city or allopatric disaster recovery in the data center, solve the problem that in the prior art, due to the limitation of transaction performance, cross-regional deployment of transaction nodes cannot be performed to meet the requirement of data disaster recovery.

Optionally, the method further includes:

analyzing the block to obtain each transaction in the block;

storing the index in the memory.

Specifically, the archiving node analyzes the block extracted from the block archiving request to obtain each transaction in the block, and the transaction and the index of the block are constructed and stored in an index database in the memory based on business needs, so that transaction query is facilitated.

Illustratively, as shown in fig. 3B, an index is established based on the correspondence between the block number of the block and the transaction number; binding a block synchronous request corresponding to a block with a block number; storing the index in the memory.

Example four

Fig. 4 is a schematic structural diagram of a transaction device in a federation chain according to a fourth embodiment of the present invention. The embodiment is applicable to a situation where each transaction node in the alliance chain synchronizes and stores the transaction in a large traffic scene, the apparatus may be implemented in a software and/or hardware manner, the apparatus may be integrated in a main transaction node, the main transaction node may be a terminal device, as shown in fig. 4, and the apparatus for the alliance chain transaction specifically includes: an acquisition module 410, a synchronization request module 420, and an archive request module 430.

The acquiring module 410 is configured to acquire a block from a consensus node, and sequentially execute each valid transaction in the block, where the valid transaction is a transaction verified by a main transaction node;

a synchronization request module 420, configured to generate a block synchronization request according to a transaction status update log generated by executing each valid transaction and a block header of the block, and send the block synchronization request to each slave transaction node, so that each slave transaction node updates the ledger status database of the slave transaction node synchronously according to the block synchronization request;

an archive request module 430 configured to generate a block archive request based on the block, the block signature of the block, and the block synchronization request, and send the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory.

Optionally, the synchronization request module 420 is specifically configured to:

writing each transaction state update log into a state update log queue;

Optionally, the method further includes:

and the block head storage module is used for storing the block head of the block in a local disk of the main transaction node after each effective transaction in the block is executed in sequence.

The product can execute the method provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method.

EXAMPLE five

Fig. 5 is a schematic structural diagram of a transaction device in a federation chain according to a fifth embodiment of the present invention. The embodiment may be applicable to a situation where each transaction node in the federation chain synchronizes and stores the transaction in a large traffic scene, the apparatus may be implemented in a software and/or hardware manner, the apparatus may be integrated in a slave transaction node, the slave transaction node may be a terminal device, as shown in fig. 5, and the apparatus for the federation chain transaction specifically includes: a first verification module 510, a first update module 520, and a first storage module 530.

The first verification module 510 is configured to verify a block synchronization request signature in a block synchronization request when the block synchronization request sent by a master transaction node is received;

a first updating module 520, configured to update the book state database of the slave transaction node based on the block state update log in the block synchronization request if the signature of the block synchronization request belongs to the signature of the master transaction node;

a first storage module 530, configured to store the chunk header in the chunk synchronization request in a local disk of the slave transaction node.

Optionally, the method further includes:

the transaction request acquisition module is used for acquiring a transaction request of the intelligent contract sent by the client;

and the execution module is used for reading the key value pair in the ledger state database or writing the key value pair into the ledger state database of the slave transaction node so as to execute the transaction request of the intelligent contract.

Optionally, the method further includes:

the synchronous request acquisition module is used for acquiring all block synchronous requests from the filing node for the newly added slave transaction node;

a third verifying module, configured to verify, for each block synchronization request, whether a block synchronization request signature in the block synchronization request belongs to the master transaction node;

the second updating module is used for updating the account book state database of the newly added slave transaction node in sequence based on the block state updating logs in the block synchronization requests passing the verification;

and the writing module is used for writing the block head in each verified block synchronization request into the local disk of the newly added slave transaction node.

EXAMPLE six

Fig. 6 is a schematic structural diagram of a transaction device in a federation chain according to a sixth embodiment of the present invention. The embodiment is applicable to a situation where each transaction node in the federation chain synchronizes and stores the transaction in a large traffic scene, the apparatus may be implemented in a software and/or hardware manner, the apparatus may be integrated in a filing node, the filing node may be a terminal device, as shown in fig. 6, and the apparatus for the federation chain transaction specifically includes: a second authentication module 610, a second storage module 620, and a third storage module 630.

The second verification module 610 is configured to verify a block synchronization request signature and a block signature in a block synchronization request when receiving a block archiving request sent by a primary transaction node;

an extracting module 620, configured to extract a block synchronization request and a block in the block archiving request if the verification passes;

a second storage module 630, configured to store the block synchronization request and the block in a memory.

Optionally, the method further includes:

the analysis module is used for analyzing the block to obtain each transaction in the block;

the index establishing module is used for establishing an index based on the corresponding relation between the block number of the block and the transaction number;

a binding module, configured to bind the block synchronization request corresponding to the block with the block number;

and the index storage module is used for storing the index in the memory.

Optionally, the storage module is a local disk or an external system database.

According to the technical scheme of the embodiment, by introducing the archiving node, when receiving a block archiving request sent by a main transaction node, the archiving node verifies a block synchronization request signature and a block signature in the block synchronization request; if the verification is passed, extracting a block synchronization request and a block in the block archiving request; the block synchronization request and the blocks are stored in the memory, the problem that in the prior art, each transaction node needs to process the transaction request and perform data backup, and the storage pressure of each transaction node is high is solved, the complete blocks which are verified by the main transaction node and the generated block state update logs are stored in the filing node, the filing node is specially responsible for data filing, and the complete blocks are not required to be stored in the head of the storage blocks in each transaction node, so that the storage pressure of each transaction node is reduced.

EXAMPLE seven

Fig. 7 is a schematic structural diagram of a transaction system of a federation chain according to a seventh embodiment of the present invention. The embodiment is applicable to a situation where each transaction node in the federation chain synchronizes and stores the transaction in a large traffic scene, and as shown in fig. 7, the system for the federation chain transaction specifically includes: a master trading node 710, a plurality of slave trading nodes 720 subordinate to the master trading node, and an archival node 730;

the main transaction node 710 is configured to obtain a block from a consensus node, and sequentially execute each valid transaction in the block, where the valid transaction is a transaction verified by the main transaction node; generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node; generating a block archive request based on the blocks, block signatures, and the block synchronization request, and sending the block archive request to an archive node,

each slave transaction node 720 is configured to verify a block synchronization request signature in a block synchronization request when receiving the block synchronization request sent by the master transaction node; if the signature of the block synchronization request belongs to the signature of the main transaction node, updating an account book state database of the slave transaction node based on a block state update log in the block synchronization request; storing a chunk header in the chunk synchronization request in a local disk of the slave transaction node;

the archive node 730, configured to verify a block synchronization request signature and a block signature in the block synchronization request when receiving a block archive request sent by a main transaction node; if the verification is passed, extracting a block synchronization request and a block in the block archiving request; storing the block synchronization request and the block in a memory.

Example eight

Fig. 8 is a schematic structural diagram of a terminal device in an eighth embodiment of the present invention. Fig. 8 shows a block diagram of an exemplary terminal device 12 suitable for use in implementing embodiments of the present invention. The terminal device 12 shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiment of the present invention.

As shown in fig. 8, terminal device 12 is in the form of a general purpose computing device. The components of terminal device 12 may include, but are not limited to: one or more processors or processors 16, a system memory 28, and a bus 18 that connects the various system components (including the system memory 28 and the processors 16).

Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, micro-channel architecture (MAC) bus, enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

Terminal device 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by terminal device 12 and includes both volatile and nonvolatile media, removable and non-removable media.

The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)30 and/or cache memory 32. Terminal device 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in FIG. 8, and commonly referred to as a "hard drive"). Although not shown in FIG. 8, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 by one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

A program/utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which examples or some combination thereof may comprise an implementation of a network environment. Program modules 42 generally carry out the functions and/or methodologies of the described embodiments of the invention.

Terminal device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), with one or more devices that enable a user to interact with terminal device 12, and/or with any devices (e.g., network card, modem, etc.) that enable terminal device 12 to communicate with one or more other computing devices. Such communication may be through an input/output (I/O) interface 22. In the terminal device 12 of the present embodiment, the display 24 is not provided as a separate body but is embedded in the mirror surface, and when the display surface of the display 24 is not displayed, the display surface of the display 24 and the mirror surface are visually integrated. Also, terminal device 12 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet) via network adapter 20. As shown, the network adapter 20 communicates with the other modules of the terminal device 12 via the bus 18. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with terminal device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

The processor 16 executes various functional applications and data processing by executing programs stored in the system memory 28, for example, to implement the federation chain transaction method provided in the first embodiment of the present invention: acquiring blocks from a consensus node, and sequentially executing each effective transaction in the blocks; generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node so that each slave transaction node synchronously updates an account book state database of each slave transaction node according to the block synchronization request; generating a block archive request based on the block, a block signature for the block, and the block synchronization request, and sending the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory; or implementing a federation chain transaction method as provided in the second embodiment of the present application: when a block synchronization request sent by a main transaction node is received, verifying a block synchronization request signature in the block synchronization request; if the signature of the block synchronization request belongs to the signature of the main transaction node, updating an account book state database of the slave transaction node based on a block state update log in the block synchronization request; storing a chunk header in the chunk synchronization request in a local disk of the slave transaction node; or the method provided by the third embodiment of the invention of the application is realized: when a block archiving request sent by a main transaction node is received, verifying a block synchronization request signature and a block signature in the block synchronization request; if the verification is passed, extracting a block synchronization request and a block in the block archiving request; storing the block synchronization request and the block in a memory.

EXAMPLE five

An embodiment five of the present invention provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a federation chain transaction method as provided in the first embodiment of the present application: acquiring blocks from a consensus node, and sequentially executing each effective transaction in the blocks; generating a block synchronization request according to a transaction state update log generated by executing each effective transaction and a block header of the block, and sending the block synchronization request to each slave transaction node so that each slave transaction node synchronously updates an account book state database of each slave transaction node according to the block synchronization request; generating a block archive request based on the block, a block signature for the block, and the block synchronization request, and sending the block archive request to an archive node to cause the archive node to store the block and the block synchronization request in memory; or implementing a federation chain transaction method as provided in the second embodiment of the present application: when a block synchronization request sent by a main transaction node is received, verifying a block synchronization request signature in the block synchronization request; if the signature of the block synchronization request belongs to the signature of the main transaction node, updating an account book state database of the slave transaction node based on a block state update log in the block synchronization request; storing a chunk header in the chunk synchronization request in a local disk of the slave transaction node; or the method provided by the third embodiment of the invention of the application is realized: when a block archiving request sent by a main transaction node is received, verifying a block synchronization request signature and a block signature in the block synchronization request; if the verification is passed, extracting a block synchronization request and a block in the block archiving request; storing the block synchronization request and the block in a memory.

Any combination of one or more computer-readable media may be employed. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A federation chain transaction method applied to a primary transaction node, the method comprising:

2. The method of claim 1, wherein generating a block synchronization request based on a transaction status update log generated by executing each of the valid transactions and a block header of the block comprises:

writing each transaction state update log into a state update log queue;

3. The method of claim 1, further comprising, after performing each valid transaction in the block in turn:

4. A federation chain transaction method applied to a slave transaction node, the method comprising:

5. The method of claim 4, further comprising:

acquiring a transaction request of an intelligent contract sent by a client;

6. The method of claim 4, further comprising:

7. A federation chain transaction method applied to an archival node, the method comprising:

storing the block synchronization request and the block in a memory.

8. The method of claim 7, further comprising:

analyzing the block to obtain each transaction in the block;

storing the index in the memory.

9. The method of claim 8, wherein the storage module is a local disk or an external system database.

10. A federation chain transaction apparatus, comprising:

11. A federation chain transaction apparatus, comprising:

12. A federation chain transaction apparatus, comprising:

13. A federation chain transaction system, comprising: a master trading node, a plurality of slave trading nodes subordinate to the master trading node, and an archival node;

14. A terminal device, characterized in that the device comprises:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the blockchain transaction method of any one of claims 1-3, the blockchain transaction method of any one of claims 4-6, or the blockchain transaction method of any one of claims 7-9.

15. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the blockchain transaction method according to any one of claims 1 to 3, the blockchain transaction method according to any one of claims 4 to 6 or the blockchain transaction method according to any one of claims 7 to 9.