heyuan 发布的文章 - 六币之门

Go-ethereum 源码解析之 miner/worker.go （下） Go-ethereum 源码解析之 miner/worker.go （下）Appendix D. 详细批注1. constresultQueueSize： 指用于监听验证结果的通道（worker.resultCh）的缓存大小。这里的验证结果是已经被签名了的区块。 txChanSize： 指用于监听事件 core.NewTxsEvent 的通道（worker.txsCh）的缓存大小。这里的缓存大小引用自事务池的大小。其中，事件 core.NewTxsEvent 是事务列表（ []types.Transaction）的封装器。 chainHeadChanSize： 指用于监听事件 core.ChainHeadEvent 的通道（worker.chainHeadCh）的缓存大小。事件 core.ChainHeadEvent 是区块（types.Block）的封装器。 chainSideChanSize： 指用于监听事件 core.ChainSideEvent 的通道（worker.chainSideCh）的缓存大小。事件 core.ChainSideEvent 是区块（types.Block）的封装器。 resubmitAdjustChanSize： 指用于重新提交间隔调整的通道（worker.resubmitAdjustCh）的缓存大小。 缓存的消息结构为 intervalAdjust，用于描述下一次提交间隔的调整因数。 miningLogAtDepth： 指记录成功挖矿时需要达到的确认数。是 miner.unconfirmedBlocks 的深度 。即本地节点挖出的最新区块如果需要得到整个网络的确认，需要整个网络再挖出 miningLogAtDepth 个区块。举个例子：本地节点挖出了编号为 1 的区块，需要等到整个网络中某个节点（也可以是本地节点）挖出编号为 8 的区块（8 = 1 + miningLogAtDepth, miningLogAtDepth = 7）之后，则编号为 1 的区块就成为了经典链的一部分。 minRecommitInterval： 指使用任何新到达的事务重新创建挖矿区块的最小时间间隔。当用户设定的重新提交间隔太小时进行修正。 maxRecommitInterval： 指使用任何新到达的事务重新创建挖矿区块的最大时间间隔。当用户设定的重新提交间隔太大时进行修正。 intervalAdjustRatio： 指单个间隔调整对验证工作重新提交间隔的影响因子。与参数 intervalAdjustBias 一起决定下一次提交间隔。 intervalAdjustBias： 指在新的重新提交间隔计算期间应用intervalAdjustBias，有利于增加上限或减少下限，以便可以访问限制。与参数 intervalAdjustRatio 一起决定下一次提交间隔。 staleThreshold： 指可接受的旧区块的最大深度。注意，目前，这个值与 miningLogAtDepth 都是 7，且表达的意思也基本差不多，是不是有一定的内存联系。 2. type environment struct数据结构 environment 描述了 worker 的当前环境，并且包含所有的当前状态信息。最主要的状态信息有：签名者（即本地节点的矿工）、状态树（主要是记录账户余额等状态？）、缓存的祖先区块、缓存的叔区块、当前周期内的事务数量、当前打包中区块的区块头、事务列表（用于构建当前打包中区块）、收据列表（用于和事务列表一一对应，构建当前打包中区块）。signer types.Signer： 签名者，即本地节点的矿工，用于对区块进行签名。 state *state.StateDB： 状态树，用于描述账户相关的状态改变，merkle trie 数据结构。可以在此修改本节节点的状态信息。 ancestors mapset.Set： ??? ancestors 区块集合（用于检查叔区块的有效性）。缓存。缓存数据结构中往往存的是区块的哈希。可以简单地认为区块、区块头、区块哈希、区块头哈希能够等价地描述区块，其中的任何一种方式都能惟一标识同一个区块。甚至可以放宽到区块编号。 family mapset.Set： ??? family 区块集合（用于验证无效叔区块）。family 区块集合比 ancestors 区块集合多了各祖先区块的叔区块。ancestors 区块集合是区块的直接父区块一级一级连接起来的。 uncles mapset.Set： 叔区块集合，即当前区块的叔区块集合，或者说当前正在挖的区块的叔区块集合。 tcount int： 一个周期里面的事务数量 gasPool *core.GasPool： 用于打包事务的可用 gas header *types.Header： 区块头。区块头需要满足通用的以太坊协议共识，还需要满足特定的 PoA 共识协议。与 PoA 共识协议相关的区块头 types.Header 字段用 Clique.Prepare() 方法进行主要的设置，Clique.Finalize() 方法进行最终的补充设置。那么以太坊协议共识相关的字段在哪里设置？或者说在 worker 的哪个方法中设置。 txs []*types.Transaction： 事务（types.Transaction）列表。当前需要打包的事务列表（或者备选事务列表），可不可以理解为事务池。 receipts []*types.Receipt： 收据（types.Receipt）列表。Receipt 表示 Transaction 一一对应的结果。 3. type task struct数据结构 task 包含共识引擎签名和签名之后的结果提交的所有信息。签名即对已经组装好的区块添加最后的签名信息。添加了签名的区块即为最终的结果区块，即签名区块或待确认区块。数据结构 task 和数据结构 environment 的区别：数据结构 environment 用于 worker 的所有操作 数据结构 task 仅用于 worker 的签名相关操作 receipts []*types.Receipt： 收据（types.Receipt）列表 state *state.StateDB： 状态树，用于描述账户相关的状态改变，merkle trie 数据结构。可以在此修改本节节点的状态信息。 block *types.Block： 待签名的区块。此时，区块已经全部组装好了，包信了事务列表、叔区块列表。同时，区块头中的字段已经全部组装好了，就差最后的签名。签名后的区块是在此原有区块上新创建的区块，并被发送到结果通道，用于驱动本地节点已经挖出新区块之后的流程。 createdAt time.Time： task 的创建时间 数据结构 task 也是通道 worker.taskCh 发送或接收的消息。4. constcommitInterruptNone 无效的中断值 commitInterruptNewHead 用于描述新区块头到达的中断值，当 worker 启动或重新启动时也是这个中断值。 commitInterruptResubmit 用于描述 worker 根据接收到的新事务，中止之前挖矿，并重新开始挖矿的中断值。 5. type newWorkReq struct数据结构 newWorkReq 表示使用相应的中断值通知程序提交新签名工作的请求。数据结构 newWorkReq 也是通道 worker.newWorkCh 发送或接收的消息。interrupt *int32： 具体的中断值，为 commitInterruptNewHead 或 commitInterruptResubmit 之一。 noempty bool： ??? 表示创建的区块是否包含事务？ timestamp int64： ??? 表示区块开始组装的时间？ 6. type intervalAdjust struct数据结构 intervalAdjust 表示重新提交间隔调整。ratio float64： 间隔调整的比例 inc bool： 是上调还是下调 在当前区块时计算下一区块的出块大致时间，在基本的时间间隔之上进行一定的微调，微调的参数就是用数据结构 intervalAdjust 描述的，并发送给对应的通道 resubmitAdjustCh。下一个区块在打包时从通道 resubmitAdjustCh 中获取其对应的微调参数 intervalAdjust 实行微调。7. type worker structworker 是负责向共识引擎提交新工作并且收集签名结果的主要对象。共识引擎会做哪些工作呢？通过方法 Clique.Prepare() 设置区块头中关于 PoA 共识的相关字段。 通过方法 Clique.Finalize() 组装可以被签名的区块。 通过方法 Clieque.Seal() 对区块进行签名，并发送给结果通道 worker.resultsCh。 通过方法 Clique.snapshot() 处理两种快照：检查点快照和投票快照。 那么共识引擎需要哪些输入呢？区块头 事务列表 收据列表 状态树 叔区块列表（PoA 共识协议中肯定为 nil） 区块，是个抽象概念，主要包含：区块头、事务列表、叔区块列表，但是并不包含收据列表。 那么共识引擎会产生哪些输出呢？方法 Clieque.Seal() 会将最终签名后的区块发送给结果通道 worker.resultsCh。 config *params.ChainConfig： 区块链的链配置信息，包含链 ID，是 ethash 还是 clique 共识协议等 engine consensus.Engine： 共识引擎接口 eth Backend： 后端，包含区块链和事务池，提供挖矿所需的所有方法 chain *core.BlockChain： 表示整个区块链。这不和 eth 中的区块链是同一个？ gasFloor uint64： 最低 gas gasCeil uint64: 最高 gas // 订阅mux *event.TypeMux： 可以简单地理解为事件的订阅管理器，即注册事件的响应函数，和驱动事件的响应函数。 txsCh chan core.NewTxsEvent： 用于在不同协程之间交互事件 core.NewTxsEvent 的通道。事件 core.NewTxsEvent 是事务列表 []*types.Transaction 的封装器，即通道 txsCh 用于在不同协程之间交互事务列表。命名协程 worker.mainLoop() 从通道 txsCh 接收事件 core.NewTxsEvent，即事务列表。使用通道 txsCh 作为只接收消息的通道向 core.TxPool 订阅事件 core.NewTxsEvent，那么应该是从 core.TxPool 发送事件 core.NewTxsEvent 到通道 txsCh。 txsSub event.Subscription： 向事务池（core.TxPool）订阅事件 core.NewTxsEvent，并使用通道 txsCh 作为此次订阅接收消息的通道。代码为 worker.txsSub = eth.TxPool().SubscribeNewTxsEvent(worker.txsCh)。 chainHeadCh chan core.ChainHeadEvent： 用于在不同协程之间交互事件 core.ChainHeadEvent 的通道。事件 core.ChainHeadEvent 是区块 types.Block 的封装器，即通道 chainHeadCh 用于不同协程之间交互新挖出的区块头。命名协程 worker.newWorkLoop() 从通道 chainHeadCh 接收事件 core.ChainHeadEvent，即新的区块头。使用通道 chainHeadCh 作为只接收消息的通道向 core.BlockChain 订阅事件 core.ChainHeadEvent，那么应该是从 core.BlockChain 发送事件 core.ChainHeadEvent 到通道 chainHeadCh。 chainHeadSub event.Subscription： 向区块链（core.BlockChain）订阅事件 core.ChainHeadEvent，并使用通道 chainHeadCh 作为此次订阅接收消息的通道。代码为 worker.chainHeadSub = eth.BlockChain().SubscribeChainHeadEvent(worker.chainHeadCh) chainSideCh chan core.ChainSideEvent： 用于在不同协程之间交互事件 core.ChainSideEvent 的通道。事件 core.ChainSideEvent 是区块 types.Block 的封装器，即通道 chainSideCh 用于不同协程之间交互新挖出的区块头。命名协程 worker.mainLoop() 从通道 chainSideCh 接收事件 core.ChainSideEvent，即新的叔区块头（但 PoA 不是不存在叔区块？）。使用通道 chainSideCh 作为只接收消息的通道向 core.BlockChain 订阅事件 core.ChainSideEvent，那么应该是从 core.BlockChain 发送事件 core.ChainSideEvent 到通道 chainSideCh。 chainSideSub event.Subscription： 向区块链（core.BlockChain）订阅事件 core.ChainSideEvent，并使用通道 chainSideCh 作为此次订阅接收消息的通道。代码为 worker.chainSideSub = eth.BlockChain().SubscribeChainSideEvent(worker.chainSideCh) // 通道newWorkCh chan *newWorkReq： 通道 newWorkCh 用于在不同协程之间交互消息 newWorkReq 的通道。命名协程 worker.newWorkLoop() 将消息 newWorkReq 发送给通道 newWorkCh。命名协程 worker.mainLoop() 从通道 newWorkCh 中接收消息 newWorkReq。 taskCh chan *task： 通道 taskCh 用于在不同协程之间交互消息 task 的通道。（1）命名协程 worker.taskLoop() 从通道 taskCh 中接收消息 task。对接收到的消息 task 先存入待处理 map 中，其中 Key 为 task 中的区块签名哈希，Value 为 task。同时，将 task 中的区块传递给共识引擎的签名方法 w.engine.Seal() 进行签名，同时将结果通道 w.resultCh 和退出通道 stopCh 也传递给共识引擎的签名方法，以便从中接收签名之后的区块或者接收中止消息。（2）命名协程 worker.mainLoop() 中的方法 worker.commit() 将消息 task 发送给通道 taskCh。此方法先将当前环境中的区块头（w.current.header）、事务列表（w.current.txs）、收据列表（w.current.receipts）作为参数传递给共识引擎的方法 Finalize() 组装出待签名的区块，代码为 block = w.engine.Finalize(w.chain, w.current.header, s, w.current.txs, uncles, w.current.receipts)。需要注意的是，区块 types.Block 中只包含区块头 types.Header、事务列表 []types.Transaction、叔区块列表 []types.Header，并不包含收据列表 []types.Receipt，但是区块头 types.Header 中的字段 ReceiptHash 是收据列表树的根哈希，所以也需要收据列表参数。将组装后的待签名区块 types.Block，及前面解释过的收据列表 []types.Receipt 等其它参数一起构建出新的任务 task 发送给通道 taskCh，同时输出一条重要的日志信息：log.Info("Commit new mining work", "number", block.Number(), "sealhash", w.engine.SealHash(block.Header()), "uncles", len(uncles), "txs", w.current.tcount, "gas", block.GasUsed(), "fees", feesEth, "elapsed", common.PrettyDuration(time.Since(start)))。到方法 commit() 这一步，已经组装出了新的任务 task，并将此新任务 task 通过通道 taskCh 发送给命名协程 worker.taskLoop()。 resultCh chan *types.Block： 通道 resultCh 用于在不同协程之间交互消息 types.Block。（1）命名协程 worker.resultLoop() 从通道 resultCh 中接收消息 types.Block，且此区块是被签名过的。对于新接收到签名区块，首先判断这个签名区块是否为重复的；其次，需要从待处理任务映射 w.pendingTasks 中获得对应区块签名哈希的任务 task，如果没找到则输出一条重要的日志信息：log.Error("Block found but no relative pending task", "number", block.Number(), "sealhash", sealhash, "hash", hash)。并从 task 中恢复 receipts 和 logs。第三，将签名区块及其对应的收据列表和状态树等信息写入数据库。如果写入失败，则输出一条重要的日志信息：log.Error("Failed writing block to chain", "err", err)，否则输出一条重要的日志信息：log.Info("Successfully sealed new block", "number", block.Number(), "sealhash", sealhash, "hash", hash, "elapsed", common.PrettyDuration(time.Since(task.createdAt)))。第四，通过新挖出的签名区块构建事件 core.NewMinedBlockEvent，并通过事件订阅管理器中的方法 w.mux.Post() 将本地节点最新签名的区块向网络中其它节点进行广播，这是基于 p2p 模块完成的。第五，同时构建事件 core.ChainEvent 和事件 core.ChainHeadEvent，或者构建事件 core.ChainSideEvent，并通过区块链中的方法 w.chain.PostChainEvents() 进行广播。需要注意的时，此广播只是针对向本地节点进行了事件注册的客户端，且是通过 JSON-RPC 完成，和第四步中的向网络中其它节点通过 p2p 进行广播是完全不同的。这一部的广播即使没有事件接收方也没有问题，因为这是业务逻辑层面的，而第四步中的广播则是必须有接收方的，否则就会破坏以太坊协议本身。比如：我们可以注册一个事件，用于监控是否有最新的区块被挖出来，然后在此基础上，查询指定账户的最新余额。第六步，将新挖出来的签名区块，添加进待确认队列中，代码为：w.unconfirmed.Insert(block.NumberU64(), block.Hash())。（2）共识引擎中的签名方法 Clique.Seal() 通过匿名协程将签名后的签名区块 types.Block 发送到通道 resultCh。 startCh chan struct： 通道 startCh 用于在不同协程之间交互消息 struct。可以发现，消息 struct 没有包含任何有意义的信息，这在 Go 中是一类特别重要的写法，用于由某个协程向另一个协程发送开始或中止消息。（1）函数 newWorker() 向通道 startCh 发送消息 struct，其中函数 newWorker() 应该是运行在主协程中或由其它某个包中的协程启动。代码为：worker.startCh <- struct。（2）方法 worker.start() 向通道 startCh 发送消息 struct，其它同（1）。（3）命名协程 worker.newWorkLoop() 从通道 startCh 中接收消息 struct。需要注意的是，（1）和（2）都可以向通道 startCh 发送消息 struct 驱动命名协程 worker.newWorkLoop() 中逻辑。方法 worker.start() 表明 worker 是可以先停止的，而不关闭，之后可以重新启动。 exitCh chan struct： 通道 exitCh 用于在不同协程之间交互消息 struct。可以参考通道 startCh 中的注释。（1）函数 worker.close() 通过调用函数 close(w.exitCh) 整个关闭通道 exitCh。（2）命名协程 worker.newWorkLoop() 从通道 exitCh 中接收消息，从而结束整个协程。（3）命名协程 worker.mainLoop() 从通道 exitCh 中接收消息，从而结束整个协程。（4）命名协程 worker.taskLoop() 从通道 exitCh 中接收消息，从而结束整个协程。（5）命名协程 worker.resultLoop() 从通道 exitCh 中接收消息，从而结束整个协程。（6）命名协程 worker.mainLoop() 调用的方法 worker.commit() 从通道 exitCh 中接收消息，从而放弃后续的工作。 resubmitIntervalCh chan time.Duration： 通道 resubmitIntervalCh 用于在不同的协程之间交互消息 time.Duration。time.Duration 是 Go 语言标准库中的类型，在这里通道 resubmitIntervalCh 起到一个定时器的作用，这也是 Go 语言中关于定时器的标准实现方式。（1）方法 worker.setRecommitInterval() 向通道 resubmitIntervalCh 发送消息 time.Duration，即设置定时器下一次触发的时间。方法 worker.setRecommitInterval() 在方法 Miner.SetRecommitInterval() 中被调用，方法 Miner.SetRecommitInterval() 又在方法 PrivateMinerAPI.SetRecommitInterval() 中调用，这应该是从外部通过 JSON-RPC 接口驱动的。（2）命名协程 worker.newWorkLoop() 从通道 resubmitIntervalCh 中接收消息 time.Duration，即获得希望定时器下一次触发的时间，并根据需要对这个时间进行一定的修正。 resubmitAdjustCh chan *intervalAdjust： 通道 resubmitAdjustCh 用于在不同的协程之间交互消息 intervalAdjust。（1）命名协程 worker.newWorkLoop() 从通道 resubmitAdjustCh 中接收消息 intervalAdjust。（2）方法 worker.commitTransactions() 向通道 resubmitAdjustCh 中发送消息 intervalAdjust。通道 resubmitAdjustCh 与通道 resubmitIntervalCh 的作用类似，都是修改下一个区块的出块时间。只不过通道 resubmitAdjustCh 中交互的消息 time.Duration 是由外部通过 JSON-RPC 接口来设定的，而通道 resubmitIntervalCh 中交互的消息 intervalAdjust 是矿工根据上一个区块的出块时间基于算法自定调整的。 current *environment： 描述了 worker 的当前环境和状态信息。具体的请参考对数据结构 environment 的注释。 possibleUncles map[common.Hash]*types.Block： 可能的叔区块集合。Key 为区块哈希 common.Hash，Value 为区块 types.Block。 unconfirmed *unconfirmedBlocks： 本地节点最近新挖出的区块集合，用于等待网络中其它节点的确认，从而成为经典链的一部分。具体的可以参考对数据结构 unconfirmedBlocks 的注释。 mu sync.RWMutex： 锁，用于保护字段 coinbase 和 extra。 coinbase common.Address： 矿工地址。 extra []byte： 分为三段：前 32 字节矿工可随意填写，最后 65 字节为对区块头的签名，中间的字节为授权签名者列表的有序列连接，且字节数为 20 的倍数。 pendingMu sync.RWMutex： 锁，用于保护字段 pendingTasks。 pendingTasks map[common.Hash]*task： 待处理的任务映射，其中：Key 为 task 中包含的区块的哈希值，Value 为 task。 snapshotMu sync.RWMutex： 锁，用于保护字段 snapshotBlock 和 snapshotState。 snapshotBlock *types.Block： 区块的快照。 snapshotState *state.StateDB： 状态的快照。 // 原子状态的计数器running int32: 用于表示共识引擎是否正在运行。 newTxs int32： 自从上次签名工作提交之后新到达的事务数量。上次签名工作即指 worker 中已经通过调用共识引擎的 Finalize() 方法组装好了待签名的区块，然后通过调用共识引擎的签名方法 Clique.Seal() 对待签名区块进行签名。即在上一个区块被本地节点挖出之后，新来的事务数量。 // Test hooksnewTaskHook func(*task)： 接收到新签名任务时调用此方法。 skipSealHook func(*task) bool： 判定是否跳过签名时调用 此方法。 fullTaskHook func()： 在推送完整签名任务之前调用此方法。 resubmitHook func(time.Duration, time.Duration)： 更新重新提交间隔时调用此方法。 (1) func newWorker(config *params.ChainConfig, engine consensus.Engine, eth Backend, mux *event.TypeMux, recommit time.Duration, gasFloor, gasCeil uint64) *worker构造函数 newWorker() 用于根据给定参数构建 worker。主要参数：config *params.ChainConfig： 链的配置信息 engine consensus.Engine： 共识引擎 eth Backend： 以太坊本地节点的后端 mux *event.TypeMux： 事件订阅管理器 recommit time.Duration： 下一次任务的基础时间间隔 gasFloor, gasCeil uint64： Gas 的下限 gasFloor 和上限 gasCeil。 主要实现：首先构建对象 worker，并设定大部分字段的初始值。 向事务池 core.TxPool 订阅事件 core.NewTxsEvent，并通过通道 worker.txsCh 接收事件 core.NewTxsEvent。 worker.txsSub = eth.TxPool().SubscribeNewTxsEvent(worker.txsCh) 向区块链 core.BlockChain 订阅事件 core.ChainHeadEvent，并通过通道 worker.chainHeadCh 接收事件 core.ChainHeadEvent。 worker.chainHeadSub = eth.BlockChain().SubscribeChainHeadEvent(worker.chainHeadCh) 向区块链 core.BlockChain 订阅事件 core.ChainSideEvent，并通过通道 worker.chainSideCh 接收事件 worker.ChainSideEvent。 worker.chainSideSub = eth.BlockChain().SubscribeChainSideEvent(worker.chainSideCh) 如果用户设定的重新提交间隔 recommit 太短，则重新设定 recommit = minRecommitInterval。同时，输出日志信息：log.Warn("Sanitizing miner recommit interval", "provided", recommit, "updated", minRecommitInterval) 启动新的独立协程运行方法 worker.mainLoop()。 启动新的独立协程运行方法 worker.newWorkLoop(recommit)。 启动新的独立协程运行方法 worker.resultLoop()。 启动新的独立协程运行方法 worker.taskLoop()。 提交第一个工作以初始化待处理状态。即给通道 startCh 发送消息。 worker.startCh <- struct (2) func (w *worker) setEtherbase(addr common.Address)方法 setEtherbase() 设置用于初始化区块 coinbase 字段的 etherbase。参数：addr common.Address： 地址 主要实现：加锁和解锁 w.coinbase = addr (3) func (w *worker) setExtra(extra []byte)方法 setExtra() 设置用于初始化区块额外字段的内容。参数：extra []byte： 应该是用于区块头 types.Header 中的字段 Extra 的前 32 字节。这 32 字节是以太坊协议规定在区块中用于存储矿工相关的一些额外信息。上层调用方法 miner.Miner.SetExtra()，继续上层调用方法为 eth.Ethereum 的构造函数 eth.New() 中的代码 eth.miner.SetExtra(makeExtraData(config.MinerExtraData))。这个参数最终是通过 geth 的 MINER OPTIONS 命令行参数 --extradata，或者 ETHEREUM OPTIONS 的命令行参数 --config，这是一个 TOML 配置文件。 (4) func (w *worker) setRecommitInterval(interval time.Duration)方法 setRecommitInterval() 更新矿工签名工作重新提交的间隔。参数：interval time.Duration： 重新提交的时间间隔。 主要实现：将重新提交的间隔 interval 发送到通道 worker.resubmitIntervalCh，代码为：w.resubmitIntervalCh <- interval。命名协程 worker.newWorkLoop() 会从通道 worker.resubmitIntervalCh 中接收此消息。 (5) func (w worker) pending() (types.Block, *state.StateDB)方法 pending() 返回待处理的状态和相应的区块。主要实现：加锁、解锁 snapshotMu。 返回字段 snapshotBlock 和字段 snapshotState 的副本。 (6) func (w *worker) pendingBlock() *types.Block方法 pendingBlock() 返回待处理的区块。主要实现：加锁、解锁 snapshotMu。 返回字段 snapshotBlock。 (7) func (w *worker) start()方法 start() 采用原子操作将 running 字段置为 1，并触发新工作的提交。主要实现：atomic.StoreInt32(&w.running, 1) w.startCh <- struct (8) func (w *worker) stop()方法 stop() 采用原子操作将 running 字段置为 0。主要实现：atomic.StoreInt32(&w.running, 0) (9) func (w *worker) isRunning() bool方法 isRunning() 返回 worker 是否正在运行的指示符。主要实现：return atomic.LoadInt32(&w.running) == 1 (10) func (w *worker) close()方法 close() 终止由 worker 维护的所有后台线程。注意 worker 不支持被关闭多次，这是由 Go 语言不允许多次关闭同一个通道决定的。主要实现close(w.exitCh) (11) func (w *worker) newWorkLoop(recommit time.Duration)方法 newWorkLoop() 是一个独立的协程，基于接收到的事件提交新的挖矿工作。不妨将此协程称作命名协程 worker.newWorkLoop()。参数：recommit time.Duration： 下一次提交间隔。 主要实现：定义了三个变量： interrupt *int32： 中断信号 minRecommit = recommit： 用户指定的最小重新提交间隔 timestamp int64： 每轮挖矿的时间戳 定义一个定时器，并丢弃初始的 tick timer := time.NewTimer(0) <-timer.C 定义内部提交函数 commit() 提交函数 commit() 使用给定信号中止正在进行的交易执行，并重新提交新信号。 构建新工作请求 newWorkReq，并发送给通道 newWorkCh 来驱动命名协程 worker.mainLoop() 来重新提交任务。 设置定时器 timer 的下一次时间。代码为：timer.Reset(recommit) 重置交易计数器。代码为：atomic.StoreInt32(&w.newTxs, 0) 定义内部函数 recalcRecommit() 根据一套规则来计算重新提交间隔 recommit。 具体规则后续补充注释。 定义内部函数 clearPending() 此函数用于清除过期的待处理任务。 参数 number uint64： 区块编号 加锁 w.pendingMu.Lock() 循环迭代 w.pendingTasks 区块签名哈希 h 任务 t 如果 t 中的区块编号比 number 要早 staleThreshold 个区块，则将其从 w.pendingTasks 中删除。 解锁 w.pendingMu.Unlock() 在 for 循环中持续从通道 startCh、timer.C、resubmitIntervalCh、resubmitAdjustCh 和 exitCh 中接收消息，并执行相应的逻辑。 startCh： 调用内部函数 clearPending() 清除链上当前区块之前的过期待处理任务。 调用内部函数 commit(false, commitInterruptNewHead) 提交新的 newWorkReq。 chainHeadCh： 从通道 chainHeadCh 接收消息 head（事件 core.ChainHeadEvent） 调用内部函数 clearPending() 清除 core.ChainHeadEvent 中区块之前的过期待处理任务。 调用内部函数 commit(false, commitInterruptNewHead) 提交新的 newWorkReq。 timer.C 如果挖矿正在进行中，则定期重新提交新的工作周期以提取更高价格的交易。禁用待处理区块的此开销。 如果交易计数器 w.newTxs 为 0 重置定时器。代码为：timer.Reset(recommit) 退出本轮迭代。 调用内部函数 commit(false, commitInterruptResubmit) 提交新的 newWorkReq。 timer.C： 如果挖矿正在进行中，则定期重新提交新的工作周期以便更新到价格较高的交易。对于待处理中的区块禁用此操作开销。 对于 poa 共识引擎，需要其配置的 Clique.Period > 0。!!!等于这里对于共识算法有个特殊处理。 调用内部函数 commit(true, commitInterruptResubmit) 提交新的 newWorkReq。 【批注 1】，这里用到了 time.Timer 将定时器，时间间隔为 recommit。 【批注 2】，通道主要的作用是用于协程之间交互消息，那么实际上影响到的就是工作流程。这个定时器应该主要就是挖矿有周期性的概念，比如 15 秒产生一个块。存在两个定时间隔，一个是静态配置的，另一个是由挖矿动态决定的。当挖矿的实际时间长于静态设定的，那么可能需要做一些操作，比如重新挖矿等等吧。当挖矿的实际时间适于静态设定的，可能不需要做什么操作。 resubmitIntervalCh： 支持由用户来重新设定重新提交的间隔。 用户设定的值不能小于 minRecommitInterval。 如果回调函数 resubmitHook 不空，则调用。 resubmitAdjustCh： 根据挖矿的反馈来动态地调整重新提交的间隔。 如果回调函数 resubmitHook 不空，则调用。 exitCh： 接收到退出消息，退出整个协程。 命名协程 worker.mainLoop() 用于根据接收到的事件生成签名任务，命名协程 worker.taskLoop() 用于接收上述验证任务并提交给共识引擎，命名协程 worker.resultLoop() 用于处理签名结果的提交并更新相关数据到数据库中。(12) func (w *worker) mainLoop()方法 mainLoop() 是一个独立的协程，用于根据接收到的事件重新生成签名任务。不妨将此协程称作命名协程 worker.mainLoop()。主要实现：在整个协程退出时，取消 txsSub、chainHeadSub、chainSideSub 这三个订阅。 defer w.txsSub.Unsubscribe() defer w.chainHeadSub.Unsubscribe() defer w.chainSideSub.Unsubscribe() 在 for 循环中持续从通道 newWorkCh、chainSideCh、txCh 和 exitCh 中接收消息，并执行相应的逻辑。 newWorkCh： 根据新接收到的消息 req（数据结构为 newWorkReq），调用函数 commitNewWork() 提交新的任务。代码为：w.commitNewWork(req.interrupt, req.noempty, req.timestamp)。需要说明的，虽然方法 commitNewWork() 中的参数没有包含任何区块、交易等信息，但这些信息都包含在当前环境 w.current 或 w 中。同时，任务最终通过通道 worker.taskCh 提交给命名协程 worker.taskLoop()。 chainSideCh： 接收到新的消息 ev（事件 ChainSideEvent） 如果 ev 中携带的区块已经在 possibleUncles 中，则退出本轮迭代。 把 ev 携带的区块添加到 possibleUncles中。代码为：w.possibleUncles[ev.Block.Hash()] = ev.Block。 如果正在挖矿中的区块所包含的叔区块少于 2 个，且 ev 中携带的新叔区块有效，则重新生成挖矿中的任务。见代码：if w.isRunning() && w.current != nil && w.current.uncles.Cardinality() < 2 获取任务开始时间 start。代码为：start := time.Now() 通过方法 commitUncle() 将 ev 中携带的区块添加到 current.uncles 中。如果成功 定义新任务中所需要的区块头列表 uncles。代码为：var uncles []*types.Header 遍历 w.current.uncles 中的每个 uncle hash 从 possibleUncles 中找到 uncle hash 对应的区块头，并添加到 uncles 中。代码为：uncles = append(uncles, uncle.Header()) 并根据最终获得的所有叔区块头列表 uncles 来调用方法 commit() 提交最终区块。代码为：w.commit(uncles, nil, true, start) 【批注 1】：possibleUncles 用于包含可能的叔区块，起到一个缓冲的作用。 current.uncles 是当前要打包的区块中已经被确认的叔区块。 【批注 2】：possibleUncles 是<区块头哈希>区块构成的 map，current.uncles 则仅包含了区块头哈希。 txsCh：根据新接收到的消息 ev（事件 core.NewTxsEvent） 如果不在挖矿状态，则将交易置于待处理状态。 注意，收到的所有交易可能与已包含在当前挖矿区块中的交易不连续。这些交易将自动消除。 if !w.isRunning() && w.current != nil 加锁、解锁的方式获取矿工地址 coinbase。代码为：coinbase := w.coinbase 定义变量 txs。代码为：txs := make(map[common.Address]types.Transactions) 遍历消息 ev 中携带的交易列表，对于每个交易 tx 还原出每个交易 tx 的发送者地址 acc 更新映射 txs。代码为：txs[acc] = append(txs[acc], tx) 将 txs 转换为 txset（数据结构为 types.TransactionsByPriceAndNonce），代码为：txset := types.NewTransactionsByPriceAndNonce(w.current.signer, txs) 提交交易列表 txset。代码为：w.commitTransactions(txset, coinbase, nil) 更新快照。代码为：w.updateSnapshot() else 如果我们正在挖矿中，但没有正在处理任何事情，请在新交易中醒来 if w.config.Clique != nil && w.config.Clique.Period == 0 w.commitNewWork(nil, false, time.Now().Unix()) 采用原子操作将 w.newTxs 的数量增加新接收到的事务数量。代码为：atomic.AddInt32(&w.newTxs, int32(len(ev.Txs))) w.exitCh 当从退出通道接收到消息时，结束整个协程。 w.txsSub.Err() 当从交易订阅通道接收到错误消息时，结束整个协程。 w.chainHeadSub.Err() 当从区块头订阅通道接收到错误消息时，结束整个协程。 w.chainSideSub.Err() 当从侧链区块头订阅通道接收到错误消息时，结束整个协程。 (13) func (w *worker) taskLoop()方法 taskLoop() 是一个独立的协程，用于从生成器中获取待签名任务，并将它们提交给共识引擎。不妨将此协程称作命名协程 worker.taskLoop()。主要实现：定义两个变量：退出通道 stopCh 和上一个区块哈希 prev stopCh chan struct prev common.Hash 定义局部中断函数 interrupt()，用于关闭退出通道 stopCh，结束所有从退出通道 stopCh 接收消息的协程，这里共识引擎方法 Seal() 中用于签名的独立匿名协程，退出通道 stopCh 是作为参数传递过去的。 close(stopCh) 局部通道 stopCh 和内部函数 interrupt() 用于组合终止进行中的签名任务（in-flight sealing task）。 在 for 循环中持续从通道 taskCh 和 exitCh 中接收消息，并执行相应的逻辑。 taskCh： 接收新任务 task 如果回调 w.newTaskHook != nil，则调用回调函数 w.newTaskHook(task) 获取任务 task 中包含区块的区块签名哈希 sealHash 如果 sealHash == prev，则退出本轮迭代。 过滤掉因重复提交产生的重复的签名任务 调用中断函数 interrupt() 中止共识引擎方法 Seal() 中正在签名的独立匿名协程。这里是通过关闭退出通道 stopCh 实现的。 给退出通道 stopCh 分配空间，并设置上一个区块哈希 prev。 stopCh, prev = make(chan struct), sealHash 如果回调函数 w.skipSealHook() 不为 nil 和 w.skipSealHook(task) 返回 true，则退出本轮迭代。 通过对锁 w.pendingMu 执行加锁、解锁，将任务 task 添加到 w.pendingTasks 中，为之后命名协程 worker.resultLoop() 中接收到已签名区块，查找包含该区块的任务 task 而用。 将任务 task 中包含的区块提交给共识引擎进行签名。代码为：w.engine.Seal(w.chain, task.block, w.resultCh, stopCh) 需要特别注意传递的两个通道参数 w.resutlCh, stopCh 通道 w.resultCh 用于从共识引擎的签名方法 Seal() 中接收已签名区块。 通道 stopCh 用于发送中止信号给共识引擎的签名方法 Seal()，从而中止共识引擎正在进行的签名操作。 如果签名失败，则输出日志信息：log.Warn("Block sealing failed", "err", err) exitCh： 当接收到退出消息时 通过调用内部中断函数 interrupt() 关闭中止通道 stopCh，从而使得共识引擎的签名方法 Seal() 放弃本次签名。 退出整个协程。 (14) func (w *worker) resultLoop()方法 resultLoop() 是一个独立的协程，用于处理签名区块的提交和广播，以及更新相关数据到数据库。不妨将此协程称作命名协程 worker.resultLoop()。主要实现：在 for 循环中持续从通道 resultCh 和 exitCh 中接收消息，并执行相应的逻辑。 resultCh： 接收已签名区块 block。 如果 block == nil，则进入下一轮迭代。 如果区块 block 已经存在于经典链中，则进入下一轮迭代。 定义两个变量： 区块签名哈希 sealhash，代码为：sealhash = w.engine.SealHash(block.Header()) 区块哈希 hash，代码为：hash = block.Hash() 分别计算区块头的验证哈希 sealHash（不包括 extraData 中的最后 65 个字节的签名信息），区块的哈希 hash （即区块头的哈希，而且包含整个 extraData）。 通过对锁 w.pendingMu 进行加锁和解锁的方式从 w.pendingTasks 中找到 sealHash 对应的 task。这是找出已签名区块对应的任务 task，从中获取需要的交易列表、交易回执列表等相关数据。 如果 task 不存在，则输出日志信息：log.Error("Block found but no relative pending task", "number", block.Number(), "sealhash", sealhash, "hash", hash) 同时，退出本次迭代。 定义两个变量，交易回执列表 receipts，交易回执中包含的日志列表 logs。 receipts = make([]*types.Receipt, len(task.receipts)) logs []*types.Log 这是因为不同的区块可能会共享相同的区块签名哈希，建立这些副本是为了防止写写冲突。 更新所有日志中的区块哈希。这是因为对于这些日志来说，直到现在才知道对应的区块哈希，而在创建单个交易的交易回执的接收日志时，并不知道对应的区块哈希。 更新 task.receipts 中各 receipt.Logs 的 BlockHash 值为 hash。 通过方法 w.chain.WriteBlockWithState() 将区块 block，交易回执列表 receipts，状态数据库 task.state 写入数据库，并返回写入状态 stat。stat 的取值：NonStatTy (0)、CanonStatTy (1)、SideStatTy(2)。 如果写入失败，则输出日志信息：log.Error("Failed writing block to chain", "err", err)。同时，退出本轮迭代。 至此，成功的验证了新的区块。输出日志信息：log.Info("Successfully sealed new block", "number", block.Number(), "sealhash", sealhash, "hash", hash, "elapsed", common.PrettyDuration(time.Since(task.createdAt))) 将新产生的新区块 block 广播到网络中的其他节点。这是通过构建事件 core.NewMinedBlockEvent 进调用 w.mux.Post() 实现的。代码为：w.mux.Post(core.NewMinedBlockEvent) 定义变量事件列表 events 根据写入数据库返回的状态 stat 的值： case core.CanonStatTy：在事件列表 events 中添加新的事件 core.ChainEvent、core.ChainHeadEvent case core.SideStatTy：在事件列表 events 中添加新的事件 core.ChainSideEvent。 通过方法 w.chain.PostChainEvents() 广播事件。代码为： w.chain.PostChainEvents(events, logs) 将已签名区块插入待确认区块列表中。代码为：w.unconfirmed.Insert(block.NumberU64(), block.Hash()) exitCh： 接收到退出消息则中止整个协程。 命名协程 worker.resultLoop() 从通道 resultCh 中接收消息 types.Block，且此区块是被签名过的。对于新接收到签名区块，首先判断这个签名区块是否为重复的；其次，需要从待处理任务映射 w.pendingTasks 中获得对应区块签名哈希的任务 task，如果没找到则输出一条重要的日志信息：log.Error("Block found but no relative pending task", "number", block.Number(), "sealhash", sealhash, "hash", hash)。并从 task 中恢复 receipts 和 logs。第三，将签名区块及其对应的收据列表和状态树等信息写入数据库。如果写入失败，则输出一条重要的日志信息：log.Error("Failed writing block to chain", "err", err)，否则输出一条重要的日志信息：log.Info("Successfully sealed new block", "number", block.Number(), "sealhash", sealhash, "hash", hash, "elapsed", common.PrettyDuration(time.Since(task.createdAt)))。第四，通过新挖出的签名区块构建事件 core.NewMinedBlockEvent，并通过事件订阅管理器中的方法 w.mux.Post() 将本地节点最新签名的区块向网络中其它节点进行广播，这是基于 p2p 模块完成的。第五，同时构建事件 core.ChainEvent 和事件 core.ChainHeadEvent，或者构建事件 core.ChainSideEvent，并通过区块链中的方法 w.chain.PostChainEvents() 进行广播。需要注意的时，此广播只是针对向本地节点进行了事件注册的客户端，且是通过 JSON-RPC 完成，和第四步中的向网络中其它节点通过 p2p 进行广播是完全不同的。这一部的广播即使没有事件接收方也没有问题，因为这是业务逻辑层面的，而第四步中的广播则是必须有接收方的，否则就会破坏以太坊协议本身。比如：我们可以注册一个事件，用于监控是否有最新的区块被挖出来，然后在此基础上，查询指定账户的最新余额。第六步，将新挖出来的签名区块，添加进待确认队列中，代码为：w.unconfirmed.Insert(block.NumberU64(), block.Hash())。(15) func (w *worker) makeCurrent(parent *types.Block, header *types.Header) error方法 makeCurrent() 为当前周期创建新的环境 environment。参数：parent *types.Block： 父区块 header *types.Header： 当前区块头 主要实现：先通过父区块状态树的根哈希从区块链中获取状态信息 state (state.StateDB)，如果失败，直接返回错误 构建当前环境 environment 的对象 env 设定字段 signer 为 types.EIP155Signer 设定字段 state 为前面获取的 state 设定字段 header 为参数 header 默认初始化其它字段 从区块链中获取父区块之前的 7 个高度的所有区块，包含叔区块 所有的直系父区块添加到字段 ancestors 所有的直系父区块和叔区块添加到字段 family 将字段 tcount 设为 0 将环境 env 赋值给字段 worker.current (16) func (w *worker) commitUncle(env *environment, uncle *types.Header) error方法 commitUncle() 将给定的区块添加至叔区块集合中，如果添加失败则返回错误。参数：env *environment： 当前环境，里面组织了本次周期里需要的所有信息 uncle *types.Header： 叔区块的区块头 主要实现：获取叔区块 hash。见代码：hash := uncle.Hash()。 判定叔区块是否惟一。见代码：if env.uncles.Contains(hash) 判定叔区块是否为兄弟区块。见代码：if env.header.ParentHash == uncle.ParentHash 判定叔区块的父区块是否存在于链上。见代码：if !env.ancestors.Contains(uncle.ParentHash) 判定叔区块是否已经存在于链上。见代码：if env.family.Contains(hash) 上述四个判定都通过，则添加到当前区块的叔区块列表中。见代码：env.uncles.Add(uncle.Hash()) (17) func (w *worker) updateSnapshot()方法 updateSnapshot() 更新待处理区块和状态的快照。注意，此函数确保当前变量是线程安全的。主要实现：- 加锁、解锁 w.snapshotMu- 定义叔区块头列表 uncles- 对于 w.current.uncles 中的每个叔区块头 uncle，如果存在于w.possibleUncles 中，则将其没回到 uncles 中。- 由 w.current.header, w.current.txs, uncles, w.current.receipts 构建出快照区块 w.snapshotBlock。- 由 w.current.state 的副本构建出快照状态 w.snapshotState。(18) func (w *worker) commitTransaction(tx types.Transaction, coinbase common.Address) ([]types.Log, error)：方法 commitTransaction() 提交交易 tx，并附上交易的发起者地址。此方法会生成交易的交易回执。参数：tx *types.Transaction： 具体的一次交易信息。 coinbase common.Address： 交易的发起方地址，可以明确指定。如果为空，则为区块签名者的地址。 返回值：[]*types.Log： 交易回执中的日志信息。 主要实现：先对状态树进行备份 snap，代码为：snap := w.current.state.Snapshot() 通过对交易 tx 及交易发起者 coinbase 调用方法 core.ApplyTransaction() 获得交易回执 receipt。 如果失败，则将状态树恢复到之前的状态 snap，并直接返回。 更新交易列表。代码为 w.current.txs = append(w.current.txs, tx) 更新交易回执列表。代码为 w.current.receipts = append(w.current.receipts, receipt) (19) func (w *worker) commitTransactions(txs *types.TransactionsByPriceAndNonce, coinbase common.Address, interrupt *int32) bool：方法 commitTransactions() 提交交易列表 txs，并附上交易的发起者地址。根据整个交易列表 txs 是否都被有效提交，返回 true 或 false。参数：txs *types.TransactionsByPriceAndNonce： 交易列表的管理器，同时根据价格和随机数值进行排序，每次输出一个排序最靠前的交易。具体的注释，参考 types.TransactionsByPriceAndNonce。 coinbase common.Address： 交易的发起方地址，可以明确指定。如果为空，则为区块签名者的地址。 interrupt *int32： 中断信号值。需要特别说明，这是个指针类型的值，意味着后续的每轮迭代都能读取外部对于参数 interrupt 的更新。同时，此方法还能将内部对于参数 interrupt 的修改反馈给外部调用者。 返回值：整个交易列表是否都被正确处理。 主要实现：如果 w.current 为空，直接返回。 如果 w.current.gasPool 为空，则初始化为 w.current.header.GasLimit 汇总的事件日志，代码为：var coalescedLogs []*types.Log 循环处理交易列表 txs： 在以下三种情况下，我们将中断交易的执行。对于前两种情况，半成品将被丢弃。对于第三种情况，半成品将被提交给共识引擎。需要特别说明的是，这一步会根据 w.current.header.GasLimit 和 w.current.gasPool.Gas() 计算事件 intervalAdjust 的字段 ratio，并将字段 inc 设为 true，然后将事件 intervalAdjust 发送给通道 w.resubmitAdjustCh，从而驱动命名协程 worker.newWorkLoop() 的工作流程。具备的可以参考代码。 （1）新的区块头块事件到达，中断信号为1。 （2）对象 worker 启动或重启，中断信号为1。 （3）对象 worker 用任何新到达的交易重新创建挖掘区块，中断信号为2。 直接返回，退出整个循环和此方法。见代码：return atomic.LoadInt32(interrupt) == commitInterruptNewHead 如果没有足够的 Gas 进行任何进一步的交易，那么就退出循环。见代码：if w.current.gasPool.Gas() < params.TxGas 输出一条重要的日志信息：log.Trace("Not enough gas for further transactions", "have", w.current.gasPool, "want", params.TxGas) 需要说明的，已经提交并得到正常处理的交易仍然不变。 获取下一个交易 tx，如果为空则退出整个循环。 获取交易的发起者 from。见代码：from, _ := types.Sender(w.current.signer, tx) 这里可能会忽略错误。交易在被加入交易池时已经得到了检查。 无论当前的 hf 如何，我们都使用 eip155 签名者。 检查交易 tx 是否重播受保护。如果我们不在 EIP155 hf 阶段，请在我们开始之前开始忽略发送方。 即过滤掉此交易。当然，仍然要从 txs 中剔除。见代码：txs.Pop(); continue 开始执行交易： 更新状态树。需要说明的是，这一步会记录交易在区块中的索引。见代码：w.current.state.Prepare(tx.Hash(), common.Hash, w.current.tcount) 通过方法 worker.commitTransaction() 提交交易。见代码：logs, err := w.commitTransaction(tx, coinbase)。根据返回值 err 决定后面的操作： case core.ErrGasLimitReached 弹出当前超出 Gas 的交易，而不从账户中转移下一个交易。这是因为，该账户已经支付不起 Gas 了，所以不需要再处理该账户的其它交易。这个实现有点漂亮！！！ 输出重要的日志信息：log.Trace("Gas limit exceeded for current block", "sender", from) txs.Pop() case core.ErrNonceTooLow 交易池和矿工之间的新区块头通知数据竞争，转移该账户下一个交易。 输出重要的日志信息：log.Trace("Skipping transaction with low nonce", "sender", from, "nonce", tx.Nonce()) txs.Shift() case core.ErrNonceTooHigh 事务池和矿工之间的重组通知数据竞争，跳过 account 的所有交易 输出重要的日志信息：log.Trace("Skipping account with hight nonce", "sender", from, "nonce", tx.Nonce()) txs.Pop() case nil 一切正常，收集日志并从同一帐户转移下一个交易 coalescedLogs = append(coalescedLogs, logs...) w.current.tcount++，需要增加当前区块的交易索引。 txs.Shift() default: 奇怪的错误，丢弃事务并获得下一个（注意，nonce-too-high子句将阻止我们徒劳地执行）。 输出重要的日志信息：log.Debug("Transaction failed, account skipped", "hash", tx.Hash(), "err", err) txs.Shift() 我们在挖掘时不会推送pendingLogsEvent。原因是当我们开采时，工人将每3秒钟再生一次采矿区。为了避免推送重复的pendingLog，我们禁用挂起的日志推送。 构建日志集合 coalescedLogs 的副本 cpy，避免同步问题 启动一个独立的匿名协程，将日志集合的副本 cpy 通过方法 TypeMux.Post() 发送出去。 如果当前间隔大于用户指定的间隔，则通知重新提交循环以减少重新提交间隔。代码为：w.resubmitAdjustCh <- &intervalAdjust。即将事件 intervalAdjust 发送到通道 w.resubmitAdjustCh，从而驱动命名协和 worker.newWorkLoop() 的后续逻辑。 (20) func (w *worker) commitNewWork(interrupt *int32, noempty bool, timestamp int64)：方法 commitNewWork() 基于父区块生成几个新的签名任务。参数：interrupt *int32： 中断信号，值为：commitInterruptNone (0)、commitInterruptNewHead (1)、commitInterruptResubmit (2) 之一。 noempty bool： ??? timestamp int64： ??? 区块时间？ 主要实现：加锁、解锁 w.mu。说明对整个方法进行了加锁处理。 获取当前时间 tstart，代码为：tstart := time.Now() 获取父区块 parent，即区块链上的当前区块。代码为：parent := w.chain.CurrentBlock() 根据父区块的时间，调整下一个区块的时间。 如果挖矿太超前，计算超前时间 wait，并睡眠 wait 时间。同时，输出日志：log.Info("Mining too far in the future", "wait", common.PrettyDuration(wait)) 获取父区块编号 num，代码为：num := parent.Number() 构建打包中的区块头 header，代码为：header := &types.Header 只有在共识引擎正在运行中，才设置 coinbase（避免虚假区块奖励） 如果 w.coinbase == (common.Address)，则输出日志信息：log.Error("Refusing to mine without etherbase")。同时，退出整个方法。 header.Coinbase = w.coinbase 调用共识引擎的方法 Prepare() 设置区块头 header 中的共识字段。如果失败，则输出日志信息：log.Error("Failed to prepare header for mining", "err", err)。同时，退出整个方法。 处理 DAO 硬分叉相关内容，暂时忽略。 构建挖矿的当前环境，代码为：w.makeCurrent(parent, header)。如果失败，输出日志：log.Error("Failed to create mining context", "err", err)。同时，退出整个方法。 env := w.current 对 env 应用 DAO 相关操作。 删除 w.possibleUncles 中相对于当前区块太旧的叔区块 遍历 w.possibleUncles 累计当前区块的叔区块列表 uncles，最多支持 2 个叔区块。 下一个可能的叔区块（hash 和 uncle） 如果叔区块列表 uncles 的长度已经达到 2，则退出遍历操作。 通过 w.commitUncle() 提交叔区块 uncle 如果失败，输出日志：log.Trace("Possible uncle rejected", "hash", hash, "reason", err) 如果成功，输出日志：log.Debug("Committing new uncle to block", "hash", hash)。同时，uncles = append(uncles, uncle.Header()) if !noempty 基于临时复制状态创建空区块以提前进行签名，而无需等待区块执行完成。 w.commit(uncles, nil, false, tstart) 使用所有可用的待处理交易填充区块。代码为：pending, err := w.eth.TxPool().Pending()。如果失败，则输出日志：log.Error("Failed to fetch pending transactions", "err", err)。同时，退出整个方法。需要说明的是，从交易池中获取所有待处理的交易列表，pending 的数据结构为：map[common.Address]types.Transactions。 如果没有待处理的交易列表 更新快照。代码为：w.updateSnapshot() 退出整个方法。 将交易池中的交易 pending 划分为本地交易列表 localTxs 和远程交易列表 remoteTxs。本地交易即提交者为 w.coinbase。 具体方法为将事务池中地址为 w.coinbase 的放入本地事务列表，否则放入远程事务列表。 如果本地交易列表 localTxs 的长度大于 0 将 localTxs 封装为数据结构 types.NewTransactionsByPriceAndNonce。代码为：txs := types.NewTransactionsByPriceAndNonce(w.current.signer, localTxs) 提交交易列表。代码为：w.commitTransactions(txs, w.coinbase, interrupt)。如果失败，退出整个方法。 如果本地交易列表 remoteTxs 的长度大于 0 将 remoteTxs 封装为数据结构 types.NewTransactionsByPriceAndNonce。代码为：txs := types.NewTransactionsByPriceAndNonce(w.current.signer, remoteTxs) 提交交易列表。代码为：w.commitTransactions(txs, w.coinbase, interrupt)。如果失败，退出整个方法。 调用方法 w.commit() 组装出最终的任务 task。 (21) func (w worker) commit(uncles []types.Header, interval func(), update bool, start time.Time) error方法 commit() 运行任何交易的后续状态修改，组装最终区块，并在共识引擎运行时提交新工作。参数：uncles []*types.Header： 叔区块列表 interval func()： 中断函数 update bool： 是否更新快照 start time.Time： 方法被调用的时间 返回值：如果出错则返回出错消息，否则返回 nil。 主要实现：为了避免在不同任务之间的交互，通过深度拷贝构建 current.receipts 的副本 receipts。 构建状态数据库 w.current.state 的副本 s。 调用共识引擎的方法 Finalize() 构建出最终待签名的区块 block。需要特别说明的是：对于待组装的区块来说，除了叔区块列表 uncles 是作为参数传入之外，其它的关键信息，如：区块头、交易列表、交易回执列表都是在当前环境 w.current 中获取的。 如果对象 worker 正在运行中： 如果中断函数 interval 非空，则调用函数 interval()。 构建任务 task，并将其发送到通道 taskCh，从而驱动命名协程 worker.taskLoop() 的工作流程。 删除待确认区块列表中的过期区块，代码为：w.unconfirmed.Shift(block.NumberU64() - 1) 累计区块 block 中所有交易消耗 Gas 的总和 feesWei。第 i 个交易 tx 消耗的 Gas 计算方式： receipts[i].GasUsed * tx.GasPrice() 将 feesWei 转换成 feesEth，即消耗的总以太币。 至此，已经打包好了最终的待签名区块。输出一条重要的日志信息：log.Info("Commit new mining work", "number", block.Number(), "sealhash", w.engine.SealHash(block.Header()), "uncles", len(uncles), "txs", w.current.tcount, "gas", block.GasUsed(), "fees", feesEth, "elapsed", common.PrettyDuration(time.Since(start))) 持续监听通道 worker.exitCh，如果接收到中止消息则输出日志：log.Info("Worker has exited") 如果 update 为 true，则更新快照： 调用 w.updateSnapshot() 更新待处理的快照和状态。 方法 worker.commit() （由命名协程 worker.mainLoop() 调用）将消息 task 发送给通道 taskCh。此方法先将当前环境中的区块头（w.current.header）、事务列表（w.current.txs）、收据列表（w.current.receipts）作为参数传递给共识引擎的方法 Finalize() 组装出待签名的区块，代码为 block = w.engine.Finalize(w.chain, w.current.header, s, w.current.txs, uncles, w.current.receipts)。需要注意的是，区块 types.Block 中只包含区块头 types.Header、事务列表 []types.Transaction、叔区块列表 []types.Header，并不包含收据列表 []types.Receipt，但是区块头 types.Header 中的字段 ReceiptHash 是收据列表树的根哈希，所以也需要收据列表参数。将组装后的待签名区块 types.Block，及前面解释过的收据列表 []types.Receipt 等其它参数一起构建出新的任务 task 发送给通道 taskCh，同时输出一条重要的日志信息：log.Info("Commit new mining work", "number", block.Number(), "sealhash", w.engine.SealHash(block.Header()), "uncles", len(uncles), "txs", w.current.tcount, "gas", block.GasUsed(), "fees", feesEth, "elapsed", common.PrettyDuration(time.Since(start)))。到方法 commit() 这一步，已经组装出了新的任务 task，并将此新任务 task 通过通道 taskCh 发送给命名协程 worker.taskLoop()。Referencehttps://github.com/ethereum/go-ethereum/blob/master/miner/worker.go ContributorWindstamp, https://github.com/windstamp

