There is a reference Newtonian real-time t
.
No process has direct access to this reference time, used only for specification purposes. The reference real-time is assumed to be aligned with the Coordinated Universal Time (UTC).
Processes are assumed to be equipped with synchronized clocks, aligned with the Coordinated Universal Time (UTC).
This requires processes to periodically synchronize their local clocks with an external and trusted source of the time (e.g. NTP servers). Each synchronization cycle aligns the process local clock with the external source of time, making it a fairly accurate source of real time. The periodic (re)synchronization aims to correct the drift of local clocks, which tend to pace slightly faster or slower than the real time.
To avoid an excessive level detail in the parameters and guarantees of
synchronized clocks, we adopt a single system parameter PRECISION
to
encapsulate the potential inaccuracy of the synchronization mechanisms,
and drifts of local clocks from real time.
There exists a system parameter PRECISION
, such that
for any two processes p
and q
, with local clocks C_p
and C_q
:
p
and q
are equipped with synchronized clocks,
then for any real-time t
we have |C_p(t) - C_q(t)| <= PRECISION
.PRECISION
thus bounds the difference on the times simultaneously read by processes
from their local clocks, so that their clocks can be considered synchronized.
A second relevant clock parameter is accuracy, which binds the values read by processes from their clocks to real time.
For the sake of completeness, we define a parameter ACCURACY
such that:
t
there is at least one correct process p
which clock marks
C_p(t)
with |C_p(t) - t| <= ACCURACY
.As a consequence, applying the definition of PRECISION
, we have:
t
the synchronized clock of any correct process p
marks
C_p(t)
with |C_p(t) - t| <= ACCURACY + PRECISION
.The reason for not adopting ACCURACY
as a system parameter is the assumption
that PRECISION >> ACCURACY
.
This allows us to consider, for practical purposes, that the PRECISION
system
parameter embodies the ACCURACY
model parameter.
The assumption that processes have access to synchronized clocks ensures that proposal times assigned by correct processes have a bounded relation with the real time. It is not enough, however, to identify (and reject) proposal times proposed by Byzantine processes.
To properly evaluate whether the time assigned to a proposal is consistent with the real time, we need some information regarding the time it takes for a message carrying a proposal to reach all its (correct) destinations. More precisely, the maximum delay for delivering a proposal to its destinations allows defining a lower bound, a minimum time that a correct process assigns to proposal. While minimum delay for delivering a proposal to a destination allows defining an upper bound, the maximum time assigned to a proposal.
There exists a system parameter MSGDELAY
for end-to-end delays of proposal messages,
such for any two correct processes p
and q
:
p
sends a proposal message m
at real time t
and q
receives m
at
real time t'
, then t <= t' <= t' + MSGDELAY
.Notice that, as a system parameter, MSGDELAY
should be observed for any
proposal message broadcast by correct processes: it is a worst-case parameter.
As message delays depends on the message size, the above requirement implicitly
indicates that the size of proposal messages is either fixed or upper bounded.
In this section we define the properties of Tendermint consensus (cf. the arXiv paper) in this system model.
A proposer proposes a consensus value v
that includes a proposal time
v.time
.
We then restrict the allowed decisions along the following lines:
v
.This implies that no two correct processes decide on different proposal times
v.time
.
v
, then v
satisfies a
predefined valid
predicate.With respect to PBTS, the valid
predicate requires proposal times to be
monotonic over heights of
consensus:
v
at the height h
of consensus,
thus setting decision[h] = v
, then v.time > decision[h'].time
for all
previous heights h' < h
.The monotonicity of proposal times, and external validity in general, implicitly assumes that heights of consensus are executed in order.
v
, then the proposal
time v.time
was considered timely
by at least one correct process.PBTS introduces a timely
predicate that restricts the allowed decisions based
on the proposal time v.time
associated with a proposed value v
.
As a synchronous predicate, the time at which it is evaluated impacts on
whether a process accepts or reject a proposal time.
For this reason, the Time-Validity property refers to the previous evaluation
of the timely
predicate, detailed in the following section.
For PBTS, a proposal
is a tuple (v, v.time, v.round)
, where:
v
is the proposed value;v.time
is the associated proposal time;v.round
is the round at which v
was first proposed.We include the proposal round v.round
in the proposal definition because a
value v
and its associated proposal time v.time
can be proposed in multiple
rounds, but the evaluation of the timely
predicate is only relevant at round
v.round
.
Considering the algorithm in the arXiv paper, a new proposal is produced by the
getValue()
method, invoked by the proposerp
of roundround_p
when starting its proposing round with a nilvalidValue_p
.The first round at which a value
v
is proposed is then the round at which the proposal forv
was produced, and broadcast in aPROPOSAL
message withvr = -1
.
The timely
predicate is evaluated when a process receives a proposal.
More precisely, let p
be a correct process:
receiveTime_p[r]
is the time p
reads from its local clock when p
is at
round r
and receives the proposal of round r
.The proposal (v, v.time, v.round)
is considered timely
by a correct process
p
if:
receiveTime_p[v.round]
is set, andreceiveTime_p[v.round] >= v.time - PRECISION
, andreceiveTime_p[v.round] <= v.time + MSGDELAY + PRECISION
.A correct process at round v.round
only sends a PREVOTE
for v
if the
associated proposal time v.time
is considered timely
.
Considering the algorithm in the arXiv paper, the
timely
predicate is evaluated by a processp
when it receives a validPROPOSAL
message from the proposer of the current roundround_p
withvr = -1
.
A Proof-of-Lock is a set of PREVOTE
messages of round of consensus for the
same value from processes whose cumulative voting power is at least 2f + 1
.
We denote as POL(v,r)
a proof-of-lock of value v
at round r
.
For PBTS, we are particularly interested in the POL(v,v.round)
produced in
the round v.round
at which a value v
was first proposed.
We call it a timely proof-of-lock for v
because it can only be observed
if at least one correct process considered it timely
:
If
POL(v,r)
with r = v.round
, andPOL(v,v.round)
contains a PREVOTE
message from at least one correct process,Then, let p
is a such correct process:
p
received a PROPOSAL
message of round v.round
, andPROPOSAL
message contained a proposal (v, v.time, v.round)
, andp
was in round v.round
and evaluated the proposal time v.time
as timely
.The existence of a such correct process p
is guaranteed provided that the
voting power of Byzantine processes is bounded by 2f
.
The existence of POL(v,r)
is a requirement for the decision of v
at round
r
of consensus.
At the same time, the Time-Validity property establishes that if v
is decided
then a timely proof-of-lock POL(v,v.round)
must have been produced.
So, we need to demonstrate here that any valid POL(v,r)
is either a timely
proof-of-lock or it is derived from a timely proof-of-lock:
If
POL(v,r)
, andPOL(v,r)
contains a PREVOTE
message from at least one correct process,Then
POL(v,v.round)
with v.round <= r
which is a timely proof-of-lock.The above relation is trivially observed when r = v.round
, as POL(v,r)
must
be a timely proof-of-lock.
Notice that we cannot have r < v.round
, as v.round
is defined as the first
round at which v
was proposed.
For r > v.round
we need to demonstrate that if there is a valid POL(v,r)
,
then a timely POL(v,v.round)
was previously obtained.
We observe that a condition for observing a POL(v,r)
is the proposer of round
r
having broadcast a PROPOSAL
message for v
.
As r > v.round
, we can affirm that v
was not produced in round r
.
So v
was, by the protocol operation, the highest valid value known by the
proposer when it started the round.
A value v
becomes a valid value when there is POL(v,vr)
with vr < r'
.
Even though the proposer p
can be incorrect, the fact of a POL(v,r)
was
produced ensures that at least one correct process also observed a POL(v,vr)
.
Considering the algorithm in the arXiv paper,
v
was proposed by the proposerp
of roundround_p
because itsvalidValue_p
variable was set tov
.The broadcast
PROPOSAL
message, in this case, has itsvr > -1
, which can only be accepted by processes that observed aPOL(v, vr)
.
So, if there is a POL(v,r)
with r > v.round
, then there is a valid
POL(v,vr)
with v.round <= vr < r
.
From this point, the reasoning becomes recursive: either vr == v.round
and
POL(v,vr)
is a timely proof-of-lock, or there is another POL(v,vr')
with
vr' < vr
, recursively leading to the first scenario (as vr
necessarily
decreases at each recursive iteration).
The safety of the algorithm requires a timely proof-of-lock for a decided value, either directly evaluated by a correct process, or indirectly received through a derived proof-of-lock.
If
C
for height k
and round r
, andC
contains a PRECOMMIT
message from at least one correct processThen, where p
is one such correct process:
p
is correct, p
received a valid POL(v,r)
, andPOL(v,r)
contains a PREVOTE
message from at least one correct process, andPOL(v,r)
is derived from a timely POL(v,r*)
with r* <= r
, andPOL(v,r*)
contains a PREVOTE
message from at least one correct process, andv
timely
at round r*
.In terms of liveness, we need to ensure that a proposal broadcast by a correct process
will be considered timely
by any correct process that is ready to accept that proposal.
So, if:
p
of a round r
is correct,POL(v',r')
for any value v'
and any round r' < r
,p
proposes a valid value v
and sets v.time
to the time it reads from its local clock,Then let q
be a correct process that receives p
's proposal, we have:
q
receives p
's proposal after its clock reads v.time - PRECISION
, andq
is at or joins round r
while p
's proposal is being transmitted,
then q
receives p
's proposal before its clock reads v.time + MSGDELAY + PRECISION
Note that, before
GST
, we cannot ensure that every correct process receivesp
's proposals, nor that it does it while ready to accept a roundr
proposal.
A correct process q
as above defined must then consider p
's proposal timely
.
It will then broadcast a PREVOTE
message for v
at round r
,
thus enabling, from the Time-Validity point of view, v
to be eventually decided.
MSGDELAY
sThe liveness assumptions of PBTS are conditioned by a conservative and clever
choice of the timing parameters, specially of MSGDELAY
.
In fact, if the transmission delay for a message carrying a proposal is wrongly
estimated, correct processes may never consider a valid proposal as timely
.
To circumvent this liveness issue, which could result from a misconfiguration,
we assume that the MSGDELAY
parameter can be increased as rounds do not
succeed on deciding a value, possibly because no proposal is considered
timely
by enough processes.
The precise behavior for this workaround is under discussion.
Back to main document.