互聯網協調系統的最小初始規範、後續決策本地化與自願採用

摘要

本文描述一種互聯網協調系統的設計模式：提供共同的技術參照點，同時不在實際運行系統的參與者之上建立持續存在的權威。它定義了三項相互關聯的原則：最小初始規範、後續決策本地化、自願採用。

在這一模式下，初始規範只定義維持唯一性、互操作性、共同安全與安全防護所必需的確定性規則，而且這些規則必須能夠在本地驗證。初始規範之後的變更，不由中央機構批准，而由實際運行代碼的參與者採用、忽略、分叉或放棄。

不採用，不構成違規。參與者不採用後續變更，仍可留在原有的兼容集合中。如果某個參與者發出的狀態，不符合另一個參與者所接受的確定性規則，後者可以在本地忽略發出該狀態的參與者。由此產生的是兼容關係的選擇、分叉、隔離或選擇性互操作，而不是機構性懲罰。

本文不定義線協議（wire protocol）。它爲協議、註冊系統、標識符系統以及協調機制的設計規定一種最佳當前實踐；這些系統與機制不得演變成永久的治理機構。

1. 引言

許多互聯網系統最初都有一個狹窄的技術目的：讓彼此獨立的主體通過共享參照點、標識符空間、驗證規則或類似註冊系統的記錄，實現互操作。隨着時間推移，這些系統往往積累起初始互操作根本不需要的權威。

這通常分三步發生。

第一，在技術上尚無必要時，就把未來的問題放進奠基層。

第二，本應由運行各自系統的參與者作出的選擇，變成依賴某個持續存在的機構作出承認、解釋或身份狀態裁定。

第三，把發佈、登記、建議或程序性批准，當作足以產生運行義務的依據，即便參與者並未在實際運行的系統中採用該變更。

結果是一個脆弱的系統。技術參照層變成治理層。記錄維護者變成守門人。協調載體變成控制未來的來源。

本文提出另一種設計紀律：

– 最小初始規範：只規定維持基本互操作性、唯一性、共同安全與安全防護所必需的確定性共同規則。
– 後續決策本地化：初始規範之後，把後續選擇留給實際運行代碼的參與者。參與者可以採用、拒絕、分叉、斷開連接，或選擇性地互操作。任何參與者，都不能改變其他繼續運行相互兼容規則的參與者之間的互操作關係。
– 自願採用：後續變更只有經過實際運行代碼的參與者實施、運行、驗證和採用，才成爲現實。

這三項原則彼此關聯。一個系統如果在開始時規定太多，就會把對未來的控制預先裝進共同層。一個系統如果保留持續存在的承認層，就會允許權威在部署之後重新出現。一個系統如果把發佈當作現實，就會把文檔變成命令。

這裏的設計直覺很簡單：有效性必須由參與者能夠在本地驗證的確定性規則來判定。參與者可以採用後續變更，也可以拒絕、分叉、斷開連接，或選擇性地互操作。它最多隻能讓自己退出某個兼容集合。它不能僅憑拒絕一項變更，就破壞其他繼續運行相互兼容代碼的參與者之間的互操作。

Bitcoin 等系統也體現了同樣的一般性教訓：共識規則由運行驗證代碼的人執行，而不是由凌駕於他們之上的機構執行。

2. 適用範圍

本文適用於互聯網協調系統，包括但不限於共享註冊系統、標識符系統、命名與編號框架、協議擴展機制、實際控制能力證明系統、可遷移性系統，以及其他由獨立主體依賴共同技術參照點的架構。

本文不反對共同規則。本文主張，共同規則應具有確定性、保持最小、能夠在本地驗證，並限於系統實際運行所必需的內容。

本文不要求使用區塊鏈、分佈式賬本或任何特定技術。它要求的是一種設計屬性：參與者應能夠在本地應用初始規範來判定有效性，而無須向常設權威請求許可或身份狀態認定。

3. 約定與定義

3.1. 規範性要求用語

本文以大寫關鍵詞標示的規範性要求用語，應按 BCP 14 的定義解釋，具體見 RFC 2119 和 RFC 8174。

3.2. 術語

初始規範：
系統首次部署所必需的規則、數據結構、格式、不變量、驗證程序及轉換規則的集合。

共同層：
獨立參與者實現互操作所必需的最小共享規則集或參照結構。共同層不是一個機構，而是參與者實施並驗證的技術實質。

