Aragon의 최신 연구: zk-Rollups를 통한 안전한 오프체인 투표
Katie 辜
2021-10-17 01:01
本文约4024字,阅读全文需要约16分钟
Ethereum에서 zk-Rollups를 사용한 바인딩 실행.

이 기사는Aragon이 기사는

보조 제목

배경

배경선도적인 디지털 거버넌스 프로젝트인 Aragon Labs는 연구 및 혁신적인 거버넌스 모델에 막대한 투자를 해왔습니다. 우리는 잠재력을 보여주지만 일부 기술적인 문제도 있는 다양한 계층 2 거버넌스 솔루션을 확인했습니다.

우리는 전용 투표 블록체인인 Vochain에서 무가스 투표 프로세스를 구현할 수 있었고, 이더리움 크로스체인에서 ERC-20 생성 코인 통계를 기반으로 하는 이더리움 스토리지 증명을 사용하는 방법을 설계 및 구현했습니다. 보체인. 하지만 지금까지 크로스체인 결과를 이더리움으로 전송할 가능성은 열린 연구 질문이었습니다.이를 위해 Aragon Labs는 새롭게 설계된 실험을 진행하고 있습니다.

이 디자인은 오프체인 투표 프로세스의 결과가 주관적인 오라클이나 다른 신뢰할 수 있는 구성 요소를 사용하지 않고 이더리움에 크로스체인될 수 있도록 합니다.

우리의 제안은 온체인 거버넌스 비용의 일부만으로 온체인 거버넌스와 동일한 무결성으로 이더리움에서 시행되는 결과와 함께 완전히 오프체인에서 이루어지는 투표 프로세스를 허용할 것입니다.

보조 제목

투표 프로토콜 개념 증명 요건

기술 솔루션을 설계하기 전에 연구 프로토콜의 매개변수를 정의했습니다.

  1. 투표 프로토콜의 요구 사항은 다음과 같습니다.

  2. 라이선스가 필요하지 않습니다.

  3. 검열에 대한 저항;

  4. Ethereum에서 결과를 바인딩하는 기능

  5. 가스비를 내지 않는 유권자

  6. 토큰 크로스체인이 없습니다.

  7. 가능한 한 간단하게(사이드 체인 없음);

ERC-20/ERC-777 및 NFT로 투표에 사용할 수 있습니다.

  1. 개념 증명 설계로서 다음 제약 조건을 허용합니다.

  2. 사용자 익명성 없음: 투표는 이더리움 주소에 바인딩될 수 있습니다.

  3. 영수증 없이는 안 됩니다. 투표 용지를 구입할 수 있습니다.

  4. 릴레이어에 대한 명확한 인센티브 체계는 없습니다.

보조 제목

이상적인 제안

제안의 디자인에 따르면, 새로운 투표 프로세스를 생성할 때 주최자는 유권자 인구 조사를 위해 ERC-20 토큰의 계약 주소를 지정하는 트랜잭션을 Ethereum에 제출합니다. 이 주소의 저장소 루트 해시는 지정된 블록 높이에서 이 프로세스의 센서스 루트가 됩니다. 주어진 토큰을 보유한 사람은 누구나 토큰 잔액의 Merkle Proof를 제공하여 자격을 증명할 수 있습니다(EIP-1186을 통해). 그런 다음 그들은 최종 결과의 증명을 계산할 zk-SNARK 롤업 릴레이에 증명과 서명을 전송하여 투표할 수 있습니다.

존재하는 잠재적인 문제는 이론적으로 결과를 계산한 zk-SNARK 증명의 참가자(코디네이터)가 투표를 제외하기로 결정하여 결과를 검토할 수 있다는 것입니다. 우리는 (코디네이터뿐만 아니라) 누구나 새 투표를 제출할 수 있도록 허용하여 이 문제를 해결합니다. 모든 사용자는 코디네이터가 투표를 포함하지 않은 것을 감지하면 자신의 투표가 포함된 집계를 생성하고 제출할 수 있습니다.

  • 우리의 제안은 다음 목적을 위해 zk-SNARKS를 사용할 것입니다.

  • Merkle Tree 누산기를 통해 투표하지 않고 주소를 검증합니다.

  • 저장소 증명을 통해 사용자가 토큰을 소유하고 있는지 확인합니다.

  • 투표 배치의 부분 결과를 계산합니다.

위의 패턴을 기반으로 두 가지 주요 문제를 찾을 수 있습니다.

보조 제목

