Does anybody really know what time it is?

[victorshoup]

In the quest to make the properties of the inclusion phase more of an "abstract API", I'm trying to understand what the counter properties really are. By "counter", I'm referring both to timestamps and inbox indices -- they both have similar properties and requirements. From the point of view if the inclusion phase, these are just abstract counters that are supplied to the inclusion phase by the other phases.

Currently, we say: The consensus timestamp is both: Less than or equal to the timestamp submitted to the current round by some honest party, and Greater than or equal to the timestamp submitted to the current round or some previous round by some honest party.

The question is, when we say "the timestamp submitted to the current round by some honest party", what does that really mean? In particular, thinking about this as a contract between the inclusion phase and the other phases, what are we saying? I mean, as far as the other phases are concerned what is the importance of "the time at which a tx is submitted to the current round"?

I would like to move the logic of "tx/bundle induction" (i.e., receipt from external parties) and "tx gossipping" into the inclusion phase. So we can talk about the time at which a tx is inducted, either directly (from an external user) or via gossip. However, we cannot talk about the "the time at which a tx is submitted to the current round" --- that is a reference to an implementation detail of inclusion phase that I would prefer is not a part of the spec.

First, maybe it would help to distinguish between the "adjusted consensus timespamp" and the "raw consensus timestamp" -- the latter is computed by the median, and the former is computed from the latter by taking a MAX to ensure monotoncity. Let's focus in the raw consensus timestamp.

So I think we can say the following: Consider a raw consensus timestamp T in round R. What property can we state that is independent of a particular implementation, but is useful and also can be easily implemented? We can say this, for example: there exists an honest party P such that at some some point in time prior to P seeing a round R output, P's local timestamp was at most (at least) T.

That's probably not enough... There also has to be a relationship between these timestamps and the tx's in the output inclusion lists.

Maybe we also have to bake into the spec the "waiting room" logic, so we can say that a party inducts a tx at a certain time and it becomes "eligible" at some later time. So we can say that if a nonpriority tx was included in round R, then it must have been an eligible tx for at least one honest party at some point in time before any party sees a consensus output for round R. We can also say that if a tx was eligible for one honest party some some time, then it will be eligible for all honest parties within some bounded amount of time (in periods of synchrony, at least). So we can also say that during periods of synchrony, these timestamps have some useful meaning.

I'm rambling here...but what I'm trying to do is think about properties that should hold with respect to well defined events, such as (1) when a tx is seen (inducted) by some honest party, (2) when a tx is eligible for some honest party, (3) when a consensus output for a given round is seen by some honest party.

[edfelten]

I tried to address these points in the current (updated) version of the spec.