@Dusk Saya sedang mengulang jejak sebuah komite dan masalahnya bukan pada bloknya. Bagian yang menjengkelkan adalah lalu lintas pemungutan suara di sekelilingnya. Empat puluh tanda tangan telah tiba, dan naluri pertamaku adalah menyebut rasio kompresi itu mudah: empat puluh tanda tangan masuk, satu agregat keluar. Angka itu terlihat terlalu rapi.

Jadi aku mulai menghitung byte.

Jika satu pemungutan suara individual menelan S byte untuk tanda tangan, I untuk identitas penandatangan, dan V untuk metadata suara, patokan yang berguna bukanlah nS. Lebih dekat ke n(S+I+V)+H. Atestasinya juga membawa beban sendiri: tanda tangan agregat A, data keanggotaan penandatangan M, dan overhead header H'.

Rasio yang sebenarnya ingin aku pedulikan menjadi

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

Pada sebuah contoh hitungan—40 suara, tanda tangan 96-byte, 4 byte data identitas, 2 byte metadata suara—sisi mentah mencapai 4.080 byte sebelum overhead umum. Jika objek agregat lengkapnya 120 byte, itu memberi kompresi 34×, kira-kira 97,1% byte lebih sedikit.

Angka yang berguna. Mungkin.

Meski begitu, aku tetap tidak akan menyebutnya sebagai pengukuran DUSK. Penyebutnya harus berasal dari atestasi terenserial yang sebenarnya, bukan asumsi yang nyaman.

Itulah pengujian yang ingin kulakukan berikutnya: tangkap atestasi komite yang benar-benar terjadi di berbagai level partisipasi dan lihat di mana kurva kompresi yang rapi itu mulai kehilangan kerapihannya.
#dusk $DUSK