Gracias Ambición 3, terence 3, Artem 9, Equipo de Protocolo de Investigación Titania para discusión y comentarios
Este documento clasifica los métodos de ataque contra PoS Ethereum y propone contramedidas, especialmente contra el notablemente peligroso ataque del 51%. Los puntos principales son los siguientes:
El objetivo de esta propuesta es mejorar la seguridad de PoS Ethereum, específicamente fortaleciendo las defensas contra el peligroso ataque del 51%.
Se conocen varios métodos de ataque contra PoS Ethereum, con resultados potenciales a los que los atacantes podrían apuntar de manera realista, incluida la reorganización, la doble finalidad y el retraso de finalidad. Un factor crucial en este análisis es la proporción de participación requerida para un ataque, que indica la apuesta mínima necesaria, que sirve como barrera de entrada. Sin embargo, casi igual de crítica es la sostenibilidad del ataque, que mide la continuidad con la que un atacante puede mantener el ataque. Si un ataque es sostenible, podría causar daños significativos. Además, la sigilo del ataque también es importante, ya que indica la forma encubierta con la que un atacante puede ejecutar un ataque. Si un protocolo no puede detectar un ataque, se hace difícil determinar si son necesarias medidas defensivas. Los valores más altos para ambas métricas indican una perspectiva más negativa desde la perspectiva del protocolo. Los métodos de ataque representativos analizados incluyen:
El retraso de finalidad es un ataque que puede ser ejecutado con una proporción de participación del 33%. El atacante evita la finalización al no proporcionar el 33% de las certificaciones. Una medida defensiva durante este ataque es el mecanismo de fuga por inactividad. Este mecanismo identifica a los validadores que no emiten certificaciones o emiten certificaciones en contra de la mayoría, reduciendo el ETH apostado de dichos validadores inactivos. Durante un ataque del 33%, la fuga por inactividad se activa, lo que provoca que el ETH del atacante disminuya y caiga por debajo de la cantidad necesaria para mantener el retraso de finalidad. En consecuencia, la sostenibilidad del ataque es relativamente baja y temporal, lo que facilita su detección debido a la fuga por inactividad.
La doble finalidad se refiere a un ataque en el que el atacante envía certificaciones para finalizar dos ramas simultáneamente. Para lograr la doble finalidad, el atacante requiere una proporción de participación del 34%. El atacante realiza una doble votación para el 34% de las certificaciones, trabajando para finalizar ambas bifurcaciones. Las medidas defensivas durante este ataque incluyen el mecanismo de corte. Dado que el voto doble está prohibido, el atacante perdería su ETH apostado, lo que haría que el ataque fuera fácilmente detectable (baja indetectabilidad). Además, la penalización de corte sustancial significa que es probable que el ataque solo ocurra una vez; Si el atacante tuviera el presupuesto para atacar varias veces, probablemente elegiría un ataque del 66% en su lugar. Por lo tanto, la sostenibilidad del ataque para este método también es muy baja.
Cuando un atacante posee una proporción de staking del 51%, puede manipular el algoritmo de elección de bifurcación. Los ataques A y B se dirigieron al Casper FFG (dispositivo de finalidad), mientras que este ataque apunta al LMD GHOST (algoritmo de elección de bifurcación). En este escenario, el atacante puede crear libremente la rama más pesada en LMD GHOST, haciendo que los validadores honestos sigan la rama del atacante, lo que resulta en la finalización. Esto permite al atacante censurar transacciones específicas y realizar reorganizaciones a corto plazo (reorg) para maximizar su valor extraíble por minero (MEV) sin incurrir en penalizaciones por slashing.
En los ataques A y B, existían mecanismos para reducir el potencial del atacante al ocurrir. En el ataque A, la fuga de inactividad disminuye la proporción de participación del atacante por debajo del umbral del 33%, lo que hace que el ataque sea imposible. En el ataque B, se reduce en un tercio su proporción de participación durante esa época, lo que hace que los ataques repetidos sean efectivamente inviables.
Sin embargo, actualmente no existen medidas defensivas algorítmicas contra el ataque C. Incluso si hay una ranura con una relación de votación del 51%, no hay forma de distinguir si esa certificación es maliciosa o una desacuerdo legítimo entre validadores honestos. Esto significa que la indetectabilidad del ataque es significativamente alta. Una vez que un ataque tiene éxito, el atacante puede continuar persistentemente el ataque hasta que se tome una decisión de bifurcación dura a través de la capa social, lo que resulta en una sostenibilidad del ataque muy alta.
En el ataque de reorganización corta y censura del 66%, el atacante puede manipular libremente la finalización, reescribiendo cadenas pasadas y finalizando nuevas ramas. Las características del ataque D son similares a las del ataque C, y ambos presentan una alta indetectabilidad y una alta sostenibilidad.
Un punto crítico a destacar es que después de ejecutar un ataque del 51%, el atacante puede utilizar las ganancias para apuntar a un ataque del 66%. Las ganancias potenciales de un ataque del 51% son significativamente mayores en comparación con los ataques del 33% y 34%, y debido a que no incurren en penalizaciones como la fuga de inactividad o el corte, un intento exitoso podría aumentar exponencialmente su dominio.
La siguiente tabla resume las características de los métodos de ataque representativos analizados:
Método de Ataque | Ratio de Staking | Ataque Stealthability | Sostenibilidad de Ataque |
A. Ataque de retraso de finalidad | 33% | Bajo | Bajo |
Ataque de doble finalidad B. | 34% | Baja | Bajo |
Ataque de acortamiento de reorganización y censura (control sobre el futuro) | 51% | Alto | Alta |
D. Ataque de reorganización y censura corta (control sobre el pasado y el futuro) | 66% | Alto | Alto |
De esta tabla, se puede observar una tendencia interesante: los ataques a los niveles del 33% y 34% (A y B) son fáciles de detectar y muestran una baja sostenibilidad, mientras que los ataques del 51% en adelante (C y D) son difíciles de detectar y muestran una alta sostenibilidad, lo que ilustra una clara dicotomía.
Me gustaría enfatizar la importancia de considerar los peores escenarios posibles en cuanto a la seguridad de PoS Ethereum. En pocas palabras, existe una posibilidad real de que Ethereum se enfrente a una situación descrita como 'fin del juego'. Si tal escenario llegara a ocurrir, todas las actividades y datos pasados dentro de innumerables ecosistemas se volverían nulos y sin efecto.
Refiriéndose a la tabla anterior, los ataques A y B tienen niveles bajos tanto de indetectabilidad de ataque como de sostenibilidad de ataque. Desde la perspectiva de un atacante, existe una alta probabilidad de que sus acciones sean expuestas, y estos ataques tienden a ser de corta duración.
En contraste, los ataques C y D muestran altos niveles tanto de sigilo como de sostenibilidad del ataque. Para los atacantes, estas acciones son menos propensas a ser detectadas, lo que les permite mantener el ataque durante un período más largo y potencialmente obtener ganancias inmensas. Al considerar en cuál de los dos ataques, C o D, enfocarse, primero debemos prestar atención a la ratio de apuesta como barrera para el ataque. Si bien ambos ataques podrían causar daños significativos, el ataque C, que requiere una cantidad absoluta menor para ejecutarse, es un objetivo más realista (especialmente considerando su potencial para llevar al ataque D). A la luz de estas consideraciones, esta discusión explorará medidas defensivas contra los ataques de reorganización corta y la censura del 51%.
El problema clave con los ataques de reorganización corta y censura del 51%, como se mencionó anteriormente, es su alto nivel de indetectabilidad y sostenibilidad del ataque, lo que implica que el daño potencial podría ser extenso.
Profundicemos en la sostenibilidad del ataque. La razón por la que estos ataques son sostenibles es que la única medida defensiva disponible es un hard fork a través del consenso social, lo que requiere un tiempo considerable (como se demostró en el incidente de DAO, que tardó un mes desde el descubrimiento del hackeo hasta el hard fork). Durante este intervalo, los bloques y épocas finalizados por el atacante se acumularán en la cadena legítima. Los validadores honestos corren el riesgo de ser penalizados por atestiguar bloques en una cadena ilegítima que se ha convertido en la minoría a pesar de ser la canónica. El quid de la cuestión radica en que el número de épocas requeridas para la finalización es fijo; por lo tanto, incluso en emergencias, la finalización ocurre en las mismas dos épocas (aproximadamente 13 minutos) que en circunstancias normales.
En el caso de un ataque del 51 %, prevemos que las certificaciones exhibirán un margen ajustado, como el 50,5 % frente al 49,5 %, y estas contiendas reñidas son relativamente raras durante las operaciones normales. Introducimos una métrica para indicar la probabilidad de que la época actual sea atacada en función del número de espacios en los que los votos principales son "reñidos". Además, a medida que esta métrica aumente, el número de épocas necesarias para la finalización aumentará exponencialmente. Este mecanismo permite el aplazamiento algorítmico de la finalización durante emergencias, lo que permite a la comunidad responder a los atacantes a través de medios sociales sin necesidad de una bifurcación dura. Debido a que los períodos normales de finalización permanecerán sin cambios, esta implementación se puede integrar sin problemas sin comprometer la experiencia del usuario. Proponemos el mecanismo de detección de voto cerrado para el primero y la finalización dinámica emergente para el segundo como defensas contra los ataques del 51%.
Cuando ocurre un ataque del 51%, los atacantes elegirán deliberadamente una cabeza que parezca canónica por ser la más pesada. Los validadores honestos aún pueden proponer bloques, pero los atacantes pueden manipular fácilmente la cabeza canónica a través de reorganizaciones a corto plazo siempre que encuentren los bloques propuestos indeseables. Cuanto más cerca esté la proporción de participación del atacante al 50%, más cerca estará la cantidad de certificaciones del 50%. A estas certificaciones que están muy cerca del 50% de la cabeza se les llamará 'votos cercanos'. Actualmente, la determinación de si se finaliza una época se realiza en la última ranura de esa época, donde agregaremos el conteo de votos cercanos.
Si la ocurrencia de votos de cierre supera un umbral determinado, el sistema reconocerá un estado de emergencia y aumentará significativamente el número de épocas requeridas para la finalización. Como resultado, el atacante necesitará mantener una mayoría sustancial de votos durante un período más largo para lograr la finalización. Durante este tiempo, la comunidad tendrá la oportunidad de implementar contramedidas. Específicamente, si el número de espacios clasificados como votos de cierre en la época actual supera un umbral determinado, el número requerido de épocas para la finalización se elevará drásticamente de las dos estándar. Nos referimos a esto como modo de emergencia. Si bien hay mucho margen para el debate sobre cuál debería ser este valor, apuntar a una mejora significativa en comparación con el retraso de un mes del incidente de DAO podría sugerir probar un valor como
. Esto requeriría que el atacante continúe su asalto durante aproximadamente nueve días (32,768 * 12 segundos ≈ 4,551,168 segundos ≈ 9 días), brindando a la comunidad tiempo suficiente para implementar rápidamente contramedidas. Este mecanismo defensivo garantiza que las operaciones normales de la red no se vean afectadas y se activa solo en caso de emergencia, lo que permite una implementación fluida sin degradar la experiencia del usuario. Además, dado que funciona de manera algorítmica, puede ejecutarse de inmediato sin esperar el juicio humano, lo que permite respuestas rápidas.
Definamos los siguientes símbolos, donde W, E, Fson parámetros:
En su forma inicial más simple, proponemos lo siguiente:
Aquí se definen los parámetros:
Las fórmulas proporcionadas definen dos indicadores que indican la posibilidad de un ataque del 51%. En primer lugar, Ci indica si un espacio específico se considera una votación reñida, lo que arroja 1 cuando |Vi−0.5|
caídas dentro del umbral W. En segundo lugar, F indica el número de épocas requeridas para la finalización. Por lo tanto, si el número de ranuras de voto cercano alcanza el umbral E, el número requerido de épocas aumenta a D, planificando así ataques sostenidos y mitigando sus impactos potenciales. Consideremos valores específicos:
Así que tenemos:
Con esta configuración, si el porcentaje de certificación Vi para cualquier ranura está dentro de ±1% del 50%, esa ranura se contará como un voto cercano. Si, por ejemplo, 4 de las 32 ranuras son votos cercanos, el total de Ci será 4, lo que requiere que F se establezca en 215Como resultado, el atacante no podrá finalizar la cadena durante aproximadamente nueve días, lo que permitirá a la comunidad tiempo suficiente para implementar un rápido hard fork para restaurar la legítima cadena de bloques de Ethereum.
El objetivo de esta propuesta es reducir el daño máximo estimado durante un ataque del 51%. Su objetivo es mitigar la probabilidad de un escenario de 'fin del juego'. Si bien es difícil discutir cambios cuantitativos específicos, es factible establecer el parámetro D para garantizar que la duración no se extienda a un mes como en el incidente de DAO. Es esencial tener en cuenta que el tiempo de respuesta esperado de la capa social también debe tenerse en cuenta en este aspecto.
Además, varios servicios que interactúan con Ethereum, como otras cadenas e intercambios centralizados, pueden operar en base a esta D. Al introducir mecanismos algorítmicos, los ecosistemas circundantes también podrán responder algorítmicamente.
Existe la preocupación de que esta propuesta pueda crear inadvertidamente un nuevo mecanismo de retraso de la finalidad. Por ejemplo, es posible controlar aleatoriamente el 51% de dominancia sobre
L ocurrencias entre 32 ranuras, que se pueden calcular fácilmente utilizando una distribución binomial. Si bien el incentivo económico para retrasar la finalidad generalmente es bajo, no podemos descartar incentivos potenciales que no se hayan considerado. Si surgen tales incentivos, podrían abordarse potencialmente mediante la introducción de un sistema de reputación. Dado que las certificaciones involucran firmas, los intentos de suplantar a otros validadores requerirían tiempo significativo para ejecutarse.
Para determinar los parámetros óptimos, debemos examinar cuidadosamente los procedimientos específicos necesarios para ejecutar una bifurcación dura a través de la capa social.
Es necesario determinar empíricamente valores adecuados para los parámetros W (definiendo el rango para votos de cierre), E (definiendo el umbral para la activación del modo de emergencia) y D (definiendo cuánto retrasar la finalización). Además, D es un componente de la fórmula F, pero también podríamos considerar un diseño más dinámico donde el aumento en el número de votos de cierre ∑iCi daría como resultado un valor mayor para F.
Necesitamos determinar las especificaciones para las certificaciones.
En esta propuesta, nos enfocamos en el peligroso ataque del 51%, como uno de los métodos de ataque contra PoS Ethereum, discutiendo sus riesgos e implicaciones mientras proponemos nuevas estrategias de defensa. Específicamente, nuestro objetivo es mejorar la resistencia a los ataques del 51% mediante la introducción de mecanismos como la Detección de Voto Cercano y la Finalización Dinámica Emergente.
Investigaciones futuras deberían explorar más a fondo la efectividad de las estrategias de defensa propuestas y su aplicabilidad a otros métodos de ataque. También es necesario continuar investigando la optimización de parámetros y los métodos de implementación específicos.
Además, el análisis de los métodos de ataque frente a diferentes algoritmos de consenso y la formulación de estrategias de defensa basadas en incentivos sociales son direcciones valiosas para una mayor discusión. Espero interactuar con la comunidad de Ethereum sobre el valor de estas ideas y abordar cualquier inquietud.
Gracias Ambición 3, terence 3, Artem 9, Equipo de Protocolo de Investigación Titania para discusión y comentarios
Este documento clasifica los métodos de ataque contra PoS Ethereum y propone contramedidas, especialmente contra el notablemente peligroso ataque del 51%. Los puntos principales son los siguientes:
El objetivo de esta propuesta es mejorar la seguridad de PoS Ethereum, específicamente fortaleciendo las defensas contra el peligroso ataque del 51%.
Se conocen varios métodos de ataque contra PoS Ethereum, con resultados potenciales a los que los atacantes podrían apuntar de manera realista, incluida la reorganización, la doble finalidad y el retraso de finalidad. Un factor crucial en este análisis es la proporción de participación requerida para un ataque, que indica la apuesta mínima necesaria, que sirve como barrera de entrada. Sin embargo, casi igual de crítica es la sostenibilidad del ataque, que mide la continuidad con la que un atacante puede mantener el ataque. Si un ataque es sostenible, podría causar daños significativos. Además, la sigilo del ataque también es importante, ya que indica la forma encubierta con la que un atacante puede ejecutar un ataque. Si un protocolo no puede detectar un ataque, se hace difícil determinar si son necesarias medidas defensivas. Los valores más altos para ambas métricas indican una perspectiva más negativa desde la perspectiva del protocolo. Los métodos de ataque representativos analizados incluyen:
El retraso de finalidad es un ataque que puede ser ejecutado con una proporción de participación del 33%. El atacante evita la finalización al no proporcionar el 33% de las certificaciones. Una medida defensiva durante este ataque es el mecanismo de fuga por inactividad. Este mecanismo identifica a los validadores que no emiten certificaciones o emiten certificaciones en contra de la mayoría, reduciendo el ETH apostado de dichos validadores inactivos. Durante un ataque del 33%, la fuga por inactividad se activa, lo que provoca que el ETH del atacante disminuya y caiga por debajo de la cantidad necesaria para mantener el retraso de finalidad. En consecuencia, la sostenibilidad del ataque es relativamente baja y temporal, lo que facilita su detección debido a la fuga por inactividad.
La doble finalidad se refiere a un ataque en el que el atacante envía certificaciones para finalizar dos ramas simultáneamente. Para lograr la doble finalidad, el atacante requiere una proporción de participación del 34%. El atacante realiza una doble votación para el 34% de las certificaciones, trabajando para finalizar ambas bifurcaciones. Las medidas defensivas durante este ataque incluyen el mecanismo de corte. Dado que el voto doble está prohibido, el atacante perdería su ETH apostado, lo que haría que el ataque fuera fácilmente detectable (baja indetectabilidad). Además, la penalización de corte sustancial significa que es probable que el ataque solo ocurra una vez; Si el atacante tuviera el presupuesto para atacar varias veces, probablemente elegiría un ataque del 66% en su lugar. Por lo tanto, la sostenibilidad del ataque para este método también es muy baja.
Cuando un atacante posee una proporción de staking del 51%, puede manipular el algoritmo de elección de bifurcación. Los ataques A y B se dirigieron al Casper FFG (dispositivo de finalidad), mientras que este ataque apunta al LMD GHOST (algoritmo de elección de bifurcación). En este escenario, el atacante puede crear libremente la rama más pesada en LMD GHOST, haciendo que los validadores honestos sigan la rama del atacante, lo que resulta en la finalización. Esto permite al atacante censurar transacciones específicas y realizar reorganizaciones a corto plazo (reorg) para maximizar su valor extraíble por minero (MEV) sin incurrir en penalizaciones por slashing.
En los ataques A y B, existían mecanismos para reducir el potencial del atacante al ocurrir. En el ataque A, la fuga de inactividad disminuye la proporción de participación del atacante por debajo del umbral del 33%, lo que hace que el ataque sea imposible. En el ataque B, se reduce en un tercio su proporción de participación durante esa época, lo que hace que los ataques repetidos sean efectivamente inviables.
Sin embargo, actualmente no existen medidas defensivas algorítmicas contra el ataque C. Incluso si hay una ranura con una relación de votación del 51%, no hay forma de distinguir si esa certificación es maliciosa o una desacuerdo legítimo entre validadores honestos. Esto significa que la indetectabilidad del ataque es significativamente alta. Una vez que un ataque tiene éxito, el atacante puede continuar persistentemente el ataque hasta que se tome una decisión de bifurcación dura a través de la capa social, lo que resulta en una sostenibilidad del ataque muy alta.
En el ataque de reorganización corta y censura del 66%, el atacante puede manipular libremente la finalización, reescribiendo cadenas pasadas y finalizando nuevas ramas. Las características del ataque D son similares a las del ataque C, y ambos presentan una alta indetectabilidad y una alta sostenibilidad.
Un punto crítico a destacar es que después de ejecutar un ataque del 51%, el atacante puede utilizar las ganancias para apuntar a un ataque del 66%. Las ganancias potenciales de un ataque del 51% son significativamente mayores en comparación con los ataques del 33% y 34%, y debido a que no incurren en penalizaciones como la fuga de inactividad o el corte, un intento exitoso podría aumentar exponencialmente su dominio.
La siguiente tabla resume las características de los métodos de ataque representativos analizados:
Método de Ataque | Ratio de Staking | Ataque Stealthability | Sostenibilidad de Ataque |
A. Ataque de retraso de finalidad | 33% | Bajo | Bajo |
Ataque de doble finalidad B. | 34% | Baja | Bajo |
Ataque de acortamiento de reorganización y censura (control sobre el futuro) | 51% | Alto | Alta |
D. Ataque de reorganización y censura corta (control sobre el pasado y el futuro) | 66% | Alto | Alto |
De esta tabla, se puede observar una tendencia interesante: los ataques a los niveles del 33% y 34% (A y B) son fáciles de detectar y muestran una baja sostenibilidad, mientras que los ataques del 51% en adelante (C y D) son difíciles de detectar y muestran una alta sostenibilidad, lo que ilustra una clara dicotomía.
Me gustaría enfatizar la importancia de considerar los peores escenarios posibles en cuanto a la seguridad de PoS Ethereum. En pocas palabras, existe una posibilidad real de que Ethereum se enfrente a una situación descrita como 'fin del juego'. Si tal escenario llegara a ocurrir, todas las actividades y datos pasados dentro de innumerables ecosistemas se volverían nulos y sin efecto.
Refiriéndose a la tabla anterior, los ataques A y B tienen niveles bajos tanto de indetectabilidad de ataque como de sostenibilidad de ataque. Desde la perspectiva de un atacante, existe una alta probabilidad de que sus acciones sean expuestas, y estos ataques tienden a ser de corta duración.
En contraste, los ataques C y D muestran altos niveles tanto de sigilo como de sostenibilidad del ataque. Para los atacantes, estas acciones son menos propensas a ser detectadas, lo que les permite mantener el ataque durante un período más largo y potencialmente obtener ganancias inmensas. Al considerar en cuál de los dos ataques, C o D, enfocarse, primero debemos prestar atención a la ratio de apuesta como barrera para el ataque. Si bien ambos ataques podrían causar daños significativos, el ataque C, que requiere una cantidad absoluta menor para ejecutarse, es un objetivo más realista (especialmente considerando su potencial para llevar al ataque D). A la luz de estas consideraciones, esta discusión explorará medidas defensivas contra los ataques de reorganización corta y la censura del 51%.
El problema clave con los ataques de reorganización corta y censura del 51%, como se mencionó anteriormente, es su alto nivel de indetectabilidad y sostenibilidad del ataque, lo que implica que el daño potencial podría ser extenso.
Profundicemos en la sostenibilidad del ataque. La razón por la que estos ataques son sostenibles es que la única medida defensiva disponible es un hard fork a través del consenso social, lo que requiere un tiempo considerable (como se demostró en el incidente de DAO, que tardó un mes desde el descubrimiento del hackeo hasta el hard fork). Durante este intervalo, los bloques y épocas finalizados por el atacante se acumularán en la cadena legítima. Los validadores honestos corren el riesgo de ser penalizados por atestiguar bloques en una cadena ilegítima que se ha convertido en la minoría a pesar de ser la canónica. El quid de la cuestión radica en que el número de épocas requeridas para la finalización es fijo; por lo tanto, incluso en emergencias, la finalización ocurre en las mismas dos épocas (aproximadamente 13 minutos) que en circunstancias normales.
En el caso de un ataque del 51 %, prevemos que las certificaciones exhibirán un margen ajustado, como el 50,5 % frente al 49,5 %, y estas contiendas reñidas son relativamente raras durante las operaciones normales. Introducimos una métrica para indicar la probabilidad de que la época actual sea atacada en función del número de espacios en los que los votos principales son "reñidos". Además, a medida que esta métrica aumente, el número de épocas necesarias para la finalización aumentará exponencialmente. Este mecanismo permite el aplazamiento algorítmico de la finalización durante emergencias, lo que permite a la comunidad responder a los atacantes a través de medios sociales sin necesidad de una bifurcación dura. Debido a que los períodos normales de finalización permanecerán sin cambios, esta implementación se puede integrar sin problemas sin comprometer la experiencia del usuario. Proponemos el mecanismo de detección de voto cerrado para el primero y la finalización dinámica emergente para el segundo como defensas contra los ataques del 51%.
Cuando ocurre un ataque del 51%, los atacantes elegirán deliberadamente una cabeza que parezca canónica por ser la más pesada. Los validadores honestos aún pueden proponer bloques, pero los atacantes pueden manipular fácilmente la cabeza canónica a través de reorganizaciones a corto plazo siempre que encuentren los bloques propuestos indeseables. Cuanto más cerca esté la proporción de participación del atacante al 50%, más cerca estará la cantidad de certificaciones del 50%. A estas certificaciones que están muy cerca del 50% de la cabeza se les llamará 'votos cercanos'. Actualmente, la determinación de si se finaliza una época se realiza en la última ranura de esa época, donde agregaremos el conteo de votos cercanos.
Si la ocurrencia de votos de cierre supera un umbral determinado, el sistema reconocerá un estado de emergencia y aumentará significativamente el número de épocas requeridas para la finalización. Como resultado, el atacante necesitará mantener una mayoría sustancial de votos durante un período más largo para lograr la finalización. Durante este tiempo, la comunidad tendrá la oportunidad de implementar contramedidas. Específicamente, si el número de espacios clasificados como votos de cierre en la época actual supera un umbral determinado, el número requerido de épocas para la finalización se elevará drásticamente de las dos estándar. Nos referimos a esto como modo de emergencia. Si bien hay mucho margen para el debate sobre cuál debería ser este valor, apuntar a una mejora significativa en comparación con el retraso de un mes del incidente de DAO podría sugerir probar un valor como
. Esto requeriría que el atacante continúe su asalto durante aproximadamente nueve días (32,768 * 12 segundos ≈ 4,551,168 segundos ≈ 9 días), brindando a la comunidad tiempo suficiente para implementar rápidamente contramedidas. Este mecanismo defensivo garantiza que las operaciones normales de la red no se vean afectadas y se activa solo en caso de emergencia, lo que permite una implementación fluida sin degradar la experiencia del usuario. Además, dado que funciona de manera algorítmica, puede ejecutarse de inmediato sin esperar el juicio humano, lo que permite respuestas rápidas.
Definamos los siguientes símbolos, donde W, E, Fson parámetros:
En su forma inicial más simple, proponemos lo siguiente:
Aquí se definen los parámetros:
Las fórmulas proporcionadas definen dos indicadores que indican la posibilidad de un ataque del 51%. En primer lugar, Ci indica si un espacio específico se considera una votación reñida, lo que arroja 1 cuando |Vi−0.5|
caídas dentro del umbral W. En segundo lugar, F indica el número de épocas requeridas para la finalización. Por lo tanto, si el número de ranuras de voto cercano alcanza el umbral E, el número requerido de épocas aumenta a D, planificando así ataques sostenidos y mitigando sus impactos potenciales. Consideremos valores específicos:
Así que tenemos:
Con esta configuración, si el porcentaje de certificación Vi para cualquier ranura está dentro de ±1% del 50%, esa ranura se contará como un voto cercano. Si, por ejemplo, 4 de las 32 ranuras son votos cercanos, el total de Ci será 4, lo que requiere que F se establezca en 215Como resultado, el atacante no podrá finalizar la cadena durante aproximadamente nueve días, lo que permitirá a la comunidad tiempo suficiente para implementar un rápido hard fork para restaurar la legítima cadena de bloques de Ethereum.
El objetivo de esta propuesta es reducir el daño máximo estimado durante un ataque del 51%. Su objetivo es mitigar la probabilidad de un escenario de 'fin del juego'. Si bien es difícil discutir cambios cuantitativos específicos, es factible establecer el parámetro D para garantizar que la duración no se extienda a un mes como en el incidente de DAO. Es esencial tener en cuenta que el tiempo de respuesta esperado de la capa social también debe tenerse en cuenta en este aspecto.
Además, varios servicios que interactúan con Ethereum, como otras cadenas e intercambios centralizados, pueden operar en base a esta D. Al introducir mecanismos algorítmicos, los ecosistemas circundantes también podrán responder algorítmicamente.
Existe la preocupación de que esta propuesta pueda crear inadvertidamente un nuevo mecanismo de retraso de la finalidad. Por ejemplo, es posible controlar aleatoriamente el 51% de dominancia sobre
L ocurrencias entre 32 ranuras, que se pueden calcular fácilmente utilizando una distribución binomial. Si bien el incentivo económico para retrasar la finalidad generalmente es bajo, no podemos descartar incentivos potenciales que no se hayan considerado. Si surgen tales incentivos, podrían abordarse potencialmente mediante la introducción de un sistema de reputación. Dado que las certificaciones involucran firmas, los intentos de suplantar a otros validadores requerirían tiempo significativo para ejecutarse.
Para determinar los parámetros óptimos, debemos examinar cuidadosamente los procedimientos específicos necesarios para ejecutar una bifurcación dura a través de la capa social.
Es necesario determinar empíricamente valores adecuados para los parámetros W (definiendo el rango para votos de cierre), E (definiendo el umbral para la activación del modo de emergencia) y D (definiendo cuánto retrasar la finalización). Además, D es un componente de la fórmula F, pero también podríamos considerar un diseño más dinámico donde el aumento en el número de votos de cierre ∑iCi daría como resultado un valor mayor para F.
Necesitamos determinar las especificaciones para las certificaciones.
En esta propuesta, nos enfocamos en el peligroso ataque del 51%, como uno de los métodos de ataque contra PoS Ethereum, discutiendo sus riesgos e implicaciones mientras proponemos nuevas estrategias de defensa. Específicamente, nuestro objetivo es mejorar la resistencia a los ataques del 51% mediante la introducción de mecanismos como la Detección de Voto Cercano y la Finalización Dinámica Emergente.
Investigaciones futuras deberían explorar más a fondo la efectividad de las estrategias de defensa propuestas y su aplicabilidad a otros métodos de ataque. También es necesario continuar investigando la optimización de parámetros y los métodos de implementación específicos.
Además, el análisis de los métodos de ataque frente a diferentes algoritmos de consenso y la formulación de estrategias de defensa basadas en incentivos sociales son direcciones valiosas para una mayor discusión. Espero interactuar con la comunidad de Ethereum sobre el valor de estas ideas y abordar cualquier inquietud.