CN108510252B

CN108510252B - Intelligent electric vehicle power grid safety payment method based on block chain

Info

Publication number: CN108510252B
Application number: CN201810309352.3A
Authority: CN
Inventors: 沈蒙; 杨晶; 祝烈煌; 高峰; 李艳东
Original assignee: Beijing Institute of Technology BIT
Current assignee: Beijing Institute of Technology BIT
Priority date: 2018-03-24
Filing date: 2018-04-09
Publication date: 2020-08-18
Anticipated expiration: 2038-04-09
Also published as: CN108510252A

Abstract

The invention relates to a block chain-based intelligent electric vehicle power grid safety payment system and method, and belongs to the payment field of a V2G network. The system of the invention is divided according to roles and comprises electric vehicle users, a Registration Authority (RA) and a block chain network. The payment management system comprises a registration module, a payment execution module and a data sharing module according to functional division. Based on the block chain technology and the cryptography technology, a special registration mechanism, an authentication mechanism and a new payment mechanism are adopted. The method can solve the problems of data sharing and identity privacy protection of the user in the V2G network payment field, and can realize effective supervision and privacy protection. The method can reduce external attack threat, realize data sharing and better accord with practical application scenes. Effective audit can be supported, and privacy data can be protected under the condition of supporting audit. The method can meet the requirements of transaction data sharing and privacy information disclosure prevention.

Description

Intelligent electric vehicle power grid safety payment method based on block chain

Technical Field

The invention relates to a block chain-based intelligent electric vehicle power grid safety payment system and method, and belongs to the payment field of a V2G network.

Technical Field

The electric automobile in the V2G network has the dual identities of an electric energy consumer and an electric energy provider, can acquire electric energy from a power grid or release redundant electric energy to the power grid according to the power grid requirement, can help the smart power grid to complete peak-shaving energy storage tasks, and can earn income for an electric vehicle holder, so that the V2G network is rapidly becoming an important development direction of the future smart power grid.

In a V2G network, bidirectional power transfer between all participants (including electric vehicles and the grid) is accompanied by a large number of records of payment for electricity charges, and these payment data can be analyzed and used to provide additional services, such as power load prediction, electricity charge price prediction, energy consumption optimal scheduling, and behavior modeling of electric vehicles participating in auxiliary services. However, the payment record sharing may bring threat of leakage of private data, including user identity information, location information, and charging and discharging rules of the electric vehicle. Therefore, it is very necessary to carefully study the balance between data sharing and privacy protection in V2G networks.

However, traditional payment mechanisms (e.g., credit card and electronic payment) as well as existing anonymous payment mechanisms in V2G networks are typically centralized in architecture, with data privacy dependent on the security of trusted nodes that handle payment processes. Once a trusted node is attacked, the payment system is at risk of single point crash, and in a scenario where payment data needs to be shared to multiple entities for analysis, it is difficult for the anonymous payment mechanism to provide the same privacy protection performance.

Therefore, in order to satisfy the requirements of privacy protection of user identity and data sharing in the payment scenario of V2G, a suitable anonymous payment mechanism must be designed.

In a V2G network, electric vehicles are typically connected to a LAG through a wireless network. Thus, payment information may be stolen by an attacker. Since the payment records will be shared to all participants, it is possible for a potential attacker to infer sensitive information of the electric vehicle, such as charging location and charging period. Furthermore, it is possible for an attacker to obtain private information from the payment record by collusion with malicious users. For example, in the distributed charging mode, a malicious owner of an electric vehicle may leak its own location information and payment record to an attacker, and then the attacker may deduce the location information of another electric vehicle in the transaction. Furthermore, it is possible for an attacker to fool a honest user by creating unreliable payments, including counterfeit transactions and double payments (i.e. paying two or more times in the same digital currency). In a distributed system without trusted third party nodes, it is difficult to detect and deny unreliable payments.

Disclosure of Invention

The invention aims to solve the problem that a payment mechanism in the field of V2G network payment is difficult to guarantee the required data sharing and privacy protection requirements, and provides an intelligent electric vehicle power grid safety payment system and method based on a block chain.

A safe payment system and method of an intelligent electric vehicle power grid based on a block chain comprises a safe payment system of the intelligent electric vehicle power grid based on the block chain and a safe payment method of the intelligent electric vehicle power grid based on the block chain;