时戳资本 | 2018年度研报总结 本文链接：https://www.8btc.com/article/348219 转载请注明文章出处

研报 | 分片技术研究报告（上） 去中心化、安全和可拓展性无法同时满足，被称为区块链的不可能三角。为了让项目方和投资者正确认识到分片技术对于公链的必要性以及其可能带来的影响，TokenInsight 详细分析了目前公链面临性能瓶颈的原因，分别计算网络带宽、硬盘容量和 I/O、内存和 CPU 计算能力等限制条件构成的性能瓶颈。对比多种链上扩容方案，经分析认为，分片是最有希望能够实现高性能而不降低去中心化程度的链上扩容方案。针对分片技术在不同项目中的应用，TokenInsight 将在【分片技术研究报告（下）】中对主流分片项目进行分析对比，敬请期待。TokenInsight 微信公众号后台回复“分片报告（上）”即可获取【分片技术研究报告（上）】PDF版本文链接：https://www.8btc.com/article/348469 转载请注明文章出处

通证分类白皮书：行业属性、功能属性、技术属性详解 目前市面中针对通证和项目进行分类的方法较多，但因分类逻辑不统一、分类方法不明确、分类结果不互斥，导致分类效果大打折扣，难以作为行业通用标准进行推广使用。TokenInsight在超过1500个项目评级的基础上，通过大量的数据积累和审慎的行业观察，运用聚类思维，为市场建立了一套成熟全面逻辑一致的通证分类框架。该框架由三个维度组成：第一个维度是行业属性，以互斥的行业名称为基础，借助“标签”体系，定位发行某通证的项目所在的行业。 第二个维度是功能属性，将通证分为“加密货币型”，“效用型”和“权益型”。 第三个维度是技术属性，有“原生通证”和“衍生通证”两个类别，刻画了通证与项目之间的关系。TokenInsight也因此成为第一家以支撑研究为目的，以风险识别为导向，设计出“互斥”行业分类的机构（具体参见维度一）。 本文链接：https://www.8btc.com/article/351293 转载请注明文章出处

