作者：文檔 / 來源：PlatON

概述

區塊鏈治理機制是指區塊鏈生態中利益相關者對決策達成一致的一套決策規則和行動標準。其目的是讓去中心化的網絡隨著時間的推移能不斷迭代發展。在區塊鏈中，一些重要的技術，如共識機制、擴展性、安全性等，都可通過治理機制提供合理的激勵方式得到更好的解決。完整的區塊鏈治理機制應該是區塊鏈技術、經濟學和政治學的結合產物，包含權利分配、經濟激勵和技術實現。區塊鏈的生態結構由開發者、礦工和用戶構成，治理中各個角色需要發揮各自的價值，承擔相應責任并獲得對應的收益。治理的意義在于減少社區分裂和混亂的發生，幫助社區提高項目更新迭代效率，提高社區成員參與的積極性。

治理現狀分析

目前治理從大的模式上分為鏈下治理和鏈上治理。鏈下治理由核心開發者控制，節點通過安裝軟件來發出決定信號，將全部責任交給那些運行完整節點的人，靈活性較高，但需要更高的社會協調成本，且缺乏合理的激勵機制，限制了新開發者的加入。而鏈上管理有一套明確的治理流程，通過鏈上提案投票機制的形式強制升級，將決策權交給利益相關者。

鏈下治理的代表公鏈如比特幣和以太坊，其協議的升級主要是由核心開發者進行運營，普通礦工和用戶群體選擇權利缺失，因此參與度低，公民基礎薄弱。意識到鏈下治理的缺點，一些公鏈開始紛紛推出自己的鏈上治理機制，將社區的決策數字化，大大降低了利益相關者的協調成本。鏈上治理機制常見的權利分配方式往往是直接民主和間接民主的選擇與平衡。

直接民主是由持幣者直接參與制定規則，采用一代幣一票的方式，去中心化程度較高，如Decred和Tezos等。在直接民主中往往存在投票率、專業性、代幣集中等問題。而間接民主即代議制，通過不同方式選出代表人，依靠代表人行使權利，如EOS超級節點、Polkadot中的理事會和DFINITY中的“跟隨投票”機制等。間接民主需要考慮到治理結構的設計、權利分配和激勵等問題。

PlatON治理機制

在我們看來，決策權應屬于“利益相關者”，即權利屬于人民。但進行全民公投需考慮到實施成本以及投票率、專業性、治理效率等問題，因此公投不應該是治理常態，更應該是重大分歧情況下的治理方式。在我們的PPoS設計中，其備選節點的產生本身就是一種選舉，且節點的利益和公鏈生態的興衰息息相關，理應承擔更多的治理責任，擁有更多的治理權利。因此，在PlatON治理中，我們采用了直接民主和間接民主結合的模式，其核心原則是：常態下由備選節點投票治理，即間接民主；重大分歧下由社區公開投票治理，即直接民主。

參與角色

• 備選節點 節點通過質押一定的Token成為候選人，其他用戶可將自己的Token委托給候選人，系統根據候選人的總權益（質押+委托）進行排名，排名前201的候選人被選舉成為備選節點。

• 持幣人 所有Token代幣持有者。

• 核心開發者 共同建設PlatON公鏈及社區的核心開發者。

權利分配

• 備選節點
  • 發起提案
  • 對公投提案投票
  • 對非公投提案投票
  • 對提案進行附議
• 持幣人
  • 發起公投提案
  • 對公投提案投票
  • 對提案進行附議
• 開發者
  • github代碼控制
  • 提案審核
  • 提案實現

提案分類

• 公投提案 公投提案的發生是在存在爭議性比較大的場景下，任意持幣人都可以發起公投提案，需要進行全民公投產生結果，場景如下：
  • 修改基本法
  • 進行重大的分叉，類似The Dao的分叉
  • 終止鏈的運行
• 非公投提案 非公投提案即普通提案，由備選節點投票產生結果，提案類型可分為以下類型：
  • 文本提案：對于無需實施的決策都可以用文本提案發起
  • 軟件升級提案：用來在鏈上發起升級投票，達到平滑升級的目的
  • 參數修改提案：用來對系統參數等可治理的參數進行修改
  • 賬戶提案： 用來凍結或解凍賬戶（包括合約）
  • 激勵提案： 用來分配治理基金賬戶余額
  • 取消提案： 用來取消鏈上正在投票中的軟件升級提案

治理流程

1) 發起提案

