zkSync Support

[dutterbutter]

I love using solidity-coverage in my projects and want to make use of it for my zkSync projects. Given zkSync has its own compiler, and has a zkEVM, soliditity-coverage does not work out of the box with the zkSync HH plugins.

Is there a solidity-coverage domain "expert", that I can connect with to discuss / learn about the inner workings better of solidity-coverage. Its far faster then just reading the code over and over. I am eager to extend support to the zkSync ecosystem so speaking with someone that has a deep understanding would greatly accelerate things.

[cgewecke]

Hi @dutterbutter! Nice!

There's little bit of an "inner workings" summary in the docs at the API section...

Am not super familiar with the zkSync HH plugins but the basic pre-requisites for solidity-coverage are that:

• the contracts are written in solidity and can be passed to some kind of compilation task
• there's a way to hook into and monitor the EVM program "step" in order to detect instrumentation hashes solidity-coverage has injected into the code.

Do you have any links to the relevant zk tooling I could look at (to see if there are any obvious blockers or incompatibilities)?

[dutterbutter]

Thanks for the quick response! @cgewecke

I think its the second point outlined - "there's a way to hook into and monitor the EVM program "step" in order to detect instrumentation hashes" - that could be problematic as zkSync makes use of a zkEVM that is not bytecode equivalent but rather compatible.

Nonetheless it would be great to get your review / investigation. I setup this minimal example project you can run here: https://github.com/dutterbutter/min-solidity-coverage-test

To run:

• git clone git@github.com:dutterbutter/min-solidity-coverage-test.git
• yarn install
• npx hardhat compile
• npx hardhat coverage

---- update ----

The equivalent to the evm step in zkSync would be the after_execution tracer

[cgewecke]

@dutterbutter Great! Will take a look...

[cgewecke]

@dutterbutter Some initial thoughts....

The simplest thing would be to use debug_traceTransaction and debug_traceCall to process the trace from the Hardhat side. You'd create a wrapped provider which overloaded ether'ssendTransaction and send methods to fetch the traces and pass those to solidity-coverage's collector etc. (I'm assuming there are no issues with instrumentation getting stripped out by the zk compiler - haven't verified that though)

This would be easy if zksync era implemented geth's custom tracer but it seems like only callTracer is enabled and that doesn't contain the necessary data. (We need to inspect the top of the evm stack as each PUSH, SWAP and DUP opcode executes.)

I see you've linked to the client codebase - are you open to taking a PR which creates a tracer type that would expose this info? In its simplest form it would just be a "coverageTracer" to get solidity-coverage working rather than something all-purpose like geth's. (Happy to work on this fwiw).

Not sure about other options but open to any ideas. Architecturally it's a little tricky because the client is in another process and that gap has to be bridged somehow.

Also please just lmk if I've missed something and the info is obtainable via an rpc endpoint somewhere...

[dutterbutter]

@cgewecke really appreciate the analysis here. We are discussing internally and will post back here.

[cgewecke]

@dutterbutter SGTM!