Resilient, encrypted replication of Satellite metadata beyond a single legal entity — is it feasible?

Ideas & Suggestions
1

Upfront: I’m a storage node operator, not a crypto/distributed-systems engineer. I may be raising something already discussed or technically naive — if so, point me to the thread and I’ll happily read up.

Full disclosure on my motivation: I run a node out of conviction more than for the payout — I care about decentralised, censorship-resistant infrastructure surviving its operators. That’s exactly why the metadata single-point-of-failure bothers me.

The recent Chapter 11 situation made me think about where the real single point of failure sits. As an operator I’ve realised that my node only holds encrypted, meaningless pieces. The thing that actually makes those pieces usable — the map of which pieces belong to which object, and where they live — lives in the Satellite metadata. If the entity operating the Satellites were ever to disappear (liquidation, servers shut off), the pieces on our disks would survive but become orphaned and unrecoverable, no matter how committed the operator community is.

So my question is about metadata resilience, not piece resilience.

I understand why metadata can’t simply be “published” to node operators: it would break the zero-knowledge/confidentiality model — it maps pieces to owners and locations, which is exactly the sensitive information the architecture is designed to protect. So please read the below as not proposing to hand metadata to operators in clear.

What I’m asking is whether the metadata could be replicated in an encrypted, distributed, entity-independent way, so it survives the disappearance of any single operator (including Storj Labs itself). A few naive framings, purely to start the discussion:

  • Could Satellite metadata be continuously backed up encrypted onto the Storj network itself (recursively), so no operator can read it but it survives the loss of the Satellite host?
  • Is there any path toward the BFT-consensus metadata layer that was mentioned as a long-term goal back around 2020 (“architect the Satellite out of the platform”)? Is that still on any roadmap, or considered a dead end?
  • Where does the Community Satellite pilot currently stand in practice — is anyone running a public, functioning third-party Satellite today, or is it still design-stage?

I’m aware the v3 whitepaper listed community-run Satellites as its final unfinished task, so I know this isn’t a new concern. But the bankruptcy makes it feel less academic: it seems like now is the moment to make sure metadata can outlive the company, rather than after a hypothetical shutdown.

Is an entity-independent, encrypted metadata replication realistic with the current architecture? If not, what’s the hard blocker — is it the consistency/coordination requirement, the confidentiality boundary, incentives, or something else I’m not seeing?

Thanks for reading a non-engineer’s question. Genuinely trying to understand where the line is between “decentralised on paper” and “survives its operator.”

2

I think this is drifting toward Sia’s design.

The satellite currently owns the metadata and coordination. If that state is distributed between independent parties and they need consensus to update it, teh satellite stops being a conventional distributed service and starts becoming part of the protocol itself.

That is not inherently bad, but it buys survivability at a fairly high cost: much more complexity, more latency, more failure modes, and a much harder system to reason about and operate.

For the specific problem of Storj Labs disappearing, that seems unnecessary. Replicating satellite state to infrastructure controlled by another entity, with the keys and procedures needed to take over, woudl solve the continuity problem much more directly.

Sia chose the decentralized coordination route from the beginning. Storj chose a satellite architecture. Replacing the latter with BFT because of operator continuity seems like a very large architectural change for a problem that can be solved much more simply.

3

Hello @Dodger2054,
Welcome to the forum!

We store metadata backups in Storj buckets, but this is primarily for error correction or data changes if something goes wrong, and their use becomes impossible if a satellite goes down—a chicken-and-egg problem.

Sia doesn’t store full metadata on other nodes; it stores it only on the node used to access its network. Therefore, if that node fails, the metadata disappears, along with access to the remaining data.

Therefore, there is currently no decentralized or distributed storage system with decentralized metadata that is fast enough to be usable as Storj is today.

There is also no fast, distributed database solution that can operate on a Byzantine network.

4

Thank you both, this is exactly the kind of grounding I was hoping for.

@arrogantrabbit — that distinction is really helpful. I think you’re right: I was unconsciously drifting toward a full BFT/Sia-style redesign, when the actual problem I care about (surviving the disappearance of Storj Labs) is much narrower. “Replicate satellite state to infrastructure controlled by another entity, with the keys and procedures to take over” is a far more proportionate answer than re-architecting the whole coordination layer. Survivability, not full decentralisation.

@Alexey — thank you, and the chicken-and-egg point is the piece I was missing. It makes sense now: metadata backups living in Storj buckets can’t bootstrap a recovery if the satellite needed to read them is the thing that’s down. And the framing that there’s currently no decentralised-metadata system fast enough to match Storj today (nor a fast distributed DB tolerant of a Byzantine network) tells me the “immortal” version is an unsolved problem, not just an unprioritised one. That’s a genuinely useful thing to understand as an operator — it separates “decentralised on paper” from what’s actually achievable.

So if I fold both answers together: the realistic goal isn’t a trustless immortal network, it’s continuity through succession — making sure that if the current entity goes away, another party can pick up the satellite state and keep the lights on.

Which leads to my real follow-up, and it feels timely given the restructuring: does a documented takeover procedure actually exist today? Concretely — is there, somewhere, a defined process by which a successor entity could obtain the satellite metadata/state plus the keys and run the satellites, without depending on the original company still being around to hand things over? Or is that continuity currently informal / undocumented?

I ask because that seems like the one piece that turns “the network could survive Storj Labs” from a hope into something with an actual runbook — and now feels like the moment to have it written down rather than after a hypothetical shutdown.

Thanks again for taking the time with a non-engineer’s question.

5

I believe this is regulated by law, not some technical procedure. Metadata also includes a client list, so a commercial project can’t simply share it; this usually involves purchasing a company or a stake in it.
Internal documentation for operating the existing infrastructure exists, and there’s also a satellite operator that documents general operating principles; see satellite-operator.

6

That’s the missing piece — thank you. The fact that it’s a legal question rather than a technical one reframes it completely for me: continuity runs through acquiring the entity (or a stake in it), not through some transfer switch. And the client-list angle makes total sense — the metadata isn’t just piece-mapping, it’s commercially sensitive data that can’t be freely replicated even encrypted, which closes off the “just distribute it” idea more firmly than I’d realised.

Good to know internal operating documentation exists and that there’s a defined satellite-operator role. I’ll go read through that tag.

So my takeaway as an operator: the network surviving Storj Labs isn’t about an immortal trustless design (unsolved), it’s about a successor entity being able to acquire and run the infrastructure — which is exactly what’s on the table right now. That’s reassuring in a grounded way. Thanks again to you both for the patient answers.