以太坊交易签名流程

1. 以太国际空间谁知道怎么玩。EIS币怎么交易

现在我们大家都很关注关于以太坊方面的问题，那么关于以太币怎么交易?我想我们大家应该会很想了解一些内容，那么下面就让我们小编在这里就来为大家好好的介绍一下很多内容关于以太币怎么交易?以太坊的交易最直观解释：从外部账户发送到区块链上的另一个账户的消息和签名的数据包。

包含如下内容：
发送者的签名
接收的地址
转移的数字货币数量等内容
以太坊上的交易都是需要支付费用，和比特币以比特币来支付一定的交易费用不同，以太坊上固定了这个环节，那么这个间接理解是以太坊的一种安全防范错误，防止了大量的无意义的交易，保证一定的安全性，特别是智能合约的创建、执行、调用都需要消耗费用，那么也保证了整个系统的稳定性，防止了一些链上无意义的恶意行为。
交易手续费
以太坊的核心是EVM，以太坊虚拟机，那么在EVM中执行的字节码都是要支付费用。也就是经常看到的Gas、Gas limit、Gas Price这几个概念。
Gas：字面理解就是汽油，以太坊和日常的汽车一样需要Gas才能运行。Gas是一笔交易过程中计算消耗的基本单位。有一个列表可以直观看到在以太坊中操作的Gas消耗量：
操作Gas消耗具体内容
step1执行周期的默认费用。
stop0终止操作是免费的。
suicide0智能合约账户的内部数据存储空间，当合约账户调用suicide()方法时，该值将被置为null。
sha320加解密
sload20在固定的存储器中去获取
sstore100输入到固定的存储器中
balance20账户余额
create100创建合约
call20初始化一个只读调用
memory1扩充内存额外支付的费用
txdata5交易过程中数据或者编码的每一个字节的消耗
transaction500交易费用
contract creation53000homestead中目前从21000调整到53000
所以有些公司或者个人觉得区块链技术去中介化，不需要中心服务器，这种开发模式是比较便宜的，但是事实上区块链的开发不比之前的那些传统软件开发来的便宜。
Gas Price：字面理解汽油价格，这个就像你去加油站，95#汽油今天是什么价格。一个Gas Price就是单价，那么你的交易费用=Gas*Gas Price，然后以以太币来ether来支出。当然你觉得我不想支付费用，你可以设置Gas Price为0，但是选择权在矿工手中，矿工有权选择收纳交易和收取费用，那么最简单的想想很难让一个矿工去接收一个价格很低的交易吧。另外提一句，以太坊默认的Gas Price是1wei。
Gas Limit：字面理解就是Gas的限制，限制是必要的，没有限制就没有约束。这个Gas Limit是有两个意思的。首先针对单个交易，那么这个表示交易的发起者他愿意支付最多是多少Gas，这个交易发起者在发起交易的时候需要设置好。还有一个是针对区块的Gas Limit，一个单独的区块也有Gas的限制。
假设几个场景来说明Gas的使用：
用户设置Gas Limit，那么在交易过程中，如果你的实际消耗的Gas used
用户设置Gas Limit，那么交易过程中，如果你的实际消耗的Gas used > Gas Limit，那么矿工肯定发现你的Gas不足，这个交易就无法执行完成，这个之后会回滚到执行之前的状态，这个时候矿工会收取Gas Price*Gas Limit。
区块的Gas Limit，区块中有一个Gas上限，收纳的交易会出现不同的用户指定的Gas Limit。那么矿工就会根据区块限制的Gas Limit来选择，“合理”选择打包交易。
具体交易
以太坊上交易可以是简单的以太币的转移，同时也可以是智能合约的代码消息。列个表格看下交易的具体内容：
代码内容
from交易发起者的地址、不能为空，源头都没有不合理。
to交易接收者的地址(这个可以为空，空的时候就表示是一个合约的创建)
value转移的以太币数量
data数据字段。这个字段存在的时候表示的是，交易是一个创建或者是一个调用智能合约的交易
Gas Limit字面理解就是Gas的限制，限制是必要的，没有限制就没有约束。这个Gas Limit是有两个意思的。首先针对单个交易，那么这个表示交易的发起者他愿意支付最多是多少Gas，这个交易发起者在发起交易的时候需要设置好。还有一个是针对区块的Gas Limit，一个单独的区块也有Gas的限制。
Gas Price一个Gas Price就是单价，那么你的交易费用=Gas*Gas Price，然后以以太币来ether来支出。以太坊默认的Gas Price是1wei。
nonce用于区别用户发出交易的标识。
hash交易ID，是由上述的信息生成的一个hash值
r、s、v交易签名的三部分，交易发起者的私钥对hash签名生成。
交易分三种类型
转账：简单明了的以太坊上的以太币的转移，就和比特币类似，A向B转移一定数量的以太币。这种交易包含：交易发起者、接收者、value的数量，其余类似Gas Limit、hash、nonce都会默认生成。所以你会看到一段代码：
web3.eth.sendTransaction({ from: "交易发起者地址", to：“交易接收者地址”, value: 数量});
智能合约创建：创建智能合约就是把智能合约部署到区块链上，那么这个时候to是一个空的字段。data字段则是初始化合约的代码。所以看到代码：
web3.eth.sendTransaction({ from: "交易发起者地址", data: "contract binary code"});
智能合约执行：合约创建部署在区块链上，那么执行就是会加上to字段到要智能合约执行的地址，然后data字段来指定调用的方法和参数的传递，所以看到代码：
web3.eth.sendTransaction({ from: "交易发起者地址", to：“合约执行者地址”, data：“调用的方法和参数的传递”});
以上大致就是交易的类型。
交易的确认
和比特币一样，以太坊的交易需要后续区块确认后，节点同步后、才能确认。简单理解就是多挖出一些区块来，通过验证后这一笔交易才算确认，以太坊时常会出现拥堵的情况，所以有时候需要等待确认。
转账、合约交易流转
首先交易发起者A发起一笔转账交易，那么发送的格式如下：
代码具体内容
from交易发起者的地址
to交易接收者的地址
value转移的以太币数量
GasGas的量
Gas PriceGas的单价
data发送给接收者的消息
nonce交易编号
节点验证：以太坊网络中会有节点收到A发送出来的消息，那么会去检查这个消息格式时候有效，然后计算Gas Limit。这个时候回去验证A的以太坊余额，如果余额不足，那么就返回错误，不予处理。一旦A发送的消息通过了节点的验证，那么节点就会把这个交易放到交易存储池中。并广播到区块链网络。
矿工验证：那么写入区块链必须要矿工打包，矿工在接收到A发出的交易，会和其他交易一块打包，普通转账交易打包即可，那么合约调用的交易则需要在矿工本地的EVM上去执行调用的合约代码，代码执行过程中检查Gas的消耗。一旦Gas消耗完了，那么就回滚，如果Gas足够那么返回多余的Gas。并广播到区块链网络。
其余节点：重复节点验证步骤，然后合约也会在本地EVM上执行验证。通过验证后同步区块链。
首先还是发起者A发起一个创建智能合约的交易请求。格式如下：
代码具体内容
from交易发起者的地址
to0
value转移的以太币数量
GasGas的量
Gas PriceGas的单价
data合约代码
nonce交易编号
节点验证：
以太坊网络中会有节点收到A发送出来的消息，检查交易是否有效，格式是否正确，验证交易签名。计算Gas，确定下发起者的地址，然后查询A账户以太币的余额。如果余额不足，那么就返回错误，不予处理。一旦A发送的消息通过了节点的验证，那么节点就会把这个交易放到交易存储池中。并广播到区块链网络。
矿工验证：
矿工将交易打包，那么会根据交易费用和合约代码，来创建合约账户，在账户的空间中部署合约。这里说下合约地址(智能合约账户的地址是有发起者的地址和交易的随机数作为输入，然后通过加密算法生成)。交易确认后会把智能合约的地址返回给A。且广播到区块链网络。
其余节点：
重复节点验证步骤，验证区块，在节点的内存池中更新A的智能合约交易，同步区块链，且智能合约部署在自己本地的区块链中。

