Rumo ao voto anónimo e vinculativo em Ethereum

O anonimato protege a privacidade do eleitor e assegura a livre expressão de opiniões, mitigando o risco de coação ou de represálias. A resistência à censura, por sua vez, garante que nenhuma entidade isolada pode manipular ou negar direitos de voto, reforçando um processo democrático descentralizado, justo e aberto.

Na Vocdoni, o nosso principal objetivo é disponibilizar a pilha tecnológica que permita processos de votação seguros e sem fricção na blockchain Ethereum, em particular para o ecossistema das organizações autónomas descentralizadas (DAO). Pretendemos criar um sistema inovador de votação off-chain, anónima e sem custos de gas, com execução vinculativa.

Este documento descreve a nossa abordagem a esta missão ambiciosa, organizada nas seguintes áreas centrais:

• Construção e verificação de um censo abrangente
• Resolução do problema do determinismo do nullifier, inerente às assinaturas ECDSA
• O mecanismo de emissão de votos off-chain
• O papel e as funções do agregador de votos
• O processo de carregamento dos resultados da votação em Ethereum

1. O censo verificado¶

Enquanto componente central de qualquer sistema de votação, o censo é responsável por enumerar os eleitores elegíveis e atribuir os pesos de voto. No entanto, gerar um censo a partir de dados da blockchain Ethereum apresenta complexidades próprias, entre as quais:

• Estrutura de dados: os dados da blockchain Ethereum não estão estruturados num formato propício à geração de um censo. Por exemplo, para um token ERC20 não existe uma estrutura de dados distinta que mantenha uma lista completa dos detentores do token.
• Compatibilidade criptográfica: a criptografia de Ethereum não é fundamentalmente compatível com os zkSnarks, o que torna mais difícil criar e verificar provas de conhecimento zero.

O grande desafio reside, então, em criar um censo baseado em tokens, compatível com zkSnarks e sem depender de confiança em terceiros, que permita a votação off-chain. É também crucial ter em conta que as transações ERC20 podem ocorrer a qualquer momento, o que implica que o censo pode variar significativamente de um bloco para outro.

Para responder a estes desafios, propomos a seguinte abordagem:

• Censo off-chain: construir um censo off-chain compatível com zkSnarks.
• Geração da prova: gerar uma prova zkSnark que verifique a correção do censo.
• Validação on-chain: validar on-chain a prova de criação do censo através de um contrato inteligente (smart contract).
• Facilitar a votação: após a validação, o censo pode ser utilizado para fins de votação.

A validação do censo em Ethereum pode ser feita de duas formas:

• Verificação de saldos: o contrato inteligente verifica a validade de todos os detentores (ou de um subconjunto) invocando a função balanceOfAt(). Esta abordagem, porém, pode implicar custos de transação elevados para o remetente.
• Storage Proof: a zkProof do censo é criada com provas de armazenamento (storage proofs), e o contrato verifica a sua correção em relação a uma State Root anterior de Ethereum. Embora este método possa ser computacionalmente dispendioso para o construtor do censo, oferece uma solução robusta.

Consideramos que a abordagem de verificação de saldos se adequa melhor a DAOs pequenas (100-200 membros), enquanto a Storage Proof funcionará melhor para grandes organizações capazes de suportar os custos de uma infraestrutura computacional maior.

2. O problema do determinismo do nullifier¶

Ao trabalhar com sistemas criptográficos, o determinismo é crítico: a mesma entrada deve produzir sempre a mesma saída. Contudo, surge um percalço com as assinaturas Ethereum.

As assinaturas ECDSA incluem um nonce arbitrário, um número usado uma única vez ou muito raramente. O signatário pode alterar este nonce para gerar assinaturas diferentes a partir do mesmo conteúdo. O resultado? Não determinismo: saídas diferentes a partir da mesma entrada.

Este não determinismo torna-se um obstáculo no cálculo de um nullifier (anulador), uma ferramenta essencial para impedir o voto duplo. Um nullifier é um identificador único de cada voto. Quando um voto é emitido, o nullifier é registado numa lista pública na blockchain.

Gerar um nullifier determinístico exige um esquema de assinatura determinístico. E, como as assinaturas ECDSA não são determinísticas, não se adequam à geração de nullifiers. Deparamo-nos, assim, com um bloqueio ao tentar impedir votos duplos num sistema de votação anónima e vinculativa em Ethereum.

