以太坊源码分析之一整体流程

⑴ 以太坊是一个什么样的东西怎么开发

以太坊是一种区块链的实现。在以太坊网络中，众多的节点彼此连接，构成了以太坊网络： 以太坊节点软件提供两个核心功能：数据存储、合约代码执行。在每个以太坊全节点中，都保存有完整的区块链数据。以太坊不仅将交易数据保存在链上，编译后 的合约代码同样也保存在链上。以太坊全节点中，同时还提供了一个虚拟机来执行合约代码。以太坊虚拟机 以太坊区块链不仅存储数据和代码，每个节点中还包含一个虚拟机（EVM：Ethereum Virtual Machine）来执行 合约代码 —— 听起来就像计算机操作系统。事实上，这一点是以太坊区别于比特币（Bitcoin）的最核心的一点：虚拟机的存在使区块链迈入了2.0 时代，也让区块链第一次成为应用开发者友好的平台。以上内容来自：以太坊DApp开发入门教程

⑵ 以太坊架构是怎么样的

以太坊最上层的是DApp。它通过Web3.js和智能合约层进行交换。所有的智能合约都运行在EVM（以太坊虚拟机）上，并会用到RPC的调用。在EVM和RPC下面是以太坊的四大核心内容，包括：blockChain, 共识算法，挖矿以及网络层。除了DApp外，其他的所有部分都在以太坊的客户端里，目前最流行的以太坊客户端就是Geth（Go-Ethereum）

⑶ 以太坊技术系列-以太坊数据结构

本篇文章和大家介绍一下以太坊的数据结构，上篇文章我们提到，以太坊为了实现智能合约这一功能，使用了基于账户的模型。我们来看看以太坊中数据结构。

既然是基于账户的模型，我们需要通过账户地址找到账户的状态。就像通过银行卡号可以找到你在银行中的各种信息一样。最简单的想法当然是一个简单的哈希表 key是账户地址 value是账户状态。但这里有个问题解决不了。

轻节点如何校验账户合法性？

上篇我们说过，区块链中有2类节点，全节点和轻节点，轻节点只会存储block header，所以轻节点如何才能校验账号是否合法呢？

这个思路和我们平时用的md5校验一致，我们会对区块内的信息进行hash运算从而得出区块内信息唯一确定的值，区块链所有节点中这个值都是相同的。

在这个过程中我们用到了一种数据结构Merkle Tree（哈希树），我们先看下Merkle Tree（哈希树）的示意图。

上篇文章说到区块链中的链表(哈希链)和我们平时常见链表不同的是将指针从地址改为了hash指，这里也一样，哈希树和二叉树的区别有2个

1.将地址改为了哈希值

2.只有叶子节点存储数据

回到之前的问题轻节点是如何校验1个账户或交易是否是在链上的呢？

整个流程如上图所示

1.轻节点需要判断1个账号是否合法

2.轻节点由于只存储block header，所以拿到1个账号的时候会向全节点发出请求

3.全节点存储了所有账户状态，将账户路径中的需要计算用到的hash值返回给轻节点

4.轻节点本地进行计算根hash值，如果计算结果和自己存储一致则账户合法，不一致则不合法。

那以太坊中的账户信息的数据结构就是这样吗？

直接用这样的数据结构来存储账户信息会有2个问题

查找困难

生成hash值不确定

第1个问题应该比较容易发现，在这个树中寻找1个账号需要的复杂度是O(n),因为没有任何顺序。

第2个问题其实也是因为无序导致的，无序的组合每个节点针对同一批账户生成的hash值不一致，这就导致无法达成共识。

既然2个问题都和顺序有关，那我们类似二叉排序树一样，使用哈希排序树是不是就可以解决问题了呢？

使用排序树后会带来另外1个问题

插入困难

因为要维持树是有序的，很可能带来树结构的很大变动。

以太坊中使用了另外一种数据结构字典树。和哈希树不同，字典树应该是很多地方都有使用。我们简单来看下字典树的结构。

