feat(api): Integrate new VM into API server (no tracers) #3033
Conversation
|
With optimized gas estimation and new VM, the CI load test yields around 115 tps (vs 70 tps baseline and approx. 60 tps for the old VM). |
|
|
||
| /// Fast VM mode to use for gas estimation in the API server. | ||
| #[serde(default)] | ||
| pub api_fast_vm_mode_for_gas_estimation: FastVmMode, |
There was a problem hiding this comment.
I haven't added corresponding option for calls and transaction execution; they can be added iteratively. Not sure what's the best approach here.
There was a problem hiding this comment.
Probably one variable for all 3 cases is enough?
There was a problem hiding this comment.
@Deniallugo What's the best way to set api_fast_vm_mode_for_gas_estimation = SHADOW for integration tests? Create a similar file and call zks config-writer like in the CI load test?
There was a problem hiding this comment.
yes, config-writer is the best effort.
You can create this file on flight
| let handler = DivergenceHandler::new(move |errors, _| { | ||
| tracing::error!(transaction, ?mode, "{errors}"); | ||
| }); |
There was a problem hiding this comment.
Not sure what the best option for the divergence handler would look like. We probably don't want to panic on divergence, but maybe we want to store a VM dump somewhere?
There was a problem hiding this comment.
It does, maybe we can just dump it to local file with some safety measures against spamming files, e.g. limit it to 10 dump files and overwrite/stop dumping when limit is reached?
What ❔
Integrates the new VM into API server for 3 use cases: gas estimation, calls, and tx execution (without the validation stage).
Why ❔
These use cases do not require tracers and could benefit from faster VM execution (particularly gas estimation, which runs the VM multiple times).
Checklist
zk_supervisor fmtandzk_supervisor lint.