Specifically, this embodiment details the process of implementing a transaction by a user in an energy transaction scenario on a federation chain. In a nearby energy trading scene, when a user sells redundant energy, a token bank in a alliance chain network stores the transmitted energy, the token bank generates tokens according to the volume of the energy, and a specific account stored in the token of the current trading is determined according to a predicted value obtained from a historical trading record of the account of the user. Meanwhile, when a new account is created, the token bank updates the user-to-account mapping information.

The embodiment describes a specific operation of changing the real transaction distribution of the users in the alliance chain by adopting the method of the invention, and the specific operation comprises the following processes:

step 1: user a transfers energy to the energy storage pool closest to it and sends a sell request.

Step 2: the energy storage pool receives the energy transmitted by the user, meanwhile, the actual volume V of the energy transmitted by the user A is counted, the exchange rate R is set for the energy transaction, and the actual energy volume value V and the exchange rate value R are signed and then sent to the token bank.

And step 3: the token bank verifies whether the signature of the energy transaction pool is legal or not, if the signature is illegal, the request of the energy storage pool is rejected, and the whole process is ended; and if the code is legal, performing the next operation.

And 4, step 4: the token bank generates a token TO according TO the received energy volume value V and the exchange rate R, and the calculation formula is as follows: TO ═ V ═ 1-R. And then the bank of the token calculates the predicted value of the energy transaction of the account by using a prediction function according to the historical energy transaction information of the latest account of the user A.

And 5: the token bank compares the predicted value with the account actual energy value V added with the transaction amount, if the predicted value is larger than or equal to the actual value, the existing account is still used for recording the transaction, and the next step is skipped; otherwise, a new account is created for the user to record the transaction.

Specifically, whether a new account needs to be generated is determined by a boundary value B (i.e., a predicted value) generated by a prediction function: t (si) ═ a (E)^e_i-1+b(E^r_i-1-E^e_i-1) T, wherein a is a weight value, E^e_i-1The estimate of the ith-1 energy transaction of the seller account is represented by the formula E^e_i＝E^e_i-1+b(E^r_i-1-E^e_i-1) And b is the weight value, and the value range of b is between 0 and 1.

The method for generating the account energy transaction amount boundary value specifically comprises the following steps:

the input includes: ei, a, b, and c, all historical sales records for the seller s, and historical energy sales records for all accounts of the token bank.

The output includes: b is

1: all transaction records do for s

2: e | s ← Σ ei/N (s)// calculating average monthly energy transaction amount for seller account

3：end for

4: for each active account do

5: calculating an average value E | S of energy transactions per month

6：end for

7: computing T ← (E | S × c)/E | S

8: reading the energy transaction value ei of the input request, the parameters a and b and the previous i-1 historical energy transaction values of the seller account;

9: utilizing E according to the previous i-1 historical energy transaction values of the seller account^e_i＝E^e_i-1+b(E^r_i-1-E^e_i-1) Calculated ith energy transaction estimate E^e_i；

10: will E^e_iSubstituting into the formula t (si) ═ a × E^e_iCalculating B by T;

11: returning the boundary value B

Step 6: the token bank encrypts the mapping relation from the user A to the newly generated account, generates an aggregated signature with the original ciphertext of the mapping relation from the user A to the account, and then updates and stores the mapping relation from the user A to all accounts.

This stage corresponds to step 6 in the summary of the invention, and specifically includes the following substeps:

step 6.1: the token bank sends a request to user a asking user a to send its stored original user-to-account mapping information cryptogram that has been encrypted by the token bank and the token bank's aggregated signature on the cryptogram.

Step 6.2: the token bank verifies whether the aggregated signature is legal or not, and if the aggregated signature is illegal, the user A is required to resend the aggregated signature; if the signature is legal, the encrypted user-to-account mapping information ciphertext sent by the user A is approved and stored, and the aggregated signature is stored at the same time.

Step 6.3: and the token bank encrypts the mapping relation between the user A and the newly generated account and signs the ciphertext information.

Step 6.4: and the token bank carries out the aggregation operation again on the newly generated signature and the aggregation signature sent by the user A to generate a new aggregation signature.

Step 6.5: the token bank replaces the stored encrypted information from the user A to the latest account in the token bank by the encrypted mapping information from the user A to the new account.