字典树能够较好地解决哈希树的2个缺点1.查找困难 2.生成的hash值不确定以及排序二叉树的1个缺点 插入困难。

但字典树我们可以看到可能树的深度可能由于部分元素导致整棵树深度非常深。

这时我们可以进一步优化，将相同路径进行压缩。这就是压缩字典树。

将哈希树和压缩字典树结合，就可以得到以太坊存储账户的最终数据结构-MPT。

将压缩字典树里面的指针从地址改为指针，并且将数据存储在叶子节点中即可。

介绍完状态树的数据结构，我们接下来讨论1个问题，区块中存储的账户状态是什么样的范围。有2种选择。

只保存当时区块中产生交易的账户状态。

保存全局所有的账户。

我们可以看下这2种方式，无非就是空间和时间的平衡，只保存当前区块产生的交易意味着是做懒加载(需要的时候才去寻找账户)，在区块链中这个代价是非常大的，因为寻找的账户之前从未交易过，这样会遍历整个区块链。另外一种保存全局的账户方式虽然看起来空间消耗较大，但查找快捷，而且空间的问题我们可以通过其他方式优化。所以最终以太坊选择了第2种每个区块都报错全局所有账户的方式。

我们来看下以太坊中是如何保存状态树的。

可以看到以太坊中虽然每个区块都保存了全部账户，但是会将未发生变化的账户状态指向前1个节点，本身只存储发生变化的状态，这样可以较大程度优化空间占用。

介绍完以太坊中比较复杂的状态树后，我们继续来看看以太坊中的另外两棵树，交易树和收据树。

首先介绍一下，为什么需要交易树&收据树。

1.交易树

虽然以太坊是基于账户的模型，但是就像银行不仅会存储银行卡的余额，还会存储卡中的每笔钱怎么来的以及怎么花的。交易树中就存储着当前区块中的包含的所有交易。

2.收据树

由于智能合约的引入增加了不少复杂性，所以以太坊用收据树存储着一些交易操作的额外信息。比如交易过程中执行日志就包含在收据树中方便查询。收据树和交易树是一一对应的。每发生一次交易就会有一次收据。

和状态树不同交易树和收据树只维护当前区块内发生的交易，因为当时区块发生交易时不需要再去查找另外1个交易，也就之前需要可能遍历整个区块链的查找操作了。

由于以太坊中的出块速度较快，我们进行一些查询一些符合条件交易的时候会面临大量数据遍历困难的问题。收据树中引入了布隆过滤器可以帮助我们有效缓解这一困难。

布隆过滤器将大集合中每个元素进行hash运算映射到1个较小的集合，这时再来1个元素要判断是否在大集合的时候，不需要遍历整个大集合，而是去进行hash运算去小集合中寻找是否存在，如果不存在，肯定不在大集合中，如果存在则不能说明任何问题。

如上图所示，布隆过滤器只能证明某1个元素不在集合中，不能证明1个元素在结合中。

以太坊中如果我们要在较多区块中寻找某1个交易，则可以利用布隆过滤器，过滤掉肯定不存在目标交易的区块，然后进入收据树内继续利用布隆过滤器筛选，剩下的才是可能的目标交易的交易，进行一一比对即可。

我们介绍了以太坊的核心数据结构，状态树&交易树&收据树，他们都是使用相同的数据结构-哈希压缩字典树。但状态树是维护1颗全局账户树，交易树和收据树则是维护本区块内的交易或收据。

介绍完数据结构后，后面我们会用几篇文章来介绍以太坊中的一些核心算法，比如共识机制，挖矿算法等。

⑷ [以太坊源码分析][p2p网络07]：同步区块和交易

同步，也就是区块链的数据的同步。这里分为两种同步方式，一是本地区块链与远程节点的区块链进行同步，二是将交易均匀的同步给相邻的节点。

01.同步区块链
02.同步交易
03.总结

ProtocolManager 协议管理中的 go pm.syncer() 协程。

先启动了 fetcher ，辅助同步区块用的。然后等待不同的事件触发不同的同步方式。

同步的过程调用 pm.synchronise 方法来进行。

