MACI: Khung chống thông đồng trong quản trị trên chuỗi

Eric Zhang

Architect @DoraFactory @DoraHacks

Để biết thông tin cơ bản của bài viết này, vui lòng tham khảo "Bỏ phiếu bậc hai và cấp vốn bậc hai" (https://matataki.io/p/6113). Một tháng sau khi xuất bản bài báo này, Quỹ BSC đã khởi động vòng tài trợ bậc hai đầu tiên cho hệ sinh thái BSC (https://hackerlink.io/grant) trên nền tảng dành cho nhà phát triển DoraHacks HackerLink và trong 15 ngày sau đó đã nhận được các dự án được gửi bởi hơn 60 nhóm nhà phát triển trên khắp thế giới.

Trong "Bỏ phiếu bậc hai và tài trợ bậc hai", tôi đã giới thiệu ba vấn đề được đề cập trong blog "Thanh toán bậc hai" của Vitalik: Hối lộ danh tính, Thông đồng, Sự thiếu hiểu biết hợp lý). Ba vấn đề này không chỉ giới hạn ở việc bỏ phiếu bậc hai, mà là những vấn đề phổ biến mà các cơ chế quản trị trên chuỗi gặp phải. Do đó, các giải pháp cho những vấn đề này không chỉ giúp cho việc bỏ phiếu bậc hai có thể mở rộng hơn và an toàn hơn mà còn mang lại lợi ích cho các cơ chế quản trị trên chuỗi.

Mục tiêu của bài viết này là chuẩn bị cho việc thiết kế cơ chế "bỏ phiếu bậc hai không hợp tác" hoặc "bỏ phiếu bậc hai chống thông đồng". Trong kịch bản này, các cử tri không thể hợp tác với nhau, vì vậy không có khả năng thông đồng. Một khuôn khổ cơ bản của cơ chế này là bài báo “Cơ sở hạ tầng chống thông đồng tối thiểu” [1] (MACI) được xuất bản bởi Vitalik Buterin trên Ethresear. Do đó, trước tiên chúng tôi giải thích cơ chế của MACI, để khám phá thêm cách sử dụng MACI để cải thiện việc bỏ phiếu bậc hai và loại bỏ khả năng thông đồng.

MACI: Minimal Anti-Collusion Infrastructure

MACI là "Khung chống thông đồng tối thiểu hóa". Để biết các tài liệu cơ bản, hãy tham khảo blog của Vitalik Buterin https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413 và "On Collusion" https://vitalik.ca/general/2019/04/03/collusion .html

cài đặt

cài đặt

Giả sử có một hợp đồng thông minh \(R\) chứa danh sách các khóa công khai\(K_1 ... K_n\),Và một số chức năng cần thiết để đăng ký các khóa công khai này vào hợp đồng thông minh. Ngoài ra, chỉ khóa công khai của người tham gia đáp ứng hai điều kiện sau để xác minh danh tính mới có thể nhập R:

Tài khoản thuộc về một người tham gia "hợp pháp" (một người độc lập, thành viên của một cộng đồng nhất định, chẳng hạn như có quốc tịch của một quốc gia nhất định, có uy tín đủ cao trong diễn đàn, nắm giữ không ít hơn một lượng Token nhất định). .. )

Khóa kiểm soát cá nhân của chủ tài khoản (ví dụ: có thể in ra để làm bằng chứng nếu được yêu cầu)

Mỗi người dùng cần đặt cọc một số tiền nhất định: nếu bất kỳ ai tiết lộ khóa riêng tư của họ, người nhận được khóa riêng tư có thể trực tiếp rút tiền và tài khoản sẽ bị xóa khỏi danh sách. Cơ chế này ngăn cản bất kỳ ai bàn giao khóa riêng cho người khác.

Ngoài ra, giả sử có một toán tử (\(operator\)) có khóa riêng\(k_\omega\),và một khóa công khai tương ứng\(K_\omega\).

Cuối cùng, giả sử có một cơ chế\(M\),nó là một chức năng\(action^n \rightarrow Outputs\),thực hiện

thực hiện

Tại thời điểm bắt đầu \(T_{start}\), \(toán tử\) bắt đầu một trạng thái thực tế\(S_{start} = {i: (key=K_i, action = \phi)}, i \in 1...n\).

Từ thời điểm bắt đầu \(T_{start}\) đến thời điểm kết thúc \(T_{end}\), bất kỳ người tham gia đã đăng ký nào cũng có thể gửi tin nhắn tới R bằng mã hóa khóa cá nhân \(k\) của chính người tham gia. Có hai loại tin nhắn:

Hành vi đồng ý: ví dụ: bỏ phiếu. Người tham gia cần gửi tin nhắn được mã hóa\(enc(msg = (i, sign(msg = action, key = k_i)), pubkey = K_\omega)\),Trong đó \(k_i\) là khóa cá nhân hiện tại của người tham gia và \(i\) là id của người tham gia trong \(R\)

