I remember we proposed to use sequence numbers in the context of the Adaptive PoW but this was causing problems, in particular to deal with collisions: what to do when two blocks with same sequence number arrive? To keep both or to ignore both?
This is indeed a tricky question. Too high sequence numbers can be safely dropped without any issue, but this does not work with collisions.
The attacking scenario would therefore be to massively spam the input queues with duplicate sequence numbers. At this point we have pretty clear evidence on the misbehavior and can file punishment requests containing the signed transactions (no reference needed).
At this point we could deem every transaction from the attacker in the slot as invalid, but some of these transactions are likely already processed by other validators (or we might have processed them ourselves) and might even be referenced.
So consensus would have to be found on which transactions are part of the ledger.
My suggestion to work around this would be to stop scheduling anything from that queue upon finding a duplicate sequence number and “dislike” everything he sent in this slot including its children so there is a high chance it will get orphaned (we’d eventually wipe the queue). In case of referenced transactions the committee would need to decide if they still include them.
If this results in more blocks than allowed inside the ledger, we treat these as if they came through the regular scheduler and deduct mana - potentially getting the attacker deep into the negatives.
By also requiring positive mana to participate in the validation scheduler (despite we normally don’t deduct it), this could result in a long ban from validation. However, this would require a higher deposit as issuers or you would also need to lock some mana as collateral that will be consumed in such cases.
BTW, I guess we can achieve the same behavior as with sequence numbers by just considering the block timestamp, as we know we cannot have more than one block in a given slot interval
Good catch! By dividing a slot into n intervals, we essentially have them set implicitly and don’t need another field.