ProtocolManager 协议管理中的 go pm.txsyncLoop() 协程。

同步交易循环 txsyncLoop 分为三个部分的内容：

发送交易的函数。

挑选函数。

三个监听协程的 case 。

⑸ 以太坊源码分析（一 简介）

以太坊作为目前区块链技术2.0的代表作品，无论是它独创的智能合约以及它本身交易的速度都优于bitcoin，通过看它的白皮书以及一些文章也略微了解了它的一些原理，但是总体还是对它的实现半知半解。
因此就想分析下它的实现源码，再结合白皮书也许可以深入的理解它的实现。

每个包的作用大致为：

以上为个人初步理解，如有不当之处望指正

注：资料查询主要位置 wiki eip

⑹ 以太坊C++源码解析（九）区块头

区块头定义位于libethcore\BlockHeader.h文件中，是一个非常简单的类，我们来看看它包含哪些重要数据：

⑺ 以太坊源码分析--p2p节点发现

节点发现功能主要涉及 Server Table udp 这几个数据结构，它们有独自的事件响应循环，节点发现功能便是它们互相协作完成的。其中，每个以太坊客户端启动后都会在本地运行一个 Server ，并将网络拓扑中相邻的节点视为 Node ，而 Table 是 Node 的容器， udp 则是负责维持底层的连接。下面重点描述它们中重要的字段和事件循环处理的关键部分。

PrivateKey - 本节点的私钥，用于与其他节点建立时的握手协商
Protocols - 支持的所有上层协议
StaticNodes - 预设的静态 Peer ，节点启动时会首先去向它们发起连接，建立邻居关系
newTransport - 下层传输层实现，定义握手过程中的数据加密解密方式，默认的传输层实现是用 newRLPX() 创建的 rlpx ，这不是本文的重点
ntab - 典型实现是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 与其他节点建立连接时的握手信息，包含本地节点的版本号以及支持的上层协议
addpeer － 连接握手完成后，连接过程通过这个通道通知 Server

Server 的监听循环，启动底层监听socket，当收到连接请求时，Accept后调用 setupConn() 开始连接建立过程

Server的主要事件处理和功能实现循环

Node 唯一表示网络上的一个节点

IP - IP地址
UDP/TCP - 连接使用的UDP/TCP端口号
ID - 以太坊网络中唯一标识一个节点，本质上是一个椭圆曲线公钥(PublicKey)，与 Server 的 PrivateKey 对应。一个节点的IP地址不一定是固定的，但ID是唯一的。
sha - 用于节点间的距离计算

Table 主要用来管理与本节点与其他节点的连接的建立更新删除

bucket - 所有 peer 按与本节点的距离远近放在不同的桶(bucket)中，详见之后的 节点维护
refreshReq - 更新 Table 请求通道

Table 的主要事件循环，主要负责控制 refresh 和 revalidate 过程。
refresh.C - 定时(30s)启动Peer刷新过程的定时器
refreshReq - 接收其他线程投递到 Table 的 刷新Peer连接 的通知，当收到该通知时启动更新，详见之后的 更新邻居关系
revalidate.C - 定时重新检查以连接节点的有效性的定时器，详见之后的 探活检测

udp 负责节点间通信的底层消息控制，是 Table 运行的 Kademlia 协议的底层组件

conn - 底层监听端口的连接
addpending － udp 用来接收 pending 的channel。使用场景为：当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复，pending用来记录一次这种还没有到来的回复。举个例子，当我们发送ping包时，总是期待对方回复pong包。这时就可以将构造一个pending结构，其中包含期待接收的pong包的信息以及对应的callback函数，将这个pengding投递到udp的这个channel。 udp 在收到匹配的pong后，执行预设的callback。
gotreply - udp 用来接收其他节点回复的通道，配合上面的addpending，收到回复后，遍历已有的pending链表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一个 Table

udp 的处理循环，负责控制消息的向上递交和收发控制

udp 的底层接受数据包循环，负责接收其他节点的 packet

