詳解最小化反共謀基礎設施（MACI）

一、MACI簡介

MACI是Minimal Anti-Collusion Infrastructure的縮寫，是一種允許用戶進行鏈上投票過程的應用程序，其有很強的抗串通/共謀能力。當今鏈上投票過程中的一個常見問題是，賄賂選民使其為某一特定選項投票十分容易。很多時候，這種賄賂採取的形式是 "加入我們的池子（按我們的方式投票），我們會給你分紅（賄賂）"。由於區塊鏈上的所有交易都是公开的，如果沒有MACI，投票者可以很容易地向賄賂者證明他們投票給了哪個選項，從而獲得賄賂獎勵。

MACI通過使用zk-SNARKs來解決這個問題，從本質上隱藏了每個人的投票方式，同時仍然顯示最終的投票結果。用戶無法證明他們投票給哪個選項，因此賄賂者無法可靠地相信用戶所投的票是投給了賄賂者所指定的選項。例如，一個選民可以告訴賄賂者他們投的是選項A，但實際上他們投的是選項B。沒有可靠的方法來證明選民實際上投的是哪個選項，所以賄賂者沒有動機去付錢給選民來投他們的票。

a.背景

本文將介紹 MACI 的一般工作流程以及它如何能夠提供以下原則（逐字逐句摘自 Wei Jie 的文章）：

1. 反對共謀。除了受信任的協調者之外，沒有人可以確定投票的有效性，從而降低賄賂的有效性。

2. 無收據性。沒有投票者可以證明（除了向協調者）他們投票的方式。

3. 隱私。除了受信任的協調者，沒有人能夠解密投票。

4. 不可審查性。任何人（甚至是受信任的協調者）都不能審查投票。

5. 不可僞造性。只有用戶私鑰的所有者可以投票與其對應的公鑰相關聯

6. 不可抵賴性。何人都不能在投票後修改或刪除投票，盡管用戶可以再次投票以使其無效

7. 正確執行。任何人（甚至是受信任的協調者）都不應該能夠產生虛假的選票。

二、系統總覽

a.角色

在MACI工作流程中，有兩種不同的角色：用戶（投票者）和一個受信任的協調者。用戶通過MACI智能合約在區塊鏈上投票，協調者統計票數並發布最終結果。

協調者必須使用zk-SNARKs來證明他們的最終統計結果是有效的，而不公布每個人的投票。因此，即使協調者是腐敗的，他們也無法改變用戶的投票或自己增加額外的投票。腐敗的協調者可以通過從不公布結果來阻止投票，但他們不能公布虛假的結果。

在將他們的投票發送到區塊鏈上之前，用戶使用一個只有用戶和協調者才可以知道的共享密鑰對他們的投票進行加密。這個密鑰方案的設計是為了讓每個單獨的用戶與協調者共享一個不同的密鑰。這可以防止任何賄賂者簡單地讀取交易數據，以便查看用戶投票給哪個選項。加密後的投票將被認為是一個 "消息"，用戶將這個消息發送到MACI智能合約上，並存儲在鏈上。

這種加密原理的一個非常簡化的說明如下所示：

b.選票覆蓋和公鑰轉換

在用戶投票之前，他們必須通過向MACI智能合約發送他們希望用於投票的公鑰來進行注冊。這個公鑰在投票時充當他們的身份。他們可以從任何地址投票，但他們的信息必須包含該公鑰的籤名。在注冊後進行實際投票時，用戶將把一些變量，包括公鑰、他們的投票選項、他們的投票金額和其他一些變量捆綁到一個所謂的 "命令 "中。然後，用戶用他們最初用於注冊的公鑰籤署該命令。之後，用戶將籤名和命令一起加密，這樣它就被認為是一個消息。關於說明如何構造更復雜消息的描述如下：

只要用戶使用之前的公鑰籤署他們的命令，就能夠推翻他們之前的投票。如果該命令被用戶以前的公鑰正確籤署，那么該信息就被認為是有效的，協調者將把這算作正確的投票。因此，當用戶在投票中提供的公鑰與他們之前的公鑰不同時，他們可以提交一個由這個新公鑰籤名的新投票，以推翻他們之前的投票。如果該籤名不是來自以前的公鑰，該信息將被標記為無效，不計入統計。因此，公鑰可以被認為是用戶的投票用戶名，而籤名就是投票密碼。如果他們提供了正確的籤名，他們就可以提交投票或更改他們的公鑰，或兩者兼而有之。

