MACI: 온체인 거버넌스의 담합 방지 프레임워크

Eric Zhang

Architect @DoraFactory @DoraHacks

이 기사의 배경은 "Quadratic Voting and Quadratic Funding"(https://matataki.io/p/6113)을 참조하십시오. 이 기사가 게시된 지 한 달 후, BSC 재단은 DoraHacks 개발자 플랫폼 HackerLink에서 BSC 생태계(https://hackerlink.io/grant)를 위한 1차 2차 펀딩을 시작했으며, 이후 15일 동안 프로젝트를 접수했습니다. 전 세계 60개 이상의 개발자 팀이 제출했습니다.

"Quadratic Voting and Quadratic Funding"에서는 Vitalik의 블로그 "Quadratic Payments"에서 언급한 3가지 이슈(Identity Bribery, Conlusion, Rational Ignore Ignorance)를 소개했습니다. 이 세 가지 문제는 2차 투표에만 국한되지 않고 온체인 거버넌스 메커니즘에서 직면하는 일반적인 문제입니다. 따라서 이러한 문제에 대한 솔루션은 2차 투표를 보다 확장 가능하고 안전하게 만들 수 있을 뿐만 아니라 더 많은 온체인 거버넌스 메커니즘에도 도움이 됩니다.

이 문서의 목표는 "비협조적 2차 투표" 또는 "담합 방지 2차 투표" 메커니즘의 설계를 준비하는 것입니다. 이 시나리오에서는 유권자들이 서로 협력할 수 없으므로 공모 가능성이 없습니다. 이 메커니즘의 기본 프레임워크는 Vitalik Buterin이 Ethresear에 게시한 "Minimal anti-collusion Infrastructure" [1] (MACI) 기사입니다. 따라서 먼저 MACI의 메커니즘을 설명하고, MACI를 사용하여 2차 투표를 개선하고 담합 가능성을 제거하는 방법을 추가로 탐색합니다.

MACI: Minimal Anti-Collusion Infrastructure

MACI는 "최소화 충돌 방지 프레임워크"입니다. 배경 자료는 Vitalik Buterin의 블로그 https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413 및 "On Collusion" https://vitalik.ca/general/2019/04/03/collusion을 참조하십시오. .html

설정

설정

공개 키 목록을 포함하는 스마트 계약 \(R\)이 있다고 가정합니다.\(K_1 ... K_n\),그리고 이러한 공개 키를 스마트 계약에 등록하는 데 필요한 몇 가지 기능이 있습니다. 또한 다음 두 가지 신원 확인 조건을 만족하는 참여자의 공개키만이 R에 들어갈 수 있다.

계정은 "합법적인" 참여자(독립적인 사람, 특정 국가의 국적을 가진 특정 커뮤니티의 구성원, 포럼에서 충분히 높은 평판을 가진 사람, 일정량 이상의 토큰을 보유하고 있는 사람)의 소유입니다. .. )

계정 소유자 개인 제어 키(예: 필요한 경우 증명을 위해 인쇄 가능)

각 사용자는 일정 금액을 스테이킹해야 합니다. 누군가 개인 키를 유출하면 개인 키를 얻은 사람이 직접 돈을 인출할 수 있으며 해당 계정은 목록에서 제거됩니다. 이 메커니즘은 개인 키를 다른 사람에게 양도하는 사람을 금지합니다.

또한 개인 키를 가진 운영자(\(operator\))가 있다고 가정합니다.\(k_\omega\),및 해당 공개 키\(K_\omega\).

마지막으로 메커니즘이 있다고 가정합니다.\(M\),그것은 기능이다\(action^n \rightarrow Outputs\),구현하다

구현하다

시작 시간 \(T_{start}\)에서 \(연산자\)가 실제 상태를 시작합니다.\(S_{start} = {i: (key=K_i, action = \phi)}, i \in 1...n\).

시작 시간 \(T_{start}\)과 종료 시간 \(T_{end}\) 사이에 등록된 모든 참가자는 참가자 자신의 개인 키 \(k\) 암호화를 사용하여 R에 메시지를 보낼 수 있습니다. 다음과 같은 두 가지 종류의 메시지가 있습니다.

