Worst case CPU soak test

[MaksymZavershynskyi]

Motivation

We are currently using a cryptographic primitive computation to estimate the relationship between the number of CPU instructions and the time which leads to relationship between the number of CPU instructions and gas. This might lead us to underestimating the cost of runtime operations, including Wasm operations, which might open the potential abuse vector. However, we need to make sure it accounts for the worst possible case – it should mostly miss CPU cache and it should mostly use the most expensive CPU instructions.

Goal

We need to write code in Rust and execute it as native. This code should exercise the worst case scenario for CPU and try to maximize <time passed>/<number of CPU instructions> ratio. It should run long enough to minimize the volatility of the computed ratio. It cannot use thread-specific primitives like atomics or OS-level primitives like threads, it is very desirable if it uses only CPU instructions that are used by popular Wasm backends during Wasm execution. In examples of what it can try to do: it can try to miss the CPU cache as much as possible, it can try to utilize only the most expensive CPU instruction.

[bowenwang1996]

What kind of CPU are we doing the benchmark on?

[bowenwang1996]

@olonho I believe you developed something similar. Is this issue already addressed?

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[bowenwang1996]

@olonho @matklad

[matklad]

Yeah, we still need to get more principle and reproducible mappin from CPU instructions to gas cost. Though, I don't think we need to target the worst-case instructions necessary -- attackers can't force specific CPU instructions, they can force specific wasm code or host funtion calls. It might be the case that some host function today uses more wall-clock time than number of cpu instructions, but this can be for the variaty of reasons (like doing IO).

Doesn't feel like a high priority issue to address to me, as it is dominated by issues with todays gas counter () and the IO costs (we still haven't switched to costs which account for IO).

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.