確定性驗證規則：
使參與者能夠通過本地計算或本地驗證，判定某個狀態、記錄、轉換、斷言或消息在指定規則集下是否有效的規則。

全局不變量：
爲維持唯一性、基本互操作性、共同安全或安全防護，必須在一個兼容集合內保持一致的屬性。

參與者：
運行、驗證、部署或依賴該系統的運營者、實現、節點、網絡、組織或其他主體。

兼容集合：
由一組參與者構成的集合；它們所實施的驗證規則允許彼此互操作。如果部分參與者採用某項後續變更，而其他參與者不採用，該變更可能形成一個新的兼容集合。

採用：
實際運行系統的參與者所進行的真實實施、部署、驗證和使用。

不採用：
參與者選擇不實施或不使用某項提議中的變更。不採用不會使其獲得無效身份狀態，只意味着該參與者沒有加入這項變更形成的兼容集合。

本地拒絕：
參與者在本地決定忽略、拒絕，或不與某個狀態、消息、記錄或轉換互操作，因爲它在該參與者運行的驗證規則下無效或不兼容。

分叉：
驗證規則或運行實踐發生分歧，由此形成兩個或更多兼容集合。

協調載體：
幫助參與者協調的文檔、註冊條目、建議、實現說明、配置規範、參考實現或其他載體。除非參與者在實際運行的系統中採用它，協調載體不會創造具有約束力的運行現實。

4. 問題陳述

設計者常常試圖通過在奠基層寫入過多內容，或留下一個持續存在的機構解釋未來問題，來減少未來的不確定性。這看似審慎，卻往往危險。

在奠基層規定過多內容，有三項代價。

第一，它把未來的選擇移入共同層，而共同層更難變更，一旦被俘獲，影響也更大。

第二，它造成技術有效性與機構承認之間的含混。

第三，它鼓勵那些維護記錄、發佈文檔或召集參與者的機構，把這些行爲視爲支配未來現實的權威。

同樣的問題也會在部署之後出現。如果一個系統需要某個持續存在的機構批准變更、裁定身份狀態，或解釋日常運行，那麼它就建立了一個奠基之後的控制層。這個層最初可能只是行政管理，隨後可能變成治理，再變成咽喉要道。

本文的設計目標，不是改善機構的自由裁量。目標是讓系統無須依賴這種裁量。

一個設計良好的互聯網協調系統，應在開始時定義確定性且可在本地驗證的有效性規則；應把不涉及不變量的選擇留在共同層之外；並應讓後續變更只有在參與者自願於實際運行的系統中採用時，才成爲現實。

5. 原則一：最小初始規範

5.1. 原則表述

初始規範應當（SHOULD）只定義維持基本互操作性、唯一性、共同安全與安全防護所必需的最小確定性共同規則。

5.2. 要求

採用這項原則的設計：

1. 必須（MUST）明確列出其全局不變量。
2. 必須（MUST）爲每一項全局不變量定義確定性驗證規則。
3. 不得（MUST NOT）將一項規則納入初始規範，除非該規則是維持某項已明確列出的全局不變量，或實現首次部署所必需的。
4. 必須（MUST）將驗證規則與政策偏好、商業安排、機構角色、治理願景及裁量判斷分開。
5. 必須（MUST）允許參與者在本地驗證日常有效性，而無須詢問任何機構、註冊機構、委員會、政策機構或其他權威。
6. 應當（SHOULD）定義本地驗證所必需的數據結構、簽名、證明、狀態轉換規則、衝突規則或其他機制。
7. 在可以預見未來變化的情況下，應當（SHOULD）定義擴展信號、版本機制、兼容性標記或分叉標識。
8. 必須（MUST）確保必需的協調載體可遷移、可審計、可復現且可替換。
9. 應當（SHOULD）優先採用客觀、可由機器驗證的條件，而不是對優劣的主觀評判。
10. 不得（MUST NOT）把未來的機構承認設爲知悉、記錄或使用有效狀態的唯一途徑。

5.3. 對設計的含義

最小初始規範，不意味着規範含糊。它意味着，只對必須共同遵守的內容作出嚴格規定。

系統仍需要足夠的共同結構才能運行。這裏的紀律，是區分：

– 哪些內容爲維持唯一性、互操作性、共同安全與安全防護，必須保持一致；以及
– 哪些內容涉及運營者偏好、商業實踐、部署時機或後續採用選擇，可以留在共同層之外。

