WO2020119298A1

WO2020119298A1 - Event processing method and apparatus based on blockchain, and electronic device

Info

Publication number: WO2020119298A1
Application number: PCT/CN2019/113960
Authority: WO
Inventors: 黄章杰
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2018-12-14
Filing date: 2019-10-29
Publication date: 2020-06-18
Also published as: CN110033363A; TWI729518B; CN110033363B; TW202025035A

Abstract

Disclosed are an event processing method and apparatus based on a blockchain, and an electronic device. When applied to a participant, the method comprises: generating corresponding alternative sub-transactions according to an event in which the participant participates so that several alternative sub-transactions cluster into a collected transaction, wherein the alternative sub-transactions are configured with corresponding state variations for enabling a corresponding numerical value change to occur to a state parameter of the participant on the basis of the state variations, and the value of the state parameter and the state variations are respectively calculated based on a homomorphic encryption algorithm or a homomorphic commitment algorithm (102); with regard to a plurality of adjacent alternative sub-transactions, events corresponding thereto all being used to decrease the value of the state parameter, in the collected transaction, generating uniform certification information to certify that the value of the state parameter after being subjected to the plurality of alternative sub-transactions is located in a correct value interval (104); and submitting the collected transaction to a blockchain so that the alternative sub-transactions included in the collected transaction are sequentially processed (106).

Description

Block chain-based event processing method and device, and electronic equipment

Technical field

One or more embodiments of this specification relate to the field of terminal technology, and in particular, to a blockchain-based event processing method and device, and electronic equipment.

Background technique

In the related art, the participants of the event can generate a corresponding blockchain transaction for the event and submit the blockchain transaction to the blockchain so that the blockchain transaction can be executed by the blockchain node. Thus completing the implementation of the incident.

Summary of the invention

In view of this, one or more embodiments of this specification provide a blockchain-based event processing method and device, and electronic equipment.

To achieve the above purpose, one or more embodiments of this specification provide technical solutions as follows:

According to a first aspect of one or more embodiments of this specification, a blockchain-based event processing method is proposed, which is applied to participants, and the method includes:

According to the events in which the participant participates, a corresponding alternative sub-transaction is generated, so that several alternative sub-transactions are aggregated into a collective transaction; wherein, the alternative sub-transaction is set with a corresponding state change amount to use In order to make the state parameters of the participants change correspondingly based on the state change, and the value of the state parameter and the state change are the ciphertext value calculated based on the homomorphic encryption algorithm or A commitment value calculated based on the homomorphic commitment algorithm;

For multiple candidate sub-transactions in which the adjacent and corresponding events in the set transaction are used to reduce the value of the state parameter, unified certification information is generated to prove that the state parameter passes through the multiple backup The value after selecting the child transaction is in the correct value range;

Submit the aggregate transaction to the blockchain so that the alternative sub-transactions included in the aggregate transaction are processed in sequence.

According to a second aspect of one or more embodiments of the present specification, a blockchain-based event processing method is proposed, which is applied to blockchain nodes. The method includes:

Receiving a set transaction submitted by a participant to the blockchain, the set transaction includes several alternative sub-transactions, the alternative sub-transactions correspond to events in which the participant participates; wherein, the alternative sub-transaction is set A corresponding state change amount is set for the state parameter of the participant to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount are based on the same The ciphertext value calculated by the homomorphic encryption algorithm or the promise value calculated based on the homomorphic commitment algorithm;

Acquiring unified certification information in the collective transaction, the unified certification information corresponding to multiple candidate sub-transactions that are adjacent and corresponding events in the collective transaction are used to reduce the value of the state parameter, Verify whether the value of the state parameter after passing through the plurality of candidate sub-transactions is in the correct value interval;

According to the verification result, a processing method for the multiple candidate sub-transactions is determined.

According to a third aspect of one or more embodiments of this specification, a blockchain-based event processing device is proposed, which is applied to participants and includes:

The first generating unit generates corresponding alternative sub-transactions according to the events in which the participant participates, so that several alternative sub-transactions are aggregated into a collective transaction; wherein, the alternative sub-transactions are set with corresponding states The amount of change is used to make the state parameter of the participant change correspondingly based on the amount of state change, and the value of the state parameter and the amount of state change are calculated based on a homomorphic encryption algorithm, respectively The cipher text value or the promise value calculated based on the homomorphic promise algorithm;

The second generating unit generates unified proof information for multiple candidate sub-transactions that are adjacent and corresponding events in the set transaction to reduce the value of the state parameter, to prove that the state parameter is passing The value after the multiple candidate sub-transactions is in the correct value interval;

The submission unit submits the aggregate transaction to the blockchain, so that the candidate sub-transactions included in the aggregate transaction are processed in sequence.

According to a fourth aspect of one or more embodiments of this specification, a blockchain-based event processing device is proposed, which is applied to a blockchain node. The device includes:

The receiving unit receives a collective transaction submitted by a participant to the blockchain, and the collective transaction includes several alternative sub-transactions, the alternative sub-transactions correspond to events in which the participant participates; wherein, the alternative The sub-transaction is set with a corresponding state change amount for the participant's state parameter to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount are It is the ciphertext value calculated based on the homomorphic encryption algorithm or the promised value calculated based on the homomorphic commitment algorithm;

The first obtaining unit obtains unified certification information in the collective transaction, the unified certification information corresponding to multiple adjacent and corresponding events in the collective transaction are used to reduce the multiple values of the state parameter Select a sub-transaction to verify whether the value of the status parameter after the multiple candidate sub-transactions is in the correct value interval;

The determining unit determines the processing method for the multiple candidate sub-transactions according to the verification result.

According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, including:

processor;

Memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method described in the first aspect above.

According to a sixth aspect of one or more embodiments of this specification, an electronic device is provided, including:

processor;

Memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method described in the second aspect above.

BRIEF DESCRIPTION

FIG. 1 is a flowchart of a blockchain-based event processing method provided by an exemplary embodiment.

FIG. 2 is a flowchart of another blockchain-based event processing method provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of a scenario of cross-border remittance provided by an exemplary embodiment.

FIG. 4 is a schematic diagram of interaction in a cross-border remittance process according to an exemplary embodiment.

FIG. 5 is a schematic diagram of content of a blockchain transaction provided by an exemplary embodiment.

FIG. 6 is a schematic diagram of a statistical trigger situation provided by an exemplary embodiment.

7 is a schematic structural diagram of an apparatus provided by an exemplary embodiment.

FIG. 8 is a block diagram of a blockchain-based event processing device provided by an exemplary embodiment.

FIG. 9 is a schematic structural diagram of another device provided by an exemplary embodiment.

FIG. 10 is a block diagram of another blockchain-based event processing apparatus provided by an exemplary embodiment.

detailed description

Exemplary embodiments will be described in detail here, examples of which are shown in the drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, the single step described in this specification may be decomposed into multiple steps for description in other embodiments; and the multiple steps described in this specification may also be combined into a single step in other embodiments. description.

FIG. 1 is a flowchart of a blockchain-based event processing method provided by an exemplary embodiment. As shown in Fig. 1, this method is applied to participants and may include the following steps:

Step 102: Generate a corresponding alternative sub-transaction according to the event that the participant participates, so that several alternative sub-transactions are aggregated into a collective transaction; wherein, the alternative sub-transaction is set with a corresponding state change amount , So that the state parameter of the participant changes correspondingly based on the state change, and the value of the state parameter and the state change are the secrets calculated based on the homomorphic encryption algorithm, respectively. The text value or the promise value calculated based on the homomorphic promise algorithm.

In an embodiment, the events in this specification may include any type and cover any scenario, such as voting, signing agreements, traffic distribution, transfers, cross-border remittance, etc. This specification does not limit this. Taking voting as an example, the descriptive information may include information such as voting reasons and voting options, and the trigger information submitted in the blockchain of each participating direction may include the selection result of the voting options, thereby triggering the completion of the voting operation.

In an embodiment, there may be multiple participants in the event, and each participant corresponds to a participant. The participant may be an individual, an enterprise, an organization, etc. This specification does not limit this. The participating object has a corresponding digital identity, so that the electronic device carrying the digital identity is equivalent to being configured as a participant corresponding to the participating object.

In an embodiment, the candidate sub-transaction contains description information of the event, and the description information is used to describe the situation of the related event, so that when the candidate sub-transaction is processed, the corresponding event can be implemented according to the description information. For example, the description information can characterize the execution logic of related events, the involved parties, the way to change the state parameters of the parties (such as increasing or decreasing the value of the state parameters), the amount of state changes, etc. This is restricted. In fact, the relevant content of the event can be communicated in advance by any participant in any way, and then any of the participants can draft the description information of the event, so that other participants of the event can respond to the View and confirm the content of the description information; of course, any one of the participants can also determine other participants of the event and other content in the description information without prior communication. This manual does not limit this .

In an embodiment, the description information of the event may be generated by any participant of the event and added as an alternative sub-transaction in the waiting queue maintained by the any participant. And, the any participant also shares the generated description information to other participants, so that the other participants can confirm the description information.

