以太坊状态树实现

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

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

既然是基于账户的模型，我们需要通过账户地址找到账户的状态。就像通过银行卡号可以找到你在银行中的各种信息一样。最简单的想法当然是一个简单的哈希表 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颗全局账户树，交易树和收据树则是维护本区块内的交易或收据。

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

2. 以太坊解读——Recursive Length Prefix协议图解(上)

在以太坊中，采用了一种名为Recursive Length Prefix(RLP)的方法对交易、账号、合约等基础的数据结构进行序列化处理，从而实现对链上数据的网络传输和持久化存储。RLP作为最为底层的编码方法，其重要性是不言而喻。因此，网上介绍RLP的文章也不少，但是由于RLP是二进制编码，又涉及到嵌套结构，造成编码过程的可读性较差，在学习中过程中，也一直没有找到完整的、易于理解的说明，总是绕在各种规则之中，且不能"自拔"，着实有点无奈。所以，在本文中，采用图形化的解释和举例的方法，帮助大家理解RLP嵌套等特点、编解码过程等。

和其他的序列化协议不同，RLP只支持两种数据类型：
1）byte数组，可以是二进制数组，当然也可以是字符串；
2）byte数组的数组，也就是列表。并支持列表内的嵌套。
对于其他的数据类型，RLP都不支持，需要用户自己先转化为数组和列表的类型。

从RLP的命名中就可以看出两个关键字：一个是递归Recursive和前缀Prefix。首先，关于递归，也就是嵌套结构，结构上非常接近“树”，在Ethereum WiKi中，更是直接地采用树的items来进行命名，叶子节点(leaf tress)来存储“byte数组”，嵌套的节点就是一个树的分叉(branching trees)。

比如，需要是对如下对象进行RLP的编码，该对象中包含一个字符数组的列表、一个单个字符的字符数组、一个空字符数组。

< <[cat],[dog]>, [0xbf], [] >

将该对象展开为树的结构，就如下图。其中[0xbf]和[]属于字符数组。<[cat], [dog]>属于列表，可以嵌套展开，再根据各个节点，进行编码。然后，对于不同长度的数组和列表，编码的方法略有不同，这个也就是Length Prefix相关的内容，和“编码过程”相关的内容，在第二节进行详细地说明。

关于为什么以太坊需要单独设计一种序列化协议，目前还没有找到官方的描述。但与其他序列化方法相比，RLP协议具有一些直接的优点，比如：

1）在以太坊中，最小货币单位为1 Wei，并且1 ETH = 10^18 Wei，所以在编码中，需要考虑对很大的整数类型的序列化，在RLP中采用去除前导零(leading zero)的大端big-endian方式，可以有效处理大整数；

2）使用了灵活的长度前缀来表示数据的实际长度，并且使用递归的方式能编码相当大的数据；

3）为了实现在链上节点的“共识Consensus”，防止出现数据的不一致，以太坊中并不支持浮点数类型，所以一般的序列化协议也不适用。

编码的过程就是将嵌套结构(nested sequence)的树形结构，添加长度前缀(Length Prefix)后，转化为顺序结构(flat sequence)的过程。添加长度前缀的目的，就是在反序列化时，可以根据长度前缀(Length Prefix)，将(flat sequence)重构出树的结构(nested sequence)。

关于前缀的生成规则，《Ethereum Yellow Paper》[2]给出了非常形式化的数学符号描述，漂亮是非常漂亮，可惜不是人类的语言，非常难于理解和表达。网上大部分文章的写法也是引用了Yellow Paper中的5个文字形式上的描述，把原文和翻译一并给出如下：

将上面这个“长度”Length Prefix的编码规则，通过“决策树”可以图形化的表达如下图。

首先，根据编码的类型，进行分类，分为“字节数组”和“列表”两类；第二，根据不同的长度，编码的长度前缀不同。若待编码对象的长度小于56，就是把长度和“前缀字符”进行求和，占用一个字节。反之，待编码对象的长度大于56，其前缀需要多个字节，第一个字节，求出“长度”所占的字节数，再加上“前缀字符”，比如：长度为56，占用1字节。然后对“长度”进行编码，其实也是一个嵌套的过程。

