Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support for ERC-1967 Compliant Proxy Contracts Registration and Lookup #1336

Open
mshakeg opened this issue Apr 8, 2024 · 1 comment

Comments

@mshakeg
Copy link

mshakeg commented Apr 8, 2024

Summary:

This feature request proposes an enhancement to Sourcify's capabilities to include support for registering and looking up ERC-1967 compliant proxy contracts. By implementing this feature, users would be able to not only verify proxy contracts but also automatically retrieve and display related contract addresses, such as logic (implementation) and admin contracts. This enhancement would significantly improve the developer experience by providing more transparency and easier access to the structure and components of proxy contracts deployed on the blockchain.

Motivation:

ERC-1967 introduces a standard for upgradeable proxies, including well-defined storage slots for key components like the logic contract and admin address. Currently, when a developer or auditor looks up a proxy contract on Sourcify, they only see the proxy contract's code and metadata. There's a missing piece in the puzzle - the link to the logic contract and possibly the admin and beacon contract. Considering the widespread use of ERC-1967 for upgradeable contracts, integrating this feature into Sourcify would greatly benefit the Ethereum developer community by making contract interactions more transparent and verifiable.

Proposed Solution:

  1. Automatic Detection and Registration of ERC-1967 Proxies: When a proxy contract is verified on Sourcify, automatically check if it complies with ERC-1967 by looking for the standardized storage slots. If detected, proceed to extract and register the addresses stored in these slots.

  2. Display Logic and Admin Contract Addresses: For any ERC-1967 compliant proxy contract queried on Sourcify, display not only the proxy's code and metadata but also links to the logic (implementation) and admin contracts, if available. This could be shown in a dedicated section of the contract's Sourcify page, enhancing the informational value of the verification service.

  3. Enhanced Verification Process: Adapt the verification process to acknowledge the dynamic nature of proxy contracts, possibly by allowing users to request a refresh/update when the logic contract changes, while still maintaining historical data(such as previous addresses) for transparency.

  4. API Enhancements: Update the Sourcify API to include endpoints or modify existing ones to return information about the logic and admin contracts for ERC-1967 proxies, making it easier for developers to integrate and retrieve this information programmatically.

Benefits:

  • Increased Transparency: Users can easily access and verify the full structure of upgradeable contracts, enhancing trust in deployed smart contracts.
  • Improved Developer Experience: Developers can quickly find and interact with the components of proxy contracts without having to manually request storage slots.

Conclusion:

Implementing this feature would significantly strengthen Sourcify's role as a pivotal tool for smart contract verification and transparency in the Ethereum ecosystem. It aligns with the broader goals of making blockchain interactions more transparent, verifiable, and user-friendly. We look forward to discussing this proposal further and exploring the best approaches to bring this valuable feature to the community.

@kuzdogan
Copy link
Member

Thanks for the feature req! Similar to your other req's #1233 this also depends on our transition to a DB based Sourcify instead of a filebase based one,unfortunately.

However we are getting closer! We just turned on the DB and now in the process of migrating our existing contracts: #1287

After that it can be possible to add proxy support by extending the current API or in our planned APIv2. We need to align on how other verifiers implemented proxy support in their APIs.

cc: @marcocastignoli @manuelwedler

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🧊 Icebox
Development

No branches or pull requests

2 participants