Skip to content

DRanking: define Store service-receipt evidence profile #766

Description

@zkjoie

Summary

Define the Store-specific evidence profile that may reuse the canonical service-receipt carrier introduced by #710. Do not enable a Store service kind until this issue fixes what verifiable storage event and duration are actually proven.

Required decisions

  • Define provider and beneficiary roles and the exact signed put/accept/acknowledgement transcript.
  • Define deterministic units without equating an acknowledgement with durable availability.
  • Specify whether and how later retrieval, retention duration, replication, expiry, and deletion affect evidence.
  • Specify replay/freshness, bounded admission, failure semantics, and privacy leakage.
  • State non-claims explicitly: a store receipt must not imply future availability, global replication, finality, or honest content retention by itself.
  • Add canonical/golden vectors, adversarial role/transcript tests, and native/Wasm persistence coverage before enabling the wire kind.

Dependencies

Follow-up to #710. Aggregation and finalized admission remain owned by #711 and #712.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions