@Dusk Tôi đang phát lại một bản ghi của hội đồng và bản thân khối đó không phải là vấn đề. Phần khó chịu là lượng giao thông bỏ phiếu xung quanh nó. Đã có 40 chữ ký đến, và phản xạ đầu tiên của tôi là gọi tỉ lệ nén là dễ: 40 chữ ký vào, 1 chữ ký tổng hợp ra. Con số đó trông quá “gọn”.

Vậy nên tôi bắt đầu đếm byte.

Nếu một phiếu bầu cá nhân tốn S byte cho chữ ký, I cho danh tính người ký, và V cho siêu dữ liệu phiếu bầu, thì mốc hiệu quả không phải là nS. Nó gần với n(S+I+V)+H hơn. Bản xác thực cũng có “hành lý” riêng: chữ ký tổng hợp A, dữ liệu tư cách thành viên người ký M, và phần dồn/overhead của tiêu đề H'.

Tỉ lệ mà tôi thực sự quan tâm trở thành

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

Trong một lần chạy minh họa—40 phiếu, chữ ký 96 byte, 4 byte dữ liệu danh tính, 2 byte siêu dữ liệu phiếu bầu—phần “thô” đạt 4.080 byte trước overhead chung. Nếu toàn bộ đối tượng tổng hợp là 120 byte, thì điều đó cho ra mức nén 34×, tương đương ít hơn khoảng 97,1% byte.

Con số hữu ích. Có thể.

Dù vậy, tôi vẫn không gọi đó là một phép đo DUSK. Mẫu số phải lấy từ bản xác thực đã tuần tự hóa thực tế, chứ không phải một giả định tiện lợi.

Đó là bài kiểm tra mà tôi sẽ chạy tiếp theo: thu thập các bản xác thực của hội đồng thực tế ở các mức độ tham gia khác nhau và xem nơi mà đường cong nén “gọn gàng” không còn gọn gàng nữa.
#dusk $DUSK