Skip to content

IFP-102.md

Latest commit

 

History

History
executable file
·
394 lines (233 loc) · 6.02 KB

IFP-102.md

File metadata and controls

executable file
·
394 lines (233 loc) · 6.02 KB
Raw

IFP-102

Inference Transaction Protocol

Status: Draft v1.0
Category: Intelligence Fabric Protocol

1. Purpose

This specification defines how inference requests are submitted, committed, escrowed, and routed within the Intelligence Fabric Protocol (IFP).

It formalizes:

  • SubmitPrompt transaction semantics
  • Prompt commitment construction
  • Fee escrow mechanics
  • Relay vs direct delivery modes

Inference execution occurs off-chain, but its economic lifecycle is governed on-chain.

2. Conceptual Model

Inference is modeled as a two-phase protocol:

  1. SubmitPrompt (on-chain registration + escrow)
  2. SubmitReceipt (on-chain settlement)

This document defines Phase 1.

3. SubmitPrompt Transaction

SubmitPrompt is a consensus-recognized transaction type defined in TET-004.

3.1 Canonical Payload

SubmitPromptPayload = { model_id: Hash32, version: u32, prompt_commitment: Hash32, max_output_tokens: u32, pricing_mode: u8, relay_mode: u8, deadline_height: u64 }

4. Field Definitions

4.1 model_id

References registered model under IFP-100.

Validation requires:

  • Model exists
  • Version exists
  • Model state == Active

4.2 version

Explicit model version.

Must match registered version.

4.3 prompt_commitment

Cryptographic commitment to the actual prompt.

Defined as:

prompt_commitment = SHA256(prompt_bytes || salt)

Salt must be:

  • Random
  • Minimum 16 bytes
  • Stored locally by client

Prompt plaintext MUST NOT appear on-chain.

4.4 max_output_tokens

Upper bound on generation size.

Used for:

  • Fee estimation
  • Escrow upper limit enforcement

4.5 pricing_mode

Defines pricing logic:

0 = Owner-defined fixed pricing
1 = Market-based operator pricing
2 = Hybrid (owner minimum + market adjustment)

Pricing logic executed deterministically by economics module.

4.6 relay_mode

Defines delivery routing:

0 = Relay delivery
1 = Direct delivery

Relay delivery: Client → Relay → Operator

Direct delivery: Client ↔ Operator

Protocol does not enforce encryption scheme but requires commitment integrity.

4.7 deadline_height

Block height after which receipt invalid.

If:

current_height > deadline_height

Receipt submission must fail.

5. Prompt Commitment Rules

5.1 Construction

Client constructs:

salt = RandomBytes(≥16) commitment = SHA256(prompt || salt)

Client must retain:

  • prompt
  • salt

Commitment ensures:

  • On-chain privacy
  • Future dispute resolution capability

5.2 Verification

Receipt must reference:

prompt_tx_hash

Matching commitment ensures linkage.

6. Fee Escrow Mechanism

6.1 Escrow Lock

Upon SubmitPrompt execution:

balance[sender] -= fee_limit EscrowAccount[prompt_tx_hash] = fee_limit

Escrowed funds are locked.

6.2 Fee Determination

Actual fee F determined upon receipt submission.

Constraint:

F ≤ fee_limit

6.3 Settlement Outcomes

Case 1: Receipt valid
→ Escrow distributed per revenue routing.

Case 2: Deadline exceeded
→ Escrow refunded to sender.

Case 3: Fraud detected
→ Escrow may be slashed or partially refunded.

7. Deterministic Validation Rules

SubmitPrompt must:

  • Pass signature validation
  • Have correct nonce
  • Reference active model
  • Provide valid commitment
  • Have deadline_height > current_height

If any condition fails:

Transaction rejected.

8. State Mutation

On successful execution:

State updates:

  1. Lock escrow
  2. Record PromptEntry: { model_id, version, sender, prompt_commitment, deadline_height, escrow_amount, status = Pending }

Entry stored in prunable ledger.

9. Relay Delivery Semantics

Protocol does NOT:

  • Store prompt content
  • Validate encrypted transport
  • Guarantee relay reliability

Relay_mode influences:

  • Client-side routing logic
  • Off-chain communication pattern

Relay_mode does NOT affect consensus state logic beyond flag storage.

10. Prompt Expiry

If:

current_height > deadline_height AND no receipt submitted

Then:

PromptEntry.status = Expired Escrow refunded deterministically.

Prunable entry eligible for removal after challenge window.

11. Multiple Receipts Prevention

Each PromptEntry must enforce:

status ∈ {Pending, Settled, Expired, Disputed}

Only one successful receipt allowed.

12. Gas Accounting

Gas cost includes:

  • Base SubmitPrompt cost
  • Payload size cost
  • Storage write cost

Gas must be deterministic.

13. Security Model

SubmitPrompt security guarantees:

  • Prompt privacy (via commitment)
  • Economic guarantee via escrow
  • Deadline enforcement
  • Deterministic settlement

Protocol does NOT guarantee:

  • Inference correctness
  • Output quality
  • Operator honesty

These are governed economically.

14. Formal Definition

Let:

SP = SubmitPrompt(S, Tx)

If valid:

S' = S

  • balance[sender] -= fee_limit
  • Escrow[prompt_tx_hash] = fee_limit
  • Prompts[prompt_tx_hash] = PromptEntry

Else:

S' = S

15. Invariants

For any PromptEntry:

  • escrow_amount ≥ 0
  • status uniquely defined
  • only one receipt may settle
  • escrow conserved until settlement

16. Interaction with IFP-103

SubmitReceipt:

  • Must reference existing PromptEntry
  • Must occur before deadline_height
  • Must not exceed escrow
  • Triggers revenue routing

17. Conclusion

IFP-102 defines:

  • Inference request registration
  • Commitment-based privacy
  • Deterministic escrow locking
  • Delivery routing flag
  • Deadline enforcement

It converts inference from:

An API call

Into:

A deterministic economic state transition.

This is the foundation of intelligence-as-infrastructure.

End of IFP-102.