mboned O. Ramadan Internet-Draft Blockcast Inc Intended status: Informational 2 November 2025 Expires: 6 May 2026 SONAR: Statistical Observation Network for Attestation and Reach draft-ramadan-mboned-sonar-00 Abstract This document specifies SONAR (Statistical Observation Network for Attestation and Reach), a protocol combining three technical constructs to enable verifiable multicast distribution: (1) Physical layer efficiency through native IP multicast transmission achieving O(1) network bandwidth regardless of receiver population, (2) Cryptoeconomic receiver accountability via on-chain stake deposits, Verifiable Random Functions (VRF) for unpredictable sampling, and blockchain-recorded attestation reporting, and (3) Multicast source authentication through ALTA-based asymmetric loss-tolerant packet verification enabling real-time content integrity proofs. SONAR achieves constant 6% bandwidth overhead through separation of content authentication (broadcast to all receivers) from coverage verification (statistical sampling with German Tank Problem estimation). The protocol employs zero-knowledge proof aggregation via zkSNARKs for sample sizes exceeding 1,000 users, providing privacy protection (preventing on-chain correlation attacks), cost efficiency (80-90% reduction), and maintaining O(1) on-chain verification cost while scaling to populations exceeding 10^8 receivers. SONAR enables cryptographically verifiable multicast distribution without trusted intermediaries or per-receiver encryption overhead. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Ramadan Expires 6 May 2026 [Page 1] Internet-Draft SONAR November 2025 This Internet-Draft will expire on 6 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 3.2. Protocol Layers . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Layer 1: Content Authentication . . . . . . . . . . . 5 3.2.2. Layer 2: Statistical Coverage Verification . . . . . 5 3.2.3. Layer 3: Zero-Knowledge Aggregation (Recommended for m > 1,000) . . . . . . . . . . . . . . . . . . . . . . 6 4. Content Authentication . . . . . . . . . . . . . . . . . . . 6 4.1. ALTA Protocol Configuration . . . . . . . . . . . . . . . 6 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Verification Procedure . . . . . . . . . . . . . . . . . 8 5. Statistical Coverage Verification . . . . . . . . . . . . . . 8 5.1. Sample Selection Protocol . . . . . . . . . . . . . . . . 8 5.1.1. VRF-Based Random Selection . . . . . . . . . . . . . 9 5.1.2. Challenge Message Format . . . . . . . . . . . . . . 9 5.2. User Attestation Protocol . . . . . . . . . . . . . . . . 11 5.2.1. Attestation Message Format . . . . . . . . . . . . . 11 5.2.2. Submission Methods . . . . . . . . . . . . . . . . . 12 5.3. Coverage Estimation . . . . . . . . . . . . . . . . . . . 13 5.3.1. German Tank Problem Estimator . . . . . . . . . . . . 13 5.3.2. Confidence Intervals . . . . . . . . . . . . . . . . 13 6. Zero-Knowledge Proof Aggregation . . . . . . . . . . . . . . 14 6.1. Merkle Tree Construction . . . . . . . . . . . . . . . . 14 6.2. zkSNARK Proof Generation . . . . . . . . . . . . . . . . 15 6.3. On-Chain Verification . . . . . . . . . . . . . . . . . . 15 6.4. Challenge Protocol . . . . . . . . . . . . . . . . . . . 15 7. Test Period Optimization . . . . . . . . . . . . . . . . . . 16 Ramadan Expires 6 May 2026 [Page 2] Internet-Draft SONAR November 2025 7.1. Unicast Replication Detection . . . . . . . . . . . . . . 16 7.2. Recommended Test Periods . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Economic Security . . . . . . . . . . . . . . . . . . . . 18 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Example Deployment . . . . . . . . . . . . . . . . . 20 A.1. NYC Television Station Scenario . . . . . . . . . . . . . 20 A.1.1. Network Configuration . . . . . . . . . . . . . . . . 20 A.1.2. SONAR Configuration . . . . . . . . . . . . . . . . . 21 A.1.3. Cost-Benefit Analysis . . . . . . . . . . . . . . . . 21 A.1.4. Performance Metrics . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Multicast distribution offers significant efficiency advantages over unicast for large-scale content delivery, reducing bandwidth costs by 99.99% or more. However, the lack of verifiable delivery mechanisms prevents widespread commercial adoption. Content providers cannot verify that infrastructure operators actually delivered content to claimed receivers, while infrastructure operators cannot prove delivery to enable billing. This bilateral trust deficit blocks the formation of liquid markets for multicast capacity. Existing multicast authentication schemes ([RFC4082], [I-D.ietf-mboned-ambi], [I-D.krose-mboned-alta]) address content authentication but do not provide per-receiver coverage proof. Per- receiver encryption defeats multicast efficiency by requiring O(N) bandwidth where N is the number of receivers. SONAR solves this problem through statistical sampling: rather than proving delivery to every receiver, SONAR proves delivery to a random sample with known statistical confidence. This enables verification of populations exceeding 10^7 receivers with constant bandwidth overhead. Ramadan Expires 6 May 2026 [Page 3] Internet-Draft SONAR November 2025 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology This document uses the following terms: Coverage Group: A set of receivers that can be addressed with a single multicast transmission, typically defined by geographic location or network topology. Attestation: A cryptographically signed statement by a receiver asserting successful reception of specific content with packet statistics. Sample Size: The number of receivers randomly selected to provide attestations in a given test window. Denoted as m. Population Size: The total number of receivers in the coverage group. Denoted as N. German Tank Estimate: A statistical estimator for population size based on maximum observation in a sampled sequence. Test Window: A time period during which packet reception is tracked for coverage verification. Duration denoted as P. zkSNARK: Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. A cryptographic proof system enabling verification of aggregate statements with constant-size proofs. 3. Architecture Overview 3.1. Design Principles SONAR is designed around the following principles: * Content authentication is independent of coverage verification * Statistical sampling provides O(1) verification cost regardless of population size Ramadan Expires 6 May 2026 [Page 4] Internet-Draft SONAR November 2025 * Broadcast bandwidth overhead MUST be <10% to preserve multicast efficiency * Return path (user attestations) uses existing internet infrastructure * Cryptographic security complemented by economic incentives 3.2. Protocol Layers 3.2.1. Layer 1: Content Authentication All receivers verify content authenticity using ALTA protocol [I-D.krose-mboned-alta]. This provides: * Non-repudiation: Content provider cannot deny transmission * Source authentication: Receivers verify authorized origin * Integrity: Content not modified in transit * Low latency: 1-10ms authentication delay ALTA is chosen over alternatives (TESLA, AMBI) because: * No time synchronization required (vs TESLA) * Real-time authentication (vs TESLA 100-6000ms delay) * Broadcast-only (vs AMBI unicast manifests) * Strong non-repudiation (periodic Ed25519 signatures) Bandwidth overhead: Approximately 6% for typical configurations. 3.2.2. Layer 2: Statistical Coverage Verification Random sample of m receivers (typically 0.1% of population) provide attestations via internet return path. Statistical inference provides population coverage estimate with confidence interval. Sample selection uses Verifiable Random Function (VRF) to prevent adversarial selection. Attestations include packet statistics enabling loss rate estimation and fraud detection. Broadcast overhead: Only sample selection message (320 KB per test). Ramadan Expires 6 May 2026 [Page 5] Internet-Draft SONAR November 2025 Return path overhead: Distributed across m users (128 bps per selected user). 3.2.3. Layer 3: Zero-Knowledge Aggregation (Recommended for m > 1,000) zkSNARK proofs SHOULD be employed when sample size m exceeds 1,000 users, primarily for privacy protection. For small communities (N < 100,000), individual viewing patterns become correlatable on-chain, enabling de-anonymization attacks. zkSNARKs provide aggregated proof of coverage statistics while hiding individual user attestations. Additional benefits: 80-90% cost reduction via off-chain storage, constant-size verification (328 bytes regardless of m), and scalability to populations exceeding 10^8. Challenge protocol enables spot-checking of individual attestations via Merkle proof while maintaining aggregate privacy. 4. Content Authentication 4.1. ALTA Protocol Configuration SONAR employs ALTA with the following parameters: Scheme Parameters: * a = 3 (backward reference interval) * p = 5 (redundancy factor) * K = 50 (signature interval) Algorithms: * MAC: HMAC-SHA256 truncated to 128 bits * Signature: Ed25519 (64 bytes) 4.2. Packet Format Each multicast packet MUST include ALTA authentication data: Ramadan Expires 6 May 2026 [Page 6] Internet-Draft SONAR November 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | MAC Count | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Previous Packet Hash (256 bits) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + MAC 1 (128 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + MAC 2 (128 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... (additional MACs) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Ed25519 Signature (512 bits) | + (present if S=1, every Kth packet) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Content Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: Monotonically increasing packet identifier S (Signature Present): 1-bit flag indicating Ed25519 signature included Reserved: 7 bits reserved for future use, MUST be zero MAC Count: Number of MACs included (typically 3-5) Previous Packet Hash: SHA-256 hash of previous packet for chain verification Ramadan Expires 6 May 2026 [Page 7] Internet-Draft SONAR November 2025 MAC n: HMAC-SHA256 of packet at offset (i - n*a) truncated to 128 bits Ed25519 Signature: Signature of packets i through i-K+1 (when S=1, every Kth packet) Content Payload: Application data Total overhead calculation: * Base: 4 + 32 = 36 bytes * MACs: 16 * MAC_Count bytes * Signature (amortized): 64 / K bytes * For MAC_Count=4, K=50: 36 + 64 + 1.28 = 101.28 bytes * Percentage for 1500-byte packets: 6.75% 4.3. Verification Procedure Upon receiving packet i, receiver performs the following steps: 1. Verify sequence number is monotonically increasing 2. Compute SHA-256(packet_{i-1}) and compare with Previous Packet Hash field 3. For each MAC_j in packet, retrieve stored packet at offset (i - j*a) 4. Recompute HMAC-SHA256 for each referenced packet and compare 5. If S=1, verify Ed25519 signature over packets [i-K+1, i] 6. If all verifications pass, accept packet as authentic Receiver MUST buffer packets until sufficient MACs received for verification (depth = p packets). 5. Statistical Coverage Verification 5.1. Sample Selection Protocol Ramadan Expires 6 May 2026 [Page 8] Internet-Draft SONAR November 2025 5.1.1. VRF-Based Random Selection Content provider generates verifiable random sample using VRF to prevent adversarial selection: 1. Obtain blockchain randomness source (e.g., block hash at height H) 2. Apply VRF with content provider private key: seed = VRF_prove(sk, blockhash || session_id) 3. Use seed for Fisher-Yates shuffle of registered user public keys 4. Select first m users from shuffled list VRF properties ensure: * Unpredictability: Adversary cannot predict selection before blockhash revealed * Verifiability: Anyone can verify selection was computed correctly * Uniqueness: Only one valid output for given input 5.1.2. Challenge Message Format Ramadan Expires 6 May 2026 [Page 9] Internet-Draft SONAR November 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type = 0x01 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Window Start (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Window End (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Selected Users (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + VRF Proof (80 bytes) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Selected User Public Keys (32 bytes each, m total) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Ed25519 Signature (512 bits) | + (signs entire message) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Size calculation for m=10,000 users: * Header: 24 bytes * VRF Proof: 80 bytes * User pubkeys: 32 * 10,000 = 320,000 bytes * Signature: 64 bytes * Total: 320,168 bytes ≈ 320 KB Broadcast frequency: Once per test period P (recommended: P = 900-7200 seconds) Bandwidth: 320 KB / P seconds * P = 900s (15 min): 356 bytes/s = 2.8 Kbps Ramadan Expires 6 May 2026 [Page 10] Internet-Draft SONAR November 2025 * P = 3600s (1 hour): 89 bytes/s = 0.7 Kbps 5.2. User Attestation Protocol 5.2.1. Attestation Message Format Selected users MUST respond within response window T_response (recommended: 60 seconds): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type = 0x02 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + User Public Key (256 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Min Observed (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Max Observed (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packets Received (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Sample Content Hash (256 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response Timesonar (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Ed25519 Signature (512 bits) | + (signs entire message) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Min/Max Observed: First and last sequence numbers received in test window Packets Received: Total count of packets successfully received and authenticated Sample Content Hash: SHA-256 hash of concatenated payload from Ramadan Expires 6 May 2026 [Page 11] Internet-Draft SONAR November 2025 sampled packets (e.g., every 100th packet) to prove actual content reception Response Timesonar: Unix timesonar when attestation created Total size: 160 bytes per attestation 5.2.2. Submission Methods 5.2.2.1. Direct Blockchain Submission Each selected user submits attestation as blockchain transaction: * Attestation payload: 160 bytes * Transaction overhead: ~40 bytes * Total: ~200 bytes per user * For m=10,000: 2 MB per test * Cost at $0.0001/tx: $1.00 per test Advantages: Simple, immediate verification Disadvantages: High on-chain cost for large m 5.2.2.2. Aggregated Submission via zkSNARK Users submit to off-chain storage (e.g., Nitro Data Anchor), then aggregator creates zkSNARK proof: 1. Users submit 160-byte attestations to off-chain storage 2. Aggregator collects m attestations 3. Aggregator builds Merkle tree with root R 4. Aggregator computes aggregate statistics 5. Aggregator generates zkSNARK proof π 6. Aggregator submits {R, statistics, π} on-chain On-chain size: 328 bytes (constant regardless of m) Cost reduction: 99.998% vs direct submission for m=10,000 Ramadan Expires 6 May 2026 [Page 12] Internet-Draft SONAR November 2025 5.3. Coverage Estimation 5.3.1. German Tank Problem Estimator Given sender transmitted N packets and user j reports packet_max_j, population size estimate: N_hat = max(packet_max_1, ..., packet_max_m) + max(...) / m - 1 Loss rate estimate for user j: span_j = packet_max_j - packet_min_j + 1 loss_j = 1 - (packets_received_j / span_j) Aggregate loss rate: loss_avg = (1/m) * sum(loss_j for j in sample) If packet_max_j ≈ N, user kept pace with real-time stream (multicast reception). If packet_max_j << N, user lagged significantly (potential unicast forwarding). 5.3.2. Confidence Intervals For sample size m from population N, coverage estimate has confidence interval: Standard error: SE = sqrt(p_hat * (1 - p_hat) / m) 95% confidence: CI_95 = p_hat ± 1.96 * SE Population coverage: Coverage = N * p_hat Coverage_CI = N * (p_hat ± 1.96 * SE) Example: N = 10,000,000 users, m = 10,000 sample, p_hat = 0.95: SE = sqrt(0.95 * 0.05 / 10000) = 0.00218 CI_95 = 0.95 ± 0.00427 = [0.946, 0.954] Coverage = 9,500,000 ± 42,700 users Minimum sample size for desired margin of error E: m_min = (1.96^2 * p_hat * (1 - p_hat)) / E^2 For E = 0.001 (0.1% margin) with p_hat = 0.95: m_min = (3.84 * 0.95 * 0.05) / 0.000001 = 18,240 samples Ramadan Expires 6 May 2026 [Page 13] Internet-Draft SONAR November 2025 6. Zero-Knowledge Proof Aggregation Zero-knowledge proof aggregation via zkSNARKs SHOULD be employed when sample size m exceeds 1,000 users. This threshold is determined by three factors: 1. Privacy Protection: Individual attestations become correlatable on-chain, enabling de-anonymization attacks. For small communities (N < 100,000), users are more easily identifiable, making privacy protection critical. 2. Cost Efficiency: Off-chain storage via Nitro Data Anchor costs $0.00001 per attestation versus $0.0001 for direct on-chain submission. For m=1,000, this represents 80-90% cost reduction: $0.02 (zkSNARK aggregated) versus $0.10 (direct). 3. Constant Verification: zkSNARK proofs maintain 200-byte size and O(1) verification cost regardless of m, enabling scalability to populations exceeding 10^8. Implementation via Nitro Termina Technology: * User attestations stored in Nitro Data Anchor (off-chain) * zkSNARK proof generated in Nitro Trusted Execution Environment (TEE) * Proof verified on-chain via smart contract * Challenge protocol enables spot-checking via Merkle proofs 6.1. Merkle Tree Construction Aggregator constructs binary Merkle tree from attestations: 1. Collect m attestations: A_1, A_2, ..., A_m 2. Compute leaf hashes: L_j = SHA256(A_j) 3. Build tree bottom-up: H_parent = SHA256(H_left || H_right) 4. Compute root: R Merkle proof for attestation A_j: * Path: Sibling hashes from leaf to root * Length: ceil(log2(m)) hashes Ramadan Expires 6 May 2026 [Page 14] Internet-Draft SONAR November 2025 * For m=10,000: 14 hashes * 32 bytes = 448 bytes 6.2. zkSNARK Proof Generation Aggregator generates proof π for statement S: Statement S: "I know m attestations {A_1, ..., A_m} such that: 1. MerkleRoot({SHA256(A_j)}) = R 2. Each A_j contains valid Ed25519 signature 3. Aggregate loss rate < threshold (e.g., 0.05) 4. Median(packet_max) > threshold (e.g., 0.95 * N)" Public inputs: {R, m, aggregate_stats, thresholds} Witness: {A_1, ..., A_m, Merkle_paths, signatures} Proof size: Approximately 200 bytes (constant regardless of m) 6.3. On-Chain Verification Smart contract verifies zkSNARK proof: 1. Extract public inputs: {R, m, statistics, π} 2. Verify proof: valid = Verify(vk, public_inputs, π) 3. If valid: Accept coverage claim for m users 4. If invalid: Reject and slash aggregator stake Verification cost: ~100,000 gas (constant regardless of m) 6.4. Challenge Protocol Any party may challenge aggregator by requesting Merkle proof for specific user: 1. Challenger submits challenge: "Prove user_j is in tree R" 2. Aggregator MUST respond within T_challenge (recommended: 24 hours) 3. Aggregator provides: {A_j, merkle_path} 4. Challenger verifies: MerkleVerify(A_j, path, R) and signature validity Ramadan Expires 6 May 2026 [Page 15] Internet-Draft SONAR November 2025 5. If verification fails: Aggregator stake slashed, challenger rewarded 6. If verification succeeds: Challenge bond returned to challenger 7. Test Period Optimization 7.1. Unicast Replication Detection A malicious relay might receive content via unicast forwarding and claim multicast reception. Detection relies on bandwidth constraints: For unicast replication to B recipients: Required bandwidth: B * R_content If B * R_content > R_relay, relay must lag Lag accumulates at rate: (B * R_content - R_relay) Minimum test period for detection: P_min = L / (alpha - 1) where alpha = (B * R_content) / R_relay L = acceptable loss rate Example: B=1M recipients, R_content=25 Mbps, R_relay=10 Gbps, L=0.05: alpha = (1,000,000 * 25) / 10,000 = 2,500 P_min = 0.05 / (2,500 - 1) ≈ 0.00002 seconds Conclusion: For typical broadcast scenarios, any test period P > 1 second provides overwhelming detection certainty. Optimal P is determined by cost-benefit tradeoff, not detection requirements. 7.2. Recommended Test Periods Test period selection based on use case: Ramadan Expires 6 May 2026 [Page 16] Internet-Draft SONAR November 2025 +===========+===============+============+============+===========+ | Use Case | Test Period P | Tests/Hour | Cost/Hour* | Detection | | | | | | Latency | +===========+===============+============+============+===========+ | Live | 300s (5 min) | 12 | $12 | <5 min | | Events | | | | | +-----------+---------------+------------+------------+-----------+ | Prime | 900s (15 min) | 4 | $4 | <15 min | | Time TV | | | | | +-----------+---------------+------------+------------+-----------+ | Off-Peak | 3600s (1 | 1 | $1 | <1 hour | | Content | hour) | | | | +-----------+---------------+------------+------------+-----------+ | ISP SLA | 7200s (2 | 0.5 | $0.50 | <2 hours | | Reporting | hours) | | | | +-----------+---------------+------------+------------+-----------+ Table 1 *Assumes m=10,000 users, $0.0001 per transaction Maximum recommended P: 7200 seconds (2 hours) Rationale: Beyond 2 hours, network state staleness reduces actionable value of coverage data. 8. Security Considerations 8.1. Threat Model SONAR must resist the following adversarial behaviors: Sybil Attacks: Attacker creates multiple fake receiver identities to inflate coverage claims. Mitigated by stake requirements and VRF- based random sampling. Replay Attacks: Adversary captures authenticated content and replays to different receivers. Mitigated by sequence numbers, timesonars, and hash chaining. Man-in-the-Middle: Intermediate node modifies content while maintaining valid authentication. Prevented by ALTA MAC chains and periodic signatures. DoS Attacks: Attacker floods network with fake packets to exhaust receiver buffers. Mitigated by instant ALTA authentication enabling immediate rejection. Ramadan Expires 6 May 2026 [Page 17] Internet-Draft SONAR November 2025 Sample Manipulation: Adversary attempts to influence which users are selected for sampling. Prevented by VRF unpredictability. 8.2. Economic Security Cryptographic security is complemented by economic incentives: * Stake requirements: $10-$100K deposits create accountability * Slashing penalties: Fraudulent attestations result in stake loss * Fraud detection rewards: 5-10x multiplier encourages honest reporting * Rational behavior: Cost of fraud exceeds expected benefit Game-theoretic analysis shows honest participation is Nash equilibrium when fraud detection probability exceeds 0.001% (easily achieved through random spot checks). 8.3. Privacy Considerations SONAR reveals the following information: * Which users are registered for coverage verification (public keys on-chain) * Which users were selected for sampling (challenge message) * Aggregate statistics about selected users (loss rates, packet counts) SONAR does NOT reveal: * Content of multicast stream (encrypted separately if needed) * Individual user consumption patterns (when zkSNARK aggregation used) * Non-selected users' reception status Privacy Attack Vector for Small Communities: Without zkSNARK aggregation, direct on-chain attestations enable correlation attacks. For small communities (N < 100,000), attackers can: * Link public keys to known wallet addresses Ramadan Expires 6 May 2026 [Page 18] Internet-Draft SONAR November 2025 * Correlate viewing timesonars with other on-chain activity * Identify viewing patterns (packet_max reveals full episode viewing) * Cross-reference with geographic or demographic data Privacy decreases inversely with community size. For N=5,000, individual identification probability exceeds 75% through cross- referencing. For N=10,000,000, crowd anonymity provides natural protection. RECOMMENDATION: zkSNARK aggregation MUST be used when sample size m > 1,000, SHOULD be used when m > 100. This protects small community viewers from de-anonymization while maintaining cryptographic coverage proof. 9. IANA Considerations This document requests IANA to create a new registry for SONAR message types: Registry Name: SONAR Message Types Registration Procedure: IETF Review Reference: This document Initial allocations: +=======+==========================+===============+ | Value | Description | Reference | +=======+==========================+===============+ | 0x01 | Sample Challenge | Section 5.1.2 | +-------+--------------------------+---------------+ | 0x02 | User Attestation | Section 5.2.1 | +-------+--------------------------+---------------+ | 0x03 | zkSNARK Aggregated Proof | Section 6.3 | +-------+--------------------------+---------------+ Table 2 10. References 10.1. Normative References Ramadan Expires 6 May 2026 [Page 19] Internet-Draft SONAR November 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.krose-mboned-alta] Rose, K. and J. Holland, "Asymmetric Loss-Tolerant Authentication", July 2019, . 10.2. Informative References [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J. D., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, June 2005, . [I-D.ietf-mboned-ambi] Holland, J., Rose, K., and M. Franke, "Asymmetric Manifest Based Integrity", March 2022, . Appendix A. Example Deployment A.1. NYC Television Station Scenario This appendix provides a concrete deployment example for a New York City television station broadcasting to 10 million concurrent viewers. A.1.1. Network Configuration * Content Provider: NBC New York * Content: Live sports broadcast * Bitrate: 25 Mbps H.265 video * Target Coverage: 10,000,000 concurrent viewers * Geographic Area: NYC metropolitan area Ramadan Expires 6 May 2026 [Page 20] Internet-Draft SONAR November 2025 A.1.2. SONAR Configuration Content Authentication (ALTA): * MAC algorithm: HMAC-SHA256 (128-bit) * Signature: Ed25519 every 50th packet * Overhead: 6.75% (1.69 Mbps) Statistical Sampling: * Sample size: m = 10,000 users (0.1%) * Test period: P = 900 seconds (15 minutes) * Confidence: 95% * Margin of error: ±0.3% Broadcast Overhead: * ALTA: 1.69 Mbps * Challenge message: 320 KB / 900s = 2.8 Kbps * Total: 1.69 Mbps (6.76%) A.1.3. Cost-Benefit Analysis Per-Hour Costs: * User sampling: 10,000 users × 4 tests/hour × $0.0001 = $4.00 * zkSNARK aggregation: 4 tests/hour × $0.0001 = $0.0004 * Total: $4.00 per hour Revenue Impact: * Traditional CPM (unverified): $10 per 1000 impressions * Verified CPM: $15 per 1000 impressions (50% premium) * Traditional revenue: 10M × $10/1000 = $100,000/hour * Verified revenue: 10M × $15/1000 = $150,000/hour Ramadan Expires 6 May 2026 [Page 21] Internet-Draft SONAR November 2025 * Additional revenue: $50,000/hour * Net benefit: $50,000 - $4 = $49,996/hour * ROI: 1,249,900% A.1.4. Performance Metrics * Broadcast bandwidth: 25 Mbps + 1.69 Mbps = 26.69 Mbps * Overhead: 6.76% * Authentication latency: 1-10ms (ALTA) * Detection latency: <15 minutes * Coverage confidence: 95% (9,458,000 - 9,542,000 users) * Blockchain TPS: 0.011 (well below capacity) Acknowledgments The author thanks Jake Holland and Kyle Rose (Akamai) for the ALTA protocol specification and insights on multicast authentication. Thanks to the IETF MBONED working group for feedback on earlier versions of this work. Special thanks to the Blockcast team for real-world deployment experience with decentralized multicast networks. Author's Address Omar Ramadan Blockcast Inc Berkeley, CA United States of America Email: omar@blockcast.network URI: https://blockcast.network Ramadan Expires 6 May 2026 [Page 22]