Conceptio › Archive › arXiv CS
arXiv CSopen access

Attestream: Usage-Aware Intermittent Data Distribution with Verifiable Lifecycle Provenance for Machine-Learning Data Streams

· arxiv_cs
arXiv CS · Papers · License: Open Access
Open Source ↗Direct PDF ↓
cryptographycybersecurityprivacysecurity
cryptography, security, privacy, cybersecurity

Attestream: Usage-Aware Intermittent Data Distribution with Verifiable Lifecycle Provenance for Machine-Learning Data Streams Kentaro Oda

arXiv:2609.07641v1 [cs.CR] 7 Sep 2026

Kagoshima University Kagoshima, Japan [email protected]

Abstract—Providers of continuously produced, commercially valuable data—sensor streams, telemetry, transaction logs, and other feeds sold as machine-learning training material—face two coupled problems: they cannot observe whether delivered data is actually used by consumers, and data that keeps flowing to inactive consumers enlarges the leakage surface without producing value. We present Attestream, a blockchain-based distribution architecture for intermittently delivered dataset streams that couples continued delivery to verifiable usage reporting. Every lifecycle event—dataset preparation, dual-signed delivery, derivative creation (e.g., a trained model), and derivative distribution—is appended to an on-chain registry as a nonrepudiable, mutually linked lifecycle record. What the mechanism requires is provable transfer, not tokenization: we define the record properties abstractly and show that plain contract storage, ERC-721 tokens, and off-chain receipts anchored on-chain are interchangeable representations of the same protocol. A smartcontract usage-aware gate automatically suspends a consumer’s stream when no derivative-creation record is registered for the most recent delivery within a reporting window, converting provenance registration from a voluntary courtesy into an economically enforced obligation. A modality-pluggable fingerprinting layer binds any leaked copy to the dual-signed delivery record of the responsible consumer; we instantiate it for tabular/geospatial records (attribute perturbation), images (spread-spectrum watermarking), and documents (randomized fingerprinting codes). We formalize the gating rule, implement the complete registry as a Solidity contract with EIP-712 dual signatures, and evaluate it on an EVM testbed. A full lifecycle round costs 657k gas with plain records (≈ $0.13 on contemporary rollups; tokenizing the records as ERC-721 adds ∼30k gas per record, 18% per round), and the gate itself adds no dedicated transactions, as it is evaluated lazily inside delivery registration. Over a 50consumer pool, leak attribution reaches 100% accuracy from 40 leaked table rows under moderate noise, survives JPEG recompression to quality 30 for images, and tolerates paraphrase rates up to 30% for documents. The gating mechanism originates in Japanese patent JP 7894573 B2; this paper contributes its first open formalization, realization, and quantitative evaluation, together with the representation analysis and the cross-modality attribution layer.

Index Terms—blockchain, data provenance, smart contracts, verifiable records, data marketplaces, machine learning, usage control, data leakage

I. I NTRODUCTION Machine-learning pipelines are increasingly fed by data streams rather than static corpora. An industrial operator sells daily equipment-telemetry batches to analytics firms that retrain condition-monitoring models as new data arrives; a mobility provider licenses trip records for demand forecasting; an environmental-sensing operator supplies each day’s measurements to forecasting services. Across these settings the asset is not one dataset but an open-ended sequence of small, timely deliveries, each of which loses value quickly if unused, and each of which is typically consumed by incremental retraining of the buyer’s models. Existing infrastructure serves this economy poorly on two fronts. First, the provider is blind after delivery. Blockchain provenance systems [1]–[4] and data marketplaces [5]–[7] create tamper-evident records of access or sale, but nothing tells the provider whether the consumer actually exploited the data—information the provider needs to curate future collection, to price fairly, and to justify continued investment in sensing. Second, unused data is pure risk. Every delivered copy that sits idle at a consumer is an additional locus from which the dataset can leak, while generating no corresponding value. A rational provider would like to stop supplying consumers who no longer use the stream—but has no signal on which to act. Our key observation is that these two problems solve each other when usage reporting is made a condition of continued supply. If the consumer must register a signed, on-chain record of each derivative work (e.g., an updated model) created from the latest delivery in order to receive the next one, then (i) the provider continuously learns whether and how its data is used, and (ii) streams to inactive consumers wither automatically, shrinking the leakage surface precisely where data produces no value. Because each delivery is intermittent and individually small, the sanction—suspension of the next delivery—is proportionate, immediate, and enforceable by a smart contract without litigation. This paper makes that observation concrete. We present

Attestream, a blockchain-based distribution architecture with the following contributions:

