Problem
Every event writes an EventLog (and usually a Transaction). They're immutable (good), but each write carries avoidable weight:
eventLog.data is a hand-built JSON string (e.g. the challenges loop in subgraph/src/pdp-verifier.ts:605-613) — arbitrary-precision toString() calls per event, stored as text that duplicates on-chain data.- Duplicated fields:
EventLog.transactionHash duplicates the id prefix, Transaction.hash duplicates the id, setId/dataSetId duplicate the proofSet relation.
DataSet.totalEventLogs / totalTransactions counters are updated in every handler, widening the hottest mutable row.
The client does query transactions and eventLogs (subgraph-clien utility/queries.ts:185,197), so these entities stay — this issue is about shrinking them, not removing them.
Proposal
- Audit which
EventLog/Transaction fields and which DataSet counters the UI actually renders; drop the rest (data JSON is the main candidate — the name + linked entities may already cover the UI's needs).
- Where
data is genuinely displayed, consider keeping only the minimal fields the UI formats, rather than pre-rendered JSON. OR completely eliminate data field and redirect users to block-explorer where contract is verified to see data.
Acceptance criteria
Problem
Every event writes an
EventLog(and usually aTransaction). They're immutable (good), but each write carries avoidable weight:eventLog.datais a hand-built JSON string (e.g. the challenges loop insubgraph/src/pdp-verifier.ts:605-613) — arbitrary-precisiontoString()calls per event, stored as text that duplicates on-chain data.EventLog.transactionHashduplicates the id prefix,Transaction.hashduplicates the id,setId/dataSetIdduplicate theproofSetrelation.DataSet.totalEventLogs/totalTransactionscounters are updated in every handler, widening the hottest mutable row.The client does query
transactionsandeventLogs(subgraph-clienutility/queries.ts:185,197), so these entities stay — this issue is about shrinking them, not removing them.Proposal
EventLog/Transactionfields and whichDataSetcounters the UI actually renders; drop the rest (dataJSON is the main candidate — the name + linked entities may already cover the UI's needs).datais genuinely displayed, consider keeping only the minimal fields the UI formats, rather than pre-rendered JSON. OR completely eliminatedatafield and redirect users to block-explorer where contract is verified to seedata.Acceptance criteria
schema.graphql+ mappings; client queries updated