隨筆65：運行代碼優先——守住互聯網原始設計所需的補丁
哪一個補丁能在註冊層恢復互聯網的原始設計？
Heng.lu這一系列此前的七篇隨筆分別是：
- 隨筆52：當註冊權力與法律責任脫鉤——爲什麼現行RIR協調模式無法以目前的形態存續
- 隨筆53：互聯網號碼資源不是政治財產
- 隨筆56：區域互聯網註冊機構的厚重治理如何把唯一性變成雙重攫取
- 隨筆58：從雙重攫取到主權倒置——各國如何因100美元而向RIR喪失主權控制
- 隨筆59：貧困懲罰——RIR模式如何向窮人徵稅，卻將其稱爲平等
- 隨筆61：對運行代碼的背叛——RIR體系如何讓共識反過來對付技術社羣
- 隨筆62：授權洗白——從RIR的幻想走向過渡架構
此前七篇文章，不是區域互聯網註冊機構的改革方案。
它們是一場屍檢。
它們從不同層面追蹤同一種制度病變：法律責任與後果脫節；號碼資源被重新貼上政治財產的標籤；唯一性被變成雙重攫取；主權被倒置；以平等之名向貧困徵稅；共識反過來對付它本應服務的網絡；最後，授權被層層洗白，直到一個辦事員開始以主權者的口吻說話。這個脈絡很重要，因爲問題並非某個糟糕的董事會、某家糟糕的註冊機構、某場訴訟，或某次令人不適的市場事件。它是同一個系統缺陷，換着不同的面目出現。CircleID的作者頁面如今清楚呈現了這一脈絡，包括《對運行代碼的背叛》和《授權洗白》。（circleid.com）
這篇文章，不是要把RIR培養成更好的統治者。
我要解釋的是，爲什麼現行註冊秩序不可能成爲終點，以及爲什麼干擾最小的修補，是爲互聯網原始技術設計補上一項原則。
這項補充，就是運行代碼優先。
它的必要性已經不再停留於理論。最近在CircleID的一場交鋒中，John Curran提出了現有體系一方最有力的論證。他認爲，RIR體系的權威不只是狹義技術協調的副產品，而是一條歷史鏈條的結果：白皮書、ICANN、ASO、ICP-2、IANA管理權移交，以及持續至今的私營部門多利益相關方治理。他表示，RIR體系的權威來自其在美國政府指定的私營部門多利益相關方模式內運作。（circleid.com）
這個論證很有用，因爲它讓爭議的實質顯露出來。
問題已經不是歷史上是否存在授權。當然存在。問題是，一項歷史上被授予的協調職能，能否後來藉助自己掌控的同一套程序機制，把自身擴張成一項持續的治理授權。現有體系的回答是可以：授權、認可、制度延續和社羣程序，共同構成一種能夠自行續期的授權。
互聯網原始技術設計所要求的回答，是不可以。
互聯網原本的傳統，邊界更窄，約束更硬，也更好。RFC 3935指出，IETF的目標是“讓互聯網運行得更好”；它把工作建立在技術能力、現實中的實現，以及“粗略共識與可運行的代碼”之上。它還明確指出，對於不屬於IETF職責範圍的協議或職能，IETF不會試圖施加控制。（rfc-editor.org）RFC 7282重申了David Clark那句老話：“我們拒絕：國王、總統和投票”，以及“我們相信：粗略共識與可運行的代碼”。（rfc-editor.org）RFC 9592把反對主權式權威的立場說得更直白：IETF不運營、不控制，也不巡查互聯網，它不是“協議警察”。（rfc-editor.org）
這個傳統從來不是說文件有魔力。它的意思是，文件能幫助系統運行，纔有意義；程序能服務於部署，才值得容忍；會議室只有讓自己受制於實際運行，纔有用。
註冊層借用了這份正當性。
卻從未完全接受相應的約束。
這就是缺失的補丁。
“運行代碼優先”意味着什麼
運行代碼優先，意味着必須以實際運行的網絡最初所證明有必要存在的最低限度技術職能爲依據，對互聯網協調體系作狹義解釋。
號碼資源層的存在，是爲了保護運行中的系統：唯一性、互操作性、與路由相關的連續性、安全聲明、控制權證明，以及獨立網絡協同運行所需的最低限度共同語義。
它不是用來製造政治權威的。
它不是用來審判商業道德的。
它不是用來把服務地域變成權屬的。
它不是用來把郵件列表變成立法機關的。
它不是用來讓一傢俬營註冊機構僅僅因爲內部政策理論發生變化，就使已經運行的網絡資產憑空消失的。
註冊機構不是國家。
數據庫聯繫人不是公司授權委託書。
服務區域不是一個人民共同體。
政策會議室不是立法機關。
註冊記錄可以描述實際運行。它不能創造實際運行。
這不是保守主義。運行代碼優先並不是說，已經部署的系統永遠不能改變。它說的是，機構對變更的權力，不能靠歷史授權、循環認可或儀式化程序來證明正當。它必須以運營者能夠在本地驗證的確定性規則，以及運行中系統的實際採納爲依據。
正確的順序是：初始規範、分佈式賬本狀態、本地驗證、運行中的實現、自願採納、兼容集合，然後纔是文檔。
錯誤的順序是：政策會議室、宣告、聲稱存在的義務、合規標籤、強制實際運行服從。
RIR體系之所以失敗，是因爲它越來越傾向於第二種順序。
關鍵的糾正是：初始規範確立之後，不再有一個需要持續向其請示的機構。沒有委員會來決定不採納是否構成違規。沒有註冊機構僅僅因爲某個參與者拒絕後續變更，就宣佈它無效。剩下的只有代碼、賬本狀態、驗證、採納、兼容性、本地拒絕、分叉和選擇性互操作。
運營者拒絕一項後續變更，不會破壞互聯網。它可以留在較舊的兼容集合中。它可以分叉。它可以斷開連接。它可能無法與採用了不兼容規則的參與者互操作。但它不能破壞那些繼續運行彼此兼容代碼的其他參與者之間的互操作。
這裏的設計直覺，與分佈式賬本之所以有用的道理相同：判斷日常有效性，不需要一個常設機構。參與者依照確定性規則，在本地驗證狀態轉換。無效狀態不會受到機構懲罰。不接受這種狀態的參與者，直接忽略它。
這就是號碼資源協調一直缺失的根本補丁。
設計缺陷從一開始就存在
最初的RIR設計，假定自己所處的是一個資源價值很低的世界。
號碼資源看起來是技術性的、充裕的、事務性的，衝突也少。在那樣的世界裏，非正式安排似乎很高效。開放郵件列表似乎有代表性。以聯繫人爲基礎的管理似乎已經足夠。限制責任的合同似乎無傷大雅。區域註冊機構看起來可以只是一本通訊錄。
IPv4稀缺摧毀了這個前提。
IPv4地址變得稀缺，可以轉讓、融資、出租、資本化，也會進入訴訟、受到制裁，並且嵌入正在運行的網絡。註冊層管轄的已不再只是事務性條目。它處在生產性基礎設施之上，處在資產價值之上，處在客戶服務連續性、雲部署、電信運營、國家網絡連通、法院命令和資本配置之上。
制度形態並沒有爲適應這些新風險而收縮。
它反而擴張了。
結果是，這套體系仍在說技術協調的語言，卻產生基礎設施治理的效果。註冊機構的決定影響着商業命運，它卻要求運營者把註冊程序視爲中立。它把參與者稱爲“社羣”，可許多承擔後果的人，從未向會議室裏的人授予明確的法律代理權。
NRS直白地指出了這個結構性問題：互聯網號碼註冊機構原本被設計爲技術協調機構，但IPv4稀缺使地址成爲有價值的資產之後，註冊機構的裁量就變成了經濟權力；當協調體系控制資本時，中心化便成爲結構性風險，去中心化也就不再只是意識形態，而是系統工程。NRS還提出了相反的設計方向：一個互聯網、開放且自主的基礎設施，以及以最低限度人爲參與爲核心的去中心化治理。（nrs.help）
這纔是真正的問題：當協調錶格變成資產關卡時，註冊層從未得到相應的修補。
運行代碼優先，就是這個補丁。
它不是一套“更好的RIR”學說。
它是後RIR時代的設計紀律。
補丁的三項規則
建設性的框架來自修訂後的隨筆64《互聯網協調體系的初始規範最小化、後續決策本地化與自願採納》：初始規範最小化、後續決策本地化和自願採納。
名稱保持不變。邏輯必須精確。
初始規範最小化，意味着共同層只包含唯一性、互操作性、控制權證明、共同安全與安全防護所必需的確定性規則，而且這些規則能夠在本地驗證。它不包含商業模式偏好、定價理論、區域政治情緒、酌情強制執行權或機構使命擴張。
後續決策本地化，不是讓某個機構決定哪些後續決策可以留在本地。那樣已經把權威層重新引了回來。它的意思是，初始規範預先完成劃界工作。部署之後，通常的後續選擇仍由運行代碼的參與者作出。參與者可以採納、拒絕、分叉、斷開連接，或選擇性互操作。任何參與者都不能改變那些繼續運行彼此兼容規則的其他參與者之間的互操作。
自願採納，意味着後續變更只有通過實現、驗證、部署和使用，才成爲現實。發佈不是現實。建議不是現實。現有機構的認可不是現實。不採納不會產生無效身份。不採納後續變更的參與者，仍留在原有的兼容集合中。如果一個參與者發出的狀態，依照另一個參與者運行的確定性規則屬於無效狀態，後者可以在本地忽略它。產生的效果是兼容性選擇，而不是機構懲罰。
這三項規則，不是爲了修復註冊機構的主權。
它們是爲了阻止這種主權換個名字捲土重來。
APNIC：法律結構本身就是風險
APNIC展示了第一種失敗：一開始，就沒有把最低限度的邊界規定得足夠嚴格。
這不是行爲準則的故事。不是禮儀的故事。也不是批評者對現有機構是否足夠禮貌的故事。
這是法律結構的故事。
2023年3月，LARUS發佈了一份法律審查，警告APNIC的治理結構帶來的風險，不僅涉及布里斯班的一家公司，還涉及整個亞太地區的互聯網治理。審查指出，APNIC總幹事擁有關閉APNIC及撤除民選執行委員會的最終法律權力，治理結構亟須修改。它還指出，這種結構使超過十億亞太互聯網用戶所依賴的互聯網治理是否安全，成爲一個問題。（larus.net）
第一份附件是ASIC公司登記摘錄，提供了公司層面的基本事實。APNIC Pty Ltd被列爲一家在昆士蘭州註冊的澳大利亞私人股份有限公司。Paul Byron Wilson被列爲董事兼公司祕書。股份資料顯示，公司發行了一股普通股，持有該股份的成員也被列爲Paul Byron Wilson。（larus.net）
用這樣的結構承載一項關鍵的區域互聯網協調職能，並不正常。
第二份附件是Peter Felter博士的法律意見，得出了治理層面的結論。它將面向公衆的APNIC結構——會員、選舉、執行委員會、總幹事和祕書處——描述爲一個依據APNIC Pty Ltd公司章程第9.3條設立的特別委員會。意見指出，25年來，APNIC Pty Ltd一直是一家由一名董事、一名股東和一名公司祕書控制的私人公司，而三個身份屬於同一個人。（larus.net）
這個區別很重要。
面向公衆和社羣的機構，並不是最終的法律載體。它是一座建在私人公司結構之上的建築。
法律意見隨後解釋了這個區別爲何重要。APNIC的內部規章被規定爲受公司章程以及公司及其董事、高管和成員的權力約束。按照這一解讀，面向公衆的APNIC結構可以通過APNIC Pty Ltd的董事決議加以改變；法律意見將APNIC描述爲實質上是APNIC Pty Ltd的一個部門。（larus.net）
這份意見最具衝擊力的地方，不在於聲稱APNIC在法律上不合法，而在於指出合法與妥當不是一回事。意見認爲，信託安排並未解決問題，因爲執行委員會的權力，仍然來自董事設立特別委員會的決議。它還指出，APNIC Pty Ltd是一傢俬人股份公司，其結構與宗旨，並不像大多數人會聯想到的那種無股本、非營利的區域公共利益註冊機構。（larus.net）
這就是第一種設計失敗最清晰的形態。
一個區域規模的號碼協調體系，不應依賴這樣一種結構：需要律師來解釋，一家只有一股股份的私人公司、一個特別委員會、一份信託契約和一個民選委員會，究竟如何拼成了對亞太號碼註冊機構的正當控制。
關鍵協調層的結構，應當讓外部的人看得明白。
它不應要求人們信任文件背後的文件。
它不應讓會員在依賴機構多年之後才發現，民選層可能不是最終的法律權力層。
它不應擺出會員治理的樣子，卻把正式權力留在別處。
因此，初始規範最小化必須納入的是分佈式有效性，而不是對機構的信任。不是因爲未來的機構需要更好的治理，而是因爲未來的後RIR體系，應當根本不需要這樣的機構。
共同層不應依賴一傢俬人公司的隱蔽控制結構。它應當規定確定性驗證規則、控制權證明狀態、狀態轉換規則、衝突規則、賬本複製、退出路徑、分叉路徑和兼容集合。如果APNIC消失、陷入內部俘獲、改變法律立場，或拒絕認可一個有效狀態，運行中的網絡不應依靠APNIC持續認可，才能知道誰控制哪些號碼資源。
註冊機構不應是有效性的來源。
依照初始規範驗證過的分佈式賬本狀態，才應當是。
ARIN：政策撞上資產現實
ARIN展示了第二種失敗：法律與市場現實，可以跑在註冊機構的理論前面。
決定性的事件，是Nortel與Microsoft之間的交易。Nortel申請破產時，其666,624個IPv4地址成爲破產程序中的有價值資產。這些地址以750萬美元售予Microsoft。ARIN介入，理由是這些地址不是財產，不能在不受註冊政策約束的情況下出售。加拿大工業部支持這一觀點。破產法院否定了這一主張；Microsoft後來簽署了一份歷史資源協議；實際結果很清楚：一旦法院和市場把號碼資源視爲資產，註冊政策就不能再是現實的唯一來源。（btw.media）
重要的教訓，不是ARIN有某種獨一無二的缺陷。
而是註冊層已經進入了一個新的範疇。
註冊記錄之所以有價值，是因爲運營者、法院、買家、賣家、債權人和網絡依賴它。否認這種依賴，不能使它獲得權威。它只有足夠貼近法律、市場和運行現實，值得信賴，才能繼續有用。
IPv4一旦變得稀缺，註冊程序就成了市場接口。轉讓規則、需求評估、認可延遲和地域限制，不再是事務性細節。它們變成了資產流通的摩擦。公開分析如今描述的是一套割裂的RIR規則體系：五個區域體系共同支配着一個每個地址交易價格約爲18至45美元的市場，相互衝突的規則可能使資產陷入困境、拖延併購，甚至迫使企業僅爲持有號碼塊，就設立不同的公司結構。（btw.media）
這不是中立協調。
這是沒有監管問責的監管效果。
ARIN證明了自願採納爲何重要。註冊政策只有在描述各方實際實現、交易、融資、訴訟並依賴的事物時，才保有可信度。把發佈視爲足以製造現實的行爲，政策就變得危險。
拒絕現實的註冊機構，不會因此成爲主權者。
它只會成爲一個過時的數據庫。
在運行代碼優先的設計中，教訓還要更鮮明。法院和市場不需要現有註冊機構來決定價值是否存在。運營者不需要委員會來告訴自己一個地址塊能否被路由。參與者需要的是確定性規則，讓控制權證明、衝突解決、賬本上可見的狀態轉換和兼容性成爲可能。舊註冊機構可以發佈一種視圖。軟件客戶端可以顯示一種視圖。賬本瀏覽器也可以顯示一種視圖。但它們都不是有效性的來源。
沒有另一個註冊機構可供遷入。
沒有一個註冊機構需要請示。
只有一份分佈式狀態，由參與者驗證、接受、拒絕、從中分叉，或與之互操作。
AFRINIC：當註冊理論威脅運行中的資產
AFRINIC是核心案例，因爲它把問題剝到了最本質的層面。
錯誤的敘事，是一個難纏的會員癱瘓了一家區域註冊機構。
這是現有體系上演的道德劇。
結構性的故事不同。AFRINIC試圖把商業使用、客戶地域、租賃、會員關係和內部政策解釋，變成一項聲稱可以註銷已經運行的號碼資源的權力。一旦提出這種主張，衝突就不可能繼續只是政策會議室裏的分歧。它變成了一場檢驗：一傢俬營註冊機構，能否藉助區域話語和政策未作規定之處，威脅已經嵌入實際運行的資產。
事實不需要戲劇化的誇張。公開報道把AFRINIC爭議描述爲一場圍繞IP地址的簡單商業糾紛，後來卻成爲非洲最大的互聯網治理事件。報道還指出，Cloud Innovation經常被描繪成反派，而後來出現的文件材料，卻指向AFRINIC自身內部的破壞性力量，以及AFRINIC代表如何以AFRINIC承擔費用爲代價，拖延、延長並持續進行訴訟。（btw.media）
這很重要，因爲它顛倒了通常的敘事。
訴訟沒有製造結構性失敗。
訴訟揭露了它。
當一傢俬營註冊機構把“沒有明確許可”當成強制控制的依據時，問題就已經存在。租賃不是對唯一性的威脅。客戶地域不是重複分配。商業使用不是路由安全故障。註冊機構不喜歡的商業模式，也不是一個全局不變量。
可註冊機構的主張，卻把這些問題全都放進了撤銷的框架。
就在這一刻，協調變成了統治。
報道記載，AFRINIC在2021年3月致函Cloud Innovation，指控其違反政策，並威脅終止會員資格；2021年7月，毛里求斯最高法院禁止AFRINIC終止Cloud Innovation的會員資格；同年12月，AFRINIC又一次試圖取消會員資格，也遭到阻止。（btw.media）這個過程，不是註冊機構從容保護互聯網的故事。它是註冊權威遇上普通法律的故事。
更廣泛的制度崩潰，也不是因爲註冊機構權力太少。更深的問題是鎖定。如果一家註冊機構對有價值的運行中資產擁有壟斷性的認可權，每一次內部失靈都會成爲互聯網連續性的風險。如果會員無法離開這套認可體系，註冊機構的失靈就會變成挾持能力。
註冊機構可以糾正自身記錄中有證據可證明的註冊欺詐。
在註冊機構模式仍然存在時，它可以防止重複分配。
在參與者仍然依賴它時，它可以維護安全聲明。
但這些都是舊架構的過渡性職能。
在後RIR架構中，這些職能不再由註冊機構承擔，而是被編碼進分佈式賬本狀態、控制權證明規則、衝突規則，以及可在本地驗證的狀態轉換。
私營機構不應把租賃變成對某個區域的叛國行爲。
不應把客戶地域變成撤銷資源的觸發條件。
不應把商業分歧視爲技術無效。
不應把資產的持續使用變成一項許可。
AFRINIC證明了正確理解後續決策本地化的必要性。不存在一箇中央機構，負責決定未來的某項商業決策“屬於本地”。相反，初始規範必須確保，這些決策從一開始就不進入共同層。租賃、客戶地域、商業使用、定價、融資、客戶構成和部署策略，都應留在確定性有效性規則之外，除非它們直接影響唯一性、安全、控制權證明或互操作性。
運營者出租地址，不能破壞其他運營者之間的互操作。
運營者向歷史註冊區域以外的客戶提供服務，不能破壞其他運營者之間的互操作。
運營者採用註冊機構不喜歡的商業模式，不能破壞其他運營者之間的互操作。
最多隻是某個運營者未能滿足其他參與者運行的確定性規則。在這種情況下，其他參與者在本地拒絕無效狀態。沒有懲罰層。沒有合規法庭。沒有區域主權者。
這條界線不是意識形態上的。
它是運行層面的。
代理權問題絕不是細節
AFRINIC的選舉爭議，讓第二個缺陷顯露出來：代表權。
NRS以直接的法律表述說明其代表權基礎。它表示，名單中的會員委託NRS在RIR治理事務中代表自己，而每一名列出的會員都提供了授權委託書。（nrs.help）在AFRINIC選舉爭議期間，NRS請會員報告自己的姓名是否出現在選民名冊上，或是否在本人沒有參與的情況下被記錄爲已經投票，並表示這類事實報告將通過合法渠道處理。（nrs.help）
這很重要，因爲它展示了法律代理與社羣話語之間的區別。
RIR體系常常把幾種身份混成一種：公司代表、數據庫聯繫人、技術聯繫人、員工、顧問、代理權持有人、政策參與者、郵件列表常客。這些不是同一回事。
數據庫聯繫人可以協助管理記錄。
授權委託書如果有效，而且行爲在授權範圍內，可以賦予代理權。
政策參與者可以貢獻專業知識。
郵件列表發言者可以表達意見。
但上述任何一種身份，都不會使其自動成爲所有承擔註冊機構決定後果的公司、客戶、國家、債權人、貸款人、買家、承租人或網絡在法律意義上的委託主體。
只有共同層保持精簡時，這個區別纔可能被忽略。一旦註冊機構聲稱自己對撤銷、轉讓、租賃、市場準入、制裁處理、資產連續性或國家基礎設施風險擁有權力，代表權就成爲憲制層面的問題。
一間會議室不是授權。
一個郵件列表不是人民。
一條聯繫人記錄不是公司授權委託書。
一個服務區域不是主權意義上的選民羣體。
這不是在程序上吹毛求疵。
這是協調與統治的區別。
運行代碼優先的體系，通過減少那些根本需要代表權的決策，避開這個陷阱。如果有效性是確定性的，而且能在本地判定，需要投票的事情就少了。如果後續變更是自願的，就不需要決定不採納者是否屬於違規者。如果狀態體現在分佈式賬本上，就不需要乞求現有註冊機構承認自己的持續存在。如果兼容集合明確，參與者無需詢問一個政治會議室，就知道自己能與誰互操作。
最好的治理問題，是系統設計直接消除了的問題。
RIPE NCC與LACNIC：俱樂部與瓶頸
RIPE NCC和LACNIC並不能證明某些RIR比另一些更文明。它們證明的是，RIR模式在技術職能之外，還有兩個執行層：俱樂部和瓶頸。
俱樂部決定誰算體面。瓶頸決定誰的註冊狀態能夠流轉。
RIPE NCC拒絕接受LARUS對RIPE 90的贊助，清楚展示了俱樂部這一層。一名會員提出贊助，卻被註冊機構一側的生態圈拒絕，原因是另一個區域裏一場與此無關的爭議。那不是路由安全決定。不是唯一性決定。不是確定性驗證規則。而是利用會議准入實施私人封殺。LACNIC也拒絕了我的贊助。不同區域，同一種本能：註冊機構俱樂部通過控制會議室、曝光、贊助、聲譽和社會正當性來保護自己。
這不是社羣。這是把守關卡。
制裁層更嚴重，因爲它以法律形式展示了中央瓶頸。RIPE NCC表示，由於機構位於荷蘭，它必須遵守歐盟制裁；制裁適用時，它會凍結RIPE數據庫中的註冊信息，阻止資源取得與轉讓，而且當事方無法提供充分文件時，相關個案也可能被視爲凍結。它還篩查OFAC名單，因爲銀行關係會影響付款。（RIPE NCC制裁透明度說明）
這不是批評RIPE NCC遵守法律。荷蘭實體必須遵守荷蘭法律和歐盟法律。問題在於架構：爲什麼一家荷蘭私營實體，應當成爲橫跨衆多國家、運營者和法律體系的號碼資源流轉的中央認可點？
制裁可以約束一家銀行。可以約束一個荷蘭實體。可以約束一個選擇不交易的交易對手。但它不應成爲其他所有人的全球技術有效性條件。
這就是設計失敗。
讓俱樂部能夠排斥批評者的同一種中心地位，也讓一個司法轄區能夠凍結註冊流轉。一個是社會層面的約束，另一個是法律層面的約束。二者之所以能奏效，都因爲註冊機構佔據了一個有效性本不應依附的位置。
這與三項原則直接相連。
初始規範最小化：俱樂部認定的體面、贊助資格、區域政治、制裁分類和聲譽，絕不能進入共同層。共同層只應包含唯一性、控制權證明、衝突處理、狀態轉換和安全所需的確定性規則。
後續決策本地化：法律風險、交易對手選擇、贊助、商業信任和制裁風險，應由承擔這些後果的行動者處理。荷蘭實體可以拒絕一筆交易。銀行可以拒絕付款。交易對手可以拒絕往來。但這些都不應成爲普遍適用的註冊真相。
自願採納：參與者通過運行代碼、驗證狀態，以及選擇與誰互操作，來決定接受哪些交易對手。不採納不是不當行爲。本地拒絕不是全球無效。俱樂部的拒絕，不應抹去有效狀態。制裁義務應約束受其管轄的行動者，而不是改寫全世界的號碼資源賬本。
這就是分佈式賬本設計不可或缺的原因。在後RIR體系中，日常有效性不由RIPE NCC、LACNIC、制裁部門、會議委員會或贊助辦公室決定。參與者在本地驗證狀態。交易對手自願接受或拒絕。分叉可見。兼容集合明確。中央註冊機構不再是真相的來源。
解決辦法不是更好的禮儀。
不是更透明的制裁處理隊列。
而是讓有效性同時脫離俱樂部和瓶頸。
分佈式狀態。本地驗證。自願接受交易對手。註冊機構不再是有效性的來源。
NRO的信：向上逃逸
最嚴重的證據，不是AFRINIC試圖越權。
而是整個體系的集體反應。
2022年，號碼資源組織（NRO）致信毛里求斯政府。信中將NRO描述爲全球RIR的協調機構，並表示各RIR管理各自區域的號碼資源。信中指出，五家註冊機構均依據區域採納的規則，或一致通過的全球政策，履行號碼資源管理職能。（nro.net）
同一封信批評了Cloud Innovation的訴訟，稱其已提起超過25起訴訟，抱怨法院命令凍結AFRINIC賬戶並叫停選舉，還表示AFRINIC曾多次請求毛里求斯承認其爲國際組織。NRO敦促政府採取措施，維護AFRINIC的獨立性和非洲互聯網的穩定。（nro.net）
這是整個事件中最能說明問題的文件。
當一傢俬營註冊機構與普通法院發生衝突時，體系的本能反應不是收窄授權。
不是解除對註冊機構的鎖定。
不是把記錄維護與強制執行分開。
不是規定分佈式驗證。
也不是追問：對運行中資產的單方面註銷權，是否從一開始就缺乏正當性。
它的本能反應，是向上逃逸。
一個私營協調機構，不能在想要裁量權時自稱技術機構，想要正當性時自稱以社羣爲基礎，想要收費時訴諸合同，想要逃避所有權責任時聲稱資源不是財產，想要隔絕法院時又擺出準國際組織的姿態。
這套組合不是治理。
這是系統層面的授權洗白。
RIR如果想要公法特權，就必須接受公法問責。如果想要私法的靈活性，就必須接受私法訴訟。它們不能合乎理性地同時要求私人裁量、公共基礎設施的重要地位、低責任、薄弱的代表機制、壟斷地位，以及準外交式的司法隔離。
這是一條通向災難的路。
運行代碼優先拒絕這條路。
註冊機構遇到法律阻力時，不能向上逃進豁免。架構必須向下收縮，回到那項曾爲其存在提供正當理由的狹義運行代碼職能。
更少主權。
註冊機構不再是有效性的來源。
更少強制執行。
更多分佈式驗證。
修訂ICP-2還不夠
現行體系知道，有些東西已經壞了。
ICANN關於《RIR治理文件》第二稿的公衆意見頁面指出，該提案將規定認可新RIR的規則與標準、RIR的運營義務與要求，以及撤銷認可的規則；如獲採納，它將取代ICP-2。同一頁面還指出，這一程序是在NRO要求ASO提出更新建議後啓動的，目的是讓RIR體系對互聯網社羣承擔更大的問責責任。（icann.org）
作爲維持連續性的措施，這可能是必要的。
但作爲正當性的理論，它遠遠不夠。
認可與撤銷認可的規則，回答的是一個事後問題：註冊機構失敗到什麼程度，才應被移除？
更早的問題才更重要：爲什麼註冊機構一開始就應當強大到足以造成災難性失敗？
ICP-2的繼任文件，如果只是強化認可、審計、交接和撤銷認可，也許能改善制度運行的規範程度，卻仍保留那個範疇錯誤。它依然假定，RIR是號碼資源協調的首要主權式形態。
運行代碼優先提出的是另一組問題。
如果一個RIR崩潰，互聯網如何繼續運行？
沒有現有機構的許可，號碼資源權利主張如何仍然可以驗證？
沒有壟斷性裁量，唯一性如何維持？
如何防止記錄變成強制執行的武器？
除非真正的全局不變量受到威脅，如何把商業決策留在確定性有效性規則之外？
完全沒有權威註冊機構時，協調如何仍然可用？
運營者如何驗證日常狀態，而不必向常設機構詢問資格狀態？
如何讓拒絕不被貼上違規標籤？
這些不是改革問題。
它們是後RIR問題。
爲什麼這是原始設計所需的補丁
問題不在於喜歡還是討厭現有註冊機構。
問題在於，號碼資源層是否仍然遵循那套讓互聯網得以運行的設計紀律：最低限度的共同規則、本地驗證、自願採納，以及運行中的代碼。
運行代碼優先不是公關策略，也不是制度妥協。它是原始設計本身所要求的技術修補。如果互聯網的構建，原本就是要拒絕把國王、總統和投票當成技術真相的來源，那麼號碼資源層就不能借註冊程序、歷史授權或社羣表演，把這些形式重新造出來。
單有共識，可以被儀式化。單有運行代碼，如果註冊層佔據認可流程的上游位置，也可以被置於從屬地位。缺失的規則，既關乎解釋，也關乎架構：當機構程序與運行中的系統所需的最低限度技術職能衝突時，運行代碼具有優先地位；提出後續變更時，它只有通過運行驗證規則的參與者自願採納，才成爲現實。
這是守住原始設計，而不是放棄它。
互聯網之所以重要，是因爲它成爲第一個無需事先獲得某個單一主權者、部委、教會、公司或守門人許可的全球通信系統。如果這個成就仍值得捍衛，註冊層就不能成爲吞掉原則的那個例外。
一個爲避免國王而構建的系統，不能讓記賬員來試演國王。
這個補丁恢復了原本的優先次序：代碼在先、運營者在先、確定性驗證在先、分佈式狀態在先；如果過渡期仍保留某些機構，它們也只能是沒有權威地位的輔助產物，絕不能是有效性的來源。
後RIR協調需要什麼
後RIR協調不意味着混亂。
它意味着，相比現有RIR壟斷，共同層變得更精簡、更客觀、更具確定性，也更加分佈式。
沒有另一個註冊機構可供遷入。
沒有一個新註冊機構需要加冕。
沒有一羣取而代之的新祭司。
有的是一份號碼資源狀態的分佈式賬本，以及確定性驗證規則、控制權證明機制、衝突處理、兼容集合、狀態轉換歷史和參與者的本地驗證。
共同層應當保留標識符唯一性、控制權證明、轉讓狀態、委派狀態、與路由相關的安全聲明、可審計性、衝突元數據和分叉可見性。
運營者層應當掌握商業使用、租賃、客戶地域、路由實踐、融資、交易對手選擇，以及不涉及不變量的商業規則。
採納層應當決定什麼成爲現實。一項協調規則，只有在運營者能夠實現、交易對手能夠接受、市場能夠依賴、法院能夠理解，而且能在不把現有機構的認可變成現實唯一來源的情況下保持互操作時，纔有意義。
強制執行層絕不能與狀態層合併。分佈式賬本可以記錄狀態。可以驗證轉換。可以揭示衝突。可以讓證明具有可攜帶性。但它不能同時成爲檢察官、法官、制裁機關、市場監管者、商業道德審判者和資產保管人。
最重要的是，必須正確理解可攜帶性。
在分佈式賬本的世界裏，可攜帶性不是從一家註冊機構遷到另一家。這仍然是註冊機構思維。沒有另一個註冊機構可供遷入。持有人的控制權證明、狀態歷史和轉讓能力，不會被困在現有機構的數據庫內。它們存在於共享、可驗證的狀態中，由參與者在本地驗證，由交易對手自願接受。
沒有這一點，每一家註冊機構都是鎖定點。
有了這一點，註冊機構就不再是有效性的來源。
因此，後RIR協調需要四項設計屬性。
第一，確定性有效性。參與者應當能夠在本地應用規範，判斷一項狀態轉換、證明、委派、轉讓或聲明是否有效。
第二，兼容集合。如果參與者採納了不同的後續規則，系統應當清楚描述兼容邊界，而不是把分歧視爲不當行爲。
第三，分佈式控制權證明。持有人不應把資源“遷移”到另一家註冊機構；它應當通過賬本規則下的有效狀態證明控制權，使任何交易對手無需現有機構首肯，就能驗證。
第四，分叉可見性。如果規則集發生分歧，分歧應當明確呈現。參與者決定運行哪個兼容集合，接受哪些交易對手。分叉可能使參與者彼此隔離。但它不會賦予任何一方藉機構權力抹去另一方的能力。
這不是在主張五個更好的壟斷。
這是在反對把壟斷當成有效性的來源。
爲什麼失敗路徑可以預見
如果什麼都不改變，失敗路徑很清楚。
第一，更多爭議會從政策會議室走進法院。稀缺資產會引來法律審視。法院將被請求凍結賬戶、保全記錄、阻止不當選舉、任命接管人、確認轉讓，或裁定誰可以代表註冊機構行事。
第二，各國將不再把RIR視爲無害的技術協會。號碼資源的連續性涉及國家網絡連通、制裁、執法、電信韌性、雲基礎設施和經濟安全。沒有哪個國家會永遠接受一個未經審視的外國私營註冊機構殼體，成爲本國通信連續性的上游節點。
第三，運營者會在可能的地方繞開註冊權威。如果註冊記錄變得政治化、不安全、缺乏代表性，或與資產現實脫節，運營者就會依賴私人合同、訴訟支持的轉讓、替代性證明、國家認可，或事實上的路由現實。
第四，ICANN和NRO層會受到進一步集中權力的誘惑。除非授權本身被收窄，否則那隻會製造同一問題的更厚重版本。
第五，政府會受到將其國家化的誘惑。這既可以預見，也很危險。如果私營註冊機構聲稱擁有準主權權威，卻不承擔公共問責，各國最終會收回主權。結果可能是碎片化、報復、相互衝突的註冊體系，以及政治性的路由壓力。
互聯網並不只在數據包停止傳送時纔算失敗。
當那些描述誰能使用標識符的機構，失去傳送數據包的運營者的信任時，互聯網也在失敗。
分佈式賬本不能解決所有政治問題。它能做一件更重要的事：讓常設註冊機構不再是日常有效性的來源。這會縮小攻擊面，削弱機構的挾持能力，把未來的分歧變成兼容性選擇，而不是行政戰爭。
問題變了
舊體系問的是：誰擁有授權？
這個問題問錯了。
更好的問題是：運行中的代碼究竟需要什麼？
這項規則是否保護唯一性？
是否保持互操作性？
是否通過確定性證據糾正能夠證明的註冊欺詐？
是否保護與路由相關的安全？
是否維護控制權證明的準確性？
是否支持本地驗證？
是否消除對某一個現有機構的依賴？
它是在描述已經被採納的現實，還是宣告尚未被採納的義務？
參與者能否拒絕它，而不被判定爲無效？
參與者能否驗證日常有效性，而不必向註冊機構詢問資格狀態？
交易對手能否自願接受或拒絕狀態？
能否發生分叉，而不讓某一方被機構抹去？
如果答案不能與運行代碼在確定性上的必要要求相聯繫，這項權力就不應存在於共同層。
這就是運行代碼優先。
供討論
這個提案是爲了展開討論。它不是最終定案。
下一步，應當是一份嚴肅的Internet-Draft或BCP式文件，從號碼資源開始，爲互聯網協調體系定義運行代碼優先。草案不應問如何修復RIR壟斷，而應問如何通過分佈式賬本狀態、確定性驗證、自願採納、交易對手接受和明確的兼容集合，構建後RIR協調。
它應當接受運營者、律師、經濟學家、協議工程師、路由安全專家、市場參與者、政府和批評者的檢驗。
草案應當提出尖銳的問題。
全局不變量是什麼？
哪些驗證規則是確定性的？
哪些狀態轉換必須在全球可見？
哪些舊有註冊權力只是歷史殘留？
哪些決策屬於運營者？
哪些決策不需要代表機制，因爲它們根本不應進入共同層？
拒絕的路徑是什麼？
分叉的路徑是什麼？
本地拒絕的路徑是什麼？
沒有現有註冊機構，持有人如何證明控制權？
沒有註冊機構，交易對手如何驗證狀態？
如果一個RIR崩潰，互聯網能否繼續運行？
沒有現有機構的許可，號碼資源能否保持唯一性？
沒有常設機構，參與者能否驗證日常狀態？
政策程序能否區分運行代碼的不變量與機構的權力慾望？
舊註冊層能否消失，而不丟失可驗證狀態？
記錄能否描述現實，而不成爲凌駕於現實之上的主權者？
有興趣的人可以通過LinkedIn聯繫我。願意幫助把這一構想推進爲首份Internet-Draft，並在社羣認爲有用的前提下，最終推進到RFC或BCP討論的嚴肅研究者、技術作者、機構或政策專家，請與我聯繫。LARUS基金會和我願意支持並資助這一方向上的嚴肅研究。
RIR體系最初的設計之所以失敗，是因爲它從未問過，運行中的代碼究竟需要什麼。
它問的是，誰能在會議室裏發言。
下一套體系，必須把這個順序倒過來。
不要授權洗白。
不要背叛運行代碼。
運行代碼優先。
附錄：互聯網協調體系的初始規範最小化、後續決策本地化與自願採納
摘要
本文描述了一種互聯網協調體系的設計模式，其目的是提供共享的技術參照點，而不在運行系統的參與者之上設立一個持續存在的權威。本文定義了三項相互關聯的原則：初始規範最小化、後續決策本地化與自願採納。
在這一模式下，初始規範只定義唯一性、互操作性、控制權證明、共同安全與安全防護所需的確定性規則，而且這些規則可以在本地驗證。初始規範確立之後，後續變更不由中央機構批准，而是由運行代碼的參與者採納、忽略、分叉或放棄。
這一設計模式所指向的是有效狀態的分佈式賬本，或等效的分佈式可驗證狀態機制，而不是註冊機構的層級體系。不存在一個決定日常有效性的常設註冊機構。參與者在本地驗證狀態，自願接受交易對手，並決定自己運行哪些兼容集合。
不採納不是違規。不採納後續變更的參與者，仍留在原有兼容集合中。如果某個參與者發出的狀態，依照另一個參與者接受的確定性規則並不有效，後者可以在本地忽略它。產生的效果是兼容性選擇、分叉、隔離或選擇性互操作，而不是機構懲罰。
本文不定義線上傳輸協議。它爲協議、標識符體系、分佈式賬本以及協調機制的設計規定了一套最佳現行實踐；這些系統不得演變爲永久治理機構。
1. 引言
許多互聯網系統起初只有一項狹義技術目的：通過共享參照點、標識符空間、驗證規則、賬本狀態或控制權證明記錄，使彼此獨立的行動者能夠互操作。隨着時間推移，這類系統往往積累起初始互操作並不需要的權威。
這通常分三步發生。
第一，在技術上尚無必要之前，就把未來的問題放進創設層。
第二，本應由運行各自系統的參與者作出的選擇，開始依賴某個持續存在的機構所作的認可、解釋或資格狀態決定。
第三，發佈、註冊、建議或程序性批准，被視爲足以產生運行義務，即便參與者尚未在運行中的系統裏採納這項變更。
結果是一個脆弱的系統。技術參照層變成治理層。記錄維護者變成守門人。協調輔助產物變成未來控制權的來源。
本文提出另一套設計紀律：
- 初始規範最小化：只規定基本互操作性、唯一性、控制權證明、共同安全與安全防護所需的確定性共同規則。
- 後續決策本地化：初始規範確立之後，後續選擇仍由運行代碼的參與者作出。參與者可以採納、拒絕、分叉、斷開連接，或選擇性互操作。任何參與者都不能改變那些繼續運行彼此兼容規則的其他參與者之間的互操作。
- 自願採納：後續變更只有經過實現、運行、驗證，以及運行代碼的參與者的採納，才成爲現實。
這些原則相互關聯。一個系統如果在一開始規定得太多，就把未來的控制權預先裝進了共同層。如果保留持續的認可層，就允許權威在部署之後重新出現。如果把發佈當成現實，就把文檔變成了命令。
設計直覺很簡單：有效性必須由確定性規則來判定，參與者能夠對照共享狀態，在本地驗證這些規則。參與者可以採納後續變更、拒絕它、分叉、斷開連接，或選擇性互操作。它最多隻能讓自己退出一個兼容集合。它不能因爲拒絕一項變更，就破壞那些繼續運行彼此兼容代碼的其他參與者之間的互操作。
這是分佈式賬本設計的一般性教訓：共識規則由運行驗證代碼、決定接受何種狀態的參與者執行，而不是由凌駕於他們之上的機構執行。
2. 範圍
本文適用於互聯網協調體系，包括但不限於標識符體系、命名與編號框架、協議擴展機制、控制權證明系統、可攜帶性系統、分佈式賬本，以及其他由獨立行動者依賴共同技術參照點的架構。
本文不反對共同規則。它主張，共同規則應具有確定性、保持最小化、可在本地驗證，並且僅限於系統實際運行所必需的內容。
本文不要求採用任何特定的分佈式賬本實現。它要求的是一種設計屬性：參與者應當能夠在本地對共享或可複製的狀態應用初始規範，判定有效性，而無需向常設權威請求許可或詢問資格狀態。
3. 約定與定義
3.1. 要求用語
本文原文中以大寫形式出現的要求用語，應按照BCP 14，具體而言是RFC 2119和RFC 8174所定義的含義理解；本譯文分別以“必須”“不得”“應當”“不應”和“可以”表達相應的要求等級。
3.2. 術語
初始規範：
系統首次部署所需的規則、數據結構、格式、不變量、驗證程序、狀態轉換規則和衝突規則的集合。
共同層：
獨立參與者實現互操作所需的最低限度共享規則集或參照結構。共同層不是機構，而是參與者實現並驗證的技術內容。
分佈式賬本：
以複製或其他分佈式方式保存的狀態轉換記錄，使參與者無需依賴常設註冊機構、委員會或其他權威，就能驗證日常有效性。這一術語不要求採用任何特定的共識算法或實現。
確定性驗證規則：
一種使參與者能夠通過本地計算或本地驗證，判斷某個狀態、記錄、轉換、聲明或消息在指定規則集下是否有效的規則。
全局不變量：
爲了保持唯一性、基本互操作性、控制權證明的完整性、共同安全或安全防護，必須在一個兼容集合內保持一致的屬性。
參與者：
運行、驗證、部署或依賴該系統的運營者、實現、節點、網絡、組織或其他行動者。
兼容集合：
一組參與者，其實現的驗證規則允許彼此互操作。如果部分參與者採納後續變更，而其他參與者不採納，這項變更可能產生一個新的兼容集合。
採納：
運行系統的參與者實際進行的實現、部署、驗證和使用。
交易對手接受：
參與者依照自己運行的驗證規則，自願決定接受另一參與者的狀態、與之交易、與之互操作，或依賴該狀態。
不採納：
參與者選擇不實現或不使用一項提議中的變更。不採納不會產生無效身份。它僅意味着，該參與者尚未加入這項變更產生的兼容集合。
本地拒絕：
參與者在本地決定忽略、拒絕某個狀態、消息、記錄或轉換，或不與之互操作，因爲它依照該參與者運行的驗證規則屬於無效或不兼容。
分叉：
驗證規則或運行實踐發生分歧，從而產生兩個或更多兼容集合。
協調輔助產物：
幫助參與者協調的文件、建議、實現說明、配置規範、參考實現、賬本瀏覽器、鏡像或其他產物。除非參與者在運行中的系統裏採納它，否則協調輔助產物不會產生具有約束力的運行現實。
4. 問題陳述
設計者常常試圖通過在創設層寫入過多內容，或留下一個持續存在的機構來解釋未來問題，以降低未來的不確定性。這看似審慎，往往卻很危險。
在創設層過度規定，有三項代價。
第一，它把未來選擇移入共同層，使變更更難，也使機構俘獲造成的影響更大。
第二，它造成技術有效性與機構認可之間的含混。
第三，它鼓勵維護記錄、發佈文件或召集參與者的機構，把這些行爲視爲支配未來現實的權威。
同一問題也會在部署之後出現。如果系統需要一個持續存在的機構來批准變更、判定資格狀態，或解釋日常運行，那麼系統就創設了一個在成立之後繼續控制的層。這個層可能從行政管理起步，繼而變成治理，再變成瓶頸。
本文的設計目標，不是更好的機構裁量。設計目標是避免需要這種裁量。
設計良好的互聯網協調體系，應當從一開始就定義確定性、可在本地驗證的有效性規則；以分佈式或其他可複製的形式表示有效狀態；把不涉及不變量的選擇留在共同層之外；並且只有當參與者在運行中的系統裏自願採納時，才讓後續變更成爲現實。
5. 原則一：初始規範最小化
5.1. 原則表述
初始規範應當只定義基本互操作性、唯一性、控制權證明、共同安全與安全防護所需的最低限度確定性共同規則。
5.2. 要求
採用這一原則的設計：
- 必須明確識別其全局不變量。
- 必須爲每一個全局不變量定義確定性驗證規則。
- 必須定義有效狀態如何表示、複製、驗證和更新。
- 不得把一項規則放入初始規範，除非它是保持某個已聲明的全局不變量，或實現首次部署所必需的。
- 必須把驗證規則與政策偏好、商業安排、機構角色、治理願景及酌情判斷分開。
- 必須允許參與者在本地驗證日常有效性，而無需詢問任何機構、註冊機構、委員會、政策組織或其他權威。
- 應當定義本地驗證所需的數據結構、簽名、證明、狀態轉換規則、衝突規則或其他機制。
- 在可以預見未來差異時，應當定義擴展信令、版本管理、兼容性標籤或分叉標識。
- 必須確保必要的協調輔助產物具有可攜帶性、可審計性、可復現性和可替換性。
- 應當優先採用客觀、機器可驗證的條件，而非主觀的優劣判斷。
- 不得使未來的機構認可成爲有效狀態能夠被知曉、記錄或使用的唯一途徑。
5.3. 設計含義
初始規範最小化，不意味着規範含糊。它意味着，只對必須共同遵守的內容作嚴格規定。
系統仍然需要足夠的共同結構才能運行。這套紀律要求區分：
- 爲了唯一性、互操作性、控制權證明、共同安全與安全防護，哪些內容必須共同遵守；以及
- 哪些內容涉及運營者偏好、商業實踐、交易對手選擇、部署時機或後續採納選擇，因此可以留在共同層之外。
如果一項設計無法清楚說明其全局不變量和確定性驗證規則，就應當假定，它規定了過多的裁量，卻規定了過少的可驗證內容。
6. 原則二：後續決策本地化
6.1. 原則表述
初始規範確立之後，後續決策應當留在運行代碼的參與者本地。後續決策只對其參與者採納了該決策的兼容集合生效。不需要持續存在的權威來批准，不採納也不會產生無效身份。
6.2. 要求
採用這一原則的設計：
- 對於不改變參與者所在兼容集合的確定性驗證規則的選擇，不得要求參與者取得現有機構、註冊機構、委員會、董事會、政策組織或其他權威的許可。
- 不得設立一個常設機構，使其認可成爲後續變更在實際運行中成爲現實的唯一途徑。
- 必須區分依照初始規範成立的有效性，與對後續可選變更的兼容性。
- 不得把不採納後續變更視爲無效。
- 必須允許不採納後續變更的參與者留在原有兼容集合中。
- 必須允許參與者通過採納新的驗證規則或運行配置規範，加入新的兼容集合。
- 必須允許參與者在本地拒絕那些依照其運行的驗證規則屬於無效或不兼容的狀態、記錄、轉換或消息。
- 必須允許參與者根據自己接受的驗證規則與兼容集合，自願選擇交易對手。
- 不得授權任何機構、註冊機構、委員會、政策組織或其他行動者，僅僅因爲參與者拒絕了後續變更，就宣佈該參與者無效。
- 應當明確標示分叉、版本、配置規範或兼容集合，使參與者知道自己運行哪些規則，以及能與哪些其他參與者互操作。
- 應當避免任何允許現有記錄維護者阻止本來有效的參與者繼續互操作的設計。
6.3. 設計含義
後續決策本地化，不意味着由中央權威把未來決策分配給本地行動者。它意味着，系統在設計上就保證，初始規範確立之後，通常的後續選擇不需要這種分配。
初始規範預先完成劃界工作。它定義唯一性、互操作性、控制權證明、共同安全與安全防護所需的最低限度不變量。其他一切，都留在共同層之外。
後續變更不由中央批准。它由運行代碼的參與者採納、忽略、分叉或放棄。
拒絕一項變更的參與者，可以留在該變更產生的兼容集合之外。它可以斷開自己與其他參與者的連接。它可以繼續留在較舊的兼容集合中。它可以分叉。它可以選擇性互操作。但它不能破壞那些繼續運行彼此兼容規則的其他參與者之間的互操作。
無效或不兼容狀態產生的效果，是本地拒絕，而不是懲罰。不需要任何人裁定某個參與者屬於違規者。運行兼容驗證規則的參與者，只是不接受無效或不兼容的狀態。
7. 原則三：自願採納
7.1. 原則表述
互聯網協調體系的變更，應當通過實現、驗證、部署、交易對手接受和參與者採納，在實際運行中成爲現實，而不是僅靠發佈或宣告。
7.2. 要求
採用這一原則的設計：
- 不得把發佈、建議、會議批准或程序性批准，視爲足以產生普遍運行義務的行爲。
- 必須允許選擇運行新規則、擴展、配置規範或程序的參與者，以漸進方式部署它們。
- 必須允許參與者拒絕後續變更而不被賦予無效身份，只要其自身狀態轉換滿足所在兼容集合的確定性驗證規則。
- 在初始規範允許持續使用的情況下，必須允許參與者繼續使用較舊的兼容集合。
- 規則不兼容時，必須允許運行一個兼容集合的參與者，在本地拒絕或忽略來自另一個兼容集合的狀態。
- 應當爲重大變更定義採納路徑，包括版本信令、兼容性標籤、過渡指引和測試向量。
- 應當爲重大變更定義拒絕路徑，包括不採納的參與者如何繼續運行、標明自己的兼容集合，以及避免含混的互操作。
- 必須確保必要的協調輔助產物可以被退出、鏡像、重新實現或替換，而不會產生無法承受的過渡成本。
- 記錄、建議和協調輔助產物，應當描述已經被採納的現實，而不是試圖通過宣告，使尚未被採納的未來現實憑空成立。
- 必須避免把系統設計成只有先獲得現有機構認可，變更才能成爲現實。
7.3. 設計含義
自願採納，是檢驗一項變更是否有用、可以接受，並與真實部署兼容的運行標準。
提案不是現實。建議不是現實。文件不是現實。參與者實現、驗證、部署、接受交易對手，並依賴這項變更時，現實才出現。
不採納不會產生違規身份。它只產生一個事實：該參與者沒有加入這項變更產生的兼容集合。
這並不消除標準制定程序、文檔、實現說明、瀏覽器、鏡像或審查。它只是限制它們能主張什麼。它們可以幫助參與者協調。可以發佈參考資料。可以描述採納情況。可以提出建議。但它們不能僅憑宣告，就讓尚未被採納的未來現實，約束那些並未運行它的參與者。
8. 三項原則之間的關係
三項原則相互強化，單獨採用並不能奏效。
初始規範最小化，確保共同層包含的是確定性驗證規則，而不是裁量權威。
後續決策本地化，確保後續選擇仍由運行代碼的參與者掌握，而不會被中央審批層重新收走。
自願採納，確保後續變更必須經得起實現、驗證、交易對手接受和實際使用的檢驗。
只採用其中一項或兩項原則的系統，可能以其他方式重現同樣的中心化。
- 只有初始規範最小化，沒有後續決策本地化，仍可能讓權威在部署之後積累。
- 只有後續決策本地化，沒有初始規範最小化，可能造成含混，因爲參與者無法在本地判定有效性。
- 只有自願採納，沒有確定性驗證，可能造成混亂，因爲參與者無法區分兼容的差異與無效狀態。
- 只有確定性驗證，沒有分佈式狀態，仍可能使參與者依賴具有特權的記錄維護者。
- 只有分佈式狀態，沒有分叉可見性，可能把分歧隱藏起來，直到實際運行失敗。
- 只有分佈式狀態，沒有自願接受交易對手，可能通過另一個接口重建強制。
這些原則共同構成的系統，共同層精簡、有效性可在本地驗證、後續變更自願、狀態分佈式保存，而且不需要常設機構來裁定日常運行。
9. 推薦設計模式
9.1. 確定性的分佈式共同層
共同層應當僅限於：
- 穩定的標識符語義；
- 確定性有效性規則；
- 保持唯一性所需的衝突解決規則；
- 控制權證明機制；
- 狀態轉換規則；
- 線上傳輸層面或協議層面的互操作要求；
- 共同安全不變量；
- 可攜帶、可審計的狀態格式；
- 分佈式或複製狀態的可見性；
- 擴展信令與兼容集合標識。
共同層不應包含：
- 商業模式規則；
- 定價規則；
- 區域政治偏好；
- 與技術不變量無關的資格意識形態；
- 酌情強制執行權；
- 主觀優劣評估；
- 機構使命擴張；
- 任何主要功能在於維持現有機構權威的規則。
9.2. 運營者的決策範圍
以下事項應當留在共同層之外，除非它們直接改變某個已聲明的全局不變量：
- 部署時機；
- 商業使用；
- 客戶地域；
- 租賃、融資或轉讓安排；
- 本地資格偏好；
- 運行步驟的先後順序；
- 共同有效性並不要求的路由實踐；
- 商業模式；
- 組織結構；
- 自願遷移的時機；
- 可選配置規範或擴展；
- 交易對手選擇。
參與者可以在這些領域作出不同選擇。這些選擇可能產生不同的兼容集合、商業關係、對等互聯安排或運營社羣。除非違反某個兼容集合內的確定性驗證規則，否則它們不會造成無效。
9.3. 採納循環
在可行的情況下，重大系統變更的優選順序是：
- 提案；
- 實現；
- 測試向量或確定性驗證方法；
- 由自願參與者進行有限部署；
- 觀察互操作性與安全效果；
- 標示兼容集合；
- 以文檔或建議描述已經被採納的現實。
協調輔助產物應當跟隨採納，而不是試圖先行替它作決定。
9.4. 分叉、本地拒絕與交易對手接受
符合本文的設計，應當把分叉、本地拒絕和交易對手接受視爲正常設計要求，而不是失敗。
系統應當定義參與者如何能夠：
- 繼續留在較舊的兼容集合中；
- 採納較新的兼容集合；
- 分叉進入不同的兼容集合；
- 不依賴現有記錄維護者而驗證狀態；
- 自願接受交易對手；
- 在本地拒絕無效或不兼容的狀態；
- 在兼容性允許時，選擇性互操作。
如果一個系統無法在不破壞有效運行的情況下被分叉、在本地驗證或被選擇性接受，那麼它很可能把治理權力藏進了記錄維護職能。
10. 適用性與侷限
這一設計模式尤其適用於以下情況：
- 系統涉及多個行動者和多個司法轄區；
- 獨立部署十分重要；
- 協調層預期保持精簡；
- 未來很可能出現差異，但無法詳細預測；
- 鎖定會造成治理風險；
- 有效性可以被設計爲確定性的，或可在本地驗證；
- 分佈式狀態能夠降低機構俘獲風險。
在以下情況下，它可能較難直接適用：
- 預期架構就是單一管理域；
- 強實時耦合要求始終保持一致行爲；
- 生命安全問題要求立即實現全球一致；
- 沒有任何實用機制能夠在本地驗證有效性。
即便在這些情況下，設計者仍應當儘可能縮小共同層，並在可能的地方避免對未來的酌情控制。
11. 非目標
本文並不：
- 禁止一切協調；
- 要求任何特定的分佈式賬本實現；
- 保證共識；
- 保證政治中立；
- 要求所有參與者採納每一項後續變更；
- 把拒絕採納視爲無效；
- 爲一邊聲稱兼容、一邊採取不兼容本地行爲的做法賦予正當性；
- 消除對安全至關重要的共同規則的需要。
12. 安全考慮
更精簡的協調層，可以降低俘獲風險、縮小機構錯誤的波及範圍，並提高可替換性。然而，更大的本地裁量與分佈式狀態，也可能造成不一致的安全態勢、降級路徑、碎片化壓力、含混的兼容性主張、不安全的分叉、賬本狀態爭議，以及僞造證明的企圖。
因此，應用本文的設計者必須明確規定安全不變量。具體而言：
- 共同有效性所必需的身份認證與授權要求，必須是確定性的，而且可在本地驗證；
- 控制權證明機制必須能夠抵禦僞造、重放和未經授權的轉讓；
- 在安全受到影響時，版本協商與擴展處理必須避免靜默降級；
- 必須分析拒絕、分叉和替換路徑中的濫用與拒絕服務風險；
- 兼容性標籤應當足夠清晰，以防止不兼容規則集之間發生意外互操作；
- 分佈式狀態應當具有足夠的可審計性和可復現性，以檢測不一致的視圖；
- 不得允許本地差異虛假聲稱兼容某個它並不滿足的規則集。
安全例外的存在，不能爲一個普遍許可層提供正當理由。它只能爲保持已聲明的全局不變量所必需的確定性安全規則提供正當理由。
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. 設計檢查清單
聲稱符合本文的設計，應當能夠清楚回答以下問題：
- 全局不變量是什麼？
- 哪些確定性驗證規則保持這些全局不變量？
- 初始規範中的哪些規則，是首次部署嚴格必需的？
- 有效狀態如何表示和驗證？
- 狀態是否以分佈式、複製或其他可獨立驗證的方式保存？
- 哪些未來問題被有意留在共同層之外？
- 參與者可以作出哪些後續選擇，而不改變自己所在的兼容集合？
- 參與者如何採納後續變更？
- 參與者如何拒絕後續變更，而不被判定爲無效？
- 兼容集合如何被標示或發現？
- 狀態依照參與者運行的規則屬於無效或不兼容時，本地拒絕如何運作？
- 分叉路徑是什麼？
- 沒有現有記錄維護者，持有人如何證明控制權？
- 沒有註冊機構，交易對手如何驗證狀態？
- 參與者能否不依賴現有記錄維護者，就驗證日常有效性？
- 記錄與協調輔助產物是在描述已經被採納的現實，還是試圖通過宣告，使尚未被採納的未來現實憑空成立？
- 系統是否已將嵌入共同層的決策數量降到最低？
- 系統是否避免了任何判定參與者日常資格狀態的持續性權威？
- 參與者能否自願接受或拒絕交易對手？
- 如果所有現有註冊機構都消失，系統能否繼續運行？
作者地址
- Lu
[TBD]