find a good way to verify MUD contracts on etherscan etc

[alvrs]

• 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

[tash-2s]

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.