Logical Time

Logical time is a concept on which the guarantees of delivery order are based. It has nothing to do with regular time, it is simply a way to unambiguously determine the order of message delivery.

We will start with the master block. Its logical time is always at least 1,000,000 as much as the logical time of the previous master block. This is done to guarantee that the LT of the following master block is higher than the entities dependent on it. Next:

* The LT of the block of the processing thread will always equal the LT of the master block to which the thread in question links (the last block imported by the thread) + 1,000,000. * The LT of the transaction will always be equal to MAX(the LT of the block, the LT of the incoming message, the LT of the previous account transaction, the LT of the last message created by the account) + 1. * The LT of the message is MAX(the LT of transaction, the LT of previous account message created in this transaction) + 1.

When the validator creates a candidate block, it relies on the list of rules that other validators use to check the validity of the block:

• The block collator knows for sure which messages are in outgoing queues of other threads at the moment of the last master block imported by them. This is because each time the validator imports a new master block, they have to download all the blocks of other threads registered in it and update queue states (add new messages and delete processed ones).
• The collator must import messages to its incoming queue only in the order of LT increase.
• If the LTs of two messages are equal, the one with a lesser HASH is imported.
• When the collator imports a message, it executes it immediately. When the "room" of the block is over, the collator just stops importing messages, and the validators finalize the block.

Interestingly, if a transaction creates a message whose recipient is in the same thread and all the rest of the messages have been processed, this message can be delivered in the same block.

And if there are two incoming messages in two different accounts, their LT is not dependent on each other and can even be equal.

This may sound complicated, but if you spend some time with a pen and a sheet of paper, you can quickly grasp the logic.

Some real-life examples:

If one smart contract sends two messages to another smart contract, they will be delivered strictly in the order of sending, and regardless of whether they are sent from one or multiple transactions. This is because the LT of the second message is always higher than that of the first.

A more complicated example. Here contract С will receive a guaranteed message from contract A and earlier than one from contract B, provided messages 1 and 2 were sent from one transaction and message 1 was sent earlier than message 2 in the contract code. This example is complicated by the fact that the contracts may be located differently: in one, two, or three threads.

The LT of message 3 is guaranteed to be higher than that of message 2, and the processing thread where contract С is stored cannot see message 3 without seeing message 1.

Some more examples where the order is not guaranteed:

In the following example, we do not know in which order account D will receive messages because, in the worst case scenario, all four contracts are in different threads and we do not know the load in threads B and C or the time in which they will be able to process our message. Thread B may include your message either in the next block or after N blocks in case it has a large message queue for processing.

It is best to expect delivery order only for two contracts. At most, you can expect some degree of order in the system of three contracts, mainly because contracts may live in different threads which process messages at different speeds.