17.以太坊的一些点——2019年12月13日

2019年12月13日10:43:02

1.以太坊介绍

以太坊由俄罗斯开发者 Vitalik Buterin(V神)在2013年创建的,它针对比特币区块链系统缺少图灵完备等缺点,建立了一个可编程、图灵完备的区块链。

以太坊允许任何人通过智能合约在平台上建立和使用去中心化应用 Dapp(Decentralized Application)

1.1 比特币账户与以太坊账户比较

比特币:

比特币中的用户帐户余额是一个抽象概念。——比特币区块链不持有账户余额
用户的帐户余额是每个单独的UTXO的总和(该用户持有相应的私钥)。用户持有的密钥可用于单独签名/花费每个UTXO。

以太坊:

以太坊世界状态能够管理帐户余额。

以太坊是一个基于交易的“状态”机器。在以太坊中,账户余额存储在状态树中,该账户余额每次发生与该账户相关的交易时都会改变。

2.账户

以太坊中包含两类账户:外部账户和合约账户。外部账户和合约账户在以太坊下用同一数据结构表示,

1.外部账户(Externally owned account):

​ 被私钥控制。一个外部账户可以创建交易,来发送消息给另一个外部账户或合约账户,以此来触发转账交易和智能合约的调用、创建。

2.合约账户(Contract account):

​ 被它们的合约代码控制且有代码与之关联。合约账户不可以自己发起一个交易,只能被外部账户调用。

外部账户和合约账户在以太坊下用同一数据结构表示,每个账户包含了4个字段:

  • Balance

  • Nonce

  • Code Hash

  • Storage Hash

image-20191213111006564

3. 交易数据结构

交易是一个序列化的二进制消息,其中包含以下数据:

  • Nonce
  • Gas Limit
  • Gas Price
  • To
  • Value
  • Data
  • v r s
image-20191213111037686

4.以太坊双花问题

1.以太坊协议支持分叉,则万一两个区块同时出块上链得到认可,且这两个区块中存在双花现象。

结论:可能存在这种情况,但最终只会有一笔交易有效

2.在以太坊里面,每个帐户下面也都管理着一个nonce值,这也是一个非常重要的数字。nonce解决了“双花”问题。

以太坊一个地址,就理解为一个帐号,在刚生成地址时,nonce为0,该地址每发送一笔交易,nonce值加1。

这也就是说,查看某地址的nonce值,可以知道该地址已经产生了多少笔链上交易。

3.举例:

A用户当前nonce值为10,然后A在短时间内分别向B, C 发起了2笔转帐交易,那nonce对应的是11,12。

矿工在打包交易的时候,会检查A的nonce值,不管矿工是先接收到12的交易,还是11的交易(网络传输),都一定是先打包nonce值为11的交易,再打包12的交易。

如果矿工先接收到12的交易,但是发现没有11的交易,这时交易会被挂起,一直等11的交易出现。

交易的执行顺序是依据nonce值

image-20191213111105442

4.一笔交易的结构

image-20191213111152286 image-20191213111224779

5.交易分类

1.转账交易

2.创建合约
与普通交易的区别是 to_address 为零, data 为合约二进制代码

3.调用合约
与普通交易的区别是 to_address 为合约地址, data 为合约调用函数名的 hash 值 + 参数二进制值

6.世界状态

6.1 介绍

世界状态是地址到账户状态的映射。

虽然世界状态不保存在区块链上,世界状态也由树来保存数据。世界状态可以被视为随着交易的执行而持续更新的全局状态。

如果你想知道某一账户的余额,或者某智能合约当前的状态,就需要通过查询世界状态树来获取该账户的具体状态信息。

image-20191213121532157 image-20191213121602523 image-20191213121625405

6.2 状态改变

image-20191213121717039

7.Gas和费用

7.1 介绍

费用(fees):
由以太坊网络上的交易而产生的每一次计算,都会产生费用。这个费用是以”gas”来支付。

gas就是用来衡量在一个具体计算和存储中要求的费用单位。
gas price就是你愿意在每个gas上花费Ether的数量,以“gwei”进行衡量。

image-20191213121815474 image-20191213121837586

7.2 举例gas如何消耗

例子:
假设发送者设置 gas limit 为50,000,gas price 为20Gwei。这就表示发送者愿意最多支付50,000*20 Gwei = 1,000,000,000,000,000 Wei = 0.001 Ether来执行此交易。
image-20191213121932500

