As stated in the yellow paper:
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 information from concerning its execution. Each receipt, denoted BR[i] for the ith transaction) is placed in an index-keyed trie and the root recorded in the header as He.
The transaction receipt is a tuple of four items comprising the post-transaction state, R, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, Ru, the set of logs created through execution of the transaction, Rl and the Bloom filter composed from information in those logs, Rb:
R = (R;Ru;Rb;Rl)
Can anyone give more details of how this
Rl (logs) is structured and how the
Rb (bloom filters) are constructed from it?
I've been doing some research about bloom filters and Broder and Mitzenmacher state that:
Wherever a list or set is used, and space is at a premium, consider using a Bloom filter if the effect of false positives can be mitigated.
So how does this relates to Ethereum's design rational?