zkSync Support about solidity-coverage HOT 8 OPEN

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 [email protected]: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

from solidity-coverage.

@dutterbutter Great! Will take a look...

from solidity-coverage.

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)?

from solidity-coverage.

@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...

from solidity-coverage.

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

from solidity-coverage.

@dutterbutter SGTM!

from solidity-coverage.

Zksync is a history

from solidity-coverage.

Good

from solidity-coverage.