Hace poco más de un año, los tres equipos de implementación de la red de Lightning aunaron esfuerzos para colaborar en una especificación común para la pila de protocolos. Ahora que tanto la especificación como nuestras tres implementaciones se están estabilizando y son utilizables, llegó el momento de mirar hacia adelante: mejorar aún más el protocolo, añadir nuevas características, simplificar y corregir los defectos.
Una de las innovaciones clave que hicieron posible la existencia de Lightning fue un mecanismo de actualización off-chain que permitía renegociar un nuevo estado y garantizar que el estado anterior no pudiese confirmarse on-chain. Hoy, nos complace anunciar la publicación de nuestra investigación más reciente sobre un mecanismo de actualización nuevo y simplificado para protocolos de nivel 2, llamado eltoo.
¿Cómo funciona eltoo?
Imaginemos que una negociación off-chain es un acuerdo contractual entre un número de partes, y la confirmación es la presentación de un caso ante un tribunal que decidirá el estado final (en este caso, el tribunal es la blockchain). Dado que todas las actualizaciones se producen off-chain, necesitamos una forma de que un tribunal on-chain escuche todas las voces del caso antes de tomar una decisión definitiva. En el caso de que un participante inicie la resolución de un contrato, necesitamos un mecanismo que postergue la confirmación definitiva, de modo que la contraparte tenga la oportunidad de presentar un estado más reciente. El tribunal debe seguir esperando un nuevo estado, hasta que finalmente decida resolver en base al último que se le presentó. Es sorprendente que la blockchain de Bitcoin ya cumple la mayoría de los requisitos para crear este blockchain a medida para protocolos de nivel 2.
Figura 1: Un ejemplo de la ejecución del protocolo de eltoo, en el que se muestra que los estados intermedios pueden saltearse uniendo una transacción de actualización posterior a una anterior, o directamente a la transacción de configuración. La última transacción de confirmación es la única que puede confirmarse en la blockchain.
En eltoo, cada estado está representado como un conjunto de dos transacciones: una transacción de actualización que consume el output del contrato y crea un nuevo output, y una transacción de confirmación que consume el output de actualización recientemente creado y divide los fondos de acuerdo con la distribución estipulada. Los outputs tienen un script que permite que se anexe inmediatamente una nueva transacción de actualización, o que se anexe una transacción de configuración después de un límite de tiempo configurable. En caso de que los participantes aceptan de común acuerdo una actualización antes del vencimiento del límite de tiempo, crearán una nueva transacción de actualización, con lo que consumirán el output anterior y consumirán en duplicado la confirmación correspondiente, con lo que la tornarán inválida.
La invalidación repetida de estados previos para aceptar un estado nuevo crea una larga cadena de transacciones de actualización, que finalmente quedarán concluidas mediante la última transacción de confirmación. Sin embargo, esto tiene una desventaja considerable: en caso de querer confirmar, tendríamos que volver a reproducir toda la cadena de actualizaciones en la blockchain. En ese punto, podríamos simplemente ejecutar el protocolo completo on-chain. El avance clave de eltoo es que podemos saltear las actualizaciones intermedias, con lo que en esencia se conecta la transacción de actualización final con la creación del contrato. Con el fin de posibilitar este cortocircuito de actualizaciones, proponemos un nuevo indicador de SIGHASH, SIGHASH_NOINPUT, que permite que el input de una transacción esté ligado al output de cualquier transacción que tenga el mismo script. Dado que todos los scripts de los outputs de transacciones de actualizaciones anteriores coinciden con los scripts de inputs posteriores, podemos unir una actualización posterior con cualquier actualización anterior, lo que nos permite saltear cualquier cantidad de actualizaciones intermedias. El artículo contiene la construcción completa del protocolo, incluidos los detalles sobre el desarrollo de los scripts.
Mejorar Lightning
Lo que presentamos arriba es un mecanismo de actualización que permite que los extremos de un canal de pago ajusten reiteradamente sus saldos y enlacen componentes más avanzados, tales como los HTLC, al estado.
El principal aporte del paper original de Lightning fue un mecanismo de actualización de estas características, entonces se preguntarán: ¿eso significa que con esta propuesta estamos tratando de reemplazar Lightning? ¡Por supuesto que no!
Figura 2: Un diagrama de los diversos subprotocolos que conforman la pila de Lightning.
La especificación de la red de Lightning ya no es la especificación de un protocolo único, sino más bien una pila de protocolos, cada uno de los cuales cumple su propia función. eltoo no apunta a reemplazar la totalidad de la pila de Lightning, sino que es un reemplazo directo del mecanismo de actualizaciones original que mantiene la compatibilidad retroactiva con los demás componentes de la pila.
eltoo tiene formas de compensación fundamentalmente diferentes del mecanismo presentado en el artículo original de Lightning, que llamaremos LN-penalty; así como LN-penalty utilizó un sistema de penalidades para castigar la mala conducta de una parte, eltoo simplemente refuerza el estado estipulado más reciente del contrato off-chain. Esto tiene implicancias importantes para la aplicabilidad y la seguridad de los protocolos que se desarrollen a partir del mecanismo de actualización.
Una parte surge del hecho de que, en eltoo, todos los participantes comparten un conjunto común de transacciones, a diferencia de LN-penalty, que requiere la asimetría en lo que respecta a qué participantes tienen acceso a qué transacciones, con el fin de adaptar la reacción a la parte que incurrió en mala conducta. Este cambio elimina lo que denominamos la información tóxica en Lightning. La información tóxica proviene de transacciones correspondientes a estados desactualizados, que podrían generar la pérdida de fondos en caso de filtrarse. Esto se puede producir no solo en caso de mala conducta de una parte, sino también si un nodo se olvida de una actualización (ej.: cuando se hace una restauración a partir de una copia de seguridad). Con eltoo, eso ya no es posible, ya que solo pueden confirmarse los estados estipulados (es decir, en eltoo no hay penalidades).
Con el nuevo paradigma, también se simplifica la gestión de datos para los participantes: ya no necesitan almacenar las preimágenes de hash para los estados invalidados ni los HTLC invalidados, ya que la transacción de confirmación a la que estaban anexados no puede ingresarse a la blockchain. Lo único que necesitan almacenar es la transacción de actualización más reciente, la transacción de confirmación correspondiente y, potencialmente, los HTLC que podrían consumir en el marco de esa confirmación. Además, se simplifica la confirmación y pasa a ser una simple unión de la transacción de actualización más reciente con el output de configuración, y a permitir que caduque el límite de tiempo antes de la emisión de la transacción de confirmación.
Podemos combinar los outputs de actualización con SIGHASH_SINGLE para permitir el vínculo de inputs y outputs adicionales con la transacción de actualización al momento de la confirmación. Si bien este puede parecer un cambio menor, permite el vínculo de las tarifas con las transacciones de actualización al momento de la confirmación, lo que nos exime de tener que comprometernos a una tarifa fija con anticipación. Con las implementaciones actuales, tendríamos que acordar y comprometernos a una tarifa fija, potencialmente meses antes de intentar confirmar las transacciones on-chain, lo que nos obligaría a predecir cómo evolucionará el mercado; esto implicaría un compromiso demasiado fuerte para ir por lo seguro. Con la selección de la tarifa diferida, ya no tenemos que comprometernos a una tarifa, e incluso podemos aumentarlas en caso de que resulten insuficientes.
Gracias al uso de los indicadores de características, que permiten que un nodo indique el respaldo a una característica nueva cuando se conecta por primera vez con un usuario, eltoo puede desplegarse gradualmente tomando como base la red actual. No es necesario desarrollar una red completamente nueva.
Más allá de Lightning
Como mecanismo de actualización de nivel 2 genérico, eltoo puede utilizarse en una serie de sistemas además de Lightning. Por ejemplo, permite la creación de contratos off-chain con múltiples partes, que actualmente están limitados a un máximo de siete participantes, con lo que podrían tener un número indefinido de participantes que utilicen firmas Schnorr.
Un ejemplo de contrato off-chain con múltiples partes son las fábricas de canales presentadas en Burchert et al. como una opción ampliable para financiar cualquier cantidad de canales de pago a partir de una única transacción on-chain y reequilibrar o reasignarlas dinámicamente sin tener que tocar la blockchain.
El camino a eltoo
Antes de que podamos implementar eltoo, tenemos que hacer un cambio menor a Bitcoin: introducir el indicador de SIGHASH_NOINPUT para las firmas. Esto se debatió por primera vez hace unos meses en el contexto de las torres de vigilancia para ayudar a preservar la seguridad de los canales de Lightning, pero no se hizo una propuesta formal. En el paper de eltoo se incluye una propuesta formal al respecto.
Invitamos a la comunidad a analizar nuestra propuesta y a participar en el debate. Esperamos llegar a un consenso sobre el uso de SIGHASH_NOINPUT, de modo que pueda ser aceptado e incluido en un soft fork futuro del script de Bitcoin. Eso nos pondrá en el rumbo hacia una red de Lightning más confiable y sencilla, ya que se incorporará un mecanismo de actualizaciones nuevo que podría utilizarse en muchas otras aplicaciones.