the intelligent electric vehicle power grid safety payment system based on the block chain is called a payment system for short; a safe payment method of an intelligent electric vehicle power grid based on a block chain is called as the method for short;

the payment system is divided according to functions and comprises a registration module, a payment execution module and a data sharing module;

the main task of the registration module is to submit an account generated by a user to RA for verification and registration;

the payment execution module ensures that the payer can smoothly pay the electric charge and the payee can verify the account condition; in the method, the payment of the electric charge is realized by block chain transaction, so the process executed by the payment execution module is the process that one block chain transaction is written into the global account book;

the data sharing module realizes a sharing mode of payment data; all legal transaction records in the scheme are written into a global account book; the global account book in the block chain system is shared by all participants, so that any participant can operate and maintain the local global account book through the operation block chain client and keep synchronization with the global account book in the network; when a specific transaction needs to be inquired, only a local global account book needs to be inquired directly;

the payment system is divided according to roles and comprises an electric vehicle user, a Registration Authority (RA) and a block chain network;

the electric vehicle users refer to users in the payment system, including electric vehicles and entities participating in the transaction process, wherein the entities can be charging facilities, and the entities can be used as paying parties and collecting parties in the payment system;

each electric vehicle user processes transaction information and maintains a global account book by installing a blockchain client; the computing and communication functions of most modern electric vehicles can meet the requirements of operating a blockchain client;

wherein the Registration Authority (RA): RA represents an authorized arbitration mechanism and is responsible for account registration and transaction record auditing;

RA maintains a global ledger containing all transaction information by running a blockchain client; RA also operates and maintains a certificate library, and all legal accounts and corresponding identity information are stored in the certificate library; RA is considered as a trusted entity, and not only can check all transaction records, but also can obtain the identity information of a transactor corresponding to any anonymous transaction record;

wherein, the blockchain network: the blockchain network refers to blockchain infrastructure and comprises related communication mechanisms and consensus mechanisms; the transaction format and the transaction verification method are mainly improved, and the other parts are similar to the traditional blockchain network;

a safe payment method for an intelligent electric vehicle power grid based on a block chain comprises the following steps:

step 1: the user account registration and verification method specifically comprises the following substeps:

step 1.1, the user generates an account by himself, specifically: the user generates a key pair (Pk _ user; Sk _ user) using an asymmetric encryption algorithm;

wherein, the asymmetric encryption algorithm can adopt an algorithm mainly based on RSA and ECC;

step 1.2, submitting the Pk _ user generated by the user in step 1.1 and the identity information of the user to RA for signature;

the identity information of the user is mainly information of an identity card or a driving license;

wherein, the RA is signed, specifically: after the RA checks the identity information, the private key Sk _ RA of the RA is used for signing the Pk _ user of the user, and the signature (Sk _ RA; Pk _ user) is output;

wherein Sign is a signature function in an ECDSA digital signature mechanism and can be obtained from a password library mainly comprising OPENSL;

step 1.3, the signature information output in step 1.2 is sent to a user;

step 1.4RA stores user information, specifically: the RA saves the legal account number of the user and the identity information of the user in a certificate library maintained by the RA;

the format of the legal account of the user stored in the certificate library of RA is specifically denoted as account ═ Pk _ user,;

step 1.5, the user uses the Pk _ user and synthesizes a legal account;

step 1.6, when the user carries out transaction, the payer verifies whether account is legal or not;

wherein the payer is a user of the payment during the transaction;

the payer verifies whether the account is legal or not by v ═ Verify (Pk _ RA; account.Pk _ user; account.);

wherein Verify is a verification function in an ECDSA digital signature mechanism and can be obtained from a password library mainly comprising OPENSL; pk _ RA is a public key of RA, RA is responsible for publishing the parameter in a public way, and any user can obtain Pk _ RA from a public channel; the account.pk _ user is a public key of an account to be verified, and any user can directly obtain the account.pk _ user from the account (account); account is the signature of the account to be verified, and any user can directly obtain account from the account (account);

when the output v is 1, the signature is legal, and jumping to the step 2;

otherwise, v is not equal to 1, the signature is invalid, the account belongs to an illegal account, and the step 1.1 is skipped;

wherein, step 1.1 to step 1.6 the user applies for the legal account number to RA once, and repeat the application after using up;

the number of the legal accounts which are applied for RA by the user at one time is more than or equal to 1;

step 2: paying the electricity fee;