2. 以太坊web3.sendRawTransaction离线签名交易

工作中需要复现短地址攻击和the重入攻击，重入攻击可以直接通过eth.sendTransaction和remix来发送交易，但是短地址攻击由于钱包和remix这些都对input做了长度检测，无法通过这些方式来复现，只能通过发离线签名交易来实现。

1.环境依赖：nodejs , keythereum , ethereumjs-common , ethereumjs-tx 。

2.进入Node控制台，获取相应账户私钥。

3.签名交易，进入Node,这里注意nonce问题，需要Nonce是实际可执行的nonce，Nonce不对会发送交易失败,关于如何获取input data网络比较多就不详述了。

4.遇到的坑，网络出来的步骤是有问题的或者过时了，当时是参考的这篇文章， https://www.freebuf.com/articles/blockchain-articles/199903.html
，在控制台通过eth.sendRawTransaction发送签名好的交易，我遇到了这个错误 ** sendRawTransaction invalid sender **

3. 以太坊交易(tx) 分析

更多请参考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相对应的，比如 60 对应就是 operation PUSH1,合约编译后的字节码即为一组的 operation 。

合约部署其实就是实例化一个 contract 对象，并将 data 的值设给 Code属性 。

创建合约的tx中，input字段对应的是合约的字节码，即指令数组。

其中 input 字段对应所要调用的函数签名的前四个字节（771602f7）以及对应的参数（1,2）

其中 input 字段为所要调用的合约函数签名的前四个字节（72a099b7）