In an embodiment, any participant can send the description information to other participants of the event through an off-chain channel. Sending the description information to other participants in the event through the off-chain channel can achieve the efficient transmission of the description information. Among them, the off-chain channel may be an encrypted channel or other form of secure channel established between the parties to the event to avoid information leakage.

In an embodiment, any participant can submit a transaction to the blockchain and include the above description information in the transaction, so that the transaction can be sent to all the blockchain after consensus Blockchain node; and each participant of the event can be configured as a blockchain node in the blockchain, or each participant can have a corresponding blockchain node in the blockchain, so that each participant The party can obtain the above transaction and the description information it contains through the blockchain ledger maintained by itself or the corresponding blockchain node (the blockchain ledger contains the entire transaction data of the blockchain), so that the above description information is Synchronize to other parties in the event.

In an embodiment, when any participant generates description information, the amount of state change in the description information may be a ciphertext value or a commitment value. For example, when the plaintext value of the state change is t1, if the Pedersen commitment mechanism is adopted, the corresponding ciphertext commitment T1 can be generated according to the plaintext value t1 and the random number r1, and the description information can include the T1, t1, and r1, so that The other participants of the event can verify the correspondence between the ciphertext commitment T1 and the plaintext value t1 and the random number r1. Among them, the description information can encrypt and protect the plain text value t1 and the random number r1. For example, when the description information needs to be sent to the participant X, the identity public key corresponding to the digital identity of the participant X can be used to encrypt The encrypted Enc_X(t1) and Enc_X(r1) are added to the description information, so only the participant X can decrypt Enc_X(t1) and Enc_X(r1) through their own identity private key to obtain the above plaintext values t1 and The random number r1 significantly improves data security. Of course, in addition to the public key encryption method, any other encryption method in the related art, such as a digital envelope, can also be used, which is not limited in this specification.

In an embodiment, when there are multiple other parties, the description information may respectively include encrypted data corresponding to each other party. For example, when other parameter parties include participant X and participant Y, the plaintext value t1 and random number r1 can be encrypted according to participant X's identity public key to obtain Enc_X(t1), Enc_X(r1), and according to the participant The identity public key of Y encrypts the plaintext value t1 and the random number r1 to obtain Enc_Y(t1), Enc_Y(r1), and adds Enc_X(t1), Enc_X(r1), Enc_Y(t1) and Enc_Y(r1) to In the description information, any one of the participants only needs to prepare one piece of description information and send it to each other participant separately, without preparing different description information for each other participant. Of course, any one of the participants can prepare different description information for each other participant. For example, the description information sent to participant X includes Enc_X(t1) and Enc_X(r1), and is sent to participant Y The description information contains Enc_Y(t1) and Enc_Y(r1), which is not limited in this manual.

In an embodiment, the participant may maintain a waiting queue, which contains candidate sub-transactions corresponding to each event in which the participant participates; and by selecting several candidate sub-transactions from the waiting queue, Generate the corresponding aggregate transaction. The aggregate transaction may contain multiple alternative sub-transactions, each of which corresponds to an event in which the above-mentioned parties participate, so that after the aggregate transaction is submitted to the blockchain, the multiple alternative sub-transactions included All transactions can be processed in the blockchain, so that multiple events corresponding to these alternative sub-transactions are implemented. It can be seen that by including multiple alternative sub-transactions in the set transaction, these alternative sub-transactions are submitted to the blockchain in batches, which can reduce the number of transactions submitted to the blockchain without generating for each alternative sub-transaction A blockchain transaction helps reduce resource consumption and improve processing efficiency.

In an embodiment, when the candidate sub-transactions in the waiting queue reach a preset number, the candidate sub-transactions already existing in the waiting queue (ie, a preset number of candidate sub-transactions) may be selected to: Generate the corresponding aggregate transaction. In another embodiment, the alternative sub-transactions that already exist in the waiting queue may be selected periodically according to a preset duration to generate a corresponding set transaction; of course, the capacity of each set transaction may have a maximum limit, such that There is a corresponding maximum value for the number of candidate sub-transactions selected in the same period, and the excess can be postponed to the next period for selection. Of course, alternative sub-transactions can also be selected through other preset rules, which are not limited in this specification.

In an embodiment, the candidate sub-transactions in the waiting queue can be arranged in order according to the time of addition, and each candidate sub-transaction can be selected in sequence from front to back each time, so that the previously generated candidate sub-transactions can be selected preferentially . Of course, the participants can also implement the order-independent selection operation on the alternative sub-transactions in the waiting queue according to the actual needs, such as the urgency of the event, the priority of the event, etc.; or, the waiting queue itself can follow the above-mentioned emergency Sort by degree, priority, etc., so that it can still be regarded as one by one.

In an embodiment, the description information of the event may include a state change amount, and the event may be used to cause the state parameters correspondingly recorded on the blockchain by various parties to change in value according to the state change amount, such as increasing Large values, reduced values, etc. Among them, the corresponding state parameters may also be different according to the type of event or the difference in the scene. For example, the state parameter in the scenario of transfer or cross-border remittance can be the account balance of the participant, and the state parameter in the scenario of traffic distribution can be the participant. This manual does not limit the amount of remaining flow.

Step 104: For multiple candidate sub-transactions that are adjacent and corresponding events in the set transaction are used to reduce the value of the state parameter, generate unified proof information to prove that the state parameter passes through the The value after multiple alternative sub-transactions is in the correct value range.

In an embodiment, by generating the above-mentioned unified certification information, the multiple candidate sub-transactions described above can generate only one unified certification information without having to separately and individually generate corresponding certification information, which helps simplify the certification information and improve Processing efficiency.

In an embodiment, "for multiple candidate sub-transactions that are used to reduce the value of the state parameter for adjacent and corresponding events in the set transaction" does not necessarily mean that only The multiple alternative sub-transactions generate unified certification information. If there are other alternative sub-transactions arranged before the multiple alternative sub-transactions in the collective transaction, the other alternative sub-transactions will also affect the status parameters. The value has an impact, so the unified certification information is also related to the other alternative sub-transactions. In other words, if there are other alternative sub-transactions arranged before the multiple alternative sub-transactions in the collective transaction, then the state parameter needs to experience the other alternative sub-exchanges before undergoing the multiple alternative sub-transactions The value of is changed, and the unified proof information is used to prove that the value of the state parameter after the joint action of the other candidate sub-transaction and the multiple candidate sub-transactions is in the correct value interval.

For example, when the alternative sub-transactions included in the set transaction are sequentially "decrease, decrement, and add" ("minus" represents the alternative sub-transaction used to decrease the value of the state parameter, "plus" represents the increase in the state parameter Value of alternative sub-transactions), you can generate unified proof information for the first three consecutive alternative sub-transactions. At this time, because there are no other alternative sub-transactions before these three alternative sub-transactions, the status parameter Only by the effect of these three alternative sub-transactions, the value change occurs, and the unified proof information is used to prove that the value after the change is in the correct numerical range.

For another example, when the alternative sub-transactions included in the collective transaction are "addition, subtraction, addition, subtraction, subtraction, and addition", unified proof information can be generated for the three consecutive alternative sub-transactions of the fifth, sixth, and seventh, At this time, since there are four other alternative sub-transactions of the first, second, third, and fourth before these three alternative sub-transactions, the state parameter is not only affected by three consecutive "subtracted" alternative sub-transactions. The effect is also affected by four other alternative sub-transactions. The unified proof information is used to prove that the state parameter has a value change under the action of the seven alternative sub-transactions, and the changed value is in the correct numerical range. .

In an embodiment, the above “corresponding events are all used to reduce the value of the state parameter of multiple alternative sub-transactions” may be just adjacent to each other, and no special sorting process is implemented, which makes In some cases, multiple eligible alternative sub-transactions may not be set adjacent to each other, resulting in the inability to use this manual to generate unified certification information. It may also prevent multiple eligible alternative sub-transactions from being arranged completely continuously. Split into multiple groups, then each group can still generate unified certification information separately, but it is impossible to generate a unified certification information for multiple eligible sub-transactions.

In an embodiment, when several candidate sub-transactions are selected for aggregation into the set transaction, the manner in which the value of the state parameter is adjusted by the event corresponding to each selected candidate sub-transaction can be identified ; When the events corresponding to at least two alternative sub-transactions are used to reduce the value of the state parameter, the at least two alternative sub-transactions may be arranged adjacently in the set transaction. In other words, when aggregated to form a set of transactions, you can actively sort each alternative sub-transaction, and try to arrange the alternative sub-transactions used to reduce the value of the state parameter adjacently, so that these alternative sub-transactions can be Only generating one piece of unified certification information can minimize the quantity of certification information.

In an embodiment, when a ciphertext value or a commitment value is used, for multiple alternative sub-transactions that individually exist in the set transaction and the corresponding events are used to reduce the value of the state parameter, the participant may Proof information is separately generated for it to prove that the value of the state parameter after the multiple alternative sub-transactions is in the correct value interval.

