edfelten
commented
5 months ago I think de-duplication needs to be done at a later stage of the protocol, because there may be duplicates that aren't evident until after decryption.
Also, de-duplication of ordinary (i.e., other than delayed inbox) transactions cannot affect safety, because the block building phase will filter out duplicates as having incorrect nonces.
That said, removing duplicates early will help performance (e.g., by avoiding a need to decrypt the same message more than once) and so should be done in a best-effort way in the inclusion phase.
There may be an advantage in not specifying the details of the interaction between the inclusion phase and the consensus protocol, and instead just leave the inclusion phase specified according to "Guaranteed properties of the inclusion phase". That is, the inclusion phase would be responsible for gathering tx's and spitting out inclusion lists at discrete "rounds", but the mechanism by which this happen could be left essentially unspecified. We could leave what is written as a "proof of concept" implementation, but no more.
Such an approach would give espresso a bit more flexibility to come up with a more performant / scalable implementation. The "de-duplication" issue could also plausibly be taken care of in this phase in a more streamlined fashion.