以太坊使用 Kademlia 分布式路由存储协议来进行网络拓扑维护，了解该协议建议先阅读 易懂分布式 。更权威的资料可以查看 wiki 。总的来说该协议：

源码中由 Table 结构保存所有 bucket ， bucket 结构如下

节点可以在 entries 和 replacements 互相转化，一个 entries 节点如果 Validate 失败，那么它会被原本将一个原本在 replacements 数组的节点替换。

有效性检测就是利用 ping 消息进行探活操作。 Table.loop() 启动了一个定时器（0~10s），定期随机选择一个bucket，向其 entries 中末尾的节点发送 ping 消息，如果对方回应了 pong ，则探活成功。

Table.loop() 会定期（定时器超时）或不定期（收到refreshReq）地进行更新邻居关系（发现新邻居），两者都调用 doRefresh() 方法，该方法对在网络上查找离自身和三个随机节点最近的若干个节点。

Table 的 lookup() 方法用来实现节点查找目标节点，它的实现就是 Kademlia 协议，通过节点间的接力，一步一步接近目标。

当一个节点启动后，它会首先向配置的静态节点发起连接，发起连接的过程称为 Dial ，源码中通过创建 dialTask 跟踪这个过程

dialTask表示一次向其他节点主动发起连接的任务

在 Server 启动时，会调用 newDialState() 根据预配置的 StaticNodes 初始化一批 dialTask ， 并在 Server.run() 方法中，启动这些这些任务。

Dial 过程需要知道目标节点( dest )的IP地址，如果不知道的话，就要先使用 recolve() 解析出目标的IP地址，怎么解析？就是先要用借助 Kademlia 协议在网络中查找目标节点。

当得到目标节点的IP后，下一步便是建立连接，这是通过 dialTask.dial() 建立连接

连接建立的握手过程分为两个阶段，在在 SetupConn() 中实现
第一阶段为 ECDH密钥建立 ：

第二阶段为协议握手,互相交换支持的上层协议

如果两次握手都通过，dialTask将向 Server 的 addpeer 通道发送 peer 的信息

⑻ 以太坊源码go-ethereum怎么运行

以太币（ETH）是以太坊（Ethereum）的一种数字代币，开发者们需要支付以太币（ETH）来支撑应用的运行。以太币和其他数字货币一样，可以在交易平台上进行买卖。
通俗一点说，以太坊是开源平台数字货币和区块链平台，它为开发者提供在区块链上搭建...

⑼ 【深度知识】以太坊数据序列化RLP编码/解码原理

RLP(Recursive Length Prefix)，中文翻译过来叫递归长度前缀编码，它是以太坊序列化所采用的编码方式。RLP主要用于以太坊中数据的网络传输和持久化存储。

对象序列化方法有很多种，常见的像JSON编码，但是JSON有个明显的缺点：编码结果比较大。例如有如下的结构：

变量s序列化的结果是{"name":"icattlecoder","sex":"male"},字符串长度35，实际有效数据是icattlecoder 和male，共计16个字节，我们可以看到JSON的序列化时引入了太多的冗余信息。假设以太坊采用JSON来序列化，那么本来50GB的区块链可能现在就要100GB，当然实际没这么简单。

所以，以太坊需要设计一种结果更小的编码方法。

RLP编码的定义只处理两类数据：一类是字符串（例如字节数组），一类是列表。字符串指的是一串二进制数据，列表是一个嵌套递归的结构，里面可以包含字符串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一个复杂的列表。其他类型的数据需要转成以上的两类，转换的规则不是RLP编码定义的，可以根据自己的规则转换，例如struct可以转成列表，int可以转成二进制（属于字符串一类），以太坊中整数都以大端形式存储。

从RLP编码的名字可以看出它的特点：一个是递归，被编码的数据是递归的结构，编码算法也是递归进行处理的；二是长度前缀，也就是RLP编码都带有一个前缀，这个前缀是跟被编码数据的长度相关的，从下面的编码规则中可以看出这一点。

对于值在[0, 127]之间的单个字节，其编码是其本身。

例1：a的编码是97。