In an embodiment, the value of the state parameter corresponding to each participant and the state change amount are respectively a ciphertext value calculated based on a homomorphic encryption algorithm or a promise value calculated based on a homomorphic commitment algorithm. For the homomorphic encryption algorithm, any type of homomorphic encryption algorithm can be used, as long as the homomorphic encryption algorithm can satisfy the addition homomorphism, so that even in the ciphertext state, the value of the state parameter can still be increased or decreased The amount of change in the state; for this homomorphic encryption algorithm is an additive homomorphic encryption algorithm or a fully homomorphic encryption algorithm, this specification does not limit this. For the homomorphic commitment algorithm, when using the Pedersen commitment mechanism in the related art, a random number can be determined for the unencrypted data, and the corresponding commitment value can be calculated based on the random number and the unencrypted data.

In an embodiment, when the value of the state parameter and the amount of state change are the ciphertext value or the promised value, the participant needs to provide relevant proof information so that the blockchain node can determine the transaction Legal validity. For example, when an event is used to make the value of a state parameter corresponding to a participant decrease according to the state change, that is, the purpose of the transaction is to make the value of the state parameter of the participant decrease the amount of state change, such as The above unified certification information is used to prove that the value of the participant's state parameter is sufficient to implement multiple adjacent "reduced" types of alternative sub-transactions in the above set transaction (that is, the value of the state parameter is not less than the phase The sum of the corresponding state changes of the neighboring multiple "reduced" types of candidate sub-exchanges).

For example, the set transaction may include a pre-change state value and a post-change state value respectively corresponding to each candidate sub-transaction to match the state change amount set in each candidate sub-transaction, so that each backup After the sub-transaction is processed, the state parameter of the participant changes from the pre-change state value to the post-change state value via the state change amount; wherein, the pre-change state value and the post-change state value The state value is a ciphertext value calculated based on the homomorphic encryption algorithm or a promise value calculated based on the homomorphic commitment algorithm, respectively. Then, the unified proof information can be used to prove that in the above-mentioned adjacent multiple “decrease” type alternative sub-transactions, the state value of the last alternative sub-transaction after the change is not less than 0.

In an embodiment, when a ciphertext value or a commitment value is used, for each candidate sub-transaction in the set transaction, regardless of whether it is used to increase or decrease the value of the state parameter, corresponding independent proof information is generated The independent proof information is used to prove that the state change amount set in the corresponding candidate sub-transaction is within the correct value interval. For example, the independent proof information can be used to indicate that the corresponding state change is in the correct numerical range, such as [0,264).

In an embodiment, the Range Proof technology in related technologies, such as the Bulletproofs scheme or the Borromean ring signature scheme, can be used to generate the above-mentioned certification information, which is not limited in this specification.

Step 106: Submit the aggregate transaction to the blockchain, so that the candidate sub-transactions included in the aggregate transaction are processed in sequence.

In an embodiment, the participants may add numbers to each merged transaction in the order of generation, so that each merged transaction is processed sequentially in the blockchain according to the size of the corresponding number. In other words, after receiving the merger transaction submitted by the participant, the blockchain transaction needs to read the number included in the merger exchange; if the number is continuous with the number of the previously processed merger transaction, for example, the latest processed merger transaction number is 99, If the number of the merged transaction currently received is 100, the merged transaction with the number of 100 can be processed; if the numbers are not continuous, for example, the number of the latest merged transaction processed is 99, the current received merged transaction If the number is 101, the blockchain node needs to wait and give priority to the merge transaction with the number 100 before it can process the merge transaction with the number 101. After each transaction is executed, the state parameters of the participant may change, and the execution of subsequent transactions depends on the value of the state parameters after the execution of the previous transaction, so it is necessary to ensure that each merged transaction is The size is processed sequentially so that each merged transaction can be executed correctly.

In an embodiment, the candidate sub-transaction corresponding to the event includes the single-party trigger information of the participant on the event; wherein, when all participants of the event submit to the blockchain When the unilateral trigger information of the event is all verified, the alternative sub-transaction corresponding to the event is triggered to execute in the blockchain. The unilateral trigger information indicates that the corresponding participant confirms the description information of the event, hoping to trigger the execution of the event; and each participant of the event needs to submit the unilateral trigger information to the blockchain separately, so that the blockchain node is based on all participants Unilateral trigger information submitted separately to determine whether the event indicated by the corresponding alternative sub-exchange should be executed. For example, after any participant of the event generates description information and provides it to other participants, not only does any participant need to add corresponding alternative sub-transactions to the waiting queue maintained by itself, each other participant After being confirmed, the corresponding alternative sub-transactions are also added to the waiting queue maintained by themselves; and, each participant generates a set transaction based on the waiting queue maintained by itself, so that by submitting the set transaction to the blockchain, the The above unilateral trigger information is submitted to the blockchain for verification by the blockchain nodes. The unilateral trigger information can contain description information and the signature generated by the corresponding participant on the description information; the signature belongs to the confirmation information provided by the corresponding participant, and if the cipher text value or the promise value is used, the confirmation information also contains the certification information, which is described above It has been described in detail. By submitting the single-party trigger information to the blockchain separately from each participant, instead of submitting the multi-party trigger information to a certain party, not only can the processing pressure be shared, and the processing pressure of a single participant can be prevented from being too large, but also to each participant According to their own actual situation (such as processing pressure, priority management, etc.), each event involved is selectively processed or even processed in batches.

Corresponding to the embodiment shown in FIG. 1, FIG. 2 is a flowchart of another blockchain-based event processing method provided by an exemplary embodiment. As shown in Figure 2, this method is applied to blockchain nodes and can include the following steps:

Step 202: Receive a collective transaction submitted by a participant to the blockchain, and the collective transaction includes several alternative sub-transactions, the alternative sub-transactions correspond to events in which the participant participates; wherein, the alternative The sub-transaction is set with a corresponding state change amount for the participant's state parameter to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount are It is the ciphertext value calculated based on the homomorphic encryption algorithm or the commitment value calculated based on the homomorphic commitment algorithm.

In an embodiment, the candidate sub-transactions in the waiting queue can be arranged in order according to the time of addition, and each candidate sub-transaction can be selected in sequence from front to back each time, so that the previously generated candidate sub-transactions can be selected preferentially . Of course, the participants can also implement the order-independent selection operation on the alternative sub-transactions in the waiting queue according to the actual needs, such as the urgency of the event and the priority of the event; or, the waiting queue itself can be Sort by degree, priority, etc., so that it can still be regarded as one by one.

Step 204: Obtain unified certification information in the collective transaction, and the unified certification information corresponds to multiple alternatives that are adjacent and corresponding events in the collective transaction are used to reduce the value of the state parameter Transaction to verify whether the value of the status parameter after the multiple candidate sub-transactions is in the correct value interval.

In an embodiment, the blockchain node may obtain independent proof information corresponding to each candidate sub-transaction in the set transaction to verify whether the state change amount set in the corresponding candidate sub-transaction is in the correct state Numerical interval; wherein, when the verification result of the unified proof information by the blockchain node is verified, and the independent proof information corresponding to any of the multiple alternative sub-transactions passes the verification, the blockchain The node may trigger execution of any of the alternative sub-transactions.

In an embodiment, the blockchain node may acquire the event corresponding to any of the alternative sub-transactions in the collective transaction when the value of the state parameter is used to increase the value of the state parameter. Independent certification information of any alternative sub-transaction; wherein, when the independent certification information corresponding to the alternative sub-transaction passes verification, the blockchain node may trigger execution of the alternative sub-transaction.

Step 206: Determine a processing method for the multiple candidate sub-transactions according to the verification result.

For ease of understanding, the following uses the cross-border remittance scenario as an example to describe the technical solutions of one or more embodiments of this specification. Based on the technical scheme of this specification, each institution can separately merge several remittance transactions (equivalent to the above-mentioned alternative sub-transactions) in which it participates into a blockchain transaction (equivalent to the above-mentioned collective transaction), and through the The blockchain submits the blockchain transaction to realize the batch submission and processing of several remittance transactions. The following will first describe the process of generating and processing a single remittance transaction, and then expand to the batch processing of multiple remittance transactions.

FIG. 3 is a schematic diagram of a scenario of cross-border remittance provided by an exemplary embodiment. As shown in FIG. 3, it is assumed that the user 1 transfers the blockchain to the user 2; among them, the "user" in this specification can be represented as a logged-in user account, and the user account can actually belong to an individual or organization. The manual does not limit this. Assuming that user 1 opens a customer funds account at institution 1 in country A 1, and user 2 opens a customer fund account 2 at institution 4 in country B, this specification can not directly implement cross-border remittances between institution 1 and institution 4. In the case of, through the assistance of

institutions

2 and 3, the cross-border remittance operation is implemented on the blockchain.

