[Provider] Investigate provider validations (role, bucket, agrement, user, ...)

[bkontur]

Relates to comment: https://github.com/paritytech/polkadot-sdk/pull/10731/files#r3242396564

iirc, the actual code turned off auth validation on provider.

TODO

• Summarize
  • what validations is provider doing now
  • what validations are missing
    • cross-chain genesis hash validation?
  • what is the final set of validations on the provider

[bkontur]

@danielbui12 please, start with summarize where are we now and what is missing.

cc: @eskimor

[danielbui12]

The summary is in a flow-driven way. I believe it might be easier to read and verify

[danielbui12]

Flow 1: Data Upload and Commit

Step 1.1 — PUT /node accepts a chunk or internal Merkle node

• Current
  • Storage layer recomputes blake2_256(data) and rejects mismatch with InvalidHash (provider-node/src/storage/disk.rs:204-210).
  • For internal nodes, every non-zero child hash must already exist; missing ones return ChildrenMissing (provider-node/src/storage/disk.rs:213-235).
  • Per-hash dedup is enforced (provider-node/src/storage/disk.rs:258-263).
  • Bucket quota check exists (provider-node/src/storage/disk.rs:243-249) but is dormant because init_bucket is called with u64::MAX (provider-node/src/api.rs:210).
• Missing
  • MEDIUM - Bucket existence on-chain. The provider stores nodes for any bucket_id the caller supplies, without confirming the bucket exists on chain or that an agreement names this provider. Wastes disk and lets clients pollute namespaces, but not a direct slashing risk on its own.
  • MEDIUM - Quota wiring: init_bucket should derive max_bytes from the on-chain StorageAgreement.max_bytes. Today the quota check is dormant, so a misbehaving client can push the provider past committed_bytes and break the stake-to-bytes invariant.
  • MEDIUM - Refuse uploads when the bucket is frozen. Stored data is dead weight once the bucket is frozen at a prior seq.
  • MEDIUM - Refuse uploads when the agreement is past expiry or inside an expiry margin (margin should cover at least one checkpoint window so data has time to be anchored). Consumes the cached expires_at populated by AgreementAccepted / AgreementEnded events (see ## Flow 10).
  • HIGH - Caller authorization. The route is not wrapped in check_role, so a non-member can upload to any bucket when auth is disabled, and even when auth is enabled it is not invoked here. In any multi-tenant deployment this lets arbitrary HTTP callers corrupt other users' buckets and force the provider to sign commitments over data it never authorized.
• Final validation set
  • Bucket has an active StorageAgreement<bucket_id, self> on chain.
  • Caller has Role::Writer or Role::Admin for the bucket.
  • bucket.used_bytes + len(data) ≤ agreement.max_bytes.
  • blake2_256(data) == expected_hash. Foundation of the proof system; if violated the provider is undefendable in challenges.
  • All declared children already stored. Without this, MMR proof generation against this node is corrupt.
  • Idempotent dedup on the hash key. Invariant for content-addressed storage; not a safety check on its own.

Step 1.2 — POST /commit advances the bucket MMR and signs a commitment

• Current
  • Commitment is built and signed (provider-node/src/api.rs:254-283); the signature uses state.sign() with the provider's sr25519 key.
  • No validation of the supplied data_roots against any chain state.
• Missing
  • HIGH - That every data_root was previously stored (storage.collect_chunks(root) would expose missing subtrees). If any subtree is missing, the next challenge against that range produces ProofGenerationFailed → full-stake slash at deadline.
  • HIGH - Refuse /commit when the new commitment's start_seq < bucket.frozen_start_seq. Without this, the provider signs commitments the chain will reject with SnapshotViolatesFrozen and may waste the agreement period.
  • HIGH - On PrimaryProviderRemoved or ProviderSlashed for self, stop accepting /commit for the bucket. Signing here is wasted at best and dangerous at worst — an old signature may be replayed against a later challenge.
  • MEDIUM - That an active agreement still exists and is not inside the expiry margin. Without it the signed commitment cannot anchor on chain.
  • HIGH - Caller authorization (writer/admin) — currently anyone with HTTP access can advance the MMR and force the provider to sign a commitment they did not relate to.
• Final validation set
  • Bucket and agreement live on chain.
  • Caller is writer or admin.
  • Every data_root resolves to a full local subtree.
  • start_seq ≥ frozen_start_seq for the bucket (if frozen).
  • Commit proceeds, signature is over CommitmentPayload(bucket_id, mmr_root, start_seq, 0).

[danielbui12]

Flow 2: Agreement Acceptance (Auto-accept background job)

Step 2.1 — Poll on-chain AgreementRequests

• Current
  • 6-second poll over the entire AgreementRequests map (provider-node/src/agreement_coordinator.rs:34).
  • Manual key parsing with a 104-byte length sanity check (provider-node/src/agreement_coordinator.rs:228-232); Get account bytes to parse then validate to equal with this provider's account (provider-node/src/agreement_coordinator.rs:238).
• Missing
  • Acceptable, the chain-side iteration and key filter are the only checks needed at this step. Better if we can have structure for AgreementRequests parser.

Step 2.2 — Auto-accept matching requests

• Current

  • Every matched request is submitted via accept_agreement(bucket_id). No economic pre-check is performed.

• Missing

  • LOW - request.max_bytes fits within provider.settings.max_capacity - provider.committed_bytes.
  • LOW - provider.stake ≥ (committed_bytes + request.max_bytes) × MinStakePerByte.
  • LOW - Per-agreement business policy (price acceptance, duration window) so operators can decline rather than auto-accept everything.
  • LOW - provider_info.deregister_at is None (provider is not winding down). Pallet's ensure_provider_active will reject. This is new feature, just added recently.
  • LOW - Replica agreements: provider settings still expose replica_sync_price and the offered min_sync_interval is acceptable. Pallet rejects mismatches.

  The pallet still re-validates everything at extrinsic time; the missing checks are for cost avoidance and policy expression, not safety.

• Final validation set

  • Account match.
  • Provider still active (no pending deregister).
  • Capacity headroom check.
  • Stake-to-bytes invariant check.
  • Optional policy hook (price/duration acceptance) before submitting accept_agreement.

[danielbui12]

Flow 3: Client-Initiated Checkpoint

Step 3.1 — Client requests a signature via GET /checkpoint-signature

• Current
  • Provider reads its local BucketInfo and blindly signs CommitmentPayload(bucket_id, mmr_root, start_seq, leaf_count). No validation beyond bucket existence (provider-node/src/api.rs:357-384).
• Missing
  • MEDIUM - Whether the provider is in bucket.primary_providers on chain. Signing as a non-primary is futile and wastes the caller's trip.
  • MEDIUM - Whether bucket.frozen_start_seq would reject this start_seq — the pallet enforces start_seq ≥ frozen_start (pallet/src/lib.rs:2275-:280) and signing under a frozen range produces a doomed checkpoint.
  • HIGH - Caller authorization. Without this, any HTTP caller can obtain the provider's signature over an arbitrary commitment.
• Final validation set
  • Provider is currently a primary for the bucket.
  • start_seq would satisfy any frozen-start constraint.
  • Caller is writer or admin.
  • Sign and return.

Step 3.2 — Provider acts as peer-signer for another leader (POST /checkpoint/sign)

• Current
  • Three-field equality check before signing: local mmr_root, start_seq, and leaf_count must all match the proposal (provider-node/src/api.rs:576-578).
  • On disagreement, returns agreed: false with the local root.
• Missing
  • MEDIUM - Frozen-start check (same gap as 3.1).
  • LOW - That the requester is actually the expected leader for proposal window. The chain enforces this with NotCheckpointLeader; off-chain check only prevents wasted signing capacity.
• Final validation set
  • Local view matches all three proposal fields.
  • start_seq satisfies frozen-start constraint.
  • Window number is the current window (cheap sanity check against replays).
  • Sign over CheckpointProposal and return.

[danielbui12]

Flow 4: Provider-Initiated Checkpoint (Coordinator)

Step 4.1 — Build the duty

• Current (provider-node/src/checkpoint_coordinator.rs:339-434)
  • Bucket exists locally with leaf_count > 0.
  • Reads CheckpointConfigs from chain or falls back to documented defaults.
  • Window is computed as current_block / interval, matching the pallet's calculate_window.
• Missing
  • MEDIUM - Whether the provider is in bucket.primary_providers. Submitting as a non-primary wastes the extrinsic and may miss a real window.
  • LOW - Whether config.enabled is true. Pallet rejects with ProviderCheckpointsDisabled.
  • MEDIUM - Whether this window has already been submitted (LastCheckpointWindow<bucket_id>). Avoids wasted submissions and helps detect when another primary beat this one to the window.
  • LOW - Whether this provider is the leader for the window during the grace period. Pallet enforces with NotCheckpointLeader.
• Final validation set
  • Primary membership confirmed.
  • Window-based checkpoints enabled.
  • Window strictly greater than LastCheckpointWindow.
  • Either the leader during grace, or any primary after grace.
  • Defaults applied only when chain config absent.

Step 4.2 — Collect peer signatures and submit

• Current
  • Self-signs, then collects from peer_endpoints until done or signature_timeout elapses.
  • Currently uses min_required = 1 as a placeholder (provider-node/src/checkpoint_coordinator.rs:488).
• Missing
  • MEDIUM - Read bucket.min_providers from chain; refuse to submit below threshold.
  • LOW - Validate every collected signature locally before submission. Chain re-verifies; local validation only avoids wasted RPC.
• Final validation set
  • Self-signature added.
  • At least bucket.min_providers valid signatures collected.
  • Submit provider_checkpoint(...).

[danielbui12]

Flow 5: Challenge Response

Step 5.1 — Detect a challenge targeting this provider

• Current (provider-node/src/challenge_responder.rs:289-307)
  • poll_challenges is stubbed and returns vec![]. Detection happens only via explicit ResponderCommand::RespondTo.
• Missing
  • HIGH - Live iteration of Challenges or event-stream subscription with a filter on challenge.provider == self. Without this, an unattended provider can be slashed for a challenge it never knew existed.
  • HIGH - Deadline tracking and prioritization by remaining blocks. The cost split worsens steeply with response time, a slow responder pays heavily even when defended. I.e. 90/10 at ≤1 block, 50/50 at ≥96 blocks
• Final validation set
  • Continuous detection of all challenges against this provider, with each challenge tracked until either responded or expired.

Step 5.2 — Construct the proof

• Current (provider-node/src/challenge_responder.rs:310-376)
  • Calls storage.get_mmr_proof(bucket_id, leaf_index); failure returns ProofGenerationFailed.
  • Calls storage.get_chunk_at_index(data_root, chunk_index); failure returns DataNotFound.
• Missing
  • MEDIUM - Pre-flight check that the local MMR root matches challenge.mmr_root. If they diverge, the proof would be valid only against a different commitment and the pallet would reject, costing the deadline.
  • HIGH - If the chunk is genuinely deleted with admin authorization, the responder should produce ChallengeResponse::Deleted rather than Proof. Currently only Proof is constructed, so legitimately deleted data cannot be defended.
  • HIGH - If the leaf is already inside the canonical snapshot, ChallengeResponse::Superseded should be considered. Without this variant, superseded leaves become undefendable too.
• Final validation set
  • Determine which response variant applies based on local state and the challenge's mmr_root / start_seq / leaf_index.
  • For Proof: MMR proof generation and chunk-proof generation must both succeed.
  • For Deleted: a stored admin signature over the deletion commitment must be present.
  • For Superseded: confirm the leaf is inside bucket.snapshot.start_seq + leaf_count.

Step 5.3 — Submit

• Current
  • Builds a dynamic value for ChallengeResponse::Proof and submits respond_to_challenge.
• Missing
  • HIGH - No retry logic, no deadline-aware scheduling. A transient submission failure near the deadline becomes a full-stake slash.
  • MEDIUM - No logic handles ChallengeResponse::Deleted or ChallengeResponse::Superseded
• Final validation set
  • Submit before deadline; alert if submission fails within the high-cost band.

[danielbui12]

Flow 6: Provider-as-Source (inbound from peers/replicas)

When this provider is a primary, replicas and clients pull bytes from it via the MMR-shape and node-fetch endpoints. The validation surface here is what protects bucket data from unauthorized reads and protects the primary's IO budget from abuse.

Step 6.1 — Peer requests MMR topology (GET /mmr_peaks, GET /mmr_subtree)

• Current
  • /mmr_peaks reads the bucket's mmr_root and peaks from local storage (provider-node/src/api.rs:484-498). Returns BucketNotFound if the bucket is not present locally.
  • /mmr_subtree is a stub (api.rs:500-517, comment: "Simplified implementation"). It returns a single node with the bucket's root hash and no children, regardless of query parameters. Not yet a real subtree walk.
  • Neither endpoint authenticates the caller or rate-limits.
• Missing
  • MEDIUM (multi-tenant) - Caller authorization. Mapping the MMR shape leaks how much data the bucket holds and the commitment structure; private buckets should not expose this to unauthenticated callers.
  • LOW - Bucket existence on chain (not just local). Without this, the endpoint replies BucketNotFound regardless of whether the bucket is unknown or simply does not exist; an attacker can probe for valid bucket IDs by other means anyway.
  • LOW - Apply rate limit

Missing /mmr_subtree real implementation.

• Final validation set
  • Caller has Reader/Writer/Admin role for the bucket, or is named in an active replica agreement.
  • Per-caller rate limit applied.
  • /mmr_subtree returns an actual subtree slice.

Step 6.2 — Peer fetches node data (POST /fetch_nodes)

• Current
  • Takes a JSON body with hashes: [hex...] ONLY — no bucket_id parameter (api.rs:519-546).
  • For each hash, calls state.storage.get_node(&hash) which is a global content-addressed lookup against CF_NODES. Returns whatever it finds.
  • No authentication, no bucket scoping, no rate limiting.
  • Because node storage is global by hash, a single node shared across buckets via dedup is reachable from any bucket context — the endpoint has no way to express "fetch only nodes from bucket X".
• Missing
  • HIGH (multi-tenant) - Caller authorization. Without this, any HTTP caller who knows a node hash can pull the bytes. Hashes are discoverable by walking from /mmr_peaks, so private buckets are effectively public.
  • HIGH - May be add a bucket_id parameter to the request and reject hashes that are not reachable from that bucket's MMR.
  • MEDIUM - Per-caller bandwidth/rate limit. /fetch_nodes can return large payloads; an unauthenticated or unbounded caller can consume the primary's IO budget.
  • LOW - Surface partial-fetch information explicitly. Today missing hashes are silently dropped from the response; the response should indicate which requested hashes were not found so the caller can diagnose.
• Final validation set
  • Caller authenticated.
  • Request scoped to a bucket_id; nodes returned only if reachable from that bucket's MMR.
  • Caller has read access to that bucket (member with Reader role or higher, or replica in an active agreement).
  • Per-caller bandwidth/rate limit enforced.
  • Missing hashes reported explicitly in the response.

Step 6.3 — Peer requests historical roots and sync status (GET /replica/historical_roots, GET /replica/sync_status)

This step is still in-progress, no real implementation.

• Final validation set
  • Both endpoints return real data (chain-sourced historical_roots; coordinator-sourced sync status).
  • Caller authenticated.
  • For private buckets, caller has Reader role or is a replica.

[danielbui12]

Flow 7: Replica Sync

Step 7.1 — Discover replica duties

• Current (provider-node/src/replica_sync_coordinator.rs:391-469)
  • Filters on-chain agreements where this provider is a replica.
  • Skips when sync_balance < sync_price (prevents InsufficientSyncBalance).
  • Skips when min_sync_interval has not elapsed (prevents SyncTooFrequent).
  • Skips when no snapshot exists (mmr_root == zero) or when already synced.
• Missing
  • LOW - Validation that the chosen target root is present in either bucket.snapshot or bucket.historical_roots — the pallet's find_matching_root will otherwise return InvalidSyncRoot. The local code uses snapshot.mmr_root directly, which is fine for the current snapshot but inflexible if catching up to a recent historical root.

Step 7.2 — Fetch from a primary

• Current
  • Tries primaries in order; on each, compares the returned root to the target and only accepts on equality (provider-node/src/replica_sync_coordinator:541:560).
• Missing
  • Nothing material at this point; The integrity check in store_node (Flow 1.1, storage/disk.rs:204-210) protects this automatically as long as the sync path persists via store_node rather than writing to the database directly.

Step 7.3 — Final verification before submitting

• Current (provider-node/src/replica_sync_coordinator:580:600)
  • Re-reads local bucket and confirms local.mmr_root == target.mmr_root. Mismatch returns VerificationFailed and the chain is not touched.
• Missing
  • Nothing material at this point; the three-stage verification is already qualified.

Step 7.4 — Submit confirm_replica_sync

• Current
  • Builds the 7-root array and submits.
• Missing
  • LOW - Locally compute which position_matched will be returned so the result can be verified after submission.
• Final validation set
  • Identical to current. Plus, a post-submission consistency check.

[danielbui12]

Flow 8: Data Deletion

Step 8.1 — POST /delete removes leaves and advances start_seq

• Current (provider-node/src/api.rs:456-477)
  • Reads request.admin_signature and explicitly discards it (let _ = ...).
  • Calls storage.delete_before(...) and signs the new commitment with the provider's key.
• Missing
  • HIGH - Admin signature verification over the CommitmentPayload(bucket_id, new_mmr_root, new_start_seq, 0) at provider-node/src/api.rs:461 that the chain expects in ChallengeResponse::Deleted (pallet/src/lib.rs:2986:994). Without it the provider deletes data on unauthenticated request and then cannot defend the resulting gap.
  • HIGH - Caller authorization (no check_role invocation). Any HTTP caller can trigger deletion.
• Final validation set
  • Caller is the bucket admin (verified via role check).
  • Provided admin_signature validates against the new commitment payload and the bucket's admin.
  • Deletion is persisted along with the admin signature for future challenges.
  • Provider signs the new MMR commitment.

[danielbui12]

Flow 9: Read storage

Step 9.1 — GET /read, GET /mmr_proof, GET /chunk_proof, GET /node

• Current
  • No validation beyond local existence.
• Missing
  • MEDIUM - Reader-role authorization (when auth is enabled). In multi-tenant deployments this is required for confidentiality; in gateway-gated deployments it is lower priority.
• Final validation set
  • Caller has at least Role::Reader.
  • Local data exists.

[danielbui12]

Event driven for state (to implement)

The validations in above flows may got actual rejection logic due to missing realtime data polling from on-chain.

Suggest Implementation pattern: subscribe to StorageProvider pallet events at startup, maintain a small set of in-memory caches keyed by bucket_id or (bucket_id, account_id), and let request handlers consult these caches synchronously.

Events need to be subscribed:

• BucketFrozen events (and any future Unfreeze event). Consumed by Flow 1.1 (refuse uploads when frozen), Flow 1.2 (refuse /commit with start_seq < frozen_start_seq), Flow 3.1 / 3.2 (refuse to sign checkpoint payloads under a frozen range).
• We already have MembershipCache (provider-node/src/auth.rs:48-105) but TTL-only. Needs event-driven invalidation on MemberAdded / MemberRemoved / MemberRoleUpdated events so revoked roles do not linger for up to one TTL. Consumed by every authorized HTTP route.
• AgreementAccepted, ProviderAddedToBucket, PrimaryProviderRemoved, ProviderSlashed, AgreementEnded events. Consumed by Flow 1.1, 1.2, 3.1, 3.2, 4.1, 6.x (refuse to serve buckets the provider no longer belongs to). Critical because old signatures over a bucket the provider has been removed from can be replayed against later challenges.
• AgreementAccepted, AgreementToppedUp (no change), AgreementExtended, AgreementEnded. Consumed by Flow 1.1 and 1.2 to refuse writes inside an expiry margin so uploaded data has time to be anchored before the agreement ends.
• ProviderUpdated, StakeAdded, and slash events. Consumed by Flow 2.2 (admission decisions use current values) and operator-alerting (stake-to-bytes invariant drift).
• BucketCleanedUp from the drive-registry pallet. Consumed by the cleanup scheduler to purge orphaned local state.

PR relates to this: #81

[bkontur]

@danielbui12 please, tell you assistant to create simple summary table - list of validations, column implement or not missing, column needed for W3S demo or not...

Still we can go with auth turned off on provider (as it is now for W3S).

@eskimor wdyt?

[danielbui12]

Okay, here is the validation findings by flow in a table

Flow	Step	Endpoint / Component	Severity	Gap
1. Data Upload & Commit	1.1	PUT /node	HIGH	No caller authorization (check_role not wrapped); any HTTP caller can write to any bucket
1. Data Upload & Commit	1.1	PUT /node	MEDIUM	No on-chain bucket existence check; provider stores nodes for arbitrary bucket_id
1. Data Upload & Commit	1.1	PUT /node	MEDIUM	Quota dormant — init_bucket uses u64::MAX instead of agreement's max_bytes
1. Data Upload & Commit	1.1	PUT /node	MEDIUM	No refuse-on-frozen-bucket check
1. Data Upload & Commit	1.1	PUT /node	MEDIUM	No expiry-margin refusal so uploaded data has time to be anchored
1. Data Upload & Commit	1.2	POST /commit	HIGH	Caller authorization missing
1. Data Upload & Commit	1.2	POST /commit	HIGH	No verification that every data_root resolves to a full local subtree (risks ProofGenerationFailed slash)
1. Data Upload & Commit	1.2	POST /commit	HIGH	No refusal when start_seq < bucket.frozen_start_seq (chain rejects with SnapshotViolatesFrozen)
1. Data Upload & Commit	1.2	POST /commit	HIGH	No refusal after PrimaryProviderRemoved / ProviderSlashed for self (signature replay risk)
1. Data Upload & Commit	1.2	POST /commit	MEDIUM	No active-agreement / expiry-margin check
2. Agreement Acceptance	2.1	Poll loop	—	Acceptable (cosmetic improvement only: structured parser)
2. Agreement Acceptance	2.2	accept_agreement	LOW	No capacity-headroom check (max_bytes ≤ free capacity)
2. Agreement Acceptance	2.2	accept_agreement	LOW	No stake-to-bytes invariant pre-check
2. Agreement Acceptance	2.2	accept_agreement	LOW	No business-policy hook (price/duration acceptance)
2. Agreement Acceptance	2.2	accept_agreement	LOW	No deregister_at == None check
2. Agreement Acceptance	2.2	accept_agreement	LOW	No replica-specific (replica_sync_price, min_sync_interval) policy check
3. Client-Initiated Checkpoint	3.1	GET /checkpoint-signature	HIGH	No caller authorization — anyone can obtain a signature over an arbitrary commitment
3. Client-Initiated Checkpoint	3.1	GET /checkpoint-signature	MEDIUM	No check that provider is in bucket.primary_providers
3. Client-Initiated Checkpoint	3.1	GET /checkpoint-signature	MEDIUM	No frozen_start_seq check
3. Client-Initiated Checkpoint	3.2	POST /checkpoint/sign (peer signer)	MEDIUM	No frozen-start check
3. Client-Initiated Checkpoint	3.2	POST /checkpoint/sign (peer signer)	LOW	No leader-for-window sanity check
4. Provider-Initiated Checkpoint	4.1	checkpoint_coordinator build duty	MEDIUM	No primary-membership check
4. Provider-Initiated Checkpoint	4.1	checkpoint_coordinator build duty	MEDIUM	No LastCheckpointWindow dedupe check
4. Provider-Initiated Checkpoint	4.1	checkpoint_coordinator build duty	LOW	No config.enabled check
4. Provider-Initiated Checkpoint	4.1	checkpoint_coordinator build duty	LOW	No leader-during-grace check
4. Provider-Initiated Checkpoint	4.2	Submit checkpoint	MEDIUM	Uses min_required = 1 placeholder instead of reading bucket.min_providers
4. Provider-Initiated Checkpoint	4.2	Submit checkpoint	LOW	No local validation of collected peer signatures before submission
5. Challenge Response	5.1	poll_challenges	HIGH	poll_challenges is a stub returning vec![] — unattended providers cannot detect challenges
5. Challenge Response	5.1	poll_challenges	HIGH	No deadline tracking / prioritization (cost split steepens with response time)
5. Challenge Response	5.2	Construct proof	HIGH	No ChallengeResponse::Deleted variant — legitimately deleted data is undefendable
5. Challenge Response	5.2	Construct proof	HIGH	No ChallengeResponse::Superseded variant — leaves inside the canonical snapshot are undefendable
5. Challenge Response	5.2	Construct proof	MEDIUM	No pre-flight check that local MMR root matches challenge.mmr_root
5. Challenge Response	5.3	Submit response	HIGH	No retry / deadline-aware scheduling (transient failure ⇒ full slash)
5. Challenge Response	5.3	Submit response	MEDIUM	No handling for Deleted / Superseded variants in submission path
6. Provider-as-Source	6.1	GET /mmr_peaks, GET /mmr_subtree	MEDIUM	No caller authorization (multi-tenant); leaks bucket size / commitment structure
6. Provider-as-Source	6.1	GET /mmr_peaks, GET /mmr_subtree	LOW	No per-caller rate limit
6. Provider-as-Source	6.1	GET /mmr_peaks, GET /mmr_subtree	LOW	No on-chain bucket existence check
6. Provider-as-Source	6.1	GET /mmr_subtree	—	Stub implementation — needs real subtree walk before validations are meaningful
6. Provider-as-Source	6.2	POST /fetch_nodes	HIGH	No caller authorization; any HTTP caller knowing a node hash can pull bytes
6. Provider-as-Source	6.2	POST /fetch_nodes	HIGH	No bucket_id param + reachability check — global content-addressed lookup breaks per-bucket access control (design change)
6. Provider-as-Source	6.2	POST /fetch_nodes	MEDIUM	No per-caller bandwidth / rate limit
6. Provider-as-Source	6.2	POST /fetch_nodes	LOW	Missing hashes silently dropped — should be reported explicitly
6. Provider-as-Source	6.3	GET /replica/historical_roots	HIGH	Returns six hard-coded empty strings; either populate from chain or remove
6. Provider-as-Source	6.3	GET /replica/sync_status	HIGH	Returns placeholders (last_sync_block: None, syncing: false); coordinator data not surfaced
6. Provider-as-Source	6.3	GET /replica/*	MEDIUM	No caller authorization (multi-tenant)
7. Replica Sync	7.1	Discover duties	LOW	Target root not validated against historical_roots (only snapshot.mmr_root); inflexible catch-up
7. Replica Sync	7.2	Fetch from primary	—	Adequate (covered by store_node integrity check)
7. Replica Sync	7.3	Final verification	—	Adequate (three-stage check)
7. Replica Sync	7.4	Submit confirm_replica_sync	LOW	No local compute of position_matched for post-submission verification
8. Data Deletion	8.1	POST /delete	HIGH	request.admin_signature is read then discarded (let _ = ...); no verification
8. Data Deletion	8.1	POST /delete	HIGH	No caller authorization (check_role missing)
9. Read Storage	9.1	GET /read, GET /mmr_proof, GET /chunk_proof, GET /node	MEDIUM	No Reader-role authorization (when auth enabled / multi-tenant)