這個功能，我稱之為公鑰切換，旨在對抗賄賂攻擊，用戶只需向賄賂者展示他們的信息，然後解密，讓賄賂者看到用戶的投票方式。公鑰轉換允許用戶改變他們的公鑰，並創建有利於賄賂者的無效信息。賄賂者沒有辦法知道用戶在發送顯示給賄賂者的投票之前是否切換了他們的公鑰。

舉個例子

1. Bob用公鑰1注冊

2. Bob創建了一個命令，其中包含--對選項A的投票和公鑰2

3. Bob用公鑰1，也就是他用來注冊的密鑰，籤署這個命令

4. Bob把這個命令加密成一個消息，並把它提交給MACI智能合約

5. 協調者解密這個消息，並檢查以確保該命令是由Bob之前的密鑰--公鑰1籤署的。這個消息是有效的。

6. 協調者記錄Bob對選項A的投票，並將其公鑰更新為公鑰2

Bob已經成功地投票給了選項A，為了推翻這個投票，必須發送一個帶有公鑰2籤名的新投票。在這一點上，一個賄賂者現在試圖讓Bob投票給選項B。

1. Bob創建一個命令，其中包含--對選項B的投票和公鑰1

2. Bob用公鑰1籤署這個命令，對信息進行加密，並將其提交給MACI智能合約

3. Bob向賄賂者展示解密後的信息，作為他對選項B投票的證明

4. 協調者解密了Bob的消息，看到籤名與公鑰2--Bob之前的消息中添加的密鑰不一致。因此，這條信息是無效的，這張票不會被計入最後的統計。

5. 賄賂者沒有辦法知道投票是有效還是無效的，因此沒有動力向其他用戶提供賄賂

為了更好地了解MACI是如何工作的，最重要是要知道zk-SNARKs如何能夠證明協調者解密了每個消息並正確地統計了投票。下一節對zk-SNARKs做了一個快速的、過於簡化的概述。

c.zk-SNARKs

從本質上講，zk-SNARKs允許用戶證明他們知道一個特定數學方程的答案，而不透露這個答案是什么。以下面這個方程為例。

X + Y = 15

我可以證明我知道兩個滿足方程的數值，即X和Y，而不需要透露這兩個數值是什么。當我為我的答案創建一個zk-SNARK時，任何人都可以使用SNARK（一組數字）並根據上述方程進行驗證，以證明我確實知道該方程的一個解決方案。用戶無法使用SNARK來找出我對X和Y的答案。

對於MACI來說，這個方程式要復雜得多，但可以總結為以下幾個方程式：

encrypt(command1) = message1

encrypt(command2) = message2

encrypt(command3) = message3

…

Command1 from user1 + command2 from user2 + command3 from user3 + … = total tally result

在這裏，每個人都能看到區塊鏈上的消息和總的財務結果。只有協調者通過解密消息知道各個命令/投票是什么。所以，協調者使用zk-SNARK來證明他們知道所有的投票：

1. 對區塊鏈上的信息進行加密

2. 對統計結果進行求和

然後，用戶可以使用SNARK來證明計票結果是正確的，但不能用它來證明任何個人的投票選擇。

三、工作流程

一般的工作流程可以分為4個不同的階段：

1. 注冊

2. 發布信息

3. 處理信息

4. 統計結果

這些階段利用了3個主要的智能合約--MACI、Poll和PollProcessorAndTallyer。這些合約可以在MACI github頁面上找到。MACI合約負責通過記錄每個用戶的初始公鑰來跟蹤所有用戶的注冊情況。當投票要進行時，用戶可以通過MACI.deployPoll()部署一個Poll智能合約。

最後，PollProcessorAndTallyer合約被協調者用來在鏈上證明他們正確地統計了每張投票。這個過程將在下面的處理信息和統計結果部分詳細解釋。

a.注冊

MACI的注冊過程是通過MACI.sol智能合約處理的。用戶在調用MACI.signUp()時需要發送三條信息。

1. 公鑰

2. 注冊守衛數據

3. 初始語音信用代理數據

公鑰是上述章節中提到的原始公鑰，用戶需要用它來投票。正如前面幾節所解釋的，一旦投票开始，他們可以在以後改變這個公鑰。用戶用於注冊的公鑰在每次投票中都是共享的。

MACI允許合同創建者/所有者設置一個 "注冊守衛"。它是指另一個智能合約的地址，它決定了籤到的規則。因此，當一個用戶調用MACI.signUp()時，該函數將調用注冊守衛數據，以檢查該用戶是否有效籤約。

