以太坊 矿工与挖矿奖励
解决了如何挖矿的问题后，就得解决谁来记账，并获得记账奖励的问题。
谁是矿工？
某些算力较强的节点出块速度较快，这些节点能够用比他人更快的速度计算出符合共识的区块，这些为社区贡献算力出块的计算机就俗称为 矿工 。它们打包交易，组成区块，并将区块向网络广播。成功进入区块链的区块能让矿工获得 挖矿奖励。
矿工怎么收集交易？
以太坊的打包过程比较直接，就是矿工在待打包池中选择一些交易来进行打包。由于需要保证一定的出块速度，维持网络的可用性，矿工一次打包的交易条数是有限制的，通过单一区块的 GasLimit 来进行限制，矿工在收集交易时候不能无限制添加交易，接近 GasLimit 上限就不可以再添加了，只能等待进入下一区块。
这个上限是由算法与矿工投票共同决定，目前主网上这个数值大概是 8000000，如果你发送单一交易的时候 指定交易费的数量超过这个值，就会引发“超过单一区块Gas上限”的错误而遭到无法打包进入区块的窘境。
以太坊区块链的等待池子中的交易可以从 etherscan.io [1] 网站中查询 ，数据是完全公开、透明的。
绝大部分交易被记入区块的顺序是取决于交易费高低的。
低交易费等待的时间会比较久，也可能因为交易数量太多而被暂时剔除出该池子，这个现象在交易发送方看来，就是过了数小时交易也没有“确认”。在这种情况下，该交易很可能无法进入区块，更不用提进入最终的区块链。所以在发送交易的时候，我们不要设置过低的Gas交易费，以防止转账超时而影响业务。
万一两个矿工都挖出了块呢？
矿工在打包出块后，通过网络广播这个好消息，试图让自己打包的块入选最终的区块链。 其他矿工可以选择基于此基础挖掘新高度上的块，也可以自己重新计算另一份同一高度的块。
如下图所示，在同一高度上，矿工竞争出块，在 高度2 上可能有两个区块在几乎相同的时间挖掘出来。 并且它们都进入了候选区。 此时区块链在这个高度临时面临“分叉”危机。但是最终承认哪个区块为 高度2 的块呢？
同一高度上(高度 2)两个被挖掘出的区块，谁能留在主链上？
这取决于社区内的矿工选择谁作为基础点挖掘 高度3 的区块。 区块链网络仅承认 累积难度最高的链条 为“最终”的账本。 矿工往往更聪明，与其在落后的情况下重新计算该高度，不如放弃转而支持最长链条，毕竟被算出来落后的区块不被网络承认，是白白浪费了计算电力(白白消耗了成本)。 他们往往会选择 高度2 上优先冒出来的区块作为自己的计算起点，获得更大的时间优势。
如下图所示，未被任何后继区块作为基础的 高度2 上的某一区块最终未能进入最高链条的行列，挖掘它的矿工也将无法获得挖矿奖励。
高度3区块基于某一个高度2区块挖掘，另一个高度2区块被放弃
正因为新挖掘的区块是否最终留在主链的不确定性，在实践中，虚拟货币交易所提示充值时要等待数个区块的确认时间，保证我们发出的交易处在最高的链条上。
在以太坊上是 30 个确认，耗时约 10分钟。在比特币中 6 个确认（高度）后，我们才认为账本真实有效，耗时约 60 分钟。
且慢！那未入选的区块得不到奖励了吗？
当然不是，以太坊额外发明了补偿机制。
以太坊的奖励机制的设计除参照传统的比特币挖矿奖励以外，还创造了一个新的名词 叔块 ，特指与本区块的前一区块 父块 处同一高度的块。
很不幸，这些叔块虽然本身合法，但在竞争过程中没有战胜父块入选最终区块链（一将功成万骨枯的概念），但是它们在挖掘过程中也耗费了很多电力、算力。
以太坊的设计比较人性化，当本高度区块在叔块列表里引用某叔块的时候，该叔块的挖掘者也能获得一点奖励，但奖励的数额较少。叔块中的交易还是要重新发回交易池等待打包的。
如下图所示，区块 高度3 的区块除指名自己的父块是 高度2 的区块以外，对叔块也做了引用，这样叔块的挖掘者也能分得一些以太币奖励。
高度3区块引用了高度2上的另一个区块为叔块
以太坊这样设计的深层次原因：按照其成为世界分布式计算设施的理想，需要较高的出块速度维持可用性。
目前每隔 15~20 秒产生一个区块，间隔时间较短，而网络中传播扩散速度都有秒级的延迟，世界这端的计算机和另一端的计算机往往还未能沟通、同步最新的本高度区块，下一高度的区块就又产生了。 这对那些计算速度快，但网络条件较差的矿工而言尤其不公平。
为了权衡各方利益，以太坊设计了叔块的奖励机制。目前叔块的发生概率在 14.9% 左右。叔块奖励的具体例子可在etherscan网站上参考高度为 #5907648 [#]_的主网区块 ，最“直系”的叔块奖励是区块奖励的 7/8 ，隔代越远则渐渐减弱到 1/8 ，奖励由如下公式指定。
叔块的奖励 = (叔块高度 + 8 - 包含叔块的区块高度) * 普通区块的奖励/ 8
本章讲解以太坊里的数据结构。以太坊大量使用名为 Merkle Patricia Trie （MPT树）的高效结构对数据进行组织、索引。此外，对于树的节点，使用一种高效的键值对数据库 LevelDB 进行本地持久化保存。我们 ...