합의된 행동: 예: 투표. 참가자는 암호화된 메시지를 보내야 합니다.\(enc(msg = (i, sign(msg = action, key = k_i)), pubkey = K_\omega)\),여기서 \(k_i\)는 참가자의 현재 개인 키이고 \(i\)는 \(R\)에 있는 참가자의 ID입니다.

Rekey: 참가자는 암호화된 메시지를 보내야 합니다.\(enc(msg = (i, sign(msg = NewK_i, key = k_i)), pubkey = K_\omega)\),여기서 \(NewK_i\)는 참여자가 변경할 공개 키이며,\(k_i\)는 이 참가자의 현재 개인 키입니다.

이때 운영자의 역할은 각 메시지를 체인에 업로드된 순서대로 처리하는 것입니다. 특정 처리 프로세스:

운영자의 개인 키를 사용하여 메시지를 해독합니다. 복호화에 실패하거나 복호화에 해당하는 정보가 위의 두 가지 유형의 정보로 복호화될 수 없는 경우 이 정보를 직접 건너뛰십시오.

\(state[i].key\)를 사용하여 메시지 서명 확인

디코딩된 메시지가 합의된 동작(\(action\))인 경우 다음을 설정합니다.\(state[i] = action\),디코딩된 메시지가 새로운 공개 키인 경우 다음을 설정합니다.\(state[i].key = NewK_i\)

\(T_{end}\) 이후에 운영자는 출력 상태를 알려야 합니다.\(M(state[1].action, ... , state[n].action)\),동시에 이 출력이 올바른 결과임을 증명하기 위해 ZK-SNARK가 제공됩니다.

이 메커니즘이 공모 방지인 이유

참가자가 \(action\) \(A\)를 수행하는 것과 같이 자신이 수행한 작업을 증명하려고 한다고 가정하면 그는 체인의 트랜잭션을 참조할 수 있습니다.\(enc(msg = (i, sign(msg = A, key = k_i)),pubkey = K_\omega)\), 트랜잭션에 \(A\)의 암호화된 정보가 실제로 포함되어 있는지 확인하기 위해 영지식 증명을 제공합니다. 그러나 그는 자신이 다른 거래를 보내지 않았다는 것을 증명할 수 없습니다. 열쇠, 그는 다른 일을했을 수도 있습니다.

참여자가 개인 키를 다른 사람에게 제공하는 것도 가능하지만 그렇게 함으로써 해당 사람은 키를 갖게 되면 즉시 수정을 시도할 수 있습니다. 이 경우 1) 50%의 성공률이 있고, 2) 키를 얻은 사람이 이전 지분의 예치금을 직접 가져가게 됩니다.

MACI의 해결되지 않은 문제

수신자는 신뢰할 수 있는 하드웨어 환경에서 또는 신뢰할 수 있는 다중 서명의 경우 개인 키를 판매합니다.

원본 개인 키는 신뢰할 수 있는 하드웨어 환경에서 공격을 받아 개인 키가 공격자가 미리 알지 못하는 개인 키로 변경되지 않도록 합니다.

첫 번째 경우에는 특별히 설계된 복잡한 서명 메커니즘을 사용할 수 있으며 이 설계는 신뢰할 수 있는 하드웨어 및 다중 서명에 적합하지 않습니다. 그러나 이 설계는 확인 기능이 ZKP 친화적임을 보장해야 합니다.

두 번째 경우는 "대면 영지식 증명"으로 해결할 수 있습니다.\(Y = y*G\),그리고 \(x\) 및 \(y\)가 포함된 두 개의 봉투를 검증자에게 보여주면 검증자는 하나를 열고 발표된 \(Y\)가 올바른지 확인한 다음 확인합니다.\(X + Y = K_i\)。

비협조적 2차 투표

이 메커니즘은 투표를 포함한 다양한 온체인 거버넌스 메커니즘을 개선하는 데 사용할 수 있습니다. 2차 펀딩에서 담합은 풀 규모가 매우 크거나 2차 펀딩이 더 큰 시나리오(총선거, 의회 예산 승인 등)에서 사용되는 경우 반드시 해결해야 하는 문제가 된다. 따라서 담합 방지 2차 자금 조달 메커니즘을 설계하면 2차 자금 조달을 확장할 수 있습니다.

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

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