Let me propose a challenge! We currently have a way to deal with validation blocks, but we would like to improve on it. Let’s brainstorm!
Validation Blocks. Validation Blocks are blocks regularly issued by committee members (a subset of the validator set) to achieve agreement about blocks and transactions issued during the epoch reducing communication overhead and minimizing confirmation time. This set has the size
committeeTotalSeats (which is set to some value between
50 ). A committee member is expected to issue exactly
1 validation blocks every
frequencyValidationBlock seconds (which is set to either
0.5 , or
1 ). All honest committee members reference their last own latest validation block, forming a chain of validation blocks from each validator.
Dedicated throughput. To account for this intense activity, validation blocks do not require to burn Mana to be issued nor to consume deficit in the DRR scheduler. In fact, DRR is good at adapting to changing rates from each issuer and maximising the total throughput based on who is active, but in case of validator blocks we have a fixed set of active issuers producing block at a preset rate, so we can simplify the approach and provide better properties thanks to these assumptions. Our intuition is that validation blocks can bypass the normal scheduler and get a preferencial route in the data flow.
Spam prevention. An additional concern is related to spam protection: since these block do not require to consume any Mana or deficit, a malicious committee member may produce a large number of validation blocks, effectively saturating the available network resources. Detecting misbehavior is easy (only
1 validation block every
frequencyValidationBlock seconds must be produced), but it is important to discourage this to avoid orphaning large portion of the future cone.
Homework. I would like to invite the IOTA community and researchers to formulate a solution to the problem of dedicated throughput for validation blocks in order to optimize the current approach. Let me clarify again: we currently have a solution that is being implemented in IOTA Core, which I won’t reveal here because, IMO, thinking out of the box is usually much better!