Enhance ABI fetching by adding Sourcify support and 4bytes directory …#190
Enhance ABI fetching by adding Sourcify support and 4bytes directory …#190itasli wants to merge 3 commits into
Conversation
…integration - Updated `useFetchContractAbi` to first attempt fetching the ABI from Etherscan, with a fallback to Sourcify. - Introduced `fetchContractABIFromSourcify` utility to retrieve contract ABIs from Sourcify. - Enhanced ABI with function names from the 4bytes directory in the index and contract detail pages. - Added error handling for ABI enhancement failures, ensuring fallback to original ABI when necessary.
|
@itasli is attempting to deploy a commit to the BuidlGuidl Team on Vercel. A member of the Team first needs to authorize it. |
|
I'd recommend first asking Sourcify and fallback to Etherscan as it does not require an API key :) |
|
Hi @kuzdogan, thanks for your reply. I also prefer to use sourcify directly, as it doesn't require an API key and seems easier to use. According to the review, I can either rework this PR or open a new one, of course ^^ |
|
Hey @itasli, it would've been nice if you could've created an issue or discussion before making the PR, as we mentioned in the PR template. We are tackling two things in this PR.
Was discussing and testing this with @carletex, one of the reasons why we are only fetching from etherscan is that almost all the contracts are first verified on etherscan. If it's not, then it's most likely not available on other platforms. And if we have an unnecessary number of fallbacks, the time to move to the Hemidall screen increases significantly, and the user is stuck seeing the loading spinner. Regarding 4-byte directory, it seems Sourcify's 4-byte directory has much more data than https://www.4byte.directory/! But upon quick testing, it looks Heimdall is doing its job pretty well as is without needing a 4-byte directory lookup! checkout below and compare with locahost of this branch: Do we have good examples where Heimdall is performing badly without a 4-byte lookup? If so we would love to look and integrate it 🙌 But if not, maybe it's not worth the additional complexities and api requests in code. |
…m4Bytes` to support batch lookups for multiple signatures and updating ABI items with better names from the 4bytes directory.
|
Hey @technophile-04, thanks for the detailed review. About opening an issue or discussion first: I didn’t open a new one because topics were already being talked about, and my work partially matched what was being explored there. For example:
Since these discussions already covered the same needs, I implemented the features I needed and shared the PR Why Sourcify fallbackSome chains simply don’t support the Etherscan API. CoreDAO is a direct example. Their explorer is not (or doesn't seems) compatible with Etherscan endpoints. Example contract: Supporting CoreDAO manually would work, but the same issue comes back every time an L1/L2 uses a forked or custom explorer. Sourcify solves this in a generic way because it's explorer agnostic and avoids having to hardcode specific support again and again. Why the 4-byte directory fallbackHeimdall may returns some selectors as unresolved. Having access to an open-source 4-byte directory helps fill those gaps. I use this strictly as a last resort, not as part of the normal happy path. Performance considerationsI agree that too many fallbacks slow things down. My implementation only triggers them when Etherscan gives no result, so the usual Etherscan-verified flow stays fast. |
3 participants
…integration
useFetchContractAbito first attempt fetching the ABI from Etherscan, with a fallback to Sourcify.fetchContractABIFromSourcifyutility to retrieve contract ABIs from Sourcify.Description
Adds Sourcify API support as an alternative source for fetching verified contract ABIs, with automatic fallback from Etherscan to Sourcify. Also integrates Sourcify's 4bytes directory API to enhance the decompile contract feature with better function signature decoding.
Additional Information
Related Issues
No related issue - this is a new feature addition
Your ENS/address:
0x00000000E2cEeC19EE7644F299Ce8caB2921D342