Blockchain y votación: qué se puede verificar y qué no

Un sistema de votación organiza cómo una comunidad expresa una decisión y cómo se comprueba el resultado. Esa comunidad puede ser una asociación, los participantes de un protocolo o el electorado de un país. Blockchain permite registrar y verificar determinadas partes del proceso, con aplicaciones y exigencias diferentes en cada caso.

Para valorar su aportación conviene distinguir quién puede votar, cómo se protege la elección y cómo se realiza el recuento. La exactitud del registro es una parte de esa evaluación: también hacen falta garantías sobre identidad, secreto del voto y protección frente a la coacción.

Qué aporta un registro compartido

Un sistema de votación puede usar blockchain para registrar compromisos criptográficos, publicar resultados o comprobar que ciertos eventos se incluyeron. Esa verificabilidad cubre una parte del proceso. No demuestra que el dispositivo mostrara la opción correcta, que el votante actuara libremente o que su identidad estuviera bien validada.

Por eso hay que distinguir una votación de gobernanza de un protocolo, una consulta de una asociación y unas elecciones públicas. Cambian los derechos, el censo, el secreto requerido y las consecuencias de un fallo.

Los problemas que no resuelve el consenso

• Identidad: impedir votos duplicados exige un censo y un mecanismo de elegibilidad.
• Dispositivo: malware puede modificar una elección antes de registrarla.
• Coacción: votar a distancia puede permitir presión o compra del voto.
• Secreto: direcciones seudónimas y transacciones públicas pueden revelar relaciones.
• Disponibilidad: una caída de red, interfaz o proveedor puede excluir a participantes.

La National Academies of Sciences, Engineering, and Medicine explica que blockchain no resuelve los problemas fundamentales del voto por internet. La resistencia a modificar un registro no equivale a seguridad de extremo a extremo.

Qué debe probar un diseño

El equipo debe explicar cómo se registra el voto, cómo se comprueba su inclusión y cómo se verifica el escrutinio sin revelar elecciones individuales. También necesita procedimientos para errores, recursos, recuperación y auditoría independiente. La criptografía debe evaluarse junto con la interfaz, el censo y la operación.

Una prueba técnica no permite afirmar que el sistema sea apto para elecciones vinculantes. Hace falta evaluar los requisitos de la jurisdicción y las garantías exigidas al proceso completo. No se deben usar promesas como fraude imposible o anonimato garantizado.

Del resultado de una consulta a su ejecución

Imaginemos una votación pública de gobernanza sobre el presupuesto de un protocolo. El diseño debe fijar quién puede proponer, en qué momento se calcula el peso de voto, cómo funcionan las delegaciones y qué umbral permite aprobar. Son decisiones del sistema, no consecuencias automáticas de utilizar tokens.

Una vez terminado el plazo, puede existir una diferencia entre propuesta aprobada y operación ejecutada. Si un contrato mueve fondos, hay que revisar qué instrucción se ejecutará y quién puede detenerla o modificarla. Si una persona aplica el resultado fuera de la red, sigue existiendo una dependencia operativa que debe quedar explícita.

Como prueba de aceptación, el equipo puede reconstruir el resultado a partir del estado y las reglas definidos, contrastarlo con la interfaz y comprobar la acción posterior. También debe ensayar propuestas rechazadas, empates y pérdida de acceso de un operador. Este ejemplo ayuda a analizar gobernanza transparente; no demuestra que el mismo diseño preserve el secreto necesario en una elección pública.

Separar elegibilidad, emisión del voto, cómputo y ejecución permite localizar qué componente aporta cada garantía. Un recuento reproducible sigue siendo insuficiente si las instrucciones que finalmente se ejecutan no corresponden a lo que los participantes aprobaron.

Dónde tiene sentido experimentar

En gobernanza de un protocolo puede ser aceptable publicar votos vinculados a direcciones, si los participantes conocen el modelo. Aun así, hay que documentar distribución del poder, delegación, umbrales y capacidad de cambiar reglas. Un token por voto no implica una persona por voto.

Para un piloto acotado, define primero el modelo de amenazas y los criterios de éxito: elegibilidad, verificabilidad, accesibilidad, recuperación y participación. Compara con alternativas que ya cubran las necesidades de la organización. El resultado debe demostrar qué garantías se consiguieron y cuáles siguen dependiendo de personas o sistemas externos.