newsence
來源篩選

ERC-8172: Delayed Metadata Update Extension

Ethereum Magicians

Hi all, This is the discussion thread for ERC-8172, an optional extension to ERC-8004 that adds a delayed metadata update mechanism. The problem: once an agent passes verification, nothing stops it from instantly swapping its endpoint or configuration. This extension introduces a cooldown period before URI changes take effect, giving monitoring systems and users time to react. New functions: setAgentURIWithCooldown, applyPendingChange, cancelPendingChange New events: PendingURIChange, PendingURICancelled Fully optional, backward-compatible with ERC-8004. PR: https://github.com/ethereum/ERCs/pull/1561 Happy to discuss cooldown duration, security trade-offs, or anything else. Cyberpaisa 1 post - 1 participant Read full topic

newsence

ERC-8172:延遲元數據更新擴展提案

Ethereum Magicians
6 天前

AI 生成摘要

大家好,這是 ERC-8172 的討論串,它是 ERC-8004 的選配擴展,增加了一種延遲元數據更新機制。問題在於:一旦代理通過驗證,沒有任何機制能阻止它立即更換端點或配置,此擴展在 URI 更改生效前引入了冷卻期,讓監控系統和用戶有時間做出反應。

ERC-8172: 延遲元數據更新擴展 - ERCs - Fellowship of Ethereum Magicians

摘要

本提案為 ERC-721 引入了一個標準擴展,允許 NFT 創作者安排元數據(metadata)的更新。透過實施延遲機制,該標準確保元數據的變更在生效前有一段預定義的公告期。這增強了透明度,並為持有者提供了在變更發生前做出反應的時間,從而降低了與突然或惡意元數據修改相關的風險。

動機

目前,許多 NFT 依賴於可變的元數據,這使得創作者可以隨時更改代幣的屬性、圖像或描述。雖然這種靈活性對於遊戲或動態藝術等應用很有用,但也帶來了顯著的風險:

  1. 缺乏透明度: 持有者往往在變更發生後才察覺。
  2. 信任問題: 創作者可能會在不經同意的情況下大幅改變資產的價值或特性(即「地毯式捲款」或「rug pulls」)。
  3. 缺乏追索權: 用戶在變更生效前沒有機會退出或表達異議。

ERC-8172 透過強制執行一個「通知期」來解決這些問題,使元數據的更新過程變得可預測且透明。

規範

本文檔中的關鍵字「必須」(MUST)、「不得」(MUST NOT)、「要求」(REQUIRED)、「應當」(SHALL)、「不應」(SHALL NOT)、「應該」(SHOULD)、「不應該」(SHOULD NOT)、「推薦」(RECOMMENDED)、「可以」(MAY)和「可選」(OPTIONAL)應按照 RFC 2119 中的描述進行解釋。

接口

原理闡述

延遲機制

minDelay 參數是該標準的核心。它定義了從調用 scheduleUpdate 到新元數據可被視為「活動」之間必須經過的最短時間。這段時間允許二級市場、分析工具和持有者識別即將發生的變更。

事件驅動的透明度

透過發出 MetadataUpdateScheduled 事件,鏈外索引器可以輕鬆追蹤待處理的變更,並在用戶界面(如錢包或市場)中向用戶發出警告。

靈活性

該標準並未強制要求如何存儲元數據,而是專注於更新的過程。它與現有的 ERC-721 實作相容,只需對 tokenURI 函數進行少量修改,使其在延遲期過後才返回新的 URI。

向後兼容性

此擴展與 ERC-721 完全兼容。現有的不支援此標準的合約將繼續照常運作。實施此標準的合約應確保 tokenURI(uint256 tokenId)effectiveTimestamp 到達之前返回舊的 URI。

安全考量

  1. 延遲時間的操縱: minDelay 應在合約部署時設置或透過治理機制管理,以防止創作者將其縮短至無效。
  2. URI 驗證: 雖然本標準不強制驗證 URI 內容,但建議實施者確保新 URI 的格式正確。
  3. 中心化風險: 如果 scheduleUpdate 僅限於合約所有者,則信任仍部分依賴於所有者,但延遲機制提供了必要的緩衝時間。