Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

The Blockcast RELAY

The Blockcast RELAY is the workhorse node of the Blockcast network — a compact, plug-and-play device that combines edge caching with AMT multicast relaying, deployed wherever an operator has spare capacity and an interest in monetizing it.

A RELAY caches popular content close to viewers and extends multicast reach into networks that can't peer directly with a CAST node. The operator running it earns weekly rewards proportional to verified bandwidth, uptime, and content served — settled on-chain through the Proof of Bandwidth system.

What is a Blockcast RELAY, and How is It Different?

Traditional CDN edge servers are commodity reverse-proxies (Varnish, NGINX, ATS) deployed by the CDN itself, paid for as bulk infrastructure, and operated as a closed system. A Blockcast RELAY is the same kind of edge server — but contributed by an independent operator inside their own network, registered to the Blockcast network on-chain, and verified continuously by the protocol:

  • Edge cache: Stores popular content close to viewers so requests don't have to traverse ISP transit to a distant CDN. Same role as a traditional CDN edge.

  • AMT relay: Tunnels multicast streams over unicast on RFC 7450, extending TreeDN multicast coverage to networks that can't peer directly with a CAST source. Linux kernel AMT runs by default; Juniper MX hardware offload is supported for higher tunnel scale.

  • Verified capacity: Bandwidth commitments per network interface are measured by speedtest, attested to on-chain, and re-verified periodically by the Proof of Bandwidth challenge system.

  • Operator-owned: The node belongs to whoever provisions it. Rewards accrue to the operator's wallet, not to a CDN vendor.

This combination lets ISPs, IXes, and independent operators contribute capacity to a shared streaming substrate without giving up control of their infrastructure — and lets content providers reach audiences through a wider, more resilient edge footprint than any single CDN vendor can offer alone.

How is a RELAY Node Provisioned and Managed?

A RELAY is onboarded through the Blockcast portal in six steps, then operated autonomously with portal-side observability. Going live is gated: after onboarding, a node must pass reachability, capacity and attestation, and health and uptime checks before it is promoted, so a misconfigured node can't go live and start charging the network.

Provisioning:

  • Register: The operator installs the Blockcast RELAY runtime, runs blockcastd init to produce a Hardware ID and EC P-384 Challenge Key, and registers the node in the portal. The node starts as a BEACON (attestation-only).

  • Stake to upgrade: Staking tokens on-chain upgrades the node from BEACON to RELAY status, unlocking caching, bandwidth commitments, and full rewards.

  • Allocate storage and RAM: The operator selects which physical disks (or a virtual disk path) hold the cache, and dedicates an in-memory cache tier via a RAM slider.

  • Commit bandwidth: The portal auto-detects network interfaces, runs a per-interface speedtest, and the operator commits a threshold per interface (defaults to 80% of measured). The detected ASN and cache group are pinned to the operator's verified autonomous system.

  • Optional AMT hardware offload: Linux kernel AMT handles hundreds of tunnels per node by default. Operators with Juniper MX routers can offload AMT to dedicated hardware for thousands of tunnels at line rate.

  • Verification gate: Before going live, the portal validates that ports 53 (DNS), 80 (HTTP), 443 (HTTPS/QUIC), and 2268 (AMT) are reachable, and that Traffic Monitor, Traffic Router, the cache process, and the AMT relay all report healthy.

Management:

  • My Nodes dashboard: Live health, uptime, and per-node controls — rename, transfer ownership, or drill into per-interface metrics.

  • Traffic Monitor probes every 10 seconds for liveness and performance; unhealthy nodes are routed around within seconds.

  • Proof of Bandwidth challenges run periodically against the committed thresholds and record verified capacity. Rewards scale with verified — not just claimed — bandwidth.

  • Traffic Router picks RELAYs for each request based on geography, current health, and verified capacity; the routing decision is saturation-aware across the cache group.

  • DRIAD discovery (RFC 8777): Clients performing AMT discovery reach the topologically nearest RELAY automatically — no separate signaling infrastructure to operate.

For the step-by-step onboarding guide with portal screenshots, see Start Running your RELAY. For Juniper MX hardware offload, see Juniper MX AMT Hardware Offload.

RELAY in the TreeDN Architecture (RFC 9706)

The RELAY is the edge tier of the TreeDN tree-based CDN architecture defined in RFC 9706 — fanning multicast streams out to the last-mile while serving cached unicast HTTP to clients that can't or won't speak multicast directly.

The Blockcast TreeDN implementation consists of:

  • CAST nodes as multicast content sources (ROUTE/FLUTE or MoQ-MMT)

  • RELAY nodes as AMT relays and edge caches extending multicast coverage — the role this document describes

  • BEACON nodes as deep-edge receivers on modems, TVs, phones, and browsers

  • DRIAD discovery (RFC 8777) for automatic nearest-relay selection

For a detailed technical walkthrough, see TreeDN: Multicast Content Delivery and AMT Relays & Multicast Backbone.

Last updated