如果一個設計不能清楚說明其全局不變量與確定性驗證規則，就應當先假定：它規定的裁量空間太多，可驗證的實質太少。

6. 原則二：後續決策本地化

6.1. 原則表述

初始規範之後，後續決策應當（SHOULD）留在實際運行代碼的參與者本地。後續決策只對採用它的參與者所構成的兼容集合生效。它無須由持續存在的權威批准，不採用也不會產生無效身份狀態。

6.2. 要求

採用這項原則的設計：

1. 對於不會改變參與者所在兼容集合的確定性驗證規則的選擇，不得（MUST NOT）要求參與者向既有機構、註冊機構、委員會、董事會、政策機構或其他權威取得許可。
2. 不得（MUST NOT）建立一個常設機構，並使其承認成爲後續變更在運行中成爲現實的唯一途徑。
3. 必須（MUST）區分初始規範下的有效性，與對某項後續可選變更的兼容性。
4. 不得（MUST NOT）把不採用後續變更視爲無效。
5. 必須（MUST）允許不採用後續變更的參與者留在現有兼容集合中。
6. 必須（MUST）允許參與者通過採用新的驗證規則或運行配置規範，加入新的兼容集合。
7. 必須（MUST）允許參與者在本地拒絕那些在其運行的驗證規則下無效或不兼容的狀態、記錄、轉換或消息。
8. 不得（MUST NOT）授權任何機構、註冊機構、委員會、政策機構或其他主體，僅因參與者拒絕後續變更，就宣佈該參與者無效。
9. 應當（SHOULD）明確標示分叉、版本、配置規範或兼容集合，讓參與者知道自己運行哪些規則，以及可以與哪些其他參與者互操作。
10. 應當（SHOULD）避免任何讓既有記錄維護者能夠阻止原本有效的參與者繼續互操作的設計。

6.3. 對設計的含義

後續決策本地化，不意味着由中央權威把未來決策分配給本地主體。它意味着，系統從設計上就讓初始規範之後的日常後續選擇，無須經過這種分配。

初始規範預先完成劃定邊界的工作。它定義維持唯一性、互操作性、共同安全與安全防護所必需的最小不變量。其餘一切留在共同層之外。

未來的變更不由中央批准，而由實際運行代碼的參與者採用、忽略、分叉或放棄。

拒絕一項變更的參與者，可以留在該變更形成的兼容集合之外。它可以斷開自己與其他參與者的連接，可以繼續留在舊的兼容集合中，可以分叉，也可以選擇性地互操作。但它不能破壞其他繼續運行相互兼容規則的參與者之間的互操作。

無效或不兼容狀態帶來的是本地拒絕，而不是懲罰。沒有人需要裁定某個參與者處於不合規身份狀態。運行兼容驗證規則的參與者，只是不接受那個無效或不兼容的狀態。

7. 原則三：自願採用

7.1. 原則表述

互聯網協調系統中的變更，應當（SHOULD）通過參與者的實施、驗證、部署和採用，在運行中成爲現實，而不能僅憑發佈或宣告。

7.2. 要求

採用這項原則的設計：

1. 不得（MUST NOT）把發佈、登記、建議、會議批准或程序性批准，視爲足以產生普遍運行義務的依據。
2. 必須（MUST）允許選擇運行新規則、擴展、配置規範或程序的參與者，逐步部署這些內容。
3. 必須（MUST）允許參與者拒絕後續變更而不獲得無效身份狀態，只要其自身的狀態轉換符合其兼容集合的確定性驗證規則。
4. 在初始規範允許延續的情況下，必須（MUST）允許參與者繼續使用舊的兼容集合。
5. 當規則不兼容時，必須（MUST）允許運行一個兼容集合的參與者，在本地拒絕或忽略來自另一個兼容集合的狀態。
6. 應當（SHOULD）爲重大變更定義採用路徑，包括版本信號、兼容性標記、過渡指引和測試向量。
7. 應當（SHOULD）爲重大變更定義拒絕路徑，包括不採用的參與者如何繼續運行、標識其兼容集合，以及避免含混的互操作。
8. 必須（MUST）確保參與者能夠退出必需的協調載體，或遷移、鏡像、重新實現、替換這些載體，而不承擔難以承受的過渡成本。
9. 應當（SHOULD）讓註冊系統、記錄、建議與協調載體描述已經被採用的現實，而不是宣告尚未被採用的未來現實已經存在。
10. 必須（MUST）避免把既有機構的事先承認，設計成變更成爲現實的唯一途徑。

