前言

Ethash实现了PoW，PoW的精妙在于通过一个随机数确定，矿工确实做了大量的工作，并且是没有办法作弊的。接下来将介绍：

1. Ethash的挖矿本质。
2. Ethash是如何挖矿的。
3. 如何验证Ethash的随机数。

Ethash的挖矿本质

挖矿的本质是找到一个随机数，证明自己做了很多工作（计算）。在Ethash中，该随机数称为Nonce，它需要满足一个公式：

Rand(hash, nonce) ≤ MaxValue / Difficulty

参数解释

• hash：去除区块头中Nonce、MixDigest生成的哈希值，见HashNoNonce()。
• nonce：待寻找的符合条件的随机数。
• MaxValue：固定值2^256，生成的哈希值的最大取值。
• Difficulty：挖矿难度。
• Rand()：使用hash和nonce生成一个哈希值，这其中包含了很多哈希运算。

以上参数中，在得到区块头的hash之后，只有nonce是未知的。公式的含义是，使用hash和nonce生成的哈希值必须落在合法的区间
利用下图介绍一下，Rand()函数结果取值范围是[0, MaxValue]，但只有计算出的哈希值在[0, MaxValue / Difficulty]内，才是符合条件的哈希值，进而该Nonce才是符合条件的，否则只能再去寻找下一个Nonce。

以太坊可以通过调整Difficulty来调节当前挖矿的难度，Difficulty越大，挖矿的难度越大。当Difficulty越大时， MaxValue / Difficulty越小，合法的哈希值范围越小，造成挖矿难度增加。

哈希值满足条件的概率是 p = (MaxValue / Difficulty) / MaxValue = 1 / Difficulty，矿工需要进行1 / p = Difficulty次的判断，才有可能找到一个符合条件的Nonce，当前以太坊难度为3241847139727150

为什么PoW需要做那么多的运算，而不是通过公式反推，计算出满足条件的结果(Nonce)？

PoW可以表示为许多数学公式的合集，每次运算的入参：前一个区块头的哈希，当前高度的DataSet，目标值Nonce，这些数学公式都是哈希函数，哈希函数的特性就是不可逆性，不能通过摘要获得输入数据。虽然，前一个区块头的哈希和当前高度的DataSet是固定的，但由于哈希函数的不可逆性，依然无法倒推出Nonce，只能随机的产生Nonce，或累加Nonce，并不断的重试，直到找到符合条件的Nonce。

如何挖矿

Ethash挖矿的主要思想是，开启多个线程去寻找符合条件的Nonce，给每个线程分配一个随机数，作为本线程的Nonce的初始值，然后每个线程判断当前的Nonce是否符合上面的公式，如果不符合，则把Nonce加1，再次进行判断，这样不定的迭代下去，直到找到一个符合条件的Nonce，或者挖矿被叫停。

接下来介绍挖矿的几个主要函数的实现，它们是：

1. 挖矿的入口Seal函数。
2. 挖矿函数mine函数。
3. 挖矿需要的数据cache和dataset。
4. Rand()函数的实现hashimotoFull和hashimoto。

挖矿入口Seal()

Seal是引擎的挖矿入口函数，它是管理岗位，负责管理挖矿的线程。它发起多个线程执行Ethash.mine进行并行挖矿，当要更新或者停止的时候，重新启动或停止这些线程。

挖矿函数mine()

mine函数负责挖矿。Seal在启动每一个mine的时候，给它分配了一个seed，mine会把它作为Nonce的初始值，然后生成本高度使用的dataset，然后把dataset, hash, nonce传递给hashimotoFull函数，这个函数可以认为是原理介绍中的Rand随机函数，他会生成哈希值Result，当Result <= Target的时候，说明哈希值落在符合条件的区间了，mine找到了符合条件的Nonce，使用Digest和nonce组成新的区块后，发送给Seal，否则验证下一个Nonce是否是符合条件的

挖矿需要的数据cache和dataset

dataset用来生成Result，而cache用来生成dataset。至于如何使用dataset生成Result在hashimoto()中讲述，本节介绍如何生成dataset。

dataset和cache中存放的都是伪随机数，每个epoch的区块使用相同的cache和dataset，并且dataset需要暂用大量的内存。刚开始时cache是16MB，dataset是1GB，但每个epoch它们就会增大一次，它们的大小分别定义在datasetSizes和cacheSizes，dataset每次增长8MB，最大能达到16GB，所以挖矿的节点必须有足够大的内存。

