Thoughts about what to include in block header and slot number

Research
,
1

We have discussed that we will use randomness from slot n to farm, but will wait for something like n+6 before actually producing a block with the solution to ensure everyone is in the same conditions and slower or faster hardware doesn’t result in much difference for farming.

First of all, in this case, is block considered to be “built” on slot n or slot n+6? If it is n then we wait for proof from the future, but it is odd because transactions are also from that future. If it is n+6 then it kind of makes more sense, but at odds with how we would naturally explain it and the sequence of events implemetation-wise.

Second, do we actually need to include two outputs? Theoretically doing decoding backwards from n+6 proof should make us arrive at proof n anyway, so maybe there is no point to include both in the header, while for efficient verification we would still need to get not just proof at n, but also checkpoints, it only helps partially to have one more data point in the header.

2

  1. Does transactions include “slot number”? If not, why would they be “from the future”?
    The block should have challenge from slot n (that gives eligibility on a valid PoSpace)
    The block should have a proof of time for the delay for slot n+6.
    The block should have a timestamp corresponding to the slot n+6, which is when the block is “created” and sent to the network. If transactions only have timestamps (is that even a must?), then it will not appear as if they are from the future.

  2. We don’t need to, but it does seem like a reasonable thing to do, even though the two values will have to be verified for compatibility. Recall that in the standard case PoT’s arrive to nodes before the block, they will not have to verify the PoT as part of block validation. Having the slot-n PoT, in addition to the challenge, makes the block self contained for everything-but-PoT (useful, for example, for optimistic verification; maybe for light clients?). Perhaps it also gives a better performance, because nodes only check for cache miss/hit on the slot-n PoT, but don’t have to fetch it from the cache?

3

  1. Slot number is part of the header, part of the solution to be exact. So even if we include proof n+6, solution will correspond to slot n (unless we want to infect more things with the notion that there is a delay, the idea I had was that farmer or most of the system have no idea about it). Timestamp is included in inherent extrinsic and it will correspond to whenever the block is produced, but it is decoupled from the slot. What I mean by past/future was relatively to the slot of the current PoT proof (whatever we decide that means).

  2. Actually, there is no challenge in the header, it is a derived value from randomness, but randomness itself is derived from PoT, so while before we have included randomness explicitly, now we will kind of have to include PoT, which will be even smaller (16 bytes vs 32 bytes). So I guess this is no longer much of a question here, we just swap the randomness with slot-n PoT and add slot-n+6 PoT on top (which together have the same size as on 32-byte hash we had before). Makes sense for me.

4

The slot-(n+6) PoT should be thought of as an artificial restriction, only used for block validation. It should not appear in the solution.

For the questions about transactions from the future, I still don’t see how it will appear as if they are from the future corresponding to the block time slot. I do understand that in practice the farmer could include transactions from after time slot n.

5

PoT from n+6 will still be in the header, but yes, not in a solution.

It is subjective, if we’re saying that n is the slot of the block (because it is what solution corresponds to and n+6 is an artificial restriction), then if slot n+4 is known when transaction is submitted, it can be said from the “future”, even though it is not tied or a slot otherwise.

I’m just trying to get our terminology consistent and mental model aligned.