公投提案可以由任何人發起，非公投提案由備選節點發起。每個提案都應該有與之對應的文本說明，該文本說明存儲于github上的PIP倉庫，由核心開發者管理，類似EIP。

為控制垃圾提案，所有類型的提案的發起都需要支付一筆提案手續費，作為提案的成本。

2) 提案篩選

• 公投提案：由于公投提案并非是常態，因此鏈上可以同時發起多個公投提案，這些提案將根據保證金從高到低進行排序，每個月選擇出保證金最高的提案進入投票階段。

• 非公投提案：發起提案成功即進入投票期，可多提案并行投票。

3) 提案投票

• 公投提案

  公投提案的核心的權益投票。投票將持續兩周，有三種投票選項，分別為：“支持”、“反對”和“棄權”。只有參與質押和委托的代幣才能進行投票。投票形式采用“備選節點代投+個人投票覆蓋”的模式。即：備選節點投票權重是自有質押代幣和接受委托代幣數量之和，若委托人與該備選節點持不同意見，則該委托人可自行投票，其投票權重為委托數量，該權重對應的投票選項將被覆蓋。所有的投票將會鎖定代幣到投票結束。

  為緩解由于多數代幣被少數節點控制而導致的投票中心化問題，參與投票的備選節點數量應該足夠多，若多數備選節點不同意或沒有參與投票，該提案仍然不會通過。

• 非公投提案

  非公投提案的投票的核心是備選節點投票。只要是在該提案投票周期內當選成為備選節點的節點都能進行投票。投票周期一般為兩周，軟件升級提案的投票周期可根據情況由提案發起人決定。投票形式采用備選節點一人一票制度，投票后將鎖定備選節點自有質押代幣到投票結束。除軟件升級提案外，其他類型的投票有三種投票選項，分別為：“是”、“否”、“棄權”。為了簡化投票流程，軟件升級提案沒有顯性的選項選擇，各備選節點可通過是否升級本地節點來表明自己的投票立場，具體可以參考升級機制。

4) 投票結果計算

• 公投提案： 公投提案結果計算維度有以下三個:

  • 備選節點支持率：投票支持的備選節點人數與可投票的備選節點總人數的比值
  • Token支持率：支持的Token數量與總參與投票的Token數量的比值
  • Token參與率：總參與投票的Token數量與總質押的Token數量的比值

  當同時滿足：備選節點支持率>P%，Token支持率>Q%且Token參與率>K%時，該提案投票通過，否則該提案投票未通過。

• 非公投提案：非公投提案的計算維度有以下兩個；

  • 備選節點支持率：投票支持的備選節點人數與可投票的備選節點總人數的比
  • 備選節點參與率：投票備選節點人數與總可投票備選節點人數的比值

  當同時滿足：備選節點支持率>M%，備選節點參與率>N%時，該提案投票通過，否則該提案投票未通過。

  不同類型提案對應的支持率和參與率如下:

類型	參與率	支持率
文本提案	>50%	>=66.7%
取消提案	>50%	>=66.7%
參數提案	>50%	>=66.7%
升級提案	=100%	>=66.7%

升級機制

升級機制是網絡能夠不斷迭代完善的保證。對于區塊鏈系統運行過程中可能出現的不同情況，我們應該提供有針對性的升級方式，主要有以下四種情況：

• 優化升級：此類升級是對當前鏈版本的功能優化。各節點可以根據情況決定是否升級，無論升級與否不會對共識造成影響。
• 投票升級：此類別的升級為添加了新功能，或者對補丁進行修復后影響到共識機制。該升級需要在鏈上發起軟件升級提案，通過投票結果來決定是否實施升級，在不中斷網絡的情況下完成平滑升級。后面會重點講解。
• 修復升級：當節點因版本低或者異常交易導致不能正常參與共識時，備選節點可以通過安裝新版本軟件來恢復參與網絡共識。
• 快照升級：當區塊鏈系統遇到重大異常，導致整條鏈無法正常出塊時，可基于之前的正常網絡狀態生成快照，然后基于該快照恢復網絡。

下面我們將重點說明鏈上投票升級機制。

1) 發起升級提案

升級提案只能由備選節點發起，發起時需要支付一筆高于普通交易的提案手續費，軟件升級提案參數中需要提供以下參數：