使用cache生成dataset。使用cache的部分数据，进行哈希和异或运算，就能生成一组dataset的item，比如下图中的cache中黄色块，能生成dataset中的黄色块，最后把这些Item拼起来就生成了完整的Dataset，完成该功能的函数是generateDataset。

dataset.generate()是dataset的生成函数，该函数只执行一次，先使用generateCache()生成cache，再将cache作为generateDataset()的入参生成dataset，其中需要重点关注的是generateDatasetItem()，该函数是根据部分cache，生成一组dataset item，验证PoW的nonce的时候，也需要使用该函数。

Rand()的实现hashimotoFull()和hashimoto()

hashimotoFull功能是使用dataset、hash和nonce生成Digest和Result。它创建一个获取dataset部分数据的lookup函数，该函数能够返回连续的64字节dataset中的数据，然后把lookup函数、hash和nonce传递给hashimoto。

hashimoto的功能是根据hash和nonce，以及lookup函数生成Digest和Result，lookup函数能够返回64字节的数据就行。它把hash和nonce合成种子，然后根据种子生成混合的数据mix，然后进入一个循环，使用mix和seed获得dataset的行号，使用lookup获取指定行的数据，然后把数据混合到mix中，混合的方式是使用哈希和异或运算，循环结束后再使用哈希和异或函数把mix压缩为64字节，把mix转为小端模式就得到了Digest，把seed和mix进行hash运算得到Result。

如何验证

PoW的验证是证明出块人确实进行了大量的哈希计算。Ethash验证区块头中的Nonce和MixDigest是否合法，如果验证通过，则认为出块人确实进行了大量的哈希运算。验证方式是确定区块头中的Nonce是否符合公式，并且区块头中的MixDigest是否与使用此Nonce计算出的是否相同。

验证与挖矿相比，简直是毫不费力，因为：

• 时间节省。验证只进行1次hashimoto运算，而挖矿进行大约Difficulty次。
• 空间节省。验证只需要cache，不需要dataset，也就不需要计算庞大的dataset，因此不挖矿的验证节点，不需要很高的配置。

接下来介绍验证函数VerifySeal()，以及根据cache生成Digest和Result的hashimotoLight()。

验证函数VerifySeal

Ethash.VerifySeal实现PoW验证功能。首先先判断区块中的Difficulty是否匹配，然后生成（获取）当前区块高度的cache，把cache和nonce传递给hashimotoLight，该函数能根据cache, hash, nonce生成Digest和Result，然后校验Digest是否匹配以及Result是否符合条件。

hashimotoLight函数

hashimotoLight使用cache, hash, nonce生成Digest和Result。生成Digest和Result只需要部分的dataset数据，而这些部分dataset数据时可以通过cache生成，因此也就不需要完整的dataset。它把generateDatasetItem函数封装成了获取部分dataset数据的lookup函数，然后传递给hashimoto计算出Digest和Result。

FAQ

• Q：每30000个块使用同一个dataset，那可以提前挖出一些合法的Nonce？
  A：不行。提前挖去Nonce，意味着还不知道区块头的hash，因此无法生成合法的Nonce。
• Q：能否根据符合条件的哈希值，反推出Nonce呢？
  A：不行。因为哈希运算具有不可逆性，不能根据摘要反推出明文，同理根据哈希值也无法推出Nonce。

转载自：https://lessisbetter.site/2018/06/22/ethereum-code-consensus-3/

前言

engine是以太坊封定义的一个接口，它的功能可以分为3类：

1. 验证区块类，主要用在将区块加入到区块链前，对区块进行共识验证。
2. 产生区块类，主要用在挖矿时。
3. 辅助类。

接下来我们看一下engine具体定义了哪些功能，还有各功能的使用场景。

engine定义的具体功能

engine有3类功能，验证区块类、产生区块类、辅助类。因为产生区块在前，验证区块在后，接下来采用产生区块类、验证区块类、辅助类，分别介绍它们的功能和使用场景。

验证区块类

1. Prepare：初始化区块头信息，不同的共识算法初始化不同。使用场景是，worker创建work的时候调用。
2. Finalize：根据数据生成“基本定型”的区块，但区块头中还缺少部分数据。使用场景是，1）模拟区块链的时候，被GenerateChain调用，用来生成区块链。2）交易状态管理时，被StateProcessor.Process调用用来执行交易。3）worker创建work的时候调用。
3. Seal：根据传入的块，进行的是挖矿工作，使用挖矿的结果，修改区块头，然后生成新的区块。使用场景是，被agent.mine调用。

