Final review before the Amoy deploy: hidden re-votes, a tally proved on chain, security and quality

[CodeInIA]

Resumen

Revisión completa del proyecto (contratos, backend, frontend, CLI de recuento y CI) antes de desplegar en Polygon Amoy, corrección de todo lo encontrado que tenía arreglo en código y, sobre eso, re-votos invisibles: nadie que observe la cadena puede saber que un votante ha cambiado su voto. Lo más importante:

• Re-votos invisibles. Las papeletas pasan de Paillier a ElGamal exponencial sobre Baby Jubjub con pruebas de conocimiento cero (dos circuitos circom nuevos). Una primera papeleta y un re-voto son idénticos en la cadena y no comparten ningún valor público.
• El recuento se verifica en el propio contrato. La elección suma todas las papeletas ella misma y solo acepta un resultado con una prueba Groth16 de que es el descifrado de esa suma. Ya no hay forma de publicar un recuento falso.
• Se cierran cuatro agujeros de seguridad graves: suplantación de organizadores, identidades Sybil en World ID, varias inscripciones con un mismo pasaporte, y un votante capaz de vaciar el depósito de gas.

⚠️ Cambian la ABI de los contratos, el formato de las papeletas y la derivación de la frase de recuperación. Hace falta un despliegue nuevo y una ceremonia de trusted setup (ver Despliegue en Amoy). Nada de esto afecta a Amoy, donde todavía no hay nada desplegado.

Verificación (checkout limpio del último commit, como en CI):

• Circuitos: 8/8 tests de testigos, y compilación + setup de los dos circuitos en los dos tamaños.
• Contratos: 222/222, incluida la suite E2E con pruebas Groth16 reales contra los verificadores generados (antes 185).
• Backend: 160/160 (antes 144).
• Frontend: 597/597.
• Playwright: 75 e2e (escritorio, tablet y móvil).
• oxlint, typechecks y build de producción en limpio.

Además, contra un nodo Hardhat local:

• El seed de demo creó las 38 elecciones con ~50 papeletas probadas de verdad, re-votos incluidos, y publicó las cerradas con pruebas de recuento.
• tally --verify verifica todas las publicadas desde la cadena, sin clave: vuelve a sumar las papeletas y vuelve a comprobar la prueba contra la clave de verificación.
• El CLI descifró, probó y publicó la elección que quedaba en recuento.
• En Chromium real (Vite + Playwright), un votante sembrado re-votó desde el navegador: encontró su papeleta anterior, generó la prueba en ~10 s y el contrato la aceptó. Una papeleta de más dentro del límite de ritmo se rechaza antes de probar, diciendo a qué hora se abre la siguiente.

---

🕶️ Re-votos invisibles

Antes: VoteCast publicaba el nullifier del votante y un nonce, así que quien conociera el nullifier veía que había re-votado. A un coaccionador le basta con eso.

Ahora (circuits/src/ballot.circom, ElectionV4.castVote):

• Papeleta = voto cifrado + cancelación de la papeleta anterior del votante, re-aleatorizada (de nada, si es la primera):
  • voto A = r·G, B_i = v_i·G + r·H_i, una clave por opción;
  • cancelación A' = −A_prev + s·G, B'_i = −B_prev_i + s·H_i.
• La prueba demuestra, sin revelar quién ni qué papeleta cancela:
  • que el votante está en el censo (identidad Semaphore, árbol de miembros);
  • que el voto es exactamente una opción válida (se acabó el relleno de urna);
  • que la cancelación deshace su propia papeleta anterior, probado por pertenencia al árbol de papeletas, no señalándola;
  • que el tag = Poseidon(TAG, secreto, scope, k) es suyo, con k privado: cada paso de la cadena del votante se emite una vez y los pasos no se pueden enlazar.
