以太坊源码机制：微信h5斗牛网站维护挖矿

联系方式：QQ：2747044651 网址
拜占庭将军问题
分布式系统的状态同步问题。

拜占庭帝国繁荣富饶，周边的几个小国家的将军对其垂涎已久但又各自心怀鬼胎。他们必须有超过一半以上的将军同意进攻拜占庭并且不能在战场上做出背叛的动作（达成共识），否则就会进攻失败，引火烧身。而将军的领土有可能被其他几个将军瓜分。基于这种情况，将军们之间的沟通很成问题，有的人口是心非，有的人是忠诚为了组织的利益。如何能最终达成共识，这是个问题。

分布式系统中的每个结点就是将军，这些结点要同步状态时，就会面临拜占庭将军问题。如何有效避免结点发出的错误信息对结果造成的影响？

POW(Proof Of Work)
工作量证明，顾名思义，就是证明你做了多少工作。POW是目前最流行的解决上面拜占庭将军问题的共识算法，比特币、以太坊等主流区块链数字货币都是基POW。

要想解决拜占庭将军问题，需要先确定一个方法：就是在这些平等的将军中间选拔出来一个忠诚的“大将军”，其他将军听他的决定即可。

这似乎违反了去中心化的思想，但我们仔细分析可得，这些将军在做这次决定之前都是去中心化的平等的结点，而选拔出来的大将军只是针对这一次决定，下一次决定还会再次选拔。而不是中心化的固定了一位大将军，以后几十年的朝堂内外都要听他一人的命令。

搞清楚了这个问题以后，下面要解决的就是如何选拔大将军的问题。决定之前，这些将军都是平等结点，所以要通过他们在本次决定时的发言来判断。将军们通过已知战场情报，各自估量当前战场形势，进行计算，有了结论（出块）以后广播给其他将军。同时该将军还要始终监听来自其他将军的广播内容，一旦接收到来自其他将军的结论广播，将军们会立即停止手中的计算，来验证广播的内容，如果所有将军都验证通过，那么第一个发出这个可验证通过结果广播的将军就被选拔为大将军，本次决定听他的结论（已经包含在广播中的结果内容）。

所以这个过程中比较重要的因素有两点：

首先是速度，第一个通过验证的才能被选拔为大将军，慢一步的第二个没有任何机会。
然后是正确性，即将军发出的结论是否正确，可被其他将军验证成功。
速度问题是计算能力的问题，例如我的电脑是8核32G配置，计算能力肯定比你单核1G内存的快，这个与POW算法关系不大。而POW算法是用来解决正确性的方案，POW提供了一种难于计算易于验证的方式，这是基于哈希函数的特性实现的，前面文章也有介绍过，哈希函数是

免碰撞的
逆向困难的
如果想求得特定范围的加密值，只能通过穷举法
通过这些特性，工作量证明可以发布给各结点一个哈希加密函数，各结点将待封印区块信息通过该函数再加上一个nonce值计算得到一个加密哈希，这个加密哈希需要满足一定的规则（例如前四位必须是1111），各结点只能通过穷举法来不断尝试，直到满足条件以后，即得出结论，也即出块成功，这时候再将区块哈希广播出去，其他结点一验证，的确满足预定规则（前四位的确是1111），则完成共识，该块由刚才广播的结点出块。这个工作量指的就是结点在不断尝试计算的工作量，得到符合条件的区块哈希以后，经过广播，其他结点手头正在进行的以及已经完成的工作量作废（其实这也是一种算力浪费），该块被证明为由你出块。

问题1：筛选块
就是当你广播时，其他某个结点也算出来符合条件的哈希值了，即该结点也出了编号相同的一个区块，此时就要对比两个块的时间戳，时间较早的会被确认，保留到链上，而另一个较晚的则会被抛弃。

问题2：分叉链
当某个结点发布了新的共识规则，其他结点并未同步该共识规则，一般来讲新的共识规则是向前兼容的，即链上前面的数据仍然是有效的被承认的，但未同步新规则的结点会继续挖矿，他们挖出的块不会被更新新规则的结点共识或者承认。这个时候，链就分叉了，分为1.0（旧共识规则）和2.0（新共识规则）两条链。此时有更多群众（矿工）基础的链会留下来。

例如这个公链是我们公司发布的，我们会去拉动更多客户进来，但其实作为发布者，我和这些客户的结点都是平等的，此时某个陌生结点只要加入进来，它也可以发布新规则，而作为发布者的我们也要更新我们的软件，所以社区就非常重要了，通过社区，我们可以维护着我们客户的支持与信任，当我们发布新规则时会得到他们的支持。由于区块链本身的开源、去中心化的属性，我们的公链一旦发布，就不属于我们了，而是属于每一个参与进来的结点，而我们只能通过确切地办实事，解决问题，才会得到客户矿工们的认可才能保障这条链的优秀竞争力（当然了，作为发布者的我们拥有了大量的预购币，所以为了链的发展，影响力的扩大，币的升值，我们的动力更加强劲）。

不过也有一种情况，就是原来1.0的链还有一部分人再使用，但我要说的是，他们那条链的生命力肯定不行了，因为没有利益相关者，大家不会免费付出。区块链技术是平等公平的，没有得到大家也就不会付出。

miner源码分析
下面采用代码调试的顺序，来分析以太坊miner.go文件源码内容。整个以太坊挖矿相关的操作都是通过Miner结构体暴露出来的方法：

type Miner struct {
mux *event.TypeMux // 事件锁，已被feed.mu.lock替代
worker *worker // 干活的人
coinbase common.Address // 结点地址
mining int32 // 代表挖矿进行中的状态
eth Backend // Backend对象，Backend是一个自定义接口封装了所有挖矿所需方法。
engine consensus.Engine // 共识引擎
canStart int32 // 是否能够开始挖矿操作
shouldStart int32 // 同步以后是否应该开始挖矿
}
事件锁，事件发生时，会有一个TypeMux将时间分派给注册的接收者。接收者可以注册以处理特定类型的事件。在mux结束后调用的任何操作将返回ErrMuxClosed。
共识引擎，获得共识算法的工具对象，以提供后续共识相关操作使用。我会在这篇文章之后单独写两篇文章仔细分析以太坊的两种共识算法ethash和clique。
worker
Miner结构体中其他的都介绍完毕，唯独worker对象需要深入研究，因为外部有一个单独的worker.go文件，Miner包含了这个worker对象。上面注释给出的是“干活的人”，每个miner都会有一个worker成员对象，可以理解为工人，他负责全部具体的挖矿工作流程。

type worker struct {
config *params.ChainConfig
engine consensus.Engine

mu sync.Mutex

// update loop
mux          *event.TypeMux