Blockchain has emerged as a coordination layer for transparent settlement and direct media monetization, though most designs focus on coarse-grained business workflows rather than chunk-level stream authorization [1]. While prototypes successfully integrate smart contracts with decentralized storage for live video delivery [6], practical InterPlanetary File System deployments often face non-trivial performance and centralization trade-offs [8,13,14]. Similarly, decentralized access control frameworks for cloud and Internet of Things systems [15–17], alongside self-sovereign identity mechanisms [7,18], effectively reduce central authority reliance. However, they typically manage access at the file or service level, failing to address the dual demands of fine-grained historical clipping and continuous live subscriptions within a single encrypted stream.

Multimedia research has significantly advanced automatic sports highlight generation [3], personalized detection [4], implicit user-specified generation [5], and automated narration [19]. While these works underscore the growing demand for highly granular, personalized sports clips, they primarily focus on content understanding and generation. They generally assume the desired footage is already accessible to the system, leaving the orthogonal challenge of cryptographically enforcing fine-grained paid access over untrusted distribution networks unresolved.

ABE offers expressive fine-grained authorization [10,20], but hard-codes policies into ciphertexts, rendering it inflexible for live streams with dynamically changing audiences. For temporal access, interval-based schemes efficiently delegate bounded historical ranges [21], while key regression enables forward-only derivation of future decryption states [22]. Droplet combined these concepts into a unified framework for decentralized streams [11], and SegSub further improved resilience against re-subscription leakage via chain segmentation [12]. Additionally, accumulators and broadcast encryption have been utilized for scalable revocation and group updates [23,24]. Despite these advances, no prior system simultaneously delivers exact-granularity historical clipping, secure forward-only live continuation, resistance to subscribe-cancel-resubscribe abuse, and server-side O(1) communication during massive audience churn—a gap our three-layer architecture precisely bridges. Table 2 summarizes the key differences between representative cryptographic data-sharing schemes and our proposed design.

BHT [25] is a hierarchical structure designed for deterministic key derivation. It employs a top-down approach to expand a single root secret into a large set of related keys. Let S0,1∈{0,1}λ be the root seed at depth 0, where λ represents the security parameter. Using two independent one-way hash functions HL and HR, the nodes at depth d+1 are recursively derived from their parent node Sd,i at depth d as follows:(1)Sd+1,2i−1=HL(Sd,i),Sd+1,2i=HR(Sd,i)where i∈{1,…,2d} denotes the node index at depth d. For a tree of depth k, this construction yields N=2k distinct leaf keys. The BHT structure inherently guarantees logarithmic delegation and cryptographic isolation, providing a highly efficient mechanism for hierarchical authorization in decentralized environments.

Dynamic IBBE [24] is a cryptographic primitive that securely transmits a message M to a dynamically changing set of authorized receivers 𝒰t at any given time t. Built upon the standard Rivest-Shamir-Adleman cryptographic framework, the system computes a succinct group digest At to represent the current authorized set, and issues a private decryption key (or witness) skut to each user u∈𝒰t. To distribute content, a broadcast ciphertext CTt is generated as follows:(2)CTt=IBBE.Encrypt(PK,At,M),where PK denotes the global public parameters. Any valid user u∈𝒰t can process CTt using their specific key skut and the digest At to recover M. When the authorized set changes, the system simply updates At and the corresponding public parameters to reflect the new membership.

We consider a global ecosystem comprising multiple independent sports leagues and federations (e.g., the Premier League, the NBA, and the FIFA) acting as content providers. Each provider broadcasts numerous live matches to a global audience. Aligning with standard modern streaming protocols such as Hypertext Transfer Protocol Live Streaming and Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol, a continuous live match video 𝒱 is digitized and segmented into a finite sequence of chronological data chunks, denoted as 𝒱={m1,m2,…,mN}. To protect commercial value, these chunks are subsequently encrypted, cached, and distributed via untrusted infrastructure, including both decentralized storage networks and content delivery networks.

