Is the rewards/incentive scheme likely to benefit from certificates being on chain as promptly as possible? What about iterations with multiple certificates?

[nfrisby]

RecursiveEbs cannot "rescue" certificates from the past couple iterations, since those iterations might not have finished voting before the later EB is minted.

An alternative is to include those certs in the RB that includes the later EB (analogously to LateIbs). This seems redundant with RecursiveEBs, since a later EB will eventually rescue these certificates, but the RB rescue could do it sooner.

What about iterations that have multiple certificates? Should all of the EBs be rewarded, even if they don't end up actually being applied on chain?

Edit: the title mentions rewards/incentives, but I neglected to do so in this textbox until this edit.

[Quantumplation]

The thinking was that the EB doesn't need to rescue the certificates; the EB producer can look at the past EB and decide if he would have voted on it; and when people vote on a RecursiveEB, they decide to cast their vote only if they would have cast their vote for all the referenced EBs as well as this one.

[nfrisby]

I added an edit that might help, since my question reads horribly to me the day after :'(

I think my question ultimately boils down to: is the incentive scheme likely to votes (/certificates?) per se? Or would it only be rewarding EBs that ended up on chain (and therefore must have been certified directly/indirectly).

the EB producer can look at the past EB and decide if he would have voted on it

Just a quibble: the rules-as-written currently specify that EB-to-EB references are restricted to EBs that are already certified. So later rounds of voting cannot "rescue" an EB whose contemporary voting failed. The nice corollary is that a voting node doesn't have to do extra work/bookkeeping in proportion to however many EBs the current iteration's EB references.

[pagio]

We haven't done a deep dive on incentives yet.

[ch1bo]

Should all of the EBs be rewarded, even if they don't end up actually being applied on chain?

AFAIK We can only reward things that go on chain easily, i.e. the ledger can only count rewards for things it sees.

I'm in general a bit skeptical of the recursive EB or "rescuing" past EBs as you named it. Why would an EB producer reference a past EB if they could also just pick up the things that were endorsed and certified in the past - potentially for a higher reward?

[nfrisby]

I think the difference is size/waste. Suppose no RB arises for several iterations. We want RecursiveEBs to be able to have reached at least that far back and cover all of the EBs that are still dangling. If that's ~5 minutes, then that's maybe ~ten iterations, which means the "just include the same IBs" path makes the EB ten times bigger.

Moreover, EBs don't necessarily know which EBs they need to rescue. So the spec so far says to always refer to a certified EB from the last N iterations that yielded certficates.

Instead, RecursiveEBs leverage the fact that those older "rescued" EBs have already propagated, so it doesn't have to create an EB that's N times as big as normal. It just has N extra EB IDs instead of N-times the normal amount of IB IDs. That's the benefit as I'm anticipating it---but this isn't my design, its @pagio's.