A pesquisa mais recente da Vocdoni sobre processos de votação seguros fora da cadeia.
Ferran
· 11 min de leitura
Este artigo propõe uma prova de conceito que utiliza zk-SNARKs para alcançar a próxima fronteira da governança: governança on-chain sem custos de gas, verificada e vinculante.
O conteúdo técnico desta proposta também foi publicado no fórum Ethresear.ch, aqui, para discussão com a comunidade.
Como projeto de referência em governança digital, a Vocdoni investe fortemente em pesquisa e inovação de modelos de governança. Identificamos diversas soluções de governança em layer 2 que mostram potencial, mas que também deixam em aberto várias questões técnicas. Já conseguimos viabilizar processos de votação sem custos de gas na nossa blockchain de votação especializada — a Vochain —, além de projetar e implementar um método que usa provas de armazenamento do Ethereum (Storage Proofs) para trazer censos baseados em tokens ERC20 do Ethereum para a Vochain. Até agora, porém, a possibilidade de levar os resultados de volta ao Ethereum permanecia uma questão de pesquisa em aberto.
Com esse objetivo, a Vocdoni vem conduzindo experimentos com um novo design que permitiria transferir os resultados de um processo de votação off-chain para o Ethereum, sem usar oráculos subjetivos nem qualquer outro componente que exija confiança.
A inovação central por trás dessa proposta é clara: nenhum sistema que conhecemos é capaz de organizar um processo de votação off-chain e executar ações no Ethereum de forma trustless com base nos resultados desse processo. Os casos de uso desta proposta incluem, potencialmente, todos os processos de governança que executam ações vinculantes a partir dos resultados, como (mas não apenas) DAOs votando sobre alocação de ativos ou mudanças em contratos inteligentes (smart contracts). Hoje, esses processos de governança precisam ocorrer na mainnet do Ethereum, gerando taxas de gas substanciais para cada eleitor. A alternativa seria votar off-chain, mas confiando em um componente externo para retransmitir os resultados ao Ethereum de forma precisa e honesta.
Nossa proposta permitiria que processos de votação realizados inteiramente off-chain executassem resultados no Ethereum com a mesma integridade da governança on-chain, por uma fração do custo.
Antes de conceber uma solução técnica, definimos os parâmetros da nossa proposta de pesquisa:
Os requisitos eram que o protocolo de votação fosse:
Por se tratar de um design de prova de conceito, aceitamos as seguintes limitações na proposta:
No design desta proposta, ao criar um novo processo de votação, os organizadores enviam uma transação ao Ethereum especificando o endereço do contrato de um token ERC20 a ser usado como censo de eleitores. O Storage Root Hash desse endereço, em uma altura de bloco especificada, torna-se a raiz do censo desse processo. Qualquer pessoa que detenha o token em questão pode provar sua elegibilidade fornecendo uma prova de Merkle (via EIP1186) do seu saldo do token. Em seguida, pode registrar seu voto enviando a prova (siblings) e uma assinatura a um relayer de rollup zk-SNARK, que computará uma prova dos resultados finais.
Um problema potencial é que o ator que computa a prova zk-SNARK dos resultados (o coordenador) poderia, em teoria, censurar o resultado ao decidir excluir votos. Resolvemos esse problema permitindo que qualquer pessoa (não apenas o coordenador) envie novos votos: qualquer usuário pode gerar e enviar um rollup contendo seu voto se detectar que um coordenador não o incluiu.
Nossa proposta usa zk-SNARKs para os seguintes fins:
Execução vinculante no Ethereum com zkSNARKs — proposta idealizada.
No esquema acima, podemos identificar 2 problemas principais:
Storage Proofs de ERC20 são muito complexas de verificar dentro de um SNARK. Isso se deve, em parte, ao uso de parsing de Recursive Length Prefix (RLP) e a múltiplas verificações de hash Keccak-256, ambas ineficientes de computar na tecnologia de rollups SNARK do estado da arte. É um problema difícil de contornar, então, por ora, resolvemos isso usando validação otimista.
Um padrão criptográfico atual que poderíamos usar para verificar as assinaturas dos usuários é o ECDSA com uma chave BabyJubJub derivada de uma assinatura Ethereum, usando a assinatura como chave privada bruta, o que permite ao usuário recuperar seu endereço. Como esse método depende de uma assinatura do usuário, ele é vulnerável a agentes maliciosos que induzam os usuários a assinar transações fraudulentas em sua carteira Web3. Essa vulnerabilidade existe sempre que uma carteira de navegador é usada para assinar uma transação. Uma solução potencial seria derivar uma chave privada usando o endereço web como caminho de derivação.
Um desafio adicional é provar que o endereço Ethereum de cada detentor de tokens aprova a chave BabyJubJub para votar na altura de bloco da criação do processo de votação. Conseguimos isso com um contrato inteligente 'singleton' que mapeia endereços Ethereum para chaves públicas BabyJubJub, no qual o usuário deve adicionar sua chave por meio de uma transação padrão. O mapeamento de um endereço para uma chave pode ser contestado por meio de uma prova de fraude otimista de armazenamento (já que abrimos a porta para a validação otimista das Storage Proofs). Essa solução também resolve o problema de disponibilidade de dados com um design reutilizável, pois espera-se que essas chaves autorizadas sejam usadas várias vezes em diferentes processos de votação.
Em resumo, conseguimos tratar a maioria das verificações dentro de um SNARK, mas não todas:
Execução vinculante no Ethereum com zkSNARKs — proposta
Um zk-SNARK agregará uma lista de votos emitidos. A prova zk-SNARK é válida com base em uma lista de votos, uma raiz de censo, um identificador de eleição (electionId) e um resultado agregado.
O circuito e o contrato
ENTRADAS DO zk-SNARK
As entradas da chamada à função do contrato inteligente para o envio dos resultados do coordenador são:
Implementamos os contratos inteligentes e circuitos mínimos viáveis para verificar os custos e a viabilidade da solução, disponíveis aqui. Esta PoC inclui apenas o registro de usuários, a agregação de votos e a verificação de provas de fraude.
Nossos testes registraram os seguintes custos de gas:
user key registry
deployment 258,536
registration 68,956
voting
deployment 6,673,159
new voting 25,989
aggregate rollup 291,801
fraud proof-1 574,574 (babyjubjub key not registered)
fraud proof-2 908,822 (account ERC20 balance is zero)
Em medições para estimar um número viável de votos a agregar, usando um servidor padrão com 32 GB de RAM / 8 CPUs, constatamos que é possível agregar até 300 votos (com um acumulador de árvore de Merkle de 64 níveis e ~3,8 milhões de constraints), levando 450 segundos para criar a prova e consumindo 30 GB de RAM. Para as provas, usamos Groth16 com Circom, geração de witness em C++ e rapidSNARK.
Do lado positivo, a prova que precisa ser computada para gerar uma prova de fraude é pequena o suficiente (50k) para ser gerada em um navegador. Isso permite que os usuários contestem um lote de votação sem baixar nenhum software especializado.
A partir desta pesquisa, gostaríamos de explorar as seguintes ideias com mais profundidade:
A Vocdoni desenvolveu um novo protocolo de DKG que é não interativo por design, operacionalmente assíncrono na prática e construído a partir de primitivas criptográficas padrão.
Jordi Pinyana
6 min de leitura
Nos últimos anos, a Vocdoni executou votações na Vochain, nossa blockchain L1 dedicada a votação. Como qualquer blockchain, ela nos deu algo poderoso:…
Pau Escrich
5 min de leitura
Levantamos com sucesso uma rodada pre-seed de US$ 1 milhão com investidores-anjo para desenvolver o DAVINCI. O DAVINCI supera as limitações dos sistemas de votação existentes, oferecendo uma solução resistente à censura, sem custos de gas, antissuborno, escalável e anônima para a governança digital.
Pau Escrich
6 min de leitura