Lifecycle provenance as linked verifiable records. We model the four events of the data lifecycle—preparation, delivery, derivative creation, and derivative distribution— as dual-signed records whose fields cross-reference one another, yielding three on-chain graphs: the temporal chain of deliveries in a stream, the data-to-derivative usage graph, and the parent–child lineage of incrementally retrained models. The required properties (integrity, nonrepudiation, linkability) are independent of representation; tokenization à la ERC-721 [8] is an optional add-on whose cost we quantify (Section IV). • A usage-aware delivery gate. We formalize the rule that suspends a stream when the latest delivery is not acknowledged by a derivative-creation record within a reporting window, and show how it can be evaluated lazily inside the next delivery transaction, so that monitoring adds no dedicated transactions and no off-chain trusted monitor (Section IV-C). • Dual-signed, fingerprint-bound deliveries across modalities. Delivery records embed both the provider’s transaction signature and the consumer’s EIP-712 [9] consent signature, making them non-repudiable by either party. A modality-pluggable fingerprinting layer binds leaked copies to a specific dual-signed record; going beyond the numeric-perturbation embodiment of the prior patent [10], we instantiate it for tabular/geospatial records, images (spread-spectrum watermarking [11]), and documents (randomized fingerprinting codes [12], [13]) behind one attribution interface (Section IV-D). • Implementation and evaluation. We implement the complete registry as a single Solidity contract and measure per-operation gas, end-to-end round latency, lineagequery scaling, and attribution accuracy of all three fingerprint instantiations under partial leakage, adversarial noise, compression, paraphrasing, and two-party collusion (Sections V–VI).

•

The usage-gated distribution mechanism that Attestream realizes was first proposed in Japanese patent JP 7894573 B2 [10] (published as application JP 2023-43186 A in 2023 and granted in 2026), held by Kagoshima University, Ocean Solution Technology, and Lily; the present author is one of its inventors. That document specifies the system at the level of functional units and embodiments, but contains no formal gating rule, no analysis of the record representation, no concrete realization, and no measurements. Building on it as prior work, this paper contributes the formalization, the representation-agnostic record abstraction and its cost ablation, the lazy gate realization, the modality-pluggable fingerprinting layer, and the quantitative evaluation—none of which appear in the patent literature.

II. R ELATED W ORK A. Blockchain Data Provenance and Sharing ProvChain [1] anchors cloud file-operation logs in a blockchain; MedRec [2] manages medical-record access permissions via Ethereum contracts; MeDShare [3] monitors inter-provider medical data flows and can revoke access on detected policy violations; Neisse et al. [4] model data-usage accountability contracts for GDPR compliance. These systems log or police access to primary data. Attestream extends provenance across derivative artifacts and inverts the enforcement direction: rather than sanctioning detected misuse, it sanctions the absence of affirmative usage reports, which no prior provenance system enforces. B. Data Marketplaces and Trading IDMoB [5] matches IoT vendors and buyers on-chain; SDTE [6] secures the trade itself with trusted hardware; SDPP [7] interleaves micropayments with streaming records. All treat the sale as the terminal event. Attestream instead treats delivery as the beginning of an obligation cycle—report usage or lose supply—and extends billing hooks to derivative sales, which marketplaces do not track. C. Tokenized Records Surveys of the NFT ecosystem [14] and frameworks for deployable NFT contracts [15] focus on tokens as tradeable representations of single assets. Attestream needs none of that machinery: its records are dual-signed lifecycle events whose value lies in their links to one another, and verifiability— not transferability—is the point. Tokenization is retained only as an optional representation for ecosystems that want wallet visibility or royalty rails, and Section VI quantifies exactly what that option costs. D. Model and Dataset Provenance Datasheets [16] and model cards [17] are voluntary, offchain documentation without authenticity guarantees. Lo et al. [18] record federated-learning provenance on-chain among cooperating parties. Attestream targets the adversarial provider– consumer setting and makes dataset-to-model lineage a cryptographically signed record whose registration is compelled by the delivery gate. E. Access and Usage Control via Smart Contracts FairAccess [19], contract-based IoT access control [20], auditable policy contracts [21], and Droplet’s cryptographic stream authorization [22] all gate on who may access a resource, or penalize detected misbehavior [20]. Attestream’s gate is, to our knowledge, the first to suspend supply on a consumer’s failure to act—a continuous-obligation semantics closer to usage control (UCON) than to access control, realized natively in the delivery path.

F. Leak Tracing and Accountability

Provider and consumers are mutually distrusting rational parties. A consumer may (i) deny having received a delivery, (ii) use data without reporting, (iii) leak its copy, or (iv) register fabricated usage reports. A provider may (v) deny having delivered, or (vi) falsely accuse a consumer of leaking. The ledger is assumed to provide integrity and availability (standard blockchain assumptions [32]); signing keys are not compromised. Verifying semantic truth of a usage report (that a registered hash really is a model trained on the data) is out of scope of the on-chain mechanism and is discussed in Section VII. C. Design Goals G1 Usage visibility: the provider can determine, per consumer and per delivery, whether the data was used to create a derivative. G2 Automatic supply discipline: streams to consumers who stop reporting usage are suspended without provider intervention or a trusted monitor. G3 Non-repudiation: neither party can later deny a completed delivery; consumers cannot deny authorship of registered derivatives.

reg.

parent

Recipient R

consent

.

B. Threat Model

TR2 Delivery (i) δj dual-sig.

model Mk

reg

A provider P prepares, at irregular intervals (every one to a few days), a fresh dataset Dj —the j-th element of an openended stream D = D1 , D2 , . . .. Each registered consumer (i) Ci receives its own fingerprinted variant Dj and may use it, possibly together with its previously created derivative (e.g., yesterday’s model), to produce a new derivative M . Consumers may further distribute derivatives to third-party recipients. A history-management ledger L—a blockchain hosting the Attestream contract—stores all lifecycle records. Payloads themselves are exchanged off-chain (direct download or encrypted object storage); the ledger stores only hashes, identities, timestamps, links, and signatures.

