¿Podemos construir un contrato inteligente en el que no sea posible ver el voto real hasta que finalice el período de votación? Una idea es usar hashing. Los votantes pueden enviar una versión codificada de un voto. El problema con la votación es que solo hay dos opciones, pero podemos agregar algo como sal para evitar esto. Y luego, después del final del período de votación, los votantes deben revelar sus votos. Envían sus valores sin cifrar y contratan comprobaciones de que el valor hash es el mismo que el proporcionado durante el período de votación.
El problema es que hay un paso adicional para los votantes y, por lo tanto, no se puede utilizar.
¿Algunas ideas?
Buena idea. keccakSí, un esquema de compromiso-revelación es una primitiva de la criptografía que es fácil de implementar en Ethereum usando, por ejemplo, la función hash incorporada .
La sal que menciona también se conoce como un "factor de cegamiento" en criptografía, un valor elegido al azar que oculta lo que notó que es un valor hash determinista de SÍ o NO. Su único paso adicional (revelar el voto después) se puede resolver con pruebas de conocimiento cero como se describe en los dos esquemas a continuación, que eliminan la necesidad de revelar y cuentan los votos mientras aún están encriptados. (Operar con datos cifrados sin revelarlos a veces se denomina "homomorfo")
Existe un esquema de voto privado . Hay muchos pasos adicionales involucrados en lugar de solo enviar y codificar un voto, pero todos estos pasos se pueden realizar con el software del cliente durante el período de votación y no requieren un paso adicional de todos los votantes para contar.
Un segundo esquema, que es más eficiente en costos de gas, utiliza el protocolo AZTEC ( https://www.aztecprotocol.com/ ) que ya está implementado y funcionando en mainnet. En resumen, el esquema funciona como
El comisionado electoral, para cada elemento de la boleta, crea un token de "seguridad" o ERC1724 y emite un voto "sí" (de valor 1) a cada votante registrado.
Cada votante (o su software cliente) crea dos nuevos votos, otro "sí" de valor 1 y un "no" de valor 0 (una nota señuelo), y convierte su voto asignado en dos votos, con factores de cegamiento, que ambos parecen aleatorios para el público.
Cada votante paga su nuevo yesvoto a una dirección/contrato de Ethereum que representa el resultado de la boleta que desea, y su nuevo novoto a otra dirección/contrato de Ethereum que representa el otro resultado. (Podría ser múltiple, por ejemplo, una elección presidencial podría tener 3 candidatos). Esto se hace usando el método ERC1724 confidentialTransferusando lo que se conoce como prueba de unión y división, la suma de los votos de entrada es igual a la suma de los votos de salida.
Después de que finaliza el período de votación, cada contrato de resultado está programado para comparar su saldo (la cantidad de yesvotos que recibió) entre sí usando privateRangeo publicRangepruebas, dependiendo de si la elección quiere que cada candidato revele la cantidad de votos que recibió en lugar de solo comparando quién tiene más.
El ganador se registra en cadena mediante otro contrato de conteo de votos, y tal vez pueda ser apelado por un panel de jueces de la corte suprema a través de la Corte de Aragón o un protocolo de adjudicación similar.
Lo más simple (y mejor en mi opinión) es hacer lo que dijiste y hash con una sal aleatoria y hacer un patrón de confirmación/revelación. Dado que todo en el EVM es público y legible por naturaleza, no hay forma de bloquear el tiempo de confidencialidad de los datos comprometidos sin intervención externa sin confiar en un tercero (por ejemplo, todos le dan sus votos sin cifrar y usted los revela al final). , haciendo que el usuario solo tenga que hacer una acción, pero requiriendo que no filtre/actúe sobre los votos)
poliani
Pablo Pham
poliani