回复：区块链开发公司

update()
worker.update()分别监听ChainHeadEvent，ChainSideEvent，TxPreEvent几个事件，每个事件会触发worker不同的反应。ChainHeadEvent是指区块链中已经加入了一个新的区块作为整个链的链头，这时worker的回应是立即开始准备挖掘下一个新区块(也是够忙的)；ChainSideEvent指区块链中加入了一个新区块作为当前链头的旁支，worker会把这个区块收纳进possibleUncles[]数组，作为下一个挖掘新区块可能的Uncle之一；TxPreEvent是TxPool对象发出的，指的是一个新的交易tx被加入了TxPool，这时如果worker没有处于挖掘中，那么就去执行这个tx，并把它收纳进Work.txs数组，为下次挖掘新区块备用。
需要稍稍注意的是，ChainHeadEvent并不一定是外部源发出。由于worker对象有个成员变量chain(eth.BlockChain)，所以当worker自己完成挖掘一个新区块，并把它写入数据库，加进区块链里成为新的链头时，worker自己也可以调用chain发出一个ChainHeadEvent，从而被worker.update()函数监听到，进入下一次区块挖掘。
wait()
worker.wait()会在一个channel处一直等待Agent完成挖掘发送回来的新Block和Work对象。这个Block会被写入数据库，加入本地的区块链试图成为最新的链头。注意，此时区块中的所有交易，假设都已经被执行过了，所以这里的操作，不会再去执行这些交易对象。
当这一切都完成，worker就会发送一条事件(NewMinedBlockEvent{})，等于通告天下：我挖出了一个新区块！这样监听到该事件的其他节点，就会根据自身的状况，来决定是否接受这个新区块成为全网中公认的区块链新的链头。至于这个公认过程如何实现，就属于共识算法的范畴了。
commitNewWork()
commitNewWork()会在worker内部多处被调用，注意它每次都是被直接调用，并没有以goroutine的方式启动。commitNewWork()内部使用sync.Mutex对全部操作做了隔离。这个函数的基本逻辑如下：
1. 准备新区块的时间属性Header.Time，一般均等于系统当前时间，不过要确保父区块的时间(parentBlock.Time())要早于新区块的时间，父区块当然来自当前区块链的链头了。
2. 创建新区块的Header对象，其各属性中：Num可确定(父区块Num +1)；Time可确定；ParentHash可确定;其余诸如Difficulty，GasLimit等，均留待之后共识算法中确定。
3. 调用Engine.Prepare()函数，完成Header对象的准备。
4. 根据新区块的位置(Number)，查看它是否处于DAO硬分叉的影响范围内，如果是，则赋值予header.Extra。
5. 根据已有的Header对象，创建一个新的Work对象，并用其更新worker.current成员变量。
6. 如果配置信息中支持硬分叉，在Work对象的StateDB里应用硬分叉。
7. 准备新区块的交易列表，来源是TxPool中那些最近加入的tx，并执行这些交易。
8. 准备新区块的叔区块uncles[]，来源是worker.possibleUncles[]，而possibleUncles[]中的每个区块都从事件ChainSideEvent中搜集得到。注意叔区块最多有两个。
9. 调用Engine.Finalize()函数，对新区块“定型”，填充上Header.Root, TxHash, ReceiptHash, UncleHash等几个属性。
10. 如果上一个区块(即旧的链头区块)处于unconfirmedBlocks中，意味着它也是由本节点挖掘出来的，尝试去验证它已经被吸纳进主干链中。
11. 把创建的Work对象，通过channel发送给每一个登记过的Agent，进行后续的挖掘。
以上步骤中，4和6都是仅仅在该区块配置中支持DAO硬分叉，并且该区块的位置正好处于DAO硬分叉影响范围内时才会发生；其他步骤是普遍性的。commitNewWork()完成了待挖掘区块的组装，block.Header创建完毕，交易数组txs，叔区块Uncles[]都已取得，并且由于所有交易被执行完毕，相应的Receipt[]也已获得。万事俱备，可以交给Agent进行‘挖掘’了。
CpuAgent的函数
CpuAgent中与mine相关的函数，主要是update()和mine():