TR1 Prep. ρj

prev

nt conse

A. Actors and Assets

reg.

.

III. S YSTEM M ODEL AND D ESIGN G OALS

Consumer Ci

reg

Media watermarking [11], document marking [23], database watermarking and fingerprinting [24], [25], GIS coordinate watermarking [26], collusion-secure fingerprinting codes [12], [13], and radioactive data [27] identify a guilty recipient after a leak; probabilistic leakage attribution [28] does so without marks; LUCE [29] monitors license compliance on-chain. Attestream does not propose new marks; its contribution is to place existing embedders behind one attribution interface and to combine ex-ante reduction of the leak surface (unused streams stop flowing) with ex-post attribution whose evidence—the dual-signed delivery record of the fingerprinted copy—is already on-chain. In application domains such as environmental sensing and supply chains, blockchain has been applied to product traceability [30], [31], not to sensor-data monetization with derivative tracking.

(i)

payload Dj Provider P

TR3 Deriv. creation µk

TR4 Deriv. distribution

derivative used-delivery used-prep Blockchain ledger L (Attestream contract)

Fig. 1. Attestream overview. Payloads move off-chain (dashed); every lifecycle event appends a linked, dual-signed record on-chain. The delivery gate (Alg. 1) is evaluated inside TR2 registration.

G4 Lineage: every derivative is linked to the deliveries it consumed and to its parent derivative, transitively. G5 Leak attribution: a leaked payload identifies the responsible consumer, with on-chain evidence. IV. T HE ATTESTREAM D ESIGN A. Lifecycle Records as a Linked Provenance Graph Attestream registers four record types, mirroring transactions TR1–TR4 of the patent [10] (Fig. 1): 1) Preparation (TR1): When P finishes assembling Dj , it registers ρj = (hash(Dj ), P, t). This timestamps authorship of the raw dataset before any delivery, analogous to a notarized deposit. 2) Delivery (TR2): After Ci downloads its (i) (i) fingerprinted variant Dj , P registers δj = (i) (i) (P, Ci , hash(Dj ), ρj , δj−1 , t, σCi ), where σCi is the (i) consumer’s EIP-712 signature over (P, Ci , hash(Dj ), ρj , n) with a per-consumer nonce n preventing replay. The contract verifies σCi on-chain; the transaction itself carries P ’s signature, so the confirmed record is signed by both parties (i) (G3). The δj−1 back-pointer chains all deliveries of one stream (the patent’s “previous-data identification”). 3) Derivative creation (TR3): When Ci trains a model (i) Mk from Dj (optionally refining a previous model Mk−1 ), (i) it registers µk = (Ci , hash(Mk ), δj , µk−1 , t). The useddelivery link realizes G1 and G4; the parent link records incremental-training lineage, so the full ancestry of any model version is walkable on-chain. 4) Derivative distribution (TR4): When Ci transfers Mk to a recipient R, it registers a record carrying both Ci ’s and R’s signatures, extending non-repudiation one hop down the value chain and enabling royalty-style billing on derivative sales. Only the record owner roles can register: TR1/TR2 by the provider (TR2 additionally requiring the consumer’s consent signature), TR3 by the consumer named in the referenced delivery, TR4 by the creator of the referenced derivative. All references are validated for type and ownership at registration time, so the on-chain graph is well-formed by construction.

B. Record Representation The protocol requires of a record store only four properties: integrity (records cannot be altered once confirmed), nonrepudiation (each record binds the signatures of its parties), linkability (records reference one another by stable identifiers), and queryable availability (the gate and lineage walks can read them). It does not require token semantics—no ownership transfer, no wallet balance, no marketplace interface. The patent itself spans this spectrum: its first embodiment stores history records in an audited third-party database, and only its fourth realizes them as NFTs. We therefore treat the representation as a deployment choice: 1) Plain contract records (default): Each record is a struct in contract storage plus an event; identifiers are sequence numbers. This is the minimal on-chain realization of the four properties and the cheapest (Section VI-B). 2) ERC-721 tokenization (optional): The same structs are additionally minted as ERC-721 tokens [8]. This buys wallet and explorer visibility, standardized custody, and composability with royalty/marketplace rails—relevant if derivative records are themselves traded—at a measurable gas premium. 3) Anchored receipts / audited database: Where no chain is desired, dual-signed receipts can live in an audited database (the patent’s first embodiment), optionally anchored by periodic hash commitments to a public chain; integrity then rests on the auditor plus the anchors, and the gate runs in the distribution server rather than a contract. The gate logic, signature scheme, link structure, and fingerprinting layer are identical across representations; our prototype implements the first two on the same code path and we quantify the difference in Section VI-B. C. The Usage-Aware Delivery Gate Let w be the reporting window agreed at stream registration (shorter than the delivery interval; e.g., w = 1 day for a (i) daily stream). Let tj be the confirmation time of delivery δj and aj ∈ {⊥} ∪ R the time at which some TR3 record first (i) referenced δj (⊥ if none). Define ack(j) ≡ aj ̸= ⊥ ∧ aj ≤ tj + w.

