Por qué el argumento de denegación de servicio contra BOLT 12 no se sostiene


Una propuesta sucesora de BOLT 11, BOLT 12 es una actualización propuesta de Lightning, el protocolo de Bitcoin de capa 2 más popular.

Este es un editorial de opinión de Shinobi, un educador autodidacta en el espacio de Bitcoin y presentador de podcasts de Bitcoin orientado a la tecnología.

BOLT 12 es una propuesta de Rusty Russel de Blockstream para optimizar la forma en que se realizan los pagos a través de Lightning y, en última instancia, convertirse en el sucesor de BOLT 11. Aunque hay muchas características diferentes empaquetadas juntas para componer BOLT, este artículo se centrará principalmente sobre las ventajas y desventajas y los problemas relacionados con uno de ellos. Primero, resumiré rápidamente algunas de las características clave de la propuesta BOLT aquí:

BOLT: (Base de la tecnología Lightning; el equivalente Lightning de la propuesta de mejora de Bitcoin [BIP] especificaciones)

* Blinded Paths: Se utiliza tanto para facturas de pago como para mensajes cebolla. Predefine y encripta los últimos saltos en un circuito de pago o mensaje de cebolla para que el remitente no sepa a dónde está enviando algo, al mismo tiempo que permite que llegue al destinatario previsto.

* Firmas de Schnorr: esto permite que en todos los diferentes lugares se utilicen firmas para coordinar un pago Lightning o en la comunicación con nodos para aprovechar Schnorr multisig en el futuro.

* Comprobantes del pagador: los nodos ahora crean una clave especial cuando solicitan facturas, lo que les permite demostrar, a través de una firma, que han realizado un pago. Esto también garantiza en caso de devolución que solo el pagador real pueda reclamarla.

* Árboles Merkle de facturas: las facturas ahora se codifican como árboles Merkle comprometidos con cada campo individual. De esta manera, si alguna vez necesita probar que realizó un pago o recibió una factura, puede elegir selectivamente qué partes revelar en lugar de tener que mostrarle a alguien la factura completa.

Todas estas cosas juntas construyen una «oferta relámpago». Esto le permite publicar un solo código QR estático con información para hacer ping a un nodo sobre mensajes de cebolla y recibir una factura Lightning para un pago específico a través de Lightning Network. Actualmente, las facturas de BOLT 11 solo son válidas para el pago único para el que se generan, y aunque los pagos de envío de clave permiten realizar pagos sin la factura, no le permiten recibir los detalles del pago en una factura firmada por el nodo receptor y guárdelos para futuros registros. BOLT 12 habilita todos los beneficios de ambos: permitir que una sola pieza de datos estáticos facilite los pagos a un nodo receptor mientras sigue recibiendo facturas con los detalles de cada pago individual realizado. Como nota al margen rápida, esto también permite una coordinación rápida y fácil de pagos de transmisión, pagos de suscripción, etc. que no dejan que el receptor pueda cobrar dinero si el remitente no aprueba la transacción, mientras mantiene una experiencia de usuario optimizada.

Mediante el uso de rutas ciegas, también mejora enormemente una de las mayores deficiencias de privacidad de Lightning Network: los receptores de pagos envían muchos detalles privados al remitente en el proceso de recibir un pago, como los UTXO en cadena asociados con su canal, así como su lugar en el gráfico de Lightning Network (es decir, a qué nodo están conectados y a través del cual reciben el pago). Las rutas ciegas se utilizan tanto para recibir pagos como para recibir el ping del mensaje de cebolla para enviar una factura al remitente.

BOLT 12 es una gran cantidad de partes móviles que se unen para facilitar esta nueva forma de coordinar pagos en Lightning Network. Una de las mayores críticas presentadas contra la propuesta ha sido la inclusión de mensajes cebolla de propósito general y la preocupación de que abriría nuevos vectores de ataque de denegación de servicio (DoS). Creo que la lógica aquí es completamente incorrecta, y voy a explicar por qué.

Uno de los mayores problemas de DoS (y problemas de privacidad) con el protocolo Lightning es el sondeo. Cada canal puede tener en un momento dado 483 HTLC (contratos de bloqueo de tiempo hash) abiertos, que representan pagos pendientes, debido a los límites en el tamaño de una transacción en el protocolo Bitcoin. Esto es para garantizar que una transacción de cierre de canal pueda establecerse en cadena y no ser rechazada por el mempool por ser demasiado grande. El sondeo es el acto de enviar spam a través de canales, canales que están diseñados intencionalmente para fallar con el fin de recopilar información sobre cómo se equilibran los fondos en un canal Lightning. Esto consume ancho de banda, espacio que podría usarse para procesar pagos genuinos, y desperdicia recursos en la red, además de filtrar información que podría usarse para eliminar el anonimato de los pagos.

Lo que pasa con las transacciones de sondeo es que se pueden usar para pasar mensajes arbitrarios sin pagar un solo sat por ellos. Puede enrutar un pago a través de la red que fue diseñada para nunca tener éxito e incluir datos arbitrarios para el receptor, y luego simplemente dejar que el pago falle. Esto abusa del protocolo de pago en Lightning Network para transportar información arbitraria de forma gratuita, y no hay forma de evitar que la gente haga esto ahora mismo. No tendría forma de saber si un pago que está enrutando es genuino o si simplemente está abusando de su nodo para pasar datos; cuando falla un pago, no puede saber si falló orgánicamente o si fue diseñado para fallar desde el principio. En realidad, así es como funciona Sphinxchat, con la excepción de que, obviamente, envían pagos y no abusan de la red de forma gratuita.

En última instancia, este uso del protocolo Lightning satura el escaso rendimiento en forma de ranuras HTLC que podrían usarse para pagos económicos «reales» (reales entre comillas porque obviamente, quién debe juzgar qué es la actividad económica «real») para pasar datos arbitrarios , y actualmente se puede abusar de una manera en la que a nadie se le paga por hacerlo. Este es un riesgo DoS muy real y ya presente que existe en Lightning Network.

Hay algunas soluciones propuestas para el problema de sondeo y el problema de DoS que crea, el principal de los cuales es la idea de pagar tarifas por un pago antes de que realmente tenga éxito. Esta es una propuesta bastante polémica, ya que significaría que un remitente terminará pagando tarifas por un pago independientemente de si se completa con éxito. La naturaleza de todas las soluciones propuestas para esto está fuera del alcance de este artículo, pero el punto es que hay soluciones propuestas y ninguna de ellas está implementada actualmente. Punto clave: no se implementan.

Entonces, para mí, el argumento de que los mensajes de cebolla generales «abre un nuevo vector de ataque DoS» para Lightning es completamente falaz y un argumento falso. Ese vector de ataque ya existe ahora mismo. De hecho, es incluso peor que los mensajes de cebolla generales, porque desperdicia un recurso escaso necesario para enrutar los pagos: las ranuras HTLC. Los mensajes de cebolla generales no lo hacen.

Los mensajes de cebolla son una función que se puede desactivar, por lo que su nodo puede optar por no transmitirlos por completo, y también algo que puede tener una tasa limitada. Lo que quiero decir con eso es que su nodo podría tener fácilmente una configuración en la que solo pasa «x» mensajes por segundo, o «y» cantidad de datos por segundo, o cualquier otra línea de tiempo arbitraria, y se niega a transmitir cualquier cosa que exceda estos límites. De esta manera, su nodo puede administrar fácilmente la cantidad de recursos que permite consumir pasando mensajes generales.

En otras palabras, BOLT 12 no abre ningún nuevo vector de ataque DoS; simplemente toma uno existente que afecta la capacidad de la red para procesar pagos y lo mueve a un lugar que no afecta la retransmisión de pagos ni consume ningún espacio HTLC. También tiene una forma de mitigar el consumo de recursos sin restringir aún más el flujo de pago. Lo peor que podría pasar es un evento de spam masivo en la red: saturar la capacidad de mensajes de cebolla que degradaría la capacidad de usar las ofertas de BOLT 12 o de obtener una factura a través de la red.

Esto no afectaría la retransmisión de pagos; esto no impediría la capacidad de recibir y pagar facturas BOLT 11; simplemente significaría que los intentos de obtener facturas utilizando BOLT 12 fallarían siempre que la red estuviera siendo invadida con mensajes de cebolla. Recuerde también que los nodos individuales que no querían lidiar con el ligero aumento en el uso del ancho de banda podían optar por no transmitir mensajes cebolla. Todo, tal como funciona en este momento, continuaría funcionando, y un vector de ataque DoS existente tendría una especie de válvula de alivio donde las personas que quisieran pasar mensajes arbitrarios podrían hacerlo de una manera que no desperdicie espacios HTLC ni impida el procesamiento de pagos. , y cualquier persona que quisiera optar por no participar en la nueva característica podría hacerlo.

En resumen, creo que el argumento del «vector DoS» contra BOLT 12 no tiene sentido. Si la gente quiere ofrecer argumentos sobre la complejidad de todas las piezas de trabajo, el tiempo de desarrollo necesario para implementarlo u otros aspectos de la propuesta, creo que todos estos son argumentos válidos. Sin embargo, el argumento contra los mensajes cebolla y los nuevos vectores DoS no se sostiene.

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

milfinanzas

Soy ingeniero Naval especializada . dependiente de la Universidad Veracruzana, es un programa académico dedicado al desarrollo científico y tecnológico de las ciencias de la Ingeniería Naval y sus aplicaciones en el desarrollo socioeconómico del País. Tengo las habilidades y conocimientos matemáticos, y físicos a nivel superior para el diseño, construcción, reparación y mantenimiento de todo artefacto flotante. Soy trader de tiempo medio. Devoro libros, que abarcan desde el lado más científico al más humilde y humanista  que entiende que las personas "son personas".
Botón volver arriba
AllEscort