Institution 1, institution 2, institution 3 and institution 4 have corresponding equipment 1, equipment 2, equipment 3 and equipment 4, respectively, and by running the client program of the blockchain on equipment 1 to 4, equipment 1 to 4 are Configured as a corresponding blockchain node; accordingly, institutions 1 to 4 can implement operations related to the blockchain through devices 1 to 4. For example, institutions 1 to 4 can submit corresponding blockchain transactions to the blockchain through devices 1 to 4; for another example, devices 1 to 4 respectively maintain full transaction data on the blockchain, that is, blockchain ledger, Institutions 1 to 4 can query and maintain the balance data of each blockchain account accordingly. For example, the blockchain account Y1 corresponding to institution 1 holds 1000 HKD, and the blockchain account Y2 corresponding to institution 2 holds HKD 2,500 and 4,200 Euros, the Blockchain account Y3 corresponding to Institution 3 holds 3,000 Euros and $2,000, and the Blockchain account Y4 corresponding to Institution 4 holds $1,500.

For privacy protection and other considerations, the balance data of the blockchain accounts Y1 to Y4 are often not maintained in the form of plain text, but the corresponding cipher text data is used. Taking the blockchain account Y1 as an example, it can be recorded as (currency_1, PC(a, r_a), Enc_A(a), Enc_A(r_a)) in the blockchain ledger, where: currency_1 means the currency type is Hong Kong dollar, a It means that the amount of Hong Kong dollar is 1000, r_a is the random number corresponding to a, PC(a, r_a) is the commitment value in the form of ciphertext calculated by Pedersen commitment mechanism for a and r_a, Enc_A(a), Enc_A(r_a) respectively Take values for the ciphertext of a and r_a (for example, you can use the identity public key of organization 1 for encryption, or you can use any other form of encryption algorithm). The blockchain account Y2 can be recorded as (currency_1, PC(b1, r_b1), Enc_B(b1), Enc_B(r_b1)), (currency_2, PC(b2, r_b2), Enc_B(b2), Enc_B(r_b2)) , Where: b1 means the amount of HKD is 2500, r_b1 is the random number corresponding to b1, currency_2 means the currency type is Euro, b2 means the amount of Euro is 4200, and r_b2 is the random number corresponding to b2. Blockchain account Y3 can be recorded as (currency_2, PC(c1, r_c1), Enc_C(c1), Enc_C(r_c1)), (currency_3, PC(c2, r_c2), Enc_C(c2), Enc_C(r_c2)) , Where: c1 indicates that the Hong Kong dollar is 3000, r_c1 is the random number corresponding to c1, currency_3 indicates the currency type is USD, c2 indicates the amount of USD is 2000, and r_c2 is the random number corresponding to c2. The blockchain account Y4 can be recorded as (currency_3, PC(d, r_d), Enc_D(d), Enc_D(r_d)), where d represents the amount of USD 1500 and r_d is the random number corresponding to d.

Based on the remittance scenario shown in FIG. 3, FIG. 4 is a schematic diagram of interaction in a cross-border remittance process according to an exemplary embodiment. As shown in Figure 4, the interactive process of cross-border remittance can include the following steps:

In step 401, the device 1 drafts a remittance transaction tx_i.

In an embodiment, suppose that user 1 wishes to send 500 HKD to user 2. This user 1 can provide the 500 HKD through customer funds account 1 at institution 1, and user 2 can use customer funds account 2 at institution 4 Charge the US dollar calculated at a certain exchange rate.

In an embodiment, the institution 1 may deduct 500 Hong Kong dollars from the customer funds account 1 corresponding to the user 1; and, the institution 1 needs to determine the remittance route between itself and the institution 4, for example, the remittance route in FIG. 4 is “ Institution 1→Institution 2→Institution 3→Institution 4”, so that Institution 1 can transfer 500 HKD to Institution 2, Institution 2 can transfer 56 Euros (equivalent to 500 HKD) to Institution 3, Institution 3 can transfer to Institution 4 64 US dollars (equivalent to 56 euros, 500 Hong Kong dollars), and finally the institution 4 transfers 64 US dollars to the customer funds account 2 corresponding to user 2 to complete the remittance operation. Among them, Institution 1 deducts 500 Hong Kong dollars from customer funds account 1, Institution 4 transfers US$64 to customer funds account 2 is an off-chain operation, and the transfer of funds on the chain is realized between institutions 1 to 4 through the blockchain.

In one embodiment, in the above remittance route “institution 1→institution 2→institution 3→institution 4”, there are two relay parties between organization 1 and organization 4 as organization 3 and organization 4; while in other implementations In the example, the number of relay parties may be one, three, or more than three, and this specification does not limit this.

For the above-mentioned remittance route and the amount of remittance between various institutions, the remittance transaction tx_i drafted by the device 1 may include the following remittance transaction details: the transaction id is tx_i, the address Z1 of the blockchain account Y1, and the blockchain account Y2 Address Z2, blockchain account Y3 address Z3, blockchain account Y4 address Z4, cipher text information related to the transaction amount {(currency_1, PC(t1, r_t1), Enc_B(t1), Enc_B(r_t1) ,Enc_C(t1),Enc_C(r_t1),Enc_D(t1),Enc_D(r_t1)),(currency_2,PC(t2,r_t2),Enc_B(t2),Enc_B(r_t2),Enc_C(t2),Enc_C(r_t2 ),Enc_D(t2),Enc_D(r_t2)),(currency_3,PC(t3,r_t3),Enc_B(t3),Enc_B(r_t3),Enc_C(t3),Enc_C(r_t3),Enc_D(t3),Enc_D( r_t3)), rate1, rate2, time, ...}, prove RP_t1, RP_t2, RP_t3, etc. for the interval of the transaction amount t1, t2, t3.

Among them, the addresses Z1 to Z4 are used to indicate the participants of this remittance event, so that the subsequent transfer and remittance will be made from the blockchain accounts Y1 to Y4 corresponding to the addresses Z1 to Z4.

In (currency_1, PC(t1, r_t1), Enc_B(t1), Enc_B(r_t1), Enc_C(t1), Enc_C(r_t1), Enc_D(t1), Enc_D(r_t1)), t1 means from address Z1 to address The transfer amount of Z2 (such as the above 500 Hong Kong dollars), r_t1 is the random number corresponding to the amount t1, PC(t1, r_t1) is the commitment value calculated based on the amount t1 and the random number r_t1, Enc_B(t1) indicates the institution 2 The ciphertext value of the amount t1 encrypted by the identity public key of the ID, Enc_C(t1) means the ciphertext value of the amount t1 encrypted by the identity public key of the institution 3, and Enc_D(t1) means the identity public key of the institution 4 The ciphertext value after encrypting the amount t1; similarly, Enc_B(r_t1), Enc_C(r_t1), Enc_D(r_t1) are the amounts of t1 encrypted by the identity public keys of institution 2, institution 3, and institution 4, respectively Cipher text value. (currency_2,PC(t2,r_t2),Enc_B(t2),Enc_B(r_t2),Enc_C(t2),Enc_C(r_t2),Enc_D(t2),Enc_D(r_t2)) and (currency_3,PC(t3,r_t3) , Enc_B(t3), Enc_B(r_t3), Enc_C(t3), Enc_C(r_t3), Enc_D(t3), Enc_D(r_t3)) The situation is similar, so I won’t repeat them here. rate1 and rate2 are the exchange rate of currency_1 and currency_2, and the exchange rate of currency_2 and currency_3 respectively. time is the trading moment. And, there may be some other data required for the transaction, which can be referred to the scheme in the related art, which is not listed here one by one.

RP_t1, RP_t2, and RP_t3 are the interval proofs corresponding to the transaction amounts t1, t2, and t3, respectively, to prove that the transaction amounts t1, t2, and t3 are in the correct numerical range, such as 0≤t1<264, 0≤t2<264, 0≤t3<264. Among them, the device 1 can generate the above-mentioned interval proof through the zero-knowledge proof technique in the related art, which is not limited in this specification.

In steps 402a to 402c, device 1 synchronizes the details of the remittance transaction to device 2, device 3, and device 4, respectively.

In an embodiment, the device 1 may sign the details of the remittance transaction through the identity private key of the organization 1, and then send them to the device 2 to the device 4 through an off-chain (or referred to as off-chain) channel to achieve data synchronization.

In an embodiment, device 1 to device 4 respectively run a client program of the blockchain, so that device 1 to device 4 are respectively configured as blockchain nodes in the blockchain; or, device 1 to device 4 are There are corresponding blockchain nodes in the blockchain, and this specification does not limit this. Among them, each blockchain node in the blockchain maintains a unified blockchain ledger, and the blockchain ledger records a full amount of blockchain data. Therefore, device 1 can generate a transaction that contains the remittance transaction details of the above remittance transaction tx_i, and submit the transaction to the blockchain; accordingly, when the transaction passes consensus, it can be sent to the district Each blockchain node in the blockchain is used by each blockchain node to update its maintained blockchain ledger. Therefore, device 1, device 2, device 3, and device 4 can be informed of the above transaction submitted by device 1 through the blockchain ledger maintained by their corresponding blockchain nodes, so as to obtain the above remittance transaction tx_i included in the transaction Details of the remittance transaction.

