¿Es Channel Jamming una amenaza para Lightning Network de Bitcoin?

(Un agradecimiento especial a Antoine Riard y Gleb Naumenko, cuya la investigación reciente es la base de este artículo).

La interferencia de canales es uno de los problemas destacados de Lightning Network en términos de cosas que podrían interrumpir el éxito de los pagos enrutados a través de ella. Es un problema ampliamente conocido entre los desarrolladores que se ha entendido desde antes de que la red en sí se pusiera en marcha en la red principal y comenzara a procesar incluso un solo satoshi.

Hasta ahora, el problema realmente no ha tenido ningún efecto negativo en la red, pero al considerar ese hecho, es importante tener en cuenta que la red aún es, en el gran esquema de las cosas, relativamente pequeña. Los procesadores comerciales han comenzado a admitirlo, al igual que algunos intercambios y muchos servicios y negocios nativos de Lightning/Bitcoin, pero en realidad, eso no es mucho. La red sigue siendo en gran medida una pequeña cosa predominantemente utilizada por Bitcoiners, y eso no es una gran parte del mundo en absoluto.

Aún más, la cantidad de Bitcoiners que gastan y usan regularmente su bitcoin en la configuración comercial es un subconjunto aún más pequeño de ese grupo ya pequeño. Solo porque los ataques que son posibles no están ocurriendo ahora, las personas no deben asumir que eso significa que seguirán sin ocurrir cuando la red crezca a una escala mayor. Cuanto más grande se haga, más competitivo y conflictivo se volverá.

¿Qué es la interferencia de canales?

El concepto básico de bloqueo de canales es enrutar los pagos a través de un canal Lightning que desea bloquear de usted mismo a usted mismo, y luego no finalizarlos liberando la preimagen al hash de pago en el contratos de bloqueo de tiempo hash (HTLC). La(s) víctima(s) no podrá(n) eliminar los HTLC de su canal hasta después de que haya vencido el tiempo límite para el reembolso, porque no tendrían forma de hacer cumplir su reclamo de dinero que se les debe si la preimagen se publicara después de eliminarla. Si bloquea completamente un canal haciendo esto, entonces ese canal no podrá enrutar ningún pago hasta que expire el bloqueo de tiempo en todos los pagos maliciosos.

Hay dos estrategias diferentes que se pueden emplear aquí para realizar el ataque. Puede intentar atascar la cantidad enrutable disponible en un canal, o puede intentar atascar todas las ranuras HTLC individuales en un canal. Un canal Lightning solo puede tener 483 HTLC pendientes en cada dirección que puede enrutar; esto se debe a que existe un límite de tamaño máximo de cuán grande puede ser una transacción de Bitcoin. Si agrega más de 483 HTLC por dirección en el canal, la transacción para cerrar el canal si es necesario sería demasiado grande y no válida para enviar a la red. Esto haría que todo en el canal no se pueda aplicar en la cadena.

Por lo tanto, un atacante puede intentar bloquear toda la liquidez en un canal o intentar bloquear todas las ranuras HTLC en un canal. Cualquiera de las estrategias haría que el canal quedara inutilizable, pero la interferencia de ranuras generalmente será más económica que la interferencia de cantidad. El atacante necesita tener monedas en la red para realizar este ataque, por lo que enrutar el valor mínimo permitido para un HTCL de capacidad 483 será más rentable que tratar de bloquear toda la liquidez disponible en el canal.

¿Por qué alguien querría atascar un canal de iluminación?

Hay muchas razones para realizar este ataque. En primer lugar, una entidad malintencionada que quiera atacar a Bitcoin en sí misma podría bloquear todos los canales clave en el "núcleo" de la red para inutilizar la mayor parte de la red para enrutar pagos, a excepción de los nodos que están muy conectados entre sí. . Esto requeriría muchas más monedas para funcionar a esta escala, pero no es algo que deba descartarse como una posibilidad a medida que crece Bitcoin y se convierte en una alternativa al dinero y los sistemas de pago sancionados por el gobierno.

En segundo lugar, un nodo de enrutamiento, o comerciante, podría intentar realizar el ataque a un competidor para generar tarifas para él en lugar de la competencia. Un comerciante que venda productos similares podría bloquear los canales de un competidor para evitar que los clientes realicen compras allí, con la esperanza de incentivarlos a comprar en su tienda. Un nodo de enrutamiento que tenga una conectividad de canal similar a la de otro nodo podría bloquear los canales del nodo de enrutamiento de la competencia para inutilizarlos para enrutar pagos. Con el tiempo, esto destruiría la reputación de ese nodo en términos de confiabilidad de enrutamiento y, debido a la conectividad similar, haría cada vez más probable que las billeteras de los usuarios eligieran el nodo del atacante para enrutar los pagos a través de la red.

Estos ataques pueden ser aún más eficientes en términos de capital para el atacante si se enrutan circularmente a través de un solo canal varias veces. Si están lo suficientemente cerca de la víctima en la red, pueden construir una ruta de pago que circule y continúe a través del canal de la víctima. Hay límites en cuanto a la duración de una ruta de pago, por lo que esto no se puede hacer infinitamente, pero hacer una ruta de pago en bucle como esta puede reducir drásticamente la cantidad de monedas que el atacante necesita para bloquear por completo los canales de la víctima.

Mitigación de los ataques de interferencia de canales

Se podrían aplicar algunas mitigaciones parciales básicas para aumentar el costo para los atacantes y mitigar el daño para las víctimas. El primero sería un proceso de múltiples etapas para manejar los HTLC.

