- func (s *Ethereum) StartMining(local bool) error {1 f4 M% `6 e4 \7 x
- eb, err := s.Etherbase()//用户地址+ p1 y- U# u6 A; y) f6 t
- if err != nil {! t; }0 y$ y: o/ U* Y
- log.Error("Cannot start mining without etherbase", "err", err)' w) j% f( K* a4 \4 i9 [" K/ r
- return fmt.Errorf("etherbase missing: %v", err)+ L+ {0 q! {$ ^. B v9 I3 s
- }5 C+ h& q: T' I& q! n. u6 K( J
- if clique, ok := s.engine.(*clique.Clique); ok {
- //如果是clique共识算法
- wallet, err := s.accountManager.Find(accounts.Account{Address: eb}) // 根据用它胡地址获取wallet对象* K* ]3 ]5 o/ o$ n3 x
- if wallet == nil || err != nil {
- log.Error("Etherbase account unavailable locally", "err", err)
- return fmt.Errorf("signer missing: %v", err)" w4 |# o! \( r4 b0 t) W
- }( i8 [5 F3 \9 P6 Z1 j) b: s
- clique.Authorize(eb, wallet.SignHash) // 注入签名者以及wallet对象获取签名方法
- }
- if local {
- // 如果本地CPU已开始挖矿,我们可以禁用引入的交易拒绝机制来加速同步时间。CPU挖矿在主网是荒诞的,所以没有人能碰到这个路径,然而一旦CPU挖矿同步标志完成以后,将保证私网工作也在一个独立矿工结点。
- atomic.StoreUint32(&s.protocolManager.acceptTxs, 1)% [ [- V% Q* i8 J
- }+ O. i- `5 O: L/ h+ e8 m" S* A
- go s.miner.Start(eb)$ H) h: s- R) v) V6 I% {
- return nil' L9 y% a( C$ q7 h; u/ y6 i8 `" L) T
- }
这个StartMining会在miner.start前调用,然后通过woker -> agent -> CPUAgent -> update -> seal 挖掘区块和组装(后面会写单独的文章来对挖矿过程做源码分析)。; y/ {- e& ]. ]/ S; P
Clique的代码块在go-ethereum/consensus/clique路径下。和ethash一样,在clique.go 中实现了consensus的接口, consensus 定义了下面这些接口:! E) {" M( W3 B+ F& i( y
type Engine interface {# |9 q5 \" k: F5 d& R J
Author(header *types.Header) (common.Address, error)' l5 g1 z1 X* a% C, w
VerifyHeader(chain ChainReader, header *types.Header, seal bool) error/ u2 x; l2 p1 K1 s& s' |% F
VerifyHeaders(chain ChainReader, headers []*types.Header, seals []bool) (chan
Engine.Seal()函数可对一个调用过 Finalize()的区块进行授权或封印,成功时返回的区块全部成员齐整,可视为一个正常区块,可被广播到整个网络中,也可以被插入区块链等。对于挖掘一个新区块来说,所有相关代码里 Engine.Seal()是其中最重要最复杂的一步,所以这里我们首先来看下Clique 结构体:
- type Clique struct {
- config *params.CliqueConfig // 共识引擎配置参数
- db ethdb.Database // 数据库,用来存储和获取快照检查点- F) m- M2 j0 N w
- recents *lru.ARCCache // 最近区块快照,加速快照重组
- signatures *lru.ARCCache // 最近区块签名,加速挖矿& G8 W2 o6 \( ^2 @% D3 i
- proposals map[common.Address]bool // 目前正在推送的提案4 Z$ \+ m' a+ o
- signer common.Address // 签名者的以太坊地址! W' ]5 x) ~- l
- signFn SignerFn // 授权哈希的签名方法* V0 w6 R. Z4 i- e" f8 O% @2 \" G
- lock sync.RWMutex // 用锁来保护签名字段1 N6 |3 K) \. w
- }
顺便来看下CliqueConfig共识引擎的配置参数结构体:. y8 M* k5 z: w Z3 b
- type CliqueConfig struct {' E. }* B5 @2 I/ k' E
- Period uint64 `json:"period"` // 在区块之间执行的秒数(比如出块秒数15s)( c3 B+ l% K& C/ h0 u$ C
- Epoch uint64 `json:"epoch"` // Epoch长度,重置投票和检查点(比如Epoch长度是30000个block, 每次进入新的epoch,前面的投票都被清空, 重新开始记录)0 Y% t- o: z9 s( m
- }
在上面的 StartMining中,通过Clique. Authorize来注入签名者和签名方法,先来看下Authorize:
- func (c *Clique) Authorize(signer common.Address, signFn SignerFn) { b" q( \9 T# l- Q# [: x6 ~( ?
- c.lock.Lock()0 h8 v% ?$ y. `$ j+ }: M' X
- defer c.lock.Unlock()
- // 这个方法就是为clique共识注入一个签名者的私钥地址已经签名函数用来挖出新块" I9 S% L* v, K
- c.signer = signer0 R, n; R: y& a4 F- Y1 ]+ Q8 k' {! w
- c.signFn = signFn
- }
再来看Clique的Seal()函数的具体实现:: Z% p$ J; T0 e3 X
//通过本地签名认证创建已密封的区块
func (c *Clique) Seal(chain consensus.ChainReader, block *types.Block, stop number-limit {
log.Info("Signed recently, must wait for others"), S4 Q. f2 s" M4 s* c& H( D
Seal是共识引擎的入口之一,该函数通过clique.signer对区块签名' X( I2 D; ^4 S+ ~9 o. ?
signer不在snapshot的signer中不允许签名2 F$ q5 ?% _% i& r; Y
signer不是本区块的签名者需要延时随机一段时候后再签名,是本区块的签名者则直接签名
签名存放在Extra的extraSeal的65个字节中! T( A6 ?8 V$ F9 o; k" Q
关于机会均等 为了使得出块的负载(或者说是机会)对于每个认证节点尽量均等,同时避免某些恶意节点持续出块,clique中规定每一个认证节点在连续SIGNER_LIMIT个区块中,最多只能签发一个区块,也就是说,每一轮中,最多只有SIGNER_COUNT - SIGNER_LIMIT个认证节点可以参与区块签发。 其中SIGNER_LIMIT = floor(SIGNER_COUNT / 2) + 1,SIGNER_COUNT表示认证节点的个数。
- //snap.Signers是所有的认证节点( L& I5 N h+ c+ O) t
- for seen, recent := range snap.Recents {$ G/ _( n; i9 C3 F. e* c ?* X+ l
- if recent == signer {3 ~7 V5 @6 l9 O& M
- if limit := uint64(len(snap.Signers)/2 + 1); number number-limit {
- log.Info("Signed recently, must wait for others")
/ e1 x! b" w1 V G& l" L
在保证好节点的个数大于坏节点的前提下,好节点最少的个数为SIGNER_LIMIT(大于50%),坏节点最多的个数为SIGNER_COUNT - SIGNER_LIMIT(小于50%)。一个节点在SIGNER_LIMIT这个时间窗口内最多只能签发一个区块,这就使得恶意节点在不超过50%的情况下,从理论上无法一直掌握区块的签发权。
关于难度计算 为了让每个认证节点都有均等的机会去签发一个区块,每个节点在签发时都会判断本节点是不是本轮的inturn节点,若是inturn节点,则该节点产生的区块难度为2,否则为1。每一轮仅有一个节点为inturn节点。
diffInTurn = big.NewInt(2) $ \* h1 b" o/ P' _# i+ Y5 R+ U
diffNoTurn = big.NewInt(1) ; n: @- F( U: s3 M) ^
当inturn的结点离线时,其他结点会来竞争,难度值降为1。然而正常出块时,limit中的所有认证结点包括一个inturn和其他noturn的结点,clique是采用了给noturn加延迟时间的方式来支持inturn首先出块,避免noturn的结点无谓生成区块,上面的延时代码段已经有提现了。 判断是否为inturn的节点,将本地维护的认证节点按照字典序排序,若当前区块号除以认证节点个数的余数等于该节点的下标,则该节点为inturn节点。代码实现在 snapshot.go中:
// 通过给定的区块高度和签发者返回该签发者是否在轮次内
- func (s *Snapshot) inturn(number uint64, signer common.Address) bool {
- signers, offset := s.signers(), 04 h' k! a$ n/ N" i' X" A; {: _
- for offset
Seal()代码中有获取快照,然后从快照中来检查授权区块签名者的逻辑,那么我们继续来看下Snapshot,首先看下Snapshot的结构体:% k' ? {$ k9 p" p- `, B* E+ B
// Snapshot对象是在给定时间点的一个认证投票的状态3 f7 E! R. q" |: z
- type Snapshot struct {* ~% D, q1 X7 u' R3 ~% H
- config *params.CliqueConfig // 共识引擎配置参数7 I; U: b9 q* m0 \& r; S. N
- sigcache *lru.ARCCache // 签名缓存,最近的区块签名加速恢复。6 q# u& J6 K1 d2 s0 }7 _
- Number uint64 `json:"number"` // 快照建立的区块号
- Hash common.Hash `json:"hash"` // 快照建立的区块哈希4 T/ Z9 Y% L1 F. d" a! c$ q; {9 s# F
- Signers map[common.Address]struct{} `json:"signers"` // 当下认证签名者的列表6 ?- N6 J9 ^1 `! u% {9 D7 m
- Recents map[uint64]common.Address `json:"recents"` // 最近担当过数字签名算法的signer 的地址0 ]* I5 }0 d# w$ M
- Votes []*Vote `json:"votes"` // 按时间顺序排列的投票名单。
- Tally map[common.Address]Tally `json:"tally"` // 当前的投票结果,避免重新计算。
- }
快照Snapshot对象中存在投票的Votes和记票的Tally对象:
- // Vote代表了一个独立的投票,这个投票可以授权一个签名者,更改授权列表。 N: c) l5 M' O. \7 a& q
- type Vote struct {
- Signer common.Address `json:"signer"` // 已授权的签名者(通过投票)
- Block uint64 `json:"block"` // 投票区块号3 w3 ?, K! A `6 `8 m
- Address common.Address `json:"address"` // 被投票的账户,修改它的授权* M+ C- m+ S8 G' h0 J* i( \
- Authorize bool `json:"authorize"` // 对一个被投票账户是否授权或解授权. C7 X4 i* ^8 y, `
- }/ S# a+ c4 k9 a/ M. Q, v, F
- // Tally是一个简单的用来保存当前投票分数的计分器% n! q: u5 T3 ]! Y1 o* h' O2 G
- type Tally struct {
- Authorize bool `json:"authorize"` // 授权true或移除false
- Votes int `json:"votes"` // 该提案已获票数" ~% K6 R% `. \
- }
Snapshot是一个快照,不仅是一个缓存,而且存储了最近签名者的map loadSnapshot用来从数据库中加载一个已存在的快照:+ ^ K9 G& g9 ^0 l) P& B$ B
- func loadSnapshot(config *params.CliqueConfig, sigcache *lru.ARCCache, db ethdb.Database, hash common.Hash) (*Snapshot, error) {
- //使用Database接口的Get方法通过Key来查询缓存内容
- blob, err := db.Get(append([]byte("clique-"), hash[:]...))
- if err != nil {
- return nil, err$ M( O, `5 } T `5 E! `
- }! V' q- q' |9 M! v# U
- snap := new(Snapshot)
- if err := json.Unmarshal(blob, snap); err != nil {/ y7 P& I" @5 n; \2 ]/ ^7 v* J; B
- return nil, err
- }/ x! T! m J3 j. ]8 v
- snap.config = config
- snap.sigcache = sigcache' u# @8 r* I* a
- return snap, nil6 V, D; j' y ?% I
- }
newSnapshot函数用于创建快照,这个方法没有初始化最近的签名者集合,所以只使用创世块:
- func newSnapshot(config *params.CliqueConfig, sigcache *lru.ARCCache, number uint64, hash common.Hash, signers []common.Address) *Snapshot {) g( H$ Q; {( K5 t$ {
- //组装一个Snapshot对象
- snap := &Snapshot{5 r. s/ V% n+ y6 _$ ]: t
- config: config,: s+ M8 G! P7 I
- sigcache: sigcache,& I9 l0 v* e, s# E& H& l+ v
- Number: number,( P/ _7 v) q1 O# ?" ^6 G$ N8 m$ F
- Hash: hash,
- Signers: make(map[common.Address]struct{}),
- Recents: make(map[uint64]common.Address),
- Tally: make(map[common.Address]Tally),/ ]! N8 R( c% @( _& r( b
- }
- for _, signer := range signers {
- snap.Signers[signer] = struct{}{}
- }) a8 }& v; J8 r! e
- return snap+ R- d% @! m8 `. O
- }
继续看下snapshot函数的具体实现:" W/ U5 A7 y5 c# ?; \
- // 快照会在给定的时间点检索授权快照 s, x z6 _( }2 b& h; B
- func (c *Clique) snapshot(chain consensus.ChainReader, number uint64, hash common.Hash, parents []*types.Header) (*Snapshot, error) {& [: N ~* a) q
- // 在内存或者磁盘上查找一个快照来检查检查点checkpoints7 A8 P3 G$ y+ ~- Y
- var ($ ?# @ d; I0 d# z7 Y7 i' \( o
- headers []*types.Header //区块头2 p1 J" y7 W b2 M {9 x4 O0 f: ~
- snap *Snapshot //快照对象
- )% V5 [ a! [' O7 q5 N s' J
- for snap == nil {
- // 如果在内存中找到快照时,快照对象从内存中取
- if s, ok := c.recents.Get(hash); ok {2 ?5 g" r( j: X( z5 o, C [0 V
- snap = s.(*Snapshot)/ j _0 s% \' |. P6 H
- break" f4 y2 Q3 P, \* h, r& C
- } M5 l) h2 F4 }$ v1 C* Z
- // 如果在磁盘检查点找到快照时
- if number%checkpointInterval == 0 { //checkpointInterval = 1024 表示投票快照保存到数据库的区块的区块号
- if s, err := loadSnapshot(c.config, c.signatures, c.db, hash); err == nil {
- log.Trace("Loaded voting snapshot form disk", "number", number, "hash", hash): |* l# v4 e' W) s
- snap = s9 z1 j2 l2 r! F
- break1 c* n5 n$ T/ R3 n% W; d( f
- }
- }
- // 如果在创世块,则新建一个快照
- if number == 0 {
- genesis := chain.GetHeaderByNumber(0)& Q: n: A& b! J0 |
- if err := c.VerifyHeader(chain, genesis, false); err != nil {
- return nil, err. w' q$ b% W$ g/ Z& w+ a6 |
- }$ W8 f; A- ?! ~
- signers := make([]common.Address, (len(genesis.Extra)-extraVanity-extraSeal)/common.AddressLength)
- for i := 0; i 0 {
- // 如果我们有明确的父,从那里挑选(强制执行)& q3 L' i+ n+ J
- header = parents[len(parents)-1]1 s% _8 O4 @) e' {8 C9 ^" M/ S
- if header.Hash() != hash || header.Number.Uint64() != number {; T9 o* r/ W! Q0 `
- return nil, consensus.ErrUnknownAncestor" [# R% B/ q% X& _3 S
- }8 _: Q n z; N9 ~
- parents = parents[:len(parents)-1]
- } else {& p# [( X d& F' J0 @0 Q" u
- // 没有明确的父(或者没有更多的父)转到数据库获取
- header = chain.GetHeader(hash, number)
- if header == nil {
- return nil, consensus.ErrUnknownAncestor
- }
- }9 Y; @9 @& v5 S% t' b
- headers = append(headers, header)6 m8 q; E. d6 D0 @% r4 Z
- number, hash = number-1, header.ParentHash$ d9 u% i% x5 a/ Z% T# B1 p9 c
- }$ e5 g1 p; X' e
- // 找到了之前的快照,将所有的pedding块头放在它上面
- for i := 0; i 0 {/ d! v) @; `+ I, y; N. }7 O
- if err = snap.store(c.db); err != nil {0 N; z" Y( Q7 D2 H: N
- return nil, err0 A( w+ q2 H1 R1 u5 o
- }/ h7 Q+ J' U+ h
- log.Trace("Stored voting snapshot to disk", "number", snap.Number, "hash", snap.Hash): N l' f; l6 L2 W
- }0 A% m1 [6 R# ?$ y" t, e [4 y
- return snap, err0 G4 n) a+ D: h8 s' D
- }
在snapshot中,snap.apply通过区块头来创建一个新的快照,这个apply中主要做什么操作?
- //apply将给定的区块头应用于原始头来创建新的授权快照。
- func (s *Snapshot) apply(headers []*types.Header) (*Snapshot, error) {
- //可以传空区块头* x" r% F7 c8 I
- if len(headers) == 0 {! c r' T+ h* v
- return s, nil
- }3 i7 p6 O4 S2 W
- //完整性检查区块头可用性
- for i := 0; i = limit {
- delete(snap.Recents, number-limit)
- }
- // 从区块头中解密出来签名者地址
- signer, err := ecrecover(header, s.sigcache)
- if err != nil {; D* {# q+ t2 @
- return nil, err
- }
- if _, ok := snap.Signers[signer]; !ok {
- return nil, errUnauthorized
- }
- for _, recent := range snap.Recents {5 c0 U1 m" |9 c- f7 A3 q8 }6 P
- if recent == signer {
- return nil, errUnauthorized
- }/ p- \; l( g9 k& I
- }) n" X2 W3 t8 O# F, k) H
- snap.Recents[number] = signer
- // 区块头认证,不管该签名者之前的任何投票
- for i, vote := range snap.Votes {
- if vote.Signer == signer && vote.Address == header.Coinbase {0 b, }* r4 }/ K4 j3 q5 _
- // 从缓存计数器中移除该投票
- snap.uncast(vote.Address, vote.Authorize)
- // 从按时间排序的列表中移除投票5 w. c% |" |$ m& |) |
- snap.Votes = append(snap.Votes[:i], snap.Votes[i+1:]...)
- break // 只允许一票
- }
- }
- // 从签名者中计数新的投票1 c% k# v0 B/ F9 w6 l5 Z, M+ [
- var authorize bool" q/ N- Y1 ^ [' k+ Y
- switch {) z; J0 Z& u: [2 n/ u$ A
- case bytes.Equal(header.Nonce[:], nonceAuthVote):
- authorize = true U6 z+ B9 _9 m7 M
- case bytes.Equal(header.Nonce[:], nonceDropVote):
- authorize = false
- default:( A3 x5 S1 M) R' a7 o2 p3 K
- return nil, errInvalidVote/ Q0 Q3 H7 @1 [5 u: a
- }
- if snap.cast(header.Coinbase, authorize) {
- snap.Votes = append(snap.Votes, &Vote{1 H; H. g: x- K! b3 p7 O
- Signer: signer,% a: N& V( ~$ h8 Z
- Block: number,8 }4 f! p& T( a4 O
- Address: header.Coinbase,. R% I' f# R6 _( o# B
- Authorize: authorize,
- })
- }
- // 判断票数是否超过一半的投票者,如果投票通过,更新签名者列表. o6 U5 y" g* S P3 ?1 @1 H% q8 Z
- if tally := snap.Tally[header.Coinbase]; tally.Votes > len(snap.Signers)/2 {) U7 k# T8 X# E7 O" j+ h
- if tally.Authorize {
- snap.Signers[header.Coinbase] = struct{}{}
- } else {! ~" D0 X* D' k9 p2 ]% j
- delete(snap.Signers, header.Coinbase)$ P8 S" F, h5 n% u9 a) Y* i
- // 签名者列表缩减,删除最近剩余的缓存
- if limit := uint64(len(snap.Signers)/2 + 1); number >= limit {
- delete(snap.Recents, number-limit)# h, `5 E. a# P. e! S5 \8 K
- }+ o( i0 f5 {4 O) }4 G& T. Z
- for i := 0; i
Snapshot.apply()方法的主要部分是迭代处理每个header对象,首先从数字签名中恢复出签名所用公钥,转化为common.Address类型,作为signer地址。数字签名(signagure)长度65 bytes,存放在Header.Extra[]的末尾。如果signer地址是尚未认证的,则直接退出本次迭代;如果是已认证的,则投票+1。所以一个父区块可添加一张记名投票,signer作为投票方地址,Header.Coinbase作为被投票地址,投票内容authorized可由Header.Nonce取值确定。更新投票统计信息。如果被投票地址的总投票次数达到已认证地址个数的一半,则通过之。该被投票地址的认证状态立即被更改,根据是何种更改,相应的更新缓存数据,并删除过时的投票信息。在所有Header对象都被处理完后,Snapshot内部的Number,Hash值会被更新,表明当前Snapshot快照结构已经更新到哪个区块了。7 U4 l0 o+ g5 S. c3 y3 m' Z. B8 J
区块验证的过程是普通节点在收到一个新区块时,会从区块头的extraData字段中取出认证节点的签名,利用标准的spec256k1椭圆曲线进行反解公钥信息,并且从公钥中截取出签发节点的地址,若该节点是认证节点,且该节点本轮拥有签名的权限,则认为该区块为合法区块。verifySeal是被SubmitWork(miner/remote_agent.go) 来调用,SubmitWork函数尝试注入一个pow解决方案(共识引擎)到远程代理,返回这个解决方案是否被接受。(不能同时是一个坏的pow也不能有其他任何错误,例如没有工作被pending)解决方案有效时,返回到矿工并且通知接受结果。- k! C/ @- E* q k7 Q: X
- // 检查包头中包含的签名是否满足共识协议要求。该方法接受一个可选的父头的列表,这些父头还不是本地区块链的一部分,用于生成快照
- func (c *Clique) verifySeal(chain consensus.ChainReader, header *types.Header, parents []*types.Header) error {, B4 |: h# C J; _
- // 不支持校检创世块4 n1 Z3 F! K. t+ D/ H$ C
- number := header.Number.Uint64()
- if number == 0 {
- return errUnknownBlock8 a2 G8 y7 n1 k, ?) R2 D& K
- }
- // 检索出所需的区块对象来校检去开头和将其缓存9 C. b/ y: |" L4 s2 z, B: L: h6 o
- snap, err := c.snapshot(chain, number-1, header.ParentHash, parents)" n( ?1 u+ g8 n* m
- if err != nil {3 T+ K3 Y0 c H' a
- return err ~7 r' V' P u- w' _/ N- W
- }
- //解析授权密钥并检查签署者,ecrecover方法从区块头中反解出Extra字段中签名字符串来获取签名者地址
- signer, err := ecrecover(header, c.signatures)7 T9 e8 Z" J7 Y1 X7 O( ~3 B9 N
- if err != nil {
- return err
- }
- if _, ok := snap.Signers[signer]; !ok {
- return errUnauthorized
- }
- for seen, recent := range snap.Recents {
- if recent == signer {
- // 签署者是最近的,只有当前块没有移出时才会失败,参见seal中的机会均等5 |2 {) P# ]6 b# U
- if limit := uint64(len(snap.Signers)/2 + 1); seen > number-limit {4 J2 P% d; k- s( z- B
- return errUnauthorized/ S8 F5 k, ` }
- }
- }
- }2 s+ E( u O7 i6 a- v
- // 设置区块难度,参见上面的区块难度部分
- inturn := snap.inturn(header.Number.Uint64(), signer)
- if inturn && header.Difficulty.Cmp(diffInTurn) != 0 {
- return errInvalidDifficulty9 b' H! R- e9 Y) s" F8 @$ x
- } c5 D! q8 {: y' z7 I* v5 v
- if !inturn && header.Difficulty.Cmp(diffNoTurn) != 0 {/ N) c' u6 K" e+ I
- return errInvalidDifficulty* f3 h: O; J9 {0 s
- }
- return nil+ r# p+ v( p7 g
- }
前面已经分析了Clique的认证节点的出块和校检的过程,那么如何来区分一个节点是认证节点还是一个普通节点?以及一个授权者列表是如何产生并如何全网同步的?
Clique通过投票机制来确认一个认证节点,投票的范围在委员会中,委员会就是所有节点矿工集合,普通节点没有区块生成权利。矿工的投票流程如下:
委员会节点通过RPC调用Propose,对某节点状态变更,从普通节点变成认证阶段,或者相反,写入到Clique.purposal集合中4 d, R/ }5 e+ r+ Z
- // Propose注入一个新的授权提案,可以授权一个签名者或者移除一个。
- func (api *API) Propose(address common.Address, auth bool) {& s) |& M5 l$ B. ~
- api.clique.lock.Lock()
- defer api.clique.lock.Unlock()
- api.clique.proposals[address] = auth// true:授权,false:移除
- }
本地认证节点在一次区块打包的过程中,从purposal池中随机挑选一条还未被应用的purposal,并将信息填入区块头,将区块广播给其他节点;
- //Clique.Prepare' r- |* y6 N+ [3 o1 l
- // 抓取所有有意义投票的提案4 W3 F& X% p$ v6 t/ K# r4 o
- addresses := make([]common.Address, 0, len(c.proposals))8 d- Z) t, V! a1 L
- for address, authorize := range c.proposals {$ R7 R3 ]" Z. }1 ?* D7 q
- if snap.validVote(address, authorize) {3 a4 ]( A) U- ^
- addresses = append(addresses, address)7 I+ E# i( o/ C2 B
- }
- }+ k2 _8 K0 p( y# @; a7 s1 _
- // If there's pending proposals, cast a vote on them
- if len(addresses) > 0 {# }& {' Y& M- e" b- C$ f, K% I
- header.Coinbase = addresses[rand.Intn(len(addresses))] //随机挑选一条投票节点的地址赋值给区块头的Coinbase字段。
- // 通过提案内容来组装区块头的随机数字段。
- if c.proposals[header.Coinbase] {9 B0 w" V3 o9 g6 h$ X* F- c
- copy(header.Nonce[:], nonceAuthVote)& u. @# }+ e* \, i
- } else {
- copy(header.Nonce[:], nonceDropVote)
- }; C2 Q+ l: f1 D
- }
在挖矿开始以后,会在miner.start()中提交一个commitNewWork,其中调用上面Prepare7 G1 O T6 g" |2 A Y- W3 n
- if err := self.engine.Prepare(self.chain, header); err != nil {8 Z5 I* j: w- Z6 b- N" ?! u
- log.Error("Failed to prepare header for mining", "err", err)
- return
- }
其他节点在接收到区块后,取出其中的信息,封装成一个vote进行存储,并将投票结果应用到本地,若关于目标节点的状态更改获得的一致投票超过1/2,则更改目标节点的状态:若为新增认证节点,将目标节点的地址添加到本地的认证节点的列表中;若为删除认证节点,将目标节点的地址从本地的认证节点列表中删除。具体实现可以查看上面的Snapshot.apply()方法0 b" h. z/ q/ t, C, i* b* Y
9 O2 @9 O$ b) J9 N
5 U O z4 u* n7 H9 o/ @& C$ y7 Q
以太坊中除了基于运算能力的POW(Ethash)外,还有基于权利证明的POA共识机制,Clique是以太坊的POA共识算法的实现,这里主要对POA的Clique相关源码做一个解读分析。