Of course, the device 1 may also synchronize the remittance transaction data to the device 2 to the device 4 in other ways, which is not limited in this specification.

In step 403a, the device 1 adds the remittance transaction tx_i corresponding to the remittance transaction details to its own local queue 1.

In an embodiment, when the device 1 sends the remittance transaction details through the off-chain channel, the device 1 can directly add the remittance transaction tx_i to the local queue 1; of course, the device 1 can wait for the device 2 to the device 4 to confirm the details of the remittance transaction and After the corresponding confirmation response is returned, the remittance transaction tx_i is added to the local queue 1 to ensure that devices 2 to 4 all participate in the remittance transaction tx_i.

In an embodiment, when the device 1 synchronizes the details of the remittance transaction to the device 2 to the device 4 through the blockchain, the device 1 will also receive the details of the remittance transaction synchronized on the blockchain. Remittance transaction details are verified (for verification process, please refer to step 403b), and after verification, add the remittance transaction tx_i to the local queue 1, or confirm that the remittance transaction details correspond to the remittance transaction tx_i, and the remittance transaction tx_i is determined by the device 1 When drafting and submitting to the blockchain itself, the verification process of the details of the remittance transaction is omitted, and it is directly added to the local queue 1.

In step 403b, after verifying the details of the received remittance transaction, the device 2 adds it to its own local queue 2.

In an embodiment, after receiving the details of the remittance transaction, the device 2 needs to implement a verification operation, including: the device 2 uses its own private key to identify the Enc_B(t1), Enc_B(r_t1), and Enc_B(t2) contained in the details of the remittance transaction. ), Enc_B(r_t2), Enc_B(t3), Enc_B(r_t3) to decrypt, get the corresponding amount t1 and random number r_t1, amount t2 and random number r_t2, amount t3 and random number r_t3, and verify PC(t1, r_t1) = r_t1G + t1H, PC (t2, r_t2) = r_t2G + t2H, PC (t3, r_t3) = whether r_t3G + t3H is established (where G and H are preset system parameters); device 2 verifies currency_1 and currency_2 Whether the exchange rate between rates is rate1, currency_2 and currency_3 is rate2; device 2 verifies that the interval proves that RP_t1, RP_t2, RP_t3 are correct, etc. After determining that the details of the remittance transaction have been verified, the device 2 may add the corresponding remittance transaction tx_i to the local queue 2 maintained by itself, and return a confirmation response to the device 1 to indicate that the corresponding remittance transaction is accepted.

Steps 403c-403d, after verifying the details of the received remittance transaction, the device 3-4 adds it to its own local queue 3-4.

In an embodiment, the operations performed by the device 3 and the device 4 are similar to those of the device 2, and are not repeated here.

So far, the remittance transaction tx_i has been added to the local queues 1 to 4 maintained by devices 1 to 4 respectively. Similarly, when devices 1 to 4 participate in other remittance transactions (not necessarily the remittance transactions that device 1 to device 4 participate in at the same time), the processing method similar to the above remittance transaction tx_i can also be adopted. The remittance transaction is added to the local queue for the transaction aggregation and batch processing in the following steps.

In step 404a, the device 1 aggregates the transaction TX_a according to the remittance transaction in the local queue 1, and submits it to the blockchain after signing.

As mentioned above, similar to the remittance transaction tx_i, the institution 1 can also participate in other remittance transactions. For example, when a user needs to remit money to another user through the institution 1, the device 1 can use a method similar to the above steps , Draft the corresponding remittance transaction, send the details of the remittance transaction to other institutions for verification, and add the corresponding remittance transaction tx_i to the local queue 1. At the same time, institution 1 can also act as a relay party for some remittance transactions (similar to the role of institution 2-3 in the above-mentioned embodiment) or a payee (similar to the role of institution 4 in the above-mentioned embodiment), making the institution 1 The device 1 can receive the remittance transaction details sent by the remittance party (similar to the role of the institution 1 in the above embodiment) of these remittance transactions, and add the corresponding remittance transaction to the local queue 1 after the verification is passed.

Therefore, the local queue 1 maintained by the device 1 contains many remittance transactions in which the institution 1 participates. The device 1 can select one or more remittance transactions from the local queue 1 each time according to the predefined transaction selection rules, and aggregate the selected remittance transactions to generate a blockchain transaction.

For example, FIG. 5 is a schematic diagram of content of a blockchain transaction provided by an exemplary embodiment. As shown in Figure 5, assume that device 1 selects 6 remittance transactions and aggregates them into a blockchain transaction, such as remittance transactions tx_i-3, tx_i-2, tx_i-1, tx_i, tx_i+1, tx_i+2 are aggregated For the blockchain transaction TX_a, the device 1 needs to generate corresponding proof information for each remittance transaction.

First, for each remittance transaction in the blockchain transaction TX_a, the blockchain transaction TX_a needs to contain proof information for the transaction amount of each remittance transaction, for example, the proof information corresponding to the remittance transaction tx_i-3 is RP_i-3 The proof information corresponding to the remittance transaction tx_i-2 is RP_i-2, the proof information corresponding to the remittance transaction tx_i-1 is RP_i-1, the proof information corresponding to the remittance transaction tx_i is RP_i, and the proof information corresponding to the remittance transaction tx_i+1 is RP_i +1, the proof information corresponding to the remittance transaction tx_i+2 is RP_i+2.

Taking the proof information RP_i corresponding to the remittance transaction tx_i as an example, it is equivalent to the above-mentioned interval proofs RP_t1, RP_t2, and RP_t3, which are respectively used to prove that the transaction amount t1, t2, and t3 of the remittance transaction tx_i are in the correct value interval. Similarly, for other remittance transactions drafted by other than device 1, the drafting party of the remittance transaction can generate the certification information of the transaction amount without the need for device 1; of course, even if the remittance transaction is not drafted by device 1, it can still be The device 1 generates certification information for the corresponding transaction amount, which is not limited in this specification.

Then, for the remittance transaction of institution 1 as a remittance or relay party, that is, the remittance transaction that causes the balance of the blockchain account Y1 of the institution 1 to decrease, the device 1 also needs to generate a sufficient balance of the blockchain account Y1, not less than the transaction The amount of proof information. At this time, the device 1 needs to select all the remittance transactions that will reduce the balance of the blockchain account Y1 from the above six remittance transactions, and make the selected remittance transactions be arranged next to each other in the blockchain transaction TX_a ; For example, when the remittance transaction tx_i-3, tx_i-2 and tx_i-1 will cause the balance of the blockchain account Y1 to increase, while the remittance transaction tx_i, tx_i+1, tx_i+2 will cause the balance of the blockchain account Y1 to decrease At this time, device 1 can arrange remittance transactions tx_i-3, tx_i-2 and tx_i-1 adjacently, and generate unified proof information RP_(i～i+2) for these three remittance transactions to prove the blockchain account Y1 The balance (referring to the balance after the value change caused by the remittance transaction tx_i, tx_i+1, tx_i+2) is sufficient to complete the remittance transaction tx_i, tx_i+1 and tx_i+2, without the need for the remittance transaction tx_i, tx_i+1 And tx_i+2 generate separate interval proofs.