CpuAgent.update()就是worker.commitNewWork()结束后发出Work对象的会一直监听相关channel，如果收到Work对象(显然由worker.commitNewWork()结束后发出)，就启动mine()函数；如果收到停止(mine)的消息，就退出一切相关操作。
CpuAgent.mine()会直接调用Engine.Seal()函数，利用Engine实现体的共识算法对传入的Block进行最终的授权，如果成功，就将Block同Work一起通过channel发还给worker，那边worker.wait()会接收并处理。
显然，这两个函数都没做什么实质性工作，它们只是负责调用<Engine>接口实现体，待授权完成后将区块数据发送回worker。挖掘出一个区块的真正奥妙全在Engine实现体所代表的共识算法里。
2.共识算法完成挖掘
共识算法族对外暴露的是Engine接口，其有两种实现体，分别是基于运算能力的Ethash算法和基于“同行”认证的的Clique算法。

在Engine接口的声明函数中，VerifyHeader()，VerifyHeaders()，VerifyUncles()用来验证区块相应数据成员是否合理合规，可否放入区块；Prepare()函数往往在Header创建时调用，用来对Header.Difficulty等属性赋值；Finalize()函数在区块区块的数据成员都已具备时被调用，比如叔区块(uncles)已经具备，全部交易Transactions已经执行完毕，全部收据(Receipt[])也已收集完毕，此时Finalize()会最终生成Root，TxHash，UncleHash，ReceiptHash等成员。
而Seal()和VerifySeal()是Engine接口所有函数中最重要的。Seal()函数可对一个调用过Finalize()的区块进行授权或封印，并将封印过程产生的一些值赋予区块中剩余尚未赋值的成员(Header.Nonce, Header.MixDigest)。Seal()成功时返回的区块全部成员齐整，可视为一个正常区块，可被广播到整个网络中，也可以被插入区块链等。所以，对于挖掘一个新区块来说，所有相关代码里Engine.Seal()是其中最重要，也是最复杂的一步。VerifySeal()函数基于跟Seal()完全一样的算法原理，通过验证区块的某些属性(Header.Nonce，Header.MixDigest等)是否正确，来确定该区块是否已经经过Seal操作。
在两种共识算法的实现中，Ethash是产品环境下以太坊真正使用的共识算法，Clique主要针对以太坊的测试网络运作，两种共识算法的差异，主要体现在Seal()的实现上。
Ethash共识算法
Ethash算法又被称为Proof-of-Work(PoW)，是基于运算能力的授权/封印过程。Ethash实现的Seal()函数，其基本原理可简单表示成以下公式:
RAND(h, n) <= M / d
这里M表示一个极大的数，比如2^256-1；d表示Header成员Difficulty。RAND()是一个概念函数，它代表了一系列复杂的运算，并最终产生一个类似随机的数。这个函数包括两个基本入参：h是Header的哈希值(Header.HashNoNonce())，n表示Header成员Nonce。整个关系式可以大致理解为，在最大不超过M的范围内，以某个方式试图找到一个数，如果这个数符合条件(<=M/d)，那么就认为Seal()成功。
我们可以先定性的验证一个推论：d的大小对整个关系式的影响。假设h，n均不变，如果d变大，则M/d变小，那么对于RAND()生成一个满足该条件的数值，显然其概率是下降的，即意味着难度将加大。考虑到以上变量的含义，当Header.Difficulty逐渐变大时，这个对应区块被挖掘出的难度（恰为Difficulty本义）也在缓慢增大，挖掘所需时间也在增长，所以上述推论是合理的。
mine()函数
Ethash.Seal()函数实现中，会以多线程(goroutine)的方式并行调用mine()函数，线程个数等于Ethash.threads；如果Ethash.threads被设为0，则Ethash选择以本地CPU中的总核数作为开启线程的个数。
[plain] view plain copy
1. /* consensus/ethash/sealer.go */
2. func (ethash *Ethash) mine(block *Block, id int, seed uint64, abort chan struct{}, found chan *Block) {
3. var (
4. header = block.Header()
5. hash = header.HashNoNonce().Bytes()
6. target = new(big.Int).Div(maxUint256, header.Difficulty)
7. number = header.Number.Uint64()
8. dataset = ethash.dataset(number)
9. nonce = seed
10. )
11. for {
12. select {
13. case <-abort:
14. ...; return
15. default:
16. digest, result := hashimotoFull(dataset, hash, nonce) // compute the PoW value of this nonce
17. if new(big.Int).SetBytes(result).Cmp(target) <= 0 { // x.Cmp(y) <= 0 means x <= y
18. header = types.CopyHeader(header)
19. header.Nonce = types.EncodeNonce(nonce)
20. header.MixDigest = common.BytesToHash(digest)
21. found<- block.WithSeal(header)
22. return
23. }
24. }
25. nonce++
26. }
27. }
以上代码就是mine()函数的主要业务逻辑。入参@id是线程编号，用来发送log告知上层；函数内部首先定义一组局部变量，包括之后调用hashimotoFull()时传入的hash、nonce、巨大的辅助数组dataset，以及结果比较的target；然后是一个无限循环，每次调用hashimotoFull()进行一系列复杂运算，一旦它的返回值符合条件，就复制Header对象(深度拷贝)，并赋值Nonce、MixDigest属性，返回经过授权的区块。注意到在每次循环运算时，nonce还会自增+1，使得每次循环中的计算都各不相同。
这里hashimotoFull()函数通过调用hashimoto()函数完成运算，而同时还有另外一个类似的函数hashimoLight()函数。
[cpp] view plain copy
1. func hashimotoFull(dataset []uint32, hash []byte, nonce uint64) ([]byte, []byte) {
2. lookup := func(index uint32) []uint32 {
3. offset := index * hashWords
4. return dataset[offset : offset+hashWords]
5. }
6. return hashimoto(hash, nonce, uint64(len(dataset))*4, lookup)
7. }
8. func hashimotoLight（size uint64, cache []uint32, hash []byte, nonce uint64） ([]byte, []byte) {
9. lookup := func(index uint32) []uint32 {
10. rawData := generateDatasetItem(cache, index, keccak512)
11. data := make([]uint32, len(rawData)/4)
12. for i := 0; i < len(data); i++ {
13. data[i] = binary.LittleEndian.Uint32(rawData[i*4:])
14. }
15. return data
16. }
17. return hashimoto(hash, nonce, size, lookup)
18. }
以上两个函数，最终都调用了hashimoto()。它们的差别，在于各自调用hashimoto()函数的入参@size uint 和 @lookup func()不同。相比于Light()，Full()函数调用的size更大，以及一个从更大数组中获取数据的查询函数lookup()。hashimotoFull()函数是被Seal()调用的，而hashimotoLight()是为VerifySeal()准备的。
这里的lookup()函数其实很重要，它其实是一个以非线性表查找方式进行的哈希函数！ 这种哈希函数的性能不仅取决于查找的逻辑，更多的依赖于所查找的表格的数据规模大小。lookup()会以函数型参数的形式传递给hashimoto()
核心的运算函数hashimoto()
最终为Ethash共识算法的Seal过程执行运算任务的是hashimoto()函数，它的函数类型如下：
[plain] view plain copy
1. // consensus/ethash/algorithm.go
2. func hashimoto(hash []byte, nonce uint64, size uint64, lookup(index uint32) []uint32) (digest []byte, result []byte)
hashimoto()函数的入参包括：区块哈希值@hash, 区块nonce成员@nonce，和非线性表查找的哈希函数lookup()，及其所查找的非线性表格的容量@size。返回值digest和result，都是32 bytes长的字节串。
hashimoto()的逻辑比较复杂，包含了多次、多种哈希运算。下面尝试从其中数据结构变化的角度来简单描述之：

