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.
La interferencia de canales es uno de los problemas pendientes más amenazantes con Lightning Network. Presenta un mecanismo abierto para los nodos de ataque de denegación de servicio en la red para evitar que se enruten, lo que les hace perder dinero mientras su liquidez está bloqueada y no pueden reenviar pagos que les generarán tarifas. Un atacante puede enrutar un pago a través de otros nodos de sí mismo y negarse a finalizar el pago. Esto hace que la liquidez sea inútil para reenviar otros pagos hasta que expire el bloqueo de tiempo del contrato hash timelock (HTLC) y se reembolse el pago.
El mes pasado, el desarrollador de Lightning, Antoine Riard, propuso una especificación formal para solucionar este problema. En agosto, Riard y Gleb Naumenko publicaron una investigación que analizó el problema general en sí, así como una serie de soluciones diferentes que podrían usarse para mitigarlo o resolverlo. Una de esas soluciones propuestas era una forma de credenciales anónimas que los nodos podían usar para construir una especie de sistema de puntuación de reputación para los usuarios que enrutan los pagos a través de ellos sin tener que doxear o asociar esa reputación con un identificador estático que afectaría negativamente la privacidad de las personas. Esta solución se ha convertido ahora en la propuesta de protocolo formal realizado por Riard el mes pasado.
Dentro de la propuesta de mitigación de interferencias en el canal
El núcleo de la idea es un token de efectivo de Chaumian. Estos son tokens centralizados emitidos por una autoridad de menta de una manera que evita que la emisión de un token se correlacione con el canje de un token posterior. Esto se hace firmando un token de forma ciega, lo que permite que el receptor del token lo descifre sin invalidar la firma. Luego, el emisor puede verificar que es un token legítimo sin poder conectar ese token al momento en que se emitió.
La propuesta sugiere usar estos tokens Chaumian, emitidos por cada nodo de enrutamiento en la red, como una forma de prueba de reputación. Al enrutar un pago, un token de efectivo de Chaumian emitido por cada nodo en el salto de pago se envolvería en el paquete de cebolla para ese nodo a lo largo del pago. Las unidades de token representarían tanto el valor del HTLC permitido como el período de tiempo de reembolso. Antes de reenviar el HTLC, cada nodo verificaría que el token incluido en su blob cebolla sea válido y que nunca se haya canjeado antes, y solo reenviará el HTLC si se cumplen ambas condiciones.
Si el HTLC se resuelve con éxito y se revela la preimagen, entonces cada nodo a lo largo de la ruta de pago firma e incluye un token Chaumian recién emitido que se devolverá al remitente, junto con la preimagen del HTLC. Si el HTLC no se resuelve correctamente, los nodos de enrutamiento “queman” el token incluyéndolo en su tabla de tokens gastados y no emiten un nuevo token. Esto obliga al remitente a tener que adquirir nuevos tokens de esos nodos para enrutar los pagos a través de ellos nuevamente. El concepto completo es que los ataques de interferencia siempre fallan, por lo que en este esquema, estos tokens emitidos por cada nodo por el que se enruta se queman si realiza un ataque de interferencia y crea el costo de adquirir más para hacerlo nuevamente. En este momento, los ataques de interferencia no cuestan nada más que tiempo, por lo que esto les agregaría un costo económico.
Entonces, es hora de hablar sobre el elefante en la habitación: ¿cómo inicia la emisión y circulación de estos tokens en la red? Cada nodo por el que desee enrutar requerirá un token emitido por ellos. La solución: pagar por ellos. Otra solución propuesta para el problema de la interferencia de canales son las tarifas iniciales, es decir, cobrar una tarifa incluso para intentar enrutar un pago, independientemente de si tiene éxito o no. Por lo tanto, incluso los pagos fallidos incurrirían en una tarifa para el remitente.
La propuesta de Riard es comprar estos tokens directamente de cada nodo como compras únicas. A partir de ese momento, en lugar de pagar tarifas por adelantado para cada pago, siempre que el pago anterior se haya liquidado correctamente, se le volverán a emitir “tokens de enrutamiento” que permitirán que su próximo pago propuesto se enrute sin una tarifa. De esta manera, los pagos exitosos solo pagan la tarifa de enrutamiento real y los pagos fallidos solo pagan la tarifa inicial, lo que evita una especie de “doble tarifa” para los pagos exitosos. Al menos desde el punto de vista económico, considérelo como una especie de compromiso intermedio entre el estado actual de las cosas en el que los pagos fallidos no cuestan nada y solo los pagos exitosos pagan una tarifa, y un modelo de tarifa inicial total en el que todos los pagos pagan una tarifa inicial y los exitosos también pagan una tarifa de enrutamiento.
Conclusiones de la propuesta
Personalmente, creo que este tipo de pago directo por tokens por adelantado podría introducir un alto grado de fricción de UX en el proceso de uso de Lightning Network. Sin embargo, creo que hay una solución bastante simple para esa fricción modificando un poco la propuesta.
En lugar de tener que pagar específicamente a cada nodo directamente por los tokens de Chaumian con anticipación, la propuesta podría combinarse más directamente con la propuesta de tarifa inicial. Si tiene tokens para un nodo, inclúyalos en el blob de cebolla, si no, simplemente pague una tarifa por adelantado directamente dentro de la propuesta de HTLC y, si el pago se liquida con éxito, se le devolverán los tokens Chaumian en proporción a lo que tiene. -la tarifa por adelantado era. De esta manera, en lugar de tener que recolectar tokens de muchos nodos diferentes con anticipación, simplemente los adquiere en el transcurso de los pagos iniciales hasta que tenga una buena colección de los diferentes nodos que usa con frecuencia y muy rara vez tiene que incurrir en el costo. de honorarios por adelantado para alcanzarlos.
Otra fuente potencial de fricción es para los operadores de nodos, y se reduce a cuestiones fundamentales del propio dinero electrónico de Chaumian. Para garantizar que un token solo se gaste una vez, el emisor debe mantener una base de datos de todos los tokens que se han gastado. Esto crece para siempre, lo que hace que las búsquedas para verificar la validez del token sean cada vez más costosas y consuman más tiempo a medida que crece la base de datos. Debido a esto, Riard propone que estos tokens Chaumian caduquen periódicamente, a una altura de bloque anunciada en el protocolo de chismes por nodo. Esto significa que los remitentes deben volver a comprar periódicamente estos tokens o, si la implementación fuera compatible, canjearlos por nuevos tokens firmados por la nueva clave de firma después de que caduque la anterior.
Esto supondría un costo económico regular para los remitentes de los pagos, o requeriría que se registren periódicamente para garantizar la reemisión cuando caduquen los tokens antiguos. En la práctica, esto se puede automatizar para las personas que ejecutan sus propios nodos Lightning, y para cualquier billetera creada en torno a un modelo de proveedor de servicios Lightning (LSP), el propio LSP podría manejar la adquisición y el mantenimiento de tokens en nombre de sus usuarios, manejando el aprovisionamiento de tokens para los pagos de sus usuarios. Sin embargo, al margen, sin un nodo Lightning o LSP completo, esto podría convertirse en una molestia para los usuarios de billetera ligera.
Creo que esta propuesta en realidad podría contribuir en gran medida a mitigar la interferencia de canales como vector de ataque, especialmente si se combina un poco más estrechamente con el esquema básico de tarifas iniciales, y la mayoría de las fricciones de UX pueden manejarse muy fácilmente para los usuarios de LSP y personas que operan sus propios nodos Lightning. E incluso si las tarifas iniciales presentan un alto grado de fricción, es posible que simplemente probar el control de un Bitcoin UTXO podría usarse en lugar de pagar tarifas para adquirir tokens.
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.
