O MACI é uma excelente infra-estrutura para evitar conluio em processos de governação como a votação. Oferece um mecanismo que garante que ninguém possa subornar indivíduos de forma confiável.
No entanto, o suborno não tem de visar diretamente os indivíduos: por exemplo, todos os intervenientes também podem ser subornados como um coletivo para favorecer um resultado específico. Esta postagem descreve os ataques de suborno direcionados a coletivos e investiga possíveis soluções.
Subornando o coletivo
Imagine que a configuração MACI usual é fornecida. Temos um registro R que contém n chaves públicas K_1,…,K_n que estão autorizados a votar.
A parte subornadora implementará um contrato de suborno que concede a cada chave pública de R um suborno bise o resultado preferido da votação do subornado vencer.
O contrato de suborno pode ser estabelecido de forma totalmente sem confiança: pode ser financiado antes do início do processo MACI, pode ler o resultado do MACI através de chamadas de contrato inteligentes e, portanto, pode distribuir as subvenções de forma totalmente sem confiança.
Supondo que este contrato de suborno seja implementado, cada eleitor tem um incentivo adicional para votar no resultado preferido do subornado, para aumentar a probabilidade de pagamento.
Vamos investigar os incentivos e seus impactos no caso de uma eleição binária: Cada eleitor tem a opção de votar no partido A ou no partido B e é necessária uma maioria de 51% para vencer a eleição.
Para simplificar, assume-se que cada eleitor tem uma motivação intrínseca para votar no seu partido preferido em detrimento do outro partido, e essa motivação ou utilidade pode ser representada por um valor monetário: v_i para o i-ésimo eleitor. É claro que haverá actores que não serão influenciados por incentivos monetários, votarão sempre no resultado que preferem e depois no seu resultado preferido. v_i pode ser infinito.
Agora, se b_i > v_ia estratégia económica ideal para o eleitor é votar no partido preferido do subornado, para aumentar a probabilidade de um pagamento de suborno mais elevado. Portanto, o subornador pode escolher seu suborno b, tal que v_i por metade do eu \em 1..n
Se a parte preferida do subornador vencer, o custo do suborno deverá ser de pelo menos \Sigma_{i \in n}b = n*b. Se v_i =v_j para todos i,j, isso significa que a parte que suborna tem que comprar toda a utilidade de todos os eleitores para influenciar o voto.
Vamos comparar isto com um processo de votação não-MACI: vamos supor que seria possível subornar indivíduos e que a parte subornadora só pagaria suborno aos eleitores que votassem a favor do seu resultado. Como cada eleitor tem ~1/n chance de ser fundamental e influenciar o resultado, o valor pessoal esperado de cada eleitor em relação à votação é v_i/n. Portanto, enquanto v_i/n < b_ia estratégia ideal é votar no partido preferido do subornador. O custo total para o subornador seria: n*(b_i/n) \simeq b_i assumindo v_i
Assim, em resumo, o MACI aumentou os custos dos subornos por um factor n, eliminando subornos individuais e permitindo apenas subornos colectivos para este cenário específico. Isto é valioso, pois um invasor precisa comprar aproximadamente a utilidade de todos os eleitores para influenciar a votação.
No entanto, ainda existem dois problemas na prática:
- Algumas aplicações não conseguem garantir que a soma da utilidade do seu eleitor seja superior ao valor que poderia ser extraído das suas decisões. Por exemplo, muitas instituições futuras podem ter apenas um utilitário U para detentores normais de tokens vinculados à alma, mas as instituições têm que tomar decisões sobre transações maiores que n*U. Um exemplo concreto poderia ser um novo sistema de arbitragem descentralizado – como o Kleros – governado por detentores de tokens vinculados à alma. Para estas aplicações, é necessário melhorar a relação entre os custos do suborno e a utilidade do eleitor.
- Algumas aplicações podem ter um enorme conjunto de participantes para os quais uma determinada decisão de governação tem apenas pouca utilidade. Num caso extremo, se metade dos eleitores tiver apenas uma \épsilon utilidade para uma decisão de governança específica, então o custo do suborno ainda será apenas \épsilon *n através de subornos coletivos. Isto é verdade, mesmo que para a outra metade dos eleitores a utilidade deste processo de governação seja muito elevada e seja difícil suborná-los.
Combater ataques de suborno de grupo:
A seguir, vamos investigar como o MACI pode ser melhorado para uma melhor defesa contra subornos coletivos. A princípio, observa-se que para processos MACI com resultado público, os subornos coletivos sempre podem ser iniciados de forma não confiável, com a configuração descrita acima. Em segundo lugar, o pagamento de subornos pode ser melhorado para evitar carma negativo para eleitores subornados: Ao utilizar tecnologia – semelhante ao dinheiro tornado –, os subornos podem ser pagos aos participantes de uma forma não rastreável, dando a cada chave pública de eleitor a capacidade de reclamar os seus subornos para um novo endereço de uma forma não rastreável. Isto poderia ser possibilitado preparando para cada eleitor uma nota (cf. notas de dinheiro de tornado) que só pode ser reivindicada por uma prova zk que só pode ser gerada com a chave privada do eleitor.
No contexto dos tokens vinculados à alma, isso significa que os tokens vinculados à alma subornados não receberiam carma negativo, pois ninguém poderia provar que se comportaram mal.
Dado que os subornos colectivos não podem ser facilmente evitados, propõe-se a seguir um método para aumentar o factor de custo dos subornos colectivos em comparação com os subornos individuais para além da soma da utilidade de todos os eleitores. Felizmente, ao introduzir uma pequena alteração nas especificações, isso pode ser arquivado:
Aumentando o custo dos ataques de suborno em grupo com eleitores falsos:
Imagine que o registro R contém não apenas as n chaves públicas K_1,…,K_n mas também para cada chave K_i um vetor de peso de votação (w_{i1}, w_{i2},… w_{in}) é dado. Os pesos são informações não públicas e são conhecidos apenas pelo mantenedor do R e pelo operador votante.
No início, o registro R está vazio. Para adicionar novos k chaves públicas ao registro, o mantenedor adicionaria merda contas para o registro. O k*(s-1) contas adicionais serão contas falsas que possuem um vetor de peso de votação de apenas zeros (0,…,0). Isso pode ser feito sem confiança: o operador pode gerar uma prova zk que (s-1)*k das contas adicionadas têm um vetor de peso de voto zero.
Na configuração do token vinculado à alma, a determinação e adição de pesos também podem acontecer de maneira não confiável: por exemplo, para cada peso diferente de zero de uma conta recém-adicionada, pode haver a necessidade de um processo de verificação que produza uma prova zk verificando a exatidão da adição de peso. Via recursão, essas provas poderiam ser usadas para construir uma prova zk geral, verificando se todos os pesos de um registro foram atualizados corretamente.
Essas propriedades comprovadas NÃO devem ser conhecidas publicamente sobre o detentor do token vinculado e devem ser compartilhadas apenas com o operador. Se o titular da conta compartilhasse essas propriedades abertamente e pudesse provar certas propriedades a uma parte subornadora, o titular da conta seria subornável e, portanto, deveria ser removido do registro novamente. Os vetores de peso de votação podem então ser usados arbitrariamente pelos algoritmos de votação.
Dada esta configuração, imagine que um invasor queira iniciar um suborno coletivo. Como um invasor externo não pode saber quais dos eleitores no registro são eleitores falsos, ele terá que subornar todos os eleitores no registro. Portanto, para n eleitores válidos com pesos de voto positivos, o subornador tem que subornar merda chaves públicas. Isto aumenta o custo do suborno coletivo por um fator éonde é é teoricamente arbitrário grande, mas com certeza terá limitações práticas. Se alguém iniciou um suborno coletivo, o mantenedor do registro deverá ter acesso a todas as contas falsas e também reivindicar as recompensas do suborno pelas contas falsas, para incorrer em um custo para o subornador coletivo.
Esta abordagem é promissora, uma vez que os subornos colectivos podem tornar-se arbitrariamente ineficazes através do aumento do número é.
No entanto, esta configuração só funcionará se a privacidade dos verdadeiros eleitores for garantida. Se os eleitores forem conhecidos ou puderem ser obtidos estatisticamente, a protecção não funcionará, pois o subornador pode simplesmente subornar o colectivo de prováveis eleitores.
Isso é complicado em muitas aplicações: imagine um DAO que deseja recrutar seus eleitores entre a multidão de detentores de tokens vinculados à alma que atendem a alguns critérios/métricas. Se as informações sobre os critérios forem públicas, então o subornador pode simplesmente subornar os endereços vinculados diretamente, em vez dos endereços no registro R. Portanto, cada DAO deve obter seus eleitores de um enorme conjunto de contas potenciais com propriedades/informações não públicas sobre essas contas. As informações devem ser privadas, mas ainda assim devem ser verificáveis para o mantenedor do registro R para facilitar a atribuição dos pesos de voto corretos.
Perguntas abertas
Estou realmente curioso sobre seus pensamentos.
Fontesethresear