关于函数调用，Call会把对应的Code读出来，依次解析，Code中会把所有的public签名的函数标志（4字节）push到栈里。然后依据 input 中需要调用函数的签名标志（前4字节）来匹配 Code， 匹配之后跳转到对应的 opcode 。

4. 【ETH钱包开发03】web3j转账ETH

在之前的文章中，讲解了创建、导出、导入钱包。
【ETH钱包开发01】创建、导出钱包
【ETH钱包开发02】导入钱包

本文主要讲解以太坊转账相关的一些知识。交易分为ETH转账和ERC-20 Token转账，本篇先讲一下ETH转账。

1、解锁账户发起交易。钱包keyStore文件保存在geth节点上，用户发起交易需要解锁账户，适用于中心化的交易所。

2、钱包文件离线签名发起交易。钱包keyStore文件保存在本地，用户使用密码+keystore的方式做离线交易签名来发起交易，适用于dapp，比如钱包。

本文主要讲一下第二种方式，也就是钱包离线签名转账的方式。

交易流程
1、通过keystore加载转账所需的凭证Credentials
2、创建一笔交易RawTransaction
3、使用Credentials对象对交易签名
4、发起交易

注意以下几点：

1、Credentials
这里，我是通过获取私钥的方式来加载 Credentials

还有另外一种方式，通过密码+钱包文件keystore方式来加载 Credentials

2、nonce

nonce是指发起交易的账户下的交易笔数，每一个账户nonce都是从0开始，当nonce为0的交易处理完之后，才会处理nonce为1的交易，并依次加1的交易才会被处理。

可以通过 eth_gettransactioncount 获取nonce

3、gasPrice和gasLimit
交易手续费由gasPrice 和gasLimit来决定，实际花费的交易手续费是 gasUsed * gasPrice 。所有这两个值你可以自定义，也可以使用系统参数获取当前两个值

关于 gas ，你可以参考我之前的一篇文章。
以太坊（ETH）GAS详解

gasPrice和gasLimit影响的是转账的速度，如果gas过低，矿工会最后才打包你的交易。在app中，通常给定一个默认值，并且允许用户自己选择手续费。

如果不需要自定义的话，还有一种方式来获取。获取以太坊网络最新一笔交易的 gasPrice ,转账的话， gasLimit 一般设置为21000就可以了。

Web3j还提供另外一种简单的方式来转账以太币,这种方式的好处是不需要管理nonce，不需要设置gasPrice和gasLimit，会自动获取最新一笔交易的gasPrice，gasLimit 为21000（转账一般设置成这个值就够用了）。

这个问题，我想是很多朋友所关心的吧。但是到目前为止，我还没有看到有讲解这方面的博客。

之前问过一些朋友，他们说可以通过区块号、区块哈希来判断，也可以通过Receipt日志来判断。但是经过我的一番尝试，只有 BlockHash 是可行的，在web3j中根据 blocknumber 和 transactionReceipt 都会报空指针异常。

原因大致是这样的：在发起一笔交易之后，会返回 txHash ，然后我们可以根据这个 txHash 去查询这笔交易相关的信息。但是刚发起交易的时候，由于手续费问题或者以太网络拥堵问题，会导致你的这笔交易还没有被矿工打包进区块，因此一开始是查不到的，通常需要几十秒甚至更长的时间才能获取到结果。我目前的解决方案是轮询的去刷 BlockHash ，一开始的时候 BlockHash 的值为0x00000000000，等到打包成功的时候就不再是0了。

这里我使用的是rxjava的方式去轮询刷的，5s刷新一次。

正常情况下，几十秒内就可以获取到区块信息了。

区块确认数=当前区块高度-交易被打包时的区块高度。

5. 以太坊区块链之Bug --2020/05/19

为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。注意这里的前提条件是相同的地址在相同的节点发送交易。

以下是nonce使用的几条规则：

● 当nonce太小（小于之前已经有交易使用的nonce值），交易会被直接拒绝。

● 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；

● 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。

● 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。

         第一个字段 AccountNonce ，直译就是账户随机数。它是以太坊中很小但也很重要的一个细节。以太坊为每个账户和交易都创建了一个Nonce，当从账户发起交易的时候，当前账户的Nonce值就被作为交易的Nonce。这里，如果是普通账户那么Nonce就是它发出的交易数，如果是合约账户就是从它的创建合约数。

为什么要使用这个Nonce呢？其主要目的就是为了防止重复攻击（Replay Attack）。因为交易都是需要签名的，假定没有Nonce，那么只要交易数据和发起人是确定的，签名就一定是相同的，这样攻击者就能在收到一个交易数据后，重新生成一个完全相同的交易并再次提交，比如A给B发了个交易，因为交易是有签名的，B虽然不能改动这个交易数据，但只要反复提交一模一样的交易数据，就能把A账户的所有资金都转到B手里。

当使用账户Nonce之后，每次发起一个交易，A账户的Nonce值就会增加，当B重新提交时，因为Nonce对不上了，交易就会被拒绝。这样就可以防止重复攻击。当然，事情还没有完，因为还能跨链实施攻击，直到EIP-155引入了chainID，才实现了不同链之间的交易数据不兼容。事实上，Nonce并不能真正防止重复攻击，比如A向B买东西，发起交易T1给B，紧接着又提交另一个交易T2，T2的Gas价格更高、优先级更高将被优先处理，如果恰好T2处理完成后剩余资金已经不足以支付T1，那么T1就会被拒绝。这时如果B已经把东西给了A，那A也就攻击成功了。所以说，就算交易被处理了也还要再等待一定时间，确保生成足够深度的区块，才能保证交易的不可逆。

Price 指的是单位Gas的价格，所谓Gas就是交易的消耗，Price就是单位Gas要消耗多少以太币（Ether），Gas * Price就是处理交易需要消耗多少以太币，它就相当于比特币中的交易手续费。

GasLimit 限定了本次交易允许消耗资源的最高上限，换句话说，以太坊中的交易不可能无限制地消耗资源，这也是以太坊的安全策略之一，防止攻击者恶意占用资源。

Recipient 是交易接收者，它是common.Address指针类型，代表一个地址。这个值也可以是空的，这时在交易执行时，会通过智能合约创建一个地址来完成交易。

Amount 是交易额。这个简单，不用解释。

Payload 比较重要，它是一个字节数组，可以用来作为创建合约的指令数组，这时每个字节都是一个单独的指令；也可以作为数据数组，由合约指令来进行操作。合约由以太坊虚拟机（Ethereum Virtual Machine，EVM）创建并执行。

V、R、S 是交易的签名数据。以太坊当中，交易经过数字签名之后，生成的signature是一个长度65的字节数组，它被截成三段，前32字节被放进R，再32字节放进S，最后1个字节放进V。那么为什么要被截成3段呢？以太坊用的是ECDSA算法，R和S就是ECSDA签名输出，V则是Recovery ID。

R,S,V是交易签名后的值，它们可以被用来生成签名者的公钥；R，S是ECDSA椭圆加密算法的输出值，V是用于恢复结果的ID

6. 【深度知识】区块链之加密原理图示(加密,签名)

先放一张以太坊的架构图：

在学习的过程中主要是采用单个模块了学习了解的，包括P2P,密码学，网络，协议等。直接开始总结：

秘钥分配问题也就是秘钥的传输问题，如果对称秘钥，那么只能在线下进行秘钥的交换。如果在线上传输秘钥，那就有可能被拦截。所以采用非对称加密，两把钥匙，一把私钥自留，一把公钥公开。公钥可以在网上传输。不用线下交易。保证数据的安全性。

如上图，A节点发送数据到B节点，此时采用公钥加密。A节点从自己的公钥中获取到B节点的公钥对明文数据加密，得到密文发送给B节点。而B节点采用自己的私钥解密。

2、无法解决消息篡改。

如上图，A节点采用B的公钥进行加密，然后将密文传输给B节点。B节点拿A节点的公钥将密文解密。

1、由于A的公钥是公开的，一旦网上黑客拦截消息，密文形同虚设。说白了，这种加密方式，只要拦截消息，就都能解开。

2、同样存在无法确定消息来源的问题，和消息篡改的问题。

如上图，A节点在发送数据前，先用B的公钥加密，得到密文1，再用A的私钥对密文1加密得到密文2。而B节点得到密文后，先用A的公钥解密，得到密文1，之后用B的私钥解密得到明文。

1、当网络上拦截到数据密文2时， 由于A的公钥是公开的，故可以用A的公钥对密文2解密，就得到了密文1。所以这样看起来是双重加密，其实最后一层的私钥签名是无效的。一般来讲，我们都希望签名是签在最原始的数据上。如果签名放在后面，由于公钥是公开的，签名就缺乏安全性。

2、存在性能问题，非对称加密本身效率就很低下，还进行了两次加密过程。

如上图，A节点先用A的私钥加密，之后用B的公钥加密。B节点收到消息后，先采用B的私钥解密，然后再利用A的公钥解密。

1、当密文数据2被黑客拦截后，由于密文2只能采用B的私钥解密，而B的私钥只有B节点有，其他人无法机密。故安全性最高。
2、当B节点解密得到密文1后， 只能采用A的公钥来解密。而只有经过A的私钥加密的数据才能用A的公钥解密成功，A的私钥只有A节点有，所以可以确定数据是由A节点传输过来的。

经两次非对称加密，性能问题比较严重。

基于以上篡改数据的问题，我们引入了消息认证。经过消息认证后的加密流程如下：

当A节点发送消息前，先对明文数据做一次散列计算。得到一个摘要, 之后将照耀与原始数据同时发送给B节点。当B节点接收到消息后，对消息解密。解析出其中的散列摘要和原始数据，然后再对原始数据进行一次同样的散列计算得到摘要1, 比较摘要与摘要1。如果相同则未被篡改，如果不同则表示已经被篡改。