MACI還允許合同創建者/所有者設置一個 "initialVoiceCreditProxy"。這代表了決定一個給定用戶獲得多少票數的合同。因此，當用戶調用MACI.signUp()時，該函數將調用初始語音信用代理來檢查他們可以花費多少票數。每次新的投票，用戶的語音信用余額都會被重置為這個數字。

一旦MACI檢查到用戶是有效的，並檢索到他們有多少語音點數，MACI就會將以下用戶信息存儲到Sign Up Merkle Tree中。

1. 公共密鑰

2. 語音積分

3. 時間戳

b.發布信息

一旦到了投票時間，MACI創建者/所有者將部署一個Poll智能合約。然後，用戶將調用Poll.publishMessage()並發送以下數據：

1. 消息

2. 加密密鑰

如上文各節所述，協調者將需要使用加密密鑰，以得出共享密鑰。然後，協調者可以使用共享密鑰將消息解密為一個命令，其中包含投票。

一旦用戶發布了他們的消息，投票合同將把消息和加密密鑰存儲到Message Merkle Tree中。

c.處理信息

一旦特定投票完成，協調者將使用PollProcessAndTallyer合約，首先證明他們已經正確地解密了每個消息，並應用它們來正確地創建一個更新的狀態樹。這個狀態樹記錄了所有應該被計算的有效投票。因此，在處理消息時，協調者不會在狀態樹內保留那些後來被更新的消息所覆蓋的消息。例如，如果一個用戶投票給選項A，但後來又發送了一個新消息投票給選項B，協調者將只計算選項B的投票。

協調者必須分組處理消息，以便在鏈上證明不超過數據限制。然後協調者創建一個zk-SNARK，證明他們的狀態樹正確地只包含有效的消息。一旦證明准備好了，協調者調用PollProcessorAndTallyer.processMessages()，提供狀態樹的哈希值和zk-SNARK證明作為輸入參數。

PollProcessorAndTallyer合約將把證明發送給一個單獨的驗證器合約。驗證器合約是專門用來讀取MACI zk-SNARK證明並判斷它們是否有效的。因此，如果驗證者合同返回為真，那么每個人都可以在鏈上看到協調者正確處理了那批消息。協調者重復這個過程，直到所有消息都被處理。

d.統計結果

最後，一旦所有信息都被處理，協調者就會統計有效信息的票數。協調者創建一個zk-SNARK，證明狀態樹中的有效消息（在處理消息步驟中證明）包含的票數之和為既定的統計結果。然後，他們調用PollProcessorAndTallyer.tallyVotes()，用正確統計結果的哈希值和zk-SNARK證明。與processMessages函數類似，tallyVotes函數將把證明發送給一個驗證器合約，以確保它是有效的。

只有當驗證者合約返回證明是有效時，tallyVotes函數才會成功。因此，一旦tallyVotes函數成功，用戶就可以相信協調者已經正確地統計了所有的有效投票。在這一步之後，任何人都可以看到最終的計數結果，並證明這些結果是發送到 Poll 合約的正確結果。用戶將無法看到任何個人是如何投票的，但可以相信這些投票是被正確處理和計算的。

四、結論

MACI在防止鏈上投票的共謀方面邁出了一大步。雖然它不能防止所有共謀的可能性，但它確實使之更難。MACI已經可以在DoraHacks、clr.fund中看到並使用。如，今年2月11日开始的美國區塊鏈和Web3黑客馬拉松ETH Denver，現場共有九個賽道：ColoradoJam、DAOs & Communities、Defi、Impact、Mobile-First Focus、NFTs、Gaming & Metaverse、Infrastructure & Scalability、太空技術和新領域；Hackathon現場參賽者通過DoraHacks开發者激勵平臺HackerLink.io提交項目，並角逐200萬美金的Grant和超過100萬美金的Bounty任務。這個過程中，現場新增了基於零知識證明的隱私二次方投票，社區可以通過DoraHacks提供的MACI最小抗共謀基礎設施進行匿名、隱私的二次方投票，並獲得SPORK獎金池資助。

DoraHacks實現了MACI的第一次中等規模的應用。具體基於MACI 隱私投票排行榜可以查看：https://hackerlink.io/grant/ethdenver22/top

當讓用戶投票決定哪些項目可以得到資助。尤其是資金數額變得非常大時，用戶和組織就有很大的動力去共謀，以獲得這些資金的一部分。這就是MACI能夠真正發揮作用的地方，保護諸如DoraHacks這樣的重要投票過程的公平性。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。