Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
The yellow paper says:
Transaction Receipt. In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain in- formation from its execution.
Why isn't this information stored in the transaction itself? that way one can save one more field in the block header. So what was the design philosophy behind that?
Because transactions are identified by their hashes. Transaction hash is calculated on all the fields of the transaction. After transaction is signed, you can't modify it without changing the hash, and if you do that before it is mined, the network takes it as a different transaction.
When a transaction creates a contract, the contract address is stored in the Receipt. How would you add this data to the transaction struct without changing its hash? You couldn't. The only way to seal the result of the transaction is to create another struct and store it there. This is what Receipts are, its the output of the transaction, a very different concept, while Transaction data being the input.
In short, the decision to design things this way was correct.
BTW, transactions are not stored in the block header, transactions are stored in a separate trie. Only the hash of all transactions of the block is kept in the header.