the method comprises the following steps that block chain transaction is adopted for electric charge payment, so that the process of electric charge payment is a process that one block chain transaction is written into a global account book, the electric charge payment needs to ensure that a payer can smoothly pay electric charges, a payee can verify the account condition, and the payee generates different account numbers for each transaction so as to hide the transaction rule; the payee is the user who collects the money during the transaction;

wherein, account number and legal account number are expressed as: account ═ (Pk _ user,);

the legal account is RA generated in (Pk _ user) and is RA verified;

the account in step 2 is that account is either generated by RA or is forged;

step 2, specifically comprising the following substeps:

step 2.1, initializing the number of sending times n to be 1, and setting the maximum number of sending times Nmax;

wherein the value of Nmax is more than or equal to 1 and less than 5;

step 2.2, the payee sends the account number and the electric charge information to the payer;

wherein, the account is account ═ (Pk _ user);

wherein the electricity charge information includes unit price and total amount; wherein the total amount is a total price of electricity charge calculated by the payee based on the unit price;

step 2.3, the payer receives the account number and the electric charge information sent by the payee in step 2.2, and verifies whether the account number of the payee is legal according to step 1.6, which specifically comprises the following steps:

the payer obtains a public key Pk _ RA of the RA from the public channel, calculates the value of a Verify (Pk _ RA; account.Pk _ user; account.1) function, and jumps to step 2.5 when the output function value is 1, which represents that the signature is legal;

otherwise, the output function value is not equal to 1, the signature is invalid, the account number of the payee belongs to an illegal account number, the payer refuses the payment request of the payee, a message that the account number of the payee is illegal is returned to the payee, and the step jumps to step 2.4;

step 2.4, the payee sends the account number and the electric charge information to the payer, updates n to n +1, judges whether n is greater than or equal to Nmax, and determines whether to execute the sequence or jump to step 1.1 according to the judgment result, specifically: if n is greater than or equal to Nmax, indicating that Nmax has been retransmitted for times, jumping to step 1.1; if n is less than Nmax, indicating that Nmax times of resending are not reached, jumping to step 2.4;

step 2.5, the payer uses the block chain client to create a block chain transaction;

wherein, the block chain client is simply called as the client;

wherein, a block chain transaction format comprises 3 parts: a source address area, a price area and a destination address area;

wherein the source address area contains transaction input information, the input information in the source address is not an account number directly listing the payer, but an output information pointing to the previous transaction, denoted as < sn _ sf; pre _ txhash; pre _ sn _ df; signature >;

wherein the number of the transaction input information is more than or equal to 1;

the sn _ sf represents the serial number of the current input information in a transaction source address area, the pre _ txhash is the txhash of the previous transaction, the current input source transaction can be found through the hash value, the pre _ sn _ df is the corresponding serial number of the current input information in the previous transaction destination address area, and the signature is the signature of the corresponding account number owner in the previous transaction; any user can detect whether the current input information is legally authorized by verifying the legality of the signature;

wherein the price region comprises unit price and total amount;

the unit price records the power price at the corresponding moment of the current transaction, and the data can be used for analyzing the change trend of the power price;

wherein the total amount represents a co-paid fee for the current transaction; when the payment system carries out a transaction verification process, whether all input money is larger than or equal to the total money is verified;

the account number of the payee and the collection amount form output information of the transaction, and the output information is expressed as < sn _ df, account, and account >;

wherein, sn _ df represents the serial number of the output information in the destination address area, account represents the account number of the payee, and amount represents the amount of money to be collected; the payment system requires that the sum of all output amounts be equal to the sum of the transaction input amounts; when the sum of the input amount exceeds the total amount of the electric charge of the current transaction, the payer lists an account number of the payer in a destination address area when establishing the transaction so as to receive the change fund;

the Signature generation process is represented as: signature (sk (tx)); sk represents a private key corresponding to each input account of the payer in the transaction source address area; tx represents all data in the transaction information; each signature is that the payer signs all elements of the current transaction by using the private key of the payer; the transaction signature process is specifically as follows:

wherein, signature is Sk _ user (txid, txhash, SF, PF, DF)

SF＝{[sn_sf,pre_txhash,pre_sn_df]；[sn_sf,pre_txhash,pre_sn_df]...}

PF＝{unit price,total amount}

DF＝{[sn_df,account,amount]；[sn_df,account,amount]...}；

Step 2.5 comprises the following substeps:

step 2.5.1 the payer inputs the electric charge information received in the step 2.2 in the client;

step 2.5.2 the payer inputs the account number of the payee received in step 2.2 in the client;

step 2.5.3 the client of the payer automatically selects the existing account number of the payer as the input of the transaction;

step 2.5.4 the payer client verifies whether all the input amounts of the transaction are more than or equal to the total amount, and performs corresponding operations according to the judgment result:

2.5.4A, when all input amounts of the transaction are larger than or equal to the total amount, the transaction amount is legal, and the step 2.6 is skipped;

2.5.4B, if not, all input amount of the transaction is less than the total amount, which indicates that the transaction amount is illegal; the client prompts the payer that the account amount is insufficient, and the step jumps to step 2.5;

step 2.6, the payer sends the transaction and continuously checks the transaction state;

step 2.6.1 the payer sends the transaction to the blockchain network by using the client;

after entering a blockchain network, block chain transaction is flooded to all nodes in the network according to a blockchain data propagation mechanism;

step 2.6.2 the payer will continue to check its own global account book until the transaction status is displayed as a completed status at the client; wherein, the header of the transaction in the completion state contains 1 unique transaction ID, which is represented as: txid, and a unique transaction hash value, the transaction hash value being represented as: txhash; wherein the hash value is used as an index value for the transaction;

step 2.6.3 the payer sends the transaction ID to the payee;

step 2.7, verifying the transaction by the network node of the block chain;

wherein, the block chain network node is referred to as a node for short; the node verification content comprises four aspects: verifying whether all account numbers in the transaction are legal or not, whether signature information in all input information of the transaction is legal or not, whether the total amount of all input money of the transaction is greater than or equal to the total amount of output money and whether the transaction format meets the specified format or not;

step 2.7 again specifically comprises the following substeps:

step 2.7.1 the node verifies whether all account numbers in the transaction are legal, specifically:

all account numbers in the transaction comprise input account numbers and output account numbers, the number of the input account numbers is more than or equal to 1, and the number of the output account numbers is more than or equal to 1;

here, for example, the payee account is: account _ layer ═ Pk _ user _ layer, _ layer); the account number of the payer is as follows: account _ layer ═ Pk _ user _ layer, _ layer);

the node obtains a public key Pk _ RA of RA from a public channel;

wherein, the node verifies whether the payee account is legal: calculating the value of Verify (Pk _ RA; account _ layer. Pk _ user _ layer; account _ layer. layer), and jumping to step 2.7.2 when the output v is 1, which represents that the account is legal; otherwise, v is not equal to 1, which indicates that the account is invalid, the account _ layer belongs to an illegal account, and the step 2.8 is skipped;

wherein, the node verifies whether the account number of the payer is legal: calculating the value of Verify (Pk _ RA; account _ layer. Pk _ user _ layer; account _ layer. layer), and jumping to step 2.7.2 when the output v is 1 to represent that the account is legal; otherwise, v is not equal to 1, which indicates that the account is invalid, the account _ layer belongs to an illegal account, and the step 2.8 is skipped;

step 2.7.2, the node verifies whether signature information in all input information of the transaction is legal or not, and performs related operation according to the validity or not of the signature information; the specific process of verifying whether signature information in all input information of the transaction is legal by the node is as follows: the node extracts public key information required by signature verification from an account corresponding to input information of transaction;

wherein, the transaction signature verification process: v ═ Verify (Pk _ RA; signature);

the account corresponding to the input information of the transaction is specified by pre _ txhash and pre _ sn _ df parameters in the input information;

the node performs related operations according to whether the signature information is legal or not, specifically: if the signature information is legal, go to step 2.7.3; if the signature information is illegal, jumping to the step 2.8;

the step 2.7.3 node verifies whether all the input total amounts of the transaction are greater than or equal to the output total amount, the specific process is: the total amount of all inputs of the node calculation transaction is recorded as Sum _ input, the total amount of the transaction output is calculated by the node, and the node compares the difference Value _ bal between the calculation result Sum _ input and Sum _ output; and according to the judgment result of whether the input total sum is more than or equal to the output total sum, the following operations are carried out:

2.7.3A, if the total amount is greater than or equal to the total amount, go to step 2.7.4;

2.7.3B, if the total amount input is less than the total amount output, go to step 2.8;