• El contrato suma votos y cancelaciones en un agregado (coordenadas extendidas de Baby Jubjub, BabyJubJub.sol). La suma se telescopa al último voto de cada votante: no hay que deduplicar nada.
• Límite de ritmo sin enlazar nada: un epochTag por votante y epoch de una hora sustituye al enfriamiento por nullifier del paymaster, que era en sí mismo un vínculo público entre las papeletas de un votante. La prueba puede nombrar el epoch actual o el anterior, cada tag una vez: un reemplazo inmediato y después uno por hora. La app elige al azar entre los dos cuando ambos están libres, para que nombrar el anterior no delate un re-voto.
• El scope de los tags sale de la dirección del propio contrato, no del organizador: dos elecciones nunca comparten tags.
• Recuento (circuits/src/tally.circom): prueba que los contadores son el descifrado del agregado del contrato con sus claves. publishResults(cid, counts, proof) lo verifica on-chain.
• Por debajo del quórum, voidBelowQuorum(voters, proof) prueba solo que votaron menos que el quórum y anula sin revelar nunca los contadores.
• Tamaños de circuito: 5 y 9 slots por defecto (hasta 50 opciones con build:all). La factory elige el par de verificadores más pequeño que cabe.
• ElectionDeployer guarda el bytecode de creación de ElectionV4, que ya no cabía dentro de la factory por el límite de 24 KB.

Lo que ve cada uno:

Quién	Qué puede saber
Cualquiera que mire la cadena, o un coaccionador con el recibo	Que hay N papeletas. No que una sea un re-voto, ni cuáles son del mismo votante
El organizador (tiene las claves)	La app solo descifra la suma, pero sus claves podrían abrir una papeleta suelta: su opción y, por la cancelación, si sustituyó a otra y de qué opción. Nunca de quién es ni a cuál sustituyó. Ver propuesta de descifrado por umbral
Quien tenga el secreto del votante	Todo, como antes: es tener su identidad

Coste medido por la suite E2E: ~0,99M gas por papeleta relayada con 5 slots y ~1,3M con 9. El tope por relay del paymaster sube a 5M (techo de 6M), porque se cobra el gas medido y un tope por debajo haría pagar la diferencia al relayer.

🔴 Seguridad

Problema	Consecuencia	Corrección
ElectionV4 heredaba ERC2771Context y deploy.ts usaba la dirección del deployer como forwarder si faltaba TRUSTED_FORWARDER	El deployer podía suplantar a cualquier organizador (publicar resultados falsos, cancelar, anular)	ERC2771Context eliminado por completo: nada lo usaba
/worldid/request firmaba con DEVELOPER_KEY la action que elegía el cliente	Cada action da un nullifier distinto: una persona obtenía identidades ilimitadas (Sybil)	El servidor fija la action (worldIdAction()) y verifyWorldIdProof rechaza pruebas de otra
La inscripción privada descartaba el nullifier del documento de Self	En elecciones DOCUMENT/ORB, un pasaporte con N cuentas de World ID daba N inscripciones	Nuevo documentTag en enrollPrivate, derivado del documento con la clave de época y deduplicado on-chain
relayVote sin permisos, re-votos ilimitados y papeletas de tamaño arbitrario	Un solo votante podía vaciar el depósito del organizador, y además cobrando él el reembolso como relayer	Papeletas probadas y de tamaño fijo, y un límite de ritmo con epochTag: un reemplazo inmediato y después uno por hora. El voto coaccionado se puede sobrescribir, salvo dos votos forzados seguidos en la última hora antes del cierre (documentado como límite conocido)
El owner del paymaster podía cambiar la factory y los parámetros del relay sin límite	Posible robo de los saldos de los organizadores	Factory fijable una sola vez, parámetros acotados y reserveFromBalanceFor limitado a las elecciones del propio organizador
markVoided sin restricciones	Un organizador que prometió no cancelar podía descifrar en privado y anular si perdía	Con cancellable == false, solo sin prueba si hay menos papeletas que el quórum; si no, solo con voidBelowQuorum y su prueba
La credencial SD-JWT afirmaba ageOver18: true, país y región a todo el mundo	Una credencial firmada que asegura hechos no verificados	Eliminado. La edad y la nacionalidad se prueban por elección con el documento
Credenciales de primer inicio con statusListIndex: "0"	Irrevocables durante 7 días	verifySession comprueba la revocación por el hueco del humano
Escrituras al registro pagadas por la plataforma sin cuota por usuario (vault sin límites de tamaño ni número)	Un usuario podía vaciar la wallet del registrar	Cuotas por votante (no por IP) y topes en el contrato y en la API

