Period-based authorizations

[franciscoaguirre]

Created on top of bko-authorizations to align both issues: no gaps in authorizations and unlimited low-priority store() transactions.

Background

Authorizations on Bulletin used to be block-number-based (AuthorizationPeriod = 90 days) and decoupled from the People-Chain claim period. The recent soft-cap PR made store not waste blockspace, but renew became unbounded and bytes_permanent grew across refreshes without ever decrementing — disk burden was no longer pinned by anything.

This PR re-aligns Bulletin's authorizations with the People-Chain claim period, swaps the per-account block expiry for a two-slot (current, next) period grant, and finalises the soft-store / hard-renew / tx-quota accounting. Refresh extrinsics are gone; period rollover does the work.

How a holder uses the chain (Alice, 14-day period, 10 MiB / 100 tx)

1. Basic period — soft cap, blockspace never wasted

Alice claims long-term storage on People for the current period P; People sends authorize_account(Alice, 100, 10 MiB, P) to Bulletin via XCM. Throughout P:

• store(8 MiB) → in-budget. Top tier (base + ALLOWANCE_PRIORITY_BOOST). State: bytes = 8 MiB, tx_used = 1.
• store(3 MiB) → combined 11 MiB > 10 MiB. Bottom tier (base, no boost). The tx still validates and rides leftover blockspace; bytes saturates to 11 MiB; tx_used stays at 1 because over-budget stores don't burn tx slots.

Alice can keep submitting low-priority stores indefinitely after her allowance is exhausted — they only land when there's spare blockspace. Blocks never sit empty because of allowance enforcement, and the bound on total temp storage comes from chain physics (MaxBlockBytes × RetentionPeriod ≈ 1.7 TiB), not from a per-tx rejection.

2. Two-slot model + forward claim

Alice wants continuous coverage across the period boundary so auto-renewals (see §4) survive. While still in P, she submits a second People-Chain claim with period = P + 1. The People predicate now accepts current + 1; the XCM lands as authorize_account(Alice, 100, 10 MiB, P + 1) on Bulletin, which routes it into the next slot:

Authorization { current: Some(PG{P}), next: Some(PG{P+1}) }

When the clock crosses into P + 1, the next call against Alice's authorization runs prune-and-shift: current (P) is expired and dropped, next (P + 1) is promoted into current. Both slots' counters start fresh at zero — no refresh extrinsic, no bytes_permanent carry-over.

If Alice forgets to forward-claim, period rollover leaves current = None. store and renew reject; her blobs lapse after their RetentionPeriod. Stale entries are removed by the existing remove_expired_account_authorization permissionless call.

3. Multiple claims in the same period add

A credential entitles its holder to N claims per period, each granting 1/N of the credential's per-period maximum. (E.g., PoP with N = 4 might give 4 claims of 2.5 MiB / 25 tx each, totalling 10 MiB / 100 tx per period.) The claims are independent calls of claim_long_term_storage(period, counter, account_id), where counter ∈ 0..N indexes the claim within the period. The holder can spend any subset, in any order, at any time during the period — People-Chain bookkeeping enforces that each (period, alias, counter) is spent at most once. PoP and PoP-Lite are mutually exclusive at the credential level; this mechanic stacks claims of the same credential, not different ones.

Bulletin's authorize routes every same-period claim into the same slot and adds. Worked example, Alice spends claims 0 and 1 of her four in period P:

• After claim 0: bytes_allowance = 2.5 MiB, transactions_allowance = 25
• After claim 1: bytes_allowance = 5 MiB, transactions_allowance = 50
• Used counters (bytes, bytes_permanent, tx_used) are preserved across the second claim, so her in-period spending so far isn't erased by topping up.

Two design properties matter here:

1. Holders can size their footprint mid-period. Spend two claims now, hold the other two in reserve, top up later if needed. There's no penalty for not pre-claiming the full budget.
2. No abuse vector via re-authorize. Each claim is alias-spent on People before the XCM goes out, so a holder can't loop the same claim to refill bytes_allowance repeatedly.

This is the only mechanic by which a slot's allowance grows mid-period; any other source (a different credential, an out-of-period claim) is rejected by People-Chain validation before it ever reaches Bulletin.

4. Renew is hard-capped — composes with data-renewal PR (#313)

renew(...) consumes from the same per-period budget as store. The cap is a hard rejection on the combined byte counter and on transactions_used:

combined = bytes + bytes_permanent + size
if combined > bytes_allowance OR tx_used + 1 > tx_allowance: REJECT

Worked example, period P + 1 starts with Alice's next slot promoted to current with a fresh 10 MiB / 100 tx grant:

step	call	bytes	bytes_perm	combined	tier
1	auto-renew → renew(8 MiB blob)	0	8	8	top
2	store(2 MiB)	2	8	10	top (at edge)
3	renew(3 MiB other blob)	2	8	would be 13	REJECTED
4	store(5 MiB)	7	8	15	bottom

Alice has full freedom to split her budget — keep 8 MiB alive AND store 2 MiB new at boost priority, AND throw 5 MiB more at low priority. She cannot force-renew past 10 MiB combined; that's what bounds disk burden under repeated auto-renewals.

Composition with the data-renewal PR: auto-renewal schedules renew(block, index) on the holder's behalf shortly before each blob's RetentionPeriod elapses. The renewal is subject to the hard cap above. The forward-claim mechanic from §2 is what makes auto-renewal correct across period boundaries: the next slot is in place when the renewal fires, prune-and-shift promotes it, and the renewal lands. Holders who stop claiming see their auto-renewals start failing — their blobs lapse cleanly without leaving permanently-orphaned data behind.

5. Transactions quota as DoS shield

Independently of the byte budget, transactions_allowance caps the number of boost-tier calls a holder can land per period. Why the boost tier specifically: a holder with 10 MiB / period byte allowance could otherwise land 10 M boost-priority 1-byte stores for free, occupying MaxBlockTransactions slots across blocks. The cap stops that.

Alice with transactions_allowance = 3, plenty of bytes:

call	tx_used after	tier
store(1 byte) ×3	1, 2, 3	top each time
4th store(1 byte)	3 (unchanged)	bottom — over tx budget

The 4th store still validates (soft cap on the boost — never rejection on store); it just lands as low priority and the tx counter doesn't tick. Alice can submit unlimited low-priority 1-byte stores after the boost budget is exhausted, bounded only by chain capacity. Renew, by contrast, is hard-rejected once tx_used + 1 > tx_allowance, since it has no low-priority path.

Failure mode if the holder stops engaging

State	Behavior
Forward-claimed next exists	Period rolls over → prune-and-shift → renewals continue.
Forgot to forward-claim	Period rolls over → current = None → renewals reject → blobs lapse one RetentionPeriod after their last renew. No silent revival.
Re-claims later for the new period	Fresh grant in current. New stores work; previously-lapsed blobs are gone.

Surface changes

• AuthorizationExtent gains bytes_permanent, transactions_used, transactions_allowance. Authorization is now { current: Option<PeriodGrant>, next: Option<PeriodGrant> }.
• Config: drops AuthorizationPeriod; adds TimeProvider: UnixTime and PeriodDuration: Get<u64> (must match People's LongTermStoragePeriodDuration).
• Extrinsics: authorize_account(who, transactions, bytes, for_period), authorize_preimage(content_hash, max_size, for_period). for_period ∈ {current, current + 1}. Same-slot re-authorize adds. Refresh extrinsics removed.
• AllowanceBasedPriority boost matches Call::renew too; BoostStrategy::boost consults bytes + bytes_permanent AND tx_used against the post-this-tx state.
• People-Chain: is_accepted_long_term_storage_period now also accepts current + 1; claim_long_term_storage threads for_period through, mapping grace claims to the current period before XCM. AllocateStorage trait gains for_period and current_period(), drops refresh_allocation.
• v1 → v2 migration translates old {transactions, bytes} single-grant into the new two-slot shape with current.period = current_period_at_upgrade and used counters at zero.

Tests

• pallet-bulletin-transaction-storage: 36/36
• indiv-pallet-resources: 94/94
• indiv-pallet-proof-of-ink: 40/40
• Runtime builds clean: bulletin-westend-runtime, bulletin-paseo-runtime, next-people-paseo-runtime

Out of scope

• Auto-renewal itself (renew storage by content_hash & auto renewal #313). This PR is what makes auto-renewal correct when it lands.
• Proof-of-ink authorization-lifetime redesign. PoI compiles against the new trait and now grants last one period instead of 90 days — known regression, follow-up PR.
• A shared bp-bulletin-people primitives crate for PeriodDuration. Currently inlined in both bulletin runtimes with TODO comments; alignment with People's LongTermStoragePeriodDuration is by convention.

[franciscoaguirre]

Closing in favor of #509