step 2.7.4, the node verifies whether the transaction format is legal and carries out relevant operation according to whether the transaction format is legal; the specific process of verifying whether the transaction format is legal by the node is as follows: the node compares whether the format of the received transaction is consistent with the specified format; the node performs related operations according to whether the transaction format of the transaction is legal, specifically: if the format of the transaction received by the node is consistent with the specified format, the transaction format of the transaction is legal, and the step 2.9 is skipped; if the format of the transaction received by the node is not consistent with the specified format, the transaction format of the transaction is illegal, and the step 2.8 is skipped;

step 2.8, the node directly discards the transaction without relaying the transaction to a neighbor node of the node, and the step 4 is skipped;

step 2.9, the node rebroadcasts the transaction to the neighbor node of the node;

step 2.10, the miner node digs the mine and writes the transaction into a global account book;

wherein, the miner node is a special block chain network node;

step 2.10.1 the miner node verifies the transaction;

step 2.10.2, the miner node completes the calculation problem of the consensus mechanism and writes the transaction into a global account book; wherein, the transaction is written into the global account book, and the transaction becomes a completion state;

step 2.10.3 after step 2.10.2, the global ledger changes;

and step 3: the payer inquires about the transaction and provides service;

step 3.1, the payer client synchronizes the data of the global account book;

the payer client synchronizes the global account book according to the inquiry request mode;

step 3.1.1 payer client adds block chain network;

step 3.1.2 the payer client inquires the neighbor node about the latest Block number Cur _ Net _ Block _ ID of the neighbor node;

step 3.1.3 the payer client compares the latest Block number Local _ Block _ ID and Cur _ Net _ Block _ ID stored in its Local global account; and according to the sizes of the Local _ Block _ ID and the Cur _ Net _ Block _ ID, performing related operation:

3.1.3A if Cur _ Net _ Block _ ID is greater than Local _ Block _ ID, indicating a global ledger change in the blockchain network, the payer client requests the neighbor node for chunk data from Local _ Block _ ID +1 to Cur _ Net _ Block _ ID; the neighbor node sends the requested data to the payer client;

3.1.3B if Cur _ Net _ Block _ ID is less than or equal to Local _ Block _ ID, it means that the Local global ledger for the payer client is already the most up-to-date global ledger;

step 3.2, the payee verifies the transaction and provides service;

step 3.2.1 the payee inputs the transaction ID received at step 2.6.3 at the client, querying the specific content and status of the transaction;

step 3.2.2 the payee client displays the specific information of the inquired transaction;

the specific information includes: transaction ID (txid) of the transaction, transaction hash value (txhash), and information mainly including a source address area, a price area, and a destination address area in a transaction format;

step 3.2.3 the payee checks whether the payee account in the transaction is the own account; if the account number of the payer exists, checking the amount of money paid by the payer to the account number; jumping to step 3.2.4; if the account number of the receiver in the transaction does not have the account number held by the receiver, the service is refused to be provided;

step 3.2.4, the payee provides the corresponding amount of power transmission service according to the amount paid to the payee and the unit price of the electric charge by the payer;

the service provided by the payee can be a service mainly based on power transmission;

and 4, step 4: the payee and payer end the transaction.

Advantageous effects

Compared with the conventional safe payment method, the intelligent electric vehicle power grid safe payment method based on the block chain has the following beneficial effects:

1. the method can solve the problems of data sharing and identity privacy protection of the user in the V2G network payment field, and can realize effective supervision and privacy protection;

2. the method is established based on the blockchain technology, transaction records can be easily shared by all registered users including electric vehicles, LAG and RA, any registered member can automatically maintain a global account book containing all transaction data by operating a blockchain client, and the transaction data is invisible for non-registered users, namely users who do not join a blockchain network, so that external attack threats can be reduced, data sharing is realized, and the method is more suitable for actual application scenes; the method of the invention can support effective audit by adopting a special registration mechanism and a special verification mechanism, namely, the registration and the verification in the step 1;

3. the method of the invention provides a special payment mechanism which can protect private data under the condition of supporting audit;

4. the method of the invention can meet the requirements of transaction data sharing and privacy information disclosure prevention.

Drawings

FIG. 1 is a system model architecture and method workflow diagram of an intelligent electric vehicle power grid security payment system and method based on a blockchain of the present invention;

FIG. 2 is a transaction format of the smart electric vehicle power grid security payment method based on the blockchain.

Detailed description of the preferred embodiments

