Título original: "Sobre atestados, propagación de bloques y juegos de cronometraje"
Escrito por: Nero_eth
Compilado por: Tia, Techub News
Hoy en día, los juegos de sincronización de proponentes son muy comunes y muchos estudios han analizado este fenómeno.
Este artículo le llevará a través de la evolución del juego de sincronización del proponente y analizará su impacto en los testigos. A través de estudios de caso de operadores de nodos en Lido, Coinbase y Kiln, nos sumergiremos en el juego de sincronización de propuestas de bloques y su impacto en el consenso de Ethereum.
En agosto de 2024, el mercado de construcción de bloques está en gran medida subcontratado, y ~90% de los bloques son construidos por constructores de bloques mevboost. De estos, Titan Builder y Beaverbuild construyen aproximadamente el 80% de los bloques.
Kiln es una de las principales entidades que impulsa el juego del tiempo, retrasando las propuestas de bloques entre 3 y 3,5 segundos dentro de un solo espacio.
En el entorno actual de mevboost, la propagación de bloques se realiza principalmente a través de relés. Si bien un proponente seguirá propagando un bloque después de recibirlo de un repetidor, los repetidores generalmente tienen mejores conexiones de red y, por lo tanto, pueden completar la propagación más rápido. Sin embargo, el tiempo aún lo controla el proponente, quien puede retrasar sus llamadas "getHeader" para jugar con el tiempo.
Este diagrama muestra la evolución del juego del cronometraje. Podemos ver que con el tiempo, los bloques propuestos por los validadores de Kiln quedan relativamente rezagados dentro del espacio.
Esto tiene un impacto en la red: los bloques propuestos por los proponentes de Kiln tienen significativamente más votos de encabezado de bloque perdidos o incorrectos.
Análisis anteriores mostraron que cuanto más larga es la espera, mayor es el número esperado de votos de encabezado de bloque perdidos ("el 80% de los testigos ocurren en el quinto segundo del espacio"). Kiln propone bloques muy tarde, lo que hace que algunos testigos los pierdan y voten por el bloque principal. A cada espacio se le asignarán aproximadamente 32.000 validadores, lo que dará como resultado aproximadamente un 10% de votaciones en bloque incorrectas.
Echemos un vistazo al comportamiento de los testigos de tres grandes operadores de nodos y comparemos cómo reaccionan a los bloques propuestos en diferentes momentos. La siguiente figura muestra la distribución correcta y oportuna de los votos del encabezado del bloque en segundos.
Para los primeros bloques, observamos una forma de "U" característica en los patrones de votación de Lido y Coinbase, que puede deberse a diferentes geografías o software de cliente. Por el contrario, Kiln muestra un pico claro que está ligeramente por detrás del primer pico de Coinbase y Lido. Sin embargo, para bloques posteriores, los testigos de Kiln también muestran un patrón en forma de “U”.
Cuando el bloque aparece por primera vez en la ranura a los 4 segundos (dado que es una red P2P, cada nodo recibe el bloque en un momento diferente), el testigo de Lido presencia hasta 2 segundos antes que el testigo de Kiln o Coinbase. Este patrón no indica necesariamente que Kiln esté ejecutando una "estrategia personal". Más bien, esto puede deberse a diferencias en el cliente o la ubicación geográfica.
¿Quién influyó en quién?
En la siguiente figura, comparamos el desempeño de los operadores de nodos con diferentes proponentes. Por ejemplo, la sección verde sobre y=1 indica que será más probable que los testigos de Lido se pierdan las votaciones del encabezado del bloque cuando Kiln proponga un bloque como proponente. Sin embargo, cuando Lido es el proponente, los testigos de Lido son los más oportunos para presenciar los bloques. La línea discontinua 1 representa la proporción promedio de votos de encabezado de bloque perdidos entre todas las entidades que actúan como proponentes. Una barra por debajo de 1 significa que una entidad en particular perdió menos votos de encabezado de bloque cuando se fusionó con su respectivo proponente en comparación con el promedio.
En particular, los operadores de nodos se desempeñan mejor cuando procesan sus propios bloques propuestos.
Un breve resumen de lo que vimos:
La mayoría de los operadores se desempeñan de manera relativamente consistente cuando otros operadores proponen bloques como proponentes.
Figment, Lido, Kraken y EtherFi obtuvieron malos resultados cuando Kiln propuso bloques como proponente.
Solo Kiln y Binance obtuvieron mejores resultados cuando Kiln proponía bloques como proponente.
Kiln hace un gran trabajo como testigo. Los primeros análisis muestran que Kiln tiene un rendimiento superior cuando se trata de validadores de alto rendimiento. Para obtener más detalles sobre el desempeño de Kiln's Witness, consulte este análisis.
Pero Kiln provocó la presión. Ahora sabemos que los bloqueos propuestos por Kiln presionan a otros testigos, pero no a los testigos de Kiln.
En la actualidad, es difícil explicar "cómo". Una posible explicación es que los validadores de Kiln están altamente centralizados, se ejecutan en el mismo lugar o tienen conexiones de igual a igual muy densas. Otra razón podría ser el comportamiento coordinado de los validadores que los conectan a través de una red privada/de igual a igual personalizada o mediante otras capas de comunicación adicionales. Se considera que este último es de naturaleza más centralizada ya que pone mayor énfasis en las economías de escala.
Podemos observar un patrón similar cuando observamos los tiempos de certificación (correctos y oportunos) de Lido y Coinbase cuando cada uno propuso un bloque como proponente.
Curiosamente, Kiln desarrolló una distribución en forma de "U" para sus propios bloques tardíos de 3,8 segundos a 6,1 segundos, mientras que Lido tuvo un pico en 4,2 segundos y Coinbase comenzó a tener uno en 4 segundos en la ranura, con un pequeño pico en. 6 segundos.
Evite que sus propios bloques propuestos sean reorganizados
Dirijamos nuestra atención al bloque reorganizado. Desde la perspectiva de un operador de nodo, una estrategia podría ser nunca votar por un bloque que se reorganiza a sí mismo. En pocas palabras: "Si el proponente soy yo, nunca vote el bloque principal como encabezado del bloque".
En las siguientes secciones, utilizaré "bloque local" para representar "bloque autopropuesto".
El siguiente gráfico muestra el porcentaje de testigos que votaron por el bloque reorganizado en comparación con los que votaron por el bloque matriz. El apartado rojo muestra el porcentaje de testigos que votó la entidad para reorganizar el bloque.
El horno muestra un comportamiento inusual. Mientras que la mayoría de los testigos de los operadores de nodos votan honestamente por el encabezado de bloque correcto en lugar del bloque local, los testigos de Kiln no lo hacen. Más del 10% de los testigos de Kiln intentan mantener los bloques locales en cadena votando por ellos. Si se adopta tal estrategia, pueden incurrir en pérdidas debido a que votaron por el encabezado de bloque incorrecto. Sin embargo, estas estrategias suelen ser menospreciadas en la comunidad Ethereum: "No juegues con el consenso".
Este gráfico utiliza 365 días de datos. Por lo tanto, si se implementaron algunas estrategias complejas durante el año pasado, la proporción de la porción roja será correspondientemente menor.
Pero, ¿cómo pensamos en la colaboración a otros niveles?
Con respecto a la colaboración de testigos, como comunidad parecemos aceptar el hecho de que los validadores que se ejecutan en el mismo nodo voten por los mismos puntos de control.
Es posible que no queramos hacer ningún esfuerzo para mejorar la colaboración entre validadores más allá de los límites de las máquinas físicas. Esto debería ser algo que todos puedan construir. Esta colaboración puede adoptar diferentes formas:
Nivel 1: Mecanismo de respaldo con emparejamiento estático: proporciona un nodo central de respaldo/en espera para múltiples máquinas físicas. Esto también podría ser un disyuntor, alguna máquina particularmente tolerante a fallas que actúa como retransmisión privada de mensajes. Las configuraciones con conexiones punto a punto mejoradas, redes privadas o configuraciones similares también pueden entrar en esta categoría.
Nivel 2: reglas If-else: reglas codificadas para esperar más tiempo en ciertos espacios. Se instalarán en múltiples máquinas físicas, lo que les permitirá "colaborar" según reglas predefinidas.
Nivel 3 - Botnet: Hay un oráculo centralizado que se comunica con todos los validadores y proporciona puntos de control de los votos y marcas de tiempo de cuándo deben publicarse.
En mi opinión, las dos últimas formas de colaboración (niveles 2 y 3) son problemáticas y los operadores de los nodos deberían rendir cuentas. Finalmente, puede haber áreas grises para las políticas que involucran peering estático y redes privadas.
Estas configuraciones pueden usarse para ejecutar políticas (maliciosas) como:
Asegúrese de que nunca se voten diferentes puntos de control en varias máquinas físicas.
Asegúrese de no votar nunca por un bloque que reorganice su propia propuesta.
Colaboración basada en proponentes consecutivos (cliente de reorganización honesto (s/n)).
Examinar el testimonio de una de las partes.
No votar por el bloque de un partido.
otro.
Cuando se habla de colaboración, es importante distinguir entre dos tipos:
El comportamiento colaborativo ocurre entre validadores que se ejecutan desde la misma máquina física.
El comportamiento colaborativo resulta de ejecutar el mismo software cliente modificado o confiar en el mismo oráculo centralizado.
Una posible solución contra el comportamiento complejo de los validadores colaborativos es EIP-7716: Penalizaciones anticorrelación, que propone ajustar las penalizaciones en función de la correlación entre validadores.