在传输过程中，密文2只要被篡改，最后导致的hash与hash1就会产生不同。

无法解决签名问题，也就是双方相互攻击。A对于自己发送的消息始终不承认。比如A对B发送了一条错误消息，导致B有损失。但A抵赖不是自己发送的。

在(三)的过程中，没有办法解决交互双方相互攻击。什么意思呢？ 有可能是因为A发送的消息，对A节点不利，后来A就抵赖这消息不是它发送的。

为了解决这个问题，故引入了签名。这里我们将(二)-4中的加密方式，与消息签名合并设计在一起。

在上图中，我们利用A节点的私钥对其发送的摘要信息进行签名，然后将签名+原文，再利用B的公钥进行加密。而B得到密文后，先用B的私钥解密，然后 对摘要再用A的公钥解密，只有比较两次摘要的内容是否相同。这既避免了防篡改问题，有规避了双方攻击问题。因为A对信息进行了签名，故是无法抵赖的。

为了解决非对称加密数据时的性能问题，故往往采用混合加密。这里就需要引入对称加密，如下图:

在对数据加密时，我们采用了双方共享的对称秘钥来加密。而对称秘钥尽量不要在网络上传输，以免丢失。这里的共享对称秘钥是根据自己的私钥和对方的公钥计算出的，然后适用对称秘钥对数据加密。而对方接收到数据时，也计算出对称秘钥然后对密文解密。

以上这种对称秘钥是不安全的，因为A的私钥和B的公钥一般短期内固定，所以共享对称秘钥也是固定不变的。为了增强安全性，最好的方式是每次交互都生成一个临时的共享对称秘钥。那么如何才能在每次交互过程中生成一个随机的对称秘钥，且不需要传输呢？

那么如何生成随机的共享秘钥进行加密呢？

对于发送方A节点，在每次发送时，都生成一个临时非对称秘钥对，然后根据B节点的公钥 和 临时的非对称私钥 可以计算出一个对称秘钥(KA算法-Key Agreement)。然后利用该对称秘钥对数据进行加密，针对共享秘钥这里的流程如下：

对于B节点，当接收到传输过来的数据时，解析出其中A节点的随机公钥，之后利用A节点的随机公钥 与 B节点自身的私钥 计算出对称秘钥(KA算法)。之后利用对称秘钥机密数据。

对于以上加密方式，其实仍然存在很多问题，比如如何避免重放攻击(在消息中加入 Nonce )，再比如彩虹表(参考 KDF机制解决 )之类的问题。由于时间及能力有限，故暂时忽略。

那么究竟应该采用何种加密呢？

主要还是基于要传输的数据的安全等级来考量。不重要的数据其实做好认证和签名就可以，但是很重要的数据就需要采用安全等级比较高的加密方案了。

密码套件 是一个网络协议的概念。其中主要包括身份认证、加密、消息认证(MAC)、秘钥交换的算法组成。

在整个网络的传输过程中，根据密码套件主要分如下几大类算法：

秘钥交换算法：比如ECDHE、RSA。主要用于客户端和服务端握手时如何进行身份验证。

消息认证算法：比如SHA1、SHA2、SHA3。主要用于消息摘要。

批量加密算法：比如AES, 主要用于加密信息流。

伪随机数算法：例如TLS 1.2的伪随机函数使用MAC算法的散列函数来创建一个 主密钥 ——连接双方共享的一个48字节的私钥。主密钥在创建会话密钥（例如创建MAC）时作为一个熵来源。

在网络中，一次消息的传输一般需要在如下4个阶段分别进行加密，才能保证消息安全、可靠的传输。

握手/网络协商阶段：

在双方进行握手阶段，需要进行链接的协商。主要的加密算法包括RSA、DH、ECDH等

身份认证阶段：

身份认证阶段，需要确定发送的消息的来源来源。主要采用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA签名)等。

消息加密阶段：

消息加密指对发送的信息流进行加密。主要采用的加密方式包括DES、RC4、AES等。

消息身份认证阶段/防篡改阶段：

主要是保证消息在传输过程中确保没有被篡改过。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。

ECC ：Elliptic Curves Cryptography，椭圆曲线密码编码学。是一种根据椭圆上点倍积生成 公钥、私钥的算法。用于生成公私秘钥。

ECDSA ：用于数字签名,是一种数字签名算法。一种有效的数字签名使接收者有理由相信消息是由已知的发送者创建的，从而发送者不能否认已经发送了消息(身份验证和不可否认)，并且消息在运输过程中没有改变。ECDSA签名算法是ECC与DSA的结合，整个签名过程与DSA类似，所不一样的是签名中采取的算法为ECC，最后签名出来的值也是分为r,s。 主要用于身份认证阶段 。