还是以上文中的例子，该编码对象，已经完成了“树的构建”，然后根据“长度前缀”的原则，对树的各个项目进行长度前缀的计算。

< <[cat],[dog]>, [0xbf], [] >

-对于<[cat],[dog]>属于嵌套数组，需要对内部各项非常进行长度编码的计算
  `对于[cat]，属于字符数组，且长度为3，其对应的长度为0x80+3 = 0x83
  `对于[dog]，属于字符数组，且长度为3，其对应的长度为0x80+3 = 0x83
  `<[cat],[dog]>整体上，其长度前缀为0xc0 + 2(新增的两个子项的长度所占用的字节)+6(待编码字符的长度)=0xC8
- 对于[0xbf], 属于字符数组，且长度为1，其对应的长度为0x80+1 = 0x81
- 对于[dog]，属于字符数组，且长度为3，其对应的长度为0x80+3 = 0x83
- 对于[]，属于字符数组，且长度为0，其对应的长度为0x80+0=0x80
总体上，增加的“长度编码”的字节数为6，加上原来的长度为10，所以整个对象的长度前缀为0xC0+16d=0xD0。所以最后的编码结果为：
D0 C8 83636174 83646F67 81B7 83646F67 80

解码过程将在 《以太坊解读——Recursive Length Prefix协议图解(下)》 一文中，给出图形化的解读说明。

3. 以太坊技术系列-以太坊共识机制

区块链的特点之一是去中心化。也就是节点会分布在各个地方组成分布式系统。各个节点需要对1个问题达成一致，理想情况下，只需要同步状态即可。

如上图所示 B节点将a=1=> a=2的状态同步给  ACDE四个节点，这时系统中状态变为a=2, 但如果其中有恶意节点 AE 收到通知后把a=1=>a=3修改为错误的节点，这个时候大家的状态就不一致了，此时需要共识机制使系统中得到1个唯一正确的状态。

如上面说到分布式系统存在恶意节点导致系统中状态不一致的情况有1个比较著名的虚拟问题-拜占庭将军问题。

拜占庭将军问题是指，N个将军去攻打一座城堡，如果大于一定数量的将军同时进攻则可以攻打成功，如果小于则进攻失败。将军中可能存在叛徒。

这个时候有2种情况

1.如果2个叛徒都在BCDE中，那么共识算法需要让其余2个将军听从A的正确决策进攻城堡。

2.如果A是1个叛徒，共识算法需要让BCDE中剩余的3个忠诚将军保持一致。

这个问题有很多种解法，大家有兴趣可以自行查阅(推荐学习PBFT)，我们重点来看看以太坊中目前正在使用的Nakamoto 共识和将要使用的 Casper Friendly Finality Gadget共识是如何解决拜占庭将军问题的。

说到Nakamoto共识和Casper Friendly Finality Gadget共识可能大家不太熟悉，但他们的部分组成应该都比较熟悉-POW(工作量证明)和POS(权益证明)。

POW或POS称之为Sybil抗性机制，为什么需要Sybil抗性机制呢，刚刚我们说到拜占庭将军问题，应该很容易看出恶意节点越多，达成正确共识的难度也就越大，Sybil攻击就是指1个攻击者可以伪装出大量节点来进行攻击，Sybil抗性是指抵御这种攻击能力。

POW通过让矿工或验证者投入算力，POS通过让验证者质押以太坊，如果攻击者要伪装多个节点攻击则必将投入大量的算力或资产，会导致攻击成本高于收益。在以太坊中保障的安全性是除非攻击者拿到整个系统51%算力或资产否则不可能进攻成功。

在解决完Sybil攻击后，通过选取系统中的最长链作为大家达成共识的链。

很多人平时为了简化将pow和pos认为是共识机制，这不够准确，但也说明了其重要作用，我们接下来分析pow和pos。

通过hash不可逆的特性，要求各个矿工不停地计算出某个值的hash符合某一特征，比如前多少位是000000，由于这个过程只能依赖不停的试错计算hash,所以是工作量证明。计算完成后其他节点验证的值符合hash特征非常容易验证。验证通过则成为成为合法区块(不一定是共识区块，需要在最长链中)。

以太坊中的挖矿算法用到2个数据集，1个小数据集cache,1个大数据集DAG。这2个数据集会随着区块链中区块增多慢慢变大，初始大小cache为16M DAG为1G。

我们先来看这2个数据集的生成过程

cache生成规则为有1个种子随机数seed，cache中第1个元素对seed取hash，后面数组中每个元素都是前1个元素取hash获得。

DAG生成规则为 找到cache中对应的元素后 根据元素中的值计算出下次要寻找的下标，循环256次后获得cache中最终需要的元素值进行hash计算得到DAG中元素的值。

然后我们再看看矿工如何进行挖矿以及轻节点如何验证

矿工挖矿的过程为，选择Nonce值映射到DAG中的1个item，通过item中的值计算出下次要找的下标，循环64次，得到最终item，将item中的值hash计算得到结果，结果和target比较，符合条件

则证明挖到区块，如果不符合则更换nonce继续挖矿。矿工在挖矿过程中需要将1G的DAG读取到内存中。

轻节点验证过程和矿工挖矿过程基本一致，

将块头里面的Nonce值映射到DAG中的1个item，然后通过cache数组计算出该item的值，通过item中的值计算出下次要找的下标，循环64次，得到最终item，将item中的值hash计算得到结果，结果和target比较，符合条件则验证通过。轻节点在验证过程中不需要将1G的DAG读取到内存中。每次用到DAG的item值都使用cache进行计算。

以太坊为什么需要这2个不同大小的数组进行辅助hash运算呢，直接进行hash运算会有什么问题？

如果只是进行重复计算会导致挖矿设备专业化，减少去中心化程度。因为我们日常使用的计算机内存和计算力是都需要的，如果挖矿只需要hash运算，挖矿设备则会设计地拥有超高算力，但对内存可以缩小到很小甚至没有。所以我们选用1G的大内存增加对内存访问的频率，增加挖矿设备对内存访问需求，从而更接近于我们日常使用的计算机。

我们看看在Nakamoto共识是如何解决拜占庭将军问题的。首先看看区块链中的拜占庭将军问题是什么？

区块链中需要达成一致的是哪条链为主链，虽然采用了最长链原则，但由于分叉问题，还是会带来拜占庭将军问题。

本来以太坊pow目标是抵抗51%以下的攻击，但如上图如果恶意节点沿着自己挖出的区块不断挖矿，由于主链上有分叉存在，恶意节点不需要达到51%算力就可以超过主链进而成为新的主链，为此以太坊使用了ghost协议给上图中的B1和C1也分配出块奖励，尽快合并到主链中，这样主链长度(按照合并后的总长度算，长度只是抽象概念，以太坊中按照区块权重累加)还是大于恶意节点自己挖矿的。

网络中的用户通过质押一定数量的以太坊成为验证者。每次系统从这些验证者从随机选择出区块创建者，其余验证者去验证创建出的区块是否合法。验证者会获得出块奖励，没有被选中的区块不进行验证则会被扣除一定质押币，如果进行错误验证则会被扣除全部质押币。

如上图，权益证明在每隔一定区块的地方设置一个检查点，对前面的区块进行验证，2/3验证者通过则验证通过，验证通过则该区块所在链成为最长合法链(不能被回滚)。

我们简化地只分析了权益证明本身，在以太坊中权益证明较为复杂的点在于和分片机制结合在一起时的运行流程，这部分会在后面单独将分片机制的一篇文章中详述。

本篇文章主要讨论了共识机制是解决分布式系统中的拜占庭将军问题，以及分析了以太坊中的共识机制一般包括最长链选择和一种sybil抗性机制(pow或pos)。重点分析了pow和pos的流程以及设计思想。后续将开始重点讨论智能合约的部分。

4. 区块链和智能合约，以太坊开发，183位开发者整理，知识体系汇总

在以太坊上开发应用程序的可用工具、组件、模式和平台的指南。

此列表的创建是由 ConsenSys 的产品经理推动的，他们认为需要在新的和有经验的区块链开发人员之间更好地共享工具、开发模式和组件。

开发智能合约

智能合约语言

构架

IDE

其他工具

测试区块链网络

测试以太水龙头

前端以太坊 API

后端以太坊 API

引导程序/开箱即用工具

以太坊 ABI（应用程序二进制接口）工具

以太坊客户端

贮存

Mahuta - 具有附加搜索功能的 IPFS 存储服务，以前称为 IPFS-Store

OrbitDB - IPFS 之上的去中心化数据库

JS IPFS API - IPFS HTTP API 的客户端库，用 JavaScript 实现

TEMPORAL - 易于使用的 API 到 IPFS 和其他分布式/去中心化存储协议

PINATA - 使用 IPFS 的最简单方法

消息传递

测试工具

安全工具

监控

其他杂项工具

Cheshire - CryptoKitties API 和智能合约的本地沙箱实现，可作为 Truffle Box 使用

ERCs-以太坊评论请求存储库

ERC-20 - 可替代资产的原始令牌合约

ERC-721 - 不可替代资产的令牌标准

ERC-777 - 可替代资产的改进令牌标准

ERC-918 - 可开采令牌标准

流行的智能合约库

可扩展性

支付/状态通道

等离子体

侧链

POA桥

POA 桥用户界面

POA 桥梁合同

ZK-SNARK

ZK-STARK

预构建的 UI 组件

以上内容，来自git库：

github.com/ConsenSys/ethereum-developer-tools-list

我是鱼歌，一个在深圳创业的全栈程序员，主攻区块链，元宇宙和智能合约，附加小程序和app开发。

[祈祷]

5. 什么是状态树

状态树
是运用状态机进行开发的有利助手，状态树位于Visual C++的Workspace Tab窗口。在开发过程中，它能够提供一个状态机代码自动生成框架，帮您轻松地完成诸如“新建一个状态机应用”、“新建一个状态”、“定义状态的入口/出口函数”以及“定义事件处理函数”这些重复性的工作。在调试期，您还可以在状态树中获得跟踪功能支持

6. 什么是以太坊（Ethereum）imToken支持符合ERC20代币

以太坊（Ethereum）是一个开源的有智能合约功能的公共区块链平台。通过其专用加密货币以太币（Ether，又称“以太币”）提供去中心化的虚拟机（称为“以太虚拟机”Ethereum Virtual Machine）来处理点对点合约。以太坊的概念首次在2013至2014年间由程序员Vitalik Buterin受比特币启发后提出，大意为“下一代加密货币与去中心化应用平台”，在2014年通过ICO众筹得以开始发展。
以太坊不仅是一个数据库，它还允许你在区块链的可信环境中运行程序。以太坊在区块链上搭建了一个名为 EVM（Ethereum Virtual Machine，以太坊虚拟机）的虚拟机。EVM 允许在区块链上验证和执行代码，为代码在每个人的机器上以相同方式运行提供保障。这些代码包含在智能合约中。除了追踪账户余额，以太坊使用相同方法将 EVM 的状态保存在区块链上。所有节点处理智能合约，来验证合约本身及其输出的完整性。

7. 状态管理（1）- Rex

应用的整体全局状态以对象树的方式存放于单个store。唯一改变状态树（state tree）的方法是创建action， 一个描述发生了什么的对象，并将其dispatch给store。要指定状态树如何响应action来进行更新，你可以编写recer函数，这些函数根据旧的action来计算新state。

上面这段摘抄自官网，个人认为是比较通俗的概括了rex的使用方法，你或许还没有很理解它，继续往下看，相信你会有所收获

一个简单的例子，带你熟悉rex

‘默认值’ 存在state里，我们点击按钮之后，改变改值

使用脚手架创建应用，安装依赖

安装rex

编写ui

添加home组件

创建action：
在根目录下创建action文件夹，在action文件下创建index.js
这里我们定义一个action的构建函数，让他返回action对象

action 可以理解为表示即将放生的变化类别，它是一个普通的对象，必须包含type属性，这里我们添加我们需要的value属性，作为传递的数据

创建Recer：
在根目录下新建recer文件夹，在recer文件夹下新建index.js 文件
本质就是函数，用于响应发送过来的action，函数接受两个参数，第一个是初始化state，第二个是发送过来的action
这里我们将默认的state也放到recer 文件中Object.assign({},state,action);
如果action的type为send_type 则返回， 不要忘记将recer暴露出去

创建store
store是用来把action和recer关联到一起的， 我们通过createStore来构建store，通过subscribe来注册监，通过dispatch来发送action。
store.dispatch() 并传入一个action对象，store将执行所有recer函数并计算出更新后的state，调用getState()可以获取新state
dispatch一个action可以形象的理解为“出发一个事件”，发生了一些事情，我们希望store知道这件事。Recer就像事件监听器一样，当它们收到关注的action后，它就会更新state作为响应

这里是最难理解的地方，你可以认为store的dispatch方法才是最终告知要执行action的动作了，你这个动作具体做了什么需要recer来处理

根目录下创建store文件夹，在store文件夹下创建index.js
同样的将store暴露出去

action、recer、store 都写好了，现在我们将这个rex用到组件中
我们通过store的subscribe来注册监，通过dispatch来发送action
组件一加载完成就注册监听
Home组件

store.getState()获取当前state

8. 以太坊架构是怎么样的

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

9. 【以太坊易错概念】nonce, 公私钥和地址，BASE64/BASE58,

以太坊里的nonce有两种意思，一个是proof of work nonce，一个是account nonce。

在智能合约里，nonce的值代表的是该合约创建的合约数量。只有当一个合约创建另一个合约的时候才会增加nonce的值。但是当一个合约调用另一个合约中的method时 nonce的值是不变的。
在以太坊中nonce的值可以这样来获取（其实也就是属于一个账户的交易数量）：

但是这个方法只能获取交易once的值。目前是没有内置方法来访问contract中的nonce值的

通过椭圆曲线算法生成钥匙对（公钥和私钥），以太坊采用的是secp256k1曲线,
公钥采用uncompressed模式，生成的私钥为长度32字节的16进制字串，公钥为长度64的公钥字串。公钥04开头。
把公钥去掉04，剩下的进行keccak-256的哈希，得到长度64字节的16进制字串，丢掉前面24个，拿后40个，再加上"0x"，即为以太坊地址。

整个过程可以归纳为：

2）有些网关或系统只能使用ASCII字符。Base64就是用来将非ASCII字符的数据转换成ASCII字符的一种方法，而且base64特别适合在http，mime协议下快速传输数据。Base64使用【字母azAZ数字09和+/】这64个字符编码。原理是将3个字节转换成4个字节(3 X 8) = 24 = (4 X 6)
当剩下的字符数量不足3个字节时，则应使用0进行填充，相应的，输出字符则使用'='占位，因此编码后输出的文本末尾可能会出现1至2个'='。

1）Base58是用于Bitcoin中使用的一种独特的编码方式，主要用于产生Bitcoin的钱包地址。相比Base64，Base58不使用数字"0"，字母大写"O"，字母大写"I"，和字母小写"l"，以及"+"和"/"符号。

Base58Check是一种常用在比特币中的Base58编码格式，增加了错误校验码来检查数据在转录中出现的错误。 校验码长4个字节，添加到需要编码的数据之后。校验码是从需要编码的数据的哈希值中得到的，所以可以用来检测并避免转录和输入中产生的错误。使用 Base58check编码格式时，编码软件会计算原始数据的校验码并和结果数据中自带的校验码进行对比。二者不匹配则表明有错误产生，那么这个 Base58Check格式的数据就是无效的。例如，一个错误比特币地址就不会被钱包认为是有效的地址，否则这种错误会造成资金的丢失。

为了使用Base58Check编码格式对数据（数字）进行编码，首先我们要对数据添加一个称作“版本字节”的前缀，这个前缀用来明确需要编码的数 据的类型。例如，比特币地址的前缀是0（十六进制是0x00），而对私钥编码时前缀是128（十六进制是0x80）。 表4-1会列出一些常见版本的前缀。

接下来，我们计算“双哈希”校验码，意味着要对之前的结果（前缀和数据）运行两次SHA256哈希算法：

checksum = SHA256(SHA256(prefix+data))
在产生的长32个字节的哈希值（两次哈希运算）中，我们只取前4个字节。这4个字节就作为校验码。校验码会添加到数据之后。

结果由三部分组成：前缀、数据和校验码。这个结果采用之前描述的Base58字母表编码。下图描述了Base58Check编码的过程。

相同:

1） 哈希算法、Merkle树、公钥密码算法
https://blog.csdn.net/s_lisheng/article/details/77937202?from=singlemessage

2）全新的 SHA-3 加密标准 —— Keccak
https://blog.csdn.net/renq_654321/article/details/79797428

3）在线加密算法
http://tools.jb51.net/password/hash_md5_sha

4）比特币地址生成算法详解
https://www.cnblogs.com/zhaoweiwei/p/address.html

5）Base58Check编码实现示例
https://blog.csdn.net/QQ604666459/article/details/82419527

6） 比特币交易中的签名与验证
https://www.jianshu.com/p/a21b7d72532f

10. 以太坊是如何挖矿的

以太坊的代币是通过采矿过程中产生的，每块采矿率为 5 个以太币。以太坊的采矿过程几乎与比特币相同，对于每一笔交易，矿工都可以使用计算机通过散列函数运行该块的唯一标题元数据，反复，快速地猜出答案，直到其中一人获胜。

许多新用户认为，采矿的唯一目的是以不需要中央发行人的方式生成醚（参见我们的指南“ 什么是以太？ ”）。这是真的。以太坊的代币是通过采矿过程中产生的，每块采矿率为 5 个以太币。但是，采矿还有至少同样重要的作用。通常，银行负责保持交易的准确记录。他们确保资金不是凭空创造的，用户不会多次欺骗和花钱。不过，区块链引入了一种全新的记录保存方式，整个网络而不是中介，验证交易并将其添加到公共分类账。

Ethereum Mining

尽管“无信任”或“信任最小化”货币体系是目标，但仍有人需要确保财务记录的安全，确保没有人作弊。采矿是使分散记录成为可能的创新之一。矿工们在防止欺诈行为（特别是醚的双重支出）方面达成了关于交易历史的共识 – 这是一个有趣的问题，在分散化的货币未在工作区块链之前解决。虽然以太坊正在研究其他方法来就交易的有效性达成共识，但采矿目前将平台保持在一起。

挖矿如何工作
今天，以太坊的采矿过程几乎与比特币相同。对于每一笔交易，矿工都可以使用计算机反复，快速地猜出答案，直到其中一人获胜。更具体地说，矿工将通过散列函数（它将返回一个固定长度，乱序的数字和字母串，它看起来是随机的）运行该块的唯一标题元数据（包括时间戳和软件版本），只改变’nonce 值’ ，这会影响结果散列值。

如果矿工发现与当前目标相匹配的散列，矿工将被授予乙醚并在整个网络上广播该块，以便每个节点验证并添加到他们自己的分类账副本中。如果矿工 B 找到散列，矿工 A 将停止对当前块的工作，并为下一个块重复该过程。矿工很难在这场比赛中作弊。没有办法伪造这项工作，并拿出正确的谜题答案。这就是为什么解谜方法被称为“工作证明”。

另一方面，其他人几乎没有时间验证散列值是否正确，这正是每个节点所做的。大约每 12-15 秒，一名矿工发现一块石块。如果矿工开始比这更快或更慢地解决谜题，算法会自动重新调整问题的难度，以便矿工回弹到大约 12 秒钟的解决时间。

矿工们随机赚取这些乙醚，他们的盈利能力取决于运气和他们投入的计算能力。以太坊使用的具体工作量验证算法被称为’ethash’，旨在需要更多的内存，使得使用昂贵的 ASIC 难以开采 – 特殊的采矿芯片，现在是唯一可以盈利的比特币开采方式。

从某种意义上讲，ethash 可能已经成功实现了这一目的，因为专用 ASIC 不可用于以太坊（至少目前还没有）。此外，由于以太坊旨在从工作证明挖掘转变为“股权证明”（我们将在下面讨论），购买 ASIC 可能不是一个明智的选择，因为它可能无法长久证明有用。

转移到股权证明
不过，以太坊可能永远不需要矿工。开发人员计划放弃工作证明，即网络当前使用的算法来确定哪些交易是有效的，并保护其免受篡改，以支持股权证明，网络由代币所有者担保。如果并且当该算法推出时，股权证明可以成为实现分布式共识的一种手段，而该共识使用更少的资源。