研究：STO将如何革新房地产行业 导语：无论从市场上可获取公开信息的数字化证券项目，还是根据标准共识提供咨询服务的项目信息来看，我们都可以确定：全球房地产行业正在经历一次应用区块链技术的革新。数字化证券及相关区块链技术不仅会改变相关的融资方式，我们可以设想区块链技术改变土地注册方式、智能合约带来的交易方式革新、以及资产“可编程” 化以后全新的管理方式等，将为传统房地产行业带来怎样的冲击。房地产市场作为全球最大的投资市场，其中巨大的投资潜力是其成为吸引新技术和新人才的最佳领域的原因。虽然房地产行业历史悠久，但 MBS 这类新金融产品的投资者教育普及，该行业对数字化证券发行的接受程度普遍较高。不同的资产适合不同的融资方式，不过从本篇的行业分析和展望来看，房地产行业的融资手段迎接数字化证券革新是一个明确的趋势。 本文链接：https://www.8btc.com/article/354927 转载请注明文章出处

STO 行业分析报告：区块链、房地产接受程度最高 在数字货币市场低迷和全球经济下滑的情况，STO 是新的机会。它凭借低成本、高合规、灵活等诸多优势，正成为各类企业的募资首选。1970 年 2 月，美国房屋和城市发展部发行了第一支现代住房抵押贷款支持证券，现代资产证券化从此拉开序幕。这类金融资产的发行和流通在全球金融市场扮演了重要角色。在当前这样一个不断数字化的时代，STO 也可能成为未来金融市场新的宠儿。2018 年低迷的经济情况和 2019 年可能面临更多风险，导致各类企业募资更困难，不确定性更高。BTC 价格从近 20000 美金下挫到 3500 美金。同时以 代币发行 为代表的数字货币融资市场几乎崩溃，几乎失去了募资功能。STO 就是在这样的契机下出现，它既能降低企业的募资成本，还能满足监管合规要求。数字化证券综合了传统金融证券化和通证的优势，为发行人和投资人提供了更有效的募资和投资工具。本篇研究报告将对这个新兴发展的事物展开研究和分析，分享我们的一些工作成果。本文链接：https://www.8btc.com/article/355578 转载请注明文章出处