ERC-20 저장소 증명은 SNARK에서 확인하기가 매우 복잡합니다. 이는 부분적으로 RLP(재귀 길이 접두사) 구문 분석 및 다중 Kecmack -256 해시 검증을 사용하기 때문인데, 둘 다 최첨단 SNARK 요약 기술에서 계산상 비효율적입니다. 이 문제는 해결하기 어렵기 때문에 현재 이 문제를 해결하기 위해 낙관적 검증을 사용합니다.

보조 제목

문제 2: ECDSA/Secp256k1 서명 확인은 SNARK에 적합하지 않습니다.

사용자 서명을 확인하는 데 사용할 수 있는 현재 암호화 표준 중 하나는 ECDSA입니다. ECDSA는 이더리움 서명의 BabyJubJub 키를 사용하고 해당 서명을 원래 개인 키로 사용하여 사용자가 주소를 복구할 수 있도록 합니다. 이 방법은 사용자 서명에 의존하기 때문에 사용자를 속여 Web3 지갑에서 사기 거래에 서명하도록 하는 악의적인 프록시에 취약합니다. 이 취약점은 브라우저 지갑이 트랜잭션에 서명하는 데 사용하는 모든 곳에 존재합니다. 잠재적인 솔루션은 웹 주소를 파생 경로로 사용하여 개인 키를 파생시키는 것입니다.

또 다른 과제는 각 토큰 소유자의 이더리움 주소가 BabyJubJub 공개 키가 투표 프로세스에 의해 생성된 블록 높이에서 투표하도록 승인한다는 것을 증명하는 것입니다. 우리는 이더리움 주소를 BabyJubJub 공개 키에 매핑하는 "싱글톤" 스마트 계약을 통해 이를 수행하며 사용자는 표준 트랜잭션을 통해 스마트 계약에 키를 추가해야 합니다. 주소-키 매핑은 낙관적 스토리지 사기 증명으로 달성할 수 있습니다. 이러한 인증 키는 다양한 투표 프로세스에서 여러 번 사용될 것으로 예상되기 때문에 이 솔루션은 재사용 가능한 설계를 통해 데이터 가용성 문제도 해결합니다.

  • 요약하면 다음을 제외하고 SNARK에서 대부분의 검증을 처리할 수 있습니다.

  • 이전에 Merkle tree 누산기 → SNARK를 통해 주소가 투표되지 않았는지 확인합니다.

  • Storage proof → Optimistic을 통해 사용자가 토큰을 가지고 있는지 확인합니다.

  • 보조 제목

사용자

  • 사용자

  • 계정의 투표 정보와 저장 증명을 검색하고, 투표 패킷에 서명을 생성하고, 릴레이어 또는 릴레이어 그룹에 전달합니다.

보조 제목

투표 스마트 계약

ERC-20 스마트 계약 주소, ERC-20 주소의 슬롯 인덱스 → 잔액 매핑, 투표 프로세스 시작 블록의 상태 루트 해시 및 투표 계산을 위한 프로세스 매개변수를 포함한 투표 프로세스를 등록합니다.

  • zk-Rollup을 통해 새로운 투표 등록을 모니터링함으로써 SNARK는 다음을 증명합니다.

  • 결과 계산;

  • 투표 서명은 BabyJubJub 키에 의해 결정됩니다.

  • 투표 누산기를 최신 상태로 유지하십시오.

유권자 목록을 최신 상태로 유지하십시오.

  • 누구든지 마지막 투표 등록 사기의 증거에 이의를 제기할 수 있습니다. 단, 다음 조건 중 하나를 충족해야 합니다.

  • 유권자의 이더리움 주소에 토큰이 없음을 증명하는 저장 증명;

  • BabyJubJub 키가 투표했다는 증거(키는 "투표된" Merkle 트리에 있음).