简单介绍一下上图所代表的代码流程：
· 首先，hashimoto()函数将入参@hash和@nonce合并成一个40 bytes长的数组，取它的SHA-512哈希值取名seed，长度为64 bytes。
· 然后，将seed[]转化成以uint32为元素的数组mix[]，注意一个uint32数等于4 bytes，故而seed[]只能转化成16个uint32数，而mix[]数组长度32，所以此时mix[]数组前后各半是等值的。
· 接着，lookup()函数登场。用一个循环，不断调用lookup()从外部数据集中取出uint32元素类型数组，向mix[]数组中混入未知的数据。循环的次数可用参数调节，目前设为64次。每次循环中，变化生成参数index，从而使得每次调用lookup()函数取出的数组都各不相同。这里混入数据的方式是一种类似向量“异或”的操作，来自于FNV算法。
· 待混淆数据完成后，得到一个基本上面目全非的mix[]，长度为32的uint32数组。这时，将其折叠(压缩)成一个长度缩小成原长1/4的uint32数组，折叠的操作方法还是来自FNV算法。
· 最后，将折叠后的mix[]由长度为8的uint32型数组直接转化成一个长度32的byte数组，这就是返回值@digest；同时将之前的seed[]数组与digest合并再取一次SHA-256哈希值，得到的长度32的byte数组，即返回值@result。
最终经过一系列多次、多种的哈希运算，hashimoto()返回两个长度均为32的byte数组 - digest[]和result[]。回忆一下ethash.mine()函数中，对于hashimotoFull()的两个返回值，会直接以big.int整型数形式比较result和target；如果符合要求，则将digest取SHA3-256的哈希值(256 bits)，并存于Header.MixDigest中，待以后Ethash.VerifySeal()可以加以验证。
以非线性表查找方式进行的哈希运算
上述hashimoto()函数中，函数型入参lookup()其实表示的是一次以非线性表查找方式进行的哈希运算，lookup()以入参为key，从所关联的数据集中按照定义好的一段逻辑取出64 bytes长的数据作为hash value并返回，注意返回值以uint32的形式则相应变成16个uint32长。返回的数据会在hashimoto()函数被其他的哈希运算所使用。
以非线性表的查找方式进行的哈希运算(hashing by nonlinear table lookup)，属于众多哈希函数中的一种实现，在Ethash算法的核心环节有大量使用，所使用到的非线性表被定义成两种结构体，分别叫cache{}和dataset{}。二者的差异主要是表格的规模和调用场景：dataset{}中的数据规模更加巨大，从而会被hashimotoFull()调用从而服务于Ethash.Seal()；cache{}内含数据规模相对较小，会被hashimotoLight()调用并服务于Ethash.VerifySeal()。