ECDH ：也是基于ECC算法的霍夫曼树秘钥，通过ECDH，双方可以在不共享任何秘密的前提下协商出一个共享秘密，并且是这种共享秘钥是为当前的通信暂时性的随机生成的，通信一旦中断秘钥就消失。 主要用于握手磋商阶段。

ECIES： 是一种集成加密方案,也可称为一种混合加密方案，它提供了对所选择的明文和选择的密码文本攻击的语义安全性。ECIES可以使用不同类型的函数：秘钥协商函数(KA)，秘钥推导函数(KDF)，对称加密方案(ENC)，哈希函数(HASH), H-MAC函数(MAC)。

ECC 是椭圆加密算法，主要讲述了按照公私钥怎么在椭圆上产生，并且不可逆。 ECDSA 则主要是采用ECC算法怎么来做签名， ECDH 则是采用ECC算法怎么生成对称秘钥。以上三者都是对ECC加密算法的应用。而现实场景中，我们往往会采用混合加密(对称加密，非对称加密结合使用，签名技术等一起使用)。 ECIES 就是底层利用ECC算法提供的一套集成(混合)加密方案。其中包括了非对称加密，对称加密和签名的功能。

<meta charset="utf-8">

这个先订条件是为了保证曲线不包含奇点。

所以，随着曲线参数a和b的不断变化，曲线也呈现出了不同的形状。比如:

所有的非对称加密的基本原理基本都是基于一个公式 K = k G。其中K代表公钥，k代表私钥，G代表某一个选取的基点。非对称加密的算法 就是要保证 该公式 不可进行逆运算( 也就是说G/K是无法计算的 )。 *

ECC是如何计算出公私钥呢？这里我按照我自己的理解来描述。

我理解，ECC的核心思想就是：选择曲线上的一个基点G，之后随机在ECC曲线上取一个点k(作为私钥)，然后根据k G计算出我们的公钥K。并且保证公钥K也要在曲线上。*

那么k G怎么计算呢？如何计算k G才能保证最后的结果不可逆呢？这就是ECC算法要解决的。

首先，我们先随便选择一条ECC曲线，a = -3, b = 7 得到如下曲线：

在这个曲线上，我随机选取两个点，这两个点的乘法怎么算呢？我们可以简化下问题，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 5+5+5。 那么我们只要能在曲线上计算出加法，理论上就能算乘法。所以，只要能在这个曲线上进行加法计算，理论上就可以来计算乘法，理论上也就可以计算k*G这种表达式的值。

曲线上两点的加法又怎么算呢？这里ECC为了保证不可逆性，在曲线上自定义了加法体系。

现实中，1+1=2，2+2=4，但在ECC算法里，我们理解的这种加法体系是不可能。故需要自定义一套适用于该曲线的加法体系。

ECC定义，在图形中随机找一条直线，与ECC曲线相交于三个点(也有可能是两个点)，这三点分别是P、Q、R。

那么P+Q+R = 0。其中0 不是坐标轴上的0点，而是ECC中的无穷远点。也就是说定义了无穷远点为0点。

同样，我们就能得出 P+Q = -R。 由于R 与-R是关于X轴对称的，所以我们就能在曲线上找到其坐标。

P+R+Q = 0, 故P+R = -Q , 如上图。

以上就描述了ECC曲线的世界里是如何进行加法运算的。

从上图可看出，直线与曲线只有两个交点，也就是说 直线是曲线的切线。此时P,R 重合了。

也就是P = R, 根据上述ECC的加法体系，P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0

于是乎得到 2 P = -Q (是不是与我们非对称算法的公式 K = k G 越来越近了)。

于是我们得出一个结论，可以算乘法，不过只有在切点的时候才能算乘法，而且只能算2的乘法。

假若 2 可以变成任意个数进行想乘，那么就能代表在ECC曲线里可以进行乘法运算，那么ECC算法就能满足非对称加密算法的要求了。

那么我们是不是可以随机任何一个数的乘法都可以算呢？ 答案是肯定的。 也就是点倍积 计算方式。

选一个随机数 k, 那么k * P等于多少呢？

我们知道在计算机的世界里，所有的都是二进制的，ECC既然能算2的乘法，那么我们可以将随机数k描 述成二进制然后计算。假若k = 151 = 10010111

由于2 P = -Q 所以 这样就计算出了k P。 这就是点倍积算法 。所以在ECC的曲线体系下是可以来计算乘法，那么以为这非对称加密的方式是可行的。

至于为什么这样计算 是不可逆的。这需要大量的推演，我也不了解。但是我觉得可以这样理解：

我们的手表上，一般都有时间刻度。现在如果把1990年01月01日0点0分0秒作为起始点，如果告诉你至起始点为止时间流逝了 整1年，那么我们是可以计算出现在的时间的，也就是能在手表上将时分秒指针应该指向00：00：00。但是反过来，我说现在手表上的时分秒指针指向了00：00：00,你能告诉我至起始点算过了有几年了么？