(1)

The gate admits delivery j+1 at time t iff the stream is registered, not administratively suspended, and j = 0 ∨ ack(j) ∨ t ≤ tj + w.

(2)

The last disjunct lets an early next delivery proceed while the window for the previous one is still open; once the window has lapsed without acknowledgment, every subsequent delivery attempt fails and the stream is marked suspended until the provider explicitly reinstates it. A late TR3 record (registered after tj + w) does not reopen the gate—the consumer demonstrated non-compliance, and reinstatement is a provider decision, mirroring the patent’s provider-controlled deliverypermission flag. A naive realization would run an off-chain monitor (the patent’s “monitoring unit”) that polls the ledger at tj + w

Algorithm 1 Lazy gate evaluation inside recordDelivery Require: stream state s = (δlast , tlast , ack , alast , susp), window w, now t 1: if ¬s.registered ∨ s.susp then 2: return revert 3: end if 4: if δlast ̸= ⊥ then 5: timely ← ack ∧ (alast ≤ tlast + w) 6: if ¬timely ∧ t > tlast + w then 7: s.susp ← true; emit Suspended; 8: return revert 9: else if ¬timely then 10: return revert {window still open} 11: end if 12: end if 13: verify consumer EIP-712 consent; append δ; update s

and writes a permission flag—one extra transaction per consumer per round, plus a trusted scheduler. Our key implementation insight is that the gate predicate (2) depends only on stored state and the current block timestamp, so it can be evaluated lazily inside the next recordDelivery call (Alg. 1): suspension takes effect exactly when it matters—at the moment the provider attempts the next delivery—at zero additional transaction cost, and deliveryAllowed remains available as a free view call for off-chain pre-checks (G2). Block timestamps are miner-influenceable only by seconds, negligible against windows of hours or days. D. Modality-Pluggable Fingerprinting and Leak Attribution The patent’s second embodiment derives each consumer’s variant by perturbing numeric attributes of tabular records. We generalize this into a pluggable fingerprint embedder abstraction, so that one attribution pipeline covers the payload types that real data streams actually carry—tables, images, and documents. An embedder is a keyed function F mapping the master (i) Dj and a consumer key ki to the variant Dj = F (Dj , ki ) (i) satisfying three properties: fidelity (Dj retains the utility of Dj ), robustness (the mark survives the transformations a leaker plausibly applies), and distinguishability (variants of different consumers are reliably separable even from partial content). The on-chain side is modality-agnostic: the contract only ever (i) (i) (i) sees hash(Dj ) and maintains the index hash(Dj ) 7→ δj . We instantiate F for three modalities: 1) Tabular and geospatial records (the patent’s embodiment): Zero-mean Gaussian perturbation of error-tolerant numeric attributes [24], [25], seeded by ki . Our reference instantiation perturbs the latitude/longitude of geotagged records by N (0, σ 2 ) with σ ≈ 0.0005◦ (≈55 m), well within typical sensor tolerance [26]; measurements, timestamps, or leastsignificant digits can carry the mark instead. Attribution matches leaked rows against each consumer’s expected variant by mean squared error. 2) Images: A Cox-style multiplicative spread-spectrum watermark [11]: the M perceptually most significant mid-

frequency DCT coefficients v of the master are replaced by v(1+αwi ), where wi ∼ N (0, 1)M is pseudorandomly derived from ki (α = 0.1, M = 4096 in our prototype). Attribution extracts the relative coefficient deviations of a leaked image and correlates them against each candidate pattern; spreadspectrum embedding makes the mark robust to compression, filtering, and requantization while remaining imperceptible. 3) Documents: Text does not tolerate numeric perturbation, but exposes meaning-preserving binary choice sites: synonym pairs, equivalent phrasings, punctuation and formatting variants [23]. Each consumer’s variant realizes the S sites of the master according to a pseudorandom codeword ci ∈ {0, 1}S derived from ki —a randomized fingerprinting code in the sense of Boneh–Shaw and Tardos [12], [13]. Attribution over a leaked excerpt scores the agreement of the visible sites with each candidate codeword; the code-based formulation additionally yields resistance to small coalitions of colluding consumers, which per-record perturbation alone does not provide. In all three cases the provider recomputes (or, for partial leaks, statistically matches, Section VI-D) the fingerprint of a leaked file and presents the dual-signed delivery record as evidence that this consumer received exactly this copy (G5). (i) Because the consumer co-signed hash(Dj ) at delivery time, it cannot claim the fingerprint was planted after the fact—an evidentiary link that standalone watermarking schemes lack. E. Billing Hooks Delivery and derivative-distribution records give the provider a non-repudiable basis for per-delivery charging and for revenue sharing on derivative sales (the patent’s third embodiment). Settlement can be off-chain against on-chain evidence, or native (escrowed payment released by the TR2 registration); we implement records only and discuss settlement as orthogonal. V. I MPLEMENTATION We implemented the registry as Solidity 0.8.24 contracts on OpenZeppelin’s EIP-712 (and, for the tokenized variant, ERC721) libraries, compiled with the optimizer at 200 runs for the Cancun EVM. Two variants share one code path (∼320 lines each): the default stores each record as a struct in contract storage plus an event, and the tokenized variant additionally mints each record as an ERC-721 token (Section IV-B). In both, a Record struct stores type, actor addresses, payload hash, timestamp, and the three link fields (prev, used, parent). Stream state is a (provider, consumer)keyed mapping holding the window, last delivery id and time, and acknowledgment state; TR3 registration updates the acknowledgment in O(1). Consent signatures use EIP-712 typed data with per-consumer nonces. The listing below shows the gate on the hot path: bool timely = s.lastAck && s.ackTime <= s.lastTime + s.window; bool open = block.timestamp <= s.lastTime + s.window; if (!timely && !open) {

ERC-721 records

46.2k 46.1k

registerStream

plain records 135.2k 105.3k

recordPreparation (TR1)

243.2k 213.5k

recordDelivery (TR2, dual-signed)

206.5k 176.8k

recordDerivative Creation (TR3)

191.2k 161.5k

recordDerivative Distribution (TR4) 0

50

100

150

200

250

Mean gas used (thousands) Fig. 2. Mean gas per operation over 100 lifecycle rounds, for the plain and ERC-721 record representations. Round-to-round variation is below 0.1% except for first-round cold storage-slot initialization, which raises the maxima by up to 13%.

s.suspended = true; emit StreamSuspended(provider, consumer, s.lastDeliveryId); revert ReportingWindowElapsed( s.lastDeliveryId); } if (!timely) revert ReportingWindowElapsed(s.lastDeliveryId);

