- 第 1 章 区块链
- 第 2 章 以太坊
- 第 3 章 以太坊私链入门
- 第 4 章 以太坊网络
- 第 5 章 geth v1.8.16 命令详解
- 第 6 章 Wallet
- 第 7 章 Token
- 第 8 章 智能合约语言 Solidity v0.5.0
- 第 9 章 Truffle v4.1.8 开发框架
- 第 10 章 web3.js - 1.0.0
- 第 11 章 web3j v3.4.0 - Jave Client
- 11.2. 启动以太坊
- 11.3. Maven pom.xml 文件
- 11.4. Java 与 Solidity 数据类型映射关系
- 11.5. 常量
- 11.6. 连接到服务器获取版本号
- 11.7. 获得以太坊状态信息
- 11.8. 单位转换
- 11.9. 账号管理
- 11.10. Credentials
- 11.11. 交易
- 11.12. 钱包
- 11.13. 智能合约
- 11.14. ERC20合约
- 11.15. Infura
- 11.16. 助记词
- 11.17. 过滤器 (Filter)
- 11.18. Subscription
- 11.19. 解锁账号
- 11.20. IBAN (International Bank Account Number)
- 11.21. Springboot with Ethereum (web3j)
- 第 12 章 web3.py - A python interface for interacting with the Ethereum blockchain and ecosystem.
- 第 14 章 Ethereum Developer APIs
- 第 15 章 infura
- 第 16 章 以太坊案例
- 第 17 章 FAQ
- 17.3. Error: authentication needed: password or unlock
- 17.4. 新增节点后不生效
- 17.5. Unhandled rejection Error: Returned error: The method personal_unlockAccount does not exist/is not available
- 17.6. Error: exceeds block gas limit
- 17.7. Migrations.sol:11:3: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(…) { … }" instead.
- 17.8. Exception in thread "main" rx.exceptions.OnErrorNotImplementedException: Invalid response received: okhttp3.internal.http.RealResponseBody@6c25e6c4
- 17.9. 旧版本 Remix(browser-solidity) 本地安装
- 第 18 章 Hyperledger Fabric v2.0.0
- 第 19 章 Hyperledger Fabric 运维
- 第 20 章 Chaincode 链码(智能合约)
- 第 21 章 Hyperledger Fabric Client SDK for Node.js
- 第 22 章 fabric-sdk-java
- 第 24 章 已知 Hyperledger 落地案例
- 第 25 章 Fabric Command
- 第 26 章 Fabric FAQ
- 第 27 章 IPFS(InterPlanetary File System,星际文件系统)
- 第 28 章 IPFS 命令
- 第 29 章 IPFS WebUI
- 第 30 章 IPFS 集群配置
- 第 31 章 IPFS API
- 第 32 章 IPFS Faq
- 第 33 章 EOS
- 第 34 章 EOS 安装
- 第 35 章 CLEOS
- 第 36 章 智能合约开发
- 第 37 章 EOS Dapp 开发
- 第 38 章 FAQ
- 第 39 章 BaaS (Blockchain as a Service) 平台
- 第 40 章 BitCoin
- 第 41 章 其他区块链相关
- 附录 1. 附录
1.15. 共识机制
1.15. 共识机制
共识机制,就是所有记账节点之间如何达成共识,去认定一个记录的有效性,这既是认定的手段,也是防止篡改的手段。目前主要有四大类共识机制:PoW、PoS、DPoS和分布式一致性算法。
1.15.1. PoW(Proofof Work,工作量证明)
PoW机制,也就是像比特币的挖矿机制,矿工通过把网络尚未记录的现有交易打包到一个区块,然后不断遍历尝试来寻找一个随机数,使得新区块加上随机数的哈希值满足一定的难度条件。找到满足条件的随机数,就相当于确定了区块链最新的一个区块,也相当于获得了区块链的本轮记账权。矿工把满足挖矿难度条件的区块在网络中广播出去,全网其他节点在验证该区块满足挖矿难度条件,同时区块里的交易数据符合协议规范后,将各自把该区块链接到自己版本的区块链上,从而在全网形成对当前网络状态的共识。
优点:完全去中心化,节点自由进出,避免了建立和维护中心化信用机构的成本。只要网络破坏者的算力不超过网络总算力的50%,网络的交易状态就能达成一致。
缺点:目前比特币挖矿造成大量的资源浪费;另外挖矿的激励机制也造成矿池算力的高度集中,背离了当初去中心化设计的初衷。更大的问题是PoW机制的共识达成的周期较长,每秒只能最多做7笔交易,不适合商业应用。
1.15.2. PoS(Proofof Stake,权益证明)
PoS机制,要求节点提供拥有一定数量的代币证明来获取竞争区块链记账权的一种分布式共识机制。如果单纯依靠代币余额来决定记账者必然使得富有者胜出,导致记账权的中心化,降低共识的公正性,因此不同的PoS机制在权益证明的基础上,采用不同方式来增加记账权的随机性来避免中心化。例如点点币(Peer Coin)PoS机制中,拥有最多链龄长的比特币获得记账权的几率就越大。NXT和Blackcoin则采用一个公式来预测下一记账的节点。拥有多的代币被选为记账节点的概率就会大。未来以太坊也会从目前的PoW机制转换到PoS机制,从目前看到的资料看,以太坊的PoS机制将采用节点下赌注来赌下一个区块,赌中者有额外以太币奖,赌不中者会被扣以太币的方式来达成下一区块的共识。
优点:在一定程度上缩短了共识达成的时间,降低了PoW机制的资源浪费。
缺点:破坏者对网络攻击的成本低,网络的安全性有待验证。另外拥有代币数量大的节点获得记账权的几率更大,会使得网络的共识受少数富裕账户支配,从而失去公正性。
1.15.3. DPoS(DelegatedProof-Of-Stake,股份授权证明)
DPoS很容易理解,类似于现代企业董事会制度。比特股采用的DPoS机制是由持股者投票选出一定数量的见证人,每个见证人按序有两秒的权限时间生成区块,若见证人在给定的时间片不能生成区块,区块生成权限交给下一个时间片对应的见证人。持股人可以随时通过投票更换这些见证人。DPoS的这种设计使得区块的生成更为快速,也更加节能。从某种角度来说,DPOS可以理解为多中心系统,兼具去中心化和中心化优势。
优点:大幅缩小参与验证和记账节点的数量,可以达到秒级的共识验证。
缺点:选举固定数量的见证人作记账候选人有可能不适合于完全去中心化的场景。另外在网络节点数少的场景,选举的见证人的代表性也不强。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论