Rekey: Người tham gia cần gửi tin nhắn được mã hóa\(enc(msg = (i, sign(msg = NewK_i, key = k_i)), pubkey = K_\omega)\),Trong đó \(NewK_i\) là khóa công khai được thay đổi bởi người tham gia,\(k_i\) là khóa cá nhân hiện tại của người tham gia này

Tại thời điểm này, công việc của người vận hành là xử lý từng thông báo theo thứ tự mà chúng được tải lên chuỗi. Quy trình xử lý cụ thể:

Giải mã tin nhắn bằng khóa riêng của nhà điều hành. Nếu quá trình giải mã không thành công hoặc thông tin tương ứng với việc giải mã không thể được giải mã thành hai loại thông tin trên, hãy bỏ qua thông tin này trực tiếp

Sử dụng \(state[i].key\) để xác minh chữ ký của thư

Nếu thông báo đã giải mã là hành vi đã thỏa thuận (\(hành động\)), thì hãy đặt\(state[i] = action\),Nếu tin nhắn được giải mã là một khóa công khai mới, thì hãy đặt\(state[i].key = NewK_i\)

Sau \(T_{end}\), người vận hành phải thông báo trạng thái đầu ra\(M(state[1].action, ... , state[n].action)\),Đồng thời, một ZK-SNARK được đưa ra để chứng minh rằng đầu ra này là kết quả chính xác.

Tại sao cơ chế này là chống thông đồng

Giả sử một người tham gia muốn chứng minh những gì anh ta đã làm, chẳng hạn như thực hiện \(action\) \(A\), anh ta có thể tham khảo một giao dịch trên chuỗi\(enc(msg = (i, sign(msg = A, key = k_i)),pubkey = K_\omega)\) và cung cấp bằng chứng không có kiến ​​thức để xác minh rằng giao dịch thực sự chứa thông tin được mã hóa của \(A\). Tuy nhiên, anh ta không thể chứng minh rằng anh ta đã không gửi các giao dịch khác. Ví dụ: anh ta có thể đã gửi một giao dịch trước đó và thay thế khóa công khai bằng \(NewK_i\) mới, vì vậy bằng chứng trước đó trở nên vô nghĩa, bởi vì nếu anh ta đã thay đổi khóa công khai quan trọng, anh ta có thể đã làm một cái gì đó khác.

Người tham gia cũng có thể đưa khóa riêng tư cho người khác, nhưng khi làm như vậy, người đó có thể ngay lập tức tìm cách sửa đổi khóa sau khi họ có. Trong trường hợp này, 1) tỷ lệ thành công là 50% và 2) người lấy được chìa khóa sẽ trực tiếp lấy đi tiền đặt cọc của số tiền đặt cọc trước đó.

Các vấn đề chưa được giải quyết với MACI

Người nhận bán khóa riêng trong môi trường phần cứng đáng tin cậy hoặc trong trường hợp đa chữ ký đáng tin cậy

Khóa riêng ban đầu bị tấn công trong môi trường phần cứng đáng tin cậy, điều này ngăn không cho khóa riêng bị thay đổi thành bất kỳ khóa riêng nào mà kẻ tấn công không biết trước

Trong trường hợp đầu tiên, có thể sử dụng cơ chế chữ ký phức tạp được thiết kế đặc biệt và thiết kế này không thân thiện với phần cứng đáng tin cậy và đa chữ ký. Tuy nhiên, thiết kế này cần đảm bảo rằng chức năng xác minh thân thiện với ZKP.

Trường hợp thứ hai có thể được giải quyết bằng "bằng chứng trực tiếp không có kiến ​​​​thức". Ví dụ: người tham gia có thể phân tách khóa riêng thành \(x + y = k_i\), xuất bản \(X = x*G\) và\(Y = y*G\),Và đưa cho người xác minh hai phong bì chứa \(x\) và \(y\); người xác minh mở một phong bì, kiểm tra xem \(Y\) đã thông báo có đúng không, rồi kiểm tra\(X + Y = K_i\)。

bỏ phiếu bậc hai không hợp tác

Cơ chế này có thể được sử dụng để cải thiện các cơ chế quản trị trên chuỗi khác nhau, bao gồm cả bỏ phiếu. Trong tài trợ bậc hai, thông đồng trở thành một vấn đề phải được giải quyết khi quy mô nhóm rất lớn hoặc khi tài trợ bậc hai được sử dụng trong các tình huống lớn hơn (ví dụ: tổng tuyển cử, phê duyệt ngân sách quốc hội, v.v.). Do đó, việc thiết kế một cơ chế tài trợ bậc hai Chống thông đồng có thể mở rộng quy mô tài trợ bậc hai.

[1]Vitalik Buterin, Minimal anti-collusion infrastructure,

https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413