Protocol and formal spec clarifications.

[Saizan]

We will keep having questions about the paper and how it relates to the Agda spec, so I opened this discussion to keep better track of them. Hopefully @pagio and @WhatisRT can keep an eye on it and chime in when needed.

I'll get the questions started as well:

1. The EB role has two sub-roles, Link and Endorse, but we only have one overall EB eligibility lottery. Should an eligible node perform both roles for the given slot? The Agda spec currently says so, producing a single EB with both IB and EB references (taken from different pipelines as the slices would indicate).
2. However, should the node rather produce two distinct EBs, one to fulfill the Link subrole and one for the Endorse? I don't get the sense that the paper considers the existence of "mixed" EBs with both IB and EB references.

[WhatisRT]

Thank you for opening this discussion! I'm usually quite good with checking my emails, so I shouldn't have any difficulty watching this.

That's a fantastic first question, I think I just assumed that it'd make more sense in the real world to combine the two functions. It reduces the overhead of the extra EB and I don't see any obvious downsides. But this is probably worth investigating!

[Saizan]

My concern was about creating confusion in the voting steps, since the votes do not say, neither in spec nor paper, whether they were for the Vote1 or the Vote2 round (edit: except maybe comparing slot numbers?). It seems you could assemble a certificate for an EB that actually only had enough votes in a Vote1 round, and then submit it to the base chain as if it had enough votes in a Vote2 round.

Assuming the confusion above is sorted out the other area impacted is the ledger construction: we need to be careful to ignore IB references in an EB that made it into the base-chain, as the evidence for including those IBs would be a certificate for a different EB that endorses this one.

[pagio]

The simplest way to resolve this type of issues is to assume that you have separate lotteries for each role EB1 , EB2 , vote1, vote 2. Certificates of a certain type require votes of the same type for obvious security reasons @Saizan .
While using a single lottery for say EB1, EB2 may make sense from a performance point-of-view, at this stage of the project I would go for the (simple) solution described above.

[Saizan]

Right, I can certainly go with keeping things more separate, both for roles, lotteries and produced blocks and votes.

[Saizan]

@pagio I suppose a Vote2-certified EB should be rejected by the base chain if submitted later than prescribed? i.e. an EB from slice(s,3) or earlier. Otherwise nodes might have to hold onto the referenced IBs indefinitely without guarantee they'll be part of the chain.

[pagio]

As I mentioned in Slack, blocks should not be retained forever. The exact details of this need to be figured out.