以信息化、数字化和智能化为核心特征的第四次工业革命兴起以来，新一轮的全球竞争开始加速，如 何在核心技术上实现安全可控 , 成为各国发展的重要目标。2019 年 10 月 24 日，中共中央政治局就区 块链技术发展现状和趋势进行了第十八次集体学习，会上，习近平总书记强调要把区块链作为核心技 术自主创新的重要突破口。2020 年 4 月 20 日，国家发改委首次将区块链纳入新基建的范畴，各地也 纷纷出台规划扶持区块链产业发展。区块链的重要价值不言而喻。 随着区块链技术的不断发展，基础技术框架逐渐完善，区块链上承载的业务越来越丰富，参与方也越 来越多。为了保证多方协作顺畅进行，解决业务中出现的摩擦，面向区块链技术和业务体系的“治理” 成为焦点。从共识模型看，部分依赖算力或资产权益竞争记账的区块链因马太效应使记账权趋于集中， 打破了多方博弈的均衡，长此以往，区块链公信力将被削弱；从用户角度看，部分区块链参与者丢失 私钥、资产被盗，或因系统漏洞而造成损失，减弱了对平台的信任；从机构参与者看，部分企业级区 块链应用落地时，易因角色权限设置失当 , 或业务运营管理不善而出现系统性风险；从演化策略来看， 以分叉、协议替换为主的升级，因技术成本高、众口难调等原因，不但耗时耗力，还会伴随分歧和争议， 甚至引发社区的分裂。面对上述挑战，既往的治理策略和实践，能否满足区块链技术日后高速发展的 需求，依旧是充满挑战性的难题。 虽然目前区块链治理尚处于早期阶段，但区块链治理机制的建立和不断完善是技术和市场发展的必然 要求。完善且规范的区块链治理需要从政策法律、技术、业务、联盟组织方式等多方面综合维度制定 区块链治理的目标和规范，探索实现框架和应用场景。 作为区块链行业的早期拓荒者和公众联盟链的倡导者，微众银行自 2015 年布局联盟链以来，不断夯 实技术能力，完整构建了从区块链底层平台、中间件到上层应用的一整套技术体系，并全面对外开源， 持续探索区块链技术在产业应用中的实践。基于多年的实践经验和深入思考，微众银行提出面向区块 链的多方协作治理框架Multilateral Collaborative Governance Framework（MCGF），力求厘清 分布式协作者之间的关系，设计规范且易于实施的区块链治理模式，确保分布式商业进程中的公平公 正、可信透明、激励相容和监管合规，从而促进区块链产品、社区和生态的健康、可持续发展。 前言 ( 一 )MCGF 整体框架 1. 治理角色 2. 治理对象 3. 治理机制 ( 二 )MCGF 运行流程 1. 建立元治理体系 2. 实现基础网络治理 3. 执行应用治理 目录 第一章 区块链治理的背景和发展 第二章 区块链治理面临的挑战 第三章 区块链治理框架：MCGF 01 01 04 06 11 05 02 04 05 04 06 ( 一 ) 区块链治理的定义及范围 ( 二 ) 区块链治理的发展历程 ( 一 ) 治理体系的建设需融合跨领域学科理论 ( 二 ) 治理框架需满足技术快速更新的要求 ( 三 ) 治理流程需兼顾参与度与执行效率 ( 四 ) 治理需在更高层面提供法律和规范 07 09 10 12 12 12 ( 一 ) 提案模型 1. 提案结构 2. 提案类型 3. 提案生命周期 4. 提案优先级 5. 提案接口 ( 二 ) 治理工作流 1. 提案发起 2. 提案决策 2.1 提案共识 2.2 提案验证 3. 提案执行 ( 三 ) 治理策略 1. 投票方式 1.1 直接投票 1.2 代议投票 1.3 流动投票 2. 决策规则 2.1 决策条件 2.2 计票规则 第四章 MCGF 治理机制 16 ( 三 )MCGF 技术框架概览 1. 链上治理 2. 链下治理 13 16 22 23 14 14 16 17 18 19 20 22 22 22 23 23 23 24 24 24 25 25 26 3. 执行模式 3.1 手动执行 3.2 自动执行 ( 四 ) 隐私保护 1. 提案隔离 2. 隐匿身份投票 3. 投票内容加密 ( 五 ) 奖惩机制 第五章 MCGF 的应用场景 第六章 未来展望 29 36 29 32 31 34 ( 一 ) 联盟链委员会选举 ( 二 ) 基础参数修改 ( 三 ) 用户私钥重置 ( 四 ) 业务权限管理 26 27 27 27 27 27 28 28 1 第一章 区块链治理的背景和发展 ( 一 ) 区块链治理的定义及范围 作为价值互联网和分布式商业的重要基础设施，区块链天然地存在多方参与、分布式协作的场景，多 个参与者以松耦合的联盟形式组织起来，对联盟内部相关事务进行协商、决策和执行，以实现互利共赢。 然而，联盟模式并不预设参与者之间存在完全的信任，否则也不需要引入区块链。正是由于联盟成员 彼此不完全信任，以及客观上存在利益、观念的差异，他们在达成共识的过程中，难免存在分歧和争论， 所以联盟的成员之间需要通过不断对话、博弈来解决分歧，最终达成一致的共识。基于共识，联盟成 员采用链上链下的治理工具实施管理策略、修改规则、推进业务和区块链系统演化升级，整个过程体 现了高效协同，并保持公开透明，且支持穿透式监管。 综上所述，解决区块链联盟分歧、达成决策共识、推行后续行动、并确保可审计可监管的整个过程， 我们称之为区块链治理。 区块链治理始于信任的痛点，贯穿1）共识的建立2）策略的设计和实施3）系统与规则的维护和升级4） 结果的审计监管5）撤销或升级等完整的过程，体现为一系列的工具、规范、系统以及达成信任的方法论。 2 ( 二 ) 区块链治理的发展历程 回顾过往 10 余年的区块链历史，我们可以看到区块链治理从以链下实施为主，往链上链下结合的方 向逐步演化。 在区块链萌芽阶段，治理的实践在链下进行，参与者采用邮件、论坛、社交网络等方式对提案进行充 分探讨，开发者根据讨论结果更新和发布代码到代码仓库中，最后由维护者分别将代码更新到节点， 并确保新版本得到执行。比特币的 BIP 1 是最早的链下治理模式，往后的区块链项目，在比特币治理模 式的基础上结合自身社区实际情况进行一定优化改进，例如以太坊的 EIP 2 ，提交草案门槛更低，批准 流程更加精简，治理变得更加高效和快捷。 从实践成效来看，链下治理多次以主链的硬分叉作为结果。所谓的硬分叉是指当区块链新旧协议无法 兼容，导致原有的系统难以为继，或参与者之间的分歧最终无法解决，迫使各自维护不同的区块链协 议的版本，社区最终“分而治之”。比特币和以太坊等社区均发生过硬分叉，分叉的不仅仅是网络系统， 其上的经济体系、参与者均分道扬镳。硬分叉一方面可以决绝地处理难以调和的矛盾，使突破性创新 得以异军突起，为区块链社区带来新的活力；另一方面，在可持续性以及平滑演进方面，会出现不可 避免的动荡。 总之，既往链下治理的不同参与者的权利和义务并不明确，任何治理角色都没有最终决定权。治理角 1 2 广义的治理事务包罗万象，只要是涉及到具有多方协作、对等透明、支持监管的诉求，均可以被纳入 到区块链治理框架中，囊括了治理本身的规则、区块链底层网络和上层业务等多种维度。例如，如何 有效地发布和升级区块链节点的补丁？参与者如何被许可加入到联盟链中？如何决定治理者名单并分 配何种权限？在区块链具体应用中，如何重置和找回参与者的私钥等。 完善且规范的区块链治理有助于发挥参与者的集体智慧，做出有益于联盟发展的决策，保证联盟决议 的合理性、合法性，推进区块链产业和生态持续、稳定和健康地进步。 3 透明治理。决策的过程和结果都在链上，透明且不可篡改，执行过程和结果可追溯可审计； 高效进化。所有决策经过多方共识，全网即时生效，系统可以快速自我迭代； 避免硬分叉。治理提案以代码方式在链上存储，所做修改兼容原有数据，无需开辟新网络、新系统， 从技术上避免了硬分叉。 参与度更广。任何治理参与者都可以根据持有权益或资源参与到治理过程中来，避免了因最终 决定权在于项目的核心开发者而导致中心化问题。 链上治理可更高效地协调所有利益相关者，通过协议的形式推进决策和升级系统。现有链上治理的实 践各具特色，例如通过引入资源抵押来规避治理投机的风险；引入自适应偏向性调整、二次方投票等 机制来提升决策的效率和公平；采用链上隐匿投票，既可以保护投票者的个人隐私，还可以提升投票 的质量和参与率等。总之，链上治理模式是一种完全依赖区块链网络的治理模式，相对于链下治理， 操作上无需人工重度介入，决策高效稳定，同时支持热更新。实际上，由于治理的复杂性，完全排除 链下参与的纯粹“链上治理”依旧是理想化的模型。 倘若要实现综合治理的目标和工程，则可行的治理模型，宜更多地体现为链上链下结合的混合型治理。 链下治理的侧重点在于“讨论”，适合开放性的、需反复验证、审慎推进的场景，如新功能的引入； 链上治理则更强调“执行”，适合相对结构化的、标准化、高效落地的场景，如参数调整、上层业务 治理。将两种方式结合起来实现“综合治理”，有助于取长补短，丰富治理的手段，强化治理的效果。 色通过链下方式进行协商博弈并达成共识，这也使得决策过程相对迟缓，且无法保证提案一定会被执 行。在实施阶段，则很大程度上依赖人工介入。 随着区块链基础网络的完善，尤其是功能强大的智能合约出现后，部分区块链项目开始尝试将治理从 链下往链上迁移，以期实现以链治链的目的。链上治理指结合链上状态和参与者的意图，生成链上提案， 由参与者基于链上机制达成共识，并在全网范围自动执行提案。在混合模型中，所引入的链上治理部 分具有诸多亮点： 4 迄今为止，区块链的治理已进行过多种形式的实 践，积累了宝贵经验和教训 , 但要达成完备的治 理目标依旧有不少挑战。 ( 一 ) 治理体系的建设需融合跨 领域学科理论 除了技术领域之外，区块链治理还涉及社会学、 经济学、政治学、博弈论等多种跨领域学科理论。 同时，为了兼顾多方利益、兼容各种场景，区块 链治理框架设计难度较高。 1) 从经济学角度来讲，区块链治理容易陷入“公 地悲剧”的陷阱。每个参与者出于自身利益最大 化而行动，最终可能损害集体利益。 2)从社会学角度来讲，区块链治理过程中可能 出现“马太效应”。相比头部参与者而言，中小 参与者的组织一般较为松散，可能会出现“强者 越强、弱者越弱”的现象。 3)从博弈论角度来讲，也存在一个经典的“头 羊效应”。参与者可能会轻信联盟中的意见领袖， 而缺乏独立的思考能力。 优秀的区块链治理框架设计需要融合上述多学科 知识，规避障碍和陷阱，并在实践中不断迭代探 索和完善。 ( 二 ) 治理框架需满足技术快速 更新的要求 区块链本身正处于高速发展阶段。快速发展的技 术有利于生态体系的进化，同时也带来了“给快 速行进的汽车换轮子”的挑战。 1)区块链各类技术、平台、标准和新的概念不 断涌现，其复杂性和深度性构成了较高的门槛和 陡峭的学习曲线，从而对参与治理的角色及治理 规则的设计要求更高。 2)区块链治理的发展是一个动态的过程，僵化 的治理机制难以应对社区随时间推移产生的各种 变化。治理框架的核心是能够对现有问题进行治 理，但更需要随着系统、社会等因素的变化，对 治理机制、治理参与者、治理策略及治理对象进 行动态更新。 第二章 区块链治理面临的挑战 5 作为一种知识密集型、复合型技术，区块链技术 本身已经相当复杂。加上区块链治理，须基于不 同的治理诉求，需要融合多种技术，比如隐私保 护等，这进一步加剧了技术密度和提高了技术门 槛。 ( 三 ) 治理流程需兼顾参与度与 执行效率 区块链治理涉及多方协作，相比中心化治理体系， 需要更多的治理主体参与其中，会消耗更多时间 进行讨论和博弈。考虑到治理提案的重要性和紧 急性，治理流程需兼顾参与度和执行效率。 对所有参与者而言，参与到区块链治理当中，需 要付出学习成本、时间成本、决策成本等。参与 者需要熟悉错综复杂的治理规则和随时新增的提 案内容，需要适应可能变化的流程规则等。此外， 参与者还需要付出一定的资源，以收集信息、展 开分析，并做出决策。 在现有的区块链治理实践中，为了提升参与度， 普遍的做法是，延长提案讨论、决策和投票的时 间期限。但这样容易导致投票流程冗长、决策低 效等问题，特别在处理一些紧急提案时存在不及 时的瓶颈。另一方面，高门槛的治理机制对于用 户，尤其是普通用户而言，并不友好，以致参与 度不是很高。这种种因素不仅导致决策达成共识 的周期变长，更有甚者，致使治理变成了少数参 与者的事情，联盟共识徒有虚名，实际只是头部 参与者的共识。 ( 四 ) 治理需在更高层面提供法 律和规范 任何技术，一旦走入了千家万户，产生了广泛的 影响力，就必须满足合法合规的要求。区块链技 术已经产生了巨大的技术影响力，其治理亟需法 律和规范的支撑，且须确保相关规范灵活长效、 监管友好。 1)区块链治理需积极拥抱监管，针对敏感数据 和高风险交易，为监管提供审计、终止、撤回和 删除等管理能力。区块链领域在合规表现上，经 多方努力已经有所进步，但客观上仍需尽责践行， 杜绝监管漏洞和风险。 2)法律和规范的制定需要通过社会协同与公众 参与来共同实现，一方面明确底线，另一方面确 保相关规范的灵活性和长效性，兼顾创新性和稳 定性。 综上所述，虽然区块链治理尚处于起步阶段，且 面临着多个复杂的难题和艰巨的挑战。但作为区 块链顶层设计的一部分，区块链治理的设计和建 设，有助于提升区块链技术正向演进、业务稳定 落地和生态健康发展，具有极为深远的意义和非 凡的价值。 6 第三章 区块链治理框架：MCGF 结合现有区块链的治理方式和行业挑战，融合 多种学科和技术，我们提出了面向区块链的多 方 协 作 治 理 框 架：Multilateral Collaborative Governance Framework ( 以下简称 MCGF)，旨 在降低区块链治理参与者的学习、开发和使用门 槛及成本，使得区块链治理机制可随时间及技术 的变迁而升级优化，并确保治理过程的安全可控、 权责清晰、隐私保护和奖罚分明。 需要指出的是，MCGF 并非是一个具体的产品或 基于某个平台的具体实现，而是一种参考框架， 任何企业或组织都可以基于MCGF框架，针对 特定场景，选择合适的技术方案，实现自己的治 理产品和治理能力。 此外，MCGF 聚焦联盟链领域，基于联盟链委员 会选举、准入机制、身份验证、监管友好等关键 特性，提供了相关的参考实现和标准化的组件， 实现运行高效、安全可控、可信可追溯的治理。 ( 一 )MCGF 整体框架 MCGF 整体框架由治理角色、治理对象和治理机 制三部分组成，如下图所示。 7 图 1：MCGF 治理框架图 1. 治理角色 角色的意义在于定义一类用户所具备的权限和职责。为了明确区块链治理分工边界、实现均衡治理， MCGF 采用 RBAC（Role-Based Access Control ）模型，按照参与方式、职能等维度将治理参与者划 分为5类： 普通用户、管理者、监管者、开发者、运维者 。不同角色之间相互依赖和制约，共同维护 区块链的健康发展，如下图所示。 图 2：治理角色图 8 普通用户 普通用户是区块链网络最基础的参与者和使用者，也是区块链的最大利益相关方，在联盟链中多为业 务的使用者。如何保护最广大用户的权益，以及保障用户对业务和治理的参与权，是构建区块链可持 续发展生态的根本。 管理者 管理者主要负责对区块链相关资源的运营和调度，比如治理委员会、理事会等参与者，是联盟链治理 的主要决策者与资源的调度者。 监管者 监管者负责对区块链进行监督管理。比如监管者以观察节点的身份加入联盟，对数据录入的准确性、 及时性、可信性进行审计，对智能合约、区块链设置等合规性进行审计，对区块链可能受到本地攻击 和系统范围攻击的安全性进行审计等。 开发者 开发者负责区块链网络的升级维护、漏洞修复、代码迭代更新等。 运维者 运维者通常为链上参与节点的网络与设备等资源的维护者，也可以是由联盟共同指定的第三方专业运 维机构。 9 基础网络治理 基础网络治理指的是对区块链网络的治理，包括 节点的准入、记账节点的选举、节点参数的调整、 共识机制的升级、智能合约部署等。 区块链的发展和运维，直接取决于基础网络治理。 监管者负责监督管理链的运行，确保区块链的运 营遵守法律，符合各项行政和行业规范，确保社 会公众的利益。 元治理 元治理指对治理协议本身的治理，包括提案模型、 治理流程、治理策略、联盟链委员会选举等，是 一切治理的源头。 元治理相当于治理的“基本法”，可以称之为治 理的治理。参与者基于“元治理”在初始期规划 区块链生态未来的发展道路，也能够对生态中不 合规的参与者采取相应措施。 图 3：MCGF 治理对象 2. 治理对象 在 MCGF 框架中，按照区块链治理对象从底层到具体业务的维度来进行划分，治理对象主要包括 元治 理、基础网络治理和应用治理 。在治理过程中，治理对象的变动必须具备可回滚性和可撤销性，能够 对监管意见进行整改。如下图所示。 10 一个提案可能需要经过一到多轮的投票决策，每 轮决策的参与者不同、决策机制不同、失效条件 不同。治理工作流提供配置化的流程管理能力， 确保提案的生命周期按照既定的流程推进。 治理策略 治理策略是治理的方法，厘清了治理的规则。对 于治理提案而言，一般每一轮决策都需要进行治 理策略的配置。在治理策略中包括投票方式、决 策规则和执行模式。 隐私保护 为了确保治理过程的公平公正及用户隐私， MCGF 框架针对参与人、提案、投票内容等信息 采用密码学方式进行加密保护，防止绑架投票、 选票舞弊等情况出现。 奖惩机制 为了维护区块链网络的正常运行、升级等，可通 过合理合规的方式激励作为回报；为防止恶意治 理，比如恶意提案、治理不作为等行为，需针对 作恶角色进行惩罚。奖惩机制可以从权责、资源 和信用等方面实施。 应用治理 应用治理指的是对基于区块链网络的上层应用治 理，包括业务治理委员会选举、接口调用权限管 理、应用参数调整、应用版本更新和应用生命周 期管理等。 应用治理一般独立于区块链的元治理和基础网络 治理，属于分布式应用管理的关键一环。 3. 治理机制 治理机制是治理的核心，连接治理角色和治理对 象。在区块链治理中，不同的治理角色可以针对 不同的治理对象采用不同的治理机制，参与到区 块链治理过程中。治理机制包括提案模型、治理 工作流、治理策略、隐私保护和奖惩机制。 提案模型 提案模型是主体，决定了治理提案的内容和细节。 治理活动在创建时会被描述为一个治理提案，治 理的过程围绕治理提案展开。提案模型包括了治 理活动的提案内容等静态要素，也包括决策等动 态状态。 治理工作流 治理工作流描述了治理的过程，决定了治理参与 者的范围和推进的节奏。在区块链治理过程中， 11 ( 二 )MCGF 运行流程 作为一个通用化的治理框架，MCGF 提出了灵活、可配置的治理运行流程，保证治理对象完整覆盖、 治理参与角色职责明确和治理机制的安全可控。在 MCGF 运行流程中，治理对象是目标，治理角色是 主体，治理机制是核心。 对于任何对象的治理，都会遵循治理机制。治理实施之前，首先需要对治理规则进行初始化，包括投票、 决策和执行规则的设定。治理规则的设定独立于任何一个具体的提案 , 以规章文件形式记录在链下或 以代码的形式部署在链上，供后续的提案发起时引用。提案发起阶段，由提案发起人对提案的治理工 作流进行配置，包括提案的投票角色、投票方式、决策规则、隐私保护策略、奖惩机制及执行模式等。 随后进入决策过程，决策过程按照治理工作流配置，由一到多轮投票构成，每一轮投票都有不同的参 与者按不同的投票方式投票，投票通过与否由决策规则决定。如果最后投票通过，就会进入执行阶段。 整个提案过程都受到隐私机制、奖惩机制的保护和约束，保证了治理环节的质量。 图 4：MCGF 治理框架运行流程图 12 1. 建立元治理体系 对于元治理而言，在区块链网络建立和运营前，所有参与者需要在线下进行协商，以创建并认同元治 理的规则。在区块链治理的启动阶段，所有治理规则需遵循初始约定的元治理规则。对元治理规则本 身的修改也需要遵循元治理的规则来进行。元治理一般由所有联盟成员共同参与投票决策，并由监管 者负责对提案的草案阶段和最终结果阶段实施监管操作，确保元治理的权威性。 2. 实现基础网络治理 基础网络治理依据的规则是元治理中所产生的成果，一般会先由联盟成员共同发起，按元治理的模型 和流程进行讨论，得出临时性结论，再由联盟委员会决议是否通过，如批准谁能加入网络、如何修订 某个参数值等，再赋予运维人员相应的权限进行实施。联盟委员会由管理者、监管者、开发者及运维 者共同构成，当联盟成员任意一方不按照规则行事，损害联盟利益，联盟委员会成员即可发起提案， 对原有成员进行相应惩罚。 3. 执行应用治理 对于应用治理而言，业务运营者或业务委员会可以通过编写智能合约来定义自身业务应用的治理规则， 并由其他参与方和联盟委员会进行审核，联盟委员会具有一定的把控力和必要时的一票否决权。对于 存在较大风险的业务场景，联盟委员会可以行使监管权力，采取冻结账户、冻结合约等强制措施，维 护公众利益。普通用户作为最终的服务使用者，具有监督和投票权利。当业务运行违背大众意愿时， 可发起提案提交联盟委员会，对业务委员会（业务运维者）进行惩罚，并重新发起业务委员会的成员 选举。 综上所述，在纷繁复杂的区块链治理相关事务中，MCGF治理框架旨在帮助分布式协作者厘清治理角色、 把握治理对象、优化治理机制，在实践中探索、总结出一套适合自身组织或联盟的最佳运行流程。 13 ( 三 )MCGF 技术框架概览 作为区块链治理的参考架构，MCGF抽象了区块链治理的设计规范、功能模块、参与角色及应用场景等， 可适配多种异构区块链底层网络，支持整合链上治理和链下治理的各类工具、组件和系统等来提供完 整的易于操作、可视化管理的区块链治理能力，其核心模块分为链上治理和链下治理。 此外，整个治理依赖于链上 / 链下治理模块。对于规则初始化阶段，治理模块保存治理规章信息；提 案发起过程当中，治理模块用于保存提案自身信息；在提案决策当中，基础设施保存投票信息；最后 执行阶段，治理模块用于体现执行结果，执行在链上发生。不同阶段允许采用不同的治理模块，如下 图所示。 图 5：MCGF 技术架构图 14 1. 链上治理 MCGF支持治理角色直接以区块链系统作为入 口，依托智能合约和区块链底层节点的扩展功能 模块来实现，通过RPC、SDK或跨链服务等方 式参与区块链系统的治理，称之为链上治理。 链上治理模块包含了链上治理接入、智能合约库、 治理组件等子模块。 基于多方参与、分布式账本和防篡改的特性，区 块链天然就适合作为治理的基础设施，即“以链 治链”。 相比链下系统，一方面，链上系统需要预先以可 执行代码的形式指定各个环节的时间节点和决策 标准，治理流程更加透明、有序，采用链上治理 的决策可即时全网生效，全局一致，所有治理对 象、流程和决策细节均在链上发生并留痕、记录 不可篡改，公开且可信。 另一方面，提案落地执行可基于底层指令或智能 合约实现，使得整个治理流程一体化、投票原子 化，提案决策通过后，执行可不依赖人工介入， 从而达到效率和信任兼具的效果。同时链上治理 还有助于提升治理的参与度，进一步提升投票和 决策的客观性和公平性。 不过，由于区块链的分布式账本、不可篡改等特 性及代码的开放性，一旦治理规则确定 , 系统将 “铁面”执行，难以抗拒。另外，治理的运行逻 辑对所有人都可见，任何已知的安全漏洞都可能 被利用。因此，链上治理在设计上应更加审慎， 同时需要确保在投票模型、策略及治理逻辑本身 具有可扩展性。 2. 链下治理 除依托区块链网络的链上治理模式，MCGF 也支 持通过开源软件、社交网络和专用的链下系统来 实现链下治理。治理角色以链下系统作为入口， 通过Web、App及API等方式参与区块链系统 的治理，称之为链下治理。如采用GitHub、专 用系统等接入。链下治理的接入方式和互联网的 接入方式一致，接入门槛和成本相对较低。 链下治理模块包括了社交网络、开源软件、治理 系统等子模块。 社交网络 区块链治理的核心成员通过社交网络工具进行沟 通和分享，提出问题、发表评论、进行讨论，最 终达成共识。社交网络的优点是形式自由、灵活， 可随时发起。缺点是治理参与的范围限于特定社 交圈子内，管理较为粗放，存在各种不确定性。 15 开源软件 通过 GitHub 等开源软件，发起提案、对提案进 行讨论修订并最终达成共识。治理参与者可在开 源软件上进行分享和讨论，提出草案，也可以对 软件系统的代码进行修改。例如，治理参与者可 以使用提案模板创建提案，然后发起推送请求 （pull request），提出一个草案申请。草案经 开源社区审核，通过后就会被合并到提案库中， 供参与者讨论。开源软件的优点是搭建成本较低， 对开发者群体较为友好；缺点是比较极客范，普 通用户参与度较低，区块链的发展可能被小部分 群体所掌控，存在中心化风险等。 治理系统 提供一个专有的、独立的提案和投票的治理系统， 供参与者发布提案，分享意见和参与者投票及决 策，包括政策决定、争议解决等，有助于相关参 与者提交、跟踪和讨论的治理建议。治理系统还 可以为治理团队提供提案的初步审核机制，以便 过滤一些垃圾提案，提升治理的效率。治理系统 的优势是体验友好，便于浏览、投票，适应个性 化治理的需求；缺点是需要重新开发，成本较高。 为了便于落地，MCGF 总结常见的场景，提供了 开箱即用的标准化组件。在链上，包括治理委员 会管理、业务账户治理和合约权限管理等组件； 在链下，包括与开源软件社区、社交网络、专用 链外系统对接的接口和 SDK。MCGF 对各模块牵 涉的智能合约、接口、SDK都进行了友好的封 装实现，提供样例模板、可执行的工具和 DEMO 等参考实现，方案和代码均开源开放，可一键式 安装配置和运行，以更好地分享MCGF的治理 理念和经验，促进场景化的落地。 图 6： 区块链治理平台 16 第四章 MCGF 治理机制 作为通用化的参考框架，MCGF 治理机制从提案模型、治理工作流、治理策略、隐私保护和奖惩机制 等五个方面进行分析和设计，确保 MCGF 治理机制的开放、灵活、可扩展。 ( 一 ) 提案模型 在 MCGF 框架中，所有的治理事务都基于提案模型，治理者的操作其实是对提案的操作。提案描述 了区块链网络平台的标准，包括核心协议规范、客户端 API、合约标准标准及业务规范。相比 BIP 和 EIP，MCGF 框架中的提案模型不仅包含元治理、基础网络治理和上层业务治理，而且兼顾了链上和 链下两种提案模型，提案不仅可以是一系列改进建议的文件，也可以是一段可执行的代码片段。 1. 提案结构 提案结构如下图所示，包括提案头（Header）和提案体（Body）。 图 7： 提案模型结构 17 提案头用于描述提案的概要信息，包括提案编号、提案名称、提案发起者、提案类型、提案状态、提 案发起时间及扩展项等，不涉及提案的具体内容。其中可扩展项作为可选项，可以添加提案的其他概 要信息，比如关联提案、父提案、讨论地址及其他自定义内容等。 提案体用于描述提案的具体内容，包括提案摘要、提案内容、提案条件、治理工作流定义和扩展项。 其中提案摘要用于简单描述提案内容；提案内容为提案的具体描述或实现，可以是一个文档，也可 以是具体的代码文件或者代码访问地址；为了防止垃圾提案，治理参与者在提出提案前自身需要满足 一定的条件，比如具有某个特定权限，或进行了特定资产的抵押和花费；为了治理能力的可扩展性， MCGF 将提案和实施动作分离，一个具体的提案可由具体的治理参与者配置不同的治理工作流对提案 进行管理和操作。可扩展项作为可选项，用于描述提案内容的其他信息，比如测试用例、规范、原理 阐述及其他自定义内容等。 2. 提案类型 在 MCGF 框架中，提案模型按照不同的治理对象划分为三个大类：元提案、基础网络提案、上层应用 提案。 元提案：元提案用于治理框架本身的治理。随着业务、技术和社区的发展，单一僵化的治理方式 无法满足生态对治理的诉求，所以治理框架本身也需要治理，包括提案模型升级、治理策略变更、 治理委员会选举等； 基础网络提案：描述影响区块链基础网络实现的任何更新，如区块链网络协议升级、系统参数调整、 系统漏洞修复和合约部署权限管理等； 上层应用提案：上层应用提案用于对复杂的业务场景进行描述，上层应用提案的生命周期由具体 的业务参与者管理，上层应用提案不会对基础网络造成任何影响。比如业务治理委员会选举、智 能合约接口权限管理、账户冻结、私钥重置等。 18 3. 提案生命周期 出于对安全、时效、权益分配等因素的考虑，MCGF 框架参考了主流区块链治理提案模型及 RFC 1 和 W3C 流程 2 ，提取了提案模型生命周期所必须的核心状态，确保提案的正确、高效流转和执行。 在 MCGF 框架中，提案包括发起、审核、候选、决策、核准、执行、驳回、撤销等 8 个状态。提案生 命周期如下图所示。 提案发起：任何一个提案都是从发起状态开始，链下治理可以理解为草案阶段，链上为一个正式提案。 提案审核：为确保治理的效率、安全、合规，提案在发起之后需要进行审核。审核阶段主要由治理委 员会、核心开发者或监管对提案进行审核。需要注意的是，对于一些非常标准化的链上提案并不一定 需要审核，所以提案审核为可选状态。 提案候选：完成审核之后，治理者会对提案进行操作 , 将提案状态变更为候选状态，此时提案按照既 定设置进入治理工作流。 1rfc-editor/rfc-index.html 2w3/TR/ 图 8： 提案生命周期 19 提案决策：在治理工作流中，一个提案可能需要 经过多轮决策之后 , 才能进入核准状态，在决策 阶段，主要不同的治理参与者通过投票的方式决 定提案是否通过。 提案核准：当提案经过决策并通过之后，提案进 入核准状态。当进入核准状态之后，表示提案已 经没有问题，无需再次修改和商议。 提案执行 ：只有进入核准状态的提案才能被执 行。不同的提案会由不同的治理参与者执行。提 案的执行可分为自动执行和手动执行。 提案驳回：任何提案在未核准前，都可以由相应 环节的治理参与者驳回，驳回的提案经过修订之 后，仍可以提交进入到相关流程。考虑到时效性， 被驳回的提案在经过一段时间（可配置）后未被 重新提交，则自动结束流程。 提案撤销：任何提案在未核准前，都可以由提案 发起者撤销，撤销之后的提案自动结束提案流程。 4. 提案优先级 基于提案的影响范围、紧急程度等因素的考虑， 每一个提案都具有不同的优先级。在 MCGF 框架 中，提案按照优先级被划分为4类，如下表所示。 考虑到不同社区平台的自身技术、业务等不同， MCGF 框架仅给出提案优先级分类和参考建议， 具体提案归属类别可由社区、平台灵活定义。 提案级别 优先级 描述 参考建议 一级提案 最高 对区块链网络或上层应用产生重大影响， 提案问题会导致社区、产品在较短时间内 崩溃或瓦解 系统漏洞、应用漏洞或管理权限 漏洞等 二级提案 较高 对区块链网络或上层应用不会产生重大影 响，但短期内会对部分用户和业务造成重 大影响 私钥丢失、账户被盗等 三级提案 中等 对区块链网络或上层应用短期内不会产生 重大影响，但长期看必然影响整个社区或 平台的发展 协议升级、参数调整等 四级提案 较低 对区块链网络或上层应用短期内不会产生 重大影响 文档、规范等修订 表 1：提案优先级列表 20 针对同一级别的提案，按照不同提案条件（例如资源的质押）并随时间的推移、参与度的变化，其优 先级也会产生不同的变化。在 MCGF 框架中，同一级别的提案会按照提案条件、时间、参与度三个维 度对同一级别的提案进行优先级计算排序，其中，优先级和资源多少及参与度成正比，和时间成反比。 例如，提案发起者可以在发起提案时设置提案权重，权重值与提案发起者付出或抵押的资源正相关， 权重越高的提案优先级越高；参与者讨论或投票越多的提案，其对应的优先级也越高；新提出的提案， 优先级高于存量提案。 5. 提案接口 MCGF 提出了一套规范的接口协议和标准，从提案的发起到提案的决策，再到执行，拥有完整的协议 和标准来确保提案的准确性、平台一致性和通用性。核心接口如下所示。 功能说明 接口 返回值 发起提案 submit（Proposal p） String：提案唯一标识 检查提案 check（String pId） boolean：检查是否通过 投票 vote（String pId，Option op） boolean：投票是否成功 执行提案 execute（String pId） boolean：执行是否成功 根据条件查询提案 query（Condition condition） Proposals：返回查询提案 撤回提案 revoke（String pId） boolean：撤回是否成功 表 2：通用化接口列表 21 提案发起 : 原则上任何治理参与角色都可以发起提案，提案的发起可以通过论坛或者治理系统完成， 也可以通过链上提案接口发起。 提案检查：提案检查的目的是确保提案的格式正确、内容合法合规，同时防止垃圾提案。一般在提案 提出后，由治理委员会或者社区管理者对提案进行检查。 提案投票：一个提案在提交后，需要有决策参与者来进行投票，投票接口提供投票意见选项。投票策 略包含二元投票和多元投票两种，通过接口中的 option 字段设置。提案投票完成后会按照投票结果 进行提案的决策，决定提案是否通过本轮投票。 提案执行：提案在决策通过后，需要自动或手动来执行，执行者由提案来指定。同时，需根据提案的 详情来执行对应的方案。 提案查询：提案在提交后，需要提供查询的接口，包括提案的列表和详情查询等，以供相关方查阅决策。 提案撤回：提案在提交后，可能存在需要修改的情况，故需提供提案的撤回接口，由提案的发起者来 调用撤回，完成提案的撤回。 ( 二 ) 治理工作流 MCGF基于以往的治理经验，提出了一种灵活可定制的治理工作流，用户可根据自己的实际需要对 某些环节进行定制、增减。治理通过治理工作流（Govern Flow）来进行，由提案发起(Proposal Initiate)、提案决策 (Proposal Decide)、提案执行 (Proposal Execute) 构成，其中提案决策又由一到 多轮的提案共识 (Proposal Consensus) 以及提案验证（Proposal Verify）构成，如下图所示。 22 1 提案发起 无论是链下治理，还是链上治理，提案的最基本要求是完整、自洽且清晰。就链下治理而言，要包含 谁发起了投票、解决的问题是什么、解决的方案是什么、接口规范是什么、参考实现在哪里等。就链 上而言，要包括提案的名称是什么、谁发起的、类别是什么、可投选项有哪些、资源模型、投票周期 是什么等。此外，为了保证提案的质量，MCGF 还支持提案审核、提案撤回、资源质押等机制。 2 提案决策 提案决策是指社区成员对提案取得共识的过程。提案决策至少包含一轮提案共识，外加提案验证。 2.1 提案共识 一个提案通常需要不同的治理角色成员进行多轮投票共识。在每一轮提案共识中，会由一组特定成员 进行投票，投票通过后会进入下一轮，如果未通过，则提案失效。MCGF 支持使用者定制多轮投票， 对于每一轮投票，可为其指定投票成员范围与权重、投票通过条件、下一轮投票、失败策略等。 图 9： MCGF 治理工作流图 23 2.2 提案验证 在提案通过决策后，为确保提案内容能够正确执行，需要在验证环境进行验证，主要是针对链下发起 的提案。例如，一个代码升级提案在审核通过后，要去测试环境中进行验证，在测试环境运行一段时间， 确保无误后，才会最终在生产环境上进行落地。 3 提案执行 提案在确认无误后进行最终的落地。MCG