1.一种基于区块链的智能电动汽车电网安全支付系统，其特征在于：按照功能划分，包括注册模块、支付执行模块和数据共享模块；
其中，注册模块的主要任务是将用户自行生成的账号提交给RA进行验证和注册；
其中，支付执行模块确保付款方能够顺利支付电费，收款方能够验证到账情况；在本方法中，即支付电费用区块链交易实现，因此支付执行模块执行的过程就是一笔区块链交易被写入全局账本的过程；
其中，数据共享模块实现支付数据的共享方式；本方案中所有的合法交易记录都将写入全局账本；区块链系统中全局账本是共享给所有参与者的，因此任意参与者都可以通过运行区块链客户端运维本地全局账本，并与网络中全局账本保持同步；当需要查询特定交易时，只需直接查询本地全局账本即可；
支付系统按照角色划分，包括电动汽车用户、注册机构(RA)和区块链网络；
其中，电动汽车用户指支付系统中的用户包括电动车以及参与交易过程的实体，此实体可以是充电设施，他们既可以作为支付系统中的付款方，也可以作为收款方；
每一个电动汽车用户通过安装区块链客户端来处理交易信息和维护全局账本；大多数现代电动车的计算和通信功能可以满足运行区块链客户端的需求；
其中，注册机构(RA)：RA代表一个获得授权的仲裁机构，负责账号注册和交易记录审计；
RA通过运行一个区块链客户端来维护包含所有交易信息的全局账本；RA还运维一个证书库，证书库中存储了所有合法账号以及对应的身份信息；RA被认为是可信实体，不仅能够查看所有交易记录，还能够获得任意匿名交易记录对应的交易者身份信息；
其中，区块链网络：区块链网络指区块链基础设施，包含相关的通信机制和共识机制；
主要对交易格式和交易验证方法进行改进，其他部分和传统区块链网络类似。
2.一种基于区块链的智能电动汽车电网安全支付方法，其特征在于：包括如下步骤：
步骤1：用户账号注册与验证，具体包括如下子步骤：
步骤1.1用户自行生成账号，具体为：用户使用非对称加密算法生成密钥对(Pk_user；
Sk_user)；
其中，非对称加密算法可以采用RSA及ECC为主的算法；
步骤1.2将步骤1.1用户生成的Pk_user以及用户的身份信息提交给RA进行签名；
其中，用户的身份信息是指身份证或者驾驶证为主的信息；
步骤1.2中的RA进行签名，具体为：RA检查完身份信息后，使用RA的私钥Sk_RA对用户的Pk_user进行签名，输出δ＝Sign(Sk_RA；Pk_user)；
其中，Sign是ECDSA数字签名机制中的签名函数，可以从OPENSSL为主的密码库中获得；
步骤1.3将步骤1.2输出的签名信息δ发送给用户；
步骤1.4RA存储用户信息，具体为：RA在其维护的证书库中保存用户的合法账号和用户的身份信息；
其中，RA的证书库中保存的用户的合法账号的格式具体表示为account＝(Pk_user,δ)；
步骤1.5用户使用Pk_user和δ合成合法账号；
步骤1.6用户进行交易时，付款方验证account是否合法；
其中，付款方是交易过程中的付款的用户；
付款方验证account是否合法具体通过v＝Verify(Pk_RA；account.Pk_user；account.δ)实现；
其中，Verify是ECDSA数字签名机制中的验证函数，可以从OPENSSL为主的密码库中获得；Pk_RA是RA的公钥，RA负责公开发布此参数，任何用户都可以从公开渠道获得Pk_RA；
account.Pk_user是待验证账号的公钥，任何用户都可以从账号(account)中直接获得account.Pk_user；account.δ是待验证账号的签名，任何用户都可以从账号(account)中直接获得account.δ；
当输出的v＝1代表签名是合法的，跳至步骤2；
否则，v不等于1，表明签名无效，账号account属于非法账号，跳至步骤1.1；
其中，步骤1.1到步骤1.6用户一次性向RA申请合法账号，并在使用完之后进行重复申请；
其中，用户一次性向RA申请合法账号的个数大于等于1个；
步骤2：电费支付；
其中，电费支付采用区块链交易实现，因此，电费支付的过程就是一笔区块链交易被写入全局账本的过程，电费支付需要确保付款方能够顺利支付电费，收款方能够验证到账情况，收款方为每次交易生成不同的账号以便隐藏交易规律；收款方是交易过程中的收款的用户；
其中，账号和合法账号都表示为：account＝(Pk_user,δ)；
其中，合法账号是指account＝(Pk_user,δ)中的δ是RA生成的，是经过了RA验证；
其中，步骤2中的账号是指account＝(Pk_user,δ)中的δ要么是RA生成的，否则就是伪造的；
步骤2，具体包括如下子步骤：
步骤2.1初始化发送次数n＝1，并设定最大发送次数Nmax；
其中，Nmax的数值大于等于1小于5；
步骤2.2收款方将账号和电费信息发送给付款方；
其中，账号是account＝(Pk_user,δ)；
其中，电费信息包括单价和总金额；其中，总金额是收款方基于单价计算出来的电费总价格；
步骤2.3付款方接收收款方在步骤2.2发送的账号和电费信息，付款方按照步骤1.6验证收款方的账号是否合法，具体为：
付款方从公开渠道获得RA的公钥Pk_RA，再计算Verify(Pk_RA；account.Pk_user；
account.δ)函数的值，当输出的函数值为1代表签名是合法的，跳至步骤2.5；
否则，输出的函数值不等于为1，表明签名无效，收款方的账号属于非法账号，则付款方拒绝收款方的支付请求，给收款方返回“收款方的账号是非法的”这一消息，跳至步骤2.4；
步骤2.4收款方再将账号和电费信息发送给付款方，将n更新为n+1，并判断n是否大于等于Nmax，根据判断结果决定顺序执行还是跳至步骤1.1，具体为：若n大于等于Nmax，表明已经重新发送了Nmax次，跳至步骤1.1；若n小于Nmax，表明未达到重新发送Nmax次，跳至步骤2.4；
步骤2.5付款方利用区块链客户端创建一笔区块链交易；
其中，区块链客户端简称为客户端；
其中，一笔区块链交易格式包含3部分：源地址区域、价格区域和目的地址区域；
其中，源地址区域包含交易输入信息，源地址中的输入信息不是直接列出付款者的账号，而是指向前一个交易的一个输出信息，被表示为signature>；
其中，交易输入信息的个数的大于等于1个；
其中，sn_sf代表当前输入信息在交易源地址区域中的序号，pre_txhash是前一个交易的txhash，可以通过此哈希值找到当前输入的来源交易，pre_sn_df是指当前输入信息在前一个交易目的地址区域中对应的序号，signature是前一个交易中对应账号所有者的签名；
任意用户都可以通过验证签名的合法性检测当前输入信息是否经过合法授权；
其中，价格区域包含单价和总金额；
其中，单价记录当前交易对应时刻的电力价格，此数据可以被用于分析电价的变化趋势；
其中，总金额代表当前交易一共支付的费用；支付系统进行交易验证过程时，将验证所有的输入金额是否大于或等于总金额；
其中，收款方的账号和收款金额组成交易的输出信息，被表示为；
其中，sn_df代表此输出信息在目的地址区域中的序号，account代表收款方的账号，amount代表收款金额；支付系统要求所有的输出金额之和等于交易输入金额之和；当输入金额之和超过当前交易的电费总金额时，付款方在创建交易时会将自己的一个账号列在目的地址区域，以便接收找零资金；
Signature生成过程表示为：signature＝Sk(tx)；Sk表示付款方在交易源地址区域每个输入account对应的私钥；tx表示交易信息中的所有数据；每一个签名都是付款方用自己的私钥对当前交易的所有元素签名；交易签名过程具体如下所示：
其中，signature＝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]...}；
步骤2.5又具体包括如下子步骤：
步骤2.5.1付款方在客户端中输入步骤2.2接收到的电费信息；
步骤2.5.2付款方在客户端中输入步骤2.2接收到的收款方的账号；
步骤2.5.3付款方客户端自动选择付款方已有的账号作为交易的输入；
步骤2.5.4付款方客户端验证交易所有的输入金额是否大于或等于总金额，并根据判断结果进行相应操作：
2.5.4A当交易所有的输入金额大于或等于总金额，表示交易金额合法，跳至步骤2.6；
2.5.4B否则，交易所有的输入金额小于总金额，表示交易金额不合法；客户端提示付款方“账号金额不足”，跳至步骤2.5；
步骤2.6付款方发送交易并持续检查交易状态；
步骤2.6.1付款方利用客户端发送交易到区块链网络中；
其中，区块链交易进入区块链网络后，将按照区块链数据传播机制泛洪到网络中的所有节点；
步骤2.6.2付款方将持续检查自己的全局账本，直到交易状态在客户端显示为完成状态；其中，完成状态的交易的头部包含1个唯一的交易ID，交易ID表示为：txid，和一个唯一的交易哈希值，交易哈希值表示为：txhash；其中，哈希值用于作为交易的索引值；
步骤2.6.3付款方将交易ID发送给收款方；
步骤2.7区块链网络节点验证交易；
其中，区块链网络节点简称为节点；节点验证内容包括四个方面：验证交易中所有的账号是否合法、交易所有输入信息中的签名信息是否合法、交易的所有输入的总金额是否大于或等于输出总金额和交易格式是否满足规定的格式；
步骤2.7又具体包括如下子步骤：
步骤2.7.1节点验证交易中所有的账号是否合法，具体为：
其中，交易中所有的账号包括输入账号和输出账号，且输入账号的个数大于等于1、输出账号的个数大于等于1；
这里例如收款方账号为：account_payee＝(Pk_user_payee,δ_payee)；付款方账号为：
account_payer＝(Pk_user_payer,δ_payer)；
节点从公开渠道获得RA的公钥Pk_RA；
其中，节点验证收款方账号是否合法：计算Verify(Pk_RA；account_payee.Pk_user_payee；account_payee.δ_payee)的值，当输出的v＝Verify(Pk_RA；account_payee.Pk_user_payee；account_payee.δ_payee)＝1代表账号合法，跳至步骤2.7.2；否则，v不等于1，表明账号无效，账号account_payee属于非法账号，跳至步骤2.8；
其中，节点验证付款方账号是否合法：计算Verify(Pk_RA；account_payer.Pk_user_payer；account_payer.δ_payer)的值，当输出的v＝Verify(Pk_RA；account_payer.Pk_user_payer；account_payer.δ_payer)＝1代表账号合法，跳至步骤2.7.2；否则，v不等于1，表明账号无效，账号account_payer属于非法账号，跳至步骤2.8；
步骤2.7.2节点验证交易所有输入信息中的签名信息是否合法，并根据签名信息合法与否，进行相关操作；节点验证交易所有输入信息中的签名信息是否合法的具体过程为：节点从交易的输入信息对应账号中提取验证签名所需要的公钥信息；
其中，交易签名验证过程：v＝Verify(Pk_RA；signature)实现；
其中，交易的输入信息对应的账号是由输入信息中的pre_txhash和pre_sn_df参数指定；
节点根据签名信息合法与否，进行相关操作，具体为：若签名信息合法，跳至步骤
2.7.3；若签名信息不合法,跳至步骤2.8；
步骤2.7.3节点验证交易的所有输入的总金额是否大于或等于输出总金额，具体过程为：节点计算交易的所有输入的总金额记为Sum_input，节点计算交易输出的总金额Sum_output，节点比较计算结果Sum_input和Sum_output的差值Value_bal；并根据输入的总金额是否大于等于输出总金额的判断结果进行如下操作：
2.7.3A若输入的总金额大于等于输出总金额，跳至步骤2.7.4；
2.7.3B若输入的总金额小于输出总金额，跳至步骤2.8；
步骤2.7.4节点验证交易的交易格式是否合法，并根据交易格式合法与否，进行相关操作；节点验证交易格式是否合法的具体过程为：节点比较收到的交易的格式和规定的格式是否一致；节点根据交易的交易格式是否合法，进行相关操作，具体为：若节点收到的交易的格式和规定的格式一致，表示交易的交易格式合法，跳至步骤2.9；若节点收到的交易的格式和规定的格式不一致交易的交易格式不合法,跳至步骤2.8；
步骤2.8节点直接丢弃此交易，不将此交易转播给节点的邻居节点，跳至步骤4；
步骤2.9节点转播交易给自己的邻居节点；
步骤2.10矿工节点挖矿，并将交易写入全局账本；
其中，矿工节点是一种特殊的区块链网络节点；
步骤2.10.1矿工节点验证交易；
步骤2.10.2矿工节点完成共识机制的计算问题，将交易写入全局账本；其中，交易被写入全局账本，这笔交易就变为完成状态；
步骤2.10.3经过步骤2.10.2后，全局账本变化；
步骤3：付款方查询交易并提供服务；
步骤3.1付款方客户端同步全局账本的数据；
其中，付款方客户端按照询问请求模式同步全局账本；
步骤3.1.1付款方客户端加入区块链网络；
步骤3.1.2付款方客户端向邻居节点询问邻居节点的最新的区块号Cur_Net_Block_ID；
步骤3.1.3付款方客户端比较自己本地全局账本中存储的最新的区块号Local_Block_ID和Cur_Net_Block_ID的大小；并根据Local_Block_ID和Cur_Net_Block_ID的大小，进行相关操作：
3.1.3A如果Cur_Net_Block_ID大于Local_Block_ID，表示区块链网络中全局账本变化，付款方客户端向邻居节点请求从Local_Block_ID+1到Cur_Net_Block_ID的区块数据；
邻居节点向付款方客户端发送请求的数据；
3.1.3B如果Cur_Net_Block_ID小于或等于Local_Block_ID，表示付款方客户端的本地全局账本已经是最新的全局账本；
步骤3.2收款方验证交易并提供服务；
步骤3.2.1收款方在客户端输入在步骤2.6.3接收到的交易ID，查询交易的具体内容和状态；
步骤3.2.2收款方客户端显示所查询交易的具体信息；
具体信息包括：交易的交易ID(txid)、交易哈希值(txhash)、交易格式中源地址区域、价格区域和目的地址区域为主的信息；
步骤3.2.3收款方查看交易中的收款方账号是否是自己持有的账号；若有自己的账号，就查看付款方对这个账号支付了多少金额；跳至步骤3.2.4；若交易中的收款方账号没有自己持有的账号，则拒绝提供服务；
步骤3.2.4收款方根据付款方支付给自己的金额和电费单价，提供对应量的电力传输服务；
其中，收款方提供的服务可以是电力传输为主的服务；
步骤4：收款方和付款方结束交易。