Conversation
Introduce `EEVM.Receipt` — the post-execution summary that gets folded into a block's receipts trie. Four fields per Yellow Paper §4.3.1: `status`, `cumulative_gas_used`, `logs`, `logs_bloom`. - `new/0` / `new/1` — keyword overrides; supplying `:logs` without an explicit `:logs_bloom` derives the bloom from the logs so the two cannot drift. A caller re-hydrating from RLP can pass `:logs_bloom` directly and skip `:logs`. - `encode/2` — wire form. Default `tx_type: :legacy` produces a plain RLP list `[status, cumulative_gas, bloom, logs]`. Typed variants (`:eip2930` / `:eip1559` / `:eip4844`, or a raw integer byte) prepend the EIP-2718 type byte. Each log encodes as `[address(20B), [topic(32B)...], data]`. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
EEVM.Receiptatlib/eevm/receipt.ex— the post-execution receipt struct (status,cumulative_gas_used,logs,logs_bloom) per Yellow Paper §4.3.1.new/1derives:logs_bloomfrom:logsautomatically so the two can never drift; callers re-hydrating from RLP can pass:logs_bloomdirectly and skip:logs.encode/2produces the wire form. Default is the legacy RLP list[status, cumulative_gas, bloom, logs]; passtx_type: :eip2930 | :eip1559 | :eip4844(or a raw integer byte) to prepend the EIP-2718 type byte. Each log encodes as[address(20B), [topic(32B)...], data].Notes
EEVM.Block.Receiptcarries the same four fields, andEEVM.Block.Processor.encode_receipt/1inlines its own RLP encoding. Once feat: add block-level transaction processor #111 lands, the cleanup is to (a) deleteEEVM.Block.Receiptin favor of this module and (b) replaceProcessor.encode_receipt/1with a call toEEVM.Receipt.encode/2. Keeping that consolidation out of this PR so Implement transaction receipt generation #84 can ship independently.from_transaction_result/2is intentionally absent.EEVM.TransactionResultdoes not exist onmainyet (it's on the in-flight feat: add end-to-end transaction execution pipeline #112 branch), so the wiring is deferred to a follow-up after feat: add end-to-end transaction execution pipeline #112 merges. Today, callers build the receipt withReceipt.new(status: ..., cumulative_gas_used: ..., logs: ...).Closes #84.
Test plan
mix format --check-formattedmix compile --warnings-as-errorsmix credo --strictmix test(570 tests, 0 failures; 13 new intest/receipt_test.exscoveringnew/0,new/1overrides, logs→bloom derivation, legacy + all four typed encoding variants, and bloom membership for emitted logs)🤖 Generated with Claude Code