RFC: Bloodstone Chain Mesh v2.0-Lite — Trustless Storage Layer for Blurt

I am writing this post because my personal charter is committed to transparency.

We are having discussions with the Bloodstone team in a fluid chat group but hereby share the progress.

Their team has taken steps to look into Gitlab and prepare to create a repo, I know there is a learning curve for them on this and thus am giving them the space to do what they need to, please refrain from derailing sentiment based on their current project state, we too started from humble beginnings, regent account, closed binary explorers etc.

The first draft of the Mesh storage layer instructions I have seen show it to have a centralized coordinator + decentralized chunk storage hybrid.

However, the true value is in the manifest system, content addressing, and S3 integration — not in trust-minimization, hence why I am proposing an alternate spec for discussion.

The key objectives being:

+ No central coordinator — manifest discovery via Distributed Hash Table DHT + Blurt blockchain anchoring

+ Trust-minimized retrieval — cryptographic proofs verify data integrity without trusting any single node

+ Blurt as a registry option for our isolated tenancy — manifests anchored on-chain, other tenants outside of Blurt can either use Blurt to anchor their registry or their own.

1. Executive Summary

This spec transforms Bloodstone's centralized coordinator into a decentralized DHT-based storage network where:

+ Manifests are anchored on Blurt via custom json — no hardfork

+ Discovery is DHT-based — no central coordinator for chunk lookup

+ Trust is minimized — cryptographic proofs verify data, not centralized APIs

+ Blurt witnesses run DHT bootstrap nodes — but no miners or uploads occur on witness infra only safe, read-only bootstrap services

+ Bloodstone provides the DHT software — you run it on your own infrastructure, keeping control.

+ Open-source the DHT node and storage daemon under MIT/Apache.

Bloodstone's role: Software provider + optional storage node operator.

Blurt's role: Registry layer anchors + bootstrap infrastructure witness-run DHT nodes .

2. Architecture Overview No Hardfork

3.1 Anchor Operation Format

Blurt's existing custom json operation is used with a dedicated id:

<br / Key properties:

+ Stored permanently in Blurt blocks

+ Replicated to all full nodes

+ Publicly queryable via any Blurt API

+ Posting authority uploader's account

3.2 Provider Independence

+ No provider is trusted — the manifest simply lists them. Clients:

+ Query the Blurt blockchain for the canonical manifest.

+ Cross-check provider claims against the Merkle root.

+ Verify chunk hashes independently before accepting data.

If a provider serves bad data, the client rejects it and falls back to another provider listed in the manifest.

4. DHT Architecture — Bloodstone Provides, Blurt Runs:

4.1 Bootstrap Nodes Independent Blurt Community Node Infra — Safe Mode

Purpose: Peer discovery and DHT routing only. NO storage, NO mining

Docker Deployment Example

Monitoring: Bootstrap nodes should expose Prometheus metrics for:

+ DHT table size

+ Query success rate

+ CPU/Memory usage

+ Bandwidth

Alerting: If any node exceeds resource limits, auto-restart or scale down.

4.2 Storage Providers Bloodstone + Independent Community Nodes

Storage providers are independent entities running the full storage daemon. They:

+ Store chunks and serve them

+ Participate in the DHT

+ Are not trusted by default — clients verify all data cryptographically

+ Bloodstone can be one provider among many — but if they go offline or serve bad data, clients simply use other providers from the manifest.

How Blurt can run its own provider optional :

+ Provision a dedicated VPS not on witness infra .

+ Run the Bloodstone-provided storage daemon.

+ Register your node ID in manifests when uploading.

+ Serve chunks to Blurt users.

5. Publishing Flow Completely Trustless

5.1 Upload & Anchor

<br / Trustless guarantee: Even if ALL providers are malicious, the client:

+ Verifies each chunk hash matches the manifest.

+ Verifies the manifest is signed by the uploader.

+ Can detect tampering by re-hashing the reassembled file.

5.2 Provider Discovery No Central Coordinator

Instead of contacting mytunnel.org, the client:

+ Queries the Blurt blockchain for the manifest using asset key .

+ Extracts provider IDs from the manifest.

+ Queries the DHT to find the IP addresses of those provider IDs.

+ Connects directly to providers and downloads chunks.

If a provider is offline:

+ The client tries the next provider in the list.

+ If all providers are offline, the file is unavailable — but the manifest remains on-chain as the source of truth.

Repair mechanism optional, community-driven :

+ If a file is unavailable, any node can re-upload it to new providers. + The new providers are added to the manifest via a new custom json transaction requires uploader signature or community consensus .