To securely orchestrate this ecosystem, our system involves the following interacting entities, as illustrated in Fig. 1:

Content Provider (CP): The CP is the owner and producer of the commercial streaming data. It orchestrates the entire authorization lifecycle by registering matches and commercial parameters (e.g., pricing models) on the blockchain, continuously encrypting the live video chunks, and enforcing flexible access control across diverse consumption models. Given the industrial scale of global sports broadcasting, we assume the CP is equipped with robust computational infrastructure (e.g., dedicated servers or cloud environments) capable of handling high-definition video processing and real-time cryptography.

To achieve extremely fine-grained authorization (down to a single chunk mi) while executing highly scalable dynamic access control, we propose a three-layer cryptographic architecture. This design decouples the static data payload from the dynamic authorization state by partitioning the cryptographic operations into chunk-level static encryption, stream-level key derivation, and group-level access control, thereby eliminating data re-encryption and redundant ciphertexts. The decoupled architecture of the first two layers is illustrated in Fig. 2.

Layer 1: Chunk-Level Static Encryption

For a raw video stream comprising a chronological sequence of discrete chunks 𝒱={m1,m2,…,mK}, the layer executes independent, chunk-by-chunk encryption. By configuring a BHT with an adequate depth d≥log2⁡K, we deterministically derives a mutually independent CEK ki for each respective chunk mi. Consequently, the raw payload is strictly symmetrically encrypted exactly once, yielding the data ciphertext:(3)Ci=SymEnc(ki,mi),which is subsequently offloaded to the storage infrastructure. Benefiting from the BHT’s top-down key derivation, this layer natively enables arbitrary-grained key aggregation. This topological property allows the system to efficiently share any arbitrary highlight clip of the sports stream (e.g., aggregating a minimal set of intermediate tree nodes to authorize a discrete chunk range), explicitly fulfilling the highlight buyers’ demands without introducing data redundancy.

Layer 2: Stream-Level Key Derivation

