newsence
來源篩選

ERC: Modular Dispatch Proxies

Ethereum Magicians

This is a minimalist standard for modular dispatch proxies. Similar standards include ERC-1538 (Withdrawn) ERC-2535 (Final) ERC-8109 (Withdrawn) ERC-8153 (Draft) This is designed to be a minimum standard to allow innovation in this model while providing a shared framework to help wallets and explorers. I hope future standards will find this one extensible and build for compatibility. I am compiling a list of compatible extensions and plan to keep the list below up to date. Compatible extensions: ERC-1538 (Withdrawn) ERC-2535 (Final) ERC-7201 (Final) ERC-7546 (Draft) ERC-8042 (Final) ERC-8049 (Draft) ERC-8109 (Withdrawn) ERC-8110 (Draft) ERC-8152 (Draft) ERC-8153 (Draft) Links: Prior discussion PR: Add EIP I plan to provide a reference implementation. At this stage I am seeking feedback, especially from those who have experience building these or their tooling. 1 post - 1 participant Read full topic

newsence

ERC：模組化調度代理標準

Ethereum Magicians
8 天前

AI 生成摘要

這是一個針對模組化調度代理的極簡標準。其設計旨在提供一個共享框架以協助錢包和瀏覽器，同時允許在此模型中進行創新，我希望未來的標準能發現此標準的擴展性並建立相容性。

ERC：模組化調度代理 (Modular Dispatch Proxies) - ERCs - Fellowship of Ethereum Magicians

摘要

本提案定義了一種標準，用於開發具備可擴展功能的代理合約。該標準透過將函數調度邏輯與合約存儲分離，實現了模組化架構。這使得開發者能夠在不重新部署整個代理合約的情況下，動態地添加、移除或更新特定的功能模組。

動機

現有的代理模式（如透明代理或 UUPS）雖然允許升級，但通常受限於單一的實作合約。隨著去中心化應用程式（dApps）變得日益複雜，對於能夠以模組化方式管理不同功能的需求也隨之增加。本標準旨在提供一種統一的方法，讓代理合約可以根據函數選擇器（function selectors）將調用路由至多個實作合約（模組）。

規範

核心組件

  1. 調度代理 (Dispatch Proxy)：負責接收外部調用並根據預定義的映射表將其轉發至相應模組的主合約。
  2. 模組 (Modules)：包含特定業務邏輯的智慧合約。
  3. 註冊表 (Registry)：維護函數選擇器與模組地址之間映射關係的組件。

函數路由邏輯

當調度代理收到調用時，它必須：

  1. 提取調用數據中的前四個位元組（函數選擇器）。
  2. 在註冊表中查詢與該選擇器關聯的模組地址。
  3. 使用 delegatecall 將調用轉發至該模組。
  4. 將結果（或錯誤）回傳給調用者。

介面定義

solidity
interface IModuleRegistry {    event ModuleUpdated(bytes4 indexed selector, address indexed oldModule, address indexed newModule);    function getModule(bytes4 selector) external view returns (address);    function updateModule(bytes4 selector, address module) external;}

理由

  • 靈活性：允許針對不同功能使用不同的實作合約。
  • 可擴展性：可以輕鬆添加新功能，而不會影響現有邏輯。
  • 效率：減少了單一大型實作合約可能面臨的代碼大小限制（Spurious Dragon 限制）。

向後相容性

此標準與現有的 delegatecall 代理模式完全相容。現有的合約可以透過實作相應的註冊表邏輯來遷移至此架構。

安全考量

  • 存儲衝突：開發者必須確保不同模組之間不會發生存儲插槽（storage slot）衝突。建議使用隨機化存儲佈局或結構化存儲。
  • 權限控制：updateModule 函數必須受到嚴格的存儲管理或治理機制保護，以防止未經授權的功能替換。