Historians are in charge of time. The correct order of events is essential for a proper execution of agreements as represented by Expressive Smart Contracts (ESC) and this order of events is recorded in the log produced by Historians.
Time is notoriously difficult to manage if an ESC needs a precise and trustless timestamp. For this reason, we will explore ways to use the concept of time and their impact on the complexity of the resulting ESC using them.
The simplest use of time requires an orderly list of events so that the properties “before” or “after” are natively supported without additional quantitative information about the specific instant when the events actually happened. This model provides a guarantee that the sequence of actions is preserved, barring message collisions in the sampling time window of the Messenger. In this very simple model, quantitative time computation can be carried out only if contracts provide this information client side. As an example, A and B could agree that they have access to and trust in the timing supported by a given blockchain, such as Bitcoin or any other they choose. If so, a blockchain explorer provides them a combination of timestamps and block identifiers. If a player includes this information in the sequence of contract steps, it shows that a message that follows has been assembled later than the timestamp.
Using the example of the chess game, a delay of a move that exceeds a predefined length of time causes the victory of the other party. Hence, it is in the interest of the player who has submitted the last move to keep updating the current time until the other player defaults or sends a new move. In this case, the time elapsed before the new move can be measured with the approximation introduced by the quantization effects of the blockchain. Since both players have the same incentives, they will submit the all timestamps as soon as they are produced.
Another example of client-side time management comes from the insurance industry. When a policy is purchased, it is common practice that the payment activates the coverage starting from the end of day. The interest in time management from the insurance stand point is different. It has the commitment to pay the claims of policies that have not yet expired. Hence, the insurance has interest in providing a timestamp at the end of day so that all claims and payments filed before that timestamp are included in the previous day. This approach leverages the interest of the insurance in not extending the coverage to a time that is not included in the policy.
If a more precise time window were required by the contract, an actor could perform two steps: 1) post the reference to a time associated to a block; all messages following this step are located later in time since the actor had knowledge of the content of a specific time information; and 2) could anchor the event to the selected blockchain. In this way and within the limits of the granularity of the production of blocks, the time associated to an event is coincident to or earlier than the moment of generation of the block providing the anchor. Combining the two strategies, it is possible to define a time window with the granularity limits of the underlying blockchain that defines when the data have been submitted.
At last, there could be cases when the granularity of time provided by these approaches is not satisfactory. In these cases, it is possible to use the internal counter of the TEE to get a short-term measure of time intervals. Again, using the same messaging approach, the inclusion of relative time stamps requires the introduction of a special data that is interpreted by the TEE as a request to include the current value of the time counter. While this method introduces several complexities when the number of Historians is larger than one, it might be useful for special situations otherwise not tractable.
Comments