Step 6: and the token bank sends all the current ciphertext of the mapping relation pair from the user to the account of the user A and the aggregated signature of the ciphertext to the user A together for storage, and reminds the user A to update and store the original mapping relation from the user to the account.

And 7: the bank deposits the token of the user A into the correct account according to the result of step 5.

And 8: the transaction data is linked up.

Claims

1. A federation chain privacy protection method based on a cluster signature firstly explains the related definitions:

definition 1: federation link network

The system is an infrastructure network for energy transaction, and nodes of the infrastructure network comprise a token bank, an energy storage pool and a transaction entity;

definition 2: bank of tokens

The node is a node for realizing acquisition of token and segmentation and hiding of a real transaction record of a user in the alliance chain network;

definition 3: energy storage pool

The node is a node for realizing energy storage in a alliance chain network;

definition 4: transaction entity

The energy trading method is characterized in that a user in an energy trading system based on a alliance chain is a seller of energy;

the method is characterized by comprising the following steps:

step 1: the user transmits energy to the energy storage pool nearest to the user and sends out a sale request;

step 2: the energy storage pool receives the energy transmitted by the user, meanwhile, the actual volume V of the energy transmitted by the user is counted, and an exchange rate R is set for the energy transaction, wherein the value range of the R is 0 to 1; then, after signing the actual energy volume value V and the exchange rate value R, sending the actual energy volume value V and the exchange rate value R to a token bank;

and step 3: the token bank verifies whether the signature of the energy transaction pool is legal or not, if the signature is illegal, the request of the energy storage pool is rejected, the whole process is ended, and if the signature is legal, the next operation is carried out;

and 4, step 4: the token bank generates a token TO according TO the received energy volume value V and the exchange rate R, and the calculation formula is that TO is V (1-R); then, the bank of the token judges whether a new account needs to be generated or not according to the historical energy transaction information of the latest account of the user through a prediction value generated by a prediction function;

and 5: the token bank compares the predicted value with the actual energy value of the account added with the transaction amount, if the predicted value is more than or equal to the actual value, the existing account is still used for recording the transaction, and step 7 is executed; otherwise, generating a new account for the user to record the transaction, and then executing the step 6;

step 6: the token bank encrypts the mapping relationship from the user to the newly generated account and generates an aggregated signature for the mapping relationship and the original ciphertext of the mapping relationship from the user to the account. Then, updating and storing the mapping relation from the user to all accounts;

and 7: the bank deposits the user's token into the correct account according to the result of step 5;

and 8: the transaction data is linked up.

2. The federation chain privacy protection method based on the aggregated signature as claimed in claim 1, wherein in step 4, the generation of the predicted value is obtained by bringing all historical energy trading values of the latest account of the user and all historical energy trading values of all active accounts in the system into a prediction function, and setting parameters for the function according to the original experience, wherein the judgment of the active accounts is determined by the preset lowest energy trading value of the accounts, if the accumulated energy trading value of one account is greater than or equal to the value, the active accounts belong to, otherwise, the inactive accounts belong to;

the prediction function T (Si) is:

T(Si)＝a*(E^e_i-1+b(E^r_i-1-E^e_i-1))*T (1)

3. The federated coalition chain privacy protection method based on aggregated signatures as recited in claim 1, wherein the step 6 comprises the following steps:

step 6.1: the token bank sends a request to a user, and the user is required to send an original user-account mapping information ciphertext which is stored by the user and encrypted by the token bank and an aggregated signature of the token bank to the ciphertext;

step 6.2: the token bank verifies whether the aggregated signature is legal or not, and if the aggregated signature is illegal, the user is required to resend the aggregated signature; if the encrypted user-account mapping information is legal, giving approval and storing the encrypted user-account mapping information ciphertext sent by the user, and storing the aggregated signature;

step 6.3: the token bank encrypts the mapping relation between the user and the newly generated account and signs the ciphertext information;

step 6.4: the token bank carries out the aggregation operation again on the newly generated signature and the aggregation signature sent by the user to generate a new aggregation signature;

step 6.5: the token bank replaces the stored encrypted information from the original user to the latest account in the token bank by the encrypted mapping information from the user to the new account;

4. A federation chain privacy protection method based on aggregate signatures as claimed in claim 3, characterised in that in step 6.3 the token bank encrypts the mapping between the user and the newly created account using symmetric encryption.