The prototype comprises both contract variants, a sevencase property test suite (lifecycle round-trip, gating on silence, late-acknowledgment handling, multi-round streams, lineage walking, forged-consent rejection, and unregistered-consumer rejection) executed against each variant (14 runs, all passing), and the evaluation harness. Source code is available from the author. VI. E VALUATION We ask: (Q1) What does lifecycle registration cost onchain, and is it viable on public infrastructure? (Q2) How does the lazy gate affect cost and latency? (Q3) How reliably do the three fingerprint instantiations attribute partial, degraded leaks? On-chain experiments ran on a local Hardhat/EDR EVM node (Cancun) with 100 full lifecycle rounds; gas figures are EVM-deterministic and thus identical on any EVM chain, while latency figures are testbed-local upper bounds on throughput, in practice dominated by chain block times. All fingerprint experiments use a pool of 50 registered consumers (chance level 2%). A. On-Chain Cost (Q1, Q2) Table I and Fig. 2 summarize per-operation gas. TR2 is the most expensive operation (214 k gas in the plain representation): it verifies an EIP-712 signature, checks the gate, appends the record, and writes the delivery index and stream state. A complete daily round—preparation, delivery, derivative report, and one derivative distribution—costs 657 k gas, i.e., ≈ $13 on Ethereum L1 under the stated assumptions but only ≈ $0.13 on contemporary rollups and marginal cost on a consortium

Contract deployment registerStream TR1 recordPreparation TR2 recordDelivery TR3 recordDerivCreation TR4 recordDerivDistrib Full round (TR1–TR4)

40

20

Plain

ERC-721

L1 (USD)

Rollup

1,521,789 46,145 105,297 213,548 176,768 161,473

2,318,786 46,235 135,163 243,244 206,507 191,206

30.44 0.92 2.11 4.27 3.54 3.23

0.30 0.009 0.021 0.043 0.035 0.032

657,086

776,120

13.14

0.131 Fig. 3. Lineage-query latency vs. ancestry depth (local node, view call).

chain, comfortably below the value of a commercial daily data delivery. Costs scale linearly in consumers and rounds; no operation touches unbounded state. The lazy gate (Alg. 1) adds only a few storage reads and one comparison to TR2—within round-to-round noise—and, crucially, eliminates the per-consumer-per-round monitoring transaction of the naive design, so the monitoring mechanism itself is gas-free (Q2). Suspension consumes gas only in the exceptional path (one storage write and event inside the reverting call’s gas). B. Record-Representation Ablation Because the protocol needs provable transfer rather than tokens (Section IV-B), we measured both representations on the same code path. Dropping ERC-721 minting saves a nearconstant ∼30 k gas per record—the token’s ownership and balance writes plus the transfer event—which amounts to 12– 22% per operation, 15.3% (119 k gas) per full round, and 34% of deployment cost (Table I). The gate, signatures, links, and queries are unaffected. Tokenization is thus purely a feature decision: it is worth its premium only where wallet visibility, standardized custody, or royalty rails over derivative records are actually consumed by the ecosystem, and the numbers above price that decision. C. Latency and Query Scaling A full four-transaction round completes in 13.1 ms mean (p95: 18.6 ms; plain records; the tokenized variant adds ∼3 ms) on the local node, i.e., the contract logic sustains >75 rounds/s per process; real deployments are bounded by block production, not by Attestream logic. Walking a model’s ancestry via lineageOf (a view call) returns 100 generations in under 50 ms (Fig. 3); leak-attribution lookup by payload hash is a single mapping read (under 1 ms including RPC overhead). D. Fingerprint Attribution Across Modalities (Q3) 1) Tabular/geospatial records: We simulate a 2,000-row dataset of location-stamped records, each consumer holding a variant fingerprinted with per-consumer Gaussian coordinate noise (σ = 0.0005◦ ). A leaker releases a random subset of rows and may add its own Gaussian noise of scale λσ to degrade the mark; attribution minimizes mean squared

