Disclosure of Invention
The specification provides a transaction processing method based on a blockchain, which is applied to a client, wherein a Nonce list corresponding to a user account is maintained in the blockchain, the Nonce list comprises a plurality of Nonce records, the Nonce records comprise packet identifications and Nonce values, and the method comprises the following steps:
The available Nonce records with the same grouping identifier are respectively obtained from the Nonce list for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently;
adding the obtained available Nonce records to the plurality of transactions respectively;
Issuing the multiple transactions to the blockchain, so that node equipment in the blockchain can match available Nonce records in the transactions issued by the client with Nonce records in the Nonce list, accept the transactions when the available Nonce records are matched with any target Nonce record in the Nonce list, and concurrently execute multiple transactions with the same grouping identification in the accepted transactions.
Optionally, the multiple transactions that need to be executed concurrently include multiple transactions with the same transaction type.
Optionally, the method further comprises:
if a plurality of groups of transactions which are required to be executed concurrently exist in the transactions initiated by the user through the user account, determining the execution sequence of the plurality of groups of transactions;
And respectively acquiring available Nonce records with the same grouping identifiers for the multiple groups of transactions from the Nonce list, wherein the grouping identifiers indicate the execution sequence of the multiple groups of transactions.
Optionally, before the available Nonce records with the same packet identifier are respectively obtained from the Nonce list for the multiple transactions that need to be concurrently executed and are initiated by the user through the user account, the method further includes:
responding to an initialization instruction aiming at the client, acquiring the Nonce list maintained in the blockchain, and maintaining the acquired Nonce list locally at the client;
The available Nonce records with the same grouping identifier are respectively obtained from the Nonce list for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently, and the available Nonce records comprise:
and respectively acquiring available Nonce records with the same grouping identifier for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently from the Nonce list locally maintained by the client.
Optionally, the Nonce record in the Nonce list maintained locally by the client is marked as available by default;
the method further comprises the steps of:
and respectively acquiring available Nonce records with the same grouping identifier from the Nonce list locally maintained by the client, and marking the available Nonce records as unavailable in the Nonce list after the available Nonce records with the same grouping identifier are respectively acquired for a plurality of transactions which are initiated by a user through a user account and need to be concurrently executed.
Optionally, the method further comprises:
Determining whether a notification message returned by the node equipment is received, wherein the notification message is accepted by the transaction;
And if so, monotonously increasing the Nonce value in the available Nonce records based on a preset amplitude, and re-marking the available Nonce records as available in the Nonce list after the monotonously increasing the Nonce value.
Optionally, the client is a multithreaded client, and the number of Nonce records in the Nonce list indicates transaction concurrency capability of the user account.
Optionally, the Nonce record further comprises an index identification of the Nonce record.
The specification also provides a transaction processing method based on a blockchain, which is applied to node equipment in the blockchain, wherein the blockchain maintains a Nonce list set, the Nonce list set comprises Nonce lists corresponding to a plurality of user accounts, the Nonce list comprises a plurality of Nonce records, the Nonce records comprise packet identifications and Nonce values, and the method comprises the following steps:
receiving a transaction initiated by a user through a user account and sent by a client, wherein the transaction is added with an available Nonce record obtained from a Nonce list corresponding to the user account and maintained in the blockchain;
Matching available Nonce records in the received transaction with Nonce records in a Nonce list corresponding to the user account maintained in the blockchain;
If the available Nonce record is matched with any target Nonce record in the Nonce list, accepting the transaction; and concurrently executing multiple transactions with the same group identification in the accepted transactions.
Optionally, the client indicates the execution sequence of the multiple groups of transactions for the group identifications in the available Nonce records added by the multiple groups of transactions;
the method further comprises the steps of:
And if the plurality of groups of transactions with the same grouping identifications of the plurality of groups of transactions are contained in the transactions sent by the client, sequentially executing the plurality of groups of transactions according to the execution sequence indicated by the grouping identifications of the plurality of groups of transactions.
Optionally, the method further comprises:
Monotonously increasing the Nonce value of any target Nonce record in the Nonce list based on a preset amplitude if the available Nonce record matches any target Nonce record in the Nonce list, and
And returning a notification message that the transaction is accepted to the client.
Optionally, the Nonce record further comprises an index identification of the Nonce record.
The specification also provides a transaction processing device based on a blockchain, which is applied to a client, wherein a Nonce list corresponding to the user account is maintained in the blockchain, the Nonce list comprises a plurality of Nonce records, the Nonce records comprise packet identifications and Nonce values, and the method comprises the following steps:
The acquisition module is used for respectively acquiring available Nonce records with the same grouping identifier for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently from the Nonce list;
the adding module is used for respectively adding the obtained available Nonce records to the plurality of transactions;
And the issuing module issues the multiple transactions to the blockchain, so that node equipment in the blockchain can match available Nonce records in the transactions issued by the client with Nonce records in the Nonce list, accept the transactions when the available Nonce records are matched with any target Nonce record in the Nonce list, and concurrently execute multiple transactions with the same grouping identifier in the accepted transactions.
Optionally, the multiple transactions that need to be executed concurrently include multiple transactions with the same transaction type.
Optionally, the acquiring module further:
if a plurality of groups of transactions which are required to be executed concurrently exist in the transactions initiated by the user through the user account, determining the execution sequence of the plurality of groups of transactions;
And respectively acquiring available Nonce records with the same grouping identifiers for the multiple groups of transactions from the Nonce list, wherein the grouping identifiers indicate the execution sequence of the multiple groups of transactions.
Optionally, the acquiring module further:
Before available Nonce records with the same grouping identifier are respectively obtained from the Nonce list for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently, responding to an initialization instruction aiming at the client, obtaining the Nonce list maintained in the blockchain, and maintaining the obtained Nonce list locally at the client;
and respectively acquiring available Nonce records with the same grouping identifier for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently from the Nonce list locally maintained by the client.
Optionally, the Nonce record in the Nonce list maintained locally by the client is marked as available by default;
The acquisition module is used for:
and respectively acquiring available Nonce records with the same grouping identifier from the Nonce list locally maintained by the client, and marking the available Nonce records as unavailable in the Nonce list after the available Nonce records with the same grouping identifier are respectively acquired for a plurality of transactions which are initiated by a user through a user account and need to be concurrently executed.
Optionally, the acquiring module further:
Determining whether a notification message returned by the node equipment is received, wherein the notification message is accepted by the transaction;
And if so, monotonously increasing the Nonce value in the available Nonce records based on a preset amplitude, and re-marking the available Nonce records as available in the Nonce list after the monotonously increasing the Nonce value.
Optionally, the client is a multithreaded client, and the number of Nonce records in the Nonce list indicates transaction concurrency capability of the user account.
Optionally, the Nonce record further comprises an index identification of the Nonce record.
The specification also provides a transaction processing device based on a blockchain, which is applied to node equipment in the blockchain, wherein the blockchain maintains a Nonce list set, the Nonce list set comprises Nonce lists corresponding to a plurality of user accounts, the Nonce list comprises a plurality of Nonce records, the Nonce records comprise packet identifications and Nonce values, and the method comprises the following steps:
the system comprises a receiving module, a receiving module and a processing module, wherein the receiving module receives a transaction initiated by a user through a user account and sent by a client, and the transaction is added with an available Nonce record acquired from a Nonce list corresponding to the user account and maintained in the blockchain;
The matching module is used for matching the available Nonce record in the received transaction with the Nonce record in the Nonce list corresponding to the user account and maintained in the blockchain;
And the execution module is used for receiving the transaction if the available Nonce record is matched with any target Nonce record in the Nonce list, and concurrently executing a plurality of transactions with the same grouping identification in the received transaction.
Optionally, the client indicates the execution sequence of the multiple groups of transactions for the group identifications in the available Nonce records added by the multiple groups of transactions;
The execution module further:
And if the plurality of groups of transactions with the same grouping identifications of the plurality of groups of transactions are contained in the transactions sent by the client, sequentially executing the plurality of groups of transactions according to the execution sequence indicated by the grouping identifications of the plurality of groups of transactions.
Optionally, the execution module further:
Monotonously increasing the Nonce value of any target Nonce record in the Nonce list based on a preset amplitude if the available Nonce record matches any target Nonce record in the Nonce list, and
And returning a notification message that the transaction is accepted to the client.
Optionally, the Nonce record further comprises an index identification of the Nonce record.
The present specification also proposes an electronic device comprising:
A processor;
a memory for storing machine-executable instructions;
wherein, by reading and executing the machine-executable instructions stored by the memory corresponding to the control logic for blockchain-based transaction processing, the processor is caused to:
The method comprises the steps of respectively acquiring available Nonce records with the same grouping identifier for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently from a Nonce list corresponding to the user account and maintained in a blockchain, wherein the Nonce list comprises a plurality of Nonce records;
adding the obtained available Nonce records to the plurality of transactions respectively;
Issuing the multiple transactions to the blockchain, so that node equipment in the blockchain can match available Nonce records in the transactions issued by the client with Nonce records in the Nonce list, accept the transactions when the available Nonce records are matched with any target Nonce record in the Nonce list, and concurrently execute multiple transactions with the same grouping identification in the accepted transactions.
The present specification also proposes an electronic device comprising:
A processor;
a memory for storing machine-executable instructions;
wherein, by reading and executing the machine-executable instructions stored by the memory corresponding to the control logic for blockchain-based transaction processing, the processor is caused to:
Receiving a transaction initiated by a user through a user account sent by a client, wherein the transaction is added with available Nonce records obtained from a Nonce list corresponding to the user account, which is maintained in the blockchain, wherein the Nonce list comprises a plurality of Nonce records;
Matching available Nonce records in the received transaction with Nonce records in a Nonce list corresponding to the user account maintained in the blockchain;
If the available Nonce record is matched with any target Nonce record in the Nonce list, accepting the transaction; and concurrently executing multiple transactions with the same group identification in the accepted transactions.
Through the embodiment, the technical scheme of the transaction concurrency capability of the single account on the client can be further improved on the basis of avoiding replay attack for the transaction.
Detailed Description
Replay attack in the blockchain field refers to the attack behavior of releasing repeated transactions in the blockchain to further cause that the same transaction is executed for a plurality of times, thereby causing loss to users;
After a transfer transaction is approved by the signature of the private key of the user, if the transfer transaction is intercepted by an illegal node, the illegal node can initiate replay attack based on the intercepted transaction after the execution of the transaction is finished, repeatedly issue and execute the transaction in a blockchain, so that the transfer transaction is executed for a plurality of times, and further, funds loss is caused to the user.
In one embodiment shown, the replay attack risk for a transaction may be generally addressed in such a way that a densely incremented Nonce value (densely incremented integer) is carried in the transaction;
referring to fig. 1, fig. 1 is a schematic diagram illustrating replay attack detection for a transaction according to the present disclosure.
As shown in fig. 1, each transaction initiated by a user on a client through a personal user account may specify a Nonce value and sign the transaction body of the transaction and the specified Nonce value using a private key held by the user. The signature is an integral signature of the transaction body and the Nonce value, so that the Nonce in the transaction can be guaranteed to be unable to be tampered.
When the signature is complete, the client may publish the transaction in the blockchain. The node device in the blockchain needs to verify whether the signature of the transaction is legal or not, detect whether the Nonce value in the transaction keeps strictly compact increment with the Nonce value in the last transaction successfully accepted before after receiving the transaction, accept the transaction if the transaction keeps strictly compact increment with the Nonce value in the last transaction successfully accepted before, and otherwise, judge the comparison transaction as illegal transaction.
For example, suppose that a user initiates a transaction with a Nonce value of 1 on a client through an individual user Account Account1, and after the transaction is successfully accepted by the blockchain, when the user initiates a transaction again on the client through Account1, the Nonce value in the transaction must be designated as 2, so that the transaction is accepted as a legal transaction by node devices in the blockchain.
The blockchain system maintains the Nonce state of the user Account of the user, and each time a transaction initiated by Account1 is successfully accepted, the blockchain system automatically increases the Nonce value of the user Account by 1, node equipment in the blockchain compares the Nonce value in the transaction with the Nonce value in the maintained Nonce state after receiving the transaction issued by the client, so as to judge whether the Nonce value in the transaction is strictly increased by 1 with the Nonce value in the latest transaction which has been successfully accepted, and if so, the transaction can be accepted.
In this way, although the replay attack risk of the transaction can be avoided to a certain extent, the user account needs to be accepted before the next transaction can be continuously initiated, so that the single-account transaction concurrency capability is insufficient and the application cannot be performed in a high concurrency scene.
Based on this, in the present specification, on the basis of the replay attack protection scheme shown above, a technical scheme capable of improving the transaction concurrency capability of a single account on a client is provided.
When implemented, a set of Nonce lists may be maintained in the blockchain, where Nonce lists corresponding to several user accounts may be included, and where several Nonce records may be included, each Nonce record being composed of a packet identity and a Nonce value.
After a user initiates a plurality of transactions to be executed concurrently through a personal user account on a client, the client can obtain available Nonce records with the same grouping identifier for the plurality of transactions from the Nonce list, add the obtained available Nonce records to the plurality of transactions, and then issue the plurality of transactions to a blockchain.
After receiving the transaction sent by the client, the node device in the blockchain can match the available Nonce record carried in the transaction with the Nonce record in the Nonce list corresponding to the user account maintained in the blockchain to detect replay attack of the transaction; if the available Nonce record is matched with any target Nonce record in the Nonce list, detecting that replay attack for the transaction is passed, and at the moment, the node equipment can accept the transaction;
Further, the node device can confirm again whether a plurality of transactions with the same grouping identification in the carried Nonce record exist in all the accepted transactions, if so, the node device can execute the plurality of transactions with the same grouping identification in the accepted transactions concurrently. In the above embodiment, by adding the same grouping identifier to multiple transactions to trigger node devices in the blockchain to concurrently execute multiple transactions with the same grouping identifier, in combination with replay attack detection for the transactions, the transaction concurrency capability of a single account on a client can be further improved on the basis of avoiding replay attacks for the transactions.
The following description is made by specific embodiments and with reference to specific application scenarios.
Referring to fig. 2, fig. 2 is a block chain-based transaction processing method according to an embodiment of the present disclosure, wherein the method performs the following steps:
Step 202, a client acquires available Nonce records with the same grouping identifier from a Nonce list corresponding to a user account maintained in a blockchain for a plurality of transactions which are initiated by a user through the user account and need to be executed concurrently, wherein the Nonce list comprises a plurality of Nonce records, and the Nonce records comprise the grouping identifier and the Nonce value;
step 204, the client adds the obtained available Nonce records to the plurality of transactions respectively, and issues the plurality of transactions to the blockchain;
Step 206, the node device in the blockchain matches the available Nonce record in the received transaction with the Nonce record in the Nonce list corresponding to the user account maintained in the blockchain, accepts the transaction if the available Nonce record is matched with any target Nonce record in the Nonce list, and concurrently executes a plurality of transactions with the same grouping identification in the accepted transaction.
The blockchains described in the present specification may specifically include private chains, common chains, and federated chains, and the like, and are not particularly limited in the present specification.
For example, in one scenario, the blockchain may specifically be a coalition chain composed of servers of third party paystations, in-home banking servers, out-of-home banking servers, and several user node devices as member devices. Operators of the federated chain may rely on the federated chain to deploy online services such as cross-border transfers, asset transfers, etc., based on the federated chain.
It should be noted that, the Transaction (Transaction) described in the present specification refers to a piece of data that is created by a client of the blockchain and needs to be finally published to a distributed database of the blockchain.
Transactions in blockchains typically exist in a narrow sense as well as a broad sense of the transaction. A narrow transaction refers to a transfer of value that a user publishes to a blockchain. While a generalized transaction refers to a piece of business data with business intent issued by a user to a blockchain, for example, an operator may build a coalition chain based on actual business needs, rely on the coalition chain to deploy some other types of online business (such as anti-counterfeit verification business, rental business, vehicle dispatch business, insurance claim settlement business, credit service, medical service, etc.) unrelated to value transfer, and in such a coalition chain, the transaction may be a business message or a business request with business intent issued by the user in the coalition chain.
In this specification, the client may be a multithreaded client, that is, the client may enable multiple threads simultaneously, and each thread may run independently, so that a user may initiate multiple transactions simultaneously by calling multiple threads of the client and through a personal user account.
After receiving a plurality of transactions initiated by a user through a user account, the client can determine whether a plurality of transactions which need to be executed concurrently exist in the transactions initiated by the user through the user account;
in this specification, the multiple transactions that need to be executed concurrently may include any type of transactions, where there is no strict order of executing the transactions, and the transactions can be processed and executed concurrently;
For example, if one transaction is executed, the execution result of the other transaction is required to be input, the two transactions cannot be processed and executed concurrently, otherwise, if the two transactions do not have the data dependency relationship described above, the two transactions can be processed and executed concurrently.
When the method is implemented, a plurality of transactions which need to be executed concurrently can be manually appointed by a user in the process of initiating the transactions through a user account;
for example, in one embodiment shown, after a user initiates numerous transactions, multiple transactions that need to be performed concurrently may be manually specified based on demand through a user interface provided by the client.
In practical application, multiple transactions that need to be executed concurrently can also be dynamically confirmed by the client based on preset concurrent processing rules.
The specific content of the concurrent processing rule is not particularly limited in the present specification, and in practical application, a person skilled in the art can flexibly define the concurrent processing rule based on the actual concurrent processing requirement;
for example, in one embodiment shown, the concurrency execution rule may be a rule of "concurrency execution for transactions of the same transaction type";
In this case, the client may further check specific transaction types of the transactions after receiving numerous transactions initiated by the user, and then determine a plurality of transactions having the same transaction type as transactions to be executed concurrently, e.g., if the transaction types supported by the blockchain include a transaction type for creating an account and a transaction type for transferring, the client may determine a transaction type for creating an account and a transaction type for transferring among the numerous transactions initiated by the user, and then determine a plurality of transactions corresponding to the two transaction types as transactions to be executed concurrently.
Of course, in practical applications, the above-mentioned concurrent processing rule may be a rule of "concurrent execution for transactions of the same transaction type", or may be another form of concurrent processing rule, and is not listed in the present specification.
In this specification, a set of Nonce lists may be maintained in the blockchain, in which Nonce lists corresponding to several user accounts may be included. In the above-described Nonce list, a plurality of Nonce records may be included. And each Nonce record may include an auxiliary parameter and a Nonce value.
That is, in the present specification, the Nonce record may specifically be a composite structure composed of a plurality of fields including a Nonce value.
When the method is implemented, an operator of the blockchain can allocate an available Nonce value for each user account in advance, set a corresponding auxiliary field for each Nonce value on the basis of the allocated available Nonce value, and construct a plurality of Nonce records based on each available Nonce value and the corresponding auxiliary field;
And finally, the Nonce list set can be created based on the Nonce list constructed for each user account, the Nonce list set is issued to the blockchain, the node equipment in the blockchain performs consensus processing, and after the consensus is passed, the Nonce list set is stored in distributed data of the blockchain for storage and maintenance.
In practical applications, the auxiliary parameters may specifically include any form of parameters that the operator of the blockchain expands based on actual requirements based on Nonce values available to the user account, or combinations of parameters.
That is, in practical applications, the number and types of parameters that can be included in the auxiliary parameters may not be fixed, any one of the parameters may be extended based on the Nonce value to serve as the auxiliary parameter, or a plurality of parameters may be extended based on the Nonce value to serve as the auxiliary parameter.
In the present disclosure, the auxiliary parameter in the Nonce record in the Nonce list may specifically include a packet identifier, where the packet identifier is specifically used to indicate a packet in which a transaction is located, and transactions belonging to the same packet are transactions that need to be executed concurrently, where the Nonce list in the Nonce list set corresponding to each user account may each include a plurality of Nonce records with the same packet identifier, so that when a user initiates a plurality of transactions that need to be executed concurrently through a personal user account, a client may obtain, from the Nonce list, a Nonce record with the same packet identifier for the plurality of transactions.
In one embodiment shown, the auxiliary parameters in the Nonce records in the Nonce list may further include an index identifier (such as an index number) of the Nonce record in addition to the packet identifier. The index identifier is specifically used for indicating the sequence and the position of the Nonce recorded in the Nonce list.
For example, referring to fig. 3, taking the auxiliary parameter in the Nonce record in the Nonce list and including the packet identifier and the Index identifier of the Nonce record as an example, the Nonce record may specifically be a composite structure formed by fields such as a Group ID (packet identifier), index (Index identifier), value (Nonce Value), and the like. In this case, the set of Nonce lists maintained in the blockchain may be represented in the form as shown in fig. 3.
In practical applications, the method can be flexibly set based on the actual requirements of operators of the blockchain (for example, the operators can control the specific value ranges of the Nonce values and the auxiliary parameters through the occupied byte lengths);
for example, in one implementation, the Nonce record may specifically be a 16-byte composite structure, where 4 bytes represent the Group ID (packet identifier), 4 bytes represent the Index (Index identifier), and 8 bytes represent the Value (Nonce Value).
By expanding a plurality of parameters to be used as auxiliary parameters on the basis of the Nonce value, the Nonce records in the Nonce table can cover rich value fields, so that the probability of collision of a plurality of Nonce records in the Nonce table due to the same value can be reduced;
For example, the probability of collision that two Nonce records with a total length of 12 bytes, which are composed of a Group ID (packet identification) and a Value (Nonce Value), are identical is much lower than the probability that two Nonce records with a total length of 16 bytes, which are composed of a Group ID (packet identification), an Index (Index identification) and a Value (Nonce Value), are identical.
Referring to fig. 4, when a user invokes multiple threads enabled by a client on the client, and initiates multiple transactions to be executed concurrently through a personal user account, the client may obtain available Nonce records with the same grouping identifier for the multiple transactions respectively (i.e. add the same grouping identifier for the multiple transactions) from the Nonce list corresponding to the user account maintained on the blockchain.
Because the Nonce list comprises a plurality of Nonce records, the multithreading started by the client can acquire available Nonce records from the Nonce list for the initiated transaction, and a user can use an individual user account to initiate a plurality of transactions simultaneously through the client. For example, the Nonce list includes 4 Nonce records, and then the user may initiate 4 transactions simultaneously through the user account.
Based on this, in practical application, the operator of the blockchain can flexibly specify the number of the Nonce records contained in the Nonce list based on the performance of the client, or the client can actively report the performance of the client to the blockchain system, and the operator of the blockchain flexibly specifies the number of the Nonce records contained in the Nonce list;
for example, assuming a performance decision of a client that can launch 4 threads simultaneously to initiate a transaction, 4 available Nonce records can be added to the Nonce list when creating the above-described Nonce list for a user account logging into the client.
In one embodiment shown, the client may "download" the above-described Nonce list maintained on the blockchain to the local for maintenance in advance during the initialization phase;
For example, when implemented, the client initiates a run or when a connection with a node device in the blockchain is disconnected and needs to be reconnected, an initialization operation is needed. In this case, when the client receives an initialization instruction (such as a start instruction, a reconnection instruction, etc.) triggered by the user for the client, a connection may be established with a node device in the blockchain in response to the initialization instruction, and the distributed database of the blockchain may be accessed based on the connection, so as to obtain the Nonce list maintained in the blockchain, and then the obtained Nonce list may be stored and maintained locally.
In this case, when the client needs to obtain available Nonce records with the same packet identifier for the multiple transactions, the available Nonce records may be obtained directly from the locally maintained Nonce list.
By the method, data interaction with node equipment on the blockchain can be avoided, data is read from the Nonce list maintained in the blockchain, an available Nonce record is obtained for the target transaction, and processing performance of the client can be improved.
In this case, if the user initiates a transaction through the user account, there are multiple groups of transactions that need to be executed concurrently in the multiple groups of transactions, and the client can further confirm the execution sequence of the multiple groups of transactions;
the execution sequence of the multiple groups of transactions may be defined manually by a user, or may be dynamically confirmed by a client based on an actual business process, which is not specifically limited in the present specification.
Further, after determining the execution sequence of the multiple sets of transactions, the client needs to ensure that the packet identifier added for the multiple sets of transactions contained in the multiple sets of transactions is capable of indicating the execution sequence of the multiple sets of transactions, in addition to adding the same packet identifier for the multiple sets of transactions contained in the multiple sets of transactions;
In this case, the Nonce list needs to include a plurality of Nonce records having the same packet identifier and different packet identifiers of the transaction packets having the same value, that is, the packet identifiers of the transactions in the same transaction packet are kept the same, and the transaction packet identifiers of the transaction packets having the same value are kept a certain difference, so that it is ensured that the same packet identifier is obtained from the Nonce list for the transactions in the plurality of transaction packets, and the packet identifiers indicate available Nonce records of the execution sequence of the plurality of transaction packets. The method comprises the steps of utilizing group identifiers to indicate the execution sequence of a plurality of groups of transactions, and specifically, adding the group identifiers which keep monotonically increasing in value for the plurality of groups of transactions;
For example, assume that if there are two sets of transactions { A1, B1, C1} and { A2, B2, C2} that the user initiates through the user account, the included transactions need to be performed concurrently, in which case the client may obtain an available Nonce record for the transactions A1, B1, C1 containing the same packet identity 1 from the above-described Nonce list, obtain an available Nonce record for the transactions A2, B2, C2 containing the same packet identity 2, and represent the transaction packet { A1, B1, C1} by incrementing the packet identity value, which needs to be performed prior to the transaction packet { A2, B2, C2 }. That is, the execution order of the transaction groups is consistent with the order of the added transaction identifications from small to large.
In one embodiment shown, for the above-described Nonce list maintained locally by the client, a flag indicating "available" may be added by the client for each Nonce record in the Nonce list by default.
For example, referring to fig. 5, still taking the above-mentioned Nonce record as the composite structure composed of 16 bytes shown in fig. 4 as an example, an Available field of 1 byte may be extended for the Nonce record in the Nonce list, where when the value of the Available field is T, it indicates that the Nonce record is "Available", and when the value of the Available field is F, it indicates that the Nonce record is "unavailable".
In one aspect, when a thread enabled on a client obtains available Nonce records for a plurality of transactions initiated by a user from the above-described Nonce list maintained locally by the client, a plurality of Nonce records with the same packet identity may be randomly selected as available Nonce records from all of the Nonce records marked as "available" in the above-described Nonce list.
On the other hand, when the thread enabled on the client acquires the available Nonce record from the Nonce list locally maintained by the client for a plurality of transactions initiated by the user, the mark carried by the available Nonce record may be modified and updated, and a mark indicating "unavailable" is newly added to the available Nonce record so as to mark the available Nonce record as unavailable.
In this specification, after the client acquires the available Nonce record for a plurality of transactions that are initiated by the user and need to be executed concurrently, the acquired available Nonce record may be added to the plurality of transactions;
For example, referring to fig. 4, after obtaining the available Nonce record for the transaction, the client may package the transaction body of the transaction and the available Nonce record, and then prompt the user to sign the packaged [ transaction body, nonce record ] integrally based on the held private key, so as to ensure that the Nonce record in the transaction cannot be tampered.
Further, after the client adds the obtained available Nonce record to the plurality of transactions, the client may issue the plurality of transactions to a blockchain;
For example, the client may issue the plurality of transactions to the node device to which the client accesses or broadcast the plurality of transactions in the blockchain, wherein the specific manner in which the client issues the plurality of transactions to the blockchain generally depends on the consensus mechanism employed by the blockchain and is not particularly limited in this specification.
When node equipment in the blockchain receives a transaction issued by a client, firstly, a consensus algorithm adopted in the blockchain can initiate consensus processing for the received transaction;
The consensus algorithm adopted by the blockchain and the consensus processing procedure of the target transaction based on the consensus algorithm are not described in detail in the present specification, and when the technical scheme described in the present specification is reduced to be implemented by a person skilled in the art, reference may be made to the description in the related art.
When the received transaction consensus passes, the node device in the blockchain can further initiate validity detection for the received transaction.
In this specification, the validity detection for the transaction may include at least validity detection for a signature carried by the transaction and replay attack detection for the transaction.
When the method is realized, the node equipment in the blockchain can firstly verify the signature of the received transaction based on the public key corresponding to the private key held by the user, and can determine that the transaction is illegal if the signature of the transaction fails, and the node equipment can directly return a prompt message of failure of executing the transaction to the user through the client.
If the signature verification of the transaction passes, the node device may perform replay attack detection on the transaction based on the available Nonce record carried in the target transaction and a Nonce list corresponding to the user account of the user in the blockchain.
On the one hand, referring to fig. 4, the node device may match the Nonce records carried in the transaction one by one from the Nonce records in the Nonce list corresponding to the user account maintained on the blockchain, and if the Nonce record carried in the transaction matches any one of the target Nonce records in the Nonce list, it may determine that the transaction passes the replay attack detection, and in this case, the node device may accept the transaction.
On the other hand, after the transaction is accepted, the node device can monotonically increase the Nonce value in the target Nonce record based on a preset amplitude, wherein the preset amplitude can be customized based on actual requirements;
For example, the preset amplitude may still be 1, and the node device may increase the Nonce value in the target Nonce record matched in the Nonce list by 1 after the transaction is accepted.
In this way, if a transaction is repeatedly issued again in the blockchain after being accepted, the repeatedly issued transaction will not be accepted again in the replay attack detection stage because the Nonce value in the target Nonce record in the Nonce list that matches the available Nonce record carried by the transaction has been updated, and thus the replay attack by repeatedly issuing the transaction in the blockchain will not be effectively avoided.
In one embodiment shown, a notification message that the transaction was accepted may be returned to the client after the transaction was accepted, and the client may determine whether a notification message that the transaction returned by the node device was accepted is received after issuing a transaction initiated by the user through the personal user account to the blockchain.
If it is confirmed that the notification message that the transaction was accepted is received:
In one aspect, the Nonce value in the available Nonce record obtained for the initiated transaction in the locally maintained Nonce list at the client may be monotonically increased based on a preset magnitude, e.g., the Nonce value in the available Nonce record is also self-increased by 1 to maintain content synchronization with the Nonce list maintained in the blockchain.
On the other hand, since the Available Nonce record has been marked as "unavailable" before, the value of the Available Nonce field of the Available Nonce record may be set to "T" after monotonically increasing the Nonce value in the Available Nonce record based on the preset amplitude.
In this description, when all transactions sent by the client and initiated by the user are accepted, the node device in the blockchain can further determine whether multiple transactions with the same grouping identifier exist in the accepted transactions sent by the client;
If the accepted transaction has a plurality of transactions with the same grouping identification, the node equipment in the blockchain can execute the plurality of transactions simultaneously, and after the execution of the plurality of transactions is finished, the plurality of transactions and the execution results of the plurality of transactions are stored in a distributed database of the blockchain.
Correspondingly, if the plurality of groups of transactions contained in the transaction sent by the client side have the same group identification, the plurality of groups of transactions are sent by the client side; in this case, the node device in the blockchain may execute the multiple groups of transactions sequentially according to the transaction sequence indicated by the transaction identifiers of the multiple groups of transactions after receiving the transaction with the added packet identifier sent by the client and determining that the multiple transactions with the same packet identifier of the multiple transactions included exist in the transaction sent by the client.
For example, there are two sets of transactions { A1, B1, C1} and { A2, B2, C2} that the user initiates through the user account, and the client adds an available Nonce record containing the same group identification 1 for transactions A1, B1, C1 and an available Nonce record containing the same group identification 2 for transactions A2, B2, C2, in which case the node devices in the blockchain will concurrently execute transactions A1, B2, C2 in the transaction group with group identification 1 first and then concurrently execute transactions A2, B2, C2 in the transaction group with group identification 2 after the transactions A1, B1, C2 in the above transaction group with group identification 1 are accepted.
In the scheme, the technical scheme that the node equipment in the blockchain is triggered to execute the plurality of transactions with the same grouping identifier in parallel by adding the same grouping identifier for the plurality of transactions is combined with replay attack detection for the transactions, so that the transaction concurrency capability of a single account on a client side can be further improved on the basis of avoiding replay attack for the transactions.
Corresponding to the above method embodiments, the present specification also provides embodiments of a blockchain-based transaction processing device. The embodiments of the blockchain-based transaction processing device of the present specification may be applied to an electronic device. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a nonvolatile memory into a memory by a processor of an electronic device where the device is located for operation. In terms of hardware, as shown in fig. 6, a hardware structure diagram of an electronic device where the blockchain-based transaction processing device in this specification is located is shown, and in addition to the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 6, the electronic device where the device is located in the embodiment generally may include other hardware according to the actual function of the electronic device, which is not described herein again.
FIG. 7 is a block diagram of a blockchain-based transaction processing device shown in an exemplary embodiment of the present description.
Referring to fig. 7, the blockchain-based transaction processing device 70 may be applied to the electronic device shown in fig. 6 and includes an acquisition module 701, an adding module 702 and a publishing module 703.
The acquisition module 701 is used for respectively acquiring available Nonce records with the same grouping identifier from a Nonce list corresponding to a user account and maintained in a blockchain for a plurality of transactions which are initiated by a user through the user account and need to be executed concurrently, wherein the Nonce list comprises a plurality of Nonce records;
An adding module 702, configured to add the obtained available Nonce records to the plurality of transactions respectively;
A publishing module 703 publishes the plurality of transactions to the blockchain, so that node devices in the blockchain match available Nonce records in the transactions published by the client with Nonce records in the Nonce list, accept the transactions when the available Nonce records match any target Nonce record in the Nonce list, and concurrently execute a plurality of transactions with the same group identifier in the accepted transactions.
In this embodiment, the multiple transactions that need to be executed concurrently include multiple transactions with the same transaction type.
In this embodiment, the obtaining module 701 further:
if a plurality of groups of transactions which are required to be executed concurrently exist in the transactions initiated by the user through the user account, determining the execution sequence of the plurality of groups of transactions;
And respectively acquiring available Nonce records with the same grouping identifiers for the multiple groups of transactions from the Nonce list, wherein the grouping identifiers indicate the execution sequence of the multiple groups of transactions.
In this embodiment, the obtaining module 701 further:
Before available Nonce records with the same grouping identifier are respectively obtained from the Nonce list for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently, responding to an initialization instruction aiming at the client, obtaining the Nonce list maintained in the blockchain, and maintaining the obtained Nonce list locally at the client;
and respectively acquiring available Nonce records with the same grouping identifier for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently from the Nonce list locally maintained by the client.
In this embodiment, the Nonce record in the Nonce list maintained locally by the client is marked as available by default;
The acquisition module 701:
and respectively acquiring available Nonce records with the same grouping identifier from the Nonce list locally maintained by the client, and marking the available Nonce records as unavailable in the Nonce list after the available Nonce records with the same grouping identifier are respectively acquired for a plurality of transactions which are initiated by a user through a user account and need to be concurrently executed.
In this embodiment, the obtaining module 701 further:
Determining whether a notification message returned by the node equipment is received, wherein the notification message is accepted by the transaction;
And if so, monotonously increasing the Nonce value in the available Nonce records based on a preset amplitude, and re-marking the available Nonce records as available in the Nonce list after the monotonously increasing the Nonce value.
In this embodiment, the client is a multi-threaded client, and the number of Nonce records in the Nonce list indicates the transaction concurrency capability of the user account.
In this embodiment, the Nonce record further includes an index identification of the Nonce record.
FIG. 8 is a block diagram of another blockchain-based transaction processing device shown in an exemplary embodiment of the present description.
Referring to fig. 8, the blockchain-based transaction processing device 80 may also be applied to the electronic device shown in fig. 6, and includes a receiving module 801, a second determining module 802, and an executing module 803.
A receiving module 801, configured to receive a transaction initiated by a user through a user account and sent by a client, where the transaction is added with an available Nonce record obtained from a Nonce list corresponding to the user account and maintained in the blockchain, where the Nonce list includes a plurality of Nonce records;
a matching module 802 that matches available Nonce records in the received transaction with Nonce records in a Nonce list corresponding to the user account maintained in the blockchain;
an execution module 803 accepts the transaction if the available Nonce record matches any target Nonce record in the Nonce list, and concurrently executes a plurality of transactions having the same group identification in the accepted transactions.
In the embodiment, the grouping identifiers of the multiple groups of transactions are the same in grouping identifiers of the multiple groups of transactions contained in the transactions sent by the client;
The execution module 803 further:
And if the plurality of groups of transactions with the same grouping identifications of the plurality of groups of transactions are contained in the transactions sent by the client, sequentially executing the plurality of groups of transactions according to the execution sequence indicated by the grouping identifications of the plurality of groups of transactions.
In this embodiment, the execution module 803 further:
Monotonously increasing the Nonce value of any target Nonce record in the Nonce list based on a preset amplitude if the available Nonce record matches any target Nonce record in the Nonce list, and
And returning a notification message that the transaction is accepted to the client.
In this embodiment, the Nonce record further includes an index identification of the Nonce record.
The implementation process of the functions and roles of each module in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules illustrated as separate components may or may not be physically separate, and the components shown as modules may or may not be physical, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The system, apparatus, module or module set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having some function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
Corresponding to the method embodiment described above, the present specification also provides an embodiment of an electronic device. The electronic device includes a processor and a memory for storing machine executable instructions, where the processor and the memory are typically interconnected by an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing:
The method comprises the steps of respectively acquiring available Nonce records with the same grouping identifier for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently from a Nonce list corresponding to the user account and maintained in a blockchain, wherein the Nonce list comprises a plurality of Nonce records;
adding the obtained available Nonce records to the plurality of transactions respectively;
Issuing the multiple transactions to the blockchain, so that node equipment in the blockchain can match available Nonce records in the transactions issued by the client with Nonce records in the Nonce list, accept the transactions when the available Nonce records are matched with any target Nonce record in the Nonce list, and concurrently execute multiple transactions with the same grouping identification in the accepted transactions.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing:
if a plurality of groups of transactions which are required to be executed concurrently exist in the transactions initiated by the user through the user account, determining the execution sequence of the plurality of groups of transactions;
And respectively acquiring available Nonce records with the same grouping identifiers for the multiple groups of transactions from the Nonce list, wherein the grouping identifiers indicate the execution sequence of the multiple groups of transactions.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing:
Before available Nonce records with the same grouping identifier are respectively obtained from the Nonce list for a plurality of transactions which are initiated by a user through a user account and need to be executed concurrently, responding to an initialization instruction aiming at the client, obtaining the Nonce list maintained in the blockchain, and maintaining the obtained Nonce list locally at the client;
The available Nonce records with the same grouping identifier are respectively obtained from the Nonce list locally maintained by the client for a plurality of transactions which are initiated by a user through a user account and need to be concurrently executed
In this embodiment, the Nonce record in the Nonce list maintained locally by the client is marked as available by default;
By reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing, the processor is caused to:
and respectively acquiring available Nonce records with the same grouping identifier from the Nonce list locally maintained by the client, and marking the available Nonce records as unavailable in the Nonce list after the available Nonce records with the same grouping identifier are respectively acquired for a plurality of transactions which are initiated by a user through a user account and need to be concurrently executed.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing:
Determining whether a notification message returned by the node equipment is received, wherein the notification message is accepted by the transaction;
And if so, monotonously increasing the Nonce value in the available Nonce records based on a preset amplitude, and re-marking the available Nonce records as available in the Nonce list after the monotonously increasing the Nonce value.
Corresponding to the above method embodiments, the present specification also provides another embodiment of the electronic device. The electronic device includes a processor and a memory for storing machine executable instructions, where the processor and the memory are typically interconnected by an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing:
Receiving a transaction initiated by a user through a user account sent by a client, wherein the transaction is added with available Nonce records obtained from a Nonce list corresponding to the user account, which is maintained in the blockchain, wherein the Nonce list comprises a plurality of Nonce records;
Matching available Nonce records in the received transaction with Nonce records in a Nonce list corresponding to the user account maintained in the blockchain;
If the available Nonce record is matched with any target Nonce record in the Nonce list, accepting the transaction; and concurrently executing multiple transactions with the same group identification in the accepted transactions.
In the embodiment, the grouping identifiers of the multiple groups of transactions are the same in grouping identifiers of the multiple groups of transactions contained in the transactions sent by the client;
By reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing, the processor is caused to:
And if the plurality of groups of transactions with the same grouping identifications of the plurality of groups of transactions are contained in the transactions sent by the client, sequentially executing the plurality of groups of transactions according to the execution sequence indicated by the grouping identifications of the plurality of groups of transactions.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory corresponding to control logic for blockchain-based transaction processing:
Monotonously increasing the Nonce value of any target Nonce record in the Nonce list based on a preset amplitude if the available Nonce record matches any target Nonce record in the Nonce list, and
And returning a notification message that the transaction is accepted to the client.
Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This specification is intended to cover any variations, uses, or adaptations of the specification following, in general, the principles of the specification and including such departures from the present disclosure as come within known or customary practice within the art to which the specification pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.
It is to be understood that the present description is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.
The foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.