@Dusk Ich spielte gerade einen Ausschuss-Trace nach, und das Block selbst war nicht das Problem. Das Ärgerliche war der Abstimmungsverkehr rundherum. Vierzig Signaturen waren eingetroffen, und mein erster Instinkt war, das Kompressionsverhältnis einfach auszurechnen: vierzig Signaturen hinein, eine Aggregat-Signatur heraus. Diese Zahl sah zu „ordentlich“ aus.
Also begann ich, Bytes zu zählen.
Wenn eine einzelne Abstimmung S Bytes für die Signatur kostet, I für die Signierer-Identität und V für Metadaten zur Abstimmung, dann ist die sinnvolle Basis nicht nS. Eher liegt sie bei n(S+I+V)+H. Die Bestätigung hat außerdem ihre eigene Last: eine Aggregat-Signatur A, Signierer-Mitgliedschaftsdaten M und zusätzlichen Header-Overhead H'.
Das Verhältnis, um das es mir tatsächlich geht, wird zu
[
CR=\frac{n(S+I+V)+H}{A+M+H'}.
]
Bei einem anschaulichen Lauf – 40 Stimmen, 96-Byte-Signaturen, 4 Byte Identitätsdaten, 2 Byte Abstimmungs-Metadaten – erreicht die reine „Seite“ 4.080 Bytes, bevor allgemeiner Overhead hinzukommt. Wenn das komplette Aggregatobjekt 120 Bytes wäre, ergibt das 34× Kompression, also ungefähr 97,1% weniger Bytes.
Nützliche Zahl. Vielleicht.
Ich würde es trotzdem nicht als DUSK-Messung bezeichnen. Der Nenner muss aus der real serialisierten Bestätigung stammen, nicht aus einer bequemen Annahme.
Das ist der Test, den ich als Nächstes laufen lassen würde: echte Ausschuss-Bestätigungen über unterschiedliche Teilnahmelevel erfassen und sehen, wo die elegante Kompressionskurve aufhört, elegant zu sein.
#dusk $DUSK
Also begann ich, Bytes zu zählen.
Wenn eine einzelne Abstimmung S Bytes für die Signatur kostet, I für die Signierer-Identität und V für Metadaten zur Abstimmung, dann ist die sinnvolle Basis nicht nS. Eher liegt sie bei n(S+I+V)+H. Die Bestätigung hat außerdem ihre eigene Last: eine Aggregat-Signatur A, Signierer-Mitgliedschaftsdaten M und zusätzlichen Header-Overhead H'.
Das Verhältnis, um das es mir tatsächlich geht, wird zu
[
CR=\frac{n(S+I+V)+H}{A+M+H'}.
]
Bei einem anschaulichen Lauf – 40 Stimmen, 96-Byte-Signaturen, 4 Byte Identitätsdaten, 2 Byte Abstimmungs-Metadaten – erreicht die reine „Seite“ 4.080 Bytes, bevor allgemeiner Overhead hinzukommt. Wenn das komplette Aggregatobjekt 120 Bytes wäre, ergibt das 34× Kompression, also ungefähr 97,1% weniger Bytes.
Nützliche Zahl. Vielleicht.
Ich würde es trotzdem nicht als DUSK-Messung bezeichnen. Der Nenner muss aus der real serialisierten Bestätigung stammen, nicht aus einer bequemen Annahme.
Das ist der Test, den ich als Nächstes laufen lassen würde: echte Ausschuss-Bestätigungen über unterschiedliche Teilnahmelevel erfassen und sehen, wo die elegante Kompressionskurve aufhört, elegant zu sein.
#dusk $DUSK
