Parte 1. Análisis de los datos de votación de blockchain de 2019 en la Duma de la ciudad de Moscú por alexeishch
Parte 2. Auditoría paralela durante la votación electrónica por CryptoTyan
Tuve la suerte de participar en la redacción de un informe sobre la votación blockchain en el MHD 2019 como parte del equipo Roman Uneman, y en este artículo hablaré en detalle sobre la parte relacionada con el análisis de datos.
Algunas palabras sobre los datos de origen. Inicialmente, el archivo de descarga de la cadena de bloques cayó en mis manos. Más tarde, cuando hice el análisis inicial, me puse en contacto con el equipo de Roman Uneman, tuve a mi disposición los testimonios de los observadores que estaban presentes en el "centro de votación" y fotografié monitores con datos de votación.
Métricas
Decidí mirar todo lo que sucede a través de los ojos del desarrollador. La primera pregunta que me hice fue: "¿qué haría si comenzara a diseñar dicho sistema?" Sistema de votación: debe ser un sistema de alta disponibilidad y contener un componente de observación, y esto no es solo el registro. En consecuencia, para observarlo, se requería elegir una cantidad de cantidades que sirvieran como métricas. Dado que el sistema se basó en la cadena de bloques, las métricas de la propia cadena de bloques deberían ser parte de estas métricas. Una de estas métricas es el tiempo de bloqueo. Esta conjetura fue el comienzo de todo el estudio. Antes que yo, la misma Medusa prestaba atención a los problemas, pero solo consideraban las voces y todo estaba lejos de ser obvio para ellos.
Primero, explicaré qué significa el tiempo de bloqueo y por qué necesita monitorear esta métrica mientras la cadena de bloques está funcionando. Tiempo de bloque, este es el tiempo durante el cual se calcula y escribe el bloque. Se pueden ocultar dos valores bajo este nombre: estos son el tiempo esperado para calcular un bloque y el tiempo promedio de un bloque. Los parámetros del sistema establecen el tiempo de bloqueo esperado en el caso de la Prueba de autoridad (PoA) de la cadena de bloques. El tiempo de bloqueo promedio, esto ya es en tiempo real, que se calcula de la siguiente manera: si en el tiempo T la red blockchain calculó n bloques, entonces el tiempo de bloque promedio es T / n. Un cambio anormal en esta métrica sugiere problemas y le permite solucionarlos rápidamente.
Echemos un vistazo a esta métrica, calculada sobre la base de la descarga de datos de la cadena de bloques. Como todavía soy un desarrollador, no un analista, para facilitar el trabajo de análisis de datos, escribí un programa de análisis de forma simultánea, lo que me ayudó constantemente en esto. Encontrará un enlace a su código fuente al final del artículo. De aquí en adelante, todos los gráficos se están descargando de él.
El eje X es el número de bloque, el eje Y es el tiempo promedio.
Al observar esta métrica, podemos reparar áreas de operación estable de la cadena de bloques, áreas de un fuerte aumento en el tiempo promedio del bloque (Zonas 1A, 1B, 2) y el área de degradación de la red informática de la cadena de bloques, así como un área sospechosa que se parece un poco a un pulso (Zona 3).
En primer lugar, afirmo que esta métrica debería haberse mostrado en los monitores de la mesa de votación, ya que claramente se puede juzgar por el desempeño de uno de los componentes principales del sistema. En segundo lugar, sostengo que de estos datos se deduce que se detuvo el trabajo de la cadena de bloques. Calculemos cuántas veces y cuánto tiempo.
Tenemos tres secciones con tiempos de bloqueo sospechosos llamados por mí "Zona 1A", "Zona 1B" y "Zona 2". El tiempo de cálculo del bloque para el bloque 2046 fue de entre 3 y 4 segundos. Para la evaluación, tomamos el límite superior de 4 segundos y calculamos el tiempo en que se detuvo la cadena de bloques.
Descripción de las columnas de la tabla.
- Número de bloque de inicio de zona
- Número de bloque de fin de zona
- El número de bloques en la zona.
- Hora de inicio de zona
- Hora de finalización de zona
- Duración de zona
- Tiempo estimado cuando la cadena de bloques realizó cálculos basados en el cálculo del tiempo de bloqueo de 4 segundos
- Tiempo estimado cuando la cadena de bloques estuvo deshabilitada
Observo que tomé un límite superior para el tiempo de bloque, respectivamente, esto da un límite superior para el tiempo de cálculo y un límite inferior para el tiempo de parada. Es decir Es probable que los tiempos reales de detención sean aún más. Es decir El tiempo total para que la cadena de bloques se detenga por completo es de aproximadamente 2 horas.
La siguiente zona curiosa es "zona 3". Existe una extraña grabación de bloques en frecuencia en comparación con períodos anteriores, pero consideraremos esta área por separado cuando veamos la distribución de votos entre los bloques.
Y finalmente, desde el momento a las 2:20 p.m. hasta el final de la votación, observamos un aumento constante en el tiempo de cálculo. Permítame recordarle que estamos hablando de la cadena de bloques PoA y que no hay complicaciones de las operaciones como en el caso de ETH, cuando tal comportamiento fue causado por una "bomba de complejidad" en la cadena de bloques PoW. Es decir Observamos un comportamiento inesperado de la métrica de blockchain, lo que indica la degradación del sistema.
Análisis de distribución de votos
Haré una reserva de inmediato para ser lo más objetivo posible y no mencionaré las rarezas en la distribución de votos entre los candidatos, y este análisis no se llevará a cabo en el contexto de los candidatos individuales. En el programa que escribí, sin embargo, dejé la oportunidad de hacer esto a cualquier parte interesada. En este artículo, solo estoy interesado en el rendimiento del sistema. Si está interesado en estas rarezas, debe consultar el informe, allí se describe todo lo más detallado posible.
La distribución de votos se ve así
El eje X es el número de bloque, el eje Y es el número de votos en el bloque.
Como se esperaba, en las zonas de detención de blockchain (1A, 1B, 2) no hay registros de voz, porque estas son zonas de falla. Pero la zona 3 da motivos para pensar. Hay un pequeño número de bloques de 1-3 votos, un par de ráfagas de 4-5 votos y un gran aumento de votos al final de esta zona. Combiné estos eventos en función de la métrica del tiempo de bloque, ya que la degradación ya sucedió después de estos eventos, y la grabación de estos bloques estuvo dentro de límites aceptables. En la zona 3, no hubo parada de blockchain, pero por alguna razón los datos prácticamente no cayeron en la cadena de bloques.
La duración total de estas zonas es de aproximadamente 4 horas. Es decir Dado que toda la votación duró 12 horas, luego, durante aproximadamente un tercio del tiempo, por diversas razones, los datos no se registraron en la cadena de bloques.
En el área asociada con la degradación, vemos claramente que el modo de grabación ha cambiado y los datos comenzaron a escribirse con más frecuencia, en contraste con los lugares donde la cadena de bloques funcionaba de manera estable. No se sabe exactamente con qué está conectado, porque la configuración exacta no está disponible para nosotros, pero se supone que esto puede deberse al desbordamiento de la Cola de transacciones en paridad. Este comportamiento plantea preguntas para el equipo que integró Parity con el backend, y también habla de la posibilidad teórica de perder votos asociados con las transacciones de eliminación.
Es interesante que el número de votos en el bloque esté limitado a 100. No hemos encontrado esta constante en el código publicado, ni en la configuración ni en el código.
No recibí una explicación del origen del aumento de votos, después de lo cual comenzó la degradación, en esta etapa del análisis, e intenté encontrar una explicación en las fotografías de los datos de las pantallas de votación que hicieron los observadores.
Análisis de los datos disponibles para los observadores.
Aquí hablaremos sobre los datos disponibles para los observadores; fueron posicionados como una alternativa a la presencia de observadores en una mesa de votación real. Las fotos en función de las cuales se recopilan se pueden obtener del informe.
Debo decir de inmediato que creo que los observadores no recibieron deliberadamente los datos en la medida en que necesitan comprender y rastrear los procesos que tienen lugar en el sistema.
- Los observadores no vieron las métricas del sistema y, como resultado, ni siquiera pudieron evaluar superficialmente el grado de operatividad.
- El nodo de monitoreo de blockchain no se proporcionó a los observadores
- La presentación tabular de los datos no permitió a los observadores evaluar lo que estaba sucediendo.
Los datos mostraban 4 números, que mostraban esencialmente un embudo de conversión
- ¿Cuántas personas asistieron al inicio del proceso de votación?
- ¿Cuántas personas ingresaron al SMS de registro?
- ¿Cuántas personas recibieron el boletín?
- Cuantas personas votaron
Como se trata de un embudo, los cuatro parámetros están interconectados:
- No puedes recibir SMS sin ir a la página
- No recibir SMS no puede recibir un boletín
- No puedes votar sin recibir un boletín
Además, debe tenerse en cuenta que la vida del boletín es de 15 minutos. Esto significa recibir un boletín informativo, puede votar solo por 15 minutos.
El eje X es el tiempo. El eje y es el número de personas.
Una representación visual muestra inmediatamente anomalías.
Los hechos de la ausencia de visitas a la página de votación (la línea verde la línea es horizontal) indican la inaccesibilidad del frente del sistema. El grado inferior es de 17 parcelas completas (incluyendo una parcela donde la cantidad aumentó y luego disminuyó), cada una durante 15 minutos. En total, esto es aproximadamente 4 horas y 15 minutos. Estos intervalos se superponen parcialmente con fallas relacionadas con blockchain y son parcialmente nuevos (por ejemplo, 14:20 - 15:01, 15:30 - 16:15).
Durante ese extraño aumento de votos, por alguna razón, nadie vino al sitio y nadie ingresó a SMS. No encontré una explicación para este hecho. Es decir Con una alta probabilidad, este aumento está asociado con algún tipo de interferencia externa.
Durante el intervalo de 15:30 a 16:15, solo creció un parámetro "SMS ingresado", parece que ajustaron las estadísticas, porque antes de eso, la cantidad de boletas emitidas era mayor que la cantidad de personas (línea roja) que ingresaron correctamente los SMS. Lo cual es imposible en términos de lógica.
Por supuesto, existe la posibilidad de que el mecanismo para presentar datos a los observadores simplemente no funcionó, o funcionó con errores graves, pero el reconocimiento de este hecho es esencialmente el hecho de que a los observadores no se les permitió ir a la mesa de votación, porque además de estos datos, los observadores no tenían absolutamente nada
Conclusiones
Tradicionalmente, cuando hablan de sistemas de alta disponibilidad, comienzan una conversación con un nueve - 90% de las veces que el sistema funciona sin errores. Los sistemas serios pueden proporcionar trabajo con dos o tres nueves (99% y 99.9% de las veces que el sistema procesa correctamente las solicitudes). En el caso de votar en la Duma Estatal de Moscú, la votación duró aproximadamente 12 horas y el número de votantes fue inferior a 10 mil personas. Al mismo tiempo, el sistema no funcionó durante más de 4 horas. Luego, durante cinco horas y media, los cálculos en la cadena de bloques se degradaron y nadie reaccionó a esto, lo que muestra problemas en la arquitectura debido a la falta de monitoreo de las métricas. Personalmente, tuve la opinión de que, con tales características, este sistema no puede considerarse ni siquiera un prototipo funcional.
PD Ya cuando estaba preparando lentamente este artículo, apareció un artículo del DIT sobre Habré, en el que afirmaban que "Durante todo el día, el sistema de votación electrónica funcionó de manera estable, excepto durante una hora, pero pudimos solucionar el problema rápidamente". Espero sinceramente que esto haya sucedido en un Universo paralelo y que el autor reciba el Premio Nobel por su descubrimiento, porque tanto las métricas como los datos contradicen directamente esto. Según los datos que recibí de esta realidad, se deduce que la cadena de bloques se apagó durante 2 horas, los componentes asociados con la cadena de bloques no funcionaron durante 4 horas, y desde las 14:20 hasta el final de la votación, la red informática de la cadena de bloques se degradó continuamente, lo que no pudo hacer frente a un extraño aumento de votos, que no explicado por los datos que recibí de observadores de este universo.
El contenido del informe completo se puede encontrar en el sitio web dedicado a la votación electrónica.
El código fuente del programa analizador y los datos se cargan en Github (.NET Core 3 / WPF):
Contenido del artículo del DIT sobre arquitectura del sistema