Port runtime observation and solidity-data decoding features

[alcuadrado]

This is a tracking issue created as a result of #242. We analyzed this scope with @fvictorio, split it into smaller submodule, uncovered their dependencies and came up with an execution plan.

Tasks

• Tracer bullet implementations of runtime observation #319
• Implement a way to run the stack traces tests cases automatically #328
• Codebase model definition and construction #247
• Contract identifier implementation #248
• returndata decoding #250
• Stack trace format defintion #251
• Raw/naive stack trace generation #252
• Implement stack traces improver based on the heuristics that Hardhat Network has #261
• Port the Error inferred from Hardhat Network #262
• Define a JSON format to represent Solditiy stack traces, decoded returndata and inferred errors. #263
• Create js Errors that include Solidity stack traces, decoded returnadta and inferred errors information. #264
• Test ported runtime observation in third-party repos #322
• Stack traces test runner: generate artifacts in Rust #321

Features withing scope

• Generating solidity stack traces
• Inferring common error cases based on heuristics
• Decoding the returndata of failed evm calls when possible

Submodules

The submodules are these:

• Codebase model: An internal model of the codebase and compilation output that can be used to back all the runtime analysis that we need to do. This is found here in Hardhat. A 1:1 port would be Hard to express in Rust, and at the same time, there are multiple optimization opportunities.
• build-info to codebase model: A module that given a build-info (i.e. compilation input & output pair), constructs the model described above.
• Contract identifier: A module that tries to identify which contract is being run in a certain evm call. Due to linked libraries, immutable variables inlining, and constructor parameters being appended to the bytecode, this is not a straightforward search. The most recent TS implementation of this is here
• EVM Trace Generation: A module that creates a static low-level trace of the execution of an EVM call. This has no knowledge of Solidity. It has already been implemented by @Wodann
• Raw stack traces generation: A module that naively applies source maps to the EVM trace to generate a Solidity stack trace.
• Stack traces improver: A module that takes the naive solidity stack trace and improves them to be either more correct or meaningful. This is necessary due to the source maps generated by solidity being unreliable.
• Stack trace format: A format (i.e. data structure) that can be used to represent raw and improved stack traces. We can consider having two of them though. This can be ported 1:1 from Hardhat Network, as the format we used there has a mixture of responsibilities that we agreed was a mistake. It includes information about the returndata decoding result, and about any inferred error.
• Error inferred: A module that tries to detect common error cases in failed evm calls.
• Return data decoding: A module that tries to decode the returndata of a failed evm call. It should support revert reasons, custom errros and panics.
• EDR-to-JS format: We need to define a json format to return information about stack traces, decoded returndatas and any inferred error. It can potentially be returned by any JSON-RPC request that executes EVM code. Note that this may also affect how we handle the UI.
• JS error construction: A javascript module that given the EDR-to-JS format explained above, creates a JavaScript Error object with the appropriate stack trace and information.

Definition of done

• We need to implement a test runner that can run the stack traces tests, in Rust.
  • The test runner can assume that the js one compiled all the test contracts.
• All the stack traces tests should pass, with all the solc configurations that we have, not just the default.
• We should integrate the edr_solidity module into the provider and its js wrapper, so that if a failure happens, we throw the same kind of js Error than Hardhat Network.
• We need to define a way to validate the above item.