consensus: burnt L1 UTXOs should become valid at a specific epoch. A block proposer MUST propose to mint these or the block is rejected.

[sdbondi]

Background

A L1 UTXO burnt into the L2 at a specific epoch currently may be proposed at some undefined point.

There is currently no incentive for proposers to include the mint commands into a block.

Proposal 1

A detected burnt UTXO MUST be proposed in a block as soon as the applicable epoch becomes active, that is, once we can be sure that a super majority of validators are aware of the UTXO. Failing that the block must be rejected (NO VOTE).

Assuming some disincentive for missed/invalid proposals, this indirectly incentivises proposing to mint unclaimed UTXOs.

[stringhandler]

There could be a large amount of these transactions. I agree with the above, except that I suggest that we use the base layer block height or hash and not the Epoch

[sdbondi]

I currently disagree with the need to include the base layer block data in L2 blocks.

This is why:

1. Scanning is not synchronised, when the base layer block validations where in use I commonly observed leader failures because of a race condition between the base layer scanner and the block. This validation is currently commented out for this reason.
2. We could park the block until we've scanned but this adds complexity, coupling and a (typically little) extra delay
3. I don't think it adds anything. The epoch does this with a single number.

My current mental model:

1. An epoch represents a specific block on the base layer i.e. get_block_by_height((base_layer_height - 1000(lag)) / 10)
2. Nothing can change between epochs (currently ~20 minutes, eth epochs are ~6.5 minutes). This means that no additional UTXOs are added, no additional templates are active and the active validator set is fixed until the next epoch.
3. The above (2) may not be true currently but this is how I think it should be
4. Given that no global state (base layer) changes inside an epoch, agreeing on an epoch number is sufficient.
5. We currently reset the chain at every epoch - I think this should change/not happen and should only occur when shard groups are added or removed (how/when this happens aside - but it will be after many epochs). This avoids the need to cancel/reset transactions.
6. Checkpoints should be created after each epoch and provide a "state sync anchor point", avoiding the need to sync every block for preceeding epochs.
7. We agree on epoch changes (and implicitly all the global epoch state changes, join/leaving VNs, new templates, new UTXOs)
8. If a transaction uses a template that is not yet active (or does not exist) it will be rejected.
9. If a proposer adds a UTXO that is not yet active in the epoch, the block is rejected

Thoughts? I may be missing something. I have not had this understanding until recently or expressed it until now so feedback welcome :)