摘要:以太坊中除了基于运算能力的外,还有基于权利证明的共识机制,是以太坊的共识算法的实现,这里主要对的相关源码做一个解读分析。检查包头中包含的签名是否满足共识协议
以太坊中除了基于运算能力的POW(Ethash)外,还有基于权利证明的POA共识机制,Clique是以太坊的POA共识算法的实现,这里主要对POA的Clique相关源码做一个解读分析。
Clique的初始化在 Ethereum.StartMining中,如果Ethereum.engine配置为clique.Clique, 根据当前节点的矿工地址(默认是acounts[0]), 配置clique的 签名者 : clique.Authorize(eb, wallet.SignHash) ,其中签名函数是SignHash,对给定的hash进行签名。
func (s *Ethereum) StartMining(local bool) error { eb, err := s.Etherbase()//用户地址 if err != nil { log.Error("Cannot start mining without etherbase", "err", err) return fmt.Errorf("etherbase missing: %v", err) } if clique, ok := s.engine.(*clique.Clique); ok { //如果是clique共识算法 wallet, err := s.accountManager.Find(accounts.Account{Address: eb}) // 根据用它胡地址获取wallet对象 if wallet == nil || err != nil { log.Error("Etherbase account unavailable locally", "err", err) return fmt.Errorf("signer missing: %v", err) } clique.Authorize(eb, wallet.SignHash) // 注入签名者以及wallet对象获取签名方法 } if local { // 如果本地CPU已开始挖矿,我们可以禁用引入的交易拒绝机制来加速同步时间。CPU挖矿在主网是荒诞的,所以没有人能碰到这个路径,然而一旦CPU挖矿同步标志完成以后,将保证私网工作也在一个独立矿工结点。 atomic.StoreUint32(&s.protocolManager.acceptTxs, 1) } go s.miner.Start(eb) return nil }
这个StartMining会在miner.start前调用,然后通过woker -> agent -> CPUAgent -> update -> seal 挖掘区块和组装(后面会写多带带的文章来对挖矿过程做源码分析)。
Clique的代码块在go-ethereum/consensus/clique路径下。和ethash一样,在clique.go 中实现了consensus的接口, consensus 定义了下面这些接口:
type Engine interface { Author(header *types.Header) (common.Address, error) VerifyHeader(chain ChainReader, header *types.Header, seal bool) error VerifyHeaders(chain ChainReader, headers []*types.Header, seals []bool) (chan<- struct{}, <-chan error) VerifyUncles(chain ChainReader, block *types.Block) error VerifySeal(chain ChainReader, header *types.Header) error Prepare(chain ChainReader, header *types.Header) error Finalize(chain ChainReader, header *types.Header, state *state.StateDB, txs []*types.Transaction, uncles []*types.Header, receipts []*types.Receipt) (*types.Block, error) Seal(chain ChainReader, block *types.Block, stop <-chan struct{}) (*types.Block, error) CalcDifficulty(chain ChainReader, time uint64, parent *types.Header) *big.Int APIs(chain ChainReader) []rpc.API }
Engine.Seal()函数可对一个调用过 Finalize()的区块进行授权或封印,成功时返回的区块全部成员齐整,可视为一个正常区块,可被广播到整个网络中,也可以被插入区块链等。对于挖掘一个新区块来说,所有相关代码里 Engine.Seal()是其中最重要最复杂的一步,所以这里我们首先来看下Clique 结构体:
type Clique struct { config *params.CliqueConfig // 共识引擎配置参数 db ethdb.Database // 数据库,用来存储和获取快照检查点 recents *lru.ARCCache // 最近区块快照,加速快照重组 signatures *lru.ARCCache // 最近区块签名,加速挖矿 proposals map[common.Address]bool // 目前正在推送的提案 signer common.Address // 签名者的以太坊地址 signFn SignerFn // 授权哈希的签名方法 lock sync.RWMutex // 用锁来保护签名字段 }
顺便来看下CliqueConfig共识引擎的配置参数结构体:
type CliqueConfig struct { Period uint64 `json:"period"` // 在区块之间执行的秒数(比如出块秒数15s) Epoch uint64 `json:"epoch"` // Epoch长度,重置投票和检查点(比如Epoch长度是30000个block, 每次进入新的epoch,前面的投票都被清空, 重新开始记录) }
在上面的 StartMining中,通过Clique. Authorize来注入签名者和签名方法,先来看下Authorize:
func (c *Clique) Authorize(signer common.Address, signFn SignerFn) { c.lock.Lock() defer c.lock.Unlock() // 这个方法就是为clique共识注入一个签名者的私钥地址已经签名函数用来挖出新块 c.signer = signer c.signFn = signFn }
再来看Clique的Seal()函数的具体实现:
//通过本地签名认证创建已密封的区块 func (c *Clique) Seal(chain consensus.ChainReader, block *types.Block, stop <-chan struct{}) (*types.Block, error) { header := block.Header() // 不密封创世块 number := header.Number.Uint64() if number == 0 { return nil, errUnknownBlock } // 不支持0-period的链,不支持空块密封,没有奖励但是能够密封 if c.config.Period == 0 && len(block.Transactions()) == 0 { return nil, errWaitTransactions } // 在整个密封区块的过程中不要持有signer签名者字段 c.lock.RLock() signer, signFn := c.signer, c.signFn //获取签名者和签名方法 c.lock.RUnlock() snap, err := c.snapshot(chain, number-1, header.ParentHash, nil) //调用获取快照 if err != nil { return nil, err } //检查我们是否被授权去签名一个区块 if _, authorized := snap.Signers[signer]; !authorized { return nil, errUnauthorized } // 如果我们是在‘最近签名者’中则等待下一个区块 for seen, recent := range snap.Recents { if recent == signer { // 当前签名者在‘最近签名者’中,如果当前区块没有剔除他的话只能等待(这里涉及到机会均等) if limit := uint64(len(snap.Signers)/2 + 1); number < limit || seen > number-limit { log.Info("Signed recently, must wait for others") <-stop return nil, nil } } } // 好了,走到这说明协议已经允许我们来签名这个区块,等待我们的时间 delay := time.Unix(header.Time.Int64(), 0).Sub(time.Now()) // nolint: gosimple if header.Difficulty.Cmp(diffNoTurn) == 0 { // 这不是我们的轮次来签名,延迟一点,随机延迟,这样对于每一个签签名者来说来允许并发签名 wiggle := time.Duration(len(snap.Signers)/2+1) * wiggleTime delay += time.Duration(rand.Int63n(int64(wiggle))) log.Trace("Out-of-turn signing requested", "wiggle", common.PrettyDuration(wiggle)) } log.Trace("Waiting for slot to sign and propagate", "delay", common.PrettyDuration(delay)) select { case <-stop: return nil, nil case <-time.After(delay): } // 通过signFn签名函数开始签名 sighash, err := signFn(accounts.Account{Address: signer}, sigHash(header).Bytes()) if err != nil { return nil, err } //将签名结果替换保存在区块头的Extra字段中 copy(header.Extra[len(header.Extra)-extraSeal:], sighash) //通过区块头重新组装生成一个区块 return block.WithSeal(header), nil }
Seal是共识引擎的入口之一,该函数通过clique.signer对区块签名
signer不在snapshot的signer中不允许签名
signer不是本区块的签名者需要延时随机一段时候后再签名,是本区块的签名者则直接签名
签名存放在Extra的extraSeal的65个字节中
关于机会均等
为了使得出块的负载(或者说是机会)对于每个认证节点尽量均等,同时避免某些恶意节点持续出块,clique中规定每一个认证节点在连续SIGNER_LIMIT个区块中,最多只能签发一个区块,也就是说,每一轮中,最多只有SIGNER_COUNT - SIGNER_LIMIT个认证节点可以参与区块签发。
其中SIGNER_LIMIT = floor(SIGNER_COUNT / 2) + 1,SIGNER_COUNT表示认证节点的个数。
//snap.Signers是所有的认证节点 for seen, recent := range snap.Recents { if recent == signer { if limit := uint64(len(snap.Signers)/2 + 1); number < limit || seen > number-limit { log.Info("Signed recently, must wait for others") <-stop return nil, nil } } }
在保证好节点的个数大于坏节点的前提下,好节点最少的个数为SIGNER_LIMIT(大于50%),坏节点最多的个数为SIGNER_COUNT - SIGNER_LIMIT(小于50%)。一个节点在SIGNER_LIMIT这个时间窗口内最多只能签发一个区块,这就使得恶意节点在不超过50%的情况下,从理论上无法一直掌握区块的签发权。
关于难度计算
为了让每个认证节点都有均等的机会去签发一个区块,每个节点在签发时都会判断本节点是不是本轮的inturn节点,若是inturn节点,则该节点产生的区块难度为2,否则为1。每一轮仅有一个节点为inturn节点。
diffInTurn = big.NewInt(2) diffNoTurn = big.NewInt(1)
当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(), 0 for offset < len(signers) && signers[offset] != signer { offset++ } return (number % uint64(len(signers))) == uint64(offset) }
Seal()代码中有获取快照,然后从快照中来检查授权区块签名者的逻辑,那么我们继续来看下Snapshot,首先看下Snapshot的结构体:
// Snapshot对象是在给定时间点的一个认证投票的状态 type Snapshot struct { config *params.CliqueConfig // 共识引擎配置参数 sigcache *lru.ARCCache // 签名缓存,最近的区块签名加速恢复。 Number uint64 `json:"number"` // 快照建立的区块号 Hash common.Hash `json:"hash"` // 快照建立的区块哈希 Signers map[common.Address]struct{} `json:"signers"` // 当下认证签名者的列表 Recents map[uint64]common.Address `json:"recents"` // 最近担当过数字签名算法的signer 的地址 Votes []*Vote `json:"votes"` // 按时间顺序排列的投票名单。 Tally map[common.Address]Tally `json:"tally"` // 当前的投票结果,避免重新计算。 }
快照Snapshot对象中存在投票的Votes和记票的Tally对象:
// Vote代表了一个独立的投票,这个投票可以授权一个签名者,更改授权列表。 type Vote struct { Signer common.Address `json:"signer"` // 已授权的签名者(通过投票) Block uint64 `json:"block"` // 投票区块号 Address common.Address `json:"address"` // 被投票的账户,修改它的授权 Authorize bool `json:"authorize"` // 对一个被投票账户是否授权或解授权 } // Tally是一个简单的用来保存当前投票分数的计分器 type Tally struct { Authorize bool `json:"authorize"` // 授权true或移除false Votes int `json:"votes"` // 该提案已获票数 }
Snapshot是一个快照,不仅是一个缓存,而且存储了最近签名者的map
loadSnapshot用来从数据库中加载一个已存在的快照:
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 } snap := new(Snapshot) if err := json.Unmarshal(blob, snap); err != nil { return nil, err } snap.config = config snap.sigcache = sigcache return snap, nil }
newSnapshot函数用于创建快照,这个方法没有初始化最近的签名者集合,所以只使用创世块:
func newSnapshot(config *params.CliqueConfig, sigcache *lru.ARCCache, number uint64, hash common.Hash, signers []common.Address) *Snapshot { //组装一个Snapshot对象 snap := &Snapshot{ config: config, sigcache: sigcache, Number: number, Hash: hash, Signers: make(map[common.Address]struct{}), Recents: make(map[uint64]common.Address), Tally: make(map[common.Address]Tally), } for _, signer := range signers { snap.Signers[signer] = struct{}{} } return snap }
继续看下snapshot函数的具体实现:
// 快照会在给定的时间点检索授权快照 func (c *Clique) snapshot(chain consensus.ChainReader, number uint64, hash common.Hash, parents []*types.Header) (*Snapshot, error) { // 在内存或者磁盘上查找一个快照来检查检查点checkpoints var ( headers []*types.Header //区块头 snap *Snapshot //快照对象 ) for snap == nil { // 如果在内存中找到快照时,快照对象从内存中取 if s, ok := c.recents.Get(hash); ok { snap = s.(*Snapshot) break } // 如果在磁盘检查点找到快照时 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) snap = s break } } // 如果在创世块,则新建一个快照 if number == 0 { genesis := chain.GetHeaderByNumber(0) if err := c.VerifyHeader(chain, genesis, false); err != nil { return nil, err } signers := make([]common.Address, (len(genesis.Extra)-extraVanity-extraSeal)/common.AddressLength) for i := 0; i < len(signers); i++ { copy(signers[i][:], genesis.Extra[extraVanity+i*common.AddressLength:]) } snap = newSnapshot(c.config, c.signatures, 0, genesis.Hash(), signers) if err := snap.store(c.db); err != nil { return nil, err } log.Trace("Stored genesis voting snapshot to disk") break } // 没有对于这个区块头的快照,收集区块头并向后移 var header *types.Header if len(parents) > 0 { // 如果我们有明确的父,从那里挑选(强制执行) header = parents[len(parents)-1] if header.Hash() != hash || header.Number.Uint64() != number { return nil, consensus.ErrUnknownAncestor } parents = parents[:len(parents)-1] } else { // 没有明确的父(或者没有更多的父)转到数据库获取 header = chain.GetHeader(hash, number) if header == nil { return nil, consensus.ErrUnknownAncestor } } headers = append(headers, header) number, hash = number-1, header.ParentHash } // 找到了之前的快照,将所有的pedding块头放在它上面 for i := 0; i < len(headers)/2; i++ { headers[i], headers[len(headers)-1-i] = headers[len(headers)-1-i], headers[i] } snap, err := snap.apply(headers) //通过区块头生成一个新的快照 if err != nil { return nil, err } c.recents.Add(snap.Hash, snap) //将当前区块的区块hash保存到最近区块快照,加速快照重组 // 如果我们已经生成一个新的检查点快照,保存在磁盘上 if snap.Number%checkpointInterval == 0 && len(headers) > 0 { if err = snap.store(c.db); err != nil { return nil, err } log.Trace("Stored voting snapshot to disk", "number", snap.Number, "hash", snap.Hash) } return snap, err }
在snapshot中,snap.apply通过区块头来创建一个新的快照,这个apply中主要做什么操作?
//apply将给定的区块头应用于原始头来创建新的授权快照。 func (s *Snapshot) apply(headers []*types.Header) (*Snapshot, error) { //可以传空区块头 if len(headers) == 0 { return s, nil } //完整性检查区块头可用性 for i := 0; i < len(headers)-1; i++ { if headers[i+1].Number.Uint64() != headers[i].Number.Uint64()+1 { return nil, errInvalidVotingChain } } if headers[0].Number.Uint64() != s.Number+1 { return nil, errInvalidVotingChain } //迭代区块头,创建一个新的快照 snap := s.copy() // 投票的处理核心代码 for _, header := range headers { // 删除检查点区块的所有投票 number := header.Number.Uint64() // 如果区块高度正好在Epoch结束,则清空投票和计分器,避免了维护统计信息无限增大的内存开销; if number%s.config.Epoch == 0 { snap.Votes = nil snap.Tally = make(map[common.Address]Tally) } //从最近的签名者列表中删除最旧的签名者以允许它再次签名 if limit := uint64(len(snap.Signers)/2 + 1); number >= limit { delete(snap.Recents, number-limit) } // 从区块头中解密出来签名者地址 signer, err := ecrecover(header, s.sigcache) if err != nil { return nil, err } if _, ok := snap.Signers[signer]; !ok { return nil, errUnauthorized } for _, recent := range snap.Recents { if recent == signer { return nil, errUnauthorized } } snap.Recents[number] = signer // 区块头认证,不管该签名者之前的任何投票 for i, vote := range snap.Votes { if vote.Signer == signer && vote.Address == header.Coinbase { // 从缓存计数器中移除该投票 snap.uncast(vote.Address, vote.Authorize) // 从按时间排序的列表中移除投票 snap.Votes = append(snap.Votes[:i], snap.Votes[i+1:]...) break // 只允许一票 } } // 从签名者中计数新的投票 var authorize bool switch { case bytes.Equal(header.Nonce[:], nonceAuthVote): authorize = true case bytes.Equal(header.Nonce[:], nonceDropVote): authorize = false default: return nil, errInvalidVote } if snap.cast(header.Coinbase, authorize) { snap.Votes = append(snap.Votes, &Vote{ Signer: signer, Block: number, Address: header.Coinbase, Authorize: authorize, }) } // 判断票数是否超过一半的投票者,如果投票通过,更新签名者列表 if tally := snap.Tally[header.Coinbase]; tally.Votes > len(snap.Signers)/2 { if tally.Authorize { snap.Signers[header.Coinbase] = struct{}{} } else { delete(snap.Signers, header.Coinbase) // 签名者列表缩减,删除最近剩余的缓存 if limit := uint64(len(snap.Signers)/2 + 1); number >= limit { delete(snap.Recents, number-limit) } for i := 0; i < len(snap.Votes); i++ { if snap.Votes[i].Signer == header.Coinbase { // 从缓存计数器中移除该投票 snap.uncast(snap.Votes[i].Address, snap.Votes[i].Authorize) // 从按时间排序的列表中移除投票 snap.Votes = append(snap.Votes[:i], snap.Votes[i+1:]...) i-- } } } // 不管之前的任何投票,直接改变账户 for i := 0; i < len(snap.Votes); i++ { if snap.Votes[i].Address == header.Coinbase { snap.Votes = append(snap.Votes[:i], snap.Votes[i+1:]...) i-- } } delete(snap.Tally, header.Coinbase) } } snap.Number += uint64(len(headers)) snap.Hash = headers[len(headers)-1].Hash() return snap, nil }
Snapshot.apply()方法的主要部分是迭代处理每个header对象,首先从数字签名中恢复出签名所用公钥,转化为common.Address类型,作为signer地址。数字签名(signagure)长度65 bytes,存放在Header.Extra[]的末尾。如果signer地址是尚未认证的,则直接退出本次迭代;如果是已认证的,则投票+1。所以一个父区块可添加一张记名投票,signer作为投票方地址,Header.Coinbase作为被投票地址,投票内容authorized可由Header.Nonce取值确定。更新投票统计信息。如果被投票地址的总投票次数达到已认证地址个数的一半,则通过之。该被投票地址的认证状态立即被更改,根据是何种更改,相应的更新缓存数据,并删除过时的投票信息。在所有Header对象都被处理完后,Snapshot内部的Number,Hash值会被更新,表明当前Snapshot快照结构已经更新到哪个区块了。
区块验证的过程是普通节点在收到一个新区块时,会从区块头的extraData字段中取出认证节点的签名,利用标准的spec256k1椭圆曲线进行反解公钥信息,并且从公钥中截取出签发节点的地址,若该节点是认证节点,且该节点本轮拥有签名的权限,则认为该区块为合法区块。verifySeal是被SubmitWork(miner/remote_agent.go) 来调用,SubmitWork函数尝试注入一个pow解决方案(共识引擎)到远程代理,返回这个解决方案是否被接受。(不能同时是一个坏的pow也不能有其他任何错误,例如没有工作被pending)解决方案有效时,返回到矿工并且通知接受结果。
// 检查包头中包含的签名是否满足共识协议要求。该方法接受一个可选的父头的列表,这些父头还不是本地区块链的一部分,用于生成快照 func (c *Clique) verifySeal(chain consensus.ChainReader, header *types.Header, parents []*types.Header) error { // 不支持校检创世块 number := header.Number.Uint64() if number == 0 { return errUnknownBlock } // 检索出所需的区块对象来校检去开头和将其缓存 snap, err := c.snapshot(chain, number-1, header.ParentHash, parents) if err != nil { return err } //解析授权密钥并检查签署者,ecrecover方法从区块头中反解出Extra字段中签名字符串来获取签名者地址 signer, err := ecrecover(header, c.signatures) if err != nil { return err } if _, ok := snap.Signers[signer]; !ok { return errUnauthorized } for seen, recent := range snap.Recents { if recent == signer { // 签署者是最近的,只有当前块没有移出时才会失败,参见seal中的机会均等 if limit := uint64(len(snap.Signers)/2 + 1); seen > number-limit { return errUnauthorized } } } // 设置区块难度,参见上面的区块难度部分 inturn := snap.inturn(header.Number.Uint64(), signer) if inturn && header.Difficulty.Cmp(diffInTurn) != 0 { return errInvalidDifficulty } if !inturn && header.Difficulty.Cmp(diffNoTurn) != 0 { return errInvalidDifficulty } return nil }
前面已经分析了Clique的认证节点的出块和校检的过程,那么如何来区分一个节点是认证节点还是一个普通节点?以及一个授权者列表是如何产生并如何全网同步的?
Clique通过投票机制来确认一个认证节点,投票的范围在委员会中,委员会就是所有节点矿工集合,普通节点没有区块生成权利。矿工的投票流程如下:
委员会节点通过RPC调用Propose,对某节点状态变更,从普通节点变成认证阶段,或者相反,写入到Clique.purposal集合中
// Propose注入一个新的授权提案,可以授权一个签名者或者移除一个。 func (api *API) Propose(address common.Address, auth bool) { api.clique.lock.Lock() defer api.clique.lock.Unlock() api.clique.proposals[address] = auth// true:授权,false:移除 }
本地认证节点在一次区块打包的过程中,从purposal池中随机挑选一条还未被应用的purposal,并将信息填入区块头,将区块广播给其他节点;
//Clique.Prepare // 抓取所有有意义投票的提案 addresses := make([]common.Address, 0, len(c.proposals)) for address, authorize := range c.proposals { if snap.validVote(address, authorize) { addresses = append(addresses, address) } } // If there"s pending proposals, cast a vote on them if len(addresses) > 0 { header.Coinbase = addresses[rand.Intn(len(addresses))] //随机挑选一条投票节点的地址赋值给区块头的Coinbase字段。 // 通过提案内容来组装区块头的随机数字段。 if c.proposals[header.Coinbase] { copy(header.Nonce[:], nonceAuthVote) } else { copy(header.Nonce[:], nonceDropVote) } }
在挖矿开始以后,会在miner.start()中提交一个commitNewWork,其中调用上面Prepare
if err := self.engine.Prepare(self.chain, header); err != nil { log.Error("Failed to prepare header for mining", "err", err) return }
其他节点在接收到区块后,取出其中的信息,封装成一个vote进行存储,并将投票结果应用到本地,若关于目标节点的状态更改获得的一致投票超过1/2,则更改目标节点的状态:若为新增认证节点,将目标节点的地址添加到本地的认证节点的列表中;若为删除认证节点,将目标节点的地址从本地的认证节点列表中删除。具体实现可以查看上面的Snapshot.apply()方法
转载请注明: 转载自Ryan是菜鸟 | LNMP技术栈笔记
如果觉得本篇文章对您十分有益,何不 打赏一下
本文链接地址: 以太坊POA共识机制Clique源码分析
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/24032.html
摘要:前言是以太坊封定义的一个接口,它的功能可以分为类验证区块类,主要用在将区块加入到区块链前,对区块进行共识验证。辅助类生成以太坊共识相关的。被使用,是以太坊状态管理服务,当报告数据的时候,需要获取区块的信息。 前言 engine是以太坊封定义的一个接口,它的功能可以分为3类: 验证区块类,主要用在将区块加入到区块链前,对区块进行共识验证。 产生区块类,主要用在挖矿时。 辅助类。 接下...
摘要:本文首发于深入浅出区块链社区原文链接以太坊创世区块与链配置载入分析,原文已更新,请读者前往原文阅读。以太坊允许通过创世配置文件来初始化创世区块,也可使用选择使用内置的多个网络环境的创世配置。再准备两个以太坊账户,以便在创世时存入资产。 本文首发于深入浅出区块链社区原文链接:以太坊创世区块与链配置载入分析,原文已更新,请读者前往原文阅读。 创世区块作为第零个区块,其他区块直接或间接引用到...
摘要:下面来看看具体是怎么实现接口的可以看到,启动了多个线程调用函数,当有线程挖到时,会通过传入的通道传出结果。可以看到在主要循环中,不断递增的值,调用函数计算上面公式中的左边,而则是公式的右边。 前言 挖矿(mine)是指矿工节点互相竞争生成新区块以写入整个区块链获得奖励的过程.共识(consensus)是指区块链各个节点对下一个区块的内容形成一致的过程在以太坊中, miner包向外提供挖...
摘要:月日上午点,共享云路由器在香港正式开售,售价港币,用户可使用香港本地手机号码在香港电视注册后进行选购。目前云钻已上线竞拍和区块猫等落地应用,已有用户使用云钻成功竞拍获得。6月22日上午10点,360共享云路由器在香港正式开售,售价699港币,用户可使用香港本地手机号码在香港电视 HKTVmall 注册后进行选购。消息一经公开,便吸引了众多关注。作为360的首款区块链硬件产品,360共享云路由...
摘要:本文首发于深入浅出区块链社区原文链接以太坊客户端命令用法参数详解原文已更新,请读者前往原文阅读在以太坊智能合约开发中最常用的工具必备开发工具,一个多用途的命令行工具。如果你还不知道是什么,请先阅读入门篇以太坊是什么。 本文首发于深入浅出区块链社区原文链接:以太坊客户端Geth命令用法-参数详解原文已更新,请读者前往原文阅读 Geth在以太坊智能合约开发中最常用的工具(必备开发工具),一...
阅读 3527·2021-11-22 11:59
阅读 944·2021-09-27 13:36
阅读 3602·2021-09-24 09:47
阅读 2250·2021-09-01 11:39
阅读 970·2021-08-31 09:37
阅读 2303·2021-08-05 10:01
阅读 1664·2019-08-30 15:55
阅读 692·2019-08-30 15:54