image-20191213121955169

image-20191213122006783

image-20191213122017184

8.交易流程

8.1 基本流程

1、 发起交易:

指定目标地址和交易金额以及相关的gas/gaslimit发起相关交易,如果目标地址为空,则表示其为一个智能合约的交易。

2、 交易签名:

使用私钥对交易进行签名。
3、 提交交易:

把交易添加到交易池中,类似于比特币。签名验证后,通过一定的规则对池内的交易进行排序(如交易的gas)。

4、 广播交易:EVM执行交易,然后广播到其他节点。

5、 交易打包:POW工作量证明,然后形成新的区块打包交易。

6、 广播区块事件:即提交最终的区块。

image-20191213122110342

8.2 具体细节

8.2.1 发起交易

指定To、value、gasLimit、gasPrice发起相关交易。
如果To(目标地址)为空,则表示其为一个智能合约的交易。

image-20191213122450887

8.2.2 交易签名

1.

以太坊同样采用了比特币的签名算法:椭圆曲线数字签名算法 ECDSA ,选择的特定的椭圆曲线为:secp256k1。

差异化:在签名的格式有所差异

比特币中对签名数据格式采用严格的 DER 编码格式,其签名数据格式如下:

image-20191213122527121

image-20191213122543753

2.

以太坊中对内容签名时,未进行DER格式。

对比比特币签名,以太坊的签名格式是 r+s+v。

r 和 s 是 ECDSA 签名的原始输出,而末尾的一个字节为 recovery id 值,但在以太坊中用v表示,v 值为1或者0。
recovery id 简称 recid,表示从签名中成功恢复出公钥时需要查找的次数。

image-20191213122642454

3.

整个交易签名过程分为五步:

1、创建交易 创建一条Transcation数据

2、序列化数据 根据RLP协议将创建的交易进行序列化处理

3、哈希计算 使用Keccak-256算法计算序列化数据哈希值

4、私钥签名 使用私钥对上一步哈希数据进行数字签名

5、字节拆分 对签名结果进行字节拆分,得出R、S、V。

8.2.3 提交交易

交易签名后就可以提交到交易缓冲池。用户可通过以太坊钱包或者调用以太坊节点API发送交易到一个运行中的以太坊geth节点。

1.查看当前的缓存池里面有没有这笔交易

  1. 对当前的交易进行验证——pool.validateTx(tx, local)
    • 交易大小有没有超过规定大小(32kb)
    • 交易金额不能小于0
    • 交易gas值是否超出当前交易池设定的gaslimit
    • 验证签名
    • 验证给的gas price 必须要大于最低的gas price
    • 验证是否可以取出对应的stat database
    • 当前交易的Nonce一定要比当前这个from的Nonce大
    • 验证交易金额是不是小于当前账户的金额

3.查看当前的pool有没有满,如果满了的话会把金额最低的交易踢出去

4.放入 pending 或者 queue list里面

image-20191213122826647

8.2.4 挖矿流程

image-20191213122856426
1.挖矿工作量证明

以太坊的挖矿过程与比特币几乎是一样的。以太坊的工作量证明算法被称为「Ethash」

Ethash 是 Ethereum 1.0 计划的 PoW 算法。算法基本内容如下:

1、首先根据块信息计算一个种子

2、使用这个种子,计算出一个16MB的cache数据。轻客户端需要存储这份cache.

3、通过cache,计算出一个1GB(初始大小)的数据集(DAG),DAG可以理解为是一个完整的搜索空间,全客户端和矿工需要存储完整的DAG,挖矿过程中需要从DAG中重复的随机抽取数据拿去和其他数据计算mixhash,DAG中每个元素的生成只依赖于cache中的少量数据。每到一个新的纪元DAG会完全不一样,并且它的大小也随时间线性增长。

image-20191213122958817 image-20191213123017364

8.2.5 交易回执

不同于比特币,以太坊作为智能合约平台。每一笔交易作为消息在以太坊虚拟机中执行时,均会获得一个交易回执信息(Receipt)。

image-20191213123100946 image-20191213123113808

END

修改时间点:2019年12月13日12:31:38

原文地址:https://www.cnblogs.com/oneapple/p/12034071.html