• 升級的目的版本號。版本號有三位數字組成，如1.2.0，升級目的版本號前兩位需大于當前鏈版本號前兩位。
• github對升級信息的描述的文件的ID，即PIP-ID。該ID必須唯一
• 升級提案投票的共識輪數N。該參數將用來計算投票截止塊高，即在當前共識輪開始第N個共識輪的第230個塊截止投票。

鏈上只能存在一個處理中的軟件升級提案，即當鏈上已經存在處于投票中的軟件升級提案或參數提案時，不能再發起另外一個軟件升級提案。此時遇到特殊原因或者緊急情況，需要立即發起一個新的軟件升級提案，則可以發起一個取消提案來取消該軟件升級提案。

取消提案說明： 只有當鏈上存在正在投票中的升級提案時，才能發起取消提案。取消提案的交易需要有以下參數，

• 被取消的升級提案交易hash
• github對升級信息的描述的文件的ID，即PIP-ID。該ID必須唯一
• 取消提案投票的共識輪數。由該參數計算出來的投票截止塊高不能超過被取消的升級提案投票截止塊高

2) 升級提案投票

軟件升級提案發起成功之后，則進入投票階段。只能由備選節點參與投票，即投票交易只能由節點質押賬戶發起，投票前需升級本地節點，以一人一票的方式計票。

我們對于軟件升級提案的投票交易中并未設置"支持"、"反對"、"棄權"的投票選項，而是通過節點行為來表達自己的立場，如下：

• 支持者：可將本地節點版本更新到提案升級中的版本后，對升級提案發起投票；
• 中立者：可以選擇升級節點，但不投票，而發起版本聲明交易來聲明本節點已經升級，這樣不論該提案通過與否都可以正常參與共識；
• 反對者：則無需升級本地節點，無需投票。

升級提案投票交易需要提供以下參數：

• 發起提案交易的Hash
• 節點的真實版本號。該版本號需要和投票中的升級目的版本號一致，才能投票成功。
• 節點簽名。該簽名是節點私鑰對節點版本號的簽名。

投票期間雖然節點已經升級，但是當前運行的邏輯還是舊版本的邏輯。等到實施完成后才會切換到新版本的邏輯。

3) 升級提案投票結果統計

在投票截止塊高統計對升級提案的投票結果，若投票周期內投票情況如上圖所示：

• 結算周期1內總備選節點數： P1P1，備選節點發起升級投票數量為M1M1

• 結算周期2內總備選節點數： P2P2，備選節點發起升級投票數量為M2M2

• 結算周期N內總備選節點數： PnPn，備選節點發起升級投票數量為MnMn

則最后支持率：SR=100∑ni=1Pi−P1∩P2∩...∩PnSR=100∑i=1nPi−P1∩P2∩...∩Pn

若SR≥66.7SR≥66.7 ，則提案投票通過，進入實施階段。

4) 升級提案實施

由于VRF選取備選節點具有隨機性，且為了不影響共識，因此我們在實施升級時，需要保證某一個共識輪中的驗證節點都是已經升級的節點。

因此，在提案投票截止塊高時，該提案的支持率達到66.7%，則在下一個共識輪第一個塊開始實施升級，且不再選擇未升級的節點參與共識。在當前結算周期中，被淘汰的未升級節點只是不會被VRF選中參與共識,但仍然享受當前結算周期的質押收益。

5) 版本聲明

由于不同版本之間可能存在數據不兼容的情況，為避免因版本問題造成共識失敗，對鏈上的節點版本應該進行控制，因此，我們引入了版本聲明。節點通過發起版本聲明來表明自己節點版本和當前鏈版本或軟件升級提案投票中的目的版本號一致，才能有機會在升級前后正常參與共識。

只有候選節點和驗證節點才可以發起版本聲明。新加入的節點需要先成為候選人后才能發起版本聲明。各個階段版本聲明條件如下：

當節點版本和鏈上版本不一致（版本號前兩位不同）時，該節點不會被選入參與共識，即使質押很高，此時節點可以通過發起版本聲明交易來聲明自己節點與鏈版本一致，才能在后續結算周期中正常參與共識。當鏈上存在正在投票中的軟件升級提案時，可以發起和升級版本一致的版本聲明，版本聲明不代表投票，在升級提案投票通過后，聲明了與升級目的版本號一致的節點即使沒有投票也可以正常參與共識。

快速升級