보조 제목

  • 릴레이어

  • 0단계: 이더리움에서 선거 프로세스가 생성되고 사용 가능한 릴레이어 목록에서 릴레이어가 선택됩니다. 선거 주최자는 선거 수수료를 지불해야 합니다(코디네이터에게 보상). 주최자는 결과에 따라 DAO 스마트 계약 선출 후 실행해야 하는 EVM 바이트코드를 제공합니다.

  • 1단계: 투표가 시작됩니다. 누구나 선택한 코디네이터에게 투표 패킷(HTTP 또는 libp2p 전송)을 보낼 수 있습니다. 코디네이터는 선택한 결과를 배치로 롤업하고 zk-SNARK 증명을 빌드하고 증명과 결과를 이더리움에 업로드하고 사용자가 던진 투표를 수집하고 확인하고 다른 중계자에게 브로드캐스트합니다.

  • 2단계: 자신이 투표에 참여하지 않았음을 감지한 코디네이터는 자신의 투표를 롤업하고 zk-SNARK 유효성 증명을 투표 스마트 계약에 보낼 수 있습니다. 또한 투표가 잘못 추가된 것을 감지하면 이전에 추가된 결과가 유효하지 않다는 사기 증거를 보낼 수 있으며 이를 생성한 코디네이터가 삭감됩니다.

    3단계: 투표 날짜 제한에 도달하면:

    누구나(일반적으로 코디네이터) 최종 결과를 입력으로 사용하여 EVM 바이트코드 실행을 호출합니다.

보조 제목

라인과 계약

zk-SNARK는 투표 목록을 집계합니다. zk-SNARK 증명은 주어진 투표 목록, 인구 조사 루트, 선거 식별자(electionId) 및 집계된 결과를 기반으로 유효합니다.

  • zk-SNARK의 입력:

  • 해시 입력은 SNARK 검증의 가스 비용을 줄이기 위한 것입니다.

  • 개인 선거 식별자;

  • 계산된 투표 결과

  • 현재 nullifiers 루트(nullifiers root);

  • 업데이트된 빈 룬 뿌리;

  • 배치의 투표 수;

투표 값 및 해당 BabyJubJub 키 서명.

  • 조정 결과를 업로드하기 위한 스마트 계약 함수 호출에 대한 입력은 다음과 같습니다.

  • 선거 식별자;

  • 배치에 있는 유권자의 공개 키 목록입니다.

  • 업데이트된 빈 룬 뿌리;

  • SNARK 증거.

보조 제목

개념 구현 증명

우리는 최소한의 실행 가능한 스마트 계약 및 회로를 구현하여 솔루션의 비용과 타당성을 확인했습니다. 개념 증명에는 사용자 등록, 투표 집계 및 사기 증명 확인만 포함됩니다.

  • 테스트 결과 다음과 같은 가스 비용이 발생했습니다.

  • 사용자 키 레지스트리 배포: 258536

  • 등록: 68956

  • 투표 배포: 6673,159

  • 새로운 투표: 25989

  • 누적 요약: 291801

  • 사기 증거 2: 908822(계정 ERC-20 잔액이 0임)

보조 제목

미래 연구

  1. 이 연구를 바탕으로 다음 아이디어를 더 깊이 탐구하고자 합니다.

  2. SNARK를 통한 표준 kecak/ECDSA/Sec256k1 서명 확인. 우리는 곧 PLOOKUP이 이러한 체계를 검증할 수 있을 것이라고 믿으며, 이는 두 가지 가능성으로 이어질 것입니다.

  3. BabyJubJub 키가 Secp256k1 키에서 파생되었음을 증명합니다.

  4. 투표 서명 자체를 확인하십시오.

  5. 저장 증명은 SNARK 내부에서 확인됩니다. 비용이 많이 들지만 이러한 종류의 복잡한 배선을 zkVM으로 쉽게 통합할 수 있다고 생각합니다. 우리는 Ethereum 클라이언트가 더 높은 가스 비용 제한을 우선시하여 아카이브 노드에서 탈락할 것을 우려하므로 또 다른 연구 영역은 저장 증명을 위해 EIP1186 이외의 방법을 시도하는 것입니다.

  6. 카운트를 계산하기 위해 일부 opcode가 내장되어 zkVM에서 실행되므로 일반 프로그래밍 가능 투표 회로를 사용할 수 있습니다.zk.money투표 증명은 브라우저에서 생성되고 일괄 처리를 통해 혼합되며 결과는 다음과 같이 재귀적으로 집계됩니다.

  7. 규약. 이렇게 하면 투표 과정의 프라이버시가 향상됩니다.

  8. 계산 비용이 많이 들더라도 SNARK를 브라우저 수준에서 분산 방식으로 계산할 수 있습니다. 이를 통해 가시성이 높은 서버에 대한 의존도를 줄이고 완전한 P2P로 유권자에게 모든 권한을 부여합니다.

  9. 네트워크 수준에서 투표 프로토콜에 개인 정보 보호 및 혼합을 포함합니다.

  10. 이더리움 2.0과 완벽하게 상호 운용 가능한 합리적인 암호화 경제 모델을 찾으십시오.

Katie 辜
作者文库