Un canto estándar de muchos en esta casa hoy en día en respuesta a cualquier discusión sobre cambios en el protocolo de Bitcoin es “¡No te metas con la Capa 1! ¡Simplemente puedes construir en la Capa 2!” Esto parece ser una cosa muy lógica de hacer, ¿verdad? ¿Por qué arriesgar la seguridad y estabilidad de L1 cuando puedes simplemente construir encima de ella? El problema es que esto falla fundamentalmente en comprender la relación entre la Capa 1 y la Capa 2.
Un protocolo L2 es una extensión de la L1. Todo lo que se diseña para hacer un L2 debe reducirse en última instancia a lo que la L1 es capaz de hacer. La afirmación general de “¡simplemente hazlo en L2!” oscurece numerosas realidades implícitas de lo que se puede o no se puede hacer en un L2 dado el estado actual de la capa base. Por ejemplo, imagina tratar de construir la Red Lightning sin la existencia de scripts multisig. No se podría. No sería posible compartir el control entre varias personas, y el concepto completo de un canal de pago no sería posible.
La Evolución de los Canales de Pago
La razón por la cual los canales de pago pueden existir en primer lugar se debe a que la L1 de Bitcoin soporta la capacidad para que varias personas compartan el control de un UTXO con un script multisig. Lo que es posible en un L2 está inherentemente limitado por lo que es posible en un L1; sí, por supuesto que es posible hacer cosas en L2 que no son posibles en L1, pero el factor limitante en última instancia de lo que puedes hacer fuera de la cadena es lo que es posible en la cadena. La confirmación más rápida de pagos en un canal de pago es posible porque la custodia en la cadena puede ser compartida entre varias personas.
Incluso eso no es suficiente para un canal de pago seguro. El canal de pago original tenía una transacción prefirmada que utilizaba un bloqueo temporal nLocktime que le da al financiador su dinero de vuelta después de tantos bloques, y solo admitía canales de pago en una dirección. La maleabilidad de la transacción hizo que estos canales de pago originales fueran inseguros de usar. Si la transacción de financiamiento era maleada por alguien antes de confirmarse, entonces la transacción de reembolso se invalidaría y el financiador no tendría forma de reclamar su dinero de vuelta. La otra parte en el canal podría efectivamente retener su dinero como rehén.
CHECKLOCKTIMEVERIFY, el opcode de bloqueo absoluto en el tiempo, fue la solución. CLTV te permite hacer que una moneda no se pueda gastar hasta un cierto bloque o tiempo en el futuro. Esto, junto con la capacidad de crear scripts que pueden gastarse de varias formas, permitió que el UTXO multisig tuviera una ruta de script donde el financiador podría gastar todos los fondos ellos mismos después de un bloqueo temporal. Esto garantizaba que el financiador pudiera reclamar el dinero en caso de un escenario catastrófico incluso si la transacción de financiamiento era maleada. Sin embargo, el canal todavía solo podía facilitar pagos en una dirección.
Para facilitar pagos en ambas direcciones, era necesaria una solución adecuada para la maleabilidad de la transacción. Esto fue un gran motivador para Segregated Witness. Un bloqueo temporal era todo lo que se necesitaba para un canal unidireccional porque el dinero solo aumentaba en una dirección. El único riesgo para el remitente era que la otra parte nunca reclamara lo que ya se le había enviado en la cadena, dejando el resto del dinero del remitente atrapado. El reembolso del bloqueo temporal daba al receptor la motivación para reclamar los fondos en la cadena antes del bloqueo temporal, cuando perderían todos los fondos que ya se les habían enviado, y al remitente un recurso en caso de que algo sucediera para desconectar permanentemente al receptor. Los scripts no admiten la imposición de ciertas cantidades en scripts futuros, por lo que una transacción prefirmada es el único mecanismo de reembolso inicial viable si los fondos van a fluir en ambas direcciones. Esto reabrió el riesgo de que los fondos fueran retenidos como rehenes.
Con la actualización a Segwit, este problema se solucionó. En lugar de que el reembolso del bloqueo temporal incentivara el comportamiento honesto, se introdujo la clave de penalización. Dado que los fondos en un canal bidireccional pueden fluir en ambas direcciones, inevitablemente habrá un caso en el que ambos lados tenían más dinero en un estado anterior del canal que en el actual. Al establecer una rama en la transacción prefirmada de cada estado del canal utilizando una clave de penalización, los usuarios pueden intercambiarlas después de firmar el nuevo estado y saber que si la otra parte intenta usar una transacción antigua, pueden reclamar el 100% de los fondos en el canal. Los bloqueos temporales se utilizan para garantizar que la ruta de gasto normal donde los usuarios toman sus saldos respectivos no sea válida durante un tiempo para dar a las partes del canal la oportunidad de utilizar la clave de penalización si es necesario. Sin embargo, hay un problema con esto, el uso de CLTV implica que en algún momento futuro el canal debe cerrarse o de lo contrario el bloqueo temporal expirará y ya no tendrás ese período de seguridad para penalizar a la parte deshonesta.
Los canales de pago bidireccionales también necesitaban CHECKSEQUENCEVERIFY, o bloqueos temporales relativos, para resolver este problema. A diferencia de CLTV, que especifica un tiempo o bloque específico en el futuro, CSV especifica una duración de tiempo o número de bloques desde el momento o bloque en el que el UTXO que utiliza CSV en el script se confirma en la cadena de bloques. Esto permitió que el período de seguridad funcionara para el uso de la clave de penalización sin requerir que los canales se cerraran en cadena en un momento predefinido.
Incluso esto no nos da la Red Lightning tal como existe hoy. Todavía no hay forma de enrutar un pago a través de varios canales de pago. Pueden realizar pagos en ambas direcciones, pero solo entre las dos personas involucradas en el canal. Para enrutar pagos a través de varios canales se necesita, adivinaste, otra funcionalidad de la L1. Los Contratos Bloqueados por Tiempo y Hash son la forma en que se hace esto, y requieren tanto CLTV como hashlocks. Los hashlocks requieren proporcionar la preimagen a un hash para poder gastar el dinero. Es como una firma, excepto que realmente solo revelas la “clave privada” en lugar de firmar con ella. Esto permite que el receptor en un pago de Lightning proporcione un hashlock, y cada canal intermedio entre el remitente y el receptor crea un script que permite gastar directamente con la preimagen del hash, o reembolsar el dinero hacia atrás después de un bloqueo temporal. Si el receptor revela el hashlock, todos pueden reclamar el dinero por el envío del pago, si no, entonces el dinero se puede reclamar hacia atrás y revertir sin finalizarlo.
Por lo tanto, la Red Lightning tal como existe hoy depende completamente de 5 funcionalidades que son posibles en la capa base de Bitcoin. Scripts multisig, bloqueos temporales absolutos, bloqueos temporales relativos, Segregated Witness y hashlocks. Sin ninguna de estas características presentes en L1, Lightning tal como la conocemos hoy no sería una L2 posible que podríamos construir. Su existencia como L2 depende completamente de la capacidad de L1 para hacer ciertas cosas. Por lo tanto, si en un mundo con un Bitcoin que no admitiera hashlocks, bloqueos temporales en el script y sin corrección de maleabilidad, simplemente se dijera “¡Construye un sistema de canal de pago multi-direccional de varios saltos en la Capa 2! No deberíamos estar jugando con la Capa 1” sería una declaración totalmente incoherente.
El Problema
Dicho esto, estrictamente hablando técnicamente, todavía sería posible construir ese sistema de canal de pago multi-direccional de varios saltos en ese mundo sin esas tres características en L1. A un gran costo en términos de introducir confianza en otras personas para que no roben tu dinero cuando puedan hacerlo. Una sidechain federada. Todos podrían haber configurado fácilmente una cadena federada como Liquid o Rootstock y agregado esas características a la sidechain, construyendo la Red Lightning allí en lugar de en la mainchain. El problema con eso es que no es lo mismo. A nivel técnico, la red funcionaría exactamente igual, pero nadie que la use realmente tendría el mismo grado de control sobre su dinero.
Cuando cerraran un canal de Lightning, se decidiría en una sidechain respaldada por una federación, es decir, simplemente sería una entrada contable sobre la billetera multisig de otra persona donde no tienes forma de controlar esos fondos en L1. Simplemente debes confiar en el grupo distribuido que opera la federación para no engañar a todos. Incluso las drivechains (que irónicamente requieren nueva funcionalidad de L1 para ser realizadas) son solo otra forma de federación al final del día, con algunas restricciones adicionales agregadas al proceso de retiro. La federación son simplemente mineros en lugar de personas que poseen claves privadas.
Esta es la realidad implícita, ya sea que lo entiendan o no, que subyace a la respuesta “¡simplemente constrúyelo en L2!” cada vez que alguien está discutiendo mejoras en L1. Existe el alcance de lo que ya es posible construir en L2, que es bastante limitado y limitado por sus propias limitaciones de escalabilidad, y luego está el alcance de lo que no es posible actualmente. Todo lo que cae en la última categoría es imposible de construir sin inyectar alguna entidad o grupo de entidades confiables que en última instancia son responsables de los fondos de los usuarios.
¿Cuál es el Punto?
“Capa 2” no es una fórmula mágica. No puedes simplemente agitar una varita mágica y recitar las palabras, y todo se convierte mágicamente en posible. Hay limitaciones estrictas e inevitables de lo que un L2 puede lograr, y esas limitaciones son las que puede lograr la L1. Esta es simplemente una realidad inherente de la ingeniería cuando se trata de un sistema como Bitcoin. No se puede escapar de ninguna manera, excepto degradando las suposiciones de confianza cada vez más a medida que se construye un L2 más flexible más allá de las capacidades de L1.
Por lo tanto, cuando se producen discusiones sobre estos temas, como qué mejoras se pueden hacer en L1, dos cosas son de suma importancia. Primero, estas mejoras en L1 se centran casi por completo en habilitar la construcción de L2s más flexibles y escalables. En segundo lugar, los L2 no pueden habilitar mágicamente todo. Los L2 tienen sus propias limitaciones basadas en las de L1, y tener una discusión sobre cambios en L1 sin reconocer que la única forma de superar esas limitaciones es introduciendo entidades confiables no es una conversación honesta.
Es hora de empezar a reconocer la realidad si vamos a discutir qué hacer con Bitcoin en el futuro, de lo contrario no estaremos haciendo más que negar la realidad y manipularla. Y eso no es productivo.