✅ Recuento verificable

• Cada papeleta se prueba bien formada antes de entrar: una papeleta rellenada o basura no llega a la cadena.
• El contrato mantiene el agregado él mismo y solo publica un resultado con la prueba del circuito de recuento.
• Cualquiera lo comprueba sin clave, contra la cadena:
  • TallyCheck en la pantalla de resultados vuelve a sumar todas las BallotCast y comprueba que dan el agregado que se probó;
  • npm run tally -- <elección> --verify hace lo mismo y además vuelve a verificar la prueba publicada contra la clave de verificación del circuito, independientemente del verificador on-chain.
• Sustituye a la prueba de descifrado de Paillier (tallyProof.ts) de la primera fase de esta PR, que dejaba publicar un recuento y luego contradecirlo; ahora no se puede publicar.

🟡 Bugs

• VoteConfirmation: mostraba un número de referencia inventado (VTN-2025-xxxxx) al recargar la página. Ahora nunca inventa uno.
• voting.ts: un fallo de RPC dejaba cacheada la elección como de inscripción pública, y se votaba con la identidad equivocada.
• electionIdentity.ts: la caché se indexaba solo por elección. Tras una recuperación seguía devolviendo identidades de la identidad maestra anterior.
• Quórum: se lee del contrato, no del JSON de metadatos.
• registrar.ts: daba por registrado un commitment que pertenecía a otro votante.
• Sesión de Self: ya no se consume antes de que el relay tenga éxito.
• Fronteras de tiempo: voteEnd pasa a ser exclusivo en todas partes, igual que en phase().
• Seed de demo: derivaba los tags con v1 y el backend con v2. Ahora coinciden.
• Comentario de ElectionPaymaster: citaba una función depositFor que no existe.
• Frase de recuperación: derivación con estiramiento PBKDF2‑SHA256 de 600k rondas, y lista de palabras EFF de 1.296 palabras (124 bits en 12 palabras).
• Wallets MPC o smart wallets: firman de forma no determinista, así que la clave de recuento derivada de la firma era irrecuperable. Ahora se detecta y se usa una clave aleatoria exportable.

Encontrados en esta fase, al ejecutar todo el sistema

• Relay local de relayEnrollPrivate sin documentTag. El cambio de documentTag no llegó a la ABI escrita a mano del relay local: en la cadena local la inscripción privada fallaba. Nuevo test de paridad de ABI (AbiParity.test.ts) que comprueba cada fragmento escrito a mano del frontend, backend y CLI contra los artefactos compilados. Lo encontré leyendo el código; el test está comprobado contra la versión con el fallo, que ahora no pasaría.
• Raíces que caducaban al ser reemplazadas. La validez de una raíz antigua se contaba desde que se creó, no desde que se reemplazó. En una elección tranquila, una prueba hecha contra la raíz actual caducaba en cuanto otro votaba primero. Ahora se cuenta como en Semaphore, con test de regresión.
• La regla de supermayoría del CLI no coincidía con la del contrato para más de dos opciones.
• Dependencias transitivas: poseidon-solidity y @zk-kit/lean-imt.sol llegaban solo a través de @semaphore-protocol/contracts. Ahora son directas.
• Afirmaciones de privacidad en la página de privacidad (13 idiomas): decían que ni el organizador podía ver un voto individual. No era cierto ni con Paillier. Corregido con precisión.
• Tests de circuitos que se saltaban solos si no había build, y en CI iban antes del build: habrían pasado sin probar nada. Ahora compilan primero y fallan en vez de saltarse.
• CI: la fase 1 pública de Hermez ya responde 403; el runner la generaba él mismo (38 min) y el paso agotaba su tiempo sin cachear nada. Ahora se genera en un paso propio y se cachea por separado en cuanto existe.
• El CLI se quedaba colgado tras --verify, el seed no dejaba tiempo para probar papeletas reales, y un segundo voto en la misma hora llegaba al votante como texto en inglés.

