Metrics for the contract runtime team

[akhi3030]

On a network that has been stood up, measure the two metrics below. It does not really matter how many nodes are involved as the values are expected to be the same on all of them (Gas should be identical and time similar).

Cost of executing an empty function on a non-empty contract

We can calculate the gas needed to execute such a function. No measurements for this are needed. We can then measure the time needed (both latency and throughput) for the execution. We still have to define what the non-empty contract should be. We also need to define from which point to which point the time should be measured.

Cost of regular wasm ops

Again we can calculate the gas needed for this. We can then measure the time needed as well. We need to define what function to execute to capture this data. We probably want to repeat the above experiment with a non-empty function, subtract the cost of doing an empty function call and then divide by the number of wasm ops in the function.

Number of wasm opcodes supported in ZKWasm generation

One active area of development in the team is adding support for generating ZK proofs for wasm execution. This metric would track the number of wasm opcodes currently supported.

[akhi3030]

Feedback from Bowen on ZKWasm: something along the lines of proof generation time; reflects on some property of the system that does not depend on one specific implementation. Need to discuss further with Andrei.

[aborg-dev]

For ZK WASM, we now track both the WASM opcode coverage and the number of "cycles" which is a proxy for the proof generation time (with simple linear dependency).

All these metrics are stored in https://github.com/near/wasmtime/blob/main/docs/zkasm/test_summary.csv and are updated automatically by our CI pipeline.