Actualmente, cada HTLC agrega individualmente una nueva salida en la transacción de compromiso para el estado actual del canal. Un proceso de dos etapas podría crear una sola salida adicional en la transacción de compromiso y luego tener una segunda transacción después de la cual se le agregó el HTLC real. Esto permitiría un máximo de 483 multiplicado por 483 ranuras HTLC por canal (o 233,289 ranuras). Sin embargo, esto realmente no soluciona nada por sí mismo, y requeriría extender los bloqueos de tiempo porque está agregando una transacción adicional para hacer cumplir las cosas en la cadena, y en realidad podría ayudar al atacante más que a la víctima si utilizaran esta nueva estructura de transacción y el la víctima no lo hizo. Sin embargo, ayudará en combinación con otra técnica explicada momentáneamente.

La segunda sería una estrategia reactiva, donde un nodo que ha sido víctima de una interferencia puede simplemente abrir un nuevo canal al mismo par que el que está siendo bloqueado. Sin embargo, esto requeriría tener capital adicional para hacerlo, no soluciona el costo de oportunidad de tener el otro canal bloqueado y perder ingresos por tarifas, y el nuevo canal también podría bloquearse posteriormente si el atacante tiene el capital disponible para hacerlo. .

La tercera técnica sería agrupar las tragamonedas HTLC. Actualmente hay 483 espacios, y este es un límite de espacio único que se aplica universalmente a todos los pagos, independientemente del valor del pago. Los nodos podrían crear cubos separados de límites de franjas horarias más pequeños y aplicarlos a pagos de diferentes valores, es decir, los pagos de 100,000 150 sats o menos solo podrían tener acceso a XNUMX franjas horarias. Por lo tanto, los pagos de enrutamiento de menor valor no pueden consumir todas las ranuras HTLC disponibles.

Los pagos de 100,000 sats a 1 millón de sats podrían tener acceso a 300 espacios, y 1 millón de sats a 10 millones de sats podrían tener acceso a los 483 espacios completos. Esto aumentaría significativamente el costo de capital de un atacante para bloquear las tragamonedas, ya que ya no podría consumir las 483 tragamonedas con el pago de menor valor posible. Además, debido a que las salidas de HTLC por debajo del umbral de polvo (actualmente, 546 sats) ni siquiera se pueden transmitir y aplicar en cadena, cualquier cosa por debajo de este límite podría manejarse como un "cubo 0" ya que de todos modos no se crea ninguna salida de HTLC. Los nodos podrían simplemente imponer límites a estas transacciones en función de los recursos de CPU utilizados u otras métricas para evitar que se conviertan en riesgos de denegación de servicio, dependiendo de cuánto pueden permitirse perder si no se liquidan honestamente.

La asignación de espacios en combinación con el manejo de HTLC de dos etapas se puede usar para optimizar la aplicación de los límites de HTLC, es decir, los pagos de valor más alto pueden usar la estructura de dos etapas para crear más espacios para ellos por canal porque el valor de pago más alto aumenta el costo de bloquearlos para un atacante, lo que hace que el abuso de un límite de ranura más alto para realizar ataques de bloqueo sea menos probable.

En su investigación citada anteriormente, Riard y Naumenko han demostrado que con la combinación óptima de ranuras de agrupamiento y extensión de ranuras de dos etapas, la causa del atasco de ranuras puede resultar tan costosa como el atasco de cantidad. Esto no resolvería el problema de manera integral, pero aumenta el costo mínimo de realizar el ataque si los nodos de la red lo implementan ampliamente.

Las dos soluciones integrales que han analizado son una tarifa por adelantado/tiempo de espera para bloquear la liquidez y un sistema de reputación que utiliza tokens Chaumian ciegos. El TLDR del esquema de tarifas es que se pagaría un bono por una tarifa inicial por enrutar un HTLC que se espera que tome mucho tiempo para liquidarse, y cuanto más tiempo permanezca sin liquidarse, liberaría una tarifa a cada nodo de enrutamiento. por porción de tiempo que ha pasado sin liquidación. El problema es que hacer cumplir esto podría llevar a la necesidad de cerrar los canales si las tarifas no se envían cuando se requieren, y provocará casos de uso legítimos que requieren largos tiempos de bloqueo para pagar la misma tarifa más alta que pagaría un atacante que intenta bloquear el canal.

El esquema de reputación implicaría un "bono de participación" utilizando pruebas de conocimiento cero para demostrar el control de Bitcoin como una defensa de Sybil, y luego usar el vínculo vinculado a su reputación para adquirir tokens Chaumian cegados de los nodos de enrutamiento que se canjearían y volverían a emitir en HTLC. establecerse con éxito de una manera que preserve la privacidad. Los nodos emitirían tokens una vez por identidad, y si un HTLC no se liquidaba o reembolsaba de manera oportuna, los nodos podían negarse a volver a emitir el token, lo que evitaba que un usuario se enrutara a través de su nodo a menos que gastara tiempo y dinero para crear un nuevo bono de participación con diferentes monedas que se emitirán en un token nuevo.

Para aquellos que deseen leer más sobre estas dos soluciones, pueden encontrar más información en las secciones Digital XNUMXk y seis en la investigación de Riard y Naumenko.

También vale la pena señalar que si los nodos de enrutamiento adoptaran sistemas de custodia basados ​​en terceros o líneas de crédito basadas en confianza, como escribí sobre esta página, todos estos problemas relacionados con la interferencia de canales dejarían de afectarlos. Este sería un gran cambio en el modelo de confianza para los nodos de enrutamiento, pero no tendría ningún efecto sobre las personas que usan canales Lightning reales para enviar y recibir satélites, la seguridad de sus fondos o su capacidad para hacer cumplir eso en cadena.

Es posible que la gente no quiera escucharlo, pero al final del día, si las soluciones anteriores para mitigar la interferencia de canales para los canales reales no son suficientes, estos sistemas de terceros siempre son una opción potencial.

Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.