區(qū)塊鏈和分布式記賬技術 治理指南 征求意見稿_第1頁
區(qū)塊鏈和分布式記賬技術 治理指南 征求意見稿_第2頁
區(qū)塊鏈和分布式記賬技術 治理指南 征求意見稿_第3頁
區(qū)塊鏈和分布式記賬技術 治理指南 征求意見稿_第4頁
區(qū)塊鏈和分布式記賬技術 治理指南 征求意見稿_第5頁
已閱讀5頁,還剩33頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1GB/ZXXXXX—XXXX區(qū)塊鏈和分布式記賬技術治理指南本文件給出了分布式記賬技術系統(tǒng)的治理指導原則和框架。本文件適用于指導分布式記賬技術系統(tǒng)的風險、監(jiān)管環(huán)境等相關治理,以實現(xiàn)有效、高效、規(guī)范的分布式記賬技術系統(tǒng)應用。2規(guī)范性引用文件下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件,僅所注日期的版本適用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改單)適用于本文件。ISO22739,Blockchainanddistributedledgertechnologies-Vocabulary3術語和定義3.1分布式記賬技術治理,distributedledgertechnologygovernanceDLT治理,DLTgovernance指導和控制分布式記賬技術系統(tǒng),包括賬本內和賬本外決策權分配、激勵、責任和職責,確保分布式記賬技術的應用合規(guī)、風險可控和價值實現(xiàn)。3.2治理實體,governingbody對分布式記賬技術治理的性能和一致性、合規(guī)性負責的實體。4縮略語下列縮略語適應于本文件。DApp:去中心化應用(DecentralizedApplications)DLT:分布式記賬技術(DistributedLedgerTechnologies)KYC:了解你的客戶(KnowYourCustomer)5治理原則5.1概述2GB/ZXXXXX—XXXX本章節(jié)規(guī)定了九項面向DLT系統(tǒng)治理的行動原則,后續(xù)文件會更詳細地闡述。這些原則幫助利益相關方評估和改進治理機制、結構和活動,并實治理目標,即:有效、高效和規(guī)范地使用DLT系統(tǒng)。同時也實現(xiàn)了對利益相關方在治理框架內履行職責的正確激勵。DLT系統(tǒng)的治理宜包括在其建立、運營和終止過程中致力于解決可持續(xù)性問題。注:關于可持續(xù)性問題的有用信息源自《ISO26000社會責任》和《聯(lián)合國可持續(xù)發(fā)展目標(治理原則為DLT系統(tǒng)的機制、結構和活動的實施提供了基礎。每項原則表述其重要性和必要性,但沒有規(guī)定這些行動應當如何、何時或由誰實施,這取決于DLT系統(tǒng)的性質。5.2原則5.2.1原則1:定義實體參與方的標識符不同DLT系統(tǒng)的參與方標識符可能會有所不同。某些DLT系統(tǒng)使用化名作為賬本內的標識符,而另一些則使用賬本外的標識符來提供可信度。定義適用于DLT系統(tǒng)的標識符是所有治理功能的基礎。5.2.2原則2:實現(xiàn)去中心化決策去中心化決策是DLT系統(tǒng)的一個關鍵特征。DLT系統(tǒng)的決策可以分為賬本內和賬本外。去中心化系統(tǒng)促進了集體決策,增強了整體的信任。DLT系統(tǒng)宜支持去中心化的賬本內決策流程;當決策在賬本外做出時,宜以明確、正式的形式做出。5.2.3原則3:明確問責機制在DLT系統(tǒng)的生命周期中,所有權和決策權會發(fā)生變化,因此問責機制也會產生變化。鑒于大部分DLT系統(tǒng)去中心化的性質,需要建立明確的問責機制來執(zhí)行規(guī)則。在適當情況下,賬本內宜強制執(zhí)行問責機制,賬本外宜強制或補充執(zhí)行問責機制。5.2.4原則4:公開透明在DLT系統(tǒng)生命周期中涉及的操作、決策和運營宜對各利益相關方公開透明。DLT系統(tǒng)宜構建允許利益相關方查看和審計系統(tǒng)動態(tài)的機制。5.2.5原則5:激勵機制與系統(tǒng)治理目標一致DLT系統(tǒng)的激勵機制推動決策者之間達成共識,解決沖突,并就持續(xù)治理、設計和運營做出決策。DLT系統(tǒng)的激勵機制在驅動用戶和其他利益相關群體的理想行為方面發(fā)揮著關鍵作用。宜明確設計支持系統(tǒng)治理目標的激勵機制。5.2.6原則6:性能和可擴展性如果沒有提供性能保障,系統(tǒng)的敏捷性和可維護性將受到影響。DLT系統(tǒng)宜在生命周期內提供滿足性能和可擴展性需求的機制。DLT系統(tǒng)在使用時,宜保障系統(tǒng)性能,并具有有效性、高效性、可擴展性。5.2.7原則7:基于風險的決策及合規(guī)義務履行DLT系統(tǒng)的生命周期可能存在特定風險,如司法管轄權爭議。在決策過程中,宜適當評估和處理這些風險。宜制定促使DLT系統(tǒng)自我合規(guī)規(guī)則,以降低違規(guī)風險。5.2.8原則8:保證安全和隱私DLT系統(tǒng)的安全性包括機密性、完整性和可用性,宜提供適當?shù)陌踩珯C制。DLT系統(tǒng)宜考慮隱私的3GB/ZXXXXX—XXXX影響,并實現(xiàn)隱私保護。DLT系統(tǒng)宜根據(jù)任務或流程,處理安全和隱私的相關要求。5.2.9原則9:滿足互操作性要求當DLT系統(tǒng)需要與其他系統(tǒng)交互時,宜在系統(tǒng)整個生命周期中(尤其是設計階段)考慮互操作性。DLT系統(tǒng)架構宜提供互操作機制,宜支持同構或異構的DLT系統(tǒng)和非DLT系統(tǒng)。6DLT系統(tǒng)治理框架6.1概述本章節(jié)描述了DLT系統(tǒng)的治理框架。治理框架包含了與DLT治理相關的決策權、問責機制和激勵。本章節(jié)還討論了IT系統(tǒng)治理與DLT系統(tǒng)治理之間的區(qū)別。6.2與其他治理框架的比較以ISO/IEC38500、ISO/IEC/TR38502為例,傳統(tǒng)IT治理主要為中心化治理。傳統(tǒng)IT治理通常包括組織內有效、高效、規(guī)范地使用IT系統(tǒng),并負責評估計劃和提案、指導政策和戰(zhàn)略,以及監(jiān)控與IT相關的性能和合規(guī)性。一個組織不局限于公司、企業(yè)或政府機構,但需要擁有明確定義和被權威機構認證。治理機構的范圍和權力邊界通常在章程、許可文件、法律等中有所記載。與組織約束相關的IT治理的影響貫穿于現(xiàn)有治理框架的元素和假設之中。這通常反映在傳統(tǒng)IT治理框架中,具體包括定義和確保IT戰(zhàn)略和業(yè)務計劃的實施,組織管理和董事會的問責,組織風險的管理和其相關控制措施。DLT系統(tǒng)與一般的IT系統(tǒng)不同,因為它們涉及分布式計算并且是去中心化系統(tǒng),其中系統(tǒng)的不同節(jié)點通常由不同的組織或個人控制。在治理背景中,只有組織和個人被認為是問責實體。DLT系統(tǒng)可以跨越組織和司法管轄邊界,從而其治理跨越了多個組織或個人,這超出了ISO/IEC38500和ISO/IEC/TR38502等國際標準的治理方法范疇。DLT系統(tǒng)相關的組織和個人之間的關系至關重要。同時,DLT系統(tǒng)的治理框架需要解決一系列關鍵問題,包括:a)DLT系統(tǒng)有哪些不同類型,它們如何影響治理規(guī)則的制定和執(zhí)行?b)在DLT系統(tǒng)生命周期中,治理機構的變化如何影響不同的DLT治理?c)存在哪些利益相關方角色,它們如何影響DLT系統(tǒng)治理?d)如何將風險、問責機制和合規(guī)性考慮嵌入不同類型的DLT系統(tǒng)中?e)如何實現(xiàn)DLT系統(tǒng)之間以及DLT系統(tǒng)與非DLT系統(tǒng)之間的互操作性,及其需要考慮的治理事項是什么?為了實現(xiàn)對決策權、問責機制和激勵的有效治理,DLT系統(tǒng)治理宜涵蓋多利益相關方、分布式治理,并反映DLT系統(tǒng)的去中心化特性。6.3DLT系統(tǒng)治理的考慮事項ISO/IEC38500將IT治理定義為“領導和控制當前和未來IT使用的體系”。ISO/IEC38500涵蓋了適用于DLT系統(tǒng)治理的多個內容。DLT系統(tǒng)當具有特定特征和依賴關系時,需要采用不同于ISO/IEC38500所給出的IT治理方法。對于中心化組織的IT系統(tǒng)治理是一個相對成熟的領域,但對于以DLT系統(tǒng)為例的去中心化系統(tǒng)的治理卻知之甚少。本文件闡述了治理DLT系統(tǒng)所需的特定治理功能和治理特征。ISO/IEC38500中的IT治理定義涉及責任和問責機制。在參考文獻[17]中,IT治理被定義為“在使用IT過程中的決策權和問責框架,以激勵可取行為”。這個定義包含了IT治理的三個關鍵維度:決策權、4GB/ZXXXXX—XXXX問責機制和激勵。對于跨多個組織的去中心化系統(tǒng),宜考慮這三個關鍵維度。以DLT系統(tǒng)為例的去中心化系統(tǒng)通常存在于在一組組織或個人之間。去中心化系統(tǒng)的治理與組織性質以及組織方式密切相關。根據(jù)去中心化程度的不同,共有三種類型的DLT系統(tǒng),它們分別具有不同的治理結構和流程。非許可公有DLT系統(tǒng)被認為是完全去中心化的,許可公有或許可私有的DLT系統(tǒng)具有中心化的屬性,詳見表2。例如,非許可公有系統(tǒng)的治理機構可以是一組去中心化的匿名利益相關方,其沒有明確聲明任何組織層級。相比之下,許可公有系統(tǒng)的治理機構可以是一個或多個清晰可識別、驗證的實體。在許可公有DLT系統(tǒng)中,存在不同形式的治理實例,如合作社、寡頭政治或協(xié)會,它們可以通過成員投票機制來選舉代表或任命固定任期的決策者。基于文獻18的定義,表1詳細描述了DLT治理的關鍵維度。表1DLT系統(tǒng)的治理維度a)與傳統(tǒng)中心化治理環(huán)境相比,去中心化治理環(huán)b)決策權可以在賬本內或賬本外被定義,決策權也可以顯性的或隱性的被定義。隱性的決策權f)分叉是利益相關方通過建立不同治理機制或規(guī)則的新DLT系統(tǒng)從而分離出一個新的DLT系當利益相關方對治理決策有爭議時,分叉同時也是個小群體執(zhí)行,然后擴展到一個更廣泛或不同a)問責是基于DLT系統(tǒng)參與方的可識別性,他們對具體的結果和決b)問責機制在網絡中被明確規(guī)定,并由DLT系統(tǒng)進行委托和代理。a)激勵在DLT系統(tǒng)中,發(fā)揮著驅動不同Db)激勵是保障系統(tǒng)持續(xù)運行和治理的必要活動。c)如果參與者和其他利益相關方的激勵機制不一致,可能會導致出現(xiàn)對參與者或利益相關方造d)DLT系統(tǒng)中的激勵機制推動著決策者DLT用戶不一定受現(xiàn)有組織關系的約束,也不一定受合同、商業(yè)協(xié)議甚至司法管轄區(qū)的約束。治理這樣的DLT系統(tǒng)需要特定的調整,為適應傳統(tǒng)治理機制以及常規(guī)決策權和問責機制的缺乏。在去中心化或多中心化系統(tǒng)中,DLT用戶和其他利益相關方將從DLT系統(tǒng)生命周期的每個階段明確規(guī)定的決策規(guī)則、問責機制和激勵中收益。DLT系統(tǒng)治理的性質取決于不同的系統(tǒng)層級,詳見圖1。5GB/ZXXXXX—XXXX圖1DLT系統(tǒng)治理層級第I級——DLT共識機制治理:選擇工作量證明、權益證明或權威證明等共識機制,定義后續(xù)的決策權和激勵,從而確定整體治理方案。第II級——DLT系統(tǒng)治理:通過應用賬本內的技術執(zhí)行的治理機制,或賬本外的治理來實現(xiàn)。賬本內治理依賴于支持性的或隱性的決策過程、問責機制和激勵機制。第II級規(guī)定了如何制定DLT系統(tǒng)決策以及如何解決潛在沖突。賬本內的治理規(guī)定,編碼治理規(guī)則將決定允許哪些參與者參與決策,如何解決爭端,以及特定決策達成可接受共識的投票機制如何運作。第III級——DLT互操作治理:確保DLT系統(tǒng)與非DLT系統(tǒng)等其他系統(tǒng)間的互操作性。在DLT治理中,宜區(qū)分DLT系統(tǒng)的治理和通過DLT系統(tǒng)進行的治理。a)DLT系統(tǒng)的治理DLT系統(tǒng)的治理遵循其他社會技術標準的邏輯,即將DLT系統(tǒng)等技術視為需要治理的操作對象。本文件制定第II級和第III級DLT系統(tǒng)治理指南時,主要遵循該邏輯,如圖1所示。按照這種觀點,控制源最終位于DLT系統(tǒng)之外,并對其強制執(zhí)行治理機制。f)通過DLT系統(tǒng)進行的治理通過DLT系統(tǒng)進行的治理遵循算法治理的邏輯,或從技術-社會的角度對其進行治理。DLT系統(tǒng)等技術被視為行使治理的操作代理。在圖1中,一旦選擇并實施了共識機制,第Ⅰ級治理中伴隨共識機制的算法治理機制將會強制執(zhí)行或規(guī)定后續(xù)的決策和行為。按照這種觀點,控制源位于DLT系統(tǒng)內部,并通過其強制執(zhí)行治理機制。雖然人們普遍認為,隨著自主系統(tǒng)和機器間交互的出現(xiàn),通過DLT系統(tǒng)進行治理的概念(有時稱為算法治理)正變得越來越重要,但本文件采用了社會-技術視角,而不是技術-社會視角來看待DLT治理,認為控制源在于人類和法律實體,而非技術實體。明確DLT系統(tǒng)中的控制和權力來源是有效治理的關鍵要求。這一點尤其重要,因為在這些系統(tǒng)中,可能缺乏或減少了確保記錄交易完整性的決策權威。與更加傳統(tǒng)的中心化系統(tǒng)(例如:C級管理層、股東、董事會)相比,DLT系統(tǒng)的去中心化特性可能導致DLT參與者之間權利所有權的邊界不清晰。因此,那些積極參與治理DLT系統(tǒng)的人可以更多地關注他們作為用戶的需求,而不是作為這種去中心化系統(tǒng)相關權利所有者的需求。6.4決策權和決策制定決策是系統(tǒng)治理的一個關鍵屬性。DLT系統(tǒng)的治理涉及諸如分叉決策,決定系統(tǒng)賬本內運行的共識規(guī)則決策,以及關于不同參與者權利以及如何解決他們之間沖突的決策。DLT系統(tǒng)決策制定可以發(fā)生在賬本內或賬本外。當在賬本內時,決策受嵌入在DLT系統(tǒng)內的決策權和問責規(guī)則的約束,并據(jù)此執(zhí)行。當在賬本外時,決策和權力涉及隱性或顯性治理規(guī)則的應用,也包括決策權和權力。隱性賬本外治理的缺點是對參與者不透明,而優(yōu)點是更好地防范DLT系統(tǒng)中嵌入的賬本6GB/ZXXXXX—XXXX內治理規(guī)則可能無法預知的風險和挑戰(zhàn)。去中心化決策需要一些與去中心化系統(tǒng)不同的元素、技術和流程。與DLT系統(tǒng)相關的去中心化決策的一個關鍵特征是使用共識機制來達成決策。共識機制闡明了決策將被批準為DLT系統(tǒng)參與者可執(zhí)行性的標準。共識規(guī)則可以采取不同的形式。當體現(xiàn)在賬本內時,DLT系統(tǒng)本身提供了制定、定義、討論、投票和將決策付諸實施的機制。當在賬本外時,需要其他機制,如對特定參與者具有法律約束力的義務,使決策在DLT系統(tǒng)中具有約束力和可操作性。6.5問責機制為了提高當前和未來DLT系統(tǒng)用戶以及其他利益相關方的透明度,DLT系統(tǒng)中各方的責任和問責機制宜被明確聲明。這使參與者能夠理解權力如何分配和歸屬,并降低DLT用戶和其他利益相關方在評估分布式賬本系統(tǒng)運行相關風險時的不確定性。未明確分配決策問責和責任的DLT系統(tǒng)會面臨一些挑戰(zhàn),這些挑戰(zhàn)是正式合法決策權威機構可以避免的。在沒有明確聲明關鍵運營和治理決策的職責范圍的情況下,實際擁有控制權的各方往往缺乏正式的問責機制。這使得參與者在治理失敗的情況下,無法獲得有限的監(jiān)督和監(jiān)管約束,如包括濫用權力、挪用系統(tǒng)資產,或做出不符合大部分DLT系統(tǒng)用戶利益的決策。這給DLT系統(tǒng)的利益相關方帶來了挑戰(zhàn),使他們缺乏有效手段來對擁有隱性權利的決策者在DLT系統(tǒng)上問責,即使這些決策違反了DLT系統(tǒng)的規(guī)則、原則或慣例,或與DLT用戶和其他利益相關方的普遍利益相悖。基于DLT的智能合約和不依賴于特定個人或少數(shù)人群控制的組織也帶來了問責挑戰(zhàn)。這些能力的新性質給監(jiān)管機構和治理機構用于規(guī)范個人和組織活動以最小化系統(tǒng)風險的傳統(tǒng)控制手段提出了挑戰(zhàn)。此類控制通常施加于機構及其高管,監(jiān)管機構和治理機構通過發(fā)放經營許可證行以及指定法律制裁和懲罰的權力對他們的行為進行控制。當這些控制點被自治的、去中心化的治理實體所取代時,由此產生的問責空白就會挑戰(zhàn)監(jiān)管目標,因此有必要定義底層的協(xié)調實體,以支持在不確定性中的問責機制。分布式賬本系統(tǒng)中的智能合約允許未知方以降低欺詐風險和第三方執(zhí)行成本的方式進行交易。通過這種方式,智能合約提供了一種有效的手段來解決與交易對手風險相關的成本和不確定性。相反,智能合約也帶來了關鍵的治理挑戰(zhàn),這些挑戰(zhàn)表現(xiàn)在是否符合現(xiàn)有法律和監(jiān)管框架的不確定性,以及由于其非法和違規(guī)操作,在執(zhí)行法律裁決和制裁時面臨的挑戰(zhàn)。決定智能合約操作的邏輯嵌入在其源代碼中,這種代碼的可見性不足可能會進一步增加這些系統(tǒng)問責分配的不確定性。解決DLT系統(tǒng)挑戰(zhàn)的方法:a)DLT提供方宜讓利益相關方看到DLT系統(tǒng)的問責分配。理想情況下,這些問責在賬本內是可見的。或者在賬本外公有賬本內提及的問責分配情況。b)DLT提供方宜公開其關于DLT系統(tǒng)的報告,以供獨立審計。c)DLT提供方宜向監(jiān)管機構公開DLT軟件代碼和文檔,或包含可解決問題的機制。d)DLT系統(tǒng)宜為DLT參與者、提供商和更廣泛利益相關方建立爭議解決機制。6.6激勵與激勵機制DLT系統(tǒng)在如DLT用戶、DLT提供方和DLT開發(fā)者等利益相關方的群體之間存在激勵不對稱的風險。激勵不對稱可能導致系統(tǒng)被利用,并在DLT系統(tǒng)參與者之間造成經濟和其他方面的不平衡,最終導致系統(tǒng)失效。DLT系統(tǒng)激勵是指任何能夠影響參與者行為的系統(tǒng)設計機制。DLT系統(tǒng)激勵可以采取多種形式,從確保遵守法律義務到用戶功能或經濟激勵。激勵措施還可以采取鼓勵形式,讓DLT參與者和利益相關方不以某些特定方式行事,這將有助于阻止參與者采取可能對整個系統(tǒng)或特定類別的參與者的長期發(fā)展產7GB/ZXXXXX—XXXX生不利影響的行動。DLT激勵機制是指DLT系統(tǒng)中激勵的具體實施方式。賬本內的DLT激勵機制使用特定的DLT結構將激勵體現(xiàn)在DLT系統(tǒng)中,包括社會科學和計算機科學中的數(shù)學模型,如基于博弈論的獎勵機制作為經濟激勵,或支持驗證需求的激勵。大多數(shù)非許可DLT系統(tǒng)的關鍵特性是,它們使用賬本內激勵機制來激勵不同的利益相關方群體以預期的方式行事,從而保障系統(tǒng)運行的穩(wěn)定性和完整性。激勵機制也可以在賬本外發(fā)生。這些通常以傳統(tǒng)的激勵機構來體現(xiàn),如各方之間具有法律約束的商業(yè)義務、社區(qū)內的聲譽維護以及現(xiàn)有的經濟激勵。DLT系統(tǒng)本質上是分布式的。參與者關系的復雜性增加,增加了參與者之間利益和激勵不一致的內在風險。當參與者被激勵以特定的方式行事,以犧牲其他參與者和DLT系統(tǒng)的整體健康和穩(wěn)定為代價來獲得自身利益時,就會發(fā)生這種情況。如果這種不平衡在結構上是被允許的,或者在DLT系統(tǒng)中以其他方式固化,這可能導致一個參與者或某類參與者持續(xù)承擔成本,使他們考慮退出系統(tǒng)。如果DLT系統(tǒng)需要它們的存在才能繼續(xù)存在,這反而會危及系統(tǒng)本身的壽命。在設計系統(tǒng)激勵時,要重點考慮DLT系統(tǒng)的類型,因為不同類型的系統(tǒng)需要不同的激勵機制。在非許可的DLT系統(tǒng)中,參與者可匿名,也可免除任何正式關系或合同義務。這類系統(tǒng)通常依賴經濟激勵來達成共識,表現(xiàn)在對賬本內通證的依賴。另一方面,在許可DLT系統(tǒng)中,參與者是預先定義的,這意味著激勵通常可以通過傳統(tǒng)手段(例如法律合同、創(chuàng)造效率和業(yè)務收入)來創(chuàng)建。這意味著許可系統(tǒng)通常不需要本地賬本內的通證并且可以依靠各方之間現(xiàn)有的可執(zhí)行關系,通常表現(xiàn)為賬本外的法律強制關系。DLT系統(tǒng)的一些參與者可能會同時受到賬本內和賬本外的激勵。在這種情況下,宜向所有參與者公開賬本外的激勵,對信息較少的DLT參與者,以最大程度地減少信息不對稱的可能性,避免這種信息不對稱導致信息較少的DLT參與者遭受經濟損失。當賬本外的激勵機制不可能或不可取時(即去中心化的DLT系統(tǒng)),賬本外的激勵機制對實現(xiàn)DLT系統(tǒng)治理尤為重要。有效的賬本外激勵機制宜能夠實現(xiàn)DLT系統(tǒng)的持續(xù)良好治理,并于參與者和利益相關方之間存在的賬本外激勵機制協(xié)同。為了最大限度地降低激勵不一致的風險,DLT系統(tǒng)賬本內和賬本外的激勵宜公開透明。7不同類型DLT系統(tǒng)的治理7.1DLT系統(tǒng)類型從治理角度看,DLT系統(tǒng)可根據(jù)兩種訪問維度進行分類(見表2)。訪問系統(tǒng)進行交易驗證(通過運行DLT節(jié)點)涉及到驗證交易的能力以及安裝協(xié)議更新的控制權。在非許可的DLT系統(tǒng)中,所有實體都有權驗證交易。非許可指系統(tǒng)沒有明確的所有者,因此沒有實體有法律權力排除其他實體參與。在有許可的DLT系統(tǒng)中,只有預先注冊的實體才有權驗證交易。在此情況下,系統(tǒng)有一個所有者且該所有者可以決定訪問系統(tǒng)進行交易驗證的參與者名單。第二種訪問形式是指技術上的排他性。公有DLT系統(tǒng)允許所有實體讀取數(shù)據(jù)和提出新交易,從技術上無法阻止對系統(tǒng)的訪問。私有DLT系統(tǒng)則只允許由中央權威預先注冊的實體讀取數(shù)據(jù)和提出新交易。對于系統(tǒng)的擁有者來說,可在技術上決定是否允許某個實體訪問DLT系統(tǒng)[18]。表2DLT系統(tǒng)治理類型訪問對所有實體開放——運行及操作訪問對所有實體開放——運行及操作8GB/ZXXXXX—XXXX實體的訪問受到限制——運行及操作實體的訪問受到限制——運行及操作資源在技術上無法被限制使按照此種邏輯,非許可或許可是與某種所有權相關的維度,而公有或私有則涉及技術上的排他性。在治理方面,控制和權威的來源比技術上的排他性更重要。這就是為什么使用“非許可公有”、“許可公有”和“許可私有”,而非“公有非許可”或單純的“公有”的原因,因為后者不足以具體定義DLT系統(tǒng)的治理類型。這些治理類型會導致DLT系統(tǒng)內部治理方式的多樣性。從生命周期的角度看,所有此類系統(tǒng)仍將遵循7.1節(jié)中描述的生命周期,但不同治理類型下,系統(tǒng)中各個角色的責任和義務會有顯著變化。為了更好地理解從節(jié)點或驗證者以及DLT系統(tǒng)用戶的角度來看不同的治理類型,可見表3中有關生命周期操作階段功能的詳細說明。預先注冊的DLT預先注冊的DLT預先注冊的DLT預先注冊的DLT預先注冊的DLT點決策過程的去中心化說明需要有大量有影響力的決策者或投票者。抗壓韌性要求決策不能被少數(shù)人操控,這在非許可DLT系統(tǒng)中尤為重要,因為這需要大量活躍的投票者關注每個決策。在此種情況下,可擴展性意味著每輪投票中可能需要做出許多決策。決策過程的去中心化也意味著沒有中央控制機制的情況下運作,此種情況只存在于非許可DLT系統(tǒng)以及某些許可系統(tǒng)的運作階段。在缺乏中央控制機制和信任程序及權威作為代理時,在不確定環(huán)境中生成信任的情況下,宜避免權力的集中。若負責設計和實現(xiàn)DLT系統(tǒng)的治理機構采用集中管理的模式,則會像在許可系統(tǒng)中一樣形成權力集中。一旦系統(tǒng)發(fā)布,基于分布式代碼執(zhí)行的DLT系統(tǒng)便成為一個集中化搭建的系統(tǒng)。對多數(shù)人而言,DLT系統(tǒng)代表去中心化和權力分散,而在非許可公有系統(tǒng)中,另一個重要元素是包容性,即每個人都可以參與治理。在本文件中,DLT系統(tǒng)的治理結構分為三種不同類型的治理機制和治理生命周期,上述類型在圖2中進行了展示。9GB/ZXXXXX—XXXX圖2DLT系統(tǒng)治理分類作為圖2詳細說明的擴展內容,本文件討論了DLT系統(tǒng)的以下特征,這些特征取決于系統(tǒng)屬性(許可/非許可)和(私有/公有),并考慮到交易驗證以及系統(tǒng)的開放性或技術排他性。DLT有許多參與節(jié)點,這些節(jié)點在各種組織環(huán)境下運行,包括:a)非許可公有:節(jié)點由不同的參與方(個人或組織)操作,這些參與方不一定有共同利益,也不一定相互認識或被明確的權威機構認可。b)許可公有:節(jié)點由不同的實體(如金融或供應鏈行業(yè)的公司)運作,這些實體由一個共享的頂級組織(如行業(yè)協(xié)會)擁有或對其負責。c)許可私有:節(jié)點是由單個實體擁有和運作的獨立IT系統(tǒng)。傳統(tǒng)的IT治理方法可以直接應用于類型B(許可公有)和類型C(許可私有),盡管DLT系統(tǒng)的詳細策略、政策和管理系統(tǒng)可能與傳統(tǒng)系統(tǒng)(如云系統(tǒng)或企業(yè)IT)不同。責任和義務可以通過外包合同產生,而非通過單個組織或聯(lián)盟的所有權,但這種安排依然適用于傳統(tǒng)的IT治理方法。對于類型A(非許可公有在所有參與方共同認可一個共享的權威來源或治理機構的情況下,傳統(tǒng)的IT治理方法也可以有效。7.2許可DLT系統(tǒng)的治理在傳統(tǒng)的信息系統(tǒng)實現(xiàn)中,許可DLT系統(tǒng)的訪問規(guī)則由其所有者個體或群體定義。而在公有許可DLT系統(tǒng)中,盡管賬本可以是去中心化的,但其訪問規(guī)則是由一個中央權威機構、特權用戶組成的聯(lián)盟或委員會來定義的。用戶獲得DLT系統(tǒng)訪問權限的條件可能是該用戶滿足特定要求(例如,該用戶是一家特定行業(yè)的公司,通過第三方認證或遵守某些資本要求或者由其他用戶或權威機構共同選擇或選舉。這些訪問規(guī)則完全由建立階段的所有者個體或群體決定,所有者可以組織成任何現(xiàn)有的組織形式。在此類DLT系統(tǒng)中,未經所有者個體或群體的同意,用戶無法成為驗證節(jié)點甚至系統(tǒng)的閱讀者。系統(tǒng)背后的所有參與方都是已知的、可識別的,并且此類許可系統(tǒng)背后的組織通常為公司結構、基金會結構或類似于開源協(xié)作社區(qū)。GB/ZXXXXX—XXXX這也意味著系統(tǒng)中的問責相對容易執(zhí)行,并且此種DLT系統(tǒng)可以有條理地進行維護和升級。對于已知所有利益相關方身份的許可DLT系統(tǒng),宜明確實施決策權、問責和激勵機制。如前所述,許可私有DLT系統(tǒng)的治理類似于層級組織環(huán)境中的傳統(tǒng)IT治理方法。許可私有DLT系統(tǒng)的治理方式類似于組織內部或共享IT系統(tǒng)的常見治理方式。由于此類系統(tǒng)由明確的單一控制源擁有和運作,傳統(tǒng)的治理方法已經滿足要求,無需通過責任、問責和決策權的去中心化進行擴展。在許可公有DLT系統(tǒng)中,可以看到許可私有系統(tǒng)和非許可公有系統(tǒng)的元素。因此,這些系統(tǒng)通常被稱為聯(lián)盟或混合系統(tǒng)。當DLT用戶需要權限訪問系統(tǒng)時,會有一個特權機構或管理機構授予訪問權限。盡管該特權實體有權代表所有DLT用戶行事,但大多數(shù)許可公有系統(tǒng)具有分布式治理的元素。管理機構可以決定分配決策權、問責,并提供類似于非許可DLT系統(tǒng)的激勵機制。此類混合系統(tǒng)的主要區(qū)別是特權實體可以隨時撤銷分布式決策權。7.3非許可公有DLT系統(tǒng)的治理傳統(tǒng)的IT治理方法存在一個假設,即存在明確的所有權作為權威來源,治理機構可以在必要時行使權力并承擔責任。然而,在非許可公有DLT系統(tǒng)中,沒有單一的權威來源。在DLT系統(tǒng)治理的生命周期中,非許可公有DLT系統(tǒng)在治理方面會帶來獨特的挑戰(zhàn)。盡管治理的基礎在建立階段就已經奠定,但后續(xù)可能需要進行調整,這需要通過賬本內或賬本外的治理機制來組織軟分叉或硬分叉。在DLT系統(tǒng)的建立階段,系統(tǒng)架構師宜為預期目的設計治理系統(tǒng)。可由單一權威機構或由未來使用該系統(tǒng)的社區(qū)委員會完成。設計好的治理系統(tǒng)需要在啟動前或啟動時獲得社區(qū)的批準和采納。批準可以通過實際使用(用戶安裝錢包進行交易)或通過投票機制來合法化并正式驗證系統(tǒng)的實施,具體取決于所提議的流程。通常需要在核心開發(fā)者的提議與驗證者和全節(jié)點的采納之間找到平衡,同時考慮不同利益相關方的激勵。如果潛在用戶不采納或之后認為現(xiàn)有的治理結構不利,他們可以對系統(tǒng)進行分叉并創(chuàng)建新的DLT系統(tǒng)。因此,分叉是非許可公有DLT系統(tǒng)中處理爭議的一種治理工具。非許可公有DLT系統(tǒng)被許多群體視為能夠將參與式決策結構和決策過程引入商業(yè)模型,從而發(fā)展出一種新的經濟系統(tǒng)。這是因為DLT系統(tǒng)具有有效性、透明性和可審計性。這可能需要修訂或創(chuàng)建新的系統(tǒng)維護、風險框架以及最終的治理形式,可能還需要引入聲譽機制或其他激勵結構。由于非許可公有DLT應用和基礎設施高度關聯(lián),基礎設施的治理必須考慮其上構建的應用程序的治理。與傳統(tǒng)IT治理不同,在傳統(tǒng)IT系統(tǒng)中可以將應用程序下線、修改后再上線,而在非許可公有DLT系統(tǒng)中無法實現(xiàn)。因此,設計治理系統(tǒng)時,必須考慮非許可DLT系統(tǒng)上的應用類型。這些類型可以是直接交易型(如錢包)或按條件交易型(由可識別方通過智能合約進行)。根據(jù)不同類型,需要采用不同的治理方法。8系統(tǒng)生命周期治理和內容治理8.1DLT系統(tǒng)生命周期治理GB/ZXXXXX—XXXX圖3DLT系統(tǒng)生命周期8.1.1概述DLT系統(tǒng)的生命周期經歷建設、運行和終止三個核心階段,如圖3所示。DLT系統(tǒng)的治理貫穿全生命周期階段的問責、決策權和激勵。治理挑戰(zhàn)和需求的本質因DLT系統(tǒng)的生命周期不同而異。8.1.2建設階段治理在建設階段,涉及形成DLT系統(tǒng)的需求和設計,啟動和評估試點項目,推進商業(yè)化實施及開展研究。在這一階段,設計和實現(xiàn)了關鍵的治理功能和基礎設施。在DLT系統(tǒng)建設階段的治理包括:a)治理機構或架構的性質和類型;b)DLT系統(tǒng)和非DLT系統(tǒng)的互操作性;c)遵守法律和監(jiān)管框架;d)任何DLT系統(tǒng)基本規(guī)則的存在和形式;e)爭議解決機制和程序;f)賬本外治理的范圍和作用;g)管理運營的程序和規(guī)則;h)DLT系統(tǒng)的終止。DLT系統(tǒng)建設階段的治理決策是由問責方在系統(tǒng)建設過程中隱性的或顯性的提出并制定的。宜澄清治理決策權的賦予方,以減少系統(tǒng)建設階段的不確定性。DLT系統(tǒng)建設階段的關鍵決策,將定義隨后部署的DLT系統(tǒng)的治理方式。一旦這些決策由問責方做出,DLT系統(tǒng)建立階段的下一階段治理決策就與DLT系統(tǒng)的設計及支持DLT系統(tǒng)運行所需的基礎設施有關。建設階段的治理決策將影響系統(tǒng)運行階段和終止階段的治理,決定系統(tǒng)的運行方式、運行原則以及系統(tǒng)更新規(guī)則。8.1.3運行階段治理當DLT系統(tǒng)建立后,它就進入了其生命周期的運營階段。核心目的和功能是根據(jù)其設計進行執(zhí)行,并根據(jù)在建立過程中設定的決策權、問責和激勵機制進行管理。DLT系統(tǒng)的治理在運營階段負責幾個關GB/ZXXXXX—XXXX鍵功能,包括DLT系統(tǒng)中參與方的參與權利以及與之相關的合約規(guī)則等。所有DLT系統(tǒng)都宜在法律和監(jiān)管框架的范圍內運行。DLT系統(tǒng)可以提供指南和賬本內的管理機制來管理運營。DLT用戶之間以及與賬本外實體之間的交易,由交易規(guī)則和交易功能決定。宜確定適用于給定用戶特定情境的規(guī)則和功能。此外,宜對交易進行驗證,以確保在DLT系統(tǒng)上執(zhí)行的交易的有效認定,并且可以被其他DLT用戶信賴為真實且是對現(xiàn)實的正確表達。在DLT系統(tǒng)的背景下,這將包括驗證、操作共識機制、共識管理和治理決策的執(zhí)行。DLT系統(tǒng)的管理和監(jiān)督在其運行過程中進行。這涵蓋了DLT系統(tǒng)持續(xù)運行所涉及的操作。在監(jiān)督方面,DLT系統(tǒng)在更廣泛的賬本外環(huán)境中運行。DLT系統(tǒng)可以為監(jiān)督和管理功能提供賬本內支持,并具有額外的賬本外監(jiān)督功能。在DLT系統(tǒng)建設階段,宜設計DLT系統(tǒng)的架構和運營方式,以及與其最終終止相關的治理機制。在審查DLT系統(tǒng)的持續(xù)運營過程中,宜明確治理機制將如何運作,包括此類決策權的責任歸屬,以及它們將如何應用和實施。8.1.4終止階段治理當DLT系統(tǒng)進入終止階段時,治理決策主要包括決定DLT系統(tǒng)的數(shù)據(jù)或資產如何被轉移、銷毀或以其他方式處置,以及參與方的權利如何得到清算。終止階段宜明確支持DLT系統(tǒng)終止時與外部環(huán)境的交互,否則DLT系統(tǒng)的終止將由賬本外的治理條件和因素所決定。8.2DLT系統(tǒng)環(huán)境治理8.2.1DLT治理概覽不同的DLT治理如圖4所示。8.2.2數(shù)據(jù)數(shù)據(jù)治理包括與DLT系統(tǒng)全生命周期各階段相一致、相適應的數(shù)據(jù)治理的方方面面。在DLT系統(tǒng)生命周期的創(chuàng)建階段,數(shù)據(jù)的治理被定義。這包括在DLT系統(tǒng)整個生命周期中,如何及哪些類型的數(shù)據(jù)會被定義、管理以及銷毀,同時也界定了當與其他DLT系統(tǒng)及非DLT系統(tǒng)共存與交互時的數(shù)據(jù)治理。在DLT系統(tǒng)的運營生命周期階段,數(shù)據(jù)被采集、存儲、匯報、融入決策和分發(fā)。DLT系統(tǒng)的運營宜GB/ZXXXXX—XXXX預測在每個上述功能中的每一種情況下數(shù)據(jù)將如何被治理。在DLT系統(tǒng)生命周期的終止階段,DLT系統(tǒng)的治理宜預測并指導數(shù)據(jù)的處置,包括其歸檔或銷毀。8.2.3協(xié)議在DLT系統(tǒng)的創(chuàng)建階段,DLT系統(tǒng)的協(xié)議宜被定義,這包括在DLT系統(tǒng)整個生命周期中,如何定義及管理DLT交易。同樣,在創(chuàng)建階段的DLT治理協(xié)議也將界定該DLT系統(tǒng)協(xié)議與其他DLT系統(tǒng)及非DLT系統(tǒng)之間的協(xié)同操作性。在DLT系統(tǒng)的運營生命周期階段,DLT的治理宜定義這些協(xié)議如何運行及管控它們變更的規(guī)則。在DLT系統(tǒng)的終止階段,DLT系統(tǒng)的治理宜預測并指導DLT系統(tǒng)的協(xié)議如何運作。這包括終止將被如何決定、執(zhí)行和驗證的指導。8.2.4應用程序在DLT系統(tǒng)的創(chuàng)建階段,DLT系統(tǒng)應用的治理宜被定義。這包括去中心化應用程序的實現(xiàn)方式、訪問權限以及責任。如果應用程序被其他DLT系統(tǒng)及非DLT系統(tǒng)使用,宜為此確定規(guī)定訪問權限和責任。在DLT系統(tǒng)的運營生命周期階段,DLT的治理宜界定DLT系統(tǒng)中各應用程序如何交互,以及為了支持應用程序的持續(xù)使用,哪些變更和維護的應用治理規(guī)則是必要的。在DLT系統(tǒng)的終止階段,DLT治理宜預測并指導應用程序的如何處置、銷毀或轉移應用程序。8.2.5組織機構在DLT系統(tǒng)創(chuàng)建過程中,DLT系統(tǒng)的組織機構治理宜定義DLT系統(tǒng)如何與特定的組織機構的治理在功能和操作上共存和協(xié)作。這包括DLT系統(tǒng)的治理機制和結構如何關聯(lián)與現(xiàn)有組織機構治理職能,比如由董事會和執(zhí)行管理層履行宜履行的。如果不存在這樣的關系,也宜明確聲明。在DLT系統(tǒng)的運營生命周期階段,在機構中的DLT系統(tǒng)治理宜定義其DLT系統(tǒng)的治理功能如何與現(xiàn)有的組織治理功能關聯(lián)和互操作,包括DLT系統(tǒng)的決策權、責任及激勵措施如何與現(xiàn)有相關的組織機構一起運作。在DLT系統(tǒng)的終止階段,DLT系統(tǒng)治理宜定義在系統(tǒng)終止過程中,如何與現(xiàn)有的組織機構治理功能協(xié)同工作,包括DLT系統(tǒng)的決策權、責任及激勵措施如何與各組織機構的治理相協(xié)作。9治理框架中的角色責任、問責、決策權和激勵機制可以歸因于DLT系統(tǒng)中的不同角色,無論是在賬本內還是賬本外環(huán)境中。鑒于DLT系統(tǒng)有許多不同的設置,因此沒有一種單一的正確方法將這些屬性分配給系統(tǒng)中的角色。角色之間可能存在冗余。表4中的治理框架中所展示的角色可以是一個單獨的個人/實體,或者多個合作以完成該角色功能的個人或實體的組合。并非所有角色都適用于所有的DLT類型。通常,DLT用戶通過一個應用程序或與API交互的賬本外代碼的方式來使用系統(tǒng),而不是直接與DLT節(jié)點交互。對于那些使用自動化系統(tǒng),而不是自然人用戶的DLT用戶來說更是如此,它們與DLT節(jié)點的交互往往是通過DLT應用程序提供的API來實現(xiàn)的。表4治理框架中的角色實現(xiàn)DTL系統(tǒng)的長期商業(yè)模1.設定并維護與以下責任和問責相關的策略:值GB/ZXXXXX—XXXX式的可行性和連續(xù)性(包含經濟、道德、法律和財務方面)。b)許可d)決策規(guī)則和沖突解決(如:投票機制).賬本內和賬本外的決策安排和協(xié)議.社區(qū)領袖的角色和權力.管理投票和分叉e)所有職位和角色的激勵、責任和問責2.與外部利益相關方溝通(如適用)4.與DLT節(jié)點運營者合作以確保監(jiān)控和治理得到執(zhí)行。6.管理行業(yè)聯(lián)盟,管理單一企業(yè)的贊助關系DLT審計方收集并驗證1.設定審計活動的策略,涵蓋性能和DLT審計方確保DLT系統(tǒng)中政DLT系統(tǒng)遵守策策審計的證據(jù),2.確保DLT組件審計和報告工略、治理和法規(guī)。向相關方(例如他們可以與DLT管理方、管理員運營方、監(jiān)管方、等)發(fā)出偏差信5.提出解決方案,支持執(zhí)行糾正措施管理方等合作。DLT管理方DLT管理方執(zhí)行特定的管理活動(特別是針對安全配置)。確保DLT系統(tǒng)完全的完整性。4.管理對DLT系統(tǒng)的基于角5.制定和管理隱私和安全策略及協(xié)議勵DLT開發(fā)者對DLT開發(fā)者,有兩個子角色——DLT應用開發(fā)者和DLT系統(tǒng)開發(fā)者。確保DLT系統(tǒng)的連續(xù)性,來持續(xù)地適應系統(tǒng)對技術和業(yè)務的需求。1.管理社區(qū)對開發(fā)策略和規(guī)5.設計、創(chuàng)建、集成和維護專用設備勵GB/ZXXXXX—XXXX8.如果適用:管理公司內部開發(fā)團隊DLT提供方DLT提供方指在DLT系統(tǒng)和DLT網絡中擁有并運營一個或多個節(jié)點的角色。子角色包括:DLT系統(tǒng)節(jié)點運營方、DLT節(jié)點運營方和DLT應用運營方。確保運行DLT系統(tǒng)組件的虛擬和物理元素的業(yè)務連續(xù)性和所需的技術性能。護6.確定分片、輕節(jié)點、其他配置7.提出和/或確定DLT配置的勵DLT用戶通過非欺詐性1.使用DLT系統(tǒng)提供的服務可以代表個人、組的方式來確保織、設備或系統(tǒng)。DLT系統(tǒng)的連3.使用DLT用戶應用程序勵續(xù)性,從而加強治理規(guī)則及其4.安裝用于與DLT系統(tǒng)交互的客戶應用。6.觀察并遵守規(guī)則,不參與欺詐行為10治理工具10.1概述DLT系統(tǒng)治理通過DLT協(xié)議內部的工具(賬本內治理工具)、DLT協(xié)議外部的治理工具(賬本外治理工具)和賬本內賬本外交互來實現(xiàn)。為實現(xiàn)透明治理和問責,具體系統(tǒng)的治理策略宜確定并記錄工具信息、工具交互情況。賬本內治理工具可寫在DLT協(xié)議中,也可由智能合約執(zhí)行。賬本內事件和賬本外事件均可激活治理工具。賬本內治理工具根據(jù)其編程邏輯運行,執(zhí)行具體操作,但不對操作后果負責。賬本外治理工具在DLT協(xié)議之外應用。通常,賬本外治理工具使DLT協(xié)議與法人實體連接,確定決策權、問責機制和激勵結構。法人實體應用的賬本外治理工具宜符合相關監(jiān)管框架和法律規(guī)定。賬本外治理工具宜盡量和賬本內治理工具保持一致,互為補充。可由正式協(xié)議明確約定DLT系統(tǒng)中部署的治理工具或工具類型。通常在系統(tǒng)建設階段確定DLT系統(tǒng)治理,如選擇共識機制,約定全生命周期內開發(fā)和維護DLT協(xié)議的規(guī)則和流程等。根據(jù)ISO/IEC38500,DLT利益相關方可通過以下三種方式參與DLT系統(tǒng)治理:a)評估DLT系統(tǒng)當前和未來的使用情況,識別義務和風險;b)親自制定、實施相關策略、流程和內控框架,確保合規(guī)使用DLT系統(tǒng),降低重大風險;c)監(jiān)控策略、流程和執(zhí)行是否符合內控框架,以降低風險,確保合規(guī)。有效、高效、規(guī)范地建立、運營和終止DLT系統(tǒng)的責任仍由治理機構承擔,不宜委托給其他機構。10.2賬本內及賬本外治理工具GB/ZXXXXX—XXXX10.2.1概述賬本內和賬本外兩種治理工具皆可部署于DLT系統(tǒng)以達成治理目標。工具可根據(jù)表1列出的維度進行分類。表5從問責性、責任和決策權、激勵等三個角度列出賬本內和賬本外治理工具的特征。這些特征是DLT用戶有效設計DLT系統(tǒng)所需的典型屬性。表5內容并非詳盡,可能有重疊。為實現(xiàn)預期目標,DLT系統(tǒng)可以組合部署表中多種工具,也可部署表中未列出的工具。宜記錄所用工具便于相關方知曉DLT系統(tǒng)的治理情況。表5賬本內和賬本外治理工具——身份鑒別——存取控制——確認——審計——數(shù)據(jù)保護——認證——基本屬性——處理權——訪問規(guī)則——范圍——共識協(xié)議運營——過程執(zhí)行模型——交易過程——靈活性——互操作性——安全性——運營一致性——數(shù)據(jù)驗證——訪問策略——應用訪問——抵制審查制度——碎片化——身份暴露——社區(qū)規(guī)則——決策過程——可擴展性——實現(xiàn)——共識協(xié)議選擇——驗證——性能——成本效益——可轉移性10.2.2賬本內治理工具賬本內治理由DLT系統(tǒng)的內在設計決定,該設計包含制定、更改和執(zhí)行系統(tǒng)運行規(guī)則的整套機制。治理透明度顯著增強DLT用戶和其他利益相關方對系統(tǒng)的信任。賬本內治理的價值之一是提升治理機制及其更改流程和更改歷史等的透明度。此外,賬本內治理支持多司法管轄區(qū)部署。例如,共識機制就是一種賬本內治理工具,一個具體決策需達到共識協(xié)議要求的最低法定人數(shù)才能獲得批準。賬本內治理可能導致無法達成共識,因此系統(tǒng)可支持分叉,有分叉時宜遵循適當流程確保參與方將賬本穩(wěn)妥拆分為兩個單獨的DLT系統(tǒng)。10.2.3賬本外治理工具賬本外治理取決于DLT系統(tǒng)外部的機制。因需要遵守法律和監(jiān)管框架、要求、行業(yè)行為規(guī)范,所以所有DLT系統(tǒng)都與賬本外治理有所交互。賬本外治理是為了支持賬本內交易達成預期目的。例如,治理包括支持防篡改和交易驗證的能力,確保賬本內賬本外信息完整。賬本外治理宜符合ISO/IEC38500、ISO/IEC27014和ISO37001中規(guī)定的原則。借助賬本外治理,利益相關方可以通過投票等機制達成共識。10.3實現(xiàn)治理機制的相關考慮10.3.1適應性DLT系統(tǒng)在運行過程中對變化的適應能力決定其可用性。DLT系統(tǒng)治理宜能對變更達成共識,隨后執(zhí)行變更。宜采用諸如ISO9001或ISO/IEC20000-1規(guī)定的流程來管理變更。GB/ZXXXXX—XXXX對于許可公有DLT系統(tǒng),網絡中的DLT治理者負責治理變更,治理機構組織實施系統(tǒng)變更。許可私有DLT系統(tǒng)不需要專門的共識機制才能決定變更,有需要時利益相關方就能實施變更。在非許可公有DLT系統(tǒng)中,宜實現(xiàn)投票之類賬本內治理機制以發(fā)起、完善和執(zhí)行變更。如果利益相關方間無法達成共識,可以選擇分叉DLT系統(tǒng),有軟、硬兩種分叉方法。10.3.2風險在DLT系統(tǒng)中,多數(shù)情況下參與者按照諸如ISO31000、ISO31022和ISO/IEC27005中所概述的現(xiàn)有風險管理框架即可評估風險。然而,DLT系統(tǒng)還面臨分布式或去中心化系統(tǒng)治理特有的風險。多方有效治理,DLT系統(tǒng)才能正常運行,決策權、問責或激勵機制的錯配將給各個參與方和DLT系統(tǒng)本身帶來巨大的風險。許可和非許可系統(tǒng)都如此,但風險的根源會有所差異,取決于系統(tǒng)類型和治理結構。在沒有中心治理機構的非許可系統(tǒng)中,風險的緩解依賴于多樣化的、可能匿名的個人群體。不同DLT系統(tǒng)的風險緩解,由賬本內機制實現(xiàn),或者在賬本外發(fā)生。參與方之間的激勵不一致可能會導致意想不到的后果。此外,非許可系統(tǒng)的改進通常是開放式的,如果沒有賬本內機制的支持,決策就會很繁瑣,阻礙問題的有效解決。為降低此類風險,宜引入有效機制在非許可系統(tǒng)全生命周期保持共同的激勵。在許可DLT系統(tǒng)中,合約框架等傳統(tǒng)治理機制基本能實現(xiàn)高效多方治理,但依然會有激勵沖突。比如系統(tǒng)中占據(jù)了主導地位的參與方可能會利用其地位追逐私利。特別是當DLT系統(tǒng)由競爭者共享時,商業(yè)競爭會導致決策和系統(tǒng)改進效率低下。為了避免這種情況,許可系統(tǒng)宜從建立階段就考慮并引入共同的基礎和共同的激勵措施,并在系統(tǒng)全生命周期加以維護。諸如構建商業(yè)和組織結構時要考慮盡量整合所有潛在系統(tǒng)參與方利益。DLT系統(tǒng)整體風險評估的難度取決于系統(tǒng)類型。對于許可DLT系統(tǒng),其利益相關方經批準才能加入,身份明確,風險評估較為容易。因此宜在生命周期的不同階段實施例行風險評估。對于非許可公有DLT系統(tǒng),其利益相關方身份不明,風險評估通常較為復雜。在進行風險評估時,宜考慮以下一般風險領域:——行為風險(例如:平等對待客戶、客戶投訴、員工行為);——公開風險(例如:數(shù)據(jù)隱私、身份盜竊、內幕交易、市場操縱——網絡風險(例如:數(shù)據(jù)篡改、暴力攻擊、雙花、DDoS攻擊);——技術風險(例如:硬件、中間件和軟件兼容性、升級路徑、設備兼容性);——運營風險(例如:缺乏規(guī)范、關鍵人員風險、玩忽職守——競爭風險(例如:串通、反競爭行為、信息共享、壟斷——知識產權風險(例如:侵犯版權或專利、濫用開源材料或違反許可證,喪失、盜竊或濫用知識產權);——責任風險(例如:服務的欺詐、盜竊、喪失或濫用導致賠償,軟件未歸因、濫用、錯誤的責任,治理、運營或其他變更的責任);——金融犯罪風險(例如:未充分進行身份驗證和制裁、用戶甄別和交易監(jiān)控(反洗錢和制裁)、欺詐預防);——監(jiān)管風險(例如:未遵守監(jiān)管規(guī)定、監(jiān)管變更、投資者或客戶保護)。DLT系統(tǒng)中的一個利益相關方可能只需要處理其中的一部分風險,例如用戶只需要評估和處理技術風險。DLT系統(tǒng)的利益相關方宜在系統(tǒng)全生命周期中遵守合規(guī)要求。這對非許可公有DLT系統(tǒng)帶來一個問題:需要厘清合規(guī)要求中哪些由利益相關方滿足,哪些由系統(tǒng)自身滿足。在許可的公有或私有DLT系統(tǒng)中,治理機構宜選擇需滿足的合規(guī)要求,并在整個系統(tǒng)中落實。GB/ZXXXXX—XXXX10.3.3隱私DLT系統(tǒng)治理機構宜決定DLT系統(tǒng)如何存儲、管理個人身份信息,包括考慮賬本內外機制。治理機構宜關注隱私原則,比如隱私框架中對治理有影響的部分,以ISO/IEC29100、ISO/

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論