The intelligent electric vehicle power grid safety payment method based on the block chain is described in detail below with reference to the accompanying drawings.

Example 1

This example describes the steps of the method of the present invention in further detail.

Fig. 1 is a system model architecture and a method workflow diagram of a system and a method for secure payment of an intelligent electric vehicle power grid based on a block chain, as shown in fig. 1, including the following steps:

i, registering and verifying an Alice account of a user; the method specifically comprises the following substeps:

step I.1, a user Alice generates a key pair (Pk _ user; Sk _ user) by using an RSA algorithm;

step I.2, the Pk _ user generated by the user Alice and the identity card number of the Alice in the step I.1 are: 510723199007195415, name: alice, gender: female and home address: number 5 and driver's license number in south street of guancun, hai lake district, beijing: 123456789 submits to RA for signature;

wherein, the RA is signed, specifically: RA checks the information submitted by user Alice, including: identity card number, name, gender, home address and driver's license number;

when the information of the user Alice is checked by the RA, the RA signs the Pk _ user of the Alice by using a private key Sk _ RA, and outputs the signature (Sk _ RA; Pk _ user);

otherwise, the RA finds that the identity card number of the Alice does not accord with the driving license number, the RA refuses to register the Alice account, feeds error information back to the Alice, and prompts the Alice to submit correct information;

step I.3RA sends the signature information output in step I.2 to user Alice;

step I.4RA stores the user Alice information, specifically: RA saves Pk _ user of Alice and identity card number, name, sex, family address and driving license number information of Alice in a certificate library maintained by RA;

step i.5alice uses Pk _ user and a synthetic legal account, where the format of the legal account is specifically expressed as account ═ Pk _ user,;

step II, registering and verifying three different account numbers of the user Bob; the method specifically comprises the following substeps:

step II.1 user Bob generates three key pairs (Pk _ user _ Bob; Sk _ user _ Bob), (Pk _ user _ Bob _ 1; Sk _ user _ Bob _1) and (Pk _ user _ Bob _ 2; Sk _ user _ Bob) using the RSA algorithm

Step II.2, the Pk _ user _ Bob generated by the user Bob in the step I.1 and the identity card number of Bob are: 510723199007190000, name: bob, gender: male and home addresses: number 8 and license number of south street of Guancun in Haizu district, Beijing: 123498765 submitted to the RA for signing;

wherein, the RA is signed, specifically: RA checks the information submitted by user Bob, including: identity card number, name, gender, home address and driver's license number;

when the RA passes the information check of the user Bob, the RA signs the Pk _ user _ Bob of the user Bob by using the private key Sk _ RA, and outputs the _ Bob as Sign (Sk _ RA; Pk _ user _ Bob);

otherwise, the RA finds that the identity card number of the Bob does not accord with the driving license number, the RA refuses to register the Bob account number, feeds error information back to the Bob, and prompts the Bob to submit correct information;

step II.3RA sends the signature information _ Bob output in the step I.2 to a user Bob;

step II.4RA stores user Bob information, specifically: RA saves Pk _ user _ Bob of user Bob and identity card number, name, gender, home address and driver's license number information of Bob in a certificate library maintained by RA;

step ii.5Bob uses Pk _ user _ Bob and a synthetic legal account number, the format of the legal account number is specifically expressed as account _ Bob ═ (Pk _ user _ Bob, _ Bob);

step ii.6bob repeats steps ii.2 to ii.5, completing registration and validation of two other accounts, two other accounts being: account _ Bob _1 ═ Pk _ user _ Bob _1, _ Bob _1) and account _ Bob _2 ═ Pk _ user _ Bob _2, _ Bob _ 2;

step III, Bob pays the electricity charge of 200 RMB to Alice; step III specifically comprises the following substeps:

step III.1Alice accounts: account ═ (Pk _ user,) and electricity charge price: 5 yuan/degree, and sending to Bob;

step III.2Bob verifies whether account (Pk _ user) sent by Alice is legal or not; bob obtains a public key Pk _ RA of RA from a public channel;

bob calculates v-Verify (Pk _ RA; account.Pk _ user; account.) and outputs v-1 which represents that Alice account is legal;

step III.3Bob uses the block chain client to create a block chain transaction;

