Talking about height in EC (+ tickets, null blocks, etc)

[sternhenri]

@whyrusleeping @jbenet @ZenGround0 @nicola

The goal here is to explain how EC works as simply as possible, leading to an intuitive explanation with the least nomenclature involved.

Specifically, this issue is focused on how we should explain our current construction (and not on the construction itself) as it pertains to ticket generation and mining on top of losing tickets. In EC, given the use of VDFs, there can be 0, 1 or multiple blocks generated in a round (with a round defined as an attempted block mine, lower bounded by the VDF proof generation time). In that sense, block time is variable (unlike in BTC), though on expectation a block will be mined at every round.

We have explained this in two ways thus far:

1. We talk about mining on top of null blocks.
2. We talk about null or losing tickets.

Both have pros and cons but as came up in a recent conversation with @sa8, the spec as is is still not quite clear. I'd like to try and find the simplest way to explain how things work.

[sternhenri]

My current view:

• We haven't yet found the right solution here but iterating on 2 seems the best way to do this
• losing tickets are strictly better than null blocks given that that explanation works equally well for both lookback or not, and that null blocks makes little sense in the context of lookback parameters
• I expect a couple of visualizations here may get us over the edge.

[sternhenri]

Also pointing you here: https://dahliamalkhi.wordpress.com/2018/04/03/tendermint-in-the-lens-of-bft/

Within the first few paragraphs, this comes up:

Like PBFT, the protocol for deciding on the block at each height is 'view' based, where each view has a dedicated proposer by rotation. In a view, one decision may be reached or none. In Tendermint, a view is called a 'round'. The view is changed if a certain period elapses without progress. When a decision is reached, the engine moves to the next height.

followed by:

This paradigm is standard in the BFT literature, but is very confusing. We can considerably simplify it, because there is no reason to have two counters, one for heights, and one for rounds; and there is no reason to distinguish rounds with decisions from rounds without decisions.

Using the Hot-Stuff framework, we are going to blur in TDRMNT the distinction between heights and views, and use only `levels’. At each level, a proposer needs to choose a branch to extend. If there is no proposal at the preceding level, it regards it as a nil proposal. The proposer may decide to extend the branch with new content or to merely reinforce an undecided branch.

An option for us to consider...

[pooja]

@jbenet We need your input here, thanks!

[sternhenri]

Ouroboros praos discusses these (section 3.3) as active and empty slots.

[sternhenri]

Reading more, I believe slots is the easiest to grok version of this. I vote for that version of the world. Tickets is just a mechanism working atop that.

[EbonyBelle]

Hi All,

@whyrusleeping Why brought this to my attention, Juan hasn't been able to respond, I'm hoping he'll be able to respond at some point tomorrow or at the latest this weekend. Does that sound good?

Thanks!

[pooja]

@EbonyBelle, sounds great. Could you help me nudge @jbenet so we can move forward with this this week?

[jbenet]

Please refer to this as (1), mining on null blocks. (the historical way we have referred to this).

Constraints:

• block time in filecoin is not variable, there is a fixed block time, with a block at every time slot. (null or not null). (consider this a product requirement if you want. hard constraint).
  • anybody should be able to figure out a back of the envelope calculation of how many block heights there have been by looking at a time period and dividing by the block time.
  • anybody should be able to estimate how many non-null blocks there have been (on expectation, same as the block height).
  • critical: the chain ticks with exact frequency (null or non null), with as little variance as we can get (usually variance will enter via block propagation delays on the network, or hardware variance on producing blocks, etc.)
• "chain shape" (logical time) exactly matches/maps the passage of physical/wall clock time.
  • relevant for visual renderings
  • relevant for broadest intuitive understandings of consensus protocols and blockchains

And:

• UIs and UXs should render a physical empty blocks (see fig 1 below).
  • UIs and UXs that render whole block trees should use null blocks, which will be instrumental in visually showing height differences/quality of tipsets.

---

Fig 1. correct rendering of null blocks.