ERC 討論:針對 ERC-3668 / CCIP Read 的標準化鏈上訪問控制

ERC 討論:針對 ERC-3668 / CCIP Read 的標準化鏈上訪問控制

Ethereum Magicians·

我想針對一項可能的 ERC 提案徵求回饋,該提案旨在為 ERC-3668 / CCIP Read 生態系統擴展標準化的鏈上訪問控制介面,以解決鏈下數據檢索的權限管理與透明度問題。

大家好,

我想針對一個可能的 ERC 提案徵求回饋,該提案旨在為 ERC-3668 / CCIP Read 生態系統擴展一個標準化的鏈下數據訪問權限控制介面。

背景

ERC-3668 透過 CCIP Read 實現了最小化信任的鏈下數據檢索。當關注點在於閘道器(Gateway)返回數據的真實性與可驗證性時,它的運作效果良好。

然而,ERC-3668 並未定義一種標準方式來限制「誰」可以訪問特定數據或觸發特定的鏈下查詢。

這在以下場景中成為實際問題:

  • 企業或私人數據集
  • 付費訂閱數據
  • 受限權限的服務
  • 計量或按次付費的 API

目前,閘道器運營商通常透過自定義 API 身份驗證或私有的白名單來解決此問題。但這會產生一些問題:

  • 訪問策略通常在鏈下執行
  • 閘道器運營商難以公開證明誰獲得了授權
  • 授權的授予與撤銷沒有透明地記錄在鏈上
  • 客戶端、閘道器和回調(Callback)合約可能無法基於相同的狀態評估授權

問題陳述

對於 CCIP Read,我們可能希望閘道器運營商在鏈上公開承諾一個授權模型,以便:

  • 授權與撤銷由鏈上交易記錄
  • 訪問決策是針對特定的區塊高度進行評估的
  • 客戶端、閘道器和回調合約都能得出相同的決策結果
  • 權限控制變得可組合且可審計,而非私有封閉

換句話說,目標不是取代 ERC-3668,而是定義一個可以與其並行使用的標準權限控制層。

核心思路

初步構想是標準化一個用於訪問驗證的最小化介面,同時允許在該介面後方使用多種授權模型。

可能的權限控制模型示例包括:

  • 獨立的主體註冊表 (Standalone principal registry)
    一個專用合約或繼承的模組,用於維護主體(Principals)及其授權狀態。

  • 基於 EAS 的證明 (EAS-based attestation)
    如果請求者持有符合特定策略的有效證明,則授予訪問權限。

  • 按次付費 / 類 x402 模型 (Pay-per-use / x402-like model)
    在支付後,或出示支付證明 / 使用權證明後授予訪問權限。

由於這些模型差異很大,我認為標準應避免強制規定單一的授權機制。相反,定義以下內容可能更好:

  • 一個通用的驗證介面
  • 將一個或多個權限控制模組綁定到 CCIP Read 流程的方法
  • 區塊一致性評估模型
  • 選用的元數據,以便客戶端發現正在使用哪種授權方案

這將使以下情況成為可能:

  • 為單個 CCIP 合約支持多種授權方案
  • 多個 CCIP 合約共享同一個授權方案

期望屬性

我認為此類標準應致力於實現的屬性:

  • 鏈上授權事實來源
    授予與撤銷應在鏈上體現。

  • 區塊一致性評估
    訪問權限應針對特定區塊高度進行評估,以便閘道器、合約和客戶端能基於相同狀態進行推理。

  • 可組合設計
    不同的訪問模型應能通過通用介面使用。

  • 對身份的最小假設
    主體可以是外部帳戶 (EOA)、智能合約帳戶,或潛在的其他經過驗證的角色。

  • 與 ERC-3668 兼容
    這應該是一個擴展層,而非替代品。

開放式設計問題

我特別希望針對以下問題獲得回饋:

  • 這應該是一個獨立的 ERC,還是專門圍繞 ERC-3668 構建的擴展?

  • 主體模型(Principal model)應該是什麼?
    授權應該僅針對類似 msg.sender 的角色定義,還是應該支持任意對象 / 委託人?

  • 驗證介面應該返回什麼?
    一個簡單的布林值?
    還是包含有效期、策略標識符或證明要求的更豐富結果?

  • 區塊一致性應如何標準化?
    是否應要求閘道器針對 CCIP Read 流程中包含的特定區塊高度進行評估?

初步範圍

我目前的直覺是,該提案應僅標準化:

  • 授權檢查的介面
  • 基於區塊驗證的語義
  • 權限控制結果如何與 CCIP Read 流程組合

而將實際的策略邏輯保持開放。

非目標

至少在初期,我認為此提案應嘗試標準化:

  • 通用的身份系統
  • 單一的規範白名單註冊表
  • 特定的支付管道
  • 特定的證明框架
  • CCIP Read 流程之外的傳輸層 API 身份驗證細節

為什麼這值得標準化

如果沒有標準,每個受限的 CCIP Read 部署都可能會發明自己的權限控制機制,這會降低互操作性並增加客戶端支持的難度。

一個通用的介面可以幫助錢包、客戶端、中間件、閘道器和合約以更可預測的方式整合受限的鏈下讀取。

我想徵求大家的回饋:這個問題是否足夠真實以支持標準化?如果是,最精簡且有用的標準會是什麼樣子?

如果有足夠的興趣,我可以隨後提供更具體的 ERC 草案結構和介面草圖。

謝謝。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-discussion-standardized-onchain-access-control-for-erc-3668-ccip-read/28306)

Ethereum Magicians

相關文章

其他收藏 · 0