New Event Tree and Extended LOG Discussion

[SergioDemianLerner]

The receipt trie is not well suited for lightweight wallets to use, therefore a new data structure that reduce the stress on light clients is needed. This RSKIP introduces the Event trie structure, whose root is committed in the block header. The Event Trie is organized such that the keys are contract addresses, and each data element is itself a trie of logged events. The key of each second level trie entry is the log sequential number, and the payload is a RLP-encoded list of the list of topics, the LOG data, and the transaction index originating the log event.

To log events in the new events trie, we propose the use of the same LOG opcode. Creating still another opcode seems not to be necessary and reduces compatibility with existent compilers. Also the same arguments would be required for the new LOG and the old LOG opcode, which consumes 4 byte addresses, one for each number of arguments. Therefore adding a new LOG opcode would consume for additional addresses, which seem excessive. It was decided to use the same LOG opcodes in an "extended mode". Two methods to switch to the extended mode were evaluated.

1. Use a specific topic (e.g. 0xff..ff), to log the same message in the two different trees.

2. Switch to a new extended mode by other means using a previous code sequence, and then using the LOG event in the traditional way.

The last option was chosen because the first present some compatibility problems, duplicates the amount of information logged at the same cost (LOG cost cannot be increased without breaking the 2300 minimum gas sent barrier).

To be as compatible as possible with Ethereum, we allow the VM to switch between old LOG mode and new LOG extended mode using the internal configuration register (COREG). This register is 32 bytes long, and is memory mapped. The description and reasons why we used a memory mapped register are described in [RSKIP51]. A single bit in the COREG changes the mode of LOG.

When transactions are processed in parallel (See [RSKIP03]), the order in which the logged items are stored should still be deterministic. Generally each transaction that modifies its state belongs to a single verification thread, therefore all transactions that use the new mode of the LOG opcode will belong to the same thread and so the order of logged events is deterministic.

However a contract that does not modify its state but logs information could be called from different threads. In this case a sequential log index does not work as key to the events trie. We could use as key the transaction index plus a sequential value which starts from zero on each new transaction. However, for simplicity, we decided using only a sequential number and force sequential processing of transactions in the cases of extended-mode LOGs without state modification. This is also because the new LOG mode modifies the account state, as follows.

To allow light clients to follow the list of events created by a contract, a new field is added to each account/contract: blockNumberOfLastEvent. This field is updated each time the contract emits a LOG in extended mode, with the current block number. The initial value of this field is zero. Light clients can use this field to skip to the previous emitted LOG each time they detect a new LOG, and therefore process the list of all logged items in reverse.

An alternate design is that each logged event key be a sequential number that does not reset on each block, but continues. The account state would store the sequential number of the las event logged. This design was not chosen, as it consumes more space, bringing little benefit.

To allow logging the previous value of blockNumberOfLastEvent before the LOG command is executed, a new opcode is added: LASTEVENTBLOCKNUMBER. This opcode pushes into the stack the value of the blockNumberOfLastEvent field. This way light wallets can log this value, and light clients can learn the block number of the previous logged event when they access any logged event.