以cache{}的结构体声明为例，成员cache就是实际使用的一块内存Buffer，mmap是内存映射对象，dump是该内存buffer存储于磁盘空间的文件对象，epoch是共享这个cache{}对象的一组区块的序号。从上述UML图来看，cache和dataset的结构体声明基本一样，这也暗示了它们无论是原理还是行为都极为相似。
cache{}对象的生成
dataset{}和cache{}的生成过程很类似，都是通过内存映射的方式读/写磁盘文件。

以cache{}为例，Ethash.cache(uint64)会确保该区块所用到的cache{}对象已经创建，它的入参是区块的Number，用Number/epochLength可以得到该区块所对应的epoch号。epochLength被定义成常量30000，意味着每连续30000个区块共享一个cache{}对象。
有意思的是内存映射相关的函数，memoryMapAndGenerate()会首先调用memoryMapFile()生成一个文件并映射到内存中的一个数组，并调用传入的函数型参数generator() 进行数据的填入，于是这个内存数组以及所映射的磁盘文件就同时变得十分巨大，注意此时传入memoryMapFile()的文件操作权限是可写的。然后再关闭所有文件操作符，调用memoryMapFile()重新打开这个磁盘文件并映射到内存的一个数组，注意此时的文件操作权限是只读的。可见这组函数的coding很精细。
Ethash中分别用一个map结构来存放不同epoch对应的cache对象和dataset对象，缓存成员fcache和fdataset，用以提前创建cache{}和dataset{}对象以避免下次使用时再花费时间。
我们以cache{}为例，看看cache.generate()方法的具体逻辑：

