Gas Cost of Storing an Audit Trail On-Chain
A team is building a provenance registry for a supply-chain pilot on Ethereum mainnet. Each product batch writes a record containing a 32-byte batch ID, a 20-byte manufacturer address, a 32-byte document hash, an 8-byte timestamp, and a variable-length UTF-8 note averaging 120 bytes. They expect 40,000 batches in the first year and want every record queryable by any external auditor without trusting the team's servers. A junior developer proposes storing the full note string in a struct array and emitting an event as a redundant backup. The finance lead is alarmed because a prior prototype cost roughly 0.004 ETH per record at 20 gwei. The team asks you to review the design before the contract is finalized.
1. Evaluate the storage design. What dominates the cost, and what would you change while preserving auditor verifiability?
Read the worked answer
The dominant cost is persistent storage, not computation. Every nonzero storage slot written from zero costs 20,000 gas; the fixed fields (batch ID, address, hash, timestamp) can be packed into two slots if ordered carefully, so roughly 40,000 gas. The 120-byte note spans four slots (32 bytes each) and costs about 80,000 gas on its own, plus array length and offset bookkeeping. Emitting an event as a backup does not reduce storage cost and adds log gas, so it is pure overhead here.
The right move is to separate what must be readable on-chain from what must merely be provable. Store the fixed fields plus a hash of the full note on-chain, and publish the note itself in an event or in calldata to a separate anchoring transaction. Auditors can recompute the hash from the off-chain note and compare it to the stored value, which preserves verifiability without paying for 120 bytes of state per record. If the note genuinely must be readable by contracts, consider storing only a short category code and keeping the prose off-chain. Also avoid writing the same data twice; pick storage or events, not both. Finally, batch writes where the domain allows, since per-transaction overhead (21,000 gas) and slot initialization dominate at this volume.
2. The finance lead wants a per-record cost estimate. Using 20 gwei gas price and assuming ETH at $3,000, roughly what does the current design cost per record, and how does your redesign compare?
Read the worked answer
Work in gas first, then convert. Current design: two slots of fixed data at 20,000 each is 40,000; four note slots is 80,000; array length and offset writes add roughly 40,000 in the worst case of a fresh dynamic array; event logging of ~200 bytes costs roughly 2,000-4,000. Call it ~165,000 gas of execution, plus 21,000 transaction overhead, so ~186,000 gas per record if each record is its own transaction.
At 20 gwei, 186,000 gas is 0.00372 ETH, which at $3,000 is about $11.16 per record. For 40,000 records that is roughly $446,000 in year one - clearly unsustainable for a pilot.
Redesign: fixed fields in two packed slots (40,000) plus one hash slot (20,000) plus a short event (~2,000), so ~62,000 execution plus 21,000 overhead, ~83,000 gas. At 20 gwei that is 0.00166 ETH, about $4.98 per record, or roughly $199,000 for 40,000 records. Batching many records per transaction removes most of the 21,000 overhead and pushes the marginal cost toward the ~62,000 execution figure, roughly $3.72 per record. The key point for the exam is to show the arithmetic and the reasoning about which components shrink, not to hit an exact number.