search

near / nearcore

Reference client for NEAR Protocol
https://near.org
GNU General Public License v3.0
2.33k stars 627 forks source link

Worst case CPU soak test #3119

Open MaksymZavershynskyi opened 4 years ago

MaksymZavershynskyi commented 4 years ago

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 commented 4 years ago

What kind of CPU are we doing the benchmark on?

bowenwang1996 commented 3 years ago

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

stale[bot] commented 3 years ago

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 commented 3 years ago

@olonho @matklad

matklad commented 3 years ago

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[bot] commented 2 years ago

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.