Track SRI crate bump from 1.9.0 baseline to current releases #1

New issue

Open

opened 2026-07-16 23:11:16 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-16 23:11:16 +01:00

Collaborator

So that I can keep Hashpool on a protocol stack that matches current SRI releases, track the next dependency-bump pass separately from the completed SRI 1.9.0 migration.

Context

Hashpool master is clean and already completed the archived docs/archive/dev-plan-dep-bump-sri-1.9.0.md milestone. A fresh audit on 2026-07-16 shows the current SRI crates.io/tag surface has moved again: stratum-mining/stratum has v1.11.0, stratum-mining/sv2-apps has v0.6.0, and the local manifests/lock are still on the 1.9.0-era versions.

Current bump candidates found in Hashpool:

Crate	Hashpool current	Current upstream	Notes
`binary_sv2`	`5.0.1`	`6.0.0`	registry dependency
`codec_sv2`	`5.0.0`	`6.0.0`	registry dependency
`framing_sv2`	`6.0.1`	`7.0.0`	registry dependency
`common_messages_sv2`	`7.1.0`	`8.0.0`	registry dependency
`mining_sv2`	`9.0.0`	`11.0.0`	registry dependency; high-risk API surface
`template_distribution_sv2`	`5.0.0`	`6.0.0`	registry dependency
`job_declaration_sv2`	`7.0.0`	`9.0.0`	registry dependency
`channels_sv2`	`5.0.0`	`7.0.0`	registry dependency
`derive_codec_sv2`	`1.1.2`	`1.1.3`	likely lock/manifest patch bump
`stratum-core`	`0.3.0`	`0.5.0`	via vendored `common/stratum-apps`
`stratum-apps`	local `0.4.0`	`0.6.0`	vendored with Hashpool changes
`sv1_api`	local `2.1.1`	`5.0.0`	local SRI-derived crate
`parsers_sv2`	local `0.1.1`; registry `0.3.0` also appears transitively	`0.5.0`	local copy carries Hashpool `mint_quote_sv2` message wiring
`handlers_sv2`	local `0.1.0`; registry `0.3.0` also appears transitively	`0.5.0`	tied to local parser changes
`roles_logic_sv2`	local `4.0.0`	`5.0.0`	tied to local parser/handler changes
`stratum_translation`	local `0.1.0`; registry `0.2.0` also appears transitively	`0.4.0`	local roles utility plus transitive SRI copy

Crates already current in this audit: noise_sv2 = 1.4.2, buffer_sv2 = 3.0.1, const_sv2 = 4.0.1, and network_helpers_sv2 = 4.0.1.

Scope

Plan and implement this as a staged dependency bump, not a single blind cargo update:

Bump the registry SRI crates together against the current stratum-mining/stratum release line.
Decide whether the local SRI-derived crates should be synced to current upstream source or kept vendored with Hashpool-specific deltas re-applied.
Preserve Hashpool-only protocol extensions: mint_quote_sv2, stats_sv2, and parser wiring for the mint quote messages.
Reconcile duplicate transitive SRI crates in roles/Cargo.lock where possible, especially parsers_sv2, handlers_sv2, stratum_translation, and sv1_api.
Treat stratum-apps as its own decision point: update the vendored copy to 0.6.0 or unvendor only if the local monitoring/key-utils changes have a clean replacement.

Validation

devenv shell cargo check --manifest-path protocols/Cargo.toml
devenv shell cargo check --manifest-path roles/Cargo.toml
devenv shell cargo test --manifest-path protocols/Cargo.toml
devenv shell cargo test --manifest-path roles/Cargo.toml
Full regtest stack smoke test: pool, mint, translator, JDS/JDC, sv2-tp, web dashboards, and a miner submitting accepted shares.

Boundaries

Do not combine this with the template-provider migration work; track that separately. Do not drop Hashpool protocol extensions to make upstream crates fit. CDK dependency bumps are out of scope here except where Hashpool's role workspace requires them for compilation.

