feat: share CDN bandwidth rail across a payer's data sets - #527
Draft
juliangruber wants to merge 2 commits into
Draft
feat: share CDN bandwidth rail across a payer's data sets#527juliangruber wants to merge 2 commits into
juliangruber wants to merge 2 commits into
Conversation
Multi-copy upload stores a piece in 2 data sets on 2 providers. With withCDN on both, the CDN bandwidth service was bought twice. This lets a client buy it once: the withCDN metadata value carries an optional group id, FWSS keys a shared bandwidth rail by keccak256(payer, groupId), and data sets in the same group join one rail instead of creating a second. The shared cdnRailId is the subscription identity, settled once via the new settleCDNBandwidthRail(cdnRailId, cdnAmount). The cache-miss rail stays per data set (its payee is the data set's SP). cdnRailRefCount tracks members so the bandwidth rail is torn down only at zero across the termination, deletion, and abandonment paths. Empty group id keeps the legacy one-rail-per-data-set behavior.
Run make gen and make update-abi so the checked-in artifacts match the shared bandwidth rail changes: settleCDNBandwidthRail and the UnknownCDNBandwidthRail error in the ABIs, and the cdnGroupRail (slot 23) and cdnRailRefCount (slot 24) mappings in the layout JSON.
Contributor
|
Marked as potential for #534 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Lets a client buy the CDN bandwidth service once and share it across multiple data sets, instead of paying for it per data set. This is the core, on-chain part of a cross-repo proposal.
Full proposal, with rationale and the companion changes in the other repos: https://gist.github.com/juliangruber/a34b225f9588ec68d069054d731e20c9
The gist also links to the companion draft PRs in
FilOzone/synapse-sdk,filbeam/contracts, andfilbeam/worker.Why
The SDK now does multi-copy upload, a piece is stored in 2 data sets on 2 providers. When
withCDNis enabled on both, each data set creates its own CDN bandwidth rail to the same FilBeam beneficiary, so the bandwidth service is bought twice: the 0.7 USDFC lockup is reserved twice and there are two rails for FilBeam to meter against. The bytes are delivered to the end user once, so this duplication is pure cost to the client.The cache-miss rail is different, its payee is the data set's SP, which differs across the two copies, so it genuinely stays per provider.
How
A CDN subscription is keyed by
(payer, groupId), wheregroupIdis an optional value carried in thewithCDNmetadata entry (its presence was the only thing read before, the value was unused). FWSS maps that key to a single shared bandwidth rail.cdnGroupRail(subscription key to sharedcdnRailId) andcdnRailRefCount(members per shared rail), appended at slots 23 and 24.createRailsreuses an active shared bandwidth rail when the group key matches, skipping the second rail and its lockup. The first member creates and seeds it. The cache-miss rail is always created per data set.validatePayerOperatorApprovalAndFundsonly requires the bandwidth lockup for the first member of a subscription.settleCDNBandwidthRail(cdnRailId, cdnAmount)settles the shared rail once for the whole subscription.settleFilBeamPaymentRailsremains for cache-miss and legacy ungrouped data sets.terminateCDNService,dataSetDeleted, abandonment) decrements the ref count and terminates the bandwidth rail only when the last member leaves.The shared
cdnRailIdis the subscription identity, so downstream systems aggregate bandwidth by rail id and need no knowledge of group ids.Compatibility
Purely additive. An empty
withCDNvalue keeps the legacy one-rail-per-data-set behavior, ref counting only engages for grouped data sets. No change to the immutable FilBeam beneficiary and no new signed-message format, the group id is already covered by the EIP-712 creation signature.Follow-ups
These are intentionally out of scope for this draft.
.sollayout binding is updated here, the generated.jsonartifact is not).cdnRailRefCount/cdnGroupRailif FilBeam wants to read subscription membership on-chain.