研报 | 比特币可拓展性现状与解决方案 研读Vitalik近日内再次对比特币可拓展性问题发表了批评的意见，并称由于其所产生的超额费用导致的损失超过了门头沟黑客事件的损失金额。增加区块大小，或是减少出块时间对于网络的可拓展性是否真实有效？摘要比特币的可拓展性问题往往与区块链价值主张相结合，因此不能通过改变区块链中的参数来简单地增强可拓展性。比特币社区主要可以调整两个变量来尝试增加每秒事物处理数量（TPS）。一个变量是区块大小，另一个变量是区块生成时间。大多人会发现仅仅增加区块大小或降低挖掘复杂性对于可拓展性提升有限。由于事务传播中继时间，尝试以比旧块更快的速度挖掘新块会导致一些相当大的安全问题。围绕比特币的可拓展性现有一系列的解决方案，包括批量事务处理，闪电网络，硬分叉，甚至是全新的共识机制修改。然而另一个考虑因素是了解当前行业发展阶段所需的权衡，即目前所有可用的解决方案都有局限性的。风险提示：加密数字市场具有高投资性、高波动性的风险特征，存在过度炒作、概念宣传等投资风险。本文仅为行业方向研究，不作为投资参考依据。 本文链接：https://www.8btc.com/article/357242 转载请注明文章出处