In an embodiment, considering that the remittance transactions submitted by the device 1 may not all be successfully executed, and the remittance transaction submitted earlier may affect the balance of the blockchain account Y1, thereby affecting the subsequent remittance transaction, therefore, in the generation When unifying the proof information RP_(i～i+2), the influence of the previously submitted blockchain transaction should be considered. For example, when institution 1 acts as a remittance or relay party in several remittance transactions included in the blockchain transaction, institution 1 will subtract the corresponding transfer amount (remittance) from the account balance of its corresponding blockchain account Y1 The party only transfers out the funds; the relaying party can receive the transferred funds and need to transfer out the funds, which is described for the operation of the transferred funds), and continue to participate in the subsequent remittance transactions based on the updated remittance amount. After the blockchain transaction is submitted to the blockchain, if institution 1 as a remittance or relay party successfully executes a remittance transaction, institution 1 does not need to adjust the blockchain account Y1; if institution 1 acts as a remittance party or If a remittance transaction of the successor is not successfully executed, the institution 1 needs to adjust the balance of the account of the blockchain account Y1. When the above-mentioned blockchain transaction includes institution 1 as the payee or the relay party (the payee only transfers funds; the relay party can receive the transferred funds and need to transfer the funds, here is for the transferred funds During the remittance transaction, if the remittance transaction is successfully executed, the institution 1 needs to add the corresponding funds to the blockchain account Y1 to realize the collection. If the remittance transaction is not successfully executed, the institution 1 does not need to adjust the blockchain account Y1. Correspondingly, when the blockchain node receives and processes the blockchain transaction submitted by the device 1, it can mark the status of each remittance transaction according to whether the remittance transaction included in the blockchain exchange can be successfully executed, such as the transaction is successful Status, failure status, timeout status, etc.

Therefore, when the device 1 aggregates and generates the blockchain transaction TX_a, it does not directly generate the unified certification information RP_(i～i+2) through the value of the balance of the blockchain account Y1, but needs to determine the previous submission of the device 1 The remittance transactions that may cause changes in the amount of blockchain transactions include: the increase in the amount of money (receipt) generated when the remittance transaction of institution 1 as a relay or payee is marked as successful, and the institution 1 as a sender or The amount of money generated when the remittance transaction of the relay party is marked as a failed state or a time-out state is increased (the deducted transfer amount is rolled back), etc. And, the device 1 further takes the value of the balance of the blockchain account Y1 (the transfer amount of the previously submitted remittance transaction has been deducted, the unreceived payment) and the actual value change value of the above remittance transaction that may cause the amount change to the block The balance value of the chain account Y1 is updated, and then unified certification information RP_(i~i+2) is generated according to the updated balance value.

In addition, when generating each blockchain transaction, the device 1 also adds a corresponding sequence number seq for each blockchain transaction according to the generation sequence of the blockchain transaction. For example, when device 1 generates blockchain transactions TX_1, TX_2, and TX_3, the seq value of blockchain transaction TX_1 is 99, the seq value of blockchain transaction TX_2 is 100, and the seq value of blockchain transaction TX_3 is A value of 101 indicates that the blockchain transaction TX_1 was generated earlier than the blockchain transaction TX_2, and the blockchain transaction TX_2 was generated earlier than the blockchain transaction TX_3. Correspondingly, after receiving each blockchain transaction submitted by device 1, the blockchain node will process each blockchain transaction in the order of seq from small to large, such as first processing the blockchain transaction TX_1, Then process the blockchain transaction TX_2, and then process the blockchain transaction TX_3.

In steps 404b-d, devices 2 to 4 aggregate the transactions TX_b, TX_c, and TX_d according to the remittance transactions in the local queues 2 to 4, and submit them to the blockchain after signing.

In an embodiment, similar to the device 1, the device 2 can select one or more remittance transactions from the local queue 2 to aggregate and generate corresponding blockchain transactions. Assume that device 2 includes the above-mentioned remittance transaction tx_i in a selected remittance transaction, and accordingly generates a corresponding blockchain transaction TX_b; where the remittance transaction that causes the balance of the institution 2’s blockchain account Y2 to decrease is in TX_b Arranged adjacent to each other to generate corresponding unified certification information.

In an embodiment, similar to the device 1, the device 3 may select one or more remittance transactions from the local queue 3 to aggregate and generate corresponding blockchain transactions. Assume that device 3 includes the above-mentioned remittance transaction tx_i in a selected remittance transaction, and accordingly generates the corresponding blockchain transaction TX_c; where the remittance transaction that causes the balance of the institution’s 3 blockchain account Y3 to decrease is in TX_c Arranged adjacent to each other to generate corresponding unified certification information.

In an embodiment, similar to the device 1, the device 4 may select one or more remittance transactions from the local queue 4 to aggregate and generate corresponding blockchain transactions. Assume that device 4 includes the above-mentioned remittance transaction tx_i in a certain selected remittance transaction, and accordingly generates the corresponding blockchain transaction TX_d; where the remittance transaction that causes the balance of the blockchain account Y4 of institution 4 to decrease is in TX_d Arranged adjacent to each other to generate corresponding unified certification information.

It should be pointed out that device 1 to device 4 can choose to generate the corresponding blockchain transaction according to the actual situation, and it does not necessarily process the remittance transaction tx_i immediately; in other words, device 1 to device 4 are actually asynchronous to the block The chain submits the remittance transaction tx_i (included in the corresponding blockchain transaction), so that the execution of the remittance transaction tx_i is allocated to be triggered by the device 1 to the device 4 respectively, prompting the device 1 to the device 4 to participate in a large number of remittance transactions In this case, blockchain transactions can be generated in batches for participating remittance transactions, thereby reducing the number of blockchain transactions generated and submitted, which helps reduce processing burden and improve processing efficiency.

Step 405: The blockchain node processes the received blockchain transaction to verify each remittance transaction included in the blockchain transaction.

Step 406, mark the remittance transaction tx_i.

In one embodiment, since each institution will continuously submit blockchain transactions to the blockchain, the remittance transactions included in the previously submitted blockchain exchange will affect the inclusion of blockchain transactions included in the subsequent submission. Remittance transactions, therefore, after receiving the blockchain transaction submitted by each institution, the blockchain node needs to read the sequence number seq contained in the received blockchain transaction, and process the Blockchain transactions of corresponding institutions. For example, when a blockchain node receives the TX_a blockchain transaction submitted by device 1, it reads the sequence number seq contained in it as 100; and if the sequence number of the latest blockchain transaction that the blockchain node has processed seq is 98, then the blockchain node needs to wait for the blockchain transaction with the sequence number seq of 99 submitted by the device 1, and only after the blockchain transaction with the sequence number 99 is processed, the sequence number is 100. Blockchain transactions are processed.

In an embodiment, after receiving the blockchain transactions submitted by the devices 1 to 4, the blockchain nodes can separately extract and verify the remittance transactions included in each blockchain transaction. Taking the blockchain transaction TX_a submitted by device 1 as an example, blockchain nodes can verify the certification information RP_i-3, RP_i-2, RP_i-1, RP_i, RP_i+1, RP_i+2, as shown in FIG. 5, In order to determine whether the remittance amount of each remittance transaction is in the correct value range; and, the blockchain node verifies the unified certification information RP_(i～i+2) to determine whether the account balance of the blockchain account Y1 is sufficient, to Determine whether each remittance transaction in the blockchain transaction TX_a can be successfully executed. Of course, the blockchain node may also implement other verification operations. You can refer to the verification process for remittance transactions in related technologies, such as verifying whether the remittance amount is consistent with the remittance amount, and whether it is consistent with the business amount. I will repeat it, and this specification does not limit it.

In one embodiment, if the execution of the remittance transaction is triggered by participants such as the remittance party, relay party, and recipient, the blockchain node also needs to verify whether each participant of the remittance transaction has implemented the trigger (ie Submit the blockchain transaction containing the remittance transaction). For example, FIG. 6 is a schematic diagram of a statistical trigger situation provided by an exemplary embodiment. As shown in Figure 6, based on the native functions of the blockchain or the extended functions provided by smart contracts, blockchain nodes can record the blockchain transactions submitted by institutions 1 to 4 respectively, such as the blockchain submitted by institution 1 Transaction TX_a, TX_*, Blockchain transaction TX_*, TX_b, TX_# submitted by Institution 2, Blockchain transaction TX_*, TX_c submitted by Institution 3, Blockchain transaction TX_d submitted by Institution 4, etc.; and, Block The chain node can extract the remittance transactions included in each blockchain transaction and make statistics for the participants of each remittance transaction (the details of the remittance transaction include the information of the remittance, relay, and recipient): when received When the remittance transaction is included in the blockchain transaction submitted by the corresponding participant, and the remittance transaction passes the above verification, the participant may be marked as "OK".

For example, since the blockchain transaction TX_a submitted by device 1 contains the remittance transaction tx_i, if the content of the blockchain transaction TX_a corresponding to the remittance transaction tx_i is verified, then the blockchain node can be marked as shown in Figure 6 " Y1:OK"; similarly, if the blockchain nodes are also marked as "Y2:OK", "Y3:OK", "Y4:OK", etc. for institutions 2 to 4, respectively, then the blockchain nodes can determine the The remittance transaction tx_i has been confirmed by all participants, and the remittance transaction tx_i can be marked as a successful status.

As another example, since only the blockchain transactions submitted by device 1, device 2, and device 3 contain information about the remittance transaction tx_*, even if the information has been individually verified, the blockchain node can still only be used for the remittance transaction tx_* adds tags "Y1:OK", "Y2:OK", "Y3:OK", and needs to continue to wait for the blockchain transaction submitted by device 4.

For another example, because only the blockchain transaction submitted by device 2 contains relevant information of the remittance transaction tx_#, even if the relevant information has been individually verified, the blockchain node can only add the tag “Y2:” to the remittance transaction tx_#: "OK", and need to continue to wait for the blockchain transaction submitted by device 1, device 3 and device 4.

Still taking the remittance transaction tx_i as an example, if any participant in the institution 1 to institution 4 fails to submit a blockchain transaction containing the remittance transaction tx_i before the transaction time arrives, the blockchain node will send the remittance transaction tx_i Marked as a timeout status, so that it cannot be successfully executed. If any of the participants in Institution 1 to Institution 4 mentioned a blockchain transaction containing the remittance transaction tx_i, but failed to pass the separate verification due to errors in the amount accumulation details or the interval certification error, then the blockchain node The remittance transaction tx_i will be marked as failed, so that it cannot be successfully executed.

When the remittance transaction tx_i or other remittance transactions are added with a success status, failure status, or timeout status flag by the blockchain node, Institution 1 to Institution 4 can refer to these statuses to generate the corresponding amount accumulation when they subsequently generate blockchain transactions Details, generating interval proofs with sufficient balance, etc. are similar to the processes described in steps 404a to 404d above, and will not be repeated here.

After confirming that the remittance transaction tx_i was successfully executed, Institution 1 collected 500 HKD from user 1 outside the chain, and transferred 500 HKD to institution 2, and institution 2 received 500 HKD from institution 1, and transferred 56 to institution 3, and the institution 3 Collecting 56 euros transferred into institution 2 and transferring 64 dollars to institution 4, agency 4 charging 64 dollars transferred into institution 3 and transferring 64 dollars to user 1 outside the chain, which is equivalent to the balance of expenditures of institutions 1 to 4. User 1 completes the remittance operation of 500 HKD to user 2.

The data changes on the blockchain ledger are: The blockchain account Y1 corresponding to institution 1 is updated to (currency_1, PC(a-t1, r_a-r_t1), Enc_A(a-t1), Enc_A(r_a-r_t1 )), a reduction of 500 Hong Kong dollars; the blockchain account Y2 corresponding to Institution 2 is updated to: (currency_1, PC(b1+t1, r_b1+r_t1), Enc_B(b1+t1), Enc_B(r_b1+r_t1)), ( currency_2,PC(b2-t2,r_b2-r_t2),Enc_B(b2-t2),Enc_B(r_b2-r_t2)), increased by 500 Hong Kong dollars, reduced by 56 Euros; the corresponding blockchain account Y3 of Institution 3 is updated to: (currency_2,PC(c1+t2,r_c1+r_t2),Enc_C(c1+t2),Enc_C(r_c1+r_t2)),(currency_3,PC(c2-t3,r_c2-r_t3),Enc_C(c2-t3), Enc_C(r_c2-r_t3)), increased by 56 euros and reduced by 64 dollars; the corresponding blockchain account Y4 of institution 4 is updated to: (currency_3,PC(d+t3,r_d+r_t3),Enc_D(d+t3) , Enc_D(r_d+r_t3)), increased by 64 dollars.

It should be pointed out that: in the blockchain transactions submitted by device 1 to device 4, not every remittance transaction is necessarily triggered by all participants; for example, at least one remittance transaction can use the technical solutions in related technologies , That is, a participant collects confirmation information of transaction details of all participants for remittance transactions, generates interval proofs required by the transaction, etc. (that is, generates the multi-party trigger information described in the above embodiment), and only the certain A participant submits a blockchain transaction containing the remittance transaction.

7 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 7. At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710. Of course, it may include hardware required for other services. The processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it to form a blockchain-based event processing terminal interaction device at a logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as a logic device or a combination of software and hardware, etc., that is to say, the execution body of the following processing flow is not limited to each The logic unit may also be a hardware or logic device.

Please refer to FIG. 8. In the software implementation, the blockchain-based event processing device is applied to participants, and may include:

The first generating unit 801 generates corresponding alternative sub-transactions according to the events in which the participant participates, so that several alternative sub-transactions are aggregated into a collective transaction; wherein, the alternative sub-transactions are set with corresponding State change amount for the state parameter of the participant to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount are calculated based on a homomorphic encryption algorithm, respectively The ciphertext value obtained or the promise value calculated based on the homomorphic promise algorithm;

The second generating unit 802 generates unified proof information for multiple candidate sub-transactions that are used to reduce the value of the state parameter in the adjacent and corresponding events in the aggregate transaction to prove that the state parameter is in The value after the multiple alternative sub-transactions is in the correct value interval;

The submitting unit 803 submits the set transaction to the blockchain, so that the candidate sub-transactions included in the set transaction are processed in sequence.

Optional, also includes:

The identifying unit 804, when several candidate sub-transactions are selected for aggregation into the set transaction, identify the manner in which the event corresponding to each selected candidate sub-transaction adjusts the value of the state parameter;

The arranging unit 805 arranges the at least two candidate sub-transactions adjacent to the set transaction when the events corresponding to the at least two candidate sub-transactions are used to reduce the value of the state parameter.

Optionally, the set transaction includes a pre-change state value and a post-change state value respectively corresponding to each candidate sub-transaction to match the state change amount set in each candidate sub-transaction, so that each After the candidate sub-transaction is processed, the state parameter of the participant changes from the pre-change state value to the post-change state value via the state change amount; wherein, the pre-change state value and the change The post-state value is a ciphertext value calculated based on the homomorphic encryption algorithm or a promise value calculated based on the homomorphic commitment algorithm, respectively.

Optional, also includes:

The third generating unit 806 separately generates corresponding independent certification information for each candidate sub-transaction in the set transaction, and the independent certification information is used to prove that the state change amount set in the corresponding candidate sub-transaction is in State the correct numerical interval.

Optionally, the candidate sub-transaction corresponding to the event includes unilateral trigger information of the participant on the event; wherein, when all participants of the event submit to the blockchain for the When the unilateral trigger information of the event is all verified, the alternative sub-transaction corresponding to the event is triggered to execute in the blockchain.

Optional, also includes:

The adding unit 807 adds corresponding numbers to each set transaction in the order of generation, so that each set transaction is sequentially processed in the blockchain according to the corresponding number size.

9 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 9. At the hardware level, the device includes a processor 902, an internal bus 904, a network interface 906, a memory 908, and a non-volatile memory 910. Of course, it may include hardware required for other services. The processor 902 reads the corresponding computer program from the non-volatile memory 910 into the memory 908 and then runs it to form a blockchain-based event processing terminal interaction device at a logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as a logic device or a combination of software and hardware, etc., that is to say, the execution body of the following processing flow is not limited to each The logic unit may also be a hardware or logic device.

Please refer to FIG. 10. In the software implementation, the blockchain-based event processing device is applied to a blockchain node, and may include:

The receiving unit 1001 receives a collective transaction submitted by a participant to the blockchain, and the collective transaction includes several alternative sub-transactions, the alternative sub-transactions correspond to events in which the participant participates; wherein, the backup The sub-transaction is set with a corresponding state change amount for the participant's state parameter to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount Respectively, the ciphertext value calculated based on the homomorphic encryption algorithm or the commitment value calculated based on the homomorphic commitment algorithm;

The first obtaining unit 1002 obtains unified certification information in the collective transaction, and the unified certification information corresponds to multiple adjacent and corresponding events in the collective transaction that are used to reduce the value of the state parameter. Alternative sub-transactions to verify whether the value of the state parameter after passing through the multiple alternative sub-transactions is in the correct value interval;

The determining unit 1003 determines the processing method of the multiple candidate sub-transactions according to the verification result.

Optional,

It also includes: a second obtaining unit 1004, which obtains independent certification information corresponding to each candidate sub-transaction in the collective transaction to verify whether the state change amount set in the corresponding candidate sub-transaction is within the correct numerical range ;

The determining unit 1003 is specifically configured to: when the verification result is verified, and the independent certification information corresponding to any one of the plurality of candidate sub-transactions passes verification, trigger execution of any Alternative sub-transactions.

Optional, also includes:

The third acquiring unit 1005, when the event corresponding to any candidate sub-transaction in the collective transaction is used to increase the value of the state parameter, acquires the candidate sub-transaction corresponding to the optional sub-transaction in the collective transaction Independent certification information of the transaction;

The first triggering unit 1006 triggers execution of any alternative sub-transaction when the independent certification information corresponding to the alternative sub-transaction passes verification.

Optionally, the candidate sub-transaction corresponding to the event includes unilateral trigger information of the participant on the event; the device further includes:

The second triggering unit 1007 triggers the execution of the alternative sub-transaction corresponding to the event when all the parties involved in the event submit the single-party trigger information for the event to the blockchain and the verification is passed.

Optional, also includes:

The identifying unit 1008 identifies the serial number corresponding to the collective transaction, and the serial number is added in the order in which each collective transaction is generated to sequentially process each collective transaction submitted by the participant according to the corresponding serial number size.

The system, device, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product with a certain function. A typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet computer, wearable device, or any combination of these devices.

In a typical configuration, the computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in computer-readable media, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media, including permanent and non-permanent, removable and non-removable media, can store information by any method or technology. The information may be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device that includes a series of elements includes not only those elements, but also includes Other elements not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. Without more restrictions, the element defined by the sentence "include one..." does not exclude that there are other identical elements in the process, method, commodity, or equipment that includes the element.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only, and is not intended to limit one or more embodiments of this specification. The singular forms "a", "said" and "the" used in one or more embodiments of the present specification and the appended claims are also intended to include the majority forms unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that although one or more embodiments in this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to a determination".

The above are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Anything within the spirit and principle of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc., should be included within the scope of protection of one or more embodiments of this specification.

Claims

A blockchain-based event processing method applied to participants. The method includes:

According to the events in which the participant participates, a corresponding alternative sub-transaction is generated, so that several alternative sub-transactions are aggregated into a collective transaction; wherein, the alternative sub-transaction is set with a corresponding state change amount to use In order to make the state parameters of the participants change correspondingly based on the state change, and the value of the state parameter and the state change are the ciphertext value calculated based on the homomorphic encryption algorithm or Commitment value calculated based on homomorphic commitment algorithm;

For multiple candidate sub-transactions in which the adjacent and corresponding events in the set transaction are used to reduce the value of the state parameter, unified certification information is generated to prove that the state parameter passes through the multiple backup The value after selecting the child transaction is in the correct value range;

Submit the aggregate transaction to the blockchain so that the alternative sub-transactions included in the aggregate transaction are processed in sequence.
The method of claim 1, further comprising:

When several candidate sub-transactions are selected for aggregation into the set transaction, identify the manner in which the event corresponding to each selected candidate sub-transaction adjusts the value of the state parameter;

When the events corresponding to at least two candidate sub-transactions are used to reduce the value of the state parameter, the at least two candidate sub-transactions are arranged adjacently in the set transaction.
The method of claim 1, the set transaction includes a pre-change state value and a post-change state value corresponding to each candidate sub-transaction, respectively, to match the state change set in each candidate sub-transaction After each candidate sub-transaction is processed, the state parameter of the participant changes from the pre-change state value to the post-change state value via the state change amount; wherein, the pre-change state The value and the changed state value are respectively a ciphertext value calculated based on the homomorphic encryption algorithm or a promise value calculated based on the homomorphic commitment algorithm.
The method of claim 1, further comprising:

The corresponding independent proof information is separately generated for each candidate sub-transaction in the set transaction, and the independent certification information is used to prove that the state change amount set in the corresponding candidate sub-transaction is within the correct numerical interval.
The method according to claim 1, wherein the candidate sub-transaction corresponding to the event includes unilateral triggering information of the participant on the event; wherein, when all participants of the event separately submit to the blockchain When the submitted unilateral trigger information for the event passes verification, the alternative sub-transaction corresponding to the event is triggered to execute in the blockchain.
The method of claim 1, further comprising:

Add corresponding numbers to each set transaction in the order of generation, so that each set transaction is processed sequentially in the blockchain according to the corresponding number size.
A blockchain-based event processing method applied to blockchain nodes. The method includes:

Receiving a set transaction submitted by a participant to the blockchain, the set transaction includes several alternative sub-transactions, the alternative sub-transactions correspond to events in which the participant participates; wherein, the alternative sub-transaction is set A corresponding state change amount is set for the state parameter of the participant to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount are based on the same The ciphertext value calculated by the homomorphic encryption algorithm or the promise value calculated based on the homomorphic commitment algorithm;

Acquiring unified certification information in the collective transaction, the unified certification information corresponding to multiple candidate sub-transactions that are adjacent and corresponding events in the collective transaction are used to reduce the value of the state parameter, Verify whether the value of the state parameter after passing through the plurality of candidate sub-transactions is in the correct value interval;

According to the verification result, a processing method for the multiple candidate sub-transactions is determined.
The method according to claim 7,

It also includes: obtaining independent certification information corresponding to each candidate sub-transaction in the set transaction to verify whether the state change amount set in the corresponding candidate sub-transaction is within the correct numerical range;

The determining the processing method for the multiple candidate sub-transactions according to the verification result includes: when the verification result is verified, and any of the multiple candidate sub-transactions corresponds to an independent When the certification information passes the verification, the execution of any of the candidate sub-transactions is triggered.
The method of claim 7, further comprising:

When the event corresponding to any candidate sub-transaction in the set transaction is used to increase the value of the state parameter, obtain independent certification information corresponding to the any candidate sub-transaction in the set transaction;

When the independent certification information corresponding to the any alternative sub-transaction passes the verification, the execution of the any alternative sub-transaction is triggered.
The method according to claim 7, wherein the candidate sub-transaction corresponding to the event contains unilateral trigger information of the participant on the event; the method further comprises:

When all the parties involved in the event submit the single-party trigger information for the event that is submitted to the blockchain, and the verification is passed, the execution of the alternative sub-transaction corresponding to the event is triggered.
The method of claim 7, further comprising:

Identify the serial number corresponding to the collective transaction, and the serial number is added in the order in which each collective transaction is generated to sequentially process each collective transaction submitted by the participant according to the corresponding serial number size.
An event processing device based on blockchain, applied to participants, the device includes:

The first generating unit generates corresponding alternative sub-transactions according to the events in which the participant participates, so that several alternative sub-transactions are aggregated into a collective transaction; wherein, the alternative sub-transactions are set with corresponding states The amount of change is used to make the state parameter of the participant change correspondingly based on the amount of state change, and the value of the state parameter and the amount of state change are calculated based on a homomorphic encryption algorithm, respectively The cipher text value or the promise value calculated based on the homomorphic promise algorithm;

The second generating unit generates unified proof information for multiple candidate sub-transactions that are adjacent and corresponding events in the set transaction to reduce the value of the state parameter, to prove that the state parameter is passing The value after the multiple candidate sub-transactions is in the correct value interval;

The submission unit submits the aggregate transaction to the blockchain, so that the candidate sub-transactions included in the aggregate transaction are processed in sequence.
The apparatus according to claim 12, further comprising:

An identification unit, when several candidate sub-transactions are selected for aggregation into the set transaction, identifying the manner in which the event corresponding to each selected candidate sub-transaction adjusts the value of the state parameter;

The arranging unit, when the events corresponding to at least two candidate sub-transactions are used to reduce the value of the state parameter, arrange the at least two candidate sub-transactions adjacently in the set transaction.
The device according to claim 12, wherein the set transaction includes a pre-change state value and a post-change state value corresponding to each alternative sub-transaction, respectively, to match the state change set in each alternative sub-transaction After each candidate sub-transaction is processed, the state parameter of the participant changes from the pre-change state value to the post-change state value via the state change amount; wherein, the pre-change state The value and the changed state value are respectively a ciphertext value calculated based on the homomorphic encryption algorithm or a promise value calculated based on the homomorphic commitment algorithm.
The apparatus according to claim 12, further comprising:

The third generating unit respectively generates corresponding independent certification information for each candidate sub-transaction in the set transaction, and the independent certification information is used to prove that the state change amount set in the corresponding candidate sub-transaction is in the Correct value interval.
The apparatus according to claim 12, wherein the candidate sub-transaction corresponding to the event includes unilateral triggering information of the participant on the event; wherein, when all participants of the event respectively submit to the blockchain When the submitted unilateral trigger information for the event passes verification, the alternative sub-transaction corresponding to the event is triggered to execute in the blockchain.
The apparatus according to claim 12, further comprising:

The adding unit adds corresponding numbers to each set transaction in the order of generation, so that each set transaction is processed sequentially according to the corresponding number size in the blockchain.
A blockchain-based event processing device applied to blockchain nodes, the device includes:

The receiving unit receives a collective transaction submitted by a participant to the blockchain, and the collective transaction includes several alternative sub-transactions, the alternative sub-transactions correspond to events in which the participant participates; wherein, the alternative The sub-transaction is set with a corresponding state change amount for the participant's state parameter to change correspondingly based on the state change amount, and the value of the state parameter and the state change amount are It is the ciphertext value calculated based on the homomorphic encryption algorithm or the promised value calculated based on the homomorphic commitment algorithm;

The first obtaining unit obtains unified certification information in the collective transaction, the unified certification information corresponding to multiple adjacent and corresponding events in the collective transaction are used to reduce the multiple values of the state parameter Select a sub-transaction to verify whether the value of the status parameter after the multiple candidate sub-transactions is in the correct value interval;

The determining unit determines the processing method for the multiple candidate sub-transactions according to the verification result.
The device according to claim 18,

It also includes: a second obtaining unit, which obtains independent certification information corresponding to each candidate sub-transaction in the set transaction to verify whether the state change amount set in the corresponding candidate sub-transaction is within the correct numerical range;

The determining unit is specifically configured to: when the verification result is verified, and the independent certification information corresponding to any one of the plurality of candidate sub-transactions passes the verification, trigger the execution of any backup Select sub-transactions.
The apparatus of claim 18, further comprising:

A third acquiring unit, when the event corresponding to any candidate sub-transaction in the collective transaction is used to increase the value of the state parameter, acquiring the corresponding sub-transaction in the collective transaction Independent certification information;

The first triggering unit triggers execution of any alternative sub-transaction when the independent certification information corresponding to the alternative sub-transaction passes verification.
The apparatus according to claim 18, wherein the candidate sub-transaction corresponding to the event includes unilateral trigger information of the participant on the event; the apparatus further includes:

The second triggering unit triggers the execution of the alternative sub-transaction corresponding to the event when all the parties involved in the event submit the single-party trigger information for the event to the blockchain and the verification is passed.
The apparatus of claim 18, further comprising:

The identification unit identifies the serial number corresponding to the collective transaction, and the serial number is added in the order in which each collective transaction is generated to sequentially process each collective transaction submitted by the participant according to the corresponding serial number size.
An electronic device, including:

processor;

Memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method according to any one of claims 1-6.
An electronic device, including:

processor;

Memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method according to any one of claims 7-11.