Mainnet v4.8.x#4330
Conversation
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
[Fix] Ensure `--dev-on-prod works` as expected
Install missing deps for github workflows
Postrelease merge mainnet
…lt-feature Make telemetry part of default snarkOS build features
Start consensus handlers only after CDN sync is complete
[Feat] Increase REST body limit
…evnet test
- Update snarkVM rev from c457b6b9e to e4a7a945 (historic program edition support)
- Add POST /{network}/program/{id}/view/{function} endpoint for latest height
- Register new route in lib.rs alongside the height-specific route
- Add `view get_value` to test_program.aleo in test_devnet.sh
- Test both view endpoints (latest + specific height) in test_devnet.sh
- Move height capture inside spawn_blocking to minimize race window - Rename test view function from get_value to compute_sum for clarity
Signed-off-by: ljedrz <ljedrz@users.noreply.github.com>
…otion_warn [Logs] Be more explicit about unexpected peer status during promotion
…ion IDs. Rejection reasons are keyed by the fee transaction ID, so look up the unconfirmed and confirmed transaction IDs when a direct lookup misses. Co-authored-by: Cursor <cursoragent@cursor.com>
Surface rejection reasons endpoint
![veria-ai[bot]](https://avatars.githubusercontent.com/in/1723776?s=60&v=4){kind=small}
| // Evaluate the view function in a blocking task. | ||
| // The latest block's state is captured inside the task to minimise the window | ||
| // between state sampling and evaluation. | ||
| let (outputs, height) = match tokio::task::spawn_blocking(move || { |
There was a problem hiding this comment.
Medium: Unbounded VM evaluation
This public route executes caller-selected view functions on Tokio's blocking pool without a semaphore or cost gate. A client can repeatedly POST to a costly deployed view function and keep CPU/blocking threads occupied; the history variant at line 1232 has the same pattern when that feature is enabled. Add a bounded permit around view evaluation or enforce a metered view-cost limit before spawning the work.
PR overviewThis PR updates the Mainnet v4.8.x codebase, including REST routes that execute VM view functions against current and, when enabled, historical state. One security issue remains open: the public view-function evaluation route can run caller-selected VM work without a concurrency or cost bound. A client could repeatedly invoke expensive view functions and consume CPU or Tokio blocking-pool capacity, degrading REST node availability. No issues have been addressed yet in this review cycle, so the PR still needs a bounded execution or metering control for these routes. Open issues (1)
Fixed/addressed: 0 · PR risk: 6/10 |
Motivation
Release PR merging testnet into mainnet and updating snarkVM rev to ProvableHQ/snarkVM#3314
No crates.io release will be made yet in this PR, but we can do this retro-actively when certain applications require it.