7.3. 對設計的含義

自願採用，是檢驗一項變更是否有用、是否可接受、是否適合實際部署的運行尺度。

提案不是現實。建議不是現實。註冊系統的更新不是現實。文檔不是現實。只有當參與者實施、驗證、部署並依賴這項變更時，現實才出現。

不採用，不產生任何違規身份狀態。它只產生一個事實：該參與者沒有加入這項變更形成的兼容集合。

這並不消除標準制定流程、註冊系統、文檔或審查。它限制的是這些事物所能主張的權力。它們可以幫助參與者協調，可以發佈參考資料，可以描述採用情況，也可以提出建議。但它們不能僅憑宣告，就使尚未被採用的未來現實，對那些沒有運行它的參與者產生約束力。

8. 三項原則之間的關係

這三項原則相互強化，孤立採用任何一項都不足以奏效。

最小初始規範確保共同層包含的是確定性驗證規則，而不是裁量權威。

後續決策本地化確保未來選擇留在實際運行代碼的參與者手中，而不是被中央審批層重新奪回。

自願採用確保後續變更必須經受實際實施與使用的檢驗。

一個系統如果只採用其中一項或兩項原則，可能通過其他手段重現同樣的集中化。

– 有最小初始規範而沒有後續決策本地化，仍可能讓權威在部署之後積累。
– 有後續決策本地化而沒有最小初始規範，可能產生含混，因爲參與者無法在本地判定有效性。
– 有自願採用而沒有確定性驗證，可能產生混亂，因爲參與者無法區分兼容的變化與無效狀態。
– 有確定性驗證卻沒有退出、可遷移性或可替換性，仍可能產生鎖定，因爲記錄維護載體可能變得無法脫離。

三項原則共同作用，形成這樣一種系統：共同層保持薄，有效性能夠在本地驗證，未來變更出於自願，日常運行無須由任何常設機構裁定。

9. 推薦的設計模式

9.1. 確定性共同層

共同層應當（SHOULD）僅包含：

– 穩定的標識符語義；
– 確定性有效性規則；
– 維持唯一性所必需的衝突解決規則；
– 傳輸層面或協議層面的互操作要求；
– 共同的安全防護不變量；
– 必要時的實際控制能力證明機制；
– 必要時的可遷移、可審計記錄格式；
– 擴展信號與兼容集合標識。

共同層不應當（SHOULD NOT）包含：

– 商業模式規則；
– 定價規則；
– 地區政治偏好；
– 與技術不變量無關的資格認定意識形態；
– 自由裁量的執行權；
– 對優劣的主觀評估；
– 機構使命的擴張；
– 主要作用是維護既有機構權威的任何規則。

9.2. 運營者的決策範圍

以下事項應當（SHOULD）留在共同層之外，除非它們直接改變某項已明確列出的全局不變量：

– 部署時機；
– 商業用途；
– 客戶所在地域；
– 租賃、融資或轉讓安排；
– 本地資格認定偏好；
– 運行步驟的先後順序；
– 共同有效性並不要求的路由實踐；
– 商業模式；
– 組織結構；
– 自願遷移的時機；
– 可選的配置規範或擴展。

參與者可以（MAY）在這些領域作出不同選擇。這些選擇可能形成不同的兼容集合、商業關係、對等互聯安排或運行共同體。除非違反某個兼容集合內的確定性驗證規則，否則這些選擇不構成無效。

9.3. 採用循環

在可行的情況下，實質性系統變更的優選順序是：

1. 提案；
2. 實現；
3. 測試向量或確定性驗證方法；
4. 由自願參與者進行有限部署；
5. 觀察互操作性與安全防護方面的影響；
6. 標記兼容集合；
7. 以文檔或建議描述已經被採用的現實。

協調載體應當（SHOULD）跟隨採用，而不是試圖搶先替採用作出決定。

9.4. 退出、分叉與可遷移性

符合本文要求的設計，應當（SHOULD）將退出、分叉與可遷移性視爲正常設計要求，而不是失敗。

系統應當（SHOULD）定義參與者如何：

– 繼續留在舊的兼容集合中；
– 採用新的兼容集合；
– 分叉到不同的兼容集合；
– 遷移記錄、標識符、證明或運行狀態；
– 不依賴既有記錄維護者，驗證記錄的有效性；
– 在兼容性允許的範圍內，選擇性地互操作。

