区块链和分布式记账技术 治理指南 征求意见稿

1GB/ZXXXXX—XXXX区块链和分布式记账技术治理指南本文件给出了分布式记账技术系统的治理指导原则和框架。本文件适用于指导分布式记账技术系统的风险、监管环境等相关治理，以实现有效、高效、规范的分布式记账技术系统应用。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO22739，Blockchainanddistributedledgertechnologies-Vocabulary3术语和定义3.1分布式记账技术治理，distributedledgertechnologygovernanceDLT治理，DLTgovernance指导和控制分布式记账技术系统，包括账本内和账本外决策权分配、激励、责任和职责，确保分布式记账技术的应用合规、风险可控和价值实现。3.2治理实体，governingbody对分布式记账技术治理的性能和一致性、合规性负责的实体。4缩略语下列缩略语适应于本文件。DApp：去中心化应用（DecentralizedApplications）DLT：分布式记账技术（DistributedLedgerTechnologies）KYC：了解你的客户（KnowYourCustomer）5治理原则5.1概述2GB/ZXXXXX—XXXX本章节规定了九项面向DLT系统治理的行动原则，后续文件会更详细地阐述。这些原则帮助利益相关方评估和改进治理机制、结构和活动，并实治理目标,即：有效、高效和规范地使用DLT系统。同时也实现了对利益相关方在治理框架内履行职责的正确激励。DLT系统的治理宜包括在其建立、运营和终止过程中致力于解决可持续性问题。注：关于可持续性问题的有用信息源自《ISO26000社会责任》和《联合国可持续发展目标(治理原则为DLT系统的机制、结构和活动的实施提供了基础。每项原则表述其重要性和必要性，但没有规定这些行动应当如何、何时或由谁实施，这取决于DLT系统的性质。5.2原则5.2.1原则1：定义实体参与方的标识符不同DLT系统的参与方标识符可能会有所不同。某些DLT系统使用化名作为账本内的标识符，而另一些则使用账本外的标识符来提供可信度。定义适用于DLT系统的标识符是所有治理功能的基础。5.2.2原则2：实现去中心化决策去中心化决策是DLT系统的一个关键特征。DLT系统的决策可以分为账本内和账本外。去中心化系统促进了集体决策，增强了整体的信任。DLT系统宜支持去中心化的账本内决策流程；当决策在账本外做出时，宜以明确、正式的形式做出。5.2.3原则3：明确问责机制在DLT系统的生命周期中，所有权和决策权会发生变化，因此问责机制也会产生变化。鉴于大部分DLT系统去中心化的性质，需要建立明确的问责机制来执行规则。在适当情况下，账本内宜强制执行问责机制，账本外宜强制或补充执行问责机制。5.2.4原则4：公开透明在DLT系统生命周期中涉及的操作、决策和运营宜对各利益相关方公开透明。DLT系统宜构建允许利益相关方查看和审计系统动态的机制。5.2.5原则5：激励机制与系统治理目标一致DLT系统的激励机制推动决策者之间达成共识，解决冲突，并就持续治理、设计和运营做出决策。DLT系统的激励机制在驱动用户和其他利益相关群体的理想行为方面发挥着关键作用。宜明确设计支持系统治理目标的激励机制。5.2.6原则6：性能和可扩展性如果没有提供性能保障，系统的敏捷性和可维护性将受到影响。DLT系统宜在生命周期内提供满足性能和可扩展性需求的机制。DLT系统在使用时，宜保障系统性能，并具有有效性、高效性、可扩展性。5.2.7原则7：基于风险的决策及合规义务履行DLT系统的生命周期可能存在特定风险，如司法管辖权争议。在决策过程中，宜适当评估和处理这些风险。宜制定促使DLT系统自我合规规则，以降低违规风险。5.2.8原则8：保证安全和隐私DLT系统的安全性包括机密性、完整性和可用性，宜提供适当的安全机制。DLT系统宜考虑隐私的3GB/ZXXXXX—XXXX影响，并实现隐私保护。DLT系统宜根据任务或流程，处理安全和隐私的相关要求。5.2.9原则9：满足互操作性要求当DLT系统需要与其他系统交互时，宜在系统整个生命周期中（尤其是设计阶段）考虑互操作性。DLT系统架构宜提供互操作机制，宜支持同构或异构的DLT系统和非DLT系统。6DLT系统治理框架6.1概述本章节描述了DLT系统的治理框架。治理框架包含了与DLT治理相关的决策权、问责机制和激励。本章节还讨论了IT系统治理与DLT系统治理之间的区别。6.2与其他治理框架的比较以ISO/IEC38500、ISO/IEC/TR38502为例，传统IT治理主要为中心化治理。传统IT治理通常包括组织内有效、高效、规范地使用IT系统，并负责评估计划和提案、指导政策和战略，以及监控与IT相关的性能和合规性。一个组织不局限于公司、企业或政府机构，但需要拥有明确定义和被权威机构认证。治理机构的范围和权力边界通常在章程、许可文件、法律等中有所记载。与组织约束相关的IT治理的影响贯穿于现有治理框架的元素和假设之中。这通常反映在传统IT治理框架中，具体包括定义和确保IT战略和业务计划的实施，组织管理和董事会的问责，组织风险的管理和其相关控制措施。DLT系统与一般的IT系统不同，因为它们涉及分布式计算并且是去中心化系统，其中系统的不同节点通常由不同的组织或个人控制。在治理背景中，只有组织和个人被认为是问责实体。DLT系统可以跨越组织和司法管辖边界，从而其治理跨越了多个组织或个人，这超出了ISO/IEC38500和ISO/IEC/TR38502等国际标准的治理方法范畴。DLT系统相关的组织和个人之间的关系至关重要。同时，DLT系统的治理框架需要解决一系列关键问题，包括：a)DLT系统有哪些不同类型，它们如何影响治理规则的制定和执行？b)在DLT系统生命周期中，治理机构的变化如何影响不同的DLT治理？c)存在哪些利益相关方角色，它们如何影响DLT系统治理？d)如何将风险、问责机制和合规性考虑嵌入不同类型的DLT系统中?e)如何实现DLT系统之间以及DLT系统与非DLT系统之间的互操作性，及其需要考虑的治理事项是什么？为了实现对决策权、问责机制和激励的有效治理，DLT系统治理宜涵盖多利益相关方、分布式治理，并反映DLT系统的去中心化特性。6.3DLT系统治理的考虑事项ISO/IEC38500将IT治理定义为“领导和控制当前和未来IT使用的体系”。ISO/IEC38500涵盖了适用于DLT系统治理的多个内容。DLT系统当具有特定特征和依赖关系时，需要采用不同于ISO/IEC38500所给出的IT治理方法。对于中心化组织的IT系统治理是一个相对成熟的领域，但对于以DLT系统为例的去中心化系统的治理却知之甚少。本文件阐述了治理DLT系统所需的特定治理功能和治理特征。ISO/IEC38500中的IT治理定义涉及责任和问责机制。在参考文献[17]中，IT治理被定义为“在使用IT过程中的决策权和问责框架，以激励可取行为”。这个定义包含了IT治理的三个关键维度：决策权、4GB/ZXXXXX—XXXX问责机制和激励。对于跨多个组织的去中心化系统，宜考虑这三个关键维度。以DLT系统为例的去中心化系统通常存在于在一组组织或个人之间。去中心化系统的治理与组织性质以及组织方式密切相关。根据去中心化程度的不同，共有三种类型的DLT系统，它们分别具有不同的治理结构和流程。非许可公有DLT系统被认为是完全去中心化的，许可公有或许可私有的DLT系统具有中心化的属性，详见表2。例如，非许可公有系统的治理机构可以是一组去中心化的匿名利益相关方，其没有明确声明任何组织层级。相比之下，许可公有系统的治理机构可以是一个或多个清晰可识别、验证的实体。在许可公有DLT系统中，存在不同形式的治理实例，如合作社、寡头政治或协会，它们可以通过成员投票机制来选举代表或任命固定任期的决策者。基于文献18的定义，表1详细描述了DLT治理的关键维度。表1DLT系统的治理维度a)与传统中心化治理环境相比，去中心化治理环b)决策权可以在账本内或账本外被定义，决策权也可以显性的或隐性的被定义。隐性的决策权f)分叉是利益相关方通过建立不同治理机制或规则的新DLT系统从而分离出一个新的DLT系当利益相关方对治理决策有争议时，分叉同时也是个小群体执行，然后扩展到一个更广泛或不同a)问责是基于DLT系统参与方的可识别性，他们对具体的结果和决b)问责机制在网络中被明确规定，并由DLT系统进行委托和代理。a)激励在DLT系统中，发挥着驱动不同Db)激励是保障系统持续运行和治理的必要活动。c)如果参与者和其他利益相关方的激励机制不一致，可能会导致出现对参与者或利益相关方造d)DLT系统中的激励机制推动着决策者DLT用户不一定受现有组织关系的约束，也不一定受合同、商业协议甚至司法管辖区的约束。治理这样的DLT系统需要特定的调整，为适应传统治理机制以及常规决策权和问责机制的缺乏。在去中心化或多中心化系统中，DLT用户和其他利益相关方将从DLT系统生命周期的每个阶段明确规定的决策规则、问责机制和激励中收益。DLT系统治理的性质取决于不同的系统层级，详见图1。5GB/ZXXXXX—XXXX图1DLT系统治理层级第I级——DLT共识机制治理：选择工作量证明、权益证明或权威证明等共识机制，定义后续的决策权和激励，从而确定整体治理方案。第II级——DLT系统治理：通过应用账本内的技术执行的治理机制，或账本外的治理来实现。账本内治理依赖于支持性的或隐性的决策过程、问责机制和激励机制。第II级规定了如何制定DLT系统决策以及如何解决潜在冲突。账本内的治理规定，编码治理规则将决定允许哪些参与者参与决策，如何解决争端，以及特定决策达成可接受共识的投票机制如何运作。第III级——DLT互操作治理：确保DLT系统与非DLT系统等其他系统间的互操作性。在DLT治理中，宜区分DLT系统的治理和通过DLT系统进行的治理。a)DLT系统的治理DLT系统的治理遵循其他社会技术标准的逻辑，即将DLT系统等技术视为需要治理的操作对象。本文件制定第II级和第III级DLT系统治理指南时，主要遵循该逻辑，如图1所示。按照这种观点，控制源最终位于DLT系统之外，并对其强制执行治理机制。f)通过DLT系统进行的治理通过DLT系统进行的治理遵循算法治理的逻辑，或从技术-社会的角度对其进行治理。DLT系统等技术被视为行使治理的操作代理。在图1中，一旦选择并实施了共识机制，第Ⅰ级治理中伴随共识机制的算法治理机制将会强制执行或规定后续的决策和行为。按照这种观点，控制源位于DLT系统内部，并通过其强制执行治理机制。虽然人们普遍认为，随着自主系统和机器间交互的出现，通过DLT系统进行治理的概念（有时称为算法治理）正变得越来越重要，但本文件采用了社会-技术视角，而不是技术-社会视角来看待DLT治理，认为控制源在于人类和法律实体，而非技术实体。明确DLT系统中的控制和权力来源是有效治理的关键要求。这一点尤其重要，因为在这些系统中，可能缺乏或减少了确保记录交易完整性的决策权威。与更加传统的中心化系统(例如：C级管理层、股东、董事会)相比，DLT系统的去中心化特性可能导致DLT参与者之间权利所有权的边界不清晰。因此，那些积极参与治理DLT系统的人可以更多地关注他们作为用户的需求，而不是作为这种去中心化系统相关权利所有者的需求。6.4决策权和决策制定决策是系统治理的一个关键属性。DLT系统的治理涉及诸如分叉决策，决定系统账本内运行的共识规则决策，以及关于不同参与者权利以及如何解决他们之间冲突的决策。DLT系统决策制定可以发生在账本内或账本外。当在账本内时，决策受嵌入在DLT系统内的决策权和问责规则的约束，并据此执行。当在账本外时，决策和权力涉及隐性或显性治理规则的应用，也包括决策权和权力。隐性账本外治理的缺点是对参与者不透明，而优点是更好地防范DLT系统中嵌入的账本6GB/ZXXXXX—XXXX内治理规则可能无法预知的风险和挑战。去中心化决策需要一些与去中心化系统不同的元素、技术和流程。与DLT系统相关的去中心化决策的一个关键特征是使用共识机制来达成决策。共识机制阐明了决策将被批准为DLT系统参与者可执行性的标准。共识规则可以采取不同的形式。当体现在账本内时，DLT系统本身提供了制定、定义、讨论、投票和将决策付诸实施的机制。当在账本外时，需要其他机制，如对特定参与者具有法律约束力的义务，使决策在DLT系统中具有约束力和可操作性。6.5问责机制为了提高当前和未来DLT系统用户以及其他利益相关方的透明度，DLT系统中各方的责任和问责机制宜被明确声明。这使参与者能够理解权力如何分配和归属，并降低DLT用户和其他利益相关方在评估分布式账本系统运行相关风险时的不确定性。未明确分配决策问责和责任的DLT系统会面临一些挑战，这些挑战是正式合法决策权威机构可以避免的。在没有明确声明关键运营和治理决策的职责范围的情况下，实际拥有控制权的各方往往缺乏正式的问责机制。这使得参与者在治理失败的情况下，无法获得有限的监督和监管约束，如包括滥用权力、挪用系统资产，或做出不符合大部分DLT系统用户利益的决策。这给DLT系统的利益相关方带来了挑战，使他们缺乏有效手段来对拥有隐性权利的决策者在DLT系统上问责，即使这些决策违反了DLT系统的规则、原则或惯例，或与DLT用户和其他利益相关方的普遍利益相悖。基于DLT的智能合约和不依赖于特定个人或少数人群控制的组织也带来了问责挑战。这些能力的新性质给监管机构和治理机构用于规范个人和组织活动以最小化系统风险的传统控制手段提出了挑战。此类控制通常施加于机构及其高管，监管机构和治理机构通过发放经营许可证行以及指定法律制裁和惩罚的权力对他们的行为进行控制。当这些控制点被自治的、去中心化的治理实体所取代时，由此产生的问责空白就会挑战监管目标，因此有必要定义底层的协调实体，以支持在不确定性中的问责机制。分布式账本系统中的智能合约允许未知方以降低欺诈风险和第三方执行成本的方式进行交易。通过这种方式，智能合约提供了一种有效的手段来解决与交易对手风险相关的成本和不确定性。相反，智能合约也带来了关键的治理挑战，这些挑战表现在是否符合现有法律和监管框架的不确定性，以及由于其非法和违规操作，在执行法律裁决和制裁时面临的挑战。决定智能合约操作的逻辑嵌入在其源代码中，这种代码的可见性不足可能会进一步增加这些系统问责分配的不确定性。解决DLT系统挑战的方法：a)DLT提供方宜让利益相关方看到DLT系统的问责分配。理想情况下，这些问责在账本内是可见的。或者在账本外公有账本内提及的问责分配情况。b)DLT提供方宜公开其关于DLT系统的报告，以供独立审计。c)DLT提供方宜向监管机构公开DLT软件代码和文档，或包含可解决问题的机制。d)DLT系统宜为DLT参与者、提供商和更广泛利益相关方建立争议解决机制。6.6激励与激励机制DLT系统在如DLT用户、DLT提供方和DLT开发者等利益相关方的群体之间存在激励不对称的风险。激励不对称可能导致系统被利用，并在DLT系统参与者之间造成经济和其他方面的不平衡，最终导致系统失效。DLT系统激励是指任何能够影响参与者行为的系统设计机制。DLT系统激励可以采取多种形式，从确保遵守法律义务到用户功能或经济激励。激励措施还可以采取鼓励形式，让DLT参与者和利益相关方不以某些特定方式行事，这将有助于阻止参与者采取可能对整个系统或特定类别的参与者的长期发展产7GB/ZXXXXX—XXXX生不利影响的行动。DLT激励机制是指DLT系统中激励的具体实施方式。账本内的DLT激励机制使用特定的DLT结构将激励体现在DLT系统中，包括社会科学和计算机科学中的数学模型，如基于博弈论的奖励机制作为经济激励，或支持验证需求的激励。大多数非许可DLT系统的关键特性是，它们使用账本内激励机制来激励不同的利益相关方群体以预期的方式行事，从而保障系统运行的稳定性和完整性。激励机制也可以在账本外发生。这些通常以传统的激励机构来体现，如各方之间具有法律约束的商业义务、社区内的声誉维护以及现有的经济激励。DLT系统本质上是分布式的。参与者关系的复杂性增加，增加了参与者之间利益和激励不一致的内在风险。当参与者被激励以特定的方式行事，以牺牲其他参与者和DLT系统的整体健康和稳定为代价来获得自身利益时，就会发生这种情况。如果这种不平衡在结构上是被允许的，或者在DLT系统中以其他方式固化，这可能导致一个参与者或某类参与者持续承担成本，使他们考虑退出系统。如果DLT系统需要它们的存在才能继续存在，这反而会危及系统本身的寿命。在设计系统激励时，要重点考虑DLT系统的类型，因为不同类型的系统需要不同的激励机制。在非许可的DLT系统中，参与者可匿名，也可免除任何正式关系或合同义务。这类系统通常依赖经济激励来达成共识，表现在对账本内通证的依赖。另一方面，在许可DLT系统中，参与者是预先定义的，这意味着激励通常可以通过传统手段(例如法律合同、创造效率和业务收入)来创建。这意味着许可系统通常不需要本地账本内的通证并且可以依靠各方之间现有的可执行关系，通常表现为账本外的法律强制关系。DLT系统的一些参与者可能会同时受到账本内和账本外的激励。在这种情况下，宜向所有参与者公开账本外的激励，对信息较少的DLT参与者，以最大程度地减少信息不对称的可能性，避免这种信息不对称导致信息较少的DLT参与者遭受经济损失。当账本外的激励机制不可能或不可取时(即去中心化的DLT系统)，账本外的激励机制对实现DLT系统治理尤为重要。有效的账本外激励机制宜能够实现DLT系统的持续良好治理，并于参与者和利益相关方之间存在的账本外激励机制协同。为了最大限度地降低激励不一致的风险，DLT系统账本内和账本外的激励宜公开透明。7不同类型DLT系统的治理7.1DLT系统类型从治理角度看，DLT系统可根据两种访问维度进行分类（见表2）。访问系统进行交易验证（通过运行DLT节点）涉及到验证交易的能力以及安装协议更新的控制权。在非许可的DLT系统中，所有实体都有权验证交易。非许可指系统没有明确的所有者，因此没有实体有法律权力排除其他实体参与。在有许可的DLT系统中，只有预先注册的实体才有权验证交易。在此情况下，系统有一个所有者且该所有者可以决定访问系统进行交易验证的参与者名单。第二种访问形式是指技术上的排他性。公有DLT系统允许所有实体读取数据和提出新交易，从技术上无法阻止对系统的访问。私有DLT系统则只允许由中央权威预先注册的实体读取数据和提出新交易。对于系统的拥有者来说，可在技术上决定是否允许某个实体访问DLT系统[18]。表2DLT系统治理类型访问对所有实体开放——运行及操作访问对所有实体开放——运行及操作8GB/ZXXXXX—XXXX实体的访问受到限制——运行及操作实体的访问受到限制——运行及操作资源在技术上无法被限制使按照此种逻辑，非许可或许可是与某种所有权相关的维度，而公有或私有则涉及技术上的排他性。在治理方面，控制和权威的来源比技术上的排他性更重要。这就是为什么使用“非许可公有”、“许可公有”和“许可私有”，而非“公有非许可”或单纯的“公有”的原因，因为后者不足以具体定义DLT系统的治理类型。这些治理类型会导致DLT系统内部治理方式的多样性。从生命周期的角度看，所有此类系统仍将遵循7.1节中描述的生命周期，但不同治理类型下，系统中各个角色的责任和义务会有显著变化。为了更好地理解从节点或验证者以及DLT系统用户的角度来看不同的治理类型，可见表3中有关生命周期操作阶段功能的详细说明。预先注册的DLT预先注册的DLT预先注册的DLT预先注册的DLT预先注册的DLT点决策过程的去中心化说明需要有大量有影响力的决策者或投票者。抗压韧性要求决策不能被少数人操控，这在非许可DLT系统中尤为重要，因为这需要大量活跃的投票者关注每个决策。在此种情况下，可扩展性意味着每轮投票中可能需要做出许多决策。决策过程的去中心化也意味着没有中央控制机制的情况下运作，此种情况只存在于非许可DLT系统以及某些许可系统的运作阶段。在缺乏中央控制机制和信任程序及权威作为代理时，在不确定环境中生成信任的情况下，宜避免权力的集中。若负责设计和实现DLT系统的治理机构采用集中管理的模式，则会像在许可系统中一样形成权力集中。一旦系统发布，基于分布式代码执行的DLT系统便成为一个集中化搭建的系统。对多数人而言，DLT系统代表去中心化和权力分散，而在非许可公有系统中，另一个重要元素是包容性，即每个人都可以参与治理。在本文件中，DLT系统的治理结构分为三种不同类型的治理机制和治理生命周期，上述类型在图2中进行了展示。9GB/ZXXXXX—XXXX图2DLT系统治理分类作为图2详细说明的扩展内容，本文件讨论了DLT系统的以下特征，这些特征取决于系统属性（许可/非许可）和（私有/公有），并考虑到交易验证以及系统的开放性或技术排他性。DLT有许多参与节点，这些节点在各种组织环境下运行，包括：a)非许可公有：节点由不同的参与方（个人或组织）操作，这些参与方不一定有共同利益，也不一定相互认识或被明确的权威机构认可。b)许可公有：节点由不同的实体（如金融或供应链行业的公司）运作，这些实体由一个共享的顶级组织（如行业协会）拥有或对其负责。c)许可私有：节点是由单个实体拥有和运作的独立IT系统。传统的IT治理方法可以直接应用于类型B（许可公有）和类型C（许可私有），尽管DLT系统的详细策略、政策和管理系统可能与传统系统（如云系统或企业IT）不同。责任和义务可以通过外包合同产生，而非通过单个组织或联盟的所有权，但这种安排依然适用于传统的IT治理方法。对于类型A（非许可公有在所有参与方共同认可一个共享的权威来源或治理机构的情况下，传统的IT治理方法也可以有效。7.2许可DLT系统的治理在传统的信息系统实现中，许可DLT系统的访问规则由其所有者个体或群体定义。而在公有许可DLT系统中，尽管账本可以是去中心化的，但其访问规则是由一个中央权威机构、特权用户组成的联盟或委员会来定义的。用户获得DLT系统访问权限的条件可能是该用户满足特定要求（例如，该用户是一家特定行业的公司，通过第三方认证或遵守某些资本要求或者由其他用户或权威机构共同选择或选举。这些访问规则完全由建立阶段的所有者个体或群体决定，所有者可以组织成任何现有的组织形式。在此类DLT系统中，未经所有者个体或群体的同意，用户无法成为验证节点甚至系统的阅读者。系统背后的所有参与方都是已知的、可识别的，并且此类许可系统背后的组织通常为公司结构、基金会结构或类似于开源协作社区。GB/ZXXXXX—XXXX这也意味着系统中的问责相对容易执行，并且此种DLT系统可以有条理地进行维护和升级。对于已知所有利益相关方身份的许可DLT系统，宜明确实施决策权、问责和激励机制。如前所述，许可私有DLT系统的治理类似于层级组织环境中的传统IT治理方法。许可私有DLT系统的治理方式类似于组织内部或共享IT系统的常见治理方式。由于此类系统由明确的单一控制源拥有和运作，传统的治理方法已经满足要求，无需通过责任、问责和决策权的去中心化进行扩展。在许可公有DLT系统中，可以看到许可私有系统和非许可公有系统的元素。因此，这些系统通常被称为联盟或混合系统。当DLT用户需要权限访问系统时，会有一个特权机构或管理机构授予访问权限。尽管该特权实体有权代表所有DLT用户行事，但大多数许可公有系统具有分布式治理的元素。管理机构可以决定分配决策权、问责，并提供类似于非许可DLT系统的激励机制。此类混合系统的主要区别是特权实体可以随时撤销分布式决策权。7.3非许可公有DLT系统的治理传统的IT治理方法存在一个假设，即存在明确的所有权作为权威来源，治理机构可以在必要时行使权力并承担责任。然而，在非许可公有DLT系统中，没有单一的权威来源。在DLT系统治理的生命周期中，非许可公有DLT系统在治理方面会带来独特的挑战。尽管治理的基础在建立阶段就已经奠定，但后续可能需要进行调整，这需要通过账本内或账本外的治理机制来组织软分叉或硬分叉。在DLT系统的建立阶段，系统架构师宜为预期目的设计治理系统。可由单一权威机构或由未来使用该系统的社区委员会完成。设计好的治理系统需要在启动前或启动时获得社区的批准和采纳。批准可以通过实际使用（用户安装钱包进行交易）或通过投票机制来合法化并正式验证系统的实施，具体取决于所提议的流程。通常需要在核心开发者的提议与验证者和全节点的采纳之间找到平衡，同时考虑不同利益相关方的激励。如果潜在用户不采纳或之后认为现有的治理结构不利，他们可以对系统进行分叉并创建新的DLT系统。因此，分叉是非许可公有DLT系统中处理争议的一种治理工具。非许可公有DLT系统被许多群体视为能够将参与式决策结构和决策过程引入商业模型，从而发展出一种新的经济系统。这是因为DLT系统具有有效性、透明性和可审计性。这可能需要修订或创建新的系统维护、风险框架以及最终的治理形式，可能还需要引入声誉机制或其他激励结构。由于非许可公有DLT应用和基础设施高度关联，基础设施的治理必须考虑其上构建的应用程序的治理。与传统IT治理不同，在传统IT系统中可以将应用程序下线、修改后再上线，而在非许可公有DLT系统中无法实现。因此，设计治理系统时，必须考虑非许可DLT系统上的应用类型。这些类型可以是直接交易型（如钱包）或按条件交易型（由可识别方通过智能合约进行）。根据不同类型，需要采用不同的治理方法。8系统生命周期治理和内容治理8.1DLT系统生命周期治理GB/ZXXXXX—XXXX图3DLT系统生命周期8.1.1概述DLT系统的生命周期经历建设、运行和终止三个核心阶段，如图3所示。DLT系统的治理贯穿全生命周期阶段的问责、决策权和激励。治理挑战和需求的本质因DLT系统的生命周期不同而异。8.1.2建设阶段治理在建设阶段，涉及形成DLT系统的需求和设计，启动和评估试点项目，推进商业化实施及开展研究。在这一阶段，设计和实现了关键的治理功能和基础设施。在DLT系统建设阶段的治理包括：a)治理机构或架构的性质和类型；b)DLT系统和非DLT系统的互操作性；c)遵守法律和监管框架；d)任何DLT系统基本规则的存在和形式；e)争议解决机制和程序；f)账本外治理的范围和作用；g)管理运营的程序和规则；h)DLT系统的终止。DLT系统建设阶段的治理决策是由问责方在系统建设过程中隐性的或显性的提出并制定的。宜澄清治理决策权的赋予方，以减少系统建设阶段的不确定性。DLT系统建设阶段的关键决策，将定义随后部署的DLT系统的治理方式。一旦这些决策由问责方做出，DLT系统建立阶段的下一阶段治理决策就与DLT系统的设计及支持DLT系统运行所需的基础设施有关。建设阶段的治理决策将影响系统运行阶段和终止阶段的治理，决定系统的运行方式、运行原则以及系统更新规则。8.1.3运行阶段治理当DLT系统建立后，它就进入了其生命周期的运营阶段。核心目的和功能是根据其设计进行执行，并根据在建立过程中设定的决策权、问责和激励机制进行管理。DLT系统的治理在运营阶段负责几个关GB/ZXXXXX—XXXX键功能，包括DLT系统中参与方的参与权利以及与之相关的合约规则等。所有DLT系统都宜在法律和监管框架的范围内运行。DLT系统可以提供指南和账本内的管理机制来管理运营。DLT用户之间以及与账本外实体之间的交易，由交易规则和交易功能决定。宜确定适用于给定用户特定情境的规则和功能。此外，宜对交易进行验证，以确保在DLT系统上执行的交易的有效认定，并且可以被其他DLT用户信赖为真实且是对现实的正确表达。在DLT系统的背景下，这将包括验证、操作共识机制、共识管理和治理决策的执行。DLT系统的管理和监督在其运行过程中进行。这涵盖了DLT系统持续运行所涉及的操作。在监督方面，DLT系统在更广泛的账本外环境中运行。DLT系统可以为监督和管理功能提供账本内支持，并具有额外的账本外监督功能。在DLT系统建设阶段，宜设计DLT系统的架构和运营方式，以及与其最终终止相关的治理机制。在审查DLT系统的持续运营过程中，宜明确治理机制将如何运作，包括此类决策权的责任归属，以及它们将如何应用和实施。8.1.4终止阶段治理当DLT系统进入终止阶段时，治理决策主要包括决定DLT系统的数据或资产如何被转移、销毁或以其他方式处置，以及参与方的权利如何得到清算。终止阶段宜明确支持DLT系统终止时与外部环境的交互，否则DLT系统的终止将由账本外的治理条件和因素所决定。8.2DLT系统环境治理8.2.1DLT治理概览不同的DLT治理如图4所示。8.2.2数据数据治理包括与DLT系统全生命周期各阶段相一致、相适应的数据治理的方方面面。在DLT系统生命周期的创建阶段，数据的治理被定义。这包括在DLT系统整个生命周期中，如何及哪些类型的数据会被定义、管理以及销毁，同时也界定了当与其他DLT系统及非DLT系统共存与交互时的数据治理。在DLT系统的运营生命周期阶段，数据被采集、存储、汇报、融入决策和分发。DLT系统的运营宜GB/ZXXXXX—XXXX预测在每个上述功能中的每一种情况下数据将如何被治理。在DLT系统生命周期的终止阶段，DLT系统的治理宜预测并指导数据的处置，包括其归档或销毁。8.2.3协议在DLT系统的创建阶段，DLT系统的协议宜被定义，这包括在DLT系统整个生命周期中，如何定义及管理DLT交易。同样，在创建阶段的DLT治理协议也将界定该DLT系统协议与其他DLT系统及非DLT系统之间的协同操作性。在DLT系统的运营生命周期阶段，DLT的治理宜定义这些协议如何运行及管控它们变更的规则。在DLT系统的终止阶段，DLT系统的治理宜预测并指导DLT系统的协议如何运作。这包括终止将被如何决定、执行和验证的指导。8.2.4应用程序在DLT系统的创建阶段，DLT系统应用的治理宜被定义。这包括去中心化应用程序的实现方式、访问权限以及责任。如果应用程序被其他DLT系统及非DLT系统使用，宜为此确定规定访问权限和责任。在DLT系统的运营生命周期阶段，DLT的治理宜界定DLT系统中各应用程序如何交互，以及为了支持应用程序的持续使用，哪些变更和维护的应用治理规则是必要的。在DLT系统的终止阶段，DLT治理宜预测并指导应用程序的如何处置、销毁或转移应用程序。8.2.5组织机构在DLT系统创建过程中，DLT系统的组织机构治理宜定义DLT系统如何与特定的组织机构的治理在功能和操作上共存和协作。这包括DLT系统的治理机制和结构如何关联与现有组织机构治理职能，比如由董事会和执行管理层履行宜履行的。如果不存在这样的关系，也宜明确声明。在DLT系统的运营生命周期阶段，在机构中的DLT系统治理宜定义其DLT系统的治理功能如何与现有的组织治理功能关联和互操作，包括DLT系统的决策权、责任及激励措施如何与现有相关的组织机构一起运作。在DLT系统的终止阶段，DLT系统治理宜定义在系统终止过程中，如何与现有的组织机构治理功能协同工作，包括DLT系统的决策权、责任及激励措施如何与各组织机构的治理相协作。9治理框架中的角色责任、问责、决策权和激励机制可以归因于DLT系统中的不同角色，无论是在账本内还是账本外环境中。鉴于DLT系统有许多不同的设置，因此没有一种单一的正确方法将这些属性分配给系统中的角色。角色之间可能存在冗余。表4中的治理框架中所展示的角色可以是一个单独的个人/实体，或者多个合作以完成该角色功能的个人或实体的组合。并非所有角色都适用于所有的DLT类型。通常，DLT用户通过一个应用程序或与API交互的账本外代码的方式来使用系统，而不是直接与DLT节点交互。对于那些使用自动化系统，而不是自然人用户的DLT用户来说更是如此，它们与DLT节点的交互往往是通过DLT应用程序提供的API来实现的。表4治理框架中的角色实现DTL系统的长期商业模1.设定并维护与以下责任和问责相关的策略：值GB/ZXXXXX—XXXX式的可行性和连续性（包含经济、道德、法律和财务方面）。b)许可d)决策规则和冲突解决（如：投票机制）.账本内和账本外的决策安排和协议.社区领袖的角色和权力.管理投票和分叉e)所有职位和角色的激励、责任和问责2.与外部利益相关方沟通（如适用）4.与DLT节点运营者合作以确保监控和治理得到执行。6.管理行业联盟，管理单一企业的赞助关系DLT审计方收集并验证1.设定审计活动的策略，涵盖性能和DLT审计方确保DLT系统中政DLT系统遵守策策审计的证据，2.确保DLT组件审计和报告工略、治理和法规。向相关方（例如他们可以与DLT管理方、管理员运营方、监管方、等）发出偏差信5.提出解决方案，支持执行纠正措施管理方等合作。DLT管理方DLT管理方执行特定的管理活动（特别是针对安全配置）。确保DLT系统完全的完整性。4.管理对DLT系统的基于角5.制定和管理隐私和安全策略及协议励DLT开发者对DLT开发者，有两个子角色——DLT应用开发者和DLT系统开发者。确保DLT系统的连续性，来持续地适应系统对技术和业务的需求。1.管理社区对开发策略和规5.设计、创建、集成和维护专用设备励GB/ZXXXXX—XXXX8.如果适用：管理公司内部开发团队DLT提供方DLT提供方指在DLT系统和DLT网络中拥有并运营一个或多个节点的角色。子角色包括：DLT系统节点运营方、DLT节点运营方和DLT应用运营方。确保运行DLT系统组件的虚拟和物理元素的业务连续性和所需的技术性能。护6.确定分片、轻节点、其他配置7.提出和/或确定DLT配置的励DLT用户通过非欺诈性1.使用DLT系统提供的服务可以代表个人、组的方式来确保织、设备或系统。DLT系统的连3.使用DLT用户应用程序励续性，从而加强治理规则及其4.安装用于与DLT系统交互的客户应用。6.观察并遵守规则，不参与欺诈行为10治理工具10.1概述DLT系统治理通过DLT协议内部的工具（账本内治理工具）、DLT协议外部的治理工具（账本外治理工具）和账本内账本外交互来实现。为实现透明治理和问责，具体系统的治理策略宜确定并记录工具信息、工具交互情况。账本内治理工具可写在DLT协议中，也可由智能合约执行。账本内事件和账本外事件均可激活治理工具。账本内治理工具根据其编程逻辑运行，执行具体操作，但不对操作后果负责。账本外治理工具在DLT协议之外应用。通常，账本外治理工具使DLT协议与法人实体连接，确定决策权、问责机制和激励结构。法人实体应用的账本外治理工具宜符合相关监管框架和法律规定。账本外治理工具宜尽量和账本内治理工具保持一致，互为补充。可由正式协议明确约定DLT系统中部署的治理工具或工具类型。通常在系统建设阶段确定DLT系统治理，如选择共识机制，约定全生命周期内开发和维护DLT协议的规则和流程等。根据ISO/IEC38500，DLT利益相关方可通过以下三种方式参与DLT系统治理：a)评估DLT系统当前和未来的使用情况，识别义务和风险；b)亲自制定、实施相关策略、流程和内控框架，确保合规使用DLT系统，降低重大风险；c)监控策略、流程和执行是否符合内控框架，以降低风险，确保合规。有效、高效、规范地建立、运营和终止DLT系统的责任仍由治理机构承担，不宜委托给其他机构。10.2账本内及账本外治理工具GB/ZXXXXX—XXXX10.2.1概述账本内和账本外两种治理工具皆可部署于DLT系统以达成治理目标。工具可根据表1列出的维度进行分类。表5从问责性、责任和决策权、激励等三个角度列出账本内和账本外治理工具的特征。这些特征是DLT用户有效设计DLT系统所需的典型属性。表5内容并非详尽，可能有重叠。为实现预期目标，DLT系统可以组合部署表中多种工具,也可部署表中未列出的工具。宜记录所用工具便于相关方知晓DLT系统的治理情况。表5账本内和账本外治理工具——身份鉴别——存取控制——确认——审计——数据保护——认证——基本属性——处理权——访问规则——范围——共识协议运营——过程执行模型——交易过程——灵活性——互操作性——安全性——运营一致性——数据验证——访问策略——应用访问——抵制审查制度——碎片化——身份暴露——社区规则——决策过程——可扩展性——实现——共识协议选择——验证——性能——成本效益——可转移性10.2.2账本内治理工具账本内治理由DLT系统的内在设计决定，该设计包含制定、更改和执行系统运行规则的整套机制。治理透明度显著增强DLT用户和其他利益相关方对系统的信任。账本内治理的价值之一是提升治理机制及其更改流程和更改历史等的透明度。此外，账本内治理支持多司法管辖区部署。例如，共识机制就是一种账本内治理工具，一个具体决策需达到共识协议要求的最低法定人数才能获得批准。账本内治理可能导致无法达成共识，因此系统可支持分叉，有分叉时宜遵循适当流程确保参与方将账本稳妥拆分为两个单独的DLT系统。10.2.3账本外治理工具账本外治理取决于DLT系统外部的机制。因需要遵守法律和监管框架、要求、行业行为规范，所以所有DLT系统都与账本外治理有所交互。账本外治理是为了支持账本内交易达成预期目的。例如，治理包括支持防篡改和交易验证的能力，确保账本内账本外信息完整。账本外治理宜符合ISO/IEC38500、ISO/IEC27014和ISO37001中规定的原则。借助账本外治理，利益相关方可以通过投票等机制达成共识。10.3实现治理机制的相关考虑10.3.1适应性DLT系统在运行过程中对变化的适应能力决定其可用性。DLT系统治理宜能对变更达成共识，随后执行变更。宜采用诸如ISO9001或ISO/IEC20000-1规定的流程来管理变更。GB/ZXXXXX—XXXX对于许可公有DLT系统，网络中的DLT治理者负责治理变更，治理机构组织实施系统变更。许可私有DLT系统不需要专门的共识机制才能决定变更，有需要时利益相关方就能实施变更。在非许可公有DLT系统中，宜实现投票之类账本内治理机制以发起、完善和执行变更。如果利益相关方间无法达成共识，可以选择分叉DLT系统，有软、硬两种分叉方法。10.3.2风险在DLT系统中，多数情况下参与者按照诸如ISO31000、ISO31022和ISO/IEC27005中所概述的现有风险管理框架即可评估风险。然而，DLT系统还面临分布式或去中心化系统治理特有的风险。多方有效治理，DLT系统才能正常运行，决策权、问责或激励机制的错配将给各个参与方和DLT系统本身带来巨大的风险。许可和非许可系统都如此，但风险的根源会有所差异，取决于系统类型和治理结构。在没有中心治理机构的非许可系统中，风险的缓解依赖于多样化的、可能匿名的个人群体。不同DLT系统的风险缓解，由账本内机制实现，或者在账本外发生。参与方之间的激励不一致可能会导致意想不到的后果。此外，非许可系统的改进通常是开放式的，如果没有账本内机制的支持，决策就会很繁琐，阻碍问题的有效解决。为降低此类风险，宜引入有效机制在非许可系统全生命周期保持共同的激励。在许可DLT系统中，合约框架等传统治理机制基本能实现高效多方治理，但依然会有激励冲突。比如系统中占据了主导地位的参与方可能会利用其地位追逐私利。特别是当DLT系统由竞争者共享时，商业竞争会导致决策和系统改进效率低下。为了避免这种情况，许可系统宜从建立阶段就考虑并引入共同的基础和共同的激励措施,并在系统全生命周期加以维护。诸如构建商业和组织结构时要考虑尽量整合所有潜在系统参与方利益。DLT系统整体风险评估的难度取决于系统类型。对于许可DLT系统，其利益相关方经批准才能加入，身份明确，风险评估较为容易。因此宜在生命周期的不同阶段实施例行风险评估。对于非许可公有DLT系统，其利益相关方身份不明，风险评估通常较为复杂。在进行风险评估时，宜考虑以下一般风险领域：——行为风险（例如：平等对待客户、客户投诉、员工行为）；——公开风险（例如：数据隐私、身份盗窃、内幕交易、市场操纵——网络风险（例如：数据篡改、暴力攻击、双花、DDoS攻击）；——技术风险（例如：硬件、中间件和软件兼容性、升级路径、设备兼容性）；——运营风险（例如：缺乏规范、关键人员风险、玩忽职守——竞争风险（例如：串通、反竞争行为、信息共享、垄断——知识产权风险（例如：侵犯版权或专利、滥用开源材料或违反许可证，丧失、盗窃或滥用知识产权）；——责任风险（例如：服务的欺诈、盗窃、丧失或滥用导致赔偿，软件未归因、滥用、错误的责任，治理、运营或其他变更的责任）；——金融犯罪风险（例如：未充分进行身份验证和制裁、用户甄别和交易监控（反洗钱和制裁）、欺诈预防）；——监管风险（例如：未遵守监管规定、监管变更、投资者或客户保护）。DLT系统中的一个利益相关方可能只需要处理其中的一部分风险，例如用户只需要评估和处理技术风险。DLT系统的利益相关方宜在系统全生命周期中遵守合规要求。这对非许可公有DLT系统带来一个问题：需要厘清合规要求中哪些由利益相关方满足，哪些由系统自身满足。在许可的公有或私有DLT系统中，治理机构宜选择需满足的合规要求，并在整个系统中落实。GB/ZXXXXX—XXXX10.3.3隐私DLT系统治理机构宜决定DLT系统如何存储、管理个人身份信息，包括考虑账本内外机制。治理机构宜关注隐私原则，比如隐私框架中对治理有影响的部分，以ISO/IEC29100、ISO/