La investigación más reciente de Vocdoni sobre procesos de votación seguros fuera de la cadena.
Ferran
· 11 min de lectura
Este artículo propone una prueba de concepto que aprovecha los zk-SNARKs para alcanzar la siguiente frontera de la gobernanza: una gobernanza on-chain sin gas, verificada y vinculante.
El contenido técnico de esta propuesta también se ha publicado en el foro Ethresear.ch aquí para su debate con la comunidad.
Como proyecto de referencia en gobernanza electrónica, Vocdoni invierte mucho en investigar e innovar en modelos de gobernanza. Hemos identificado varias soluciones de gobernanza de capa 2 con potencial, pero que dejan abiertas varias cuestiones técnicas. Hemos logrado procesos de votación sin gas en nuestra blockchain de votación especializada, la Vochain, y hemos diseñado e implementado un método que usa pruebas de almacenamiento de Ethereum (Storage Proofs) para trasladar censos basados en tokens ERC20 desde Ethereum a la Vochain. Sin embargo, hasta ahora la posibilidad de llevar los resultados de vuelta a Ethereum seguía siendo una cuestión de investigación abierta.
Con este fin, Vocdoni ha estado experimentando con un nuevo diseño que permitiría trasladar a Ethereum los resultados de un proceso de votación celebrado fuera de la cadena, sin usar oráculos subjetivos ni ningún otro componente que exija confianza.
La innovación central de esta propuesta es clara: no conocemos ningún sistema capaz de organizar un proceso de votación fuera de la cadena y ejecutar acciones en Ethereum en función de sus resultados sin necesidad de confianza. Los casos de uso de esta propuesta abarcan potencialmente todos los procesos de gobernanza que ejecutan acciones vinculantes según los resultados, como (entre otros) las votaciones de las DAO sobre la asignación de activos o sobre cambios en contratos inteligentes (smart contracts). Hoy en día, estos procesos de gobernanza deben celebrarse en la mainnet de Ethereum, con comisiones de gas considerables para cada votante. La alternativa es votar fuera de la cadena, pero confiando en un componente externo para que transmita los resultados a Ethereum con exactitud y honestidad.
Nuestra propuesta permitiría que procesos de votación celebrados íntegramente fuera de la cadena ejecuten sus resultados en Ethereum con la misma integridad que la gobernanza on-chain, a una fracción del coste.
Antes de idear una solución técnica, definimos los parámetros de nuestra propuesta de investigación.
Los requisitos para el protocolo de votación eran:
Al tratarse de un diseño de prueba de concepto, aceptamos las siguientes limitaciones en la propuesta:
Según el diseño de esta propuesta, al crear un nuevo proceso de votación los organizadores envían una transacción a Ethereum que especifica la dirección del contrato de un token ERC20 que se usará como censo de votantes. El Storage Root Hash de esa dirección, a una altura de bloque determinada, se convierte en la raíz del censo del proceso. Cualquiera que posea el token puede demostrar su elegibilidad aportando una prueba de Merkle (mediante EIP1186) de su saldo del token. Después puede emitir su voto enviando la prueba (siblings) y una firma a un relayer de rollup zk-SNARK, que computará una prueba de los resultados finales.
Un posible problema es que el actor que computa la prueba zk-SNARK de los resultados (el coordinador) podría, en teoría, censurar el resultado excluyendo votos. Lo resolvemos permitiendo que cualquiera (no solo el coordinador) envíe votos nuevos: cualquier usuario puede generar y enviar un rollup con su voto si detecta que un coordinador no lo ha incluido.
Nuestra propuesta usa los zk-SNARKs para los siguientes fines:
Ejecución vinculante en Ethereum con zkSNARKs: propuesta idealizada.
En el esquema anterior podemos identificar dos problemas principales:
Las Storage Proofs de ERC20 son muy complejas de verificar dentro de un SNARK. Esto se debe en parte a que usan parsing de Recursive Length Prefix (RLP) y múltiples verificaciones de hashes Keccak-256, ambas ineficientes de computar con la tecnología puntera actual de rollups SNARK. Es un problema difícil de sortear, así que de momento lo resolvemos con validación optimista.
Un estándar criptográfico actual que podríamos usar para verificar las firmas de los usuarios es ECDSA con una clave BabyJubJub derivada de una firma de Ethereum, usando la firma como clave privada en bruto, lo que permite al usuario recuperar su dirección. Como este método depende de una firma del usuario, es vulnerable a que agentes maliciosos engañen a los usuarios para que firmen transacciones fraudulentas en su cartera Web3. Esta vulnerabilidad existe siempre que se usa una cartera de navegador para firmar una transacción. Una posible solución sería derivar una clave privada usando la dirección web como ruta de derivación.
Un reto adicional es demostrar que la dirección de Ethereum de cada titular de tokens aprueba la clave BabyJubJub para votar a la altura de bloque en que se crea el proceso de votación. Lo conseguimos con un contrato inteligente «singleton» que mapea direcciones de Ethereum a claves públicas BabyJubJub, en el que el usuario debe añadir su clave mediante una transacción estándar. El mapeo de una dirección a una clave puede impugnarse mediante una prueba de fraude optimista sobre el almacenamiento (puesto que ya hemos abierto la puerta a la validación optimista de Storage Proofs). Esta solución también resuelve el problema de la disponibilidad de datos con un diseño reutilizable, ya que se espera que estas claves autorizadas se usen varias veces en distintos procesos de votación.
En resumen, podemos realizar la mayoría de las verificaciones dentro de un SNARK, pero no todas:
Ejecución vinculante en Ethereum con zkSNARKs: propuesta
Un zk-SNARK agregará una lista de votos emitidos. La prueba zk-SNARK es válida respecto a una lista de votos dada, una raíz de censo, un identificador de elección (electionId) y un resultado agregado.
El circuito y el contrato
ENTRADAS DEL zk-SNARK
Las entradas de la llamada a la función del contrato inteligente para subir los resultados del coordinador son:
Hemos implementado los contratos inteligentes y circuitos mínimos viables para comprobar los costes y la viabilidad de la solución aquí. Esta PoC solo incluye el registro de usuarios, la agregación de votos y la verificación de pruebas de fraude.
Nuestras pruebas arrojaron los siguientes costes 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)
En las mediciones para estimar un número viable de votos a agregar, con un servidor estándar de 32 GB de RAM y 8 CPU comprobamos que es posible agregar hasta 300 votos (con un acumulador de árbol de Merkle de 64 niveles y ~3,8 millones de restricciones), tardando 450 segundos en crear la prueba y consumiendo 30 GB de RAM. Para las pruebas usamos Groth16 con Circom, generación del witness en C++ y rapidSNARK.
Como aspecto positivo, la prueba que hay que computar para generar una prueba de fraude es lo bastante pequeña (50k) como para generarse en un navegador. Esto permite a los usuarios impugnar un lote de votos sin descargar ningún software especializado.
A partir de esta investigación, nos gustaría explorar con más profundidad las siguientes ideas:
Vocdoni ha desarrollado un nuevo protocolo DKG no interactivo por diseño, operativamente asíncrono en la práctica y construido a partir de primitivas criptográficas estándar.
Jordi Pinyana
7 min de lectura
Durante los últimos años, Vocdoni ha operado sus votaciones sobre Vochain, nuestra blockchain L1 diseñada específicamente para votar. Como cualquier blockchain, nos dio algo muy potente:…
Pau Escrich
5 min de lectura
Hemos cerrado con éxito una ronda presemilla de 1 millón de dólares de inversores ángeles para desarrollar DAVINCI. DAVINCI supera las limitaciones de los sistemas de votación existentes y ofrece una solución resistente a la censura, sin gas, antisoborno, escalable y anónima para la gobernanza digital.
Pau Escrich
6 min de lectura