研报 | 分片技术研究报告（下） 在分片技术研究报告（上）中，TokenInsight分析了造成公链可扩展性问题的原因以及资源瓶颈，最终得出结论：分片是最有希望能够实现高性能而不降低去中心化程度的链上扩容方案。分片包括网络分片、交易分片、状态分片等，其中状态分片实现难度最大，因此为了更客观地分析各个项目，本篇报告中将状态分片进一步细分为智能合约分片与存储分片。分片虽然是最有希望的链上扩容方案，但其目前仍处于起步和探索阶段，当前市场上还未出现一种能解决所有关键问题的方案。但是相比于 Bitcoin、Ethereum 的性能，现有方案已经有了长足的进步，已基本能够满足现阶段应用的需求。因此近期有众多项目宣布引入分片技术以提升其系统性能。本篇报告将会对 Ethereum 2.0、Zilliqa、QuarkChain、Monoxide 四个热门项目或方案的分片技术部分进行分析，从而让读者对各个项目以及分片技术有更深刻的认识。 本文链接：https://www.8btc.com/article/361997 转载请注明文章出处

2019年DApp调查报告：160款DApp开发者这样说 随着 2017 年的 ICO 狂潮过后，催生出了一系列新的区块链平台，2018 年也因此被称为 DApp 之年。随着 DApp CryptoKitties（http://cryptokitties.co/） 的成功，2018 年有了一个完美的开端，人们也越发期待 DApp 在 2018 年呈现出爆发式增长。Fluence Labs（https://fluence.network/） 的目标是为新兴的 Web3 技术开发出一个能够实时进行大容量数据处理的去中心化网络。作为一个基础设施项目，我们一直都很好奇 DApp 市场上都发生了什么。这项调查从一开始就是为了联系 DApp 开发者社区以便深入了解这个市场正在发生的事情。我们向众多 DApp 开发者和创业者发起问卷调查，希望能通过这项调查来澄清有关 DApp 的事实、猜测和谣言。我们将阐明他们是谁、他们正在做什么、他们将要面临什么样的挑战、在当前市场上有多少活跃的 DApp 项目，以及实现这些 DApp 究竟有多难。我们相信，我们在调查过程中的一些发现不仅可以帮到我们，也可以帮到该领域中的每一个人。这项调查结果将有助于大家更好地理解当前 DApp 在用户接受度和技术可行性方面的状态。关键点：尽管 2018 年市场环境恶劣，受调查的大多数项目却都是在这一年启动的。 在受调查的项目中有四分之一都是游戏相关的 DApp。 大约有一半的项目采用了集中式云服务作为后端，并使用了像 Infura 这样的集中式工具来连接以太坊区块链。 在交易过程中收取交易费用是大多数项目采取的主要盈利模式。 有超过四分之三的受访者认为，引导新用户是影响用户采用的主要障碍。 我们认为，不仅是那些采用了 Web3 技术的开发者对这些发现感兴趣，加密领域内外的投资者和任何想要了解 DApp 将要面临的挑战以启动一个新项目的创业者都会对这些发现感兴趣。为了更好地理解这份调查报告，你可能需要提前了解一些加密内部工作原理和关键术语，比如公钥和私钥、Layer 1/2 区块链以及 MetaMask，等等。这份调查报告的结构和产品开发的生命周期类似。从技术平台的选择开始介绍，然后进入到开发中的常见问题，最后再讨论在用户接受度和业务方面所遇到的挑战。免责声明：这份调查报告不应被视为 Fluence Labs 或者其任何董事、高级职员、普通职员、代理人、顾问等关于购买或认购加密产品的建议。读者也不应将本调查报告的内容解释为法律、税务、监管、财务或者会计等相关的建议。读者应该就其具体事项咨询自己内部的相关顾问。该调查报告的内容纯粹是为了提供信息。在任何情况下，读者都应该对该报告中的数据自行进行调查和分析。1. 一般信息 1.1 DApp 定义首先，我们需要确定哪些项目可以被称为 DApp。“DApp“ 一词来源于以太坊社区，可以用来定义任何以“智能合约“为核心组件的应用程序。为了减少歧义，该报告中所指的 DApp 仅指那些关注最终用户的应用程序。基于该定义，我们共收集到了 1624 款 DApp。在这些应用程序中，我们只找到了其中 900 款应用的联系信息，包括 Email、Telegram 或 Discord 。最终，共有 160 款 DApp 的代表填写了调查问卷。1.2 DApp 调查综述尽管 2018 年的市场环境相当恶劣，但大多数项目（72%）都是在这一年启动的。其中有 12.5% 的受调查项目由独立开发者运营。大多数 DApp 团队成员规模在 2 至 5 人之间（47.5%），团队成员规模超过 5 名的占 40%。2.DApp 组成 2.1 平台（Layer 1 区块链）大多数 DApp 采用以太坊平台（87%），排名第二的是 EOS（19%），第三名是 TRON（8%）。还有 10% 的受调查项目同时构建在多区块链之上。虽然我们对采用了其他区块链的 DApp 非常好奇，但并不能准确的统计出这些项目的数量。2.2 整体技术栈大多数 DApp 都是基于网页作为前端，在受调查项目中，有近一半（48%）的 DApp 采用了传统基于云的后端技术方案。值得注意的是，在选择存储方案方面，采用了去中心化存储方案（比如 IPFS）的项目数量（32%）和采用中心化 CDN 的项目数量（31%）几乎相同。在数据库的选型方面也发现了类似的比例：31% 的 DApp 依赖于集中式数据库，而 25% 的 DApp 采用了分布式数据库。从所使用的技术来看，React 和 Node.js 的采用量遥遥领先，远远超过其他语言和框架。被提及的数据库包括 MongoDB、PostgreSQL 和 MySQL ，其中被提到最多的是 MongoDB。2.3 技术栈的集中式部分超过一半的受访者都提到，他们在开发去中心化项目时，有些基础设施必须采取集中式设计：48% 的受调查项目依赖于集中式后端，31% 的项目采取了集中式的文件存储，以及 21% 的项目采用了身份验证 API（如 Facebook Connect）。3.DApp 开发 3.1 工具质量和文档通常来说，新的开发者加入对促进新技术的采用是至关重要的。与此同时，DApp 的开发者也提到，在去中心化的技术生态中工具和框架都是极不稳定的，它们可能彼此不兼容、缺乏项目文档，有时候它们的运行结果也是不可预知的。“Solidity 有很多‘陷阱’，如果你稍有不慎，这些‘陷阱’带来的结果可能就是灾难性的。” —— 佚名“对于区块链开发者来说，文档的缺失也是一个大问题。”——  CryptoKube“Angular 和以太坊的某些库并不能很好地协作。Docker 是一项很好的技术，但是想要在 DevOps 工作流中正确地配置 Docker 仍然是一项挑战。最后，无论从用户体验的角度还是从技术的角度来看，与以太坊区块链和智能合约的交互都是十分复杂的。” ——   Emoon3.2 区块链网络的状态在以太坊 DApp 开发者中，63% 的受访者提到 Infura 是他们连接以太坊网络的一种方式。一些开发者指出，有时候他们需要采用多种技术来连接到区块链，以保证 DApp 的数据状态和用户接口都是最新的。区块链的连接性问题和节点稳定性问题也是采用多种技术连接到区块链的原因之一，这些问题将影响 DApp 的整体质量，并对最终用户体验产生负面影响。" rel="nofollow noopener" 超级节点是不稳定的，在处理事务时还存在很多问题。”——  佚名“Geth 无法在一台好机器上完成 4 周的数据同步。” —— Alice“主网的行为和测试网络的行为不一样。” —— FABG“速度慢，需要大容量的硬件存储空间。” —— Quick Blocks“Web3 注入会延迟，区块链和 Infura 之间的同步也会延迟。用户交易可能已经批准，服务器却需要几分钟时间来同步用户的交易状态。当然，如果你习惯了这种状态，可能不会觉得这有什么问题。但是相信真正的用户还是更习惯于获得及时反馈，而不是每次点击鼠标操作后，去先喝杯咖啡再回来查看结果。” ——  Chibi Fighters3.3 事件追踪和数据查询受访者表示，从区块链中检索数据也将是一项挑战，尤其是当项目要求具备实时处理性能时。一些开发者采用了内部工具来追踪智能合约中的事件和处理传入的数据。“处理大量 RPC 请求通常是最令人沮丧的。现在主要采用内部负载均衡来解决这个问题。” —— Local Ethereum“当前维护数据库事件是最令人头疼的。我认为应该采用一种现收现付（pay-as-you-go）的服务来解决这类问题。” —— Known Origin“有时网络中的节点非常不稳定（特别是在一年半之前我们遇到了宕机问题），我们需要开发自己的中间件来追踪交易。” —— Alice“以确定性的方式轮询事件和检查区块确认信息是有问题的。” —— Crypto Care4.DApp 的业务问题 4.1 应用的受众虽然可以通过收集发送到智能合约的交易来获取用户信息，但并不是每一次用户和应用的交互都涉及到智能合约调用。由于我们认为开发者能够通过内部分析工具获得准确的用户数量信息，因此我们直接向他们询问了 DApp 的用户数量。尽管有 58% 的 DApp 日活跃用户少于 50 人，但仍然有 12% 的受调查项目日活跃用户在 500 人以上。4.2 资金情况从 2017 年以来，DApp 的主要收入来自于自筹资金（38%）和代币的销售（31%），风险投资参与的项目仅占了 24%。 2018 年，大部分去中心化项目仍然是自筹资金，只有一小部分项目通过代币销售（10%）和风险投资（16%）获得资金。然而，从数字的绝对值来看，这些差别并不明显：代币的销售数据略有下降，而风险投资的数据略有增加。2017 年和 2018 年最大的不同在于，自筹资金的 DApp 数量有了近 4 倍的增长。4.3 货币化大多数的受访者（55%）表示希望通过收取交易费用来赚钱。还有一些受访者表示计划通过用户订阅（16%）和广告（11%）收益来赚钱。另外，还有一些受访者建议出售 NFT 或者将以太坊作为潜在的货币化模型。还有其他一些人提到的其他商业模式如下：“部署代币作，作为桌面客户端使用许可，从通过我们的 DApp 获利的用户那里收取许可费用。” —— Kryptium“发布一款基于 ERC-20 标准的代币，比如 Augur 或者 KEEP，然后随着时间的推移，他的价值会得到升值。我们可以动态改变代币机制，并设置独立的实体来提供集中式的服务，从而增加收入。但是在这个过程中，最重要的组织服务应该还是免费的，不收取任何费用。“  —— 佚名5. 用户体验 5.1 用户引导当被问起在推广 DApp 时遇到的挑战时，开发人员提到新用户引导是他们最担心的问题，因为接受加密应用程序的用户群体数量是有限的。向新接触 DApp 的用户解释这些概念很难，比如：创建钱包、获得代币以及什么是 gas。"先从认识钱包开始，告诉他们用各种各样的软件“登录”钱包，尽管其中的一些软件充满了欺诈，并且还要告诉他们，不要丢失软件的密码，否则将会永远失去该账户，无法找回。如果没有一个好的用户引导工具，这样的应用程序将很难被用户所接受。" ——  佚名“应用程序新用户也不知道他们该设置多少 gas 比较合适。”  ——  Riot Cats“让他们了解以太币也是一项巨大的挑战。在代币交易中使用以太币进行交易的人仍然是少数。” —— Daxia“新用户引导。只要钱包已经被设置好了，并且手里有一定的以太币，那么接下来的事情就比较容易理解了。” —— Crypto Care“如果对于开发者来说创建钱包都觉得很复杂的话，那么我们又怎么能期待一个非技术人员愿意采用用户体验很糟糕的加密产品呢？” ——  FundRequest“当前，创建一个 EOS 钱包的步骤非常复杂。除此之外，CPU 使用时间和 RAM 的概念对于一个普通人来说是很难理解的。这些都是人们接受 DApp 的障碍。” —— Dice一些基于以太坊区块链开发 DApp 的开发者表示，MetaMask 的用户体验需要得到进一步改善。其中的一个原因就是：单独对每一笔交易进行签名会导致过多的问题，特别是对于那些复杂一点的应用程序来说。“对于简单的单页游戏来说，MetaMask 表现良好。但是像“赤壁战士 (Chibi Fighters)“这样的复杂游戏，可以支持同时开十个网页，这使得它在各个地方风靡。” —— Chibi Fighters“每一笔交易都需要在 MetaMask 中签名。” —— FABG5.2 理解 DApp 和加密技术一些受访者也提到了另一个问题：他们需要去教育那些对密码学没有深入研究的用户。在调查报告中体现的问题之一就是，用户总是对加密应用程序中没有 “修改密码” 选项感到很吃惊。另一个问题是，用户总是不能够理解加密货币、ERC20 代币和非同质代币的区别。"我们没有预料到的一件事情是，我们还需要帮助人们理解 CryptoKitties 不是一种加密货币。" rel="nofollow noopener" ——  CryptoKitties“最让我意想不到的是，我们的 DApp 和其他 DApp 都在同一个平台上。” —— CryptoKitties City“然而，在新兴的经济体下，假设加密货币对非银行用户处于完全可扩展的状态，那么要求他们安全保存自己的私钥就太过分了。” —— Ethichub“我们并没有存储用户的密码，因此我们无法帮助用户重置他们的账户。” ——  Primas“我们并没有采取 OAuth2 风格的用户认证流程，即用户可以在应用程序中注册账户，并在其他平台上使用。这是 Be Your Own Bank 和身份管理器面临的一个最大的问题。” —— 佚名 6. 技术要点 6.1 可扩展性为了解决可扩展性问题，大多数受调查项目的开发人员计划使用 Layer 2 区块链或者其他相应的解决方案来处理用户增长所带来的问题。然而，仍然有 33% 的 DApp 开发者对于如何扩展持续增长的容量没有明确的计划。39% 的受访者计划使用现有的 Layer 2 区块链平台，27% 的受访者表示他们将构建自己的区块链平台。6.2 去中心化受访者对采用分布式计算和存储平台作为构建块来实现未来可伸缩性持乐观态度。然而，还有大约四分之一的开发者计划采用集中式的硬件设备进行密集计算。尽管如此，32% 的受访者表示，他们可能会在未来使用分布式数据库服务作为主要的数据存储解决方案，另外有 33% 的受访者表示他们正在考虑采用分布式的文件存储方案。总结在区块链生态体系中，人们普遍认为可扩展性是基于区块链应用程序首要面临的主要障碍。相反，DApp 开发者回应说，他们目前遇到的最大痛点是“有限的用户数量“（占 67%）和“用户体验差“（占 44%）。尽管只有 36% 的受访者提到了可扩展性可能带来的限制，但一旦项目拥有了更多的用户，可扩展性最终将会成为优先考虑的问题。我们相信以下这些有助于减少 DApp 和用户之间的摩擦：Web 浏览器和加密钱包之间更深层次的集成。这样的集成可能是双向的：浏览器与加密钱包的集成（比如 Opera 浏览器 正在这么做）以及在加密钱包中集成去中心化浏览器（参见以太坊的 Status 和 Trust Wallet，以及 EOS 的 Token Pocket、Math Wallet 和 Lynx）。 一些新兴的可重用跨平台认证和用户引导工具，为用户提供了更好的移动端、网页端和桌面端交互体验（比如 Scatter 和 UniversallLogin）。 被广泛采用的解决方案为最终用户消除 Gas 成本（比如 Loom network、Meta transaction）。 我们热切期待着 2019 年 DApp 的发展。作为区块链领域的一个基础设施类项目，我们也一直在关注着 DApp 整个生态系统，并尽力与之保持联系。在未来的一年内，我们将尽可能为我们的研究提出更多的见解。 来源：区块链前哨原文链接：https://medium.com/fluence-network/dapp-survey-results-2019-a04373db6452译者：徐进本文链接：https://www.8btc.com/article/359817 转载请注明文章出处

研报：区块链赋能电网系统研究初探 区块链技术在传统行业中的应用日渐清晰，近期，TokenInsight 对其行业分类框架下的传统行业进行了系统研究，并结合中国能源行业发展现状对区块链在能源行业的应用进行了初探。根据研究，TokenInsight 总结出区块链在电力行业中的 5 大潜在应用场景并予以分析，助力区块链技术赋能传统行业。 本文链接：https://www.8btc.com/article/360786 转载请注明文章出处