search

mds1 / evm-diff

Diff EVM-compatible chains in a friendly format
https://evmdiff.com
MIT License
272 stars 27 forks source link

feat: add metis andromeda #74

Open sakulstra opened 2 months ago

sakulstra commented 2 months ago

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[bot] commented 2 months ago

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 commented 2 months ago

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: https://github.com/mds1/evm-diff/blob/52f1893cab9245ad00f5c770f04d87c0964fa3cd/script/index.ts#L121-L128

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 https://github.com/mds1/evm-diff/issues/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 commented 2 months ago

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 :+1:

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