For the chronological delivery of a live streaming, this layer executes a continuous, time-bound key encapsulation. By initializing a unidirectional hash chain, we recursively derives a temporal state si uniquely corresponding to each chunk mi. This derivation is governed by a dynamic cryptographic salt, denoted as ηi, defined mathematically as si=H(si−1∥ηi). Consequently, rather than exposing the static CEK ki directly, the CP symmetrically encrypts it using the current temporal state si, yielding the lightweight key-ciphertext:(4)Ci∗=SymEnc(si,ki)which is continuously distributed as the composite ciphertext tuple {Ci,Ci∗}. To further detail the state transition, let ρi denote the block height of the most recent on-chain revocation event synchronized by the CP prior to computing state si. The salt ηi is updated by (5)ηi={0,if ρi=ρi−1VRF(skCP,ρi),if ρi>ρi−1where VRF denotes the VRF evaluation parameterized by the CP’s secret key skCP.

During periods of stable on-chain membership (ρi=ρi−1), the salt defaults to a deterministic zero (ηi=0). Legitimate subscribers holding a valid prior state si−1 can autonomously derive si and subsequent states strictly via local hash operations (i.e., si=H(si−1∥0)).

Conversely, upon detecting a new on-chain revocation (ρi>ρi−1), the CP transitions the authorization phase. By injecting a verifiable, unpredictable salt ηi, the CP mathematically breaks the hash derivation chain. Lacking this parameter, the revoked user is precluded from deriving si and any future states. Meanwhile, the remaining valid subscribers securely receive the updated ηi (detailed in Layer 3) to resume their autonomous derivation. Due to the one-way nature of the hash chain, this layer naturally guarantees backward secrecy, which means that newly joined subscribers cannot rewind the hash progression to decrypt past video chunks.

In this manner, Layer 2 achieves an event-triggered adaptive authorization segmentation, which enforces precise, time-bound access control without ever requiring the heavy static payloads in Layer 1 to be re-encrypted.

Layer 3: Group-Level Access Control

To securely distribute the dynamic salt generated in Layer 2 exclusively to authorized subscribers, this layer establishes a group-level access control mechanism by leveraging a Dynamic IBBE scheme.

Let 𝒰ρi denotes the set of active, authorized blockchain addresses, and let Aρi represent its corresponding accumulator value bound to the latest revocation block height ρi. The layer encapsulates the newly derived salt (denoted as ηρi) into a broadcast ciphertext:(6)C^ρi=IBBE.Enc(PP,Aρi,ηρi)where PP denotes the global public parameters. This ciphertext C^ρi is subsequently packaged into an on-chain transaction. The legitimate subscriber u∈𝒰ρi utilizes a cryptographic witness Wu,ρi to retrieve the salt as follows:(7)ηρi=IBBE.Dec(Wu,ρi,C^ρi).

Cryptographically, the witness Wu,ρi is inherently bound to the accumulator state Aρi. When the authorized group changes, the accumulator Aρi is updated, requiring remaining legitimate subscribers to update their witness locally via the standard Stateless Witness Update algorithm [26]:(8)Wu,ρi=WitnessUpdate(Wu,ρi−1,ΔRρi,PP)where Δℛρi denotes the membership delta (e.g., the set of revoked and added addresses) in the authorized group, which can be derived directly from recorded on-chain transactions. Users excluded from Aρi cannot obtain a valid witness to decrypt C^ρi, inherently guaranteeing forward secrecy. Additionally, regardless of the sheer volume of addresses in 𝒰ρi, the size of C^ρi depends solely on the public parameters PP, thus ensuring an O(1) communication overhead.

Ultimately, this three-layer architecture establishes a rigorous cryptographic foundation tailored for decentralized sports streaming. Specifically, Layer 1 achieves arbitrary-grained aggregated authorization, empowering users to unlock customized, discrete video segments (e.g., highlights) using a single compact key token. Concurrently, Layer 2 and Layer 3 jointly realize state-driven adaptive authorization for continuous live subscriptions.

In the on-demand scenario, the live event has concluded, and the entire video 𝒱 is securely anchored within the static Layer 1 BHT. A viewer v wishes to purchase a specific highlight reel spanning from chunk ma to mb. Since the temporal stream has finalized, this paradigm bypasses the Layer 2 Hash Chain and Layer 3 IBBE entirely, relying strictly on a direct on-chain delivery mechanism. The authorization protocol proceeds in four stages (as summarized in Algorithm 1):

Step 1: Purchase Initiation. Viewer v triggers a smart contract function BuyHighlight (addrv,a,b), transferring the requisite cryptocurrency. Upon payment validation, the contract emits a public PurchaseRequest event.

Step 2: Minimum Cover Derivation. The CP monitors the blockchain for purchase events. To authorize access, the CP derives the Minimum Node Cover 𝒩a,b from the BHT, which represents the minimal set of higher-level intermediate nodes required to perfectly reconstruct the requested subtree.

Step 3: Token Delivery. To ensure secure delivery over the public ledger, the CP encrypts 𝒩a,b using the viewer’s public key pkv. The resulting cryptographic token is Tokenv=AsymEnc(pkv,𝒩a,b). The CP submits Tokenv to the smart contract via a fulfillment transaction, prompting the contract to emit the token compactly within an on-chain event log.

Step 4: Decryption. Viewer v retrieves the emitted token from the blockchain event log, decrypts Tokenv using their local wallet private key skv, and deterministically derives all underlying CEKs {kj}j=ab via top-down hashing to unlock the specific video chunks.

Unlike the static on-demand scenario, live sports streaming requires continuous temporal progression and dynamic membership management. This workflow activates the full three-layer architecture to handle the onboarding of new subscribers and the access severance of revoked users, entirely without re-encrypting the video payload. The protocol operates through a continuous steady-state derivation, punctuated by rigorous state transitions, detailed in Algorithm 2:

Step 1: Subscription Initiation. When a new viewer v subscribes mid-match, the smart contract dynamically adds addrv to the authorized group and updates the accumulator to A′ to reflect this addition. As defined in Layer 2, the current temporal salt ηρi remains unchanged, since salt rotation is strictly triggered by revocations (detailed below).

Step 2: Token Delivery. When the CP detects the on-chain update, it extracts the current Layer 2 temporal state sj alongside generating the initial Layer 3 witness Wv. The CP encrypts this minimal state tuple using the viewer’s public key as Tokenv=AsymEnc(pkv,{Wv,sj}), and submits it to the contract to emit compactly via an event log.

Step 3: Derivation and Decryption. Viewer v retrieves and decrypts Tokenv to obtain {Wv,sj}. With sj acquired, the viewer immediately begins playback. As the CP continuously broadcasts the encrypted chunks and key-ciphertexts Cj+1∗=SymEnc(sj+1,kj+1) generated in layer 2, the viewer autonomously rolls their local hash chain sj+1=H(sj∥0) to unwrap the underlying video keys. The witness Wv is securely stored locally, remaining dormant until the next revocation triggers a salt rotation.

Revocation: When a user w is revoked (e.g., subscription expiration) at the subsequent block height ρi+1, the CP triggers a strict state transition to sever access. (a)

The CP updates the accumulator to Aρi+1, permanently excluding user w.

Excluded from Aρi+1, the revoked user w cannot obtain a valid witness to decrypt C^ρi+1. Consequently, their local hash chain stalls, explicitly preventing them from deriving any subsequent temporal states. Meanwhile, remaining legitimate viewers autonomously update their witness to Wv,ρi+1 locally using public blockchain records, decrypt the new salt ηρi+1, and continuously derive subsequent video keys.

We model the adversary 𝒜 as a Probabilistic Polynomial-Time (PPT) entity. The adversary can observe all on-chain transactions and event logs, control the honest-but-curious storage infrastructure, obtain all public ciphertexts {Ci,Ci∗}, and adaptively issue subscription, cancellation, resubscription, and highlight-purchase queries through corrupted blockchain addresses. The adversary may also pool all credentials legitimately obtained by corrupted identities, including historical BHT tokens, stale temporal states, and stale IBBE witnesses. However, 𝒜 cannot compromise the CP’s signing key, VRF secret key, or IBBE master secret, cannot violate the finality and correct execution of the underlying blockchain, and cannot force an honest active subscriber to redistribute freshly decrypted salts, keys, or plaintext outside the protocol.

Definition 1 (Forward Secrecy): We define forward secrecy via a challenge-response game GFS between a challenger 𝒞 and a PPT adversary 𝒜. Let tc be the time of a cancellation query made by 𝒜. 𝒜 wins if it can distinguish the temporal state st (where t>tc) from a truly random string with a non-negligible advantage. The proposed architecture guarantees forward secrecy if, for all PPT adversaries, the advantage in GFS is negligible.

Definition 2 (Backward Secrecy): Symmetrically, we define backward secrecy via a game GBS. Let ts be the time of a subscription query. 𝒜 wins if it can distinguish any historical temporal state st (where t<ts) from a random string with a non-negligible advantage.

Definition 3 (SCR Security under Collusion): We formalize Subscribe-Cancel-Resubscribe (SCR) security under a collusion model. Let 𝒜 adaptively issue a cancellation query at t1 and a subsequent resubscription query at t2 (t1<t2). By pooling the stale credentials from t1 and the fresh credentials from t2, 𝒜 attempts to derive the symmetric key kt for any chunk within the unauthorized gap t∈[t1,t2−1]. The architecture achieves SCR security if 𝒜’s advantage in deriving st remains negligible despite the pooled knowledge.

Theorem 1 (Forward Secrecy): The proposed architecture ensures forward secrecy such that a revoked adversary 𝒜 at chunk tc cannot derive any subsequent temporal state st for t>tc.

Proof of Theorem 1: Suppose 𝒜 wins GFS by deriving stc+1. According to the protocol, stc+1=H(stc∥ηρ). While 𝒜 may possess the stale state stc, computing stc+1 strictly requires the fresh salt ηρ, which is encapsulated within the broadcast ciphertext C^ρ using the dynamic IBBE scheme. Since 𝒜’s witness Wu is mathematically excluded from the updated IBBE accumulator Aρ upon revocation, deriving ηρ is equivalent to breaking the underlying IBBE scheme’s indistinguishability under chosen-plaintext attack. Furthermore, the pseudo-randomness of the VRF ensures ηρ cannot be predicted without the secret key skCP. Thus, 𝒜’s advantage is negligible. □

Theorem 2 (Backward Secrecy): The proposed architecture ensures backward secrecy such that a newly joined adversary 𝒜 at chunk ts cannot derive any historical temporal state st for t<ts.

Proof of Theorem 2: Let 𝒜 possess the current temporal state sts upon subscription. To win GBS, 𝒜 must derive sts−1 from the known sts=H(sts−1∥ηts). This requires inverting the cryptographic hash function H. Under the assumption that H exhibits pre-image resistance, finding sts−1 is computationally infeasible for any PPT adversary. By induction, all historical states {s0,…,sts−1} remain hidden. Thus, 𝒜’s advantage is negligible. □

Theorem 3 (SCR Attack Resistance and Collusion Resilience): The architecture is resilient against SCR attacks and collusion among multiple corrupted identities, ensuring that pooled credentials yield no advantage in unauthorized intervals.

Proof of Theorem 3: Consider an extreme collusion scenario (satisfying Definition 3) where 𝒜 pools credentials from a revoked session at t1 and a new session at t2 (t1<t2). Let the pooled knowledge be Kcollusion=Kt1∪Kt2. To derive any key kt for the unauthorized gap t∈[t1,t2−1], 𝒜 must either roll st1 forward or st2 backward. As demonstrated in Theorem 1, the forward derivation is blocked by the exclusion from the IBBE-protected salt update. As demonstrated in Theorem 2, the backward derivation is blocked by the pre-image resistance of the hash chain. Since both the forward and backward cryptographic paths are severed at the authorization boundaries, combining the knowledge Kt1 and Kt2 provides no algebraic path to st. Thus, the architecture is secure against both SCR and collusion attacks. □

Remark 1 (Out-of-Band Key Sharing and Piracy): While our architecture rigorously prevents cryptographic collusion (i.e., attackers attempting to derive unauthorized keys by pooling stale and fresh credentials, as formally proven in Theorem 3), it does not prevent a legitimate, active subscriber from voluntarily redistributing their correctly decrypted keys or plaintext video payload to unauthorized users. Such out-of-band key sharing is fundamentally beyond the scope of cryptographic access control models. In commercial digital rights management deployments, mitigating this specific piracy vector requires integrating complementary orthogonal technologies, such as digital watermarking or traitor tracing schemes, which can be seamlessly applied to the Layer 1 static payloads without altering our proposed three-layer authorization protocol.

By decoupling the static video payload from dynamic access rights, our architecture achieves highly scalable performance strictly bounded by constants or logarithmic functions.

Communication Overhead. For continuous live subscriptions, the Layer 3 dynamic IBBE ensures that the broadcast ciphertext C^ρi+1 size remains strictly constant at O(1), entirely independent of the total subscriber population |𝒰|. For arbitrary-grained highlight authorization, the encrypted token uniquely encapsulates the minimum node cover 𝒩a,b. Due to the structural properties of the Layer 1 BHT, the token size is rigorously bounded by O(log⁡|I|), where M is the requested chunk span. These properties make on-chain event emissions exceptionally economical and scalable.

Computational Efficiency (Content Provider). During steady-state streaming, the CP’s workload is minimal, requiring only one symmetric encryption and one hash evaluation O(1) per video chunk. For the most intensive administrative operation (e.g., dynamic revocation), the CP only computes the accumulator state transition and generates a single O(1) IBBE ciphertext C^ρi+1.

Computational Efficiency (Subscriber). Authorized viewers execute real-time playback on local devices with negligible overhead. Unwrapping a temporal chunk requires precisely one O(1) hash derivation and one symmetric decryption. Crucially, during membership transitions, remaining legitimate viewers locally execute the witness update. The complexity of the stateless witness update algorithm is mathematically bounded by O(min(|Δℛ|,|𝒰active|)), where 𝒰active denotes the set of remaining legitimate viewers. For standard sparse revocations, the overhead scales incrementally with O(|Δℛ|). However, during massive revocation events where the revoked population exceeds a specific threshold, the algorithm efficiently reconstructs the witness based on the shrinking active population, causing the computational overhead to decrease. This guarantees that end-users can seamlessly maintain temporal hash progression under any extreme membership volatility, even on resource-constrained mobile devices.

To evaluate the communication overhead for historical video highlights, we simulate a stream of K=4096 chunks using Secure Hash Algorithm 256-bit (SHA-256) (32-Byte keys). We configure SegSub with a segment length of l=16 and account for Droplet’s 33-Byte privacy-preserving ephemeral key overhead. Fig. 3 evaluates the communication cost across varying highlight lengths from 10 to 1000 chunks under two conditions: Relaxed Granularity and Exact-Chunk Granularity.

Boundary Alignment and Privacy Overhead. As shown in Fig. 3, both Our Scheme and Droplet exhibit jagged curves. This is because the communication cost in BHT-based designs depends on how well the requested intervals align with the tree structure. Although both schemes achieve an O(log⁡|I|) bound, Droplet has a consistently higher cost due to its 33-Byte “privacy tax” for identity-unlinkability. Our Scheme removes this extra payload because such extreme anonymization is not required for sports streaming. As a result, Our Scheme achieves the most efficient overhead for exact-chunk authorization.

Impact of Access Precision. As shown in Fig. 3a, SegSub seems competitive under relaxed granularity because it delivers keys at the segment level. However, this approach is limited because it often includes extra, unrequested chunks within those segments to simplify key delivery. This means the provider either risks data leakage by sending more than requested or faces higher costs to be precise. When we enforce Exact-Chunk Granularity to prevent such leakage (Fig. 3b), SegSub’s performance drops significantly. This happens because SegSub send many individual 32-Byte keys for any chunks that fall outside its segment boundaries. In contrast, Our Scheme supports precise access for any interval from the start, which keeps the communication cost low while strictly following the principle of least privilege.

To evaluate scalability under high churn, we examine the server communication overhead during batch revocation events. Fig. 4 plots the server communication cost (in kilobytes) relative to the number of revoked users (R), assuming a total audience of N=100,000.

Droplet relies on a unicast mechanism to distribute updated keys to all remaining valid users, causing its communication cost to scale linearly with N−R. As shown in Fig. 4, its overhead starts extremely high and decreases only when the majority of the user base is revoked. SegSub attempts to optimize this by grouping users (e.g., M=100 per group). For very small R, it successfully reduces communication by broadcasting to unaffected groups. However, as R increases, the probability of a group containing at least one revoked user rapidly approaches 1. Once a group is “tainted” by a revoked user, its shared group key becomes invalid, forcing SegSub to fall back to unicasting new keys to the remaining valid users in that specific group. Consequently, when R grows (e.g., R≥1000), SegSub’s grouping mechanism collapses, and its overhead surges to match Droplet’s linear cost.

In contrast, Our Scheme eliminates the need for user-specific key distribution. By leveraging IBBE and on-chain state tracking, the server only needs to broadcast a single, constant-size epoch ciphertext. As illustrated by the flat blue line in Fig. 4, the server communication overhead remains strictly O(1) and minimal, providing absolute immunity to revocation storms regardless of the batch size R. However, this O(1) communication efficiency involves an inherent architectural trade-off by shifting the cryptographic burden to the clients. Consequently, Our Scheme incurs a higher client-side computation latency than Droplet and SegSub (Fig. 5), although this localized state-transition overhead is safely absorbed within the 2000 ms decoding deadline of standard chunk buffers (Fig. 6).

To evaluate practical deployment, we anchor our simulation parameters to standard micro-benchmarks. For the server, we model a standard cloud instance (Elliptic Curve Integrated Encryption Scheme: 1.1 ms, SHA-256: 1.2 µs, IBBE broadcast: 10 ms). For the client, we model a typical smartphone (Elliptic Curve Digital Signature Algorithm: 4.4 ms, SHA-256: 45 µs, IBBE resolve: 15 ms).

Server-Side Scalability. During a batch revocation of R=1000 out of N = 100,000 users, Droplet and SegSub require the server to perform nearly 99,000 asymmetric encryptions. This sequential load exceeds 1.5 min, forcing the live stream to stall. In contrast, Our Scheme offloads witness updates to the clients, requiring the server to execute only a single O(1) IBBE encryption. As shown in Fig. 5a, the server latency remains strictly at 10.0 ms, rendering it immune to revocation storms.

Client-Side Latency. To achieve this server scalability, legitimate clients should fetch the on-chain revocation list and locally compute the O(Rlog2⁡(N/R)) witness update. Fig. 5b shows that this computation takes approximately 314 ms for R=1000. While higher than the baselines’ 5 ms, this 314 ms latency safely consumes less than 16% of the standard 2000 ms decoding buffer margin typical of chunk-based streaming protocols.

Theoretical Boundary and Practical Limitations. Since the client latency is dominated by local hashing, we evaluate its non-linear scaling to identify hardware limits. The computational complexity reaches its theoretical maximum at R=N/e (≈36,787 evictions for N=100,000), resulting in a latency of 2403 ms. While this marginally exceeds the 2000 ms buffer limit (Fig. 6), it is practically mitigated by two factors. First, the probability of an instantaneous 36% churn rate within a 2-s epoch is negligible; real-world churn is distributed over time, keeping R safely below this boundary. Second, this peak represents a transient, one-time state synchronization cost. Once updated, the latency for subsequent chunks instantly reverts to the nominal baseline, resulting in at most a sub-second stutter isolated to a single chunk. By trading a transient local delay for the absolute eradication of O(N) server-side bottlenecks, the system achieves genuine scalability.

Since the IBBE decryption overhead is constant (15 ms), the client latency is entirely dominated by the local batch witness update, which scales mathematically at O(Rlog2⁡(N/R)). Fig. 6 tracks this non-linear scaling behavior.

Remark 2 (Mitigating Blockchain Latency): Our system is immune to blockchain latency during steady-state operations, as subscribers autonomously roll the hash chain off-chain (η=0). Latency is only introduced during revocation events, which require waiting for block confirmations to retrieve a fresh salt η. For seamless playback, this latency can be mitigated via: (1) Scheduled Revocation: The new salt’s activation is scheduled for a future chunk, absorbing confirmation delays with negligible economic impact (e.g., granting revoked users brief extra access); and (2) Pre-Confirmation Propagation: The CP immediately distributes the updated ciphertext C^ via the peer-to-peer network, allowing subscribers to verify the signature and retrieve η without waiting for strict on-chain finality.

Remark 3 (Client-Side Revocation Overhead): The primary client-side computational bottleneck stems from the IBBE witness updates triggered by membership revocations. As illustrated in Figs. 5 and 6, this overhead is manageable under typical churn rates. For constrained clients (e.g., low-power devices), this computation can be practically absorbed without playback stuttering by expanding the playback buffer (e.g., from 2 s to 4 s) or dynamically adjusting the video frame rate. Furthermore, to address increased natural churn at a massive system scale, our future research will explore reputation-based tiered grouping. By isolating volatile users, this approach minimizes the revocation scale within stable clusters, fundamentally reducing the witness update burden for the majority of clients.