PBTS: spec reorganization, summary of changes on README.md

[cason]

No description provided.

[josef-widder]

Looks great. Thanks. I just left two text suggestions to clarify the context a bit.

[williambanfield]

Some nits, but nothing major. A general question: Is there a value to keeping the old versions and drafts in the repo? They are accessible via the git history and, in my view the clutter the repository, making it a bit unclear. Additionally, is there a reason to continue using the _draft suffix for these files? As far as I can tell, this is no longer a draft.

[williambanfield]

Not sure I understand why this is true. If f of the voting power is controlled by byzantine validators, couldn't they shift the median by generating faulty timestamps?

[cason]

The point here is: if Byzantine validators produce timestamps in the past (or the future), when the 2f + 1 timestamps are ordered, the f+1th timestamp will not be in the past (or future).

[williambanfield]

this is linked right below, do we need to link it here as well?

[cason]

No, ehehhe.

[cason]

Some nits, but nothing major. A general question: Is there a value to keeping the old versions and drafts in the repo? They are accessible via the git history and, in my view the clutter the repository, making it a bit unclear. Additionally, is there a reason to continue using the _draft suffix for these files? As far as I can tell, this is no longer a draft.

I agree, I would remove the _draft suffix after the next round of reviews.

[josef-widder]

Let's use the suffix _reviewed then.

[sergio-mena]

Folks, these are my notes while reading the PBTS spec before the meeting. So some of those comments are now obsolete after the discussion and clarifications. Still, I think those have some value in the sense those were the questions I had by just reading the spec and having little context on what PBTS is.

Don't hesitate to come back to me if something is not clear.

• Overall comments:

  • What happens if MSGDELAY is too big? From the text, I understand it won't be corrected; but then doesn't it become too flexible for the whole lifetime of the system?

    More precisely, when discussing the properties (liveness in particular), references to "good periods" or "bad periods" are not included in the properties' definitions, albeit one reference to GST in a note. It gives the impression that the algorithm assumes a (somewhat) synchronous system (at least w.r.t. message delays). But then we have that timing assumptions affect safety

  • What if "synchronized clocks" assumption is broken in the following way: 2/3+ processes temporarily (a glitch?) produce a block far in the future. Then their clocks become synchronous. How do we recover from this?
    In other words: isn't it dangerous to assume "synchronized clocks" as a safety assumption?

    An idea: add a parameter "offset" to the implementation, so that a process's clock way in the past can still participate. [Note after the meeting: I see now that this may defeat the purpose of the check for MSGDELAY]

  • "Derived POL" concept is not totally clear to me after going through the problem statement. Maybe we can discuss about it.

• README.md

  • Time-validitty <--> "timely predicate". Probably best to refer to it consistently

• System model

  • PBTS-MSG-D.0: ts and t are used together in the inequality, aren't we mixing up real and measured time?
  • Timely Proof-of-Locks: (very minor) the initial definition should include the height to be non-ambiguous
  • PBTS-TIMELY-POL.1: the third condition follows from the definition of POL(v,r)
  • I'm confused by the definition of POL(v,r). "There exists", yes but what if all those PREVOTE messages are delayed for a long long time?
  • POLRound is not defined in the text
  • PBTS-DERIVED-POL.1:
    • the second condition follows from the definition of POL(v,r)
    • shouldn't you define r* as you did in PBTS-TIMELY-POL.1 ?

• Protocol Specification

  • "when it becomes locked by the network": I'm bewildered by this sentence. The fact that the proposer receives 2/3+ prevotes does not make the value locked across the network... only at the proposer
  • PBTS-ALG-UPON-PROP.1: Although adding timely in the Upon's guard is correct, wouldn't it be more efficient (and maybe easier to understand) to add it in the "if"? Since we already received an untimely proposal, it's pointless to keep on waiting in this step as no other proposal is supposed to come.
  • Rules at Lines 28 - 33 remain unchanged: "... at least f + 1 processes judged v as timely". Shouldn't it read "... at least f+1 correct processes..." ?

• Editorial

  • s/interest is to possibility of/interest is the possibility of/
  • s/when adjusted by the clocks/when adjusted by the clocks'/
  • s/cycle aligns the process local clock/cycle aligns the process' local clock/
  • s/is a process is equipped/is a process equipped/
  • s/be time a process/be the time a process/
  • s/do not simultaneous read/do not simultaneously read/
  • s/behind of the clock/behind the clock
  • s/has not being updated/has not been updated/
  • s/other rules remains unchanged/other rules remain unchanged/

[cason]

A brief point here, before going further on @sergio-mena comments.

Yes, we assume a synchronous system with respect to the propagation of Proposal messages, which carry (in particular) the timestamp of a block. Moreover, the timestamp are generated from clocks that are assumed to be synchronized (all the times, again, a synchronous assumption).

While I do agree those are strong assumptions, they don't affect safety. The non-observance of the synchronous assumptions jeopardize liveness, as blocks will be arbitrarily rejected. Two blocks are not decided under any timing behavior, that is, even if (most) clocks are not synchronized and proposals take more than MSGDELAY to be delivered.

[sergio-mena]

Thanks @cason for clarifying. It makes sense to me. We can keep safety out of the discussion.