VRF và Bầu cử Lãnh đạo Bí mật Đơn lẻ

Giới thiệu

Trong quá trình nghiên cứu dự án blockchain của riêng mình, tôi đã tìm thấy bằng chứng rằng Quỹ Ethereum đang điều tra một VRF với cấu trúc DDH cho việc bầu chọn lãnh đạo bí mật đơn (SSLE).

Trong suốt thời gian của tôi trên diễn đàn này, tôi nhìn chung đã nhận thấy sự thiếu nhận thức và hiểu biết về cấu trúc DDH, điều này thật đáng tiếc vì mọi người có xu hướng sử dụng các thiết lập phức tạp một cách không cần thiết liên quan đến zk-S{N,T}ARKs. Đừng hiểu lầm, tôi là một người hâm mộ lớn của zk-S{N,T}ARKs nhưng chúng cũng rất phức tạp và quá mức so với một vài phép cộng và nhân điểm trên một đường cong elliptic.

Vì vậy tôi nghĩ sẽ bắt đầu một chủ đề để cung cấp một giới thiệu nhanh cho bất kỳ ai quan tâm. Phần giới thiệu này dựa trên cấu trúc được mô tả trong RFC-9381 và nó cũng hoạt động như các ghi chú cá nhân của tôi cho dự án.

Như thường lệ, nếu có điều gì đó không đúng, vui lòng cho tôi biết. Những độc giả trong tương lai có thể phụ thuộc vào các vấn đề bảo mật quan trọng vào đây.

Thuật toán ký

• Hash tới đường cong:

• Tính toán điểm đầu ra:

• Tạo các điểm chứng minh:

• Tính toán vô hướng thách thức:

• Tính toán vô hướng chữ ký Schnorr:

\pi = (c, s)π=(c,s). Đầu ra (\Gamma, \pi)(Γ,π).

1. Sử dụng hash của block trước đó làm nguồn ngẫu nhiên – thất bại hoàn toàn: các nhà xây dựng block có thể kiểm duyệt tất cả các giao dịch cho đến khi một block hash thuận lợi xuất hiện, họ có thể điều chỉnh block hash bằng cách sắp xếp lại các giao dịch và sau đó gửi giao dịch đến dApp ở block tiếp theo, v.v.
2. Sử dụng hash của block hiện tại – dApp cam kết với một block và sẽ nhận hash của nó trong một giao dịch trong tương lai. Vẫn thất bại theo nhiều cách, ví dụ như các nhà xây dựng block có thể gửi giao dịch cam kết và sau đó là giao dịch giải quyết ở block tiếp theo, nhưng nếu hai block đó không mang lại kết quả thuận lợi thì họ có thể thử lại với một fork khác.
3. Sử dụng hash của block tiếp theo – cùng vấn đề như trên, chỉ cần thêm một block (có thể vẫn ở trên một fork).
4. Sử dụng hash của block N+10 – dApp cam kết với block N và tính ngẫu nhiên sẽ là hash của block N+10, khi block N là chính tắc. Thất bại ở việc điều chỉnh vì các nhà xây dựng block có thể thực hiện nhiều lần bằng cách sắp xếp lại các giao dịch của block N+10.
5. VRF dựa trên DDH được gieo bằng hash từ 10 block trước – vẫn dễ bị kiểm duyệt vì "hash từ 10 block trước" liên tục thay đổi.
6. Cam kết với block N, sau đó ở block N+11 sử dụng hàm get_random như được định nghĩa ở trên, gieo bằng hash của block N+10 – hai block cuối cùng (N+10 và N+11) vẫn có thể ở trên một fork, vì vậy một nhà xây dựng block có thể thực hiện nhiều lần bằng cách sắp xếp lại các giao dịch của block N+10.
7. Cam kết với block N, sau đó ở block N+20 sử dụng get_random gieo bằng hash của block N+10 – dường như vượt qua tất cả các bài kiểm tra, và nó không quá khác so với những gì ChainLink làm. Có lẽ hơi chậm, nhưng nó giả định rằng mất 10 slot để một block trở nên chính tắc, vì vậy có thể chúng ta có một số không gian để cải thiện bằng cách đặt ngưỡng thấp hơn.