6. Retrieval Flow Trustless Verification

6.1 Client Retrieval Steps

6.2 Trustless Guarantees

No trust in Bloodstone or any provider is required.

Threat Mitigation --------------------------------- ------------------------------------------------- Provider serves corrupted data Chunk hash verification catches it Provider serves wrong chunk order Chunk index + order in manifest Manifest tampered with Anchored on Blurt, signed by uploader Provider goes offline Fallback to other providers in manifest All providers offline File unavailable, but manifest persists; can be re-uploaded

7. Bloodstone Relationship

7.1 What Bloodstone Provides

Deliverable Trust Requirement ------------------------------------------ -------------------------------------------- DHT node software open-source Can audit the code Storage daemon software Can audit the code Optional storage provider their own node Treated as untrusted — verify everything Documentation & support No trust needed

7.2 What Blurt Controls

Control Implementation ---------------------------- ----------------------------------------------------- Manifest anchors custom json — Blurt owns the blockchain Bootstrap nodes Run by Blurt witnesses safe, read-only Provider selection Blurt backend chooses which providers to use Verification logic Blurt backend implements hash verification Upload authorization Blurt accounts sign manifests

7.3 Separation of Concerns

Bloodstone CANNOT:

+ Modify or delete manifests they're on Blurt

+ Force clients to use their provider

+ Access private data all files are public by design

+ Control the DHT bootstrap nodes are run by Blurt

+ Hardfork or change Blurt

Bloodstone SHOULD:

+ Release new open source versions of their software Operators must retain upgrade sovereignty, update push to be optional

+ Run their own storage provider node

+ Contribute to the ecosystem

This is a healthy, low-trust relationship.

8. Risk Assessment & Mitigations

Risk Probability Impact Mitigation ----------------------------------------- ------------- -------- ---------- Bloodstone stops maintaining software Low Medium Fork the code, maintain in-house Bloodstone's provider goes offline Medium Low Use multiple providers, fallback DHT bootstrap nodes go down Low Medium Run 3–5 nodes, monitor Bad data from providers Low High Always verify hashes client-side custom json too large for block size Low Medium Keep manifests minimal hashes only Bloodstone's code has backdoors Low High Open-source audit + run only read-only bootstraps initially

9. Comparison with Original v1.0

Criteria v1.0 Bloodstone v2.0-Lite This Spec :--- :--- :--- Coordinator Single server SPOF DHT + on-chain anchors Manifest registry Centralized API Blurt custom json Discovery Centralized lookup DHT + blockchain Trust model Trust Bloodstone Trustless verification Bloodstone dependency Required Optional provider only On-chain integration Weak optional anchors Strong custom json registry Blurt hardfork needed No No Token usage None None Witness infra impact None Read-only bootstrap nodes only Decentralization Low High

10. Bloodstone must and should scale beyond Blurt

As much as it is attractive to have Bloodstone tied to the Blurt blockchain for immutable and independent registry, Bloodstone and its Chain Mesh are best served as a generic storage network where Blurt is one tenant among many.

The premise is that the registry can be provided by any tenant, but if they want an existing robust and proven registry they can use Blurt, or Bloodstone might create another independent registry.

Either way, Blurt benefits from great ecosystem discovery from Bloodstone's growth.

Key Expansion Features:

Aspect Implication :--- :--- Bloodstone's mesh Operates independently — doesn't require Blurt anchors Blurt's usage Can opt-in to on-chain anchoring for its own files Other tenants May use Bloodstone's coordinator, their own registry, or nothing at all Bloodstone's incentive Keep the mesh useful for ALL tenants — not just Blurt

The mesh doesn't care how you index manifests. It just stores chunks and serves them on request.

10.1 The Two-Layer Model

Layer 1: The Mesh Itself Bloodstone's Infrastructure

┌──────────────────────────────────────────────────────────────┐ │ CHAIN MESH NETWORK │ │ Chunk storage + DHT + peer-to-peer transfer │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Tenant │ │ Tenant │ │ Tenant │ │ │ │ Blurt │ │ Alice │ │ BobCorp │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ All tenants share the same: │ │ • Chunk storage nodes │ │ • DHT for chunk location │ │ • Peer discovery │ │ • Transfer protocols │ └──────────────────────────────────�…

+ Who uploaded a chunk

+ What manifest system they use

+ Whether they anchor on-chain or not

The mesh is agnostic — it stores chunk hash → data and serves it.

