search

mds1 / evm-diff

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

feat: EVM playground for each supported chain #5

Open mds1 opened 1 year ago

mds1 commented 1 year ago

From @pcaversaccio in https://github.com/mds1/evm-diff/issues/4#issuecomment-1582382624:

I love the playground feature from https://www.evm.codes/playground: it would be a nice feature to be able to simulate the differences at opcode or Solidity level, for example. Let me make a simple example: you have a contract compiled with solc version 0.8.20 and default EVM version shanghai. You copy-paste the contract into the playground, select "Optimism<>Ethereum diff" and press run. It will deploy on Ethereum but not on Optimism yet due to PUSH0. Diffs are very powerful on a documentation level, but many times you also want to understand the engineering implications. Thus, we should also think about how to integrate this best into the UI.

This would be nice to have, I think the main thing to figure out is how to actually implement it. The EVM Codes playground is powered by ethereumjs and solc-js, and there's no guarantee these exist for each chain. Since EVM compatible chains should support solc out of the box, ethereumjs is the main one to figure out. Probably can just query a node instead of simulating locally with etheruemjs

pcaversaccio commented 1 year ago

Since EVM compatible chains should support solc out of the box

unfortunately not all of them. E.g. zkSync needs an LLVM-based transpiler for Solidity and Vyper!

hrik2001 commented 1 year ago

Hey! Really interested to contribute!

I was wondering, if this solution is overkill or not, but what if we make our own VM, that way we will be able to keep the website up to date with new functionality very fast. Moreover, we can kind of implement it in such a way so that it solves #6 too. So, basically an opcode object which will contain all the metadata that is mentioned at #6, but it will also have a method, that will do the required changes to the state of the VM. For inspiration we can look at execution-specs too.

Moreover, a lot of the opcodes are same for multiple chains, so we can just import those opcodes and make our own changes to the required ones to come up with a different dialect of EVM for that chain itself. So a modular plug-n-play EVM with metadata.

Now that takes care of the opcode, but about solidity compilation, that poses a problem. I don't know if the website has to be solely client sided, but we can have an AWS lambda instance for outlier cases like zkSync where solc cannot be used, for the rest wherever solc and ethereumjs can be used, we can use them

mds1 commented 1 year ago

Hey! Really interested to contribute!

Hey @hrik2001, that's awesome to hear!

I was wondering, if this solution is overkill or not, but what if we make our own VM, that way we will be able to keep the website up to date with new functionality very fast.

Yea I was thinking a bit about how to do this also. Building a modular VM to support something like this is definitely a lot of work, and in the limit, to support everything, you basically just end up writing a node. So with this route, my guess (and I haven't spent much time thinking about this) is that the best approach would probably be to wait for reth to be ready and leverage that, since it's built to be modular and that might provide a flexible, robust foundation.

we can have an AWS lambda instance for outlier cases like zkSync where solc cannot be used

Agreed, I think we'd have to do something like this, which is ok.

I should mention that I think this feature—while definitely valuable—is also a lot of work. And IMO the "work to benefit" ratio for a text/UI-based diff is significantly better than that ratio for this feature. Focusing on the UI-based diff first also has the benefit of having no unknowns, whereas this feature has unknowns around the best way to implement it. As a result I think it's probably too early in EVM Diff's life to spend much time focusing on this (though I don't want to discourage you, just want to let you know what I'm prioritizing currently!) 😅

pcaversaccio commented 1 year ago

@hrik2001 thanks for joining the discussion!

My 2 cents on the priority of this issue: for the first evmdiff.com we should aim for a quick win and focus on the low-hanging fruits: the simple UI-based diff. Two benefits:

  1. People will love starting using the website (I can already claim that lol) and provide feedback accordingly
  2. More brain power will be attracted and potential contributors who might share other possible approaches

That being said, while I deem (my) issue as very relevant, I think we can figure out along the way what's the best approach to implement this feature. It might be a separate VM but it can be also something we figure out along the road which works much better for us. So my recommendation here is to continue brain dumping and discussing thoughts but in terms of real-world implementation I would jump on other issues. @mds1 and @hrik2001 thoughts?

mds1 commented 1 year ago

@pcaversaccio Completely agree with all of that

mds1 commented 1 year ago

Half baked idea—if we have a VM for each chain we can run the standard ethereum test suite against each and show which tests fail for a given chain: https://github.com/ethereum/tests

pcaversaccio commented 1 year ago

Half baked idea—if we have a VM for each chain we can run the standard ethereum test suite against each and show which tests fail for a given chain: https://github.com/ethereum/tests

Oh yeah, that makes a lot of sense. There is also another newer repo that offers tests for EL client implementations which could be leveraged as well: https://github.com/ethereum/execution-spec-tests

jayketo commented 11 months ago

@mds1 @hrik2001 @pcaversaccio

This one caught my eye. Will have to find some time but perhaps can start with the simple diff vs simulation. That's a heavy commitment