Introduzimos o conceito de Registo Global de Chaves de Compromisso (Global Registry of Commitment Keys). Um contrato inteligente gere este registo e serve de ferramenta de mapeamento que liga um endereço Ethereum a uma chave de compromisso. A estrutura básica é: Endereço Ethereum => hash(segredo).

A chave de compromisso, gerada a partir de um segredo do utilizador, ajuda a associar um endereço Ethereum a uma saída determinística, garantindo assim o determinismo, crítico para o nosso caso de uso.

Esta informação de mapeamento chave-endereço é armazenada na blockchain Ethereum sob a forma de uma árvore de Merkle compatível com Snarks. As árvores de Merkle são particularmente adequadas para este fim porque permitem criar um sistema eficiente e à prova de adulteração para armazenar e verificar grandes quantidades de dados, um requisito essencial no nosso caso.

Ao emitir um voto, o utilizador tem de fornecer uma prova zkSNARK. Esta prova demonstra que o utilizador conhece o segredo da chave de compromisso, que faz parte da árvore de Merkle de chaves de compromisso armazenada em Ethereum. Isto permite-nos criar um sistema de votação seguro, anónimo e resistente ao voto duplo, sem necessidade de determinismo nas assinaturas ECDSA.

3. Emissão de votos off-chain¶

Com um censo de votação verificado e a raiz de Merkle do Registo Global estabelecidos, pode iniciar-se o processo de emissão de boletins de voto.

Para votar, o utilizador precisa de provar duas coisas:

• Inclusão no censo: o endereço e o saldo do utilizador fazem parte do censo de votação.
• Conhecimento da chave secreta: o utilizador conhece a chave secreta do compromisso atribuído ao seu endereço no Registo Global.

O utilizador constrói então provas zkSnark, anonimizando efetivamente a sua identidade e gerando um nullifier. Este nullifier é calculado de forma determinística através do hash da chave secreta com um identificador único da proposta.

Note-se que, com este mecanismo, dado que o registo global é uma árvore de Merkle compatível com zkSnarks, não precisamos de usar a criptografia de Ethereum (secp256k1) dentro do circuito, o que resulta numa geração de boletins mais eficiente e adequada ao navegador.

O boletim e a prova são agrupados num pacote e distribuídos por uma rede peer-to-peer (p2p) de agregadores. Uma rede p2p descentralizada é fundamental para alcançar resistência à censura, garantindo que nenhuma entidade isolada pode controlar ou manipular o processo de votação.

4. O processo de agregação de votos¶

Uma vez emitidos os votos, estes precisam de ser agregados numa prova zkSnark abrangente. Esta agregação pode ser feita de uma só vez ou em lotes. A prova construída durante este processo verifica o seguinte:

• Um hash de raiz específico do censo de votação
• Um hash de raiz único do registo global
• Uma lista de nullifiers de votos válidos
• A correção dos resultados da votação

Dado que os votos originais são, eles próprios, provas zkSnark, o processo de agregação exige um nível de recursão, ou seja, uma zkSnark que prova a exatidão de outra zkSnark.

Contudo, dado o estado da arte atual e a compatibilidade limitada de Ethereum com curvas elípticas, executar este processo de geração recursiva de provas é um desafio significativo. As complexidades envolvidas significam que talvez tenhamos de aguardar por avanços nos frameworks de zkSnark e por um melhor suporte de Ethereum para a criptografia zkSnark.

5. Carregamento dos resultados em Ethereum¶

Concluída a agregação dos votos, qualquer utilizador pode submeter a prova final a um contrato inteligente de Ethereum. A responsabilidade do contrato inteligente é verificar o seguinte:

• Prova de resultados: a prova dos resultados está correta.
• Raiz do censo de votação: a raiz do censo de votação corresponde à previamente verificada.
• Raiz do registo global: a raiz do registo global é exata.
• Período de votação: o período de votação está em conformidade com o intervalo de tempo predefinido.

Após a verificação bem-sucedida destes elementos, o contrato inteligente pode executar as ações predeterminadas associadas ao processo de votação em Ethereum. Este processo assegura a validade e a integridade dos votos e facilita a implementação