Can we assume that Ethereum Events (aka Logs) are in-sequence

Question

Lets consider a simple Contract that is to track a variable. A client App needs to access this variable's history to show a graph.

I can create an Array inside the Contract, and push() the value anytime, like the following (untested code):

contract Price {
    uint[] public priceHistory;
    function logPrice(uint price) public {
        priceHistory.push(price);
    }
}

Perhaps a cheaper and better option is to emit Events, similar to the following:

contract Price {
    event PriceChanged(uint price);
    function logPrice(uint price) public {
       emit PriceChanged(price);
    }
}

As per (3) a cheaper form of storage, the second approach is low cost. My question is, can we assume, reliably, that the logs will be written in time order (so that we can reconstruct a history from them).

The next question is, if this Contract calls other Contracts, which follow the same design pattern (all storage is in logs), how can we weave together a history with proper time-ordering? ie, establishing ClientApp -> ContractA - ContractB -> ContractC from reading Event logs for all the three Contracts.

One thought could be to pass-on transaction-hash from the first user -> contract call, and pass it all the way to subsequent contract -> contract calls.

If this were a monolithic system, timestamp could have helped. But since its a distributed system, I wonder how do we establish the notion of a sequence here?

Answer 1

Yes, but with some nuances so the guarantees are well understood.

Event log entries are part of the transactions in blocks. As such, you can reason about event sequence assurances with the same principles you would use to reason about transaction order. They will arrive in the same order as the transactions mine.

The idea of using event logs as inexpensive storage is sometimes called a "stateless" pattern. The main caveat is that such entries are not (easily) accessible for contract logic.

I'm not 100% sure what this means:

ClientApp -> ContractA -> ContractB -> ContractC

1. If the client app makes three calls to three contracts, no assurance of the order, because mining will decide.
2. If the client calls ContractA which then calls ContractB which in turn calls ContractC then it is deterministic and you can have it in the order the functions were called, or in the reverse order depending on how you write the contract functions.

If you habitually place the event emitter first, then you get "ready(a), aim(b), fire(c). All three events arrive with the confirmed transaction, in that order.

emit LogReady(...
contractB.aim(...

If you put the contract call before the event, then you get fire(c), ready(b), aim(a), in that order when the mined transaction arrives.

contractB.aim(...
emit LogReady(...

The second way is more intuitive - first do stuff, then log what you did. It results in peculiar (reverse order) logs for long chains of functions. The first way is not so intuitive but it yields a nice sequence regardless of how many separate event LogName() logs are involved.

Hope it helps.

Answer 2

Events are guaranteed to be in the same sequence that of transactions. (there is some randomness in order of transactions due to the way transactions are selected for mining by nodes)

Transactions are ordered

1. By the blocks these are part of
2. Transaction sequence within a block

You you can

1. Scan for all blocks and transactions within the blocks
2. Find events emitted by each transaction

Code for this is provided in following thread : web3: How do I get past events of myContract.myEvent?