獨立和解協議文件索引。
過去幾個月，我在以太坊主網部署了一系列獨立的智慧合約協定。每個協議都已完成、不可篡改且無所有者。每個協議都只做一件事。
本文介紹 Substrate：它既不是協議，也不是框架，更不是套件，而是一個文件索引。在這裡，這些協議被簡要描述、單獨鏈接，並展示了它們如何相互協調——即使它們彼此獨立，互不依賴。
每個協議是什麼
本合集中的每個協議都遵循相同的結構模式：
代表鏈上實體或數位物件或資產的 ERC 原語
不可竄改的智能合約，用於處理中立、確定性的結算
這就是完整的架構。沒有治理機制，沒有升級空間，也沒有所有者。每個協定都已部署，並在 Etherscan 上驗證，然後放棄所有權。它們無需我或任何其他人參與即可運行。
每個協議還有一個獨立的快速入門模板庫。這些範本是參考實現，提供了直接且有文件記錄的建置路徑，無需透過任何平台或中間件即可基於每個協定進行建置。
協定
DeDe ：包裹結算。 P2P取件、投遞及送達確認。 ERC-721包裹基本協議，外加託管和簽署人登記。
DROP ：實體儲存結算。在儲存節點接收、保管和釋放實體貨物。 ERC-721 儲存會話原語，並可選配託管功能。
CUT ：數位所有權和版權結算。任何數位媒體的部分或全部所有權。 ERC-1155 媒體基元加上場景註冊。
KEY ：車輛所有權與銷售結算。基於 ERC-721 車輛身份錨點，並採用原子性銷售結算。在車輛登記機構開放 API 的司法管轄區，基於 KEY 建構的平台可以從去中心化端發起具有法律效力的所有權轉移。登記機構無法發起或修改 KEY 交易。該橋接是單向的。
STAY ：商品結算。商品資產和使用權的代表和結算。
ACT ：實體服務結算。指任何現實世界服務的協議簽訂、交付、確認和結算。規模和背景與該協議無關。
獨立設計
這些協定彼此互不相知。它們之間沒有共享狀態、沒有內部耦合、也沒有公共協調器。每個協定都可以在完全隔離的環境下部署並正常運作。
它們共享一種設計模式和一位作者。僅此而已，它們之間並無其他關聯。
這一點值得明確說明，因為人們看到一系列協議時，很容易將它們理解為必須協同使用的系統。但事實並非如此。物流平台可能只使用 DeDe 和 DROP 協議；媒體平台可能只使用 CUT 協議；車輛交易平台可能只使用 KEY 協議；旅行平台可能只使用 STAY 和 ACT 協議。這些平台都不需要其他協定就能正常運作。
之所以存在編排的可能性，是因為每個協定都是一個清晰、功能明確的原始元件。組合使用專用工具比使用單一工具試圖完成多項任務更能發揮其效用。但組合始終是平台決策，而非協議要求。
區塊鏈微服務
最接近的架構類比是微服務。每個協議都是一個獨立的、職責單一的服務，它暴露一個確定性的接口，並且對外部環境沒有任何干預。平台對這些協定進行編排，就像系統在上層編排獨立服務一樣，而無需修改服務本身。
與傳統微服務的差別在於其永久性。這些服務無法被維運人員關閉、修改或重新部署。它們是不可更改的基礎設施。部署時定義的穩定行為將永久保持不變。
這在實踐中意味著什麼
先前，在鏈上結算現實世界的交易要麼需要自行建立結算邏輯，要麼需要依賴控制支付通道的平台。而控制支付通道的平台可以收取費用、修改交易行為、限制存取權限，並且容易受到外部壓力的影響。
這些協議就像鐵軌，不受任何平台控制。協議費用不可更改，部署時即已設定。範本確保通往協議的直接路徑始終暢通且有文件記錄。任何平台都無法關閉這條路徑。
這並不意味著現有平台會過時。平台透過匹配、發現、用戶體驗和法律合規性來創造真正的價值。改變的是，平台底層的結算機制現在是中立的、永久的，任何人都可以使用。
這種選擇是存在的。這篇文章就是要討論這個。
基底
協議庫、範本庫、合約地址和編排範例都記錄在一個地方。
https://github.com/pablo-chacon/substrate