验证区块类

1. VerifyHeader：验证区块头。使用在fetcher中，当fetcher要插入区块的时候，需要先对区块头进行校验。
2. VerifyHeaders：验证一批区块头。有2种使用场景，1）区块链中，insertChain当把一批区块插入到区块链这个链条的时候，需要进行检查；2）LightChain中，把一批区块头插入到本地链。
3. VerifyUncles：验证区块中的叔块。insertChain当区块插入区块链的时候，需要对叔块进行验证，调用在VerifyHeaders之后。
4. VerifySeal：针对Seal函数做的功能进行验证。验证Seal()所修改的区块头中的数据。对外的使用场景是，把Work发送给远端Agent的时候调用。对内的使用场景是，验证区块头的时候会被调用。

辅助类

1. APIs：生成以太坊共识相关的API。在以太坊启动RPC服务时，生成API。
2. Author：读取区块头中的coinbase。被ethstats使用，ethstats是以太坊状态管理服务，当报告数据的时候，需要获取区块的Author信息。

最后关注一下蓝色的线条，它们代表insertChain所调用的范围，先关的有VerifyHeaders、VerifyUncles、Finalize，涉及到块头的验证、叔块的验证，以及执行区块中的交易，一个区块加入到区块链中，不仅要验证，还要执行各种交易，改变各种状态，所有节点执行确定性的行为之后，达成一致性。

Faq

• Q：谁实现engine
  A：以太坊中的Ethash和Clique实现了engine，Ethash是基于PoW的共识，Clique是基于PoA的共识。
• Q：为什么insertChain没有调用VerifySeal？
  A：因为Seal()修改的是header中的部分数据，在验证区块头的时候，会被调用。只是调用流程在Ethash和Clique中的实现略有不同，后续讲解。

转载自：https://lessisbetter.site/2018/06/22/ethereum-code-consensus-2/

前言

矿工在PoW中负责了产生区块的工作，把一大堆交易交给它，它生成一个证明自己工作了很多区块，然后将区块加入到本地区块链并且广播给其他节点。

接下来我们将从以下角度介绍矿工：

1. 角色。矿工不是一个人，而是一类人，可以把这一类人分成若干角色。
2. 一个区块产生的主要流程。
3. 矿工的主要函数介绍，掌握矿工的主要挖矿机制。

介绍矿工由哪些部分组成，会和哪些其他模块进行交互，这些部分是如何协作产生区块的。

角色

有3种角色：miner、worker、agent。

• miner：是矿长，负责管理整个矿场的运作，比如：启动、停止挖矿，处理外部请求，设置挖矿获得的奖励的钱包地址等等。
• worker：副矿长，负责具体挖矿工作的安排，把挖矿任务（Work）安排给agent。
• agent：真实的矿工，他们负责挖矿，把自己的劳动成果（Result）交给worker，agent默认只有1个，可以通过API创建多个。

一个区块产生的主要流程

实际的挖矿过程基本不涉及miner，只涉及worker、agent和engine，engine是共识引擎模块，我们利用下图介绍生成一个区块的主要流程。
挖矿过程中只涉及engine的3个接口：

1. Prepare()挖矿前的准备工作，
2. Finalize()形成一个基本定型的区块，
3. Seal()形成最终的区块。

• worker把区块头、交易、交易执行的收据等传递给engine.Finalize。
• engine.Finalize返回一个block，该block的header中缺少Nonce和MixDigest，这两个值是挖矿获取的。
• worker把block封装到work，把work发送给所有的agent。
• agent.update把work传递给agent.mine。
• agent.mine把work传递给engine.Seal，调用engine.Seal挖矿。
• engine.Seal把Nonce和MixDigest填到区块头，生成一个new block交给agent.mine.
• agent.mine把new block封装成Result，发送给worker。

矿工的主要函数

介绍miner、worker和agent的主要函数，他们是矿工的具体运作机制。

miner的主要函数

主要关注2个函数：

1. New()：负责创建miner。还创建1个worker和1个agent，但agent还可以通过API创建，然后启动update函数。
2. update()：负责关注downloader的3个事件：StartEvent、DoneEvent、FailedEvent。StartEvent是开始同步区块，必须停止挖矿，DoneEvent和FailedEvent是同步成功或者失败，是同步的结束，已经可以挖矿了。表明：挖矿和同步区块不可同时进行，尽量降低了区块冲突的可能。

