El año pasado, escribí sobre Mercury Wallet de Commerceblock, una implementación de cadenas estatales y CoinSwaps. Esto introdujo simultáneamente una nueva herramienta de mezcla, así como la primera billetera para implementar una nueva solución de escalado de segunda capa. El equipo se basó en la propuesta de cadena de estado initial de Ruben Somsen con algunos cambios para que funcione sin la bandera sighash de ANYPREVOUT/Eltoo necesaria, e integró un nuevo diseño de CoinSwap para permitir a los usuarios mezclar varias veces sin necesidad de realizar transacciones en cadena para cada combinación.
Antecedentes
Para resumir rápidamente para aquellos que no leyeron mi artículo anterior: una cadena de estado es un mecanismo fuera de la cadena para transferir libremente entre cualquier persona completamente fuera de la cadena. El propietario/usuario first colabora con un operador de cadena de estado para construir una dirección ECDSA-MPC donde la clave privada se fragmenta con una mitad en manos del usuario y la otra mitad en manos del operador, luego se crea una transacción de retiro prefirmada y con límite de tiempo y firmado, con el operador antes de enviar fondos a la nueva dirección.
Ninguna de las partes controla por completo la clave privada, y el usuario tiene una transacción prefirmada que le permite recuperar unilateralmente las monedas después del bloqueo de tiempo. Cuando el usuario desea transferir la cadena de estado, notifica al operador que luego colabora con el receptor. El receptor y el operador generan un nuevo conjunto de claves privadas compartidas que se corresponden con la misma dirección y generan una nueva transacción prefirmada con un bloqueo de tiempo más bajo que la última, y luego el operador elimina su antigua clave compartida.
De la forma en que funciona la criptografía, la nueva clave compartida del operador solo funcionará con la clave compartida del nuevo usuario, por lo que si elimina la anterior, ni siquiera es posible que colabore con el antiguo usuario para gastar las monedas. Además, dado que la transacción de retiro más reciente tiene un bloqueo de tiempo más bajo, esa transacción siempre se puede confirmar antes que la del propietario anterior. Esto limita la cantidad de veces que se puede transferir la cadena de estado antes de que deba cerrarse, pero si el operador actúa con honestidad, esto evita que los propietarios antiguos roben fondos.
Un canal de relámpagos encima de una cadena de estado
Commerceblock ahora está trabajando en un nuevo BLIP (Propuesta de mejora de Bitcoin Lightning) para implementar un diseño para algo propuesto en la propuesta de cadena de estado inicial de Somsen: establecer un canal Lightning encima de una cadena de estado.
Una de las deficiencias de una cadena de estado en sí misma es que toda la UTXO debe transferirse a la vez. Sin embargo, si la transacción de retiro de statechain se gasta en un canal Lightning en lugar de en la dirección de un solo usuario, entonces se pueden transferir fracciones de statechain a través de la distribución de saldo inicial en un canal y ese canal se puede usar de manera convencional para realizar pagos Lightning posteriormente.
El proceso primero comienza cuando un usuario crea una cadena de estado. El creador y el operador pasan por el proceso standard de crear la clave fragmentada y firmar una transacción de retiro de respaldo con un bloqueo de tiempo, luego el creador (Alice) encuentra una contraparte (Bob) que aceptará cadenas de estado. Alice y Bob se involucran en el mismo protocolo utilizado para crear una clave fragmentada que Alice hizo con el operador de cadena de estado y generar su propia clave compartida. Luego, ambos comparten tanto la clave pública acumulativa como sus acciones de clave pública individuales con el operador de la cadena de estado. Esto permite que el operador los desafíe a ambos para que firmen individualmente y demuestren que están de acuerdo con el saldo real para los cierres cooperativos sin esperar a que expire el bloqueo de tiempo de retiro de la cadena de estado.
A partir de aquí, con la autorización de Bob, Alice y el operador de la cadena de estado firman una transacción pasando directamente la cadena de estado al multigrado del canal Lightning y manejan la creación de la transacción del canal Lightning. En este punto, la dirección de la cadena de estado todavía está controlada solo por Alice y el operador, pero la transacción que abre un canal Lightning ahora está en posesión de Bob con un bloqueo de tiempo más bajo que el retiro unique de la cadena de estado, lo que garantiza que se pueda confirmar antes de que Alice pueda cerrar unilateralmente la cadena de estado. a ella misma. Luego, Alice y Bob finalizan el protocolo completando una última actualización con la entidad de cadena de estado, creando una transacción de cadena de estado remaining con un bloqueo de tiempo más reducido usando su clave combinada con la del operador para realizar una transacción de retiro que gasta los fondos en el canal Lightning. Ahora ambos pueden anunciar el canal Lightning como abierto y el protocolo está completo.
Mejorando la utilidad de las cadenas de estado
Esta propuesta mejoraría en gran medida la utilidad de una cadena estatal al aflojar la estricta dinámica de liquidez de cómo funcionan. Siempre que alguien esté dispuesto a aceptar una cadena de estado pero la denominación no coincida con el pago, el remitente puede simplemente abrir un canal Lightning entre ellos y esperar hasta que necesite gastar el resto de los fondos (o terminar recibiendo lo que envió atrás) para finalizar una transferencia de todo el saldo de la cadena de estado. Tal posibilidad no solo aumenta la utilidad de una cadena de estado, sino que también aumenta la utilidad de Lightning Network si se admite adecuadamente.
El reequilibrio de canales es una necesidad para los nodos de la crimson, tanto los nodos de enrutamiento como los nodos perimetrales que simplemente envían y reciben transacciones. Cuando los fondos fluyen completamente hacia un lado de un canal, hace que el canal sea inútil para pasar pagos en una dirección (si todo el dinero está de su lado, entonces no puede recibir pagos si está del otro lado, entonces usted no puede enviar pagos). Esto requiere mover dinero de un canal a otro, lo que también contribuye a desequilibrar los canales en el camino para reequilibrar el tuyo. Eventualmente, esta dinámica llega a un punto en el que las cosas deben reequilibrarse intercambiando fondos entre Lightning y la capa base en la cadena.
Las cadenas de estado permiten que la liquidez se mueva con la misma libertad que se brinda al hacerlo en la cadena, sin necesidad de crear la huella en la cadena o pagar tarifas por ello. Digamos que tiene un canal agotado, con toda la liquidez del otro lado dejándolo, sin capacidad de gasto y también tiene una cadena de estado. Esa cadena de estado se puede transferir libremente a cualquier persona que la acepte, e incluso puede tener un canal Lightning encima si no está enviando el valor completo, y se puede usar para reequilibrar los fondos en su canal recurring de su lado. .
Esto permite mucha más eficiencia en términos de cuántos canales tiene que enrutar para reequilibrar su canal (recuerde, está contribuyendo a cambiar los saldos de todos los demás canales por los que enruta), en el mejor de los casos literalmente enviándolo directamente al mismo compañero con el que tiene abierto el canal que está reequilibrando. Si desea cerrar un canal con un par y abrirlo con otro, incluso puede reequilibrar las cosas para tener todo el equilibrium del canal y moverlo completamente fuera de la cadena al nuevo par si está construido sobre un cadena de estado
El futuro de las cadenas de estado y los rayos
Hablando de sus planes en el futuro, Nicolas Gregory de Commerceblock dijo: «Nuestro objetivo es establecer un enfoque estandarizado para combinar cadenas de estado y tecnología Lightning para facilitar el equilibrio fuera de la cadena de canales Lightning mediante el uso de canales estatales. Esta especificación servirá como la base para lograr este objetivo».
Desde el principio, siempre se propuso que las cadenas de estado interactúen con Lightning para resolver el problema de usarlas solas: que debe transferir el valor overall de la UTXO completa. También brindan un grado de flexibilidad a Lightning que no tiene por sí solo en términos de cómo se administra y transfiere la liquidez a través de la crimson.
Ahora que Lightning se encuentra en una etapa saludable en su crecimiento inicial, y ha existido una implementación concreta de cadenas de estado durante más de un año, es hora de comenzar a considerar cómo estas dos tecnologías pueden interactuar juntas. Lightning como crimson es un sistema para transferencias de custodia atómica entre dos partes que no están conectadas directamente en el gráfico de la pink. Cómo funciona cada conexión en ese gráfico, estrictamente hablando, no debería importar a los remitentes y receptores de pagos, siempre que funcione.
Los canales Statechains y Lightning tienen mucho que ofrecerse mutuamente en términos de beneficios, todo lo que se necesita hacer es trabajar en la estandarización de la interacción de los dos entre sí.
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.
