Saltar al contenido
Financial Context Wiki

Ataques de largo alcance en PoS: claves históricas, riesgo de arranque y puntos de control

Un ataque de largo alcance en PoS presenta una historia alternativa firmada con autoridad histórica de validadores. Aprende qué nodos están expuestos, qué debe reproducir el atacante y cómo los puntos de control de subjetividad débil y las reglas de sincronización específicas del protocolo limitan el riesgo.

Actualizado

Análisis educativo sobre seguridad de protocolos únicamente. La resistencia a ataques de largo alcance depende del protocolo y de su versión; obtén los datos de arranque de fuentes autenticadas y verificadas de forma independiente antes de confiar en un nodo recién sincronizado o que haya permanecido desconectado durante mucho tiempo.

Respuesta directa

Un ataque de largo alcance en un sistema de prueba de participación intenta hacer creíble una historia conflictiva mediante una autoridad de validadores que fue válida mucho tiempo atrás. Una modalidad habitual, conocida a menudo como corrupción posterior, consiste en adquirir o comprometer las claves de validadores después de que hayan salido y su garantía ya no pueda ser penalizada. Como producir firmas antiguas no exige repetir el gasto energético de la prueba de trabajo, el adversario puede construir una bifurcación internamente coherente a bajo costo respecto del costo histórico de la cadena honesta.

El objetivo suele ser un nodo sin una vista autenticada reciente: un nodo que se inicia por primera vez, uno restaurado desde una copia de seguridad antigua o uno que permaneció desconectado más allá del horizonte seguro de sincronización del protocolo. Un nodo que observa la red de forma continua ya conoce un ancestro finalizado o protegido de otro modo y debería rechazar una bifurcación que entre en conflicto con él. Por tanto, un ataque de eclipse o una fuente de datos comprometida puede amplificar el ataque al ocultar la vista honesta al nodo que se sincroniza.

Las claves históricas por sí solas no son una herramienta universal de falsificación. La historia alternativa debe satisfacer los dominios de firma, las transiciones de estado, la evolución del conjunto de validadores, las reglas temporales, las pruebas de finalidad o selección de cadena y cualquier restricción sobre evolución de claves o puntos de control del protocolo objetivo. Algunos protocolos PoS exigen un punto de control reciente de subjetividad débil; otros definen un arranque orientado al bloque génesis o supuestos distintos de confianza y disponibilidad. Hay que analizar la cadena, la red, la versión de la bifurcación, el cliente y el modo de sincronización concretos, en vez de tratar «PoS» como un único mecanismo.

Un punto de control no es solo un número de bloque conveniente. Vincula una red y un estado de consenso específicos con una raíz o un hash en una época, ranura o altura. Una vez autenticado, limita las historias que el nodo considerará. Desde ese ancla, el resto de la cadena puede verificarse conforme a las reglas del protocolo. Esto es la subjetividad débil: una entrada externa acotada durante el arranque, seguida de validación objetiva dentro del período asumido, no confianza permanente en la cabecera más reciente de un par.

Ruta del ataque y de la verificación

  1. Elegir un punto de bifurcación antiguo. El adversario identifica un estado histórico cuya autoridad de validadores ha cambiado desde entonces o que resulta difícil de autenticar de forma independiente para un nodo nuevo.
  2. Obtener suficiente poder histórico de firma. Las claves pueden comprarse, robarse, conservarse, recuperarse de copias de seguridad o quedar expuestas por sistemas de firma comprometidos después de la salida de los validadores. El peso y los tipos de mensaje necesarios dependen del protocolo; poseer una sola clave antigua de proponente no basta automáticamente.
  3. Construir una alternativa válida para el protocolo. El adversario produce bloques, votos, certificados y cambios del conjunto de validadores que superan las comprobaciones históricas del cliente de la víctima. Una transición de estado inválida, un dominio erróneo, una temporización imposible o una prueba ausente aún pueden invalidar la bifurcación.
  4. Extender y presentar la bifurcación. La producción barata de firmas puede permitir al adversario completar una historia larga, pero el número bruto de bloques no es decisivo. La rama debe ganar o eludir el procedimiento exacto de selección empleado en ese modo de sincronización.
  5. Controlar la vista de arranque. La víctima queda aislada de un punto de control reciente autenticado o de pruebas de pares honestos, y se le muestra la historia alternativa como la única candidata o la preferida.
  6. Provocar confianza aguas abajo. Si el nodo acepta el estado equivocado, su RPC, monedero, indexador, monitor de puentes o aplicación pueden informar saldos, eventos y miembros del conjunto de validadores que son válidos para el protocolo en la bifurcación del atacante, aunque la red activa siga otra cadena.

El defensor debe reproducir el recorrido a la inversa: autenticar un ancla, confirmar la identidad de su cadena y red, verificar que la candidata desciende de ella, ejecutar todas las comprobaciones de consenso y transición de estado y comparar el estado finalizado o seleccionado entre infraestructuras independientes. Una descarga completada no demuestra que la historia seleccionada sea la canónica.

Ejemplo desarrollado

Supongamos que el conjunto de validadores V_old controlaba una cadena PoS hipotética en la época 120,000. Años después, más de 2/3 de ese peso histórico ha salido y ya no está expuesto a penalizaciones del protocolo. Un adversario obtiene esas claves antiguas e inicia una historia conflictiva inmediatamente después del punto de control C_old.

En la rama fabricada, el adversario firma los votos que exige este protocolo hipotético, cambia posteriormente los miembros del conjunto de validadores y continúa hasta la época 420,000. La red honesta también ha alcanzado la época 420,000, por lo que números de época iguales o un archivo más largo no indican a un nodo en arranque qué rama es canónica desde el punto de vista social y operativo. Que la rama fabricada sea siquiera admisible depende de todas las reglas históricas del protocolo.