among them, Bob's two accounts have funds available, account _ Bob _1 ═ Pk _ user _ Bob _1, _ Bob _1) account has funds 120RMB therein and account _ Bob _2 ═ Pk _ user _ Bob _2, _ Bob _2) account has funds 80RMB therein. The Hash values for Bob's historical transactions are: the 1 st output of the pre _ txhash _ Bob1 transaction and the 2 nd output of the pre _ txhash _ Bob2 transaction;

wherein the header of the transaction contains 1 unique transaction ID: 000003, and a unique transaction hash value: 111ab 3; wherein the hash value is used as an index value for the transaction;

wherein, a block chain transaction content comprises 3 parts: a source address area, a price area and a destination address area;

wherein the source address region is < 0; pre _ txhash _ Bob 1; 1; signature1> and < 1; pre _ txhash _ Bob 2; 2; signature2 >;

SF＝{[0，pre_txhash_Bob1，1]，[1，pre_txhash_Bob2，2]}

PF＝{5,200}

DF＝{0,account＝(Pk_user,),200}

signature1＝Sk_user_Bob_1(000003，111ab3，SF，PF，DF)；

signature2＝Sk_user_Bob_2(000003，111ab3，SF，PF，DF)；

wherein, the output information is <0, account ═ Pk _ user, 200 >;

step iii.3 comprises in particular the following substeps:

step III.3.1Bob client verifies that all input amounts 200 of the transaction are equal to the total amount 200, which indicates that the transaction amount is legal;

step III.4Bob clicks a transaction sending button at the client, sends the transaction, continuously refreshes a transaction page of the client and checks the transaction state;

step iii.4.1bob sends the transaction to the blockchain network with the client;

step III.4.2Bob continuously checks the global account book of the user until the transaction state is displayed as a completion state at the client;

step iii.4.3bob will trade ID: 000003 to Alice.

Step III.5, verifying the transaction and transmitting the transaction by the blockchain network node;

step iii.5 comprises in particular the following substeps:

step iii.5.1, the node verifies whether account _ Bob and account _ Bob in the transaction are legal, which specifically includes: the node obtains a public key Pk _ RA of the RA from a public channel, and calculates that 1 represents that the identifier is legal (Pk _ RA; account.Pk _ user; account.); then, calculating Verify (Pk _ RA; account _ Bob. Pk _ user _ Bob; account _ Bob. _ Bob) ═ 1 to represent that the _ Bob is legal;

step III.5.2, verifying whether signature information signature1 and signature1 in all input information are legal or not by the node;

step iii.5.2 again comprises the following sub-steps:

step III.5.2.1, the node extracts public key information required by signature verification from an account corresponding to input information of transaction;

transaction signature verification process: v ═ Verify (Pk _ RA; signature);

the node calculates the following contents according to pre _ txhash and pre _ sn _ df parameters in the transaction input information:

v 0＝Verify(Pk_user_Bob_1；signature1)；

v 1＝Verify(Pk_user_Bob_2；signature2)；

v 0-v 1-1, the transaction signature verification is passed;

step iii.5.3 node calculates the total amount of all inputs to the transaction: 120+80 equals 200, the input total amount equals 200, the transaction amount is verified

Step III.5.4, the node compares the format of the received transaction with the specified format, and the format of the transaction received by the node is consistent with the specified format;

step III.6, the node rebroadcasts the transaction to the neighbor node of the node;

step III.7, the miner node digs the mine and writes the transaction into a global account book;

step III.7.1 the miner node verifies the transaction;

step III.7.2, the miner node completes the calculation problem of the consensus mechanism and writes the transaction into a global account book; wherein, the transaction is written into the global account book, and the transaction becomes a completion state;

step III.7.3 after step III.7.2, the global ledger changes;

step IV, Alice inquires about the transaction and provides service;

step IV.1Alice client-side synchronizes the data of the global account book;

the Alice client synchronizes the global account book according to the inquiry request mode;

step IV.1.1Alice client adds block chain network;

step iv.1.2alice client inquires about the neighbor node of its latest Block number Cur _ Net _ Block _ ID 9876;

step iv.1.3alice client compares the latest Block number Local _ Block _ ID 9870 stored in its Local global book with the size Cur _ Net _ Block _ ID 9876, which is greater than Local _ Block _ ID 9870, indicating that the global book in the blockchain network changes, and the payer client requests the neighbor node for Block data from 9871 to 9876; the neighbor node sends the requested data to the payer client;

step V, Alice verifies the transaction and provides service;

