Bài viết này đến từAragonBài viết này đến từ

tiêu đề phụ

lý lịch

lý lịchLà một dự án quản trị kỹ thuật số hàng đầu, Aragon Labs đã đầu tư rất nhiều vào nghiên cứu và các mô hình quản trị đổi mới. Chúng tôi đã xác định nhiều giải pháp quản trị Lớp 2 cho thấy tiềm năng nhưng cũng có một số vấn đề kỹ thuật.

Chúng tôi đã có thể triển khai quy trình bỏ phiếu không cần gas trên Vochain, chuỗi khối bỏ phiếu chuyên dụng của chúng tôi, đồng thời đã thiết kế và triển khai một phương pháp sử dụng bằng chứng Lưu trữ Ethereum, dựa trên số liệu thống kê về Coin thế hệ ERC-20 từ chuỗi chéo Ethereum đến Vochain. Tuy nhiên, cho đến nay, khả năng chuyển kết quả chuỗi chéo sang Ethereum vẫn là một câu hỏi nghiên cứu mở.Để đạt được mục tiêu đó, Aragon Labs đã tiến hành một thử nghiệm được thiết kế mới,

Thiết kế này sẽ cho phép kết quả của quy trình bỏ phiếu ngoài chuỗi được liên kết chéo với Ethereum mà không cần sử dụng các lời tiên tri chủ quan hoặc bất kỳ thành phần đáng tin cậy nào khác.

Đề xuất của chúng tôi sẽ cho phép quy trình bỏ phiếu diễn ra hoàn toàn ngoài chuỗi, với kết quả được thực thi trên Ethereum với tính toàn vẹn giống như quản trị trên chuỗi, với một phần chi phí quản trị trên chuỗi.

tiêu đề phụ

Giao thức bỏ phiếu Bằng chứng về yêu cầu khái niệm

Trước khi thiết kế giải pháp kỹ thuật, chúng tôi đã xác định các tham số của giao thức nghiên cứu:

1. Các yêu cầu của giao thức bỏ phiếu là:

2. không cần giấy phép;

3. chống kiểm duyệt;

4. Khả năng ràng buộc kết quả trên Ethereum;

5. Cử tri không phát sinh phí xăng xe;

6. Miễn phí từ chuỗi chéo mã thông báo;

7. Đơn giản nhất có thể (không có sidechains);

Có thể được sử dụng để biểu quyết với ERC-20/ERC-777 và NFT.

1. Là một thiết kế bằng chứng về khái niệm, chúng tôi chấp nhận các ràng buộc sau:

2. Không ẩn danh người dùng: phiếu bầu có thể được liên kết với một địa chỉ Ethereum;

3. Không phải không có biên lai: có thể mua phiếu bầu;

4. Không có chương trình khuyến khích rõ ràng cho người tiếp sức.

tiêu đề phụ

đề xuất lý tưởng

Theo thiết kế của đề xuất, khi tạo một quy trình bỏ phiếu mới, người tổ chức sẽ gửi một giao dịch tới Ethereum chỉ định địa chỉ hợp đồng của mã thông báo ERC-20 để điều tra cử tri. Băm gốc lưu trữ của địa chỉ này trở thành gốc điều tra của quá trình này ở độ cao khối được chỉ định. Bất kỳ ai nắm giữ một mã thông báo nhất định đều có thể chứng minh tính đủ điều kiện của họ bằng cách cung cấp Bằng chứng Merkle về số dư mã thông báo (thông qua EIP-1186). Sau đó, họ có thể bỏ phiếu bằng cách gửi bằng chứng và chữ ký tới bộ chuyển tiếp tổng số zk-SNARK, bộ phận này sẽ tính toán bằng chứng về kết quả cuối cùng.

Vấn đề tiềm ẩn tồn tại là những người tham gia bằng chứng zk-SNARK (điều phối viên) đã tính toán kết quả về mặt lý thuyết có thể xem xét kết quả bằng cách quyết định loại bỏ phiếu bầu. Chúng tôi giải quyết vấn đề này bằng cách cho phép bất kỳ ai (không chỉ điều phối viên) gửi phiếu bầu mới: bất kỳ người dùng nào cũng có thể tạo và gửi tổng hợp có chứa phiếu bầu của họ nếu họ phát hiện ra rằng điều phối viên không đưa phiếu bầu đó vào.

• Đề xuất của chúng tôi sẽ sử dụng zk-SNARKS cho các mục đích sau:

• Xác thực một địa chỉ mà không cần bỏ phiếu thông qua bộ tích lũy Merkle Tree;

• Xác minh rằng người dùng sở hữu mã thông báo thông qua Proof of Storage;

• tính kết quả từng phần của một đợt phiếu;

Dựa trên mô hình trên, chúng ta có thể tìm thấy hai vấn đề chính:

tiêu đề phụ