⚙️ Escalabilidad

• Backend, transacciones: un único proveedor de RPC y una cola serializada por clave (chain/signer.ts), con NonceManager. Se acabaron las colisiones de nonce con peticiones concurrentes.
• Lista de revocación: lecturas en paralelo acotado, deduplicación de peticiones simultáneas y sin pérdida silenciosa de índices por encima de 131.072.
• Frontend: getElections paginado, e historial y recibos en paralelo con un límite de concurrencia.
• Estado en memoria: límites de sesiones por votante y por IP, para que un atacante no pueda expulsar a los demás.
• Capacidad por elección: 2^20 miembros y 2^20 papeletas (profundidad de los circuitos).

🧹 Calidad y herramientas

• Código compartido: ballotCrypto.ts, sin dependencias, lo usan el navegador, el CLI, los tests y el seed. contracts/scripts/lib/prover.ts prueba desde Node exactamente como el navegador. Una sola función de relay, TwoStepOwnable compartido y un helper de errores.
• CI: nuevo job circuits (tests de testigos + build cacheado) que alimenta al job de contratos. La fase 1 de desarrollo (2^17, ~40 min en un runner) se genera una vez y se cachea aparte, guardada en cuanto existe. REQUIRE_CIRCUITS=1 hace que un build ausente falle en vez de saltarse la E2E.
• Linter: oxlint en frontend y backend. typescript-eslint no soporta TypeScript 7. Se corrigieron 19 errores reales.
• Seguridad del servidor: cabeceras de seguridad, manejador de errores en JSON, límite de tamaño del body, errores de ethers reducidos al nombre del revert, y validación de forma de cada papeleta relayada antes de simularla.
• Versiones fijadas: Node 24 y npm 11 (engines y .nvmrc).
• Playwright: test:e2e estaba roto porque faltaba @playwright/test. El smoke test ya es autónomo y se ejecuta en CI.
• Dependencias eliminadas: paillier-bigint, @semaphore-protocol/proof y @semaphore-protocol/contracts.
• Documentación: README, arquitectura, glosario y guías de módulo describen el nuevo esquema y sus límites, con diagramas Mermaid.

🔧 Cambios posteriores (27-28 sep)

• Re-voto inmediato: la app usa también el epoch anterior (chooseEpoch), elegido al azar cuando ambos están libres y descartado en los últimos 2 minutos antes del cambio de hora.
• deploy.ts: las comprobaciones de ceremonia, attester y circuitos se hacen antes de la primera transacción, así que un despliegue rechazado en Amoy ya no deja contratos pagados y huérfanos.
• Circuitos en Windows: build.mjs usa un circom nativo si lo hay (o CIRCOM), porque circom2 (WASM) no compila estos circuitos en Windows.
• Coste por papeleta según el tamaño de circuito de cada elección: antes una elección de 6 opciones (circuito de 9 slots) prometía ~50 % más papeletas de las que su reserva podía pagar. Un tamaño sin medir se estima por lo alto.
• Lecturas del RPC: timeout y un reintento, y una pantalla propia de "no se puede conectar" en lugar de "página no encontrada". El proxy local ya no reutiliza conexiones cerradas por Hardhat.
• UI e i18n: acentos perdidos en cinco idiomas, plurales, roles de diálogo accesibles, el tag de la papeleta ya no se etiqueta como "referencia", y un mensaje claro con la hora cuando se alcanza el límite de ritmo.
• Dependencias actualizadas a su última versión (hardhat-toolbox-mocha-ethers 4, vite 8.3, vitest 5, oxlint 1.86, snarkjs 0.7.6…), y Poseidon importado por aridad: el chunk de vendor pasa de 581 kB a 61 kB.
• Textos legales y de privacidad alineados con lo que hacen los contratos (reserva por elección, límite de ritmo real).

