@Dusk Я заново прогонял трассировку работы комитета, и проблема была не в самом блоке. Самое раздражающее — трафик голосования вокруг него. Пришли сорок подписей, и моя первая интуиция была назвать коэффициент сжатия простым: сорок подписей на входе и одна агрегированная на выходе. Эта цифра выглядела слишком уж аккуратно.

Поэтому я начал считать байты.

Если отдельный голос обходится в S байт(ов) для подписи, I для идентификатора подписанта и V для метаданных голоса, то полезная базовая оценка — не nS. Ближе к n(S+I+V)+H. У аттестации тоже есть собственный багаж: агрегированная подпись A, данные принадлежности подписантов M и накладные расходы заголовка H'.

Коэффициент, который меня на самом деле интересует, становится

[
CR=\frac{n(S+I+V)+H}{A+M+H'}.
]

В наглядном прогоне — 40 голосов, подписи по 96 байт, 4 байта данных идентичности и 2 байта метаданных голоса — «сырые» расходы доходят до 4 080 байт до общих накладных расходов. Если же полный агрегированный объект весит 120 байт, это даёт 34× сжатия, то есть примерно на 97,1% меньше байт.

Полезная цифра. Возможно.

Но я всё равно не назвал бы это измерением DUSK. Знаменатель должен браться из реальной сериализованной аттестации, а не из удобного допущения.

Вот тест, который я бы провёл дальше: снять реальные аттестации комитета при разных уровнях участия и посмотреть, где аккуратная кривая сжатия перестаёт быть аккуратной.
#dusk $DUSK