ECDSA签名算法和其他DSA、RSA基本相似，都是采用私钥签名，公钥验证。只不过算法体系采用的是ECC的算法。交互的双方要采用同一套参数体系。签名原理如下：

在曲线上选取一个无穷远点为基点 G = (x,y)。随机在曲线上取一点k 作为私钥， K = k*G 计算出公钥。

签名过程：

生成随机数R, 计算出RG.

根据随机数R,消息M的HASH值H,以及私钥k, 计算出签名S = (H+kx)/R.

将消息M,RG,S发送给接收方。

签名验证过程：

接收到消息M, RG,S

根据消息计算出HASH值H

根据发送方的公钥K,计算 HG/S + xK/S, 将计算的结果与 RG比较。如果相等则验证成功。

公式推论：

HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG

在介绍原理前，说明一下ECC是满足结合律和交换律的，也就是说A+B+C = A+C+B = (A+C)+B。

这里举一个WIKI上的例子说明如何生成共享秘钥，也可以参考 Alice And Bob 的例子。

Alice 与Bob 要进行通信，双方前提都是基于 同一参数体系的ECC生成的 公钥和私钥。所以有ECC有共同的基点G。

生成秘钥阶段：

Alice 采用公钥算法 KA = ka * G ，生成了公钥KA和私钥ka, 并公开公钥KA。

Bob 采用公钥算法 KB = kb * G ，生成了公钥KB和私钥 kb, 并公开公钥KB。

计算ECDH阶段：

Alice 利用计算公式 Q = ka * KB 计算出一个秘钥Q。

Bob 利用计算公式 Q' = kb * KA 计算出一个秘钥Q'。

共享秘钥验证：

Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'

故 双方分别计算出的共享秘钥不需要进行公开就可采用Q进行加密。我们将Q称为共享秘钥。

在以太坊中，采用的ECIEC的加密套件中的其他内容：

1、其中HASH算法采用的是最安全的SHA3算法 Keccak 。

2、签名算法采用的是 ECDSA

3、认证方式采用的是 H-MAC

4、ECC的参数体系采用了secp256k1, 其他参数体系 参考这里

H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下：

在 以太坊 的 UDP通信时(RPC通信加密方式不同)，则采用了以上的实现方式，并扩展化了。

首先，以太坊的UDP通信的结构如下：

其中，sig是 经过 私钥加密的签名信息。mac是可以理解为整个消息的摘要， ptype是消息的事件类型，data则是经过RLP编码后的传输数据。

其UDP的整个的加密，认证，签名模型如下：

7. 使用Nodejs部署智能合约

实现智能合约的方式很多种，可以用truffle框架来实现，编译，部署。
这里介绍一种简单的使用nodejs来实现，编译，部署的方法。
创建一个nodejs项目，实现一个简单的智能合约。

这个合约实现了一个造币和转币的逻辑。
我们的合约是运行在evm上面的字节码，solidity是静态语言，需要通过编译器生成evm的字节码。

调用 node compile.js ,对BaseToken进行编译，生成字节码。web3中提供了一个部署合约的接口，使用如下，

利用编译生成的abi和bytecode，创建一个合约对象，然后进行发布，等待着异步执行的方法输出合约地址 contractAddress ，这样就完成了部署。不过这种方式有一个问题，就是在发布合约时，你的私钥处于联网状态，
处于安全策略，我们需要尽量避免私钥在联网状态。

以太坊上部署合约是向空地址发送一个附有字节码的签名交易，其中发送者就是这个合约的拥有者。因此我们只需要将合约构建成一笔交易，我们在无网状态下对这笔交易进行签名，然后将签名发送到以太坊网络中。这样能够降低我们私钥被泄漏的风险。
对合约的签名方法如下：

以上对一个合约签名，这里需要注意的问题是，to的地址需要是，空地址。
完成签名之后，我们把这笔交易发送出去就好，最简单的方法就是使用 etherscan的发送Tx的方式 ，一旦发送完成，部署完成，就可以看到合约地址。

8. 如何创建和签署以太坊交易

交易

区块链交易的行为遵循不同的规则集

• 由于公共区块链分布式和无需许可的性质，任何人都可以签署交易并将其广播到网络。

• 根据区块链的不同，交易者将被收取一定的交易费用，交易费用取决于用户的需求而不是交易中资产的价值。

• 区块链交易无需任何中央机构的验证。仅需使用与其区块链相对应的数字签名算法（DSA）使用私钥对其进行签名。

• 一旦一笔交易被签名，广播到网络中并被挖掘到网络中成功的区块中，就无法恢复交易。

以太坊交易结构