🚀 Despliegue en Amoy

1. Ceremonia: cd circuits && PTAU=<fase 1 pública de al menos 2^17> CEREMONY_ENTROPY=<secreto> npm run build. La fase 1 debe venir de una ceremonia con muchos participantes (Hermez o la perpetual powers of tau de PSE); la URL histórica de Hermez en Google Storage ya responde 403, así que hay que obtenerla de un espejo y comprobar su hash. Mejor aún, una contribución multiparte en la fase 2. Descartar la entropía después.
2. Contratos: npm run deploy:amoy. Despliega los verificadores generados y se niega a usar la ceremonia de desarrollo fuera de la cadena local, salvo ALLOW_INSECURE_CEREMONY=1 para una prueba desechable.
3. Ficheros de prueba: publicar frontend/public/circuits/ (IPFS, por ejemplo) y poner su URL en VITE_CIRCUITS_URL. Son ~50 MB por zkey, así que no van al repositorio. Un fichero equivocado solo produce pruebas que la cadena rechaza.

💡 Propuestas

Descifrado individual (el organizador podría abrir una papeleta suelta)

• Recomendada: descifrado por umbral (t-de-n). Con ElGamal, que ya está hecho, el obstáculo de la primitiva ha desaparecido:
  • una DKG tipo Pedersen/Feldman entre trustees (organizador, plataforma en su TEE, observadores o una junta electoral declarada) genera cada clave H_i = Σ_j x_ij·G sin que nadie tenga la clave completa;
  • al cerrar, cada trustee publica su descifrado parcial x_ij·A del agregado del contrato con una prueba de igualdad de logaritmos (Chaum-Pedersen) o un circuito pequeño;
  • el contrato combina t parciales y el circuito de recuento cambia x_i por la suma de parciales. Ninguna coalición de menos de t puede abrir papeletas sueltas.
• Alternativa inmediata: claves custodiadas en el TEE. Las x_i se generan y se sellan en el enclave (Phala), que solo descifra y prueba el agregado cuando phase() indique cierre, comprobado por atestación. Es más simple, pero concentra la confianza en el hardware.
• Ya mitigado: una papeleta abierta no dice de quién es ni a qué papeleta sustituyó, y nada público enlaza las papeletas de un votante.

Indexador

• Recomendado: un subgraph (The Graph) o un indexador ligero propio (Ponder, o el backend con SQLite/Postgres):
  • indexa ElectionCreated, MemberEnrolled, BallotCast, ResultsPublished y VoidedBelowQuorum;
  • sirve listas, contadores, historial y recibos (por tag) en una sola consulta;
  • puede servir también las rutas de Merkle de los árboles de miembros y papeletas, que hoy el navegador reconstruye leyendo todos los eventos.
• El navegador sigue pudiendo leer directamente de la cadena como ruta de auditoría, y la prueba de cada papeleta falla si el indexador mintiera sobre una ruta. El indexador es una optimización, nunca una fuente de confianza.
• Multicall3 para hidratar elecciones en un solo eth_call.

Estado compartido del backend

• Redis (o el KV de la plataforma) detrás de una pequeña interfaz Store, para:
  • rate limits (rate-limit-redis);
  • sesiones de elegibilidad y peticiones de World ID en curso, con TTL nativo;
  • cachés de revocación.
• Transacciones: la cola por clave pasa a una cola distribuida (BullMQ) con un único worker por clave de firma, que conserva el orden de nonces entre instancias.
• TEE: el estado sensible (asociación sesión ↔ elección) se cifra en reposo con una clave sellada al enclave.
• Hasta entonces: requisito explícito de una sola instancia, documentado en Known limits.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JD6VzyiKH5aMXbSnv7zNXi

---

Generated by Claude Code