Some of our program execution occurs within an async context, despite being potentially blocking. This is because the VM exposes an async API, however this only works if the program being executed constantly requires external inputs (which cause it to yield execution).
The same is true for our remote and local proving, and potentially in signing or verification of signatures, or even commitment calculations are causes for concern if not done in a blocking task.
We should find such instances and move them to blocking tasks, or in cases where the API is async, create a dedicated runtime which can isolate the problem.
Known problem areas:
- validator re-executes transactions with provided inputs
- validator signs and hashes
- prover also re-executes, and proves
- network transaction builder executes, and
- also proves if configured for local proving
- store calculates commitments and hashes
- store does verification
- block producer can do local proving
Relates to #1969.
Ideally we would have all blocking tasks isolated, where blocking is defined as < 100us between await points.
Some of our program execution occurs within an async context, despite being potentially blocking. This is because the VM exposes an async API, however this only works if the program being executed constantly requires external inputs (which cause it to yield execution).
The same is true for our remote and local proving, and potentially in signing or verification of signatures, or even commitment calculations are causes for concern if not done in a blocking task.
We should find such instances and move them to blocking tasks, or in cases where the API is async, create a dedicated runtime which can isolate the problem.
Known problem areas:
Relates to #1969.
Ideally we would have all blocking tasks isolated, where blocking is defined as
< 100usbetween await points.