上图是cache.generate()方法的基本流程：如果是测试用途，则不必考虑磁盘文件，直接调用generateCache()创建buffer；如果文件夹为空，那也没法拼接出文件路径，同样直接调用generateCache()创建buffer；然后根据拼接出的文件路径，先尝试读取磁盘上已有文件，如果成功，说明文件已存在并可使用；如果文件不存在，那只好创建一个新文件，定义文件容量，然后利用内存映射将其导入内存。很明显，直接为cache{]创建buffer的generateCache()函数是这里的核心操作，包括memoryMapAndGenerate()方法，都将generateCache()作为一个函数型参数引入操作的。
参数size的生成
参数size是生成buffer的容量，它在上述cache.generate()中生成。
[plain] view plain copy
1. size = cacheSize(epoch * epochLength +1)
2. ...
3. func cacheSize(block uint64) uint64 {
4. epoch := int(block / epochLength)
5. if epoch < len(cacheSizes) {
6. return cacheSizes[epoch]
7. }
8. size := uint64(cacheInitBytes + cacheGrowthBytes * uint64(epoch) - hashBytes)
9. for !(size/hashBytes).ProbablyPrime(1) {
10. size -= 2 * hashBytes
11. }
12. return size
13. }
上述就是生成size的代码，cacheSize()的入参虽然是跟区块Number相关，但实际上对于处于同一epoch组的区块来说效果是一样的，每组个数epochLength。Ethash在代码里预先定义了一个数组cacheSizes[]，存放了前2048个epoch组所用到的cache size。如果当前区块的epoch处于这个范围内，则取用之；若没有，则以下列公式赋初始值。
size = cacheInitBytes + cacheGrowthBytes * epoch - hashBytes
这里cacheInitBytes = 2^24，cacheGrowthBytes = 2^17，hashBytes = 64，可见size的取值有多么巨大了。注意到cacheSize()中在对size赋值后还要不断调整，保证最终size是个质数，这是出于密码学的需要。
粗略计算一下size的取值范围，size = 2^24 + 2^17 * epoch，由于epoch > 2048 = 2^11，所以size > 2^28，生成的buffer至少有256MB，而这还仅仅是VerifySeal()使用的cache{}，Seal()使用的dataset{}还要大的多，可见这些数据集有多么庞大了。
参数seed[]的生成
参数seed是generateCache()中对buffer进行哈希运算的种子数据，它也在cache.generate()函数中生成。
[plain] view plain copy
1. seed := seedHash(epoch * epochLength +1)
2. ...
3. func seedHash(block uint64) []byte {
4. seed := make([]byte, 32)
5. if block < epochLength { // epochLength = 30000
6. return seed
7. }
8. keccak256 := makeHasher(sha3.NewKeccak256())
9. for i := 0; i < int(block/epochLength); i++ {
10. keccak256(seed, seed)
11. }
12. return seed
13. }
14. type hasher func(dest []byte, data []byte)
15. func makeHasher(h hash.Hash) hasher {
16. return func(dest []byte, data []byte) {
17. h.Write(data)
18. h.Sum(dest[:0])
19. h.Reset()
20. }
21. }
上述seedHash()函数用来生成所需的seed[]数组，它的长度32bytes，与common.Address类型长度相同。makeHasher()函数利用入参的哈希函数接口生成一个哈希函数，这里用了SHA3-256哈希函数。注意seedHash()中利用生成的哈希函数keccak256()对seed[]做的原地哈希，而原地哈希运算的次数跟当前区块所处的epoch序号有关，所以每个不同的cache{}所用到的seed[]也是完全不同的，这个不同通过更多次的哈希运算来实现。
generateCache()函数
generateCache()函数在给定种子数组seed[]的情况下，对固定容量的一块buffer进行一系列操作，使得buffer的数值分布变得随机、无规律可循，最终buffer作为cache{}中的数组(非线性表)返回，还可作为数据源帮助生成dataset{}。generateCache()函数主体分两部分，首先用SHA3-512哈希函数作为哈希生成器(hasher)，对buffer数组分段(每次64bytes)进行哈希化，然后利用StrictMemoryHardFunction中的RandMemoHash算法对buffer再进行处理。这个RandMemoHash算法来自2014年密码学方向的一篇学术论文，有兴趣的朋友可以搜搜看。
内存映射
由于Ethash(PoW)算法中用到的随机数据集cache{}和dataset{}过于庞大，将其以文件形式存储在磁盘上就显得很有必要。同样由于这些文件过于庞大，使用时又需要一次性整体读入内存(因为对其的使用是随意截取其中的一段数据)，使用内存映射可以大大减轻I/O负担。cache{}和dataset{}结构体中，均有一个mmap对象用以操作内存映射，以及一个系统文件对象dump，对应于打开的磁盘文件。
Ethash算法总结：
回看一下Ethash共识算法最基本的形态，如果把整个result[]的生成过程视作那个概念上的函数RAND()，则如何能更加随机，分布更加均匀的生成数组，关系到整个Ethash算法的安全性。毕竟如果result[]生成过程存在被破译的途径，那么必然有方法可以更快地找到符合条件的数组，通过更快的挖掘出区块，在整个以太坊系统中逐渐占据主导。所以Ethash共识算法应用了非常复杂的一系列运算，包含了多次、多种不同的哈希函数运算：
1. 大量使用SHA3哈希函数，包括256-bit和512-bit形式的，用它们来对数据（组）作哈希运算，或者充当其他更复杂哈希计算的某个原型 -- 比如调用makeHasher()。而SHA3哈希函数，是一种典型的可应对长度变化的输入数据的哈希函数，输出结果长度统一(可指定256bits或512bits)。
2. lookup()函数提供了非线性表格查找方式的哈希函数，相关联的dataset{}和cache{}规模巨大，其中数据的生成/填充过程中也大量使用哈希函数。
3. 在一些计算过程中，有意将[]byte数组转化为uint32或uint64整型数进行操作(比如XOR，以及类XOR的FNV()函数)。因为理论证实，在32位或64位CPU机器上，以32位/64位整型数进行操作时，速度更快。
Clique共识算法
Clique算法又称Proof-of-Authortiy(PoA)，它实现的Seal()其实是一个标准的数字签名加密过程，可由下列公式表示：
n = F(pr, h)
其中F()是数字签名函数，n是生成的数字签名，pr是公钥，h是被加密的内容。具体到Clique应用中，n是一个65 bytes长的字符串，pr是一个common.Address类型的（长度20 bytes）地址，h是一个common.Hash类型(32 bytes)的哈希值，而签名算法F()，目前采用的正是椭圆曲线数字签名算法(ECDSA)。
没错，就是这个被用来生成交易(Transaction)对象的数字签名的ECDSA。在Clique的实现中，这里用作公钥的Address类型地址有一个限制，它必须是已认证的(authorized)。所以Clique.Seal()函数的基本逻辑就是：有一个Address类型地址打算用作数字签名的公钥(不是区块的作者地址Coinbase)；如果它是已认证的，则执行指定的数字签名算法。而其中涉及到的动态管理所有认证地址的机制，才是Clique算法(PoA)的精髓。
基于投票的地址认证机制
首先了解一下Clique的认证机制authorization所包括的一些设定：
1. 所有的地址(Address类型)分为两类，分别是经过认证的，和未经过认证的。
2. 已认证地址(authorized)可以变成未认证的，反之亦然。不过这些变化都必须通过投票机制完成。
3. 一张投票包括：投票方地址，被投票地址，和被投票地址的新认证状态。有效投票必须满足：被投票地址的新认证地址与其现状相反。
4. 任意地值A只能给地址B投一张票
这些设定理解起来并不困难，把这里的地址替换成平常生活中的普通个体，这就是个很普通的投票制度。Clique算法中的投票系统的巧妙之处在于，每张投票并不是某个投票方主动“投”出来的，而是随机组合出来的。
想了解更多细节免不了要深入一些代码，下图是Clique算法中用到的一些结构体：