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

find a good way to verify MUD contracts on etherscan etc #1798

Open
alvrs opened this issue Oct 19, 2023 · 1 comment
Open

find a good way to verify MUD contracts on etherscan etc #1798

alvrs opened this issue Oct 19, 2023 · 1 comment
Labels
good first issue Good for newcomers

Comments

@alvrs
Copy link
Member

alvrs commented Oct 19, 2023

  • MUD Worlds are essentially proxies for logic implemented in System contracts.
  • Systems are upgradable, so it's hard to "statically verify" that a certain function selector maps to a certain system contract, but at least we could verify all individual contracts
@alvrs alvrs added the good first issue Good for newcomers label Oct 19, 2023
@tash-2s
Copy link
Contributor

tash-2s commented Dec 29, 2023

I explored this topic and successfully verified the emojimon contracts (World, MapSystem, etc.) on Blockscout, so I'll compile my notes here.

Contract verification is a feature of block explorers that allows the viewing of Solidity code and function signatures of deployed contracts. The most used explorers, Etherscan and Blockscout, have compatible verification APIs, allowing us to submit contract information.

The block explorers lack support for proxy contracts that delegate to multiple logic contracts, such as MUD Worlds and the Diamond standard. Thus, scenarios like calling a system contract through a world contract are not nicely displayed, even if they're verified. However, this is still beneficial for contract transparency. (There is an interesting hack to display function signatures on Etherscan for multiple logic contracts, but it requires deploying a mock contract.)

To verify contracts of MUD projects, forge's verification feature is the first choice because forge builds the contracts and manages the file structure. forge offers two methods for contract verification: 1) deploying and verifying a contract together within the same command (forge create and forge script with the --verify option), and 2) verifying a contract separately (forge verify-contract). Since MUD doesn't rely on forge for contract deployment, the latter is more appropriate.

forge verify-contract requires a contract name/identifier and deployed address. We can use a TypeScript script to create the list of a contract name and the address and invoke the forge command for each contract. It would be beneficial to integrate this work as a MUD CLI command.

forge has an issue with its contract verification feature for our use case, but I've fixed it in the foundry repository, so it will be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants