10-1 区块链治理概念
区块链治理概述
如何协调众多利益方来进行区块链平台的改进和管理,即制定业务运作规则,确保规则的执行,处理异常事件,奖励和惩罚参与者等
链下治理
由社区信任的人聚集在一起形成一个小组,负责区块链的治理和利益的划分,该小组负责修复协议中的安全漏洞和隐患,提高区块链的可扩展性并增添新的功能。同时,作为代表参与公开的讨论和生态会议,保持用户、企业和矿工之间的权利平衡
链上治理
链上治理将更改建议写入区块链协议的代码当中,开发者可以将建议的更改提交到区块链的更新中,而每个通证持有者都可以对此投出赞成票或者反对票。链上治理使得协议方可以决定区块链本身的发展方向。
链下治理和链上治理特点
良好的治理模式能让区块链协议适应不断变化的环境,同时也能够维护治理服务本身去中心化的生态系统内的决策合法性
治理类型 | 链下治理 | 链上治理 |
---|---|---|
优点 | 可以带来诸如快速执行、减少冲突、责任明确等好处 | 理论上每个节点都有权利对规则更改做出投票,并且相应的更改可以在较短的时间内得以实现。降低区块链强行分叉的可能性 |
缺点 | 安全性差、权利滥用、缺乏透明度等 | 节点投票率往往偏低,在某些设计机制中可以通过控制大量的投票权来主导社区的方向 |
区块链治理内容
区块链的治理主要体现在元治理、基础网络治理、应用治理三个方面
元治理
指对治理协议本身的治理,包括提案模型、治理流程、治理策略、联盟链委员会选举等,是一切治理的源头
基础网络治理
是对区块链网络的治理,包括节点的准入、记账节点的选举、节点参数的调整、共识机制的升级、智能合约部署等
应用治理
是对基于区块链网络上层应用治理,包括接口调用权限管理、应用参数调整、应用版本更新和应用生命周期管理等
公链治理角色
区块链的治理利益相关者主要包括核心开发者、全节点运营商、基金会及代币持有者。
核心开发者
每个区块链都有一个核心软件存储库,用于保存其协议主要实现的代码。这些软件存储库由核心开发人员团队密切管理,他们拥有向存储库添加或删除代码的流程
全节点运营商
所有全节点都包含区块链的完整分布式账本以及运行P2P协议的路由软件,要使代码更改生效,节点需要单独更新其软件使其包含更新的代码
基金会
基金会通常负责提供整体方向指导、制定发展蓝图。虽然基金会可以影响路线图,但无法执行,执行取决于编写实际代码的核心开发人员
代币持有者
代币持有者在意现有手中价值的增长,也愿意改善系统的核心使用功能。若核心开发者和全节点都同意,而绝大部分代币持有者不接受更改,代币持有者可能会集体抛售代币使得整个系统陷入混乱
在一个合理的治理机制里,要考虑各方的利益诉求和整体协调,他们有共同的利益诉求,但往往出发点不同。
公链治理角色合作共识
区块链的治理通常由四个利益相关者相互制衡而形成,是参与者之间进行互动和合作得到共识的
核心开发人员可以发布新代码,但除非全节点实现这些更改,否则更改将不会生效
全节点依赖于软件开发人员来构建和发布改进协议所需的更新,但如果他们不同意核心开发人员的决策,他们可以创建一个有争议的硬分叉
基金会可以通过决定哪些核心开发人员来支持并影响路线图和协议的总体方向,但如果没有核心开发人员和全节点的支持,它就无法实现愿景
代币持有者通常不会直接影响更新区块链的过程,但可以通过选择是否使用加密货币而造成间接影响
联盟链治理角色
联盟链治理角色是对治理参与方的权限进行划分,按照权限共划分为四类,分别是系统管理员、提议者、投票者、参与者
系统管理员
拥有开启和关闭应用合约治理、系统合约治理、平台治理,同时拥有设置治理策略的能力
提议者
拥有治理项提议能力,一种治理项可设置多个提议用户
投票者
拥有治理项的投票能力,一种治理项可设置多个投票用户
参与者
拥有查看治理项的能力,一种治理项可设置多个参与用户
不同角色之间相互依赖和制约,共同维护区块链的健康发展
区块链链下治理
链下治理通用流程
链下治理的基础是生态中的参与者广泛参与讨论,其主要流程如下
- 参与者研究并制定变更提案
- 参与者在社交媒体上对提案表达观点,并进行充分讨论
- 核心开发者根据社区的反馈决定是否接受该提案
- 如果接受,开发者会对项目代码进行更新和升级
- 矿工、节点运营商和社区决定是否支持提案
- 如果支持,他们会选择升级节点客户端并维护新链
链下治理的过程中几乎没有明确的规则去奖励治理机制中的积极参与者,容易造成“搭便车”行为;第二,虽然链下治理多为三权分立,但基金会通常占据主导的地位,掌握提案、分发奖励或增发代币等关键权力,如何制衡也是一大问题
链下治理模式例子
链下治理模式下为了实施协议的变更,必须达成更广泛的共识。
比特币治理
比特币治理模式的重点是在网络参与者之间达成共识,尤其是要在运营全节点的参与者之间建立共识。开发者可以通过BIP(比特币改进建议)协调更新,这是一种链外治理的方式
以太坊治理
以太坊治理模式在许多方面都借鉴了比特币的治理模式。开发人员可以通过EIP(以太坊改进建议)进行更新。EIP作为一个基础的应用程序,它让开发人员可以表达他们对代码改进的想法和建议。开发人员整理这些建议并整合方案,之后社区(全节点)就可以进行安装和使用
区块链链上治理
链上治理通用流程
- 参与者可以研究并制定提案
- 通过区块链对提案进行投票
- 统计投票结果,如果提案通过,所有节点自动升级
采用链上治理的区块链一般不会发生硬分叉,但链上治理也存在一些问题,特别是持有大量代币的参与者在链上治理中拥有的权力过大,持币数量较少的参与者的参与积极性不高
链上治理模式例子
Tezos治理
Tezos团队称其项目为“第一个自我修正的加密资产”,治理主要通过内置的链上治理机制来不断地更新系统,以避免分叉的发生。
任何人都可以以代码更新的形式提交对治理结构的更改。发出链上投票,如果通过,更新将进入测试网络。在测试网络上运行一段时间后,会进行确认投票,此时更改会在主网络上生效。
选举周期
- 提议阶段
- 投票探索阶段
- 测试阶段
- 投票推广阶段
10-2 治理系统的应用
比特币系统治理
比特币改进提议BIP
比特币改进提议BIP(Bitcoin improvementproposals)是一种设计文档,为比特币社区提供信息,或描述比特币或其流程或环境的新功能。BIP大致分为三种:标准类、信息类和进程类。
标准类
描述了影响大多数或所有比特币实现的任何变更,如网络协议的更改、块或交易有效性规则的更改、影响比特币使用的应用程序的互操作性的任何更改或添加
信息类
描述比特币设计问题,或向比特币社区提供一般指导或信息,但不提出新功能。信息BIP不一定代表比特币社区的共识或建议,因此用户和实现者可以自由地忽略信息BIP或遵循该建议
进程类
描述或提议流程变更。与标准BIP提议类似,但适用于比特币协议本身以外的区域。与信息BIP不同,进程BIP不仅仅是建议,用户通常不能自由忽略
比特币改进流程
实施BIP必须从草案阶段、提议阶段到最终阶段,具体流程如下
草案(Draft):BIP作为草案提交给比特币开发邮件列表和BIP GitHub代码仓库
提议(Proposed):BIP包括了一个含有部署BIP计划的工作执行方案
最终(Final):BIP符合现实世界的采用标准。且必须客观地验证这一点
延期(Deferred):BIP的提交人可以在没有取得任何进展的情况下将其状态更改为延期
撤回(withdraw):BIP的提交人也可以选择完全撤回BIP
被拒绝(Rejected):如果三年内没有取得任何进展,任何人都可以请求将BIP移至被拒绝状态
替换(Replaced):如果先前的最终BIP变得无关紧要,则将其标记为已替换
草案
草案阶段的目标是将关于比特币的新想法格式化为标准的BIP,并尽快开始征求社区的反馈意见
- BIP的提交人负责审查社区的想法,以评估该想法的可行性,并围绕它建立社区共识,应该与比特币开发者邮件列表以及Bitcoin Talk技术论坛分享想法
- 提交人创建一份BIP草案,被将其提交给比特币开发邮件列表进行讨论
- 在讨论之后,提交人将提议作为拉取请求提交给BIP GitHub代码仓库。BIP代码仓库的编辑器为提案分配一个数字,根据类型对其进行标记,然后将其添加到代码存储库中
- 为了推动草案进入提议,当提交人处理完成社区存在的任何异议时,BIP会认为草案已经完成并且其中包含了提议的工作执行方案
提议
当BIP的状态更改为提议时,从讨论状态转移到实际比特币协议中的部署,通过软分叉或硬分叉将BIP执行到代码中
软分叉引入了向后兼容的协议更改,这意味着运行最新版本软件的节点仍然与运行旧版本的节点兼容
硬分叉引入了不向后兼容的协议更改,如果大量节点不升级包含新软件的客户端,则链会被一分为二,因此,硬分叉是比BIP实施风险更高的方式
当BIP成功地通过硬分叉或软分叉发起执行,并且在比特币协议中被实现时,被认为达到“最终”阶段
BIP流程都是很复杂且漫长的,往往是多方的博弈的结果,BIP的状态改成“最终实现”将是对提交人最大的奖励
以太坊系统治理
以太坊治理机制角色
以太坊目前采用链下治理机制,由以太坊生态的各个利益相关角色自愿参与,以太坊主网所有的升级都是由以太坊生态的参与者通过链下社群投票表决得到共识的结果
核心开发者
以太坊存储库由核心开发人员团队密切管理,他们拥有向存储库添加或删除代码的流程。以太坊拥有超过22万名开发者,为目前最大的开源社区,而积极更新代码的核心开发者共有近100名,远远超过其他生态
节点运营商及矿工
以太坊的节点运营商及矿工负责运营区块链DAPP的计算网点,所有全节点都包含区块链的完整分布式账本以及运行P2P协议的路由软件。要使代码更改生效,节点需要单独更新其软件使其包含更新的代码
基金会
基金会通常负责为区块链提供指导整体方向和制定发展蓝图。虽然基金会可以影响路线图,但无法执行,执行取决于编写实际代码的核心开发人员
以太坊协议修改流程
以太坊协议进行修改的正式简洁流程如下,概述了以太坊激活协议修改的重要阶段。
以太坊治理中使用的一个重要流程是以太坊改进提议(EIP),EIP指明以太坊潜在新功能或流程的一套标准。以太坊社区内的任何人都可以创建EIP
- 提出核心EIP:正式提议对以太坊进行修改的第一步是在核心EIP进行详细说明。一旦被接受,这将作为协议开发者要执行的EIP正式规范
- 向协议开发者展示EIP:一旦拥有已对其收集社区意见的核心EIP,应该将它展示给协议开发者
- 收到所有利益相关方的反馈意见后,进入最终提议:可能需要更改初始建议,以改善其安全性,更好地满足不同用户的需求。若出现新问题,需要对建议进行另一轮迭代
- 将EIP包含在网络升级中:假定该EIP已经过审批、测试和实施,将被安排作为网络升级的一部分。鉴于网络升级的协调成本很高(每个人都需要同步升级),EIP通常被捆绑在一起升级
- 网络升级激活:网络升级激活后,EIP将在以太坊网络上运行。网络升级通常在测试网上激活后才会在以太坊主网上激活
以太坊DAO分叉
分叉是指需要对网络进行重大技术升级或改变,并改变协议“规则”,以太坊客户端必须更新他们的软件以执行新的分叉规则。区块链分叉是一些利益相关方抗议实施协议更改,导致不同、互不兼容协议版本运行,从而出现两个不同的区块链。
- DAO分叉是为了解决2016 DAO攻击。当时,一份不安全DAO合约导致黑客盗走了超过三百万个ETH。分叉将资金从错误合约转移到新合约,允许在黑客攻击中丢失资金的任何人收回这些资金
- 任何ETH持有人都能够通过在投票平台上交易来进行投票。分叉的决定获得了85%以上的票数。部分社区用户拒绝分叉,主要是认为该DAO事件不是协议缺陷。这部分用户随后成立了以太坊经典
- 面对重大的政治、哲学或经济分歧时能够分叉,这一点对于以太坊的成功治理意义重大
如今以太坊社区已经采取了不干预合约漏洞或资金损失的政策,以保持系统的可信中立性
以太坊治理问题
以太坊链下治理具有弹性高及接触面广的优势,但是同样存在不少争议性及缺失
- 争议导致的硬分叉会造成整个社区的力量被削弱
- 开发者讨论无规定时限,讨论效率低
- 并非所有利益相关者都能公平地参与议案的讨论
- 治理机制趋向寡头政治
- 以太坊生态中少数人对提案的影响力过大。而代币持有者只有在链下表达意见的权力而无实际表决的权力
- 治理架构过于狭隘
- 目前EIP提案大部分由核心开发者及基金会提出,内容主要包含技术的升级及补缺
以太坊2.0可能尝试的方向:一是维持链下治理,将规则清晰化;二是尝试链上治理,确保流程明确透明,增加参与意愿及公平性,并能够快速投票决策
超级账本系统治理
HyperLedger Fabric治理策略
Fabric策略表示成员如何同意或者拒绝网络、通道或者智能合约的变更。策略是Fabric区别于比特币、以太坊相同的特征之一,Fabric策略让对交易验证者是可变的,比如策略可以评估目前是否收集到了足够多的签名来确认某个交易已经达成了共识
策略决定了哪些组织可以访问或者更新Fabric网络,并且提供了强制执行这些决策的机制
- 策略包含有权访问给定资源的组织列表
- 策略指定了需要多少组织同意更新资源的提案
- 一旦策略被写入,会评估交易和提案中的签名,并验证签名是否满足网络治理规则
HyperLedger Fabric治理策略实现
策略实现在Fabric网络的不同层次,每个策略域都管理着网络操作的不同方面
- 系统通道配置策略
- 系统通道配置区块中的策略治理、排序服务使用的共识,并定义新区块如何被创建。
- 系统通道治理着联盟中的哪些成员可以创建新通道
- 应用通道配置策略
- 应用通道策略治理着从通道中添加和删除成员的能力
- 应用通道策略治理着使用Fabric链码生命周期在链码定义和提交到通道前需要哪些组织同意
- 权限控制列表(ACL)
- ACL通过将资源和已有策略相关联的方式提供了资源访问配置的能力
- 智能合约背书策略
- 背书策略指明了需要通道中多少不同组织的成员根据指定智能合约执行和验证交易才能使一笔交易有效
HyperLedger Fabric策略作用域
Fabric策略结构隔离了由不同排序服务组织或者不同联盟成员治理的域
完整的Fabric网络可以由许多不同职能的组织组成,通过支持排序服务创建者建立初始规则和联盟成员的方式,域提供了向不同组织扩展不同优先级和角色的能力。还支持联盟链中的组织创建私有应用通道、治理自己的商业逻辑以及限制网络中数据的访问权限
蚂蚁链平台治理
蚂蚁链治理机制
蚂蚁链在治理模式上支持盟主、大多数、防拜占庭的三种方式,治理流程由链上的治理合约驱动完成
参与治理的用户独立对治理事件做出判断并投出支持票或者反对票,未投票的用户在治理任务超时或者投票人数满足要求的情况下,视作弃权并作废票处理。当投票数满足上述某种治理模式下的阈值后,提议的治理项目将会执行。
蚂蚁链在技术层面提供链上治理能力,通过联盟多方参与和协作完成治理项的决策和执行。在治理策略上采用分布式与集中式相结合的治理思路,适配不同联盟链管理场景,并采用链上治理合约驱动的模式,实现治理客户端的无状态特性,允许随时随地地接入联盟链参与治理任务
蚂蚁链治理角色
蚂蚁链治理角色是对治理参与方的权限进行划分,按照权限共划分为四类,分别是系统管理员、提议者、投票者、参与者
系统管理员
拥有开启和关闭应用合约治理、系统合约治理、平台治理,同时拥有设置治理策略的能力
提议者
拥有治理项提议能力,一种治理项可设置多个提议用户
投票者
拥有治理项的投票能力,一种治理项可设置多个投票用户
参与者
拥有查看治理项的能力,一种治理项可设置多个参与用户
不同角色之间相互依赖和制约,共同维护区块链的健康发展
蚂蚁链治理内容
蚂蚁链治理主要包含链层治理、合约层治理、用户态治理三部分内容。
蚂蚁链的链上治理解决了多方参与的信任问题,通过提议和投票的决策机制,为多方协作提供了更加稳定、规范的治理方式
链层治理
网络治理,即节点的添加、删除、激活、更新等;
系统参数治理,即系统全局参数;
链平台系统程序更新等;
账户的冻结与解冻
合约层治理
合约生命周期的管理,合约升级、冻结、解冻,由BMS中间件提供支持
用户态治理
让合约开发者在业务逻辑里实现对业务全局参数调整功能,提供接口给多个业务参与方投票决策执行
链层节点治理能力
通过治理合约调用NODE系统合约,管理员可以在联盟网络运行过程中动态地进行节点治理
查询节点信息、添加新节点、移除已有节点、激活节点、更新节点等
蚂蚁链动态参数治理
通过治理合约调用CONFIG系统合约,管理员可以在联盟链网络运行过程中动态地调节系统运行参数
调节共识协议、区块生成、P2P通信、平台升级和其他参数调整与功能开关等。
蚂蚁链用户态治理
社区基础库分别开发了各自的治理模块来帮助合约开发者快速搭建一个可社区治理的合约
- OpenZeppelin时间锁治理
- 提供了一个有时间延迟的提案
- HQ20投票治理
- 提供了一人一票或者一token一票的投票治理方式
- DappSys群组治理
- 和投票治理类似,但增加了时间窗口的限制,时间窗口内投票通过数量达到比例则提案通过