0 0

20

40

60

80

100

Lineage depth (ancestor records traversed)

1.0

Attribution accuracy

Operation

Query latency (ms)

TABLE I G AS PER OPERATION FOR BOTH RECORD REPRESENTATIONS ( MEANS ; n = 100 ROUNDS , n = 20 FOR R E G I S T E R S T R E A M ), AND PROJECTED COST OF THE PLAIN VARIANT (E THEREUM L1 AT 5 GWEI , ROLLUP AT 0.05 GWEI , ETH = $4,000).

0.8 0.6 10 rows leaked 20 rows leaked 40 rows leaked 100 rows leaked 200 rows leaked

0.4 0.2 0.0 0.0

0.5

1.0

2.0

4.0

Adversarial noise scale (multiples of fingerprint σ) Fig. 4. Tabular records: attribution accuracy vs. adversarial noise, for varying numbers of leaked rows (200 trials per point).

coordinate error over the leaked rows. Fig. 4 reports accuracy over 200 trials per configuration. With no or moderate added noise (λ ≤ 1), attribution is essentially perfect from as few as 10–20 leaked rows. Even an adversary injecting noise at twice the fingerprint scale (λ = 2)—already doubling the positional error of its own product— is identified with 97% accuracy from 40 rows and 100% from 100 rows. Only at λ = 4, where the leaked data’s positional quality is severely degraded, does small-leak attribution fail, and 200+ leaked rows still yield 99% accuracy. 2) Images: We embed the spread-spectrum mark (α = 0.1, M = 4096 DCT coefficients) into a 512×512 reference image for each of the 50 consumers; the marked copies are visually indistinguishable from the master (mean PSNR 53.1 dB, min 52.3 dB). Each leaked copy is subjected to an attack before attribution. Fig. 5 shows the outcome: attribution remains at 100% under every attack tested—JPEG re-compression down to quality 30, additive pixel noise up to σ = 5, a 50% downscale–upscale cycle, and a combined JPEG-plusnoise attack—because the 4096-chip spread-spectrum pattern degrades gracefully while remaining strongly correlated with its key. 3) Documents: We model a document with S = 400 meaning-preserving binary choice sites and give each consumer a variant realized by its pseudorandom codeword. A leaker publishes an excerpt exposing a fraction of the sites

none

1.00

JPEG q=90

1.00

JPEG q=70

1.00

JPEG q=50

1.00

JPEG q=30

1.00

noise sigma=2

1.00

noise sigma=5

1.00

resize 50%

1.00

JPEG70+noise

1.00

0.0

0.2

0.4

0.6

0.8

1.0

Attribution accuracy (50 consumers) Fig. 5. Images: attribution accuracy after common removal attacks (spreadspectrum mark, α = 0.1, mean PSNR 53 dB; one trial per consumer per attack).

Attribution accuracy

1.0 0.8 0.6 20 sites visible 40 sites visible 100 sites visible 200 sites visible 400 sites visible

0.4 0.2 0.0 0.0

0.1

0.2

0.3

0.4

Paraphrase flip probability p Fig. 6. Documents: attribution accuracy vs. paraphrase flip probability, for varying numbers of visible choice sites (S = 400 total, 500 trials per point).

and applies a paraphrase pass that flips each visible site with probability p; attribution maximizes codeword agreement over visible sites (Fig. 6, 500 trials per point). With a tenth of the document visible (40 sites), attribution is 94% accurate under p = 0.2 and perfect under lighter paraphrasing; with half the document, it withstands p = 0.3 at 100%. Under a two-consumer collusion in which the coalition splices its two variants site-by-site, the top-scoring codeword belongs to a colluder in 96.8% of trials with 40 visible sites and 100% from 100 sites—the behavior expected of randomized fingerprinting codes [12], [13], whose collusion bounds sharpen further with dedicated code constructions. Across all three modalities, attribution accuracy grows with exactly what makes a leak harmful—its volume and fidelity— and every identification is backed by the consumer’s own delivery co-signature. VII. D ISCUSSION A. Security Properties Non-repudiation (G3). A confirmed TR2 record carries the provider’s transaction signature and the consumer’s EIP-712 consent over the payload hash and preparation reference;

