This EIP describes how to change the on-chain receipt data to track gas per transaction instead of cumulatively.
Currently, on-chain receipts track a cumulativeGasUsed field which contains the running sum of all gas spent for all transactions in the block so far. This has a number of shortcomings:
Inefficient verification: RPC clients that want to verify individual transaction gasUsed requires computation based on cumulativeGasUsed across consecutive receipts.
Limited parallelism: Receipt contents are stateful, even for transactions accessing mutually exclusive state.
The logIndex field exposed via JSON-RPC is currently also tracking an incremental block level index instead of a per-receipt index, with similar shortcomings.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Receipt constructionAll receipts emitted after this EIP activates track the individual transaction's gasUsed instead of the incremental cumulativeGasUsed value.
Within logs, the logIndex field is changed to indicate the log index position in the individual receipt, rather than in the entire block.
This EIP is a step towards aligning on-chain data with the RPC data actually being consumed by client applications. Stateful components of receipts (cumulativeGasUsed / logIndex) are replaced with per-transaction equivalents.
Applications using verified gasUsed / cumulativeGasUsed values need to adapt to the new on-chain data semantics.
Applications relying on the per block logIndex need adaptation, as logIndex now refers to an index per receipt. Note that this is solely an RPC change. Relative log ordering can be emulated by estimating logIndex as transactionIndex * 4 + logIndex (guaranteed to have same order as before, but absolute index values may be higher than before).
None
Copyright and related rights waived via CC0.