Layer 2: Manifest Registry Tenant-Specific <br /

Each tenant can use any registry they want.

+ Blurt uses Blurt blockchain → immutable, public, decentralized

+ Alice uses a central DB → fast, mutable, private

+ BobCorp uses a private ledger → permissioned, auditable

Bloodstone doesn't care — they just provide the storage and retrieval plumbing.

How Other Tenants Use the Mesh

Flow:

1. Alice's backend uploads chunks to the mesh.

2. Alice stores the manifest in her PostgreSQL database.

3. When a user requests vacation.jpg:

+ Alice's backend looks up the manifest in PostgreSQL

+ Fetches chunks from the mesh using DHT

+ Reassembles and returns the file

No blockchain needed. No Blurt needed. No on-chain anchors.

How Blurt Could Use the Same Mesh But Better

<br / Flow:

1. Blurt backend uploads chunks to the mesh same as Alice .

2. Blurt anchors the manifest on the Blurt blockchain Alice can't do this .

3. When a user requests screen.mp4:

+ Blurt backend queries the blockchain for the manifest

+ Fetches chunks from the mesh using DHT

+ Reassembles and returns the file

The mesh operations are IDENTICAL. Only the registry differs.

Bloodstone's Position: Neutral Infrastructure Provider

+ Many tenants → economies of scale

+ Stable network → more tenants

+ Low churn → long-term storage contracts

+ Not locked into a single registry system limits adoption

Why This Works for Blurt

Blurt Goal How the Mesh Delivers :--- :--- Decentralized storage Mesh is peer-to-peer, DHT-based Trustless verification Chunk hashes + Merkle roots Permanent manifests Blurt blockchain anchors No Bloodstone dependency Run your own bootstrap nodes + providers Independence Other tenants don't affect Blurt's registry

Blurt uses Bloodstone's plumbing but bringing its own registry. This is the ideal relationship.

Simplified Visual: Blurt vs. Other Tenants

<br / Each tenant uses the same mesh infrastructure but different manifest registries that suit their needs.

This is the ideal architecture — you get:

+ The network effects of a shared storage mesh

+ The sovereignty of your own registry

+ The trustless properties of cryptographic verification

---

The "What If" Scenarios

Bloodstone Goes Offline All Their Nodes

Impact Mitigation :--- :--- Their storage nodes unavailable Manifests still on Blurt — you know what chunks to fetch Their DHT nodes unavailable Your own bootstrap nodes + DHT nodes continue operating Their provider nodes gone Files stored only on Bloodstone's nodes become unavailable But: You can run your own provider nodes for critical files

Mitigation strategy: When uploading, include at least one Blurt-operated provider in the manifest That way, even if Bloodstone vanishes, you have a copy

Bloodstone Refuses Blurt Traffic

Impact Mitigation :--- :--- They block requests from Blurt IPs Use your own provider nodes They refuse to serve Blurt's chunks Your provider nodes still serve them They corrupt chunks Hash verification catches it — you reject and fallback They remove Blurt's manifest from their coordinator Doesn't matter — your manifests are on Blurt blockchain

You own the manifest. You own the verification. You own the fallback.

Bloodstone Favors Other Tenants Performance Degradation

Impact Mitigation :--- :--- Blurt traffic deprioritized Run your own storage nodes + retrieval nodes Higher latency from Bloodstone nodes Fallback to community nodes Bandwidth throttling You're not paying them directly — no SLA to enforce

The mesh is open — anyone can join. If Bloodstone's service degrades, the community can run more nodes.

11. Recommended Strategy

Phase 1 — Use Bloodstone as Primary Provider Low Risk

+ Upload files to Bloodstone's nodes

+ Anchor manifests on Blurt blockchain

+ Include Bloodstone's node IDs in manifests

+ Verify everything cryptographically

Risk: If Bloodstone shuts down, files on their nodes vanish. But manifests persist.

Phase 2 — Run Your Own Provider Node Medium Risk

+ Provision a VPS or dedicated server

+ Run Bloodstone's storage daemon or your own fork

+ Register your node ID in manifests for critical files

+ Serve chunks to Blurt users

Benefit: At least one provider is under your control.

Phase 3 — Community Provider Program Low Risk

+ Invite community members to run provider nodes

+ Offer non-financial incentives recognition, badges, priority support

+ Maintain a list of trusted community providers

+ Include them in manifests alongside Bloodstone nodes

Benefit: Multiple independent providers, no single point of failure.

--- This is a RFC - Request for Comment, please share thoughts and ideas in literal comments below, thank you!