cerc-io
/
stack-orchestrator
mirror of https://github.com/cerc-io/stack-orchestrator
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity
stack-orchestrator/docs/doublezero-multicast-access.md

6.0 KiB
Raw Blame History

DoubleZero Multicast Access Requests

Status (2026-03-06)

DZ multicast is still in testnet (client v0.2.2). Multicast groups are defined on the DZ ledger with on-chain access control (publishers/subscribers). The testnet allocates addresses from 233.84.178.0/24 (AS21682). Not yet available for production Solana shred delivery.

Biscayne Connection Details

Provide these details when requesting subscriber access:

Field Value
Client IP 186.233.184.235
Validator identity 4WeLUxfQghbhsLEuwaAzjZiHg2VBw87vqHc4iZrGvKPr
DZ identity 3Bw6v7EruQvTwoY79h2QjQCs2KBQFzSneBdYUbcXK1Tr
DZ device laconic-mia-sw01
Contributor / tenant laconic

Jito ShredStream

Not a DZ multicast group. ShredStream is Jito's own shred delivery service, independent of DoubleZero multicast. It provides low-latency shreds from leaders on the Solana network via a proxy client that connects to the Jito Block Engine.

Property Value
What it does Delivers shreds from Jito-connected leaders with low latency. Provides a redundant shred path for servers in remote locations.
How it works shredstream-proxy authenticates to a Jito Block Engine via keypair, receives shreds, forwards them to configured UDP destinations (e.g. validator TVU port).
Cost Unknown. Docs don't list pricing. Was previously "complimentary" for searchers (2024). May require approval.
Requirements Approved Solana pubkey (form submission), auth keypair, firewall open on UDP 20000, TVU port of your node.
Regions Amsterdam, Dublin, Frankfurt, London, New York, Salt Lake City, Singapore, Tokyo. Max 2 regions selectable.
Limitations No NAT support. Bridge networking incompatible with multicast mode.
Repo https://github.com/jito-labs/shredstream-proxy
Docs https://docs.jito.wtf/lowlatencytxnfeed/
Status for biscayne Not yet requested. Need to submit pubkey for approval.

ShredStream is relevant to our shred completeness problem — it provides an additional shred source beyond turbine and the Ashburn relay. It would run as a sidecar process forwarding shreds to the validator's TVU port.

DZ Multicast Groups

DZ multicast uses PIM (Protocol Independent Multicast) and MSDP (Multicast Source Discovery Protocol). Group owners define allowed publishers and subscribers on the DZ ledger. Switch ASICs handle packet replication — no CPU overhead.

bebop

Listed in earlier notes as a multicast shred distribution group. No public documentation found. Cannot confirm this exists as a DZ multicast group.

  • Owner: Unknown
  • Status: Unverified — may not exist as described

turbine (future)

Solana's native shred propagation via DZ multicast. Jito has expressed interest in leveraging multicast for shred delivery. Not yet available for production use.

  • Owner: Solana Foundation / Anza (native turbine), Jito (shredstream)
  • Status: Testnet only (DZ client v0.2.2)

bloXroute OFR (Optimized Feed Relay)

Commercial shred delivery service. Runs a gateway docker container on your node that connects to bloXroute's BDN (Blockchain Distribution Network) to receive shreds faster than default turbine (~30-50ms improvement, beats turbine ~98% of the time).

Property Value
What it does Delivers shreds via bloXroute's BDN with optimized relay topologies. Not just a different turbine path — uses their own distribution network.
How it works Docker gateway container on your node, communicates with bloXroute OFR relay over UDP 18888. Forwards shreds to your validator.
Cost $300/mo (Professional, 1500 tx/day), $1,250/mo (Enterprise, unlimited tx). OFR gateway without local node requires Enterprise Elite ($5,000+/mo).
Requirements Docker, UDP port 18888 open, bloXroute subscription.
Open source Gateway at https://github.com/bloXroute-Labs/solana-gateway
Docs https://docs.bloxroute.com/solana/optimized-feed-relay
Status for biscayne Not yet evaluated. Monthly cost may not be justified.

bloXroute's value proposition: they operate nodes at multiple turbine tree positions across their network, aggregate shreds, and redistribute via their BDN. This is the "multiple identities collecting different shreds" approach — but operated by bloXroute, not by us.

How These Services Get More Shreds

Turbine tree position is determined by validator identity (pubkey). A single validator gets shreds from one position in the tree per slot. Services like Jito ShredStream and bloXroute OFR operate many nodes with different identities across the turbine tree, aggregate the shreds they each receive, and redistribute the combined set to subscribers. This is why they can deliver shreds the subscriber's own turbine position would never see.

An open-source equivalent would require running multiple lightweight validator identities (non-voting, minimal stake) at different locations, each collecting shreds from their unique turbine tree position, and forwarding them to the main validator. No known open-source project implements this pattern.

Sources

Request Template

When contacting a group owner, use something like:

We'd like to subscribe to your DoubleZero multicast group for our Solana validator. Our details:

  • Validator: 4WeLUxfQghbhsLEuwaAzjZiHg2VBw87vqHc4iZrGvKPr
  • DZ identity: 3Bw6v7EruQvTwoY79h2QjQCs2KBQFzSneBdYUbcXK1Tr
  • Client IP: 186.233.184.235
  • Device: laconic-mia-sw01
  • Tenant: laconic