Skip to content

IFP-101.md

Latest commit

 

History

History
executable file
·
372 lines (220 loc) · 5.94 KB

IFP-101.md

File metadata and controls

executable file
·
372 lines (220 loc) · 5.94 KB
Raw

IFP-101

Shard Ownership & Storage Ledger Specification

Status: Draft v1.0
Category: Intelligence Fabric Protocol

1. Purpose

This specification defines how model weight shards are:

  • Committed
  • Indexed
  • Optionally stored
  • Economically incentivized
  • Proven available
  • Pruned

Tetcore does NOT store raw model weights on-chain.

Instead, it stores cryptographic commitments and optional availability attestations.

2. Shard Model

2.1 Shard Definition

A model M is divided into N shards:

M = {Shard₀, Shard₁, …, Shardₙ₋₁}

Each shard:

Shardᵢ ∈ Bytes

Shard size is not consensus-restricted.

2.2 Shard Commitment

For each shard:

shard_hashᵢ = SHA256(Shardᵢ)

Model root commitment:

shard_root = MerkleRoot(shard_hash₀ … shard_hashₙ₋₁)

This root is stored on-chain under IFP-100.

3. Storage Ledger Structure

The Shard Storage Ledger maintains:

ShardStorageLedger = { model_id → { version → { shard_root, shard_count, storage_registry } } }

Where:

storage_registry = { shard_index → [storage_node_addresses] }

4. Storage Node Registration

4.1 Storage Node Identity

Storage nodes are normal accounts that register willingness to store shards.

Registration transaction includes:

  • model_id
  • version
  • shard_index
  • optional collateral amount

4.2 Registration Effects

On successful registration:

storage_registry[shard_index] appends storage_node_address

Registration does NOT prove possession automatically.

5. Storage Node Obligations

Storage nodes that register for shard storage implicitly agree to:

  • Maintain shard availability
  • Respond to availability challenges
  • Serve shard data upon request (off-chain)
  • Maintain integrity of stored shard

Failure may trigger economic penalties if collateralized.

6. Availability Proof Mechanism

6.1 Challenge Model

Any participant may initiate:

ShardAvailabilityChallenge

Payload:

{ model_id, version, shard_index, challenged_node }

6.2 Proof Window

Upon challenge:

challenged_node must respond within:

challenge_window_blocks

Defined by governance.

6.3 Proof Submission

Proof includes:

  • shard_hash
  • optional Merkle proof
  • signature of storage node

If proof valid and matches shard_root:

Challenge resolved successfully.

If no proof submitted within window:

Challenge considered failed.

7. Economic Incentives

7.1 Optional Collateral

Storage registration MAY require:

collateral_amount > 0

Collateral is locked until:

  • Voluntary exit
  • Slashing event
  • Governance removal

7.2 Slashing Conditions

Collateral may be slashed if:

  • Node fails availability challenge
  • Node submits incorrect shard proof
  • Node repeatedly fails service

Slashing logic is deterministic and enforced by kernel.

8. Shard Ownership Semantics

Shard ownership is distinct from model ownership.

Model owner:

  • Controls shard_root
  • Controls version updates

Storage node:

  • Stores physical shard
  • Does not own model

Ownership of shard data does NOT transfer model rights.

9. Pruning Rules

9.1 Core Ledger

Core ledger retains:

  • shard_root
  • shard_count
  • storage registry metadata

Never pruned.

9.2 Storage Proof Records

Availability proofs and challenge records are stored in prunable ledger.

These may be pruned after:

challenge_window_blocks expire.

9.3 Expired Model Versions

If model version becomes Deprecated or Disabled:

Shard registry entries MAY be pruned after:

deprecation_ttl_blocks

Defined by governance.

10. Shard Deregistration

Storage node may voluntarily deregister:

DeregisterShardStorage transaction:

{ model_id, version, shard_index }

If collateralized:

Collateral unlocks after safety delay.

11. Determinism Requirements

All shard registry updates must:

  • Use canonical ordering
  • Be deterministic
  • Not depend on off-chain availability
  • Not verify raw shard contents

Protocol validates only commitments, not data content.

12. State Representation

Formal structure:

ShardRegistry = { (model_id, version, shard_index) → { storage_nodes: OrderedSet

, collateral_locked: map(Address → u128) } }

OrderedSet must use deterministic ordering.

13. Storage Scaling Considerations

Protocol does NOT enforce:

  • Redundancy level
  • Geographic distribution
  • Minimum storage count

These may be introduced via governance or contract logic.

14. Security Assumptions

Shard storage security relies on:

  • Economic incentives
  • Availability challenges
  • Reputation systems (future extension)

Protocol does NOT:

  • Guarantee permanent storage
  • Enforce replication factor
  • Encrypt shard contents

Encryption is model-owner responsibility.

15. Interaction with Inference Operators

Inference operators may:

  • Fetch shards from storage nodes
  • Cache shards locally
  • Operate without registering as storage node

Shard registration is optional unless governance mandates otherwise.

16. Future Extensions

Possible future enhancements:

  • Proof-of-Replication
  • Proof-of-Retrievability
  • ZK-based availability proofs
  • Decentralized storage auctions

Such features must preserve deterministic state updates.

17. Conclusion

IFP-101 defines:

  • Cryptographic commitment of model shards
  • Optional storage node participation
  • Deterministic registry tracking
  • Challenge-based availability model
  • Pruning safety rules

This enables scalable off-chain weight storage while maintaining on-chain integrity commitments.

End of IFP-101.