El nodo N_live observó el punto de control finalizado genuino C_recent en la época 419,936. Como la bifurcación atacante no desciende de C_recent, N_live la rechaza. Sin embargo, el nodo N_new parte del bloque génesis, solo se conecta a pares adversarios y carece de un ancla reciente autenticada. Si su protocolo y modo de sincronización no pueden distinguir las historias únicamente por sus pruebas internas, puede aceptar la rama atacante.

Proporcionar a N_new el par autenticado C_recent = (root, 419,936) cambia el límite de decisión. El cliente debe exigir que la ruta de sincronización contenga ese punto de control exacto y cerrarse de forma segura si no puede hacerlo. Las épocas y el umbral de 2/3 del ejemplo ilustran un diseño basado en finalidad; no son parámetros universales de PoS ni la configuración actual de una red concreta.

Controles y lista de revisión

Diseño del protocolo

  • Documenta el modelo exacto de seguridad frente a ataques de largo alcance: corrupción posterior, rotación de validadores, compromiso adaptativo de claves, aislamiento de red y disponibilidad de datos.
  • Define qué estados finalizados nunca pueden revertirse y cómo trata la regla de selección de bifurcación un conflicto con un ancla de confianza local.
  • Acota las salidas, los retiros y la rotación del conjunto de validadores para que los supuestos de seguridad sigan siendo significativos mientras la firma conflictiva aún pueda detectarse y penalizarse.
  • Especifica el período de subjetividad débil o el supuesto alternativo de seguridad de sincronización como una derivación del estado actual y las constantes del protocolo, no como un valor de calendario eterno.
  • Considera firmas con evolución de claves o seguridad hacia delante cuando el diseño del protocolo lo permita; eliminar las claves de forma ordinaria es una buena práctica, pero no una defensa completa del consenso.
  • Prueba por separado la primera sincronización, la sincronización desde un punto de control, la restauración de instantáneas y la recuperación tras una desconexión prolongada. Una regla segura de selección de bifurcación en vivo no garantiza por sí sola un arranque seguro.

Arranque y operación del nodo

  • Registra antes de sincronizar la raíz del punto de control o el hash del bloque, la época o altura, el identificador de cadena, la red, la versión de la bifurcación, la hora de adquisición y el proveedor.
  • Obtén las anclas mediante canales autenticados y compara varias fuentes realmente independientes. Varios sitios web respaldados por un mismo nodo u operador no son independientes.
  • Rechaza los puntos de control obsoletos, malformados, de la red equivocada o conflictivos. No recurras silenciosamente a una sincronización sin ancla cuando falle la validación.
  • Exige que la cadena sincronizada contenga el ancla exacta y verifica todos sus descendientes con los clientes de consenso y ejecución previstos.
  • Diversifica pares, clientes, operadores y RPC; vigila posibles eclipses, divergencias de raíces finalizadas, reversiones inusuales y fallos prolongados de finalidad.
  • Vuelve a comprobar el ancla después de restaurar una base de datos o copia de seguridad antigua y actualízala dentro del período seguro documentado por el protocolo.

Confianza de las aplicaciones

  • No liberes depósitos, mensajes de puente ni operaciones irreversibles solo porque un RPC recién sincronizado informe que se completaron.
  • Concilia la identidad de la cadena, el punto de control finalizado y la ascendencia de los eventos entre nodos independientes antes de una acción de gran impacto.
  • Separa la historia del consenso de la verdad de la aplicación: una cadena canónica no demuestra la corrección de los oráculos, la seguridad de los contratos, la disponibilidad de datos fuera del protocolo ni la solvencia de un custodio.
  • Prepara una política de parada para puntos de control o anclas de confianza finalizados que entren en conflicto. Esa situación puede indicar un fallo de consenso, datos de arranque corruptos o una red equivocada, y no debe resolverse automáticamente eligiendo la rama más larga.

Errores comunes

  • Todas las cadenas PoS son vulnerables de la misma forma. La resistencia a ataques de largo alcance depende de la evolución de los validadores, las firmas, la finalidad, la selección de bifurcación, los puntos de control y los supuestos de sincronización del protocolo.
  • Las claves antiguas permiten reescribir cualquier transacción sin restricciones. El atacante aún debe producir una historia aceptada por todas las reglas de validación de la víctima; la autoridad histórica solo es necesaria en algunas construcciones de ataque y puede no ser suficiente.
  • La cadena con más bloques, épocas o firmas es la genuina. La selección usa validez, peso, certificados y anclas específicos del protocolo, no una comparación universal de longitud.
  • La finalidad por sí sola permite a un nodo que parte del bloque génesis identificar la cadena social. Dos historias finalizadas internamente válidas pueden resultar ambiguas para un nodo sin una vista reciente autenticada; la finalidad protege a un nodo que ya conoce el punto de control pertinente.
  • La penalización siempre disuade el ataque. Los validadores que retiraron por completo sus fondos pueden no tener garantía que penalizar, y las pruebas deben poder atribuirse y procesarse mientras las sanciones aún sean aplicables.
  • Un punto de control significa confiar para siempre en una empresa. La confianza puede limitarse a un ancla reciente concreta y reducirse mediante distribución autenticada, comprobaciones cruzadas independientes y posterior verificación local.
  • Eliminar las claves retiradas resuelve el problema del protocolo. El borrado seguro reduce el riesgo de compromiso, pero las reglas robustas de consenso y arranque deben tolerar que algunas claves históricas lleguen a estar disponibles.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...