worker的主要函数

主要是3个函数：

1. commitNewWork()：负责生成work，分配agent。这个阶段做了很多工作，调用Engine.Prepare进行准备工作，创建Header，执行交易，获取Uncle，使用Engine.Finalize形成“基本定型”的临时区块，创建Work，最后把work传递给agent。另外commitNewWork存在多处调用，并且worker有wait和update另外2个协程，他们都会调用commitNewWork，所以存在临界区需要谨慎加锁。
2. update()：负责处理外部事件。它是死循环，主要处理3种事件：1）ChainHeadEvent，有了新区块头，所以得切换到挖下一个高度的区块，2）ChainSideEvent，收到了uncle区块，缓存起来，3）TxPreEvent，预处理交易，如果在挖矿执行commitNewWork，如果未挖矿，则交易设置为未决状态。
3. wait()：负责处理agent挖矿的结果。它是死循环，一直等待接收agent发回的result，然后把区块加入到本地数据库，如果没有问题，就发布NewMinedBlockEvent事件，通告其他节点挖到了一个新块。

agent的主要函数

主要2个函数:

1. update()：负责接收worker发来的任务（work）。它是死循环，把work交给mine去挖矿。
2. mine()：负责挖矿。它拥有挖矿的能力，调用Engine.Seal挖矿，如果挖矿成功则生成result，发送给worker。

转载自：https://lessisbetter.site/2018/06/22/ethereum-code-consensus-1/

区块链就是何交易打交道，我们今天就介绍下，交易处理过程中的一个重要组成部分：txpool。这篇文章主要从功能角度介绍，通过这篇文章会了解：

1. txpool的在交易中的位置和作用。
2. txpool的功能，核心组成部分queued和pending。
3. txpool如何实现它的功能。
4. txpool源码的重要关注点。

以太坊内部有个重要的内部功能是txpool，从字面意思就能看出来，交易池就是存放交易的池子。它在以太坊中的位置如下图，只要有新交易，无论是本节点创建的，还是其他peer节点广播来的，都会先加入到交易池里，在打包区块的时候，就从这个池子里提取，区块产生之后，共识区块，交易上链。

txpool有4个功能：

1. 作为存放交易的缓冲区，大量交易到来时，先存起来
2. 为打包区块服务，合适交易会被打包到区块
3. 清理交易
4. 当交易的数量多于缓冲区大小时，过滤/惩罚发送大量交易的账户（攻击者）

我们来一张稍微详细点的模块交互图，看txpool怎么实现上面4个功能的。

缓存功能的设计

txpool中的交易分为queued和pending 2种，其中queued存放未来的、当前无法执行的交易。以太坊使用nonce值决定某个账户的交易顺序，多条交易值nonce值必须连续，如果和过去的交易不连续，则无法执行，我们不妨使用nonce值，标记交易的号码，nonce为10的交易，称为第10号交易。举个例子，当前账户的nonce是10，txpool中有该账户的第100号交易，但txpool中没有第11~99号交易，这些交易的缺失，造成第100号交易无法执行，所以第100号交易就是未来的交易、不可执行的交易，存放在queue中。

pending存放可执行的交易。比如我们把上面的11 ~ 99号交易补全了，那么100号交易都可以进入到pending，因为这些交易都是连续的，都可以打包进区块。

当节点收到交易（本地节点发起的或peer广播来的）时，会先存放到queued，txpool在某些情况下，把queued中可执行的交易，转移到pending中。

为区块打包服务

这是txpool最核心的功能，worker在打包区块的时候，会获取所有的pending交易，但这些交易还存在txpool中，worker只是读取出来，至于txpool何时删除交易，稍后从txpool清理交易的角度单独在看。

清理交易

txpool清理交易有以下几种条件，符合任意以下1条的，都是无效交易，会被从pending或者queued中移除：

1. 交易的nonce值已经低于账户在当前高度上的nonce值，代表交易已过期，交易已经上链就属于这种情况
2. 交易的GasLimit大于区块的GasLimit，区块容不下交易
3. 账户的余额已不足以支持该交易要消耗的费用
4. 交易的数量超过了queued和pending的缓冲区大小，需要进行清理

交易清理主要有3个场景:

1. txpool订阅了ChainHeadEvent事件，该事件代表主链上有新区块产生，txpool会根据最新的区块，检查每个账号的交易，有些无效的会被删除，有些由于区块回滚会从pending移动到queued，然后把queued中可执行的交易移动到pending，为下一轮区块打包组号准备。
2. queued交易移动到pending被称为“提升”（promote），这个过程中，同样会检查交易，当交易不符合以上条件时，就会被直接从queued中删除。
3. 删除停留在queued中超过3小时的交易，3小时这个超时时间是可以通过geth的启动参数调整的。txpool记录了某个账户交易进入pending的时间，如果这个时间超过了3小时，代表该账号的交易迟迟不能被主链打包，既然无法被主链接受，就删除掉在queued中本来就无法执行的交易

惩罚恶意账号

这也是txpool很重要的一个属性，可以防止恶意账户以发起大量垃圾交易。防止恶意用户造成：

1. 占用txpool空间
2. 浪费节点大量内存和CPU
3. 降低打包性能

只有当交易的总数量超过缓冲区大小时，txpool才会认为有恶意账户发起大量交易。
pending和queued缓冲区大小不同，但处理策略类似：

1. pending的缓冲区容量是4096，当pending的交易数量多于此时，就会运行检查，每个账号的交易数量是否多于16，把这些账号搜集出来，进行循环依次清理，什么意思呢？就是每轮只删除（移动到queued）这些账号的每个账号1条交易，然后看数量是否降下来了，不满足再进行下一轮，直到满足。
2. queued的缓冲区容量是1024，超过之后清理策略和pending差不多，但这里可是真删除了。

该部分功能未抽象成单独的函数，而是在promoteExecutables()中，就是在每次把queued交易转移到pending后执行的。

本地交易的特权

txpool虽然对交易有诸多限制，但如果交易是本节点的账号发起的，以上数量限制等都对他无效。所以，如果你用本节点账号不停的发送交易，并不会被认为是攻击者，你用txpool.status命令，可以查看到交易的数量，肯定可以大于4096，我曾达到过60000+。

重点关注的源码

txpool的主要设计上面就讲完了，如果你想把txpool的代码阅读一番，我建议你重点关注一下这些函数和变量，按图索骥能就完全掌握txpool的实现。

• TxPoolConfig：txpool的配置参数
• chainHeadCh：txpool订阅了新区块事件
• pending：pending的交易，每个账号都有一个交易列表
• queue：queued的交易，每个账号都有一个交易列表
• loop：txpool的事件处理函数
• addTx：添加1条交易的源头，你能找到类似的函数
• promoteExecutables：queued交易移动到pending
• reset：根据当前区块的最新高度，重置txpool中的交易

仔细阅读一遍，你会发现txpool会涉及多个锁（TxPool.mu, TxPool.all, TxPool.priced.all），所以当txpool中的交易很多时，它的性能是很低的，这也会影响到区块的打包。

转载自：https://lessisbetter.site/2018/12/11/ethereum-design-of-txpool/

在测试eth.pendingTransactions时，无法获取到数据，查看代码(Github Code)

// PendingTransactions returns the transactions that are in the transaction pool
// and have a from address that is one of the accounts this node manages.
func (s *PublicTransactionPoolAPI) PendingTransactions() ([]*RPCTransaction, error) {
    pending, err := s.b.GetPoolTransactions()
    if err != nil {
        return nil, err
    }
    accounts := make(map[common.Address]struct{})
    for _, wallet := range s.b.AccountManager().Wallets() {
        for _, account := range wallet.Accounts() {
            accounts[account.Address] = struct{}{}
        }
    }
    curHeader := s.b.CurrentHeader()
    transactions := make([]*RPCTransaction, 0, len(pending))
    for _, tx := range pending {
        from, _ := types.Sender(s.signer, tx)
        if _, exists := accounts[from]; exists {
            transactions = append(transactions, newRPCPendingTransaction(tx, curHeader, s.b.ChainConfig()))
        }
    }
    return transactions, nil
}

原因

由于查询eth.pendingTransactions性能消耗较大，所以代码加了一层限制，必须查询当前交易的签名者地址加到当前节点地址中

./geth attach ipc:./data/geth.ipc
personal.importRawKey("e9bc9ae610535。。。。f4f49c025cc","passwrod..")

注意

由于当前私钥可能被外网猜测，所以当前查询节点不能对外提供RPC服务，只能内网被业务服务调用。并做好节点访问权限安全防范

参考

https://github.com/ethereum/go-ethereum/issues/21138