So that I can keep Hashpool on a protocol stack that matches current SRI releases, track the next dependency-bump pass separately from the completed SRI 1.9.0 migration. ## Context Hashpool master is clean and already completed the archived `docs/archive/dev-plan-dep-bump-sri-1.9.0.md` milestone. A fresh audit on 2026-07-16 shows the current SRI crates.io/tag surface has moved again: `stratum-mining/stratum` has `v1.11.0`, `stratum-mining/sv2-apps` has `v0.6.0`, and the local manifests/lock are still on the 1.9.0-era versions. Current bump candidates found in Hashpool: | Crate | Hashpool current | Current upstream | Notes | | --- | ---: | ---: | --- | | `binary_sv2` | `5.0.1` | `6.0.0` | registry dependency | | `codec_sv2` | `5.0.0` | `6.0.0` | registry dependency | | `framing_sv2` | `6.0.1` | `7.0.0` | registry dependency | | `common_messages_sv2` | `7.1.0` | `8.0.0` | registry dependency | | `mining_sv2` | `9.0.0` | `11.0.0` | registry dependency; high-risk API surface | | `template_distribution_sv2` | `5.0.0` | `6.0.0` | registry dependency | | `job_declaration_sv2` | `7.0.0` | `9.0.0` | registry dependency | | `channels_sv2` | `5.0.0` | `7.0.0` | registry dependency | | `derive_codec_sv2` | `1.1.2` | `1.1.3` | likely lock/manifest patch bump | | `stratum-core` | `0.3.0` | `0.5.0` | via vendored `common/stratum-apps` | | `stratum-apps` | local `0.4.0` | `0.6.0` | vendored with Hashpool changes | | `sv1_api` | local `2.1.1` | `5.0.0` | local SRI-derived crate | | `parsers_sv2` | local `0.1.1`; registry `0.3.0` also appears transitively | `0.5.0` | local copy carries Hashpool `mint_quote_sv2` message wiring | | `handlers_sv2` | local `0.1.0`; registry `0.3.0` also appears transitively | `0.5.0` | tied to local parser changes | | `roles_logic_sv2` | local `4.0.0` | `5.0.0` | tied to local parser/handler changes | | `stratum_translation` | local `0.1.0`; registry `0.2.0` also appears transitively | `0.4.0` | local roles utility plus transitive SRI copy | Crates already current in this audit: `noise_sv2 = 1.4.2`, `buffer_sv2 = 3.0.1`, `const_sv2 = 4.0.1`, and `network_helpers_sv2 = 4.0.1`. ## Scope Plan and implement this as a staged dependency bump, not a single blind `cargo update`: - Bump the registry SRI crates together against the current `stratum-mining/stratum` release line. - Decide whether the local SRI-derived crates should be synced to current upstream source or kept vendored with Hashpool-specific deltas re-applied. - Preserve Hashpool-only protocol extensions: `mint_quote_sv2`, `stats_sv2`, and parser wiring for the mint quote messages. - Reconcile duplicate transitive SRI crates in `roles/Cargo.lock` where possible, especially `parsers_sv2`, `handlers_sv2`, `stratum_translation`, and `sv1_api`. - Treat `stratum-apps` as its own decision point: update the vendored copy to `0.6.0` or unvendor only if the local monitoring/key-utils changes have a clean replacement. ## Validation - `devenv shell cargo check --manifest-path protocols/Cargo.toml` - `devenv shell cargo check --manifest-path roles/Cargo.toml` - `devenv shell cargo test --manifest-path protocols/Cargo.toml` - `devenv shell cargo test --manifest-path roles/Cargo.toml` - Full regtest stack smoke test: pool, mint, translator, JDS/JDC, sv2-tp, web dashboards, and a miner submitting accepted shares. ## Boundaries Do not combine this with the template-provider migration work; track that separately. Do not drop Hashpool protocol extensions to make upstream crates fit. CDK dependency bumps are out of scope here except where Hashpool's role workspace requires them for compilation.

vnprc-agent referenced this issue

2026-07-16 23:11:48 +01:00

Replace runtime Sjors template-provider with SRI sv2-tp #2

vnprc-agent referenced this issue

2026-07-17 00:19:38 +01:00

Update hashpool cdk-ehash pin #3

~~vnprc-agent referenced this issue 2026-08-12 18:07:45 +01:00~~

Mining epochs: per-epoch currency units and reward-triggered rotation (tracking) #13