Bằng chứng lưu trữ ERC-20 rất phức tạp để xác minh trong SNARK. Điều này một phần là do họ sử dụng phân tích cú pháp tiền tố độ dài đệ quy (RLP) và nhiều xác minh hàm băm Kecmack -256, cả hai đều không hiệu quả về mặt tính toán trong các kỹ thuật tóm tắt SNARK hiện đại. Vấn đề này rất khó giải quyết, vì vậy hiện tại chúng tôi sử dụng xác thực lạc quan để giải quyết vấn đề này.

tiêu đề phụ

Vấn đề 2: Xác minh chữ ký ECDSA/Secp256k1 không thân thiện với SNARK

Một tiêu chuẩn mật mã hiện tại mà chúng tôi có thể sử dụng để xác minh chữ ký của người dùng là ECDSA, sử dụng khóa BabyJubJub từ chữ ký Ethereum, sử dụng chữ ký đó làm khóa riêng ban đầu, cho phép người dùng khôi phục địa chỉ của họ. Vì phương pháp này dựa trên chữ ký của người dùng nên nó dễ bị các proxy độc hại lừa người dùng ký các giao dịch gian lận trong ví Web3 của họ. Lỗ hổng này tồn tại ở mọi nơi mà ví trình duyệt sử dụng để ký giao dịch. Một giải pháp tiềm năng có thể là sử dụng địa chỉ web làm đường dẫn xuất để lấy khóa riêng.

Một thách thức khác là chứng minh rằng địa chỉ Ethereum của mỗi chủ sở hữu mã thông báo chấp thuận khóa công khai BabyJubJub để bỏ phiếu ở độ cao khối được tạo bởi quy trình bỏ phiếu. Chúng tôi thực hiện điều này thông qua hợp đồng thông minh "đơn lẻ" ánh xạ địa chỉ Ethereum tới khóa công khai BabyJubJub và người dùng phải thêm khóa của họ vào hợp đồng thông minh thông qua giao dịch tiêu chuẩn. Ánh xạ địa chỉ tới khóa có thể đạt được với bằng chứng gian lận lưu trữ lạc quan. Vì các khóa ủy quyền này dự kiến ​​sẽ được sử dụng nhiều lần trong các quy trình bỏ phiếu khác nhau nên giải pháp này cũng giải quyết các vấn đề về tính khả dụng của dữ liệu thông qua một thiết kế có thể tái sử dụng.

• Tóm lại, chúng tôi có thể xử lý hầu hết các xác minh trong SNARK, ngoại trừ:

• Xác nhận rằng một địa chỉ chưa được bình chọn thông qua bộ tích lũy cây Merkle → SNARK trước đó;

• Xác minh xem người dùng có mã thông báo hay không thông qua Bằng chứng lưu trữ → Lạc quan;

• tiêu đề phụ

người dùng

• người dùng

• Truy xuất thông tin biểu quyết và bằng chứng lưu trữ của tài khoản của họ, tạo chữ ký trên gói biểu quyết và chuyển tiếp nó tới người chuyển tiếp hoặc nhóm người chuyển tiếp.

tiêu đề phụ

Hợp đồng thông minh bỏ phiếu

Đăng ký quy trình bỏ phiếu, bao gồm: địa chỉ hợp đồng thông minh ERC-20, chỉ mục vị trí của địa chỉ ERC-20 → ánh xạ cân bằng, hàm băm gốc trạng thái của khối bắt đầu quy trình bỏ phiếu và quy trình tham số để tính phiếu bầu.

• Bằng cách giám sát việc đăng ký phiếu bầu mới thông qua zk-Rollup, SNARK sẽ chứng minh rằng:

• tính kết quả;

• Chữ ký biểu quyết được xác định bởi khóa BabyJubJub;

• Luôn cập nhật bộ tích lũy phiếu bầu;

Cập nhật danh sách cử tri.

• Cho phép bất kỳ ai thách thức bằng chứng về gian lận đăng ký bỏ phiếu cuối cùng. Nhưng phải đáp ứng một trong các điều kiện sau:

• Bằng chứng lưu trữ, chứng minh rằng địa chỉ Ethereum của cử tri không có mã thông báo;

• Bằng chứng là khóa BabyJubJub đã được bình chọn (khóa nằm trong cây Merkle "được bình chọn").

tiêu đề phụ

• tiếp sức

• Giai đoạn 0: Một quy trình bầu cử được tạo trên Ethereum và một người chuyển tiếp được chọn từ danh sách những người chuyển tiếp có sẵn. Người tổ chức bầu cử cần trả lệ phí bầu cử (được thưởng cho người điều phối). Ban tổ chức cung cấp mã byte EVM cần được thực thi sau cuộc bầu chọn hợp đồng thông minh DAO, tùy thuộc vào kết quả.

• Giai đoạn 1: Bắt đầu bỏ phiếu. Bất kỳ ai cũng có thể gửi gói biểu quyết (truyền tải HTTP hoặc libp2p) đến người điều phối đã chọn. Điều phối viên cuộn các kết quả đã chọn theo lô, xây dựng bằng chứng zk-SNARK, tải bằng chứng và kết quả lên Ethereum, thu thập phiếu bầu của người dùng, xác minh chúng và phát chúng cho những người chuyển tiếp khác.