如果一個系統無法在不破壞有效運行的前提下退出或分叉，它很可能把治理權力藏進了記錄維護職能之中。

10. 適用條件與侷限

這一設計模式尤其適用於以下情況：

– 系統涉及多個主體和多個司法管轄區；
– 獨立部署很重要；
– 協調層的設計意圖是保持薄；
– 未來很可能出現變化，但無法詳細預測；
– 鎖定會帶來治理風險；
– 有效性可以通過確定性規則判定，或在本地驗證。

在以下情況下，它的直接適用性可能較弱：

– 預期架構就是單一行政管理域；
– 強實時耦合要求始終保持統一行爲；
– 生命安全問題要求立即在全局保持一致；
– 沒有任何切實可行的機制能夠在本地驗證有效性。

即便在這些情況下，設計者仍應當（SHOULD）儘可能縮減共同層，並避免以自由裁量控制未來。

11. 非目標

本文並不：

– 禁止一切協調；
– 禁止一切共享註冊系統；
– 要求使用區塊鏈或分佈式賬本技術；
– 保證達成共識；
– 保證政治中立；
– 要求所有參與者採用每一項後續變更；
– 把拒絕採用視爲無效；
– 爲一邊聲稱兼容、一邊實施不兼容本地行爲的做法賦予正當性；
– 消除對安全至關重要的共同規則的必要性。

12. 安全考慮

更薄的協調層，可以降低被俘獲的風險，縮小機構錯誤的波及範圍，並提高可替換性。不過，更大的本地裁量空間，也可能造成安全防護水平不一致、降級路徑、碎片化壓力、含混的兼容性聲明，以及不安全的分叉。

因此，採用本文原則的設計者必須（MUST）明確規定安全不變量。尤其是：

– 共同有效性所必需的身份認證與授權要求，必須（MUST）具有確定性，並能夠在本地驗證；
– 當安全受到影響時，版本協商與擴展處理必須（MUST）避免靜默降級；
– 必須（MUST）分析拒絕、分叉及替換路徑中的濫用與拒絕服務風險；
– 兼容性標記應當（SHOULD）足夠清晰，以防止不兼容規則集之間發生意外互操作；
– 不得（MUST NOT）允許本地變體虛假聲稱自己兼容某個實際上並不滿足的規則集。

安全例外的存在，不能成爲設立普遍許可層的理由。它只能爲維持已明確列出的全局不變量所必需的確定性安全規則提供理由。

13. IANA 考慮

本文不涉及任何 IANA 操作。

14. 參考文獻

14.1. 規範性參考文獻

– RFC 2119 — Bradner, S.，《在 RFC 中用於表示要求級別的關鍵詞》，BCP 14，RFC 2119。
– RFC 8174 — Leiba, B.，《RFC 2119 關鍵詞使用大寫與小寫時的歧義》，BCP 14，RFC 8174。

14.2. 資料性參考文獻

– RFC 6709 — Carpenter, B. 與 B. Aboba，《協議擴展的設計考慮》，RFC 6709。
– RFC 7282 — Resnick, P.，《論 IETF 中的共識與哼聲表態》，RFC 7282。

附錄 A. 設計覈對清單

聲稱符合本文要求的設計，應當（SHOULD）能夠清楚回答以下問題：

1. 全局不變量有哪些？
2. 哪些確定性驗證規則維持這些全局不變量？
3. 初始規範中的哪些規則，是首次部署嚴格必需的？
4. 哪些未來問題被有意留在共同層之外？
5. 哪些後續選擇可由參與者作出，而不改變其所在的兼容集合？
6. 參與者如何採用後續變更？
7. 參與者如何拒絕後續變更，而不被賦予無效身份狀態？
8. 兼容集合如何被標記或發現？
9. 當某個狀態在參與者運行的規則下無效或不兼容時，本地拒絕如何運作？
10. 分叉路徑是什麼？
11. 遷移路徑是什麼？
12. 從任何必需協調載體退出的路徑是什麼？
13. 參與者能否不依賴既有記錄維護者，驗證日常有效性？
14. 記錄與協調載體是在描述已經被採用的現實，還是試圖通過宣告，讓尚未被採用的未來現實成爲既成事實？
15. 系統是否已將嵌入共同層的決策數量減至最少？
16. 系統是否避免了任何裁定參與者日常身份狀態的持續性權威？

## 作者地址

H. Lu
[TBD]