如果byte数组长度l <= 55，编码的结果是数组本身，再加上128+l作为前缀。

例2：空字符串编码是128，即128 = 128 + 0。

例3：abc编码结果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。

如果数组长度大于55， 编码结果第一个是183加数组长度的编码的长度，然后是数组长度的本身的编码，最后是byte数组的编码。

请把上面的规则多读几篇，特别是数组长度的编码的长度。

例4：编码下面这段字符串：

The length of this sentence is more than 55 bytes, I know it because I pre-designed it
这段字符串共86个字节，而86的编码只需要一个字节，那就是它自己，因此，编码的结果如下：

184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三个字节的计算方式如下：

184 = 183 + 1，因为数组长度86编码后仅占用一个字节。
86即数组长度86
84是T的编码
例5：编码一个重复1024次"a"的字符串，其结果为：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian编码为004 0，省略掉前面的零，长度为2，因此185 = 183 + 2。

规则1~3定义了byte数组的编码方案，下面介绍列表的编码规则。在此之前，我们先定义列表长度是指子列表编码后的长度之和。

如果列表长度小于55，编码结果第一位是192加列表长度的编码的长度，然后依次连接各子列表的编码。

注意规则4本身是递归定义的。
例6：["abc", "def"]的编码结果是200 131 97 98 99 131 100 101 102。
其中abc的编码为131 97 98 99,def的编码为131 100 101 102。两个子字符串的编码后总长度是8，因此编码结果第一位计算得出：192 + 8 = 200。

如果列表长度超过55，编码结果第一位是247加列表长度的编码长度，然后是列表长度本身的编码，最后依次连接各子列表的编码。

规则5本身也是递归定义的，和规则3相似。

例7：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的编码结果是:

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前两个字节的计算方式如下：

248 = 247 +1
88 = 86 + 2，在规则3的示例中，长度为86，而在此例中，由于有两个子字符串，每个子字符串本身的长度的编码各占1字节，因此总共占2字节。
第3个字节179依据规则2得出179 = 128 + 51
第55个字节163同样依据规则2得出163 = 128 + 35

例8：最后我们再来看个稍复杂点的例子以加深理解递归长度前缀，

["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
编码结果是：

248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一项字符串abc根据规则2，编码结果为131 97 98 99,长度为4。
列表第二项也是一个列表项：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根据规则5，结果为

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
长度为90，因此，整个列表的编码结果第二位是90 + 4 = 94, 占用1个字节，第一位247 + 1 = 248

以上5条就是RPL的全部编码规则。

各语言在具体实现RLP编码时，首先需要将对像映射成byte数组或列表两种形式。以go语言编码struct为例，会将其映射为列表，例如Student这个对象处理成列表["icattlecoder","male"]

如果编码map类型，可以采用以下列表形式：

[["",""],["",""],["",""]]

解码时，首先根据编码结果第一个字节f的大小，执行以下的规则判断：

1.如果f∈ [0,128),那么它是一个字节本身。

2.如果f∈[128,184)，那么它是一个长度不超过55的byte数组，数组的长度为 l=f-128

3.如果f∈[184,192)，那么它是一个长度超过55的数组，长度本身的编码长度ll=f-183,然后从第二个字节开始读取长度为ll的bytes，按照BigEndian编码成整数l，l即为数组的长度。

4.如果f∈(192,247]，那么它是一个编码后总长度不超过55的列表，列表长度为l=f-192。递归使用规则1~4进行解码。

5.如果f∈(247,256]，那么它是编码后长度大于55的列表，其长度本身的编码长度ll=f-247,然后从第二个字节读取长度为ll的bytes,按BigEndian编码成整数l，l即为子列表长度。然后递归根据解码规则进行解码。

以上解释了什么叫递归长度前缀编码，这个名字本身很好的解释了编码规则。

（1） 以太坊源码学习—RLP编码( https://segmentfault.com/a/1190000011763339 )
（2）简单分析RLP编码原理
( https://blog.csdn.net/itchosen/article/details/78183991 )

⑽ 以太坊交易(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 。