• Giai đoạn 2: Điều phối viên phát hiện ra rằng anh ta không tham gia bỏ phiếu có thể tổng hợp phiếu bầu của chính mình và gửi bằng chứng zk-SNARK về tính hợp lệ cho hợp đồng thông minh bỏ phiếu. Ngoài ra, nếu họ phát hiện ra rằng một phiếu bầu đã được thêm vào không chính xác, họ có thể gửi bằng chứng gian lận rằng kết quả được thêm vào trước đó là không hợp lệ và điều phối viên tạo ra nó sẽ bị chém.

  Giai đoạn 3: Khi đạt đến giới hạn ngày bỏ phiếu:

  Bất kỳ ai (thường là điều phối viên) đều gọi thực thi mã byte EVM, sử dụng kết quả cuối cùng làm đầu vào.

tiêu đề phụ

Dòng và Hợp đồng

zk-SNARK sẽ tổng hợp danh sách bình chọn. Bằng chứng zk-SNARK có giá trị dựa trên danh sách bỏ phiếu nhất định, gốc điều tra dân số, mã định danh bầu cử (electionId) và kết quả tổng hợp.

• Đầu vào của zk-SNARK:

• Đầu vào băm là để giảm chi phí gas xác minh SNARK;

• định danh bầu cử riêng;

• Tính kết quả biểu quyết;

• gốc vô hiệu hóa hiện tại (nullifiers root);

• Cập nhật gốc rune trống;

• số phiếu trong đợt;

Giá trị biểu quyết và chữ ký khóa BabyJubJub tương ứng.

• Đầu vào cho lệnh gọi chức năng hợp đồng thông minh để tải lên kết quả đối chiếu là:

• định danh bầu cử;

• Danh sách các khóa công khai của những người bỏ phiếu trong đợt;

• Cập nhật gốc rune trống;

• bằng chứng SNARK.

tiêu đề phụ

Bằng chứng thực hiện khái niệm

Chúng tôi đã triển khai một mạch và hợp đồng thông minh khả thi tối thiểu, do đó kiểm tra chi phí và tính khả thi của giải pháp. Bằng chứng về khái niệm chỉ bao gồm đăng ký người dùng, tổng hợp phiếu bầu và xác minh bằng chứng gian lận.

• Các thử nghiệm của chúng tôi dẫn đến các chi phí gas sau:

• Triển khai sổ đăng ký khóa người dùng: 258536

• Đăng ký: 68956

• Bình chọn Triển khai: 6673,159

• Bình chọn mới: 25989

• Tóm tắt tích lũy: 291801

• Bằng chứng gian lận 2: 908822 (số dư tài khoản ERC-20 bằng 0)

tiêu đề phụ

nghiên cứu trong tương lai

1. Dựa trên nghiên cứu này, chúng tôi muốn khám phá sâu hơn các ý tưởng sau:

2. Xác minh chữ ký kecak/ECDSA/Sec256k1 tiêu chuẩn thông qua SNARK. Chúng tôi tin rằng chẳng bao lâu nữa, PLOOKUP sẽ có thể xác minh các sơ đồ này, điều này sẽ dẫn đến hai khả năng:

3. Bằng chứng là khóa BabyJubJub được lấy từ khóa Secp256k1.

4. Xác minh chính chữ ký biểu quyết.

5. Bằng chứng lưu trữ được xác minh bên trong SNARK. Chúng tôi nghĩ rằng loại dây phức tạp này có thể được tích hợp dễ dàng bởi một zkVM, mặc dù chi phí có thể rất lớn. Chúng tôi lo ngại rằng các máy khách Ethereum sẽ thoát khỏi các nút lưu trữ, ưu tiên giới hạn chi phí gas cao hơn, do đó, một lĩnh vực nghiên cứu khác là thử các phương pháp khác ngoài EIP1186 cho Proof of Storage.

6. Để tính toán số lượng, một số opcode được nhúng để thực thi trong zkVM, giúp cung cấp các mạch biểu quyết có thể lập trình chung.zk.moneyBằng chứng về phiếu bầu được tạo trong trình duyệt, được trộn lẫn thông qua xử lý hàng loạt và kết quả được tổng hợp đệ quy, tương tự như

7. giao thức. Điều này sẽ tăng tính riêng tư của quá trình bỏ phiếu.

8. Cho phép tính toán SNARK theo kiểu phân tán ở cấp độ trình duyệt, ngay cả khi tính toán chúng rất tốn kém. Điều này giúp tiết kiệm sự phụ thuộc vào các máy chủ có khả năng hiển thị cao và hoàn toàn là P2P, trao toàn bộ quyền lực cho cử tri.

9. Nhúng quyền riêng tư và trộn vào giao thức bỏ phiếu ở cấp độ mạng.

10. Tìm một mô hình kinh tế tiền điện tử hợp lý có thể tương thích hoàn toàn với Ethereum 2.0.