feat: add metis andromeda

[sakulstra]

Trying to add metis, but facing some issues here and there.

I think opcode detection doesn't really work, which might be related to rpc.

---

@mds1 would it make sense to move the generated jsons to public? With the current setup i think it's impossible to test before things are deployed as it relies on fetching via raw.github - if it was in public folder we could just make path dependent on origin i think as the json will be available via the deployment itself.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
evm-diff	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 28, 2024 2:16pm

[mds1]

I think opcode detection doesn't really work, which might be related to rpc.

To test opcode support we send a contract creation transaction with the initdata just being a single opcode, and inspect the result or error message. However some RPCs don't support this and error with e.g. Required "to" is empty. These RPCs get filtered out and not used:

evm-diff/script/index.ts

Lines 121 to 128 in 52f1893

	// These domains have various issues that make them unsuitable for our purposes.
	const domainsToSkip = [
	'drpc.org', // Required "to" is empty.
	'blocknative.com', // Transaction creation failed.
	'flashbots.net', // 403 (also on eth_call with no to).
	'mevblocker.io', // 429's easily.
	'matic-mainnet-full-rpc.bwarelabs.com', // "This endpoint is deprecated".
	];

After this filtering, the only metis RPC URL we're left with is https://andromeda.metis.io/?owner=1088, which gives a generic "execution reverted" error.

$ cast call -r "https://andromeda.metis.io/?owner=1088" --create 0x01
Error: 
server returned an error response: error code -32000: execution reverted

Compare that to what you get from Alchemy (geth) on mainnet, which implies the opcode is supported:

$ cast call -r $MAINNET_RPC_URL --create 0x01 
Error: 
server returned an error response: error code -32000: stack underflow (0 <=> 2)

I suspect #67 will solve this problem for Metis, though I don't have a concrete timeline on that yet (cc @fvictorio in case you plan to work on it soon).

In the meantime, if you know of an RPC URL where the above would work for Metis (even if it needs an API key), that would be a good workaround here.

would it make sense to move the generated jsons to public? With the current setup i think it's impossible to test before things are deployed as it relies on fetching via raw.github - if it was in public folder we could just make path dependent on origin i think as the json will be available via the deployment itself.

Yea, I agree that is an issue.

If I move them to the public folder, do they get included in the default bundle that's served to users? My main reason for not doing that was bloating bundle size with tons of data, but its possible nextjs/react are smart enough to split the bundle in a way that doesn't causee bloat.

The other idea I had to fix that is adding a new env var like NEXT_PUBLIC_REPO (similar to the NEXT_PUBLIC_BRANCH_NAME set here), this way we can avoid hardcoding the mds1/evm-diff portion of the path here.

[sakulstra]

If I move them to the public folder, do they get included in the default bundle that's served to users? My main reason for not doing that was bloating bundle size with tons of data, but its possible nextjs/react are smart enough to split the bundle in a way that doesn't causee bloat.

things in public are not bundled but handled as static assets. Will try to do a separate pr for this then 👍

Regarding metis, i reached out to the team and asked if there's another rpc we can use.