在鏈上發起升級投票本是一件嚴肅的事情，理論上不應該存在撤銷提案的可能，所有的結果都應該交給備選節點投票決定。但我們的只允許鏈上存在一個投票中的軟件升級提案，因此當出現緊急情況時需要快速升級時，若鏈上存在未處理完成的提案，會直接影響緊急情況的處理速度。由此我們引入取消提案，該提案由備選節點發起，投票周期可自行確定，但必須在被取消提案投票周期內。通過發起取消提案和各節點的快速響應，即可在短時間取消正在投票中的軟件升級提案，從而快速實施緊急方案。只有當鏈上存在正在投票中的升級提案時，才能發起取消提案。取消提案一旦發起則必須執行，因此我們提倡只在緊急情況使用取消提案。

取消提案的交易需要有以下參數：

• 被取消的升級提案交易hash
• github對升級信息的描述的文件的ID，即PIP-ID。該ID必須唯一。
• 取消提案投票的共識輪數。（由該參數計算出來的投票截止塊高不能超過被取消的升級提案投票截止塊高）

參數治理

備選節點可以通過發起參數治理提案來修改部分系統參數。為避免參數提案和升級提案交叉實施引發問題，因此，當鏈上存在投票中的升級提案或者參數提案，不允許在發起新的參數修改提案。 參數提案投票周期為兩周。截止當前，我們支持的治理參數如下：

• staking模塊

Key	描述	范圍
stakeThreshold	成為備選節點候選人最低的質押Token數	[10w,1000w] LAT
operatingThreshold	委托人每次委托及贖回的最低Token數	[10, 10000] LAT
maxValidators	備選節點數量	[43, 10000]
unStakeFreezeDuration	驗證節點退出，質押金凍結的結算周期數	(maxEvidenceAge,336] Epoch
rewardPerMaxChangeRange	“委托獎勵比例”每次修改的最大可調整委托獎幅度（?）	[1，2000]
rewardPerChangeInterval	"委托獎勵比例" 允許再次修改需要等待的結算周期數	[2, 28]

• slashing模塊

Key	描述	范圍
slashBlocksReward	出塊率為0，削減的區塊獎勵塊數	[0, 50000) blocks
slashFractionDuplicateSign	雙簽舉報處罰節點自有質押金比例(?)	(0,10000]
duplicateSignReportReward	舉報人可獲得處罰金的獎勵比例（%）	(0, 80]
maxEvidenceAge	雙簽舉報證據有效的結算周期數	(0, unStakeFreezeDuration）Epoch
zeroProduceCumulativeTime	零出塊持續的共識輪數，并在該時間內進行零出塊次數的累計	[zeroProduceNumberThreshold ,50]
zeroProduceNumberThreshold	零出塊次數處罰閾值	[1,zeroProduceCumulativeTime]
ZeroProduceFreezeDuration	節點零出塊懲罰被鎖定時間	[1,unStakeFreezeDuration)

• block模塊

Key	描述	范圍
MaxBlockGasLimit	區塊gaslimit動態調整可以達到的最大Gas限制	[9424776, 300000000] gas

• reward

Key	描述	范圍
increaseIssuanceRatio	PlatON網絡LAT每年增發比例（?）	[0, 2000]

• restricting

Key	描述	范圍
minimumRelease	鎖倉計劃釋放周期的釋放金額最小值	[100, 10000000]

獎懲機制

在設計治理機制時，需要有良好的制度來鼓勵更多有興趣、有能力的專業人士參與到治理中，同時也應該對惡意占用網絡資源等行為進行懲罰。

獎勵

• 提案獎勵：提案獎勵在提案投票通過后自動發放一定獎勵到提案發起賬戶
• 投票獎勵：投票后需要鎖定代幣到提案投票結束，因此投票獎勵和投票鎖定時間長度成正比，在提案投票結束時統一發放至各個投票賬戶
• 開發者獎勵：開發者獎勵需在鏈上發起提案，通過投票結果決定是否發放
• 漏洞懸賞：在確認漏洞真實存在后，需在鏈上發起提案，通過投票結果決定是否發放

懲罰

若不誠實的節點通過偽裝版本而達到升級的目的，當鏈升級成功后，該備選節點被選擇參與共識時，會由于出塊不能被共識導致出塊率低，從而受到系統的懲罰，嚴重者可直接取消驗證節點資格。

治理基金

治理基金來源于基金會，每年從基金會的賬戶劃撥固定比例的資金到治理賬戶，通過提案投票的方式分配治理賬戶余額，用于激勵、薪酬分發。當提案投票通過后，通過多重簽名方式自動下發。