• 以太坊交易的数据结构：交易0.1个ETH

  {
  'nonce':'0x00', // 十进制：0
  'gasLimit': '0x5208', //十进制： 21000
  'gasPrice': '0x3b9aca00', //十进制1，000，000，000
  'to': '' ，//发送地址
  'value': '0x16345785d8a0000',//100000000000000000 ，10^17
  'data': '0x', // 空数据的十进制表示
  'chainId': 1 // 区块链网络ID
  }

  这些数据与交易内容无关，与交易的执行方式有关，这是由于在以太坊中发送交易中，您必须定义一些其他参数来告诉矿工如何处理您的交易。交易数据结构有2个属性设计"gas": "gasPrice","gasLimit"。

• "gasPrice": 单位为Gwei, 为 1/1000个eth,表示交易费用

• "gasLimit": 交易允许使用的最大gas费用。

• 这2个值通常由钱包提供商自动填写。

  除此之外还需要指定在哪个以太坊网络上执行交易（chainId）: 1表示以太坊主网。

  在开发时，通常会在本地以及测试网络上进行测试，通过测试网络发放的测试ETH进行交易以避免经济损失。在测试完成后再进入主网交易。

  另外，如果需要提交一些其它数据，可以用"data"和"nonce"作为事务的一部分附加。

  A nonce（仅使用1次的数字）是以太坊网络用于跟踪交易的数值，有助于避免网络中的双重支出以及重放攻击。

以太坊交易签名

以太坊交易会涉及ECDSA算法，以Javascript代码为例，使用流行的ethers.js来调用ECDSA算法进行交易签名。

• const ethers = require('ethers')


• const signer = new ethers.Wallet('钱包地址')



• signer.signTransaction({


• 'nonce':'0x00', // 十进制：0


• 'gasLimit': '0x5208', //十进制： 21000


• 'gasPrice': '0x3b9aca00', //十进制1，000，000，000


• 'to': '' ，//发送地址


• 'value': '0x16345785d8a0000',//100000000000000000 ，10^17


• 'data': '0x', // 空数据的十进制表示


• 'chainId': 1 // 区块链网络ID


• })


• .then(console.log)

可以使用在线使用程序Composer将已签名的交易传递到以太坊网络。这种做法被称为”离线签名“。离线签名对于诸如状态通道之类的应用程序特别有用，这些通道是跟踪两个帐户之间余额的智能合约，并且在提交已签名的交易后就可以转移资金。脱机签名也是去中心化交易所（DEXes）中的一种常见做法。

也可以使用在线钱包通过以太坊账户创建签名验证和广播。

使用Portis，您可以签署交易以与加油站网络（GSN）进行交互。

链乔教育在线旗下学硕创新区块链技术工作站是中国教育部学校规划建设发展中心开展的“智慧学习工场2020-学硕创新工作站 ”唯一获准的“区块链技术专业”试点工作站。专业站立足为学生提供多样化成长路径，推进专业学位研究生产学研结合培养模式改革，构建应用型、复合型人才培养体系。

9. 以太坊钱包Mist多重签名

个人如果钱包中有几个以太币，保管好私钥，做几个备份也没有什么好担心的，但是要是像我这样手握成千上万个币，能不担心吗，哈哈哈。。。

一般大量持币的机构，都会使用多重签名机制来保证币的安全，所谓多重签名就是多于一个人同意交易才生效，为了弄清楚实际过程，来实操一下。

主账户需要多于1个ETH才能新建合约，至少需要3个账户才能完成多重签名钱包

OK，输入完密码后看到钱包正在创建，这里我们设置了发送任意的币都需要至少两个钱包账户同意

耐心等待一会即可看到多重签名钱包创建好了，创建好后也有一个地址，可以像正常转币一样将ETH从其他地址存到多重签名地址，这里我们存入100个，可以看到账户内现有100个ETH，每次转出需要至少2人同意

我们这里创建了多重签名账户的3个管理地址，那么其他的地址需要手动添加改地址到钱包，即可查看或操作此账户了。

选择从多重签名的钱包转出，会有提示，每日超过限额，需要其他一个账户确认

先按正常的流程走吧，输完发起账号的密码，交易历史中会看到区块确认中，当有确认的时候，发现所有多重签名账号的Mist中都多了一个提醒

PS：由于多重签名地址底层使用了以太坊的智能合约，所以每次发起（包括其他人批准）都需要消耗gas，也就是说需要保证管理账号中有足够的ETH才行。

10. 以太坊转账流程

发起:用户在本地的以太坊钱包软件中选择要发送的交易地址(From)、输入目标地址(To)、金额(Value)、是否部署或调用合(Data)、手续费单价(Gasprice)等,确认发送至以太坊节点节点和钱包可以是同一台
广播:节点收到(或自己发起)交易后,会对交易进行验证。验证:交易的签名、发起账号的余额是否能支付转账余额与手续费、Nonce是否为账号已发出的交易数。验证为合法后,将交易加入节点的交易池中交易池中存储着待打包的交
安装以太坊浏览器钱包插件,创建钱包,获取虚拟以太币,进行转账交易。 实验内容 学习 初识以太坊,发送交易 1.学习《初始以太坊,发送交易》,虚拟以太币交易。