nonces prevent replay. Neither party can later deny the delivery, and disputes reduce to signature verification against the ledger. False accusation resistance. The provider cannot frame a consumer: a leaked file attributes only if it matches a fingerprint whose hash the consumer itself co-signed. Gate manipulation. The consumer cannot forge acknowledgments (TR3 requires its own signature referencing a delivery addressed to it), and the provider cannot fabricate a missed window, since delivery and acknowledgment times are consensus timestamps. B. Limitations Semantic truth of reports. The contract verifies that a consumer registered a derivative hash, not that the hash denotes a genuine model trained on the delivered data. A consumer determined to keep the stream flowing while idling can register junk hashes at a cost of ≈ 177 k gas per round. The gate is therefore an incentive mechanism—it makes silent freeriding impossible and dishonest reporting attributable and auditable (registered hashes are commitments the provider may spot-check contractually)—rather than a proof of training. Cryptographic proofs of training (e.g., zkML) could close this gap and slot naturally into the TR3 interface. Fingerprint robustness. The three embedders withstand the subsetting, noise, compression, and paraphrasing attacks evaluated in Section VI-D, but each has known stronger adversaries: aggressive coarsening or aggregation for numeric marks, desynchronizing geometric transforms (rotation, cropping) for the globalDCT image mark, and full semantic rewriting for document codes. Hardened embedders from the respective literatures [11], [13], [25], [27] slot into the same interface without touching the on-chain layer, and larger collusion coalitions call for dedicated code constructions [13]. Privacy. Records expose pseudonymous activity patterns (who receives, who trains, how often). Deployments over public chains can blind identities with per-stream addresses; payload content is never on-chain. Collusion. A consumer can outsource training or launder data through a colluding recipient; TR4 records extend accountability one hop, but transitive enforcement beyond direct counterparties remains open. C. Deployment Considerations For a consortium of data providers and analytics firms—the setting that motivated this design—a permissioned EVM chain gives negligible marginal cost and full control over validator membership, while a public rollup provides stronger neutrality at ≈ $0.13 per round. The contract is chain-agnostic EVM bytecode; the reporting window w, the delivery cadence, and the fingerprint scale are per-stream parameters. VIII. C ONCLUSION Attestream turns the provider’s blindness after data delivery into an enforced feedback loop: lifecycle events become dual-signed, mutually linked verifiable records, and continued supply is conditioned—by contract logic alone, at zero added

transaction cost—on timely, attributable usage reporting. Evaluation of our Solidity prototype shows the complete mechanism is practical today: ∼776 k gas per lifecycle round, monitoring without dedicated transactions, and near-perfect leak attribution across tabular, image, and document payloads from small, degraded fractions of a fingerprinted delivery. Future work includes proof-of-training integration for semantically verified reports, hardened and collusion-secure embedders behind the same interface, privacy-preserving record encodings, and field deployment on commercial data streams. ACKNOWLEDGMENT The usage-gated distribution mechanism realized in this paper originates in Japanese patent JP 7894573 B2 [10], invented jointly with Yosuke Mizukami (Ocean Solution Technology Inc.) and Hiroyuki Nozaki (Lily Co., Ltd.); the patent is held by Kagoshima University, Ocean Solution Technology Inc., and Lily Co., Ltd. The author thanks the co-inventors for the collaboration that produced the original mechanism. The formalization, implementation, evaluation, and extensions reported here are the author’s own work. R EFERENCES [1] X. Liang, S. Shetty, D. Tosh, C. Kamhoua, K. Kwiat, and L. Njilla, “ProvChain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability,” in Proc. 17th IEEE/ACM Int. Symp. Cluster, Cloud and Grid Computing (CCGRID), 2017, pp. 468–477. [2] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “MedRec: Using blockchain for medical data access and permission management,” in Proc. 2nd Int. Conf. Open and Big Data (OBD), 2016, pp. 25–30. [3] Q. Xia, E. B. Sifah, K. O. Asamoah, J. Gao, X. Du, and M. Guizani, “MeDShare: Trust-less medical data sharing among cloud service providers via blockchain,” IEEE Access, vol. 5, pp. 14 757–14 767, 2017. [4] R. Neisse, G. Steri, and I. Nai Fovino, “A blockchain-based approach for data accountability and provenance tracking,” in Proc. 12th Int. Conf. Availability, Reliability and Security (ARES), 2017, pp. 14:1–14:10. [5] K. R. Özyilmaz, M. Doğan, and A. Yurdakul, “IDMoB: IoT data marketplace on blockchain,” in Proc. Crypto Valley Conf. Blockchain Technology (CVCBT), 2018, pp. 11–19. [6] W. Dai, C. Dai, K.-K. R. Choo, C. Cui, D. Zou, and H. Jin, “SDTE: A secure blockchain-based data trading ecosystem,” IEEE Transactions on Information Forensics and Security, vol. 15, pp. 725–737, 2020. [7] R. Radhakrishnan, G. S. Ramachandran, and B. Krishnamachari, “SDPP: Streaming data payment protocol for data economy,” in Proc. IEEE Int. Conf. Blockchain and Cryptocurrency (ICBC), 2019, pp. 17–18. [8] W. Entriken, D. Shirley, J. Evans, and N. Sachs, “ERC-721: Nonfungible token standard,” Ethereum Improvement Proposals, no. 721, 2018, https://eips.ethereum.org/EIPS/eip-721. [9] R. Bloemen, L. Logvinov, and J. Evans, “EIP-712: Typed structured data hashing and signing,” Ethereum Improvement Proposals, no. 712, 2017, https://eips.ethereum.org/EIPS/eip-712. [10] K. Oda, Y. Mizukami, and H. Nozaki, “Data distribution system, data distribution device, data distribution program, and data distribution method,” Japanese Patent JP 7894573 B2, 2026, filed Sep. 14, 2022; published as application JP 2023-43186 A, Mar. 28, 2023; granted Jul. 15, 2026. [11] I. J. Cox, J. Kilian, F. T. Leighton, and T. Shamoon, “Secure spread spectrum watermarking for multimedia,” IEEE Transactions on Image Processing, vol. 6, no. 12, pp. 1673–1687, 1997. [12] D. Boneh and J. Shaw, “Collusion-secure fingerprinting for digital data,” IEEE Transactions on Information Theory, vol. 44, no. 5, pp. 1897– 1905, 1998. [13] G. Tardos, “Optimal probabilistic fingerprint codes,” Journal of the ACM, vol. 55, no. 2, pp. 10:1–10:24, 2008.