step v.1alice enters at the client the transaction ID received at step 2.4.3: 000003, inquiring the specific content and state of the transaction;

v.2alice checks whether the transaction 000003 contains its own legitimate account (Pk _ user);

V.3Alice checks the amount of the transaction 200 through the client;

v.4, the Alice passes the verification, the power transmission service is provided for the Bob, and the power is transmitted for 40 degrees;

eight, other technical details helpful for understanding the present application

https://baike.baidu.com/item/V2G/9556389？fr＝aladdinBaidu encyclopedia: V2Ghttps://baike.baidu.com/item/％E5％8C％BA％E5％9D％97％E9％93％BE/ 13465666？fr＝aladdinBaidu encyclopedia: block chain

http://baike.baidu.com/link？url＝DDK6rhEtYMSxNRDCg5AE8UI7sA9uxT3m6fG h6foddi_XctIvBf4ofMSRXd62CnST7x7JYxE2c4fL-4unFMAgOIgURmnkKDECpRTumZ5iEo6Pz78 yK8MeXQPfExdbp3cTBaidu encyclopedia: biken coin

https://baike.baidu.com/item/％E8％B6％85％E7％BA％A7％E8％B4％A6％ E6％9C％AC/17262292？fr＝aladdinBaidu encyclopedia: super account bookhttps://zh.wikipedia.org/zh- hans/％E6％8C％96％E7％A4％A6_(％E6％AF％94％E7％89％B9％E5％B9％A3)Wikipedia: ore digging

In summary, the above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. The utility model provides an intelligent electric automobile electric wire netting safety payment method based on block chain which characterized in that: the method comprises the following steps:

wherein, the asymmetric encryption algorithm adopts RSA and ECC algorithms;

the identity information of the user refers to the information of an identity card or a driving license;

the RA in step 1.2 is signed, specifically: after the RA checks the identity information, the private key Sk _ RA of the RA is used for signing the Pk _ user of the user, and the signature (Sk _ RA; Pk _ user) is output;

wherein Sign is a signature function in an ECDSA digital signature mechanism and is obtained from an OPENSL password library;

step 1.3, the signature information output in step 1.2 is sent to a user;

step 1.5, the user uses the Pk _ user and synthesizes a legal account;

wherein the payer is a user of the payment during the transaction;

wherein, Verify is a verification function in an ECDSA digital signature mechanism and is obtained from an OPENSL code library; pk _ RA is a public key of RA, RA is responsible for publishing the parameter in a public way, and any user can obtain Pk _ RA from a public channel; the account.Pk _ user is a public key of the account to be verified, and any user can directly obtain the account.Pk _ user from the account; the account is the signature of the account to be verified, and any user can directly obtain the account from the account;

when the output v is 1, the signature is legal, and jumping to the step 2;

step 2: paying the electricity fee;

the legal account is RA generated in (Pk _ user) and is RA verified;

the account in step 2 is that account is either generated by RA or is forged;

step 2, specifically comprising the following substeps:

wherein the value of Nmax is more than or equal to 1 and less than 5;

wherein, the account is account ═ (Pk _ user);

wherein, the block chain client is simply called as the client;

wherein the price region comprises unit price and total amount;

wherein, signature is Sk _ user (txid, txhash, SF, PF, DF)

SF＝{[sn_sf,pre_txhash,pre_sn_df]；[sn_sf,pre_txhash,pre_sn_df]...}

PF＝{unit price,total amount}

DF＝{[sn_df,account,amount]；[sn_df,account,amount]...}；

Step 2.5 comprises the following substeps:

step 2.6.3 the payer sends the transaction ID to the payee;

step 2.7, verifying the transaction by the network node of the block chain;

step 2.7 again specifically comprises the following substeps:

the node obtains a public key Pk _ RA of RA from a public channel;

wherein, the miner node is a special block chain network node;

step 2.10.1 the miner node verifies the transaction;

step 2.10.3 after step 2.10.2, the global ledger changes;

and step 3: the payer inquires about the transaction and provides service;

step 3.1, the payer client synchronizes the data of the global account book;

step 3.1.1 payer client adds block chain network;

step 3.2, the payee verifies the transaction and provides service;

the specific information includes: the information of a transaction ID txid, a transaction hash value txhash, a source address area, a price area and a destination address area in a transaction format of the transaction;

wherein the service provided by the payee is a service of power transmission;

and 4, step 4: the payee and payer end the transaction.