Un canto común de muchos en este espacio estos días en respuesta a cualquier discusión sobre cambios en el protocolo Bitcoin es “¡No te metas con la Capa 1! ¡Puedes construirlo en la Capa 2!” Esto parece algo muy lógico, ¿verdad? ¿Por qué arriesgar la seguridad y estabilidad de L1 cuando puedes construir sobre ella? El problema es que esto esencialmente no comprende la relación entre la Capa 1 y la Capa 2.
Un protocolo L2 es una extensión del L1. Todo lo que una L2 está diseñada para hacer debe, en última instancia, reducirse a lo que la L1 es capaz de hacer. La declaración general de «¡hazlo en L2!» Ofusca numerosas realidades implícitas de lo que se puede o no se puede hacer en una L2 dado el estado actual de la capa base. Por ejemplo, imagina intentar construir Lightning Network sin la existencia de scripts de firmas múltiples. No pudiste. No sería posible compartir el control entre más de una persona y el concepto completo de canal de pago no sería posible.
La evolución de los canales de pago.
La única razón por la que pueden existir canales de pago en primer lugar es por el hecho de que L1 de Bitcoin admite la capacidad de que varias personas compartan el control de un UTXO con un script multifirma. Lo que es posible en una L2 está inherentemente limitado por lo que es posible en una L1; Sí, por supuesto que es posible hacer cosas en L2 que no son posibles en L1, pero en última instancia, el factor limitante de lo que se puede hacer fuera de la cadena es lo que es posible dentro de la cadena. La confirmación de pago más rápida en un canal de pago solo es posible porque la custodia en cadena se puede compartir entre varias personas.
Sin embargo, ni siquiera eso es suficiente para un canal de pago seguro. El canal de pago original tenía una transacción prefirmada que utilizaba un bloqueo de tiempo nLocktime que devuelve al financiador su dinero después de tantos bloqueos, y solo admitía canales de pago en una dirección. La maleabilidad de las transacciones hizo que estos canales de pago originales no fueran seguros de usar. Si alguien maltrató la transacción de financiación antes de confirmarla, entonces la transacción de reembolso quedaría invalidada y el financiador no tendría forma de reclamar su dinero. La otra parte en el canal podría efectivamente mantener su dinero como rehén.
CHECKLOCKTIMEVERIFY, el código de operación de bloqueo de tiempo absoluto, fue la solución. CLTV le permite hacer que una moneda no se pueda gastar hasta una determinada altura de bloque o momento en el futuro. Esto, en combinación con la capacidad de crear scripts que se pueden gastar de múltiples maneras, permitió que el UTXO multifirma tuviera una ruta de script donde el financiador podía gastar todos los fondos por sí mismo después de un bloqueo de tiempo. Esto garantizaba que el financiador podría reclamar la devolución del dinero en el peor de los casos, incluso si la transacción de financiación fuera maltratada. Sin embargo, el canal sólo podría facilitar los pagos unidireccionales.
Para facilitar los pagos bidireccionales, era necesaria una solución adecuada a la maleabilidad de las transacciones. Esto fue un gran motivador para Segregated Witness. Un bloqueo de tiempo es todo lo que se necesita para un canal unidireccional porque el dinero solo aumentado en una dirección. El único riesgo para el remitente era que la otra parte nunca reclamaría lo que ya se le había enviado en la cadena, dejando atrapado el resto del dinero del remitente. El reembolso del bloqueo de tiempo le dio al receptor el incentivo de reclamar fondos en la cadena antes del bloqueo de tiempo, cuando perdería todos los fondos que ya habían sido enviados, y al remitente un recurso en el peor de los casos en caso de que sucediera algo que dejara al receptor fuera de línea permanentemente. . La secuencia de comandos no admite la aplicación de ciertas cantidades a ciertas secuencias de comandos futuros, por lo que una transacción prefirmada es el único mecanismo de reembolso inicial viable si los pagos van a fluir en ambas direcciones. Esto reabrió el riesgo de que los fondos quedaran como rehenes.
Con la actualización a Segwit, este problema se solucionó. En lugar del reembolso del bloqueo de tiempo que incentiva el comportamiento honesto, se introduce la clave de penalización. Debido a que los fondos en un canal bidireccional pueden fluir hacia adelante y hacia atrás en cada dirección, inevitablemente habrá un caso en el que ambas partes tuvieran más dinero en un estado anterior del canal que en el actual. Al establecer una sucursal 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 si la otra parte intenta utilizar una transacción anterior, pueden reclamar el 100% de los fondos en el canal. Los bloqueos de tiempo se utilizan para garantizar que la ruta de gasto normal en la que los usuarios toman sus respectivos saldos no sean válidos por un tiempo para brindarles a las partes del canal la oportunidad de usar la clave de penalización si es necesario. Sin embargo, hay un problema con esto: usar CLTV significa que en algún momento en el futuro el canal tiene cerrar o, de lo contrario, el bloqueo de tiempo expirará y usted ya no tendrá ese período de seguridad para penalizar a la parte deshonesta.
Los canales de pago bidireccionales también necesitaban CHECKSEQUENCEVERIFY, o bloqueos de tiempo relativos, para resolver este problema. A diferencia de CLTV, que especifica un tiempo o altura de bloque específico en el futuro, CSV especifica una duración relativa de tiempo o número de bloques desde el momento o bloque en el que el UTXO que usa 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 necesidad de que los canales tuvieran que cerrar la cadena en un momento predeterminado.
Sin embargo, ni siquiera esto nos da la Lightning Network. Todavía no hay forma de enrutar un pago a través de Múltiples canales de pago. Pueden realizar pagos en ambas direcciones, pero sólo entre las dos personas involucradas en el canal. Para enrutar pagos a través de múltiples canales necesita, lo adivinó, otras funciones de la L1. Los contratos Hash Time Locked son la forma de lograr esto y requieren tanto CLTV como hashlocks. Los hashlocks requieren proporcionar la preimagen de un hash para poder gastar las monedas. Es como una firma, excepto que en realidad simplemente revela la «clave privada» en lugar de firmar con ella. Esto permite al receptor en un pago Lightning proporcionar un hashlock, y cada canal intermedio entre el remitente y el receptor crea un script que permite gastar inmediatamente con la preimagen del hash o reembolsar el dinero al revés después de un timelock. Si el receptor revela el hashlock, todos pueden reclamar el dinero para reenviar el pago; de lo contrario, el dinero se puede reclamar al revés y revertirlo sin finalizarlo.
Entonces, Lightning Network tal como existe hoy depende completamente de cinco Funcionalidades posibles en la capa base de Bitcoin. Scripts de firmas Múltiples, bloqueos de tiempo absolutos, bloqueos de tiempo relativos, testigos segregados y hashlocks. Sin ninguna de estas características existentes en L1, Lightning tal como lo conocemos hoy no sería una L2 posible que pudiéramos construir. Su existencia como L2 depende completamente de la capacidad de L1 para hacer ciertas cosas. Entonces, si uno lo hiciera, en un mundo con un Bitcoin que no admitiera hashlocks, timelocks en script y sin solución de maleabilidad, simplemente dijera “¡Simplemente construya un sistema de canal de pago bidireccional de Múltiples saltos en la Capa 2! No deberíamos jugar con la Capa 1”, sería una afirmación completamente incoherente.
La captura
Dicho esto, estrictamente hablando, todavía habría sido posible construir ese sistema de canal de pago bidireccional de múltiples saltos en ese mundo sin esas tres características en L1. en un masivo Costo en términos de generar confianza en otras personas para que no roben su dinero cuando sean capaces de hacerlo. Una cadena lateral federada. Todos podrían haber configurado una cadena federada como Liquid o Rootstock y agregar esas características a la cadena lateral, construyendo Lightning Network allí en lugar de en la cadena principal. El problema con eso es que no es lo mismo. A nivel técnico, la red funcionaría exactamente igual, pero nadie que la usara tendría el mismo grado de control sobre sus monedas.
Cuando cerraron un canal Lightning, se instalaría en una cadena lateral respaldada por una federación, es decir, sería simplemente un asiento contable encima de la billetera multifirma de otra persona donde no tienes la capacidad de controlar esas monedas en L1. Sólo hay que confiar en que el grupo distribuido que opera la federación no engañará a todos. Incluso las cadenas de transmisión (que irónicamente requieren que se realice una nueva funcionalidad L1) son solo otra forma de federación al final del día, con algunas restricciones adicionales agregadas al proceso de retiro. La federación está formada solo por mineros en lugar de personas que poseen claves privadas.
Esta es la realidad implícita, lo entiendan o no, que subyace a la reacción “¡simplemente constrúyalo en L2!” cada vez que alguien habla de mejoras en L1. Está el alcance de lo que ya es posible construir en L2, que es bastante limitado y restringido por sus propias limitaciones de escala, y luego está el alcance de lo que aún no es posible. Todo lo que cae en la última categoría es imposible de construir sin intervenir alguna entidad o grupo de entidades de confianza que, en última instancia, tenga el control de los fondos de los usuarios.
¿Cuál es el punto de?
La “Capa 2” no es un encantamiento mágico. No puedes simplemente agitar una varita mágica y cantar las palabras, y cualquier cosa se vuelve mágicamente posible. Existen limitaciones estrictas e ineludibles de lo que una L2 puede lograr, y esas limitaciones son lo que puede lograr una L1. Esto es sólo un hecho inherente a la realidad de la ingeniería cuando se analiza un sistema como Bitcoin. No puede escapar de él de ninguna manera, excepto degradando cada vez más los supuestos de confianza cuanto más flexible sea la L2 que construya más allá de las capacidades de la L1.
Entonces, cuando ocurren discusiones sobre estos temas, cómo qué mejoras se pueden hacer en L1, dos cosas son de suma importancia. En primer lugar, esas mejoras a la L1 se centran casi por completo en permitir la construcción de L2 más flexibles y escalables. En segundo lugar, las L2 no pueden habilitarlo todo mágicamente. Las L2 tienen sus propias limitaciones basadas en las de la L1, y tener una discusión sobre los cambios en la L1 sin reconocer que la única forma de evitar esas limitaciones es introducir entidades confiables no es una conversación honesta.
Es hora de comenzar a reconocer la realidad si vamos a discutir qué hacer con Bitcoin en el futuro; De lo contrario, no sucederá nada más que negación de la realidad e iluminación con gas. Y eso no es productivo.