[14] Q. Wang, R. Li, Q. Wang, and S. Chen, “Non-fungible token (NFT): Overview, evaluation, opportunities and challenges,” arXiv preprint arXiv:2105.07447, 2021. [15] D. Chirtoaca, J. Ellul, and G. Azzopardi, “A framework for creating deployable smart contracts for non-fungible tokens on the Ethereum blockchain,” in Proc. 2nd IEEE Int. Conf. Decentralized Applications and Infrastructures (DAPPS), 2020, pp. 100–105. [16] T. Gebru, J. Morgenstern, B. Vecchione, J. W. Vaughan, H. Wallach, H. Daumé III, and K. Crawford, “Datasheets for datasets,” Communications of the ACM, vol. 64, no. 12, pp. 86–92, 2021. [17] M. Mitchell, S. Wu, A. Zaldivar, P. Barnes, L. Vasserman, B. Hutchinson, E. Spitzer, I. D. Raji, and T. Gebru, “Model cards for model reporting,” in Proc. ACM Conf. Fairness, Accountability, and Transparency (FAT*), 2019, pp. 220–229. [18] S. K. Lo, Y. Liu, Q. Lu, C. Wang, X. Xu, H.-Y. Paik, and L. Zhu, “Toward trustworthy AI: Blockchain-based architecture design for accountability and fairness of federated learning systems,” IEEE Internet of Things Journal, vol. 10, no. 4, pp. 3276–3284, 2023. [19] A. Ouaddah, A. Abou Elkalam, and A. Ait Ouahman, “FairAccess: A new blockchain-based access control framework for the internet of things,” Security and Communication Networks, vol. 9, no. 18, pp. 5943– 5964, 2016. [20] Y. Zhang, S. Kasahara, Y. Shen, X. Jiang, and J. Wan, “Smart contractbased access control for the internet of things,” IEEE Internet of Things Journal, vol. 6, no. 2, pp. 1594–1605, 2019. [21] D. Di Francesco Maesa, P. Mori, and L. Ricci, “A blockchain based approach for the definition of auditable access control systems,” Computers & Security, vol. 84, pp. 93–119, 2019. [22] H. Shafagh, L. Burkhalter, S. Ratnasamy, and A. Hithnawi, “Droplet: Decentralized authorization and access control for encrypted data streams,” in Proc. 29th USENIX Security Symposium, 2020, pp. 2469– 2486. [23] J. T. Brassil, S. Low, N. F. Maxemchuk, and L. O’Gorman, “Electronic marking and identification techniques to discourage document copying,” IEEE Journal on Selected Areas in Communications, vol. 13, no. 8, pp. 1495–1504, 1995. [24] R. Agrawal and J. Kiernan, “Watermarking relational databases,” in Proc. 28th Int. Conf. Very Large Data Bases (VLDB), 2002, pp. 155– 166. [25] Y. Li, V. Swarup, and S. Jajodia, “Fingerprinting relational databases: Schemes and specialties,” IEEE Transactions on Dependable and Secure Computing, vol. 2, no. 1, pp. 34–45, 2005. [26] A. Abubahia and M. Cocea, “Advancements in GIS map copyright protection schemes – a critical review,” Multimedia Tools and Applications, vol. 76, pp. 12 205–12 231, 2017. [27] A. Sablayrolles, M. Douze, C. Schmid, and H. Jégou, “Radioactive data: Tracing through training,” in Proc. 37th Int. Conf. Machine Learning (ICML), 2020, pp. 8326–8335. [28] P. Papadimitriou and H. Garcia-Molina, “Data leakage detection,” IEEE Transactions on Knowledge and Data Engineering, vol. 23, no. 1, pp. 51–63, 2011. [29] A. Havelange, M. Dumontier, B. Wouters, J. Linde, D. Townend, A. Riedl, and V. Urovi, “LUCE: A blockchain solution for monitoring data license accountability and compliance,” arXiv preprint arXiv:1908.02287, 2019. [30] W. N. Probst, “How emerging data technologies can increase trust and transparency in fisheries,” ICES Journal of Marine Science, vol. 77, no. 4, pp. 1286–1294, 2020. [31] N. Alsharabi, J. Ktari, T. Frikha, A. Alayba, A. J. Alzahrani, A. Jadi, and H. Hamam, “Using blockchain and AI technologies for sustainable, biodiverse, and transparent fisheries of the future,” Journal of Cloud Computing, vol. 13, no. 1, p. 135, 2024. [32] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum Yellow Paper, 2014.

Record · ID 667925 · SHA-256 9caaec7a1e04a3a8
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.