Este artículo está dedicado a la consideración de los canales de pago fuera de la cadena: sus tipos, principios operativos y características de la aplicación. El material presentado ayudará a comprender por qué la idea de los canales de pago es revolucionaria en los sistemas de contabilidad financiera. Hablaremos sobre canales de pago específicamente para Bitcoin. Este artículo será útil para aquellos que no estén familiarizados con el concepto de canales de pago, y también brindará una comprensión de los principios de la red Lightning.
Canales de pago e información básica sobre ellos.
¿Qué es un canal de pago?
Un canal de pago es un método para realizar pagos múltiples sin agregar una transacción a la cadena de bloques. Al mismo tiempo, los miembros del canal interactúan solo entre sí. No se requiere la presencia de validadores adicionales o terceros de confianza.
Beneficios del canal de pago
¿Cuáles son los beneficios de un canal de pago sobre las transacciones regulares?
Como parte de un canal de pago ya abierto, los participantes tienen la oportunidad de realizar pagos instantáneos. La parte receptora realiza una verificación rápida e independiente y acepta el pago. No hay comisiones en la versión básica. En consecuencia, los micropagos tienen un lugar para estar. Debido a esta característica, los canales de pago también se denominan canales de micropagos.
Otra ventaja interesante es que la interacción de los participantes del canal puede realizarse de forma privada. En consecuencia, los detalles de cada micropago permanecerán en secreto para todos los demás, aunque el hecho de usar un canal de pago entre direcciones específicas de Bitcoin será conocido por todos.
Funciones del canal de pago
Esto no quiere decir que los canales de pago tengan fallas serias en comparación con las transacciones regulares, pero hay algunas características.
El canal de pago debe abrirse y, en consecuencia, cerrarse tarde o temprano. Esto se realiza mediante transacciones separadas en cadena. Para ellos, el pago de una comisión es inevitable y se requiere una confirmación pendiente. Para una transacción de apertura, es mejor esperar la confirmación completa.
Dentro de un canal específico, los pagos solo están disponibles dentro de un monto predeterminado. Lo configuran los propios participantes, congelando la cantidad deseada utilizando un script especial de Bitcoin.
Los canales de pago pueden ser unidireccionales y bidireccionales, monodireccionales o bidireccionales, respectivamente. Depende de la metodología de implementación del canal en sí.
La vida útil del canal y el número máximo de pagos pueden o no estar limitados. Depende de la técnica. En consecuencia, los canales pueden cerrarse después de un cierto tiempo o antes de lo previsto. Además, el canal se puede cerrar por consentimiento mutuo de los participantes o a petición de uno de ellos, pero con algunas características.
En una versión simplificada, el funcionamiento del canal de pago puede representarse en dicho esquema.
Hay una red bitcoin. Hay dos usuarios: Alice y Bob. Tienen billeteras Bitcoin con un módulo adicional para que el canal de pago funcione de acuerdo con cierto método. Estos módulos intercambian datos por pagos directos.
¿De quién es la idea?
Por primera vez, la idea de los canales de pago fue descrita por el propio Satoshi Nakamoto en una carta personal a uno de los desarrolladores de protocolos activos hace muchos años. Luego, en Bitcoin, no se aceptaron actualizaciones bastante importantes que permitieran diseñar canales de pago confiables. Sin embargo, más tarde se hizo posible y en 2013 volvió a esta idea realmente prometedora.
Acerca de los métodos para implementar canales de pago
Consideraremos cuatro principales.
Los canales de pago estilo Spillman son la versión más simple de un canal unidireccional con una vida útil limitada y un número ilimitado de pagos.
Más tarde, se adoptó otra mejora del protocolo de Bitcoin y se hicieron posibles los canales de pago de estilo CLTV, que representan un método anterior mejorado.
Los canales de pago Poon-Dryja son un método de canal bidireccional con tiempo de ejecución ilimitado. Requieren algunas actualizaciones más al protocolo de Bitcoin que se han adoptado recientemente. Además, estos canales se utilizan en el diseño de la red de rayos.
Los canales de pago dúplex Decker-Wattenhofer son una opción para usar dos canales unidireccionales al mismo tiempo, mejorando sus propiedades al formar no una cadena secuencial de transacciones reemplazables, sino un árbol completo de transacciones reemplazables. Además, dichos canales pueden tener más de dos participantes.
Nos detendremos en los dos primeros métodos con más detalle, pero primero repetiremos algunas características del protocolo Bitcoin.
Algunos de los protocolos de Bitcoin
nLockTime es un campo en el cuerpo de cada transacción que contiene una marca de tiempo o un número de bloque. Antes de este tiempo o altura de blockchain, los validadores no pueden incluir una transacción en un bloque.
nSecuencia es un campo en cada entrada de transacción que contiene el valor del tiempo durante el cual la confirmación de esta transacción no es posible. Además, el tiempo se calcula en relación con el momento en que se confirmó la salida que esta entrada gasta.
MultiSignature permite establecer tales condiciones a la salida de una transacción, de acuerdo con las cuales es necesario proporcionar varias firmas electrónicas. Estas firmas serán verificadas por claves públicas específicas.
Canales de pago estilo Spillman
Por lo tanto, los canales de pago al estilo de Spillman son un método para crear canales de pago unidireccionales donde hay una función de remitente y una función de destinatario. El emisor establece arbitrariamente el tiempo de funcionamiento de dicho canal, mientras que el receptor puede cerrar el canal prematuramente.
Miremos los pasos principales de dicho canal en el diagrama.
Por conveniencia, imagine que hay algún servicio que intercambia el acceso a la red global a través de un punto de acceso wi-fi, y algún cliente que quiere acceder a la red por un día. El servicio costará un bitcoin. Obviamente, el cliente no confía en el servicio por tal cantidad y quiere pagar el tráfico por segundo.
Luego deciden abrir un canal de pago por un día con una cantidad de un bitcoin. El servicio genera un nuevo par de claves para la firma electrónica y transfiere la clave pública al cliente. El cliente, a su vez, genera un nuevo par de claves y utiliza su clave pública y la clave pública del servicio para formar la dirección de firma múltiple 2-de-2. Además, el cliente forma la transacción número uno, en la que envía un bitcoin a una dirección de múltiples firmas, lo firma, pero no lo distribuye a la red de Bitcoin, ya que el servicio puede sustituir al cliente y negarse a firmar cualquier transacción para la transferencia adicional de un bitcoin.
Por lo tanto, el cliente forma la transacción número dos, donde las monedas con direcciones de múltiples firmas se envían a la dirección que él controla. Además, establece el campo nLockTime para que la transacción se pueda confirmar en un día. No firma esta transacción, sino que la envía al servicio. A su vez, el servicio acepta que el cliente puede recoger la moneda completa por sí mismo, pero no antes de un día, y firma la transacción con su llave. Le pasa la firma al cliente, el cliente la verifica. Ahora tiene la oportunidad de pre-firmar la transacción con su clave y tiene la garantía de recuperar la moneda si el servicio decide rechazarlo.
En el siguiente paso, el cliente distribuye la transacción número uno a la red de Bitcoin o la transfiere al servicio para su distribución si no tiene la conexión en sí. Después de la confirmación de la primera transacción, el canal de pago se considera abierto.
En este caso, la transacción número uno se llama transacción de financiación, y la segunda es la transacción de reembolso.
¿Cómo se realiza la interacción en los cálculos dentro del canal de pago? Veamos el siguiente diagrama.
Para enviar el primer pago, el cliente solicita a Bitcoin la dirección del servicio, que controla de forma independiente. Además, el cliente forma la transacción número tres, en la cual una moneda con una dirección de múltiples firmas se distribuye entre dos salidas: la primera es un pago a la dirección del servicio en un segundo de operación del punto de acceso, y la segunda es la entrega a la dirección del cliente. El cliente firma la transacción número tres con su clave y la pasa al servicio. El servicio verifica la exactitud de la transacción y la firma, después de lo cual acepta el pago, porque puede volver a firmar esta transacción con su clave privada y se garantiza que recibirá el pago por el primer segundo de tráfico si lo hace dentro de las 24 horas. Pero si el servicio tiene la intención de continuar brindando servicio al cliente y recibir el pago dentro del canal, simplemente guarda la transacción número tres localmente hasta que se cierre el canal.
Para enviar todos los pagos posteriores, el cliente cambia el resultado de la transacción número tres, respectivamente, lo vuelve a firmar y transfiere solo la firma y el monto del cambio al servicio. El servicio también verifica los datos recibidos y guarda la nueva versión de la transacción número tres, porque en esta versión recibe más monedas.
¿Cómo se hace el cierre del canal?
El diagrama muestra que el servicio debe tener tiempo para publicar la última versión de la transacción número tres en la red Bitcoin antes del final del tiempo de operación del canal. De lo contrario, el remitente puede hacer trampa, firmar previamente y publicar la transacción número dos, donde llevará el monto total a su dirección.
Vale la pena señalar que el cliente puede publicar una transacción de reembolso en cualquier momento durante la operación del canal. El servicio consideraría que tal comportamiento es muggle. Por lo tanto, monitorea constantemente la aparición de esta transacción en la red y, si se detecta, rescinde el contrato con el cliente, cerrando el canal antes de lo previsto publicando la última versión de la transacción número tres.
Canales de pago estilo CLTV
Veamos ahora una versión mejorada de este método, a saber, canales de pago de estilo CLTV.
Este método de canales de pago se hizo aplicable después de que se llevó a cabo la actualización de Bitcoin de Softfork con la adición de un nuevo código de script: OP_CHECKLOCKTIMEVERIF Su peculiaridad es que ahora en el resultado de la transacción puede establecer tales reglas según las monedas que se pueden gastar solo en una transacción con el parámetro nLockTime establecido no menos que el especificado. De hecho, esto significa que, entre otras condiciones, las monedas se pueden gastar solo después de un cierto período de tiempo. Ahora, utilizando las operaciones de ramificación de condiciones programadas, es decir, IF-ELSE, puede establecer diferentes condiciones de gasto según el tiempo. La ventaja de estos canales de pago en comparación con los anteriores es que no necesita crear una transacción de reembolso. En cambio, puede especificar una doble condición para gastar monedas en el script de salida de la transacción de financiación. Es decir, antes del tiempo de cierre del canal, las monedas se pueden gastar de acuerdo con las reglas de la firma múltiple, y después de cerrar una firma será suficiente.
¿Cómo se aplican los canales de pago?
Hay dos opciones: ya sea en forma pura para pagos regulares entre partes preestablecidas, o la formación de una red de rayos cambiando canales entre ellos. Cambiar significa la posibilidad de realizar un pago entre usuarios que no han abierto un canal de pago entre sí, pero tienen canales abiertos con otros participantes de la red. Luego, el valor se transmitirá a través de una cadena de canales de participantes no autorizados, si existe.
En el caso de la red de rayos, existen dificultades y características adicionales. Este es el desarrollo de un formato generalmente aceptado para cambiar canales y nodos de protocolo de comunicación. Es importante que las billeteras de algunos desarrolladores puedan trabajar con billeteras de otros. Otro desafío es el problema de enrutamiento en esta red. La tarea es tal que necesita encontrar la forma más corta de transferir valor, teniendo en cuenta el hecho de que en cada canal hay restricciones en la cantidad de transferencia en cada dirección.
Funciones de red
En el siguiente diagrama, veamos las características de la red Bitcoin y la red Lightning.
En la red Bitcoin, los nodos intercambian datos sobre transacciones y bloques, así como las direcciones de red entre sí. En este caso, se llega a un consenso y se forma una base de datos común. Además de los nodos completos, hay nodos livianos en la red de Bitcoin que reciben solo la información que necesitan, sin procesar y almacenar todo el historial.
En una red de rayos, los nodos no intercambian transacciones preparadas y no llegan a un consenso. Pero también es importante para ellos actualizar la información sobre el estado del otro e intercambiar mensajes para mantener el trabajo dentro de los canales de pago. Cabe señalar que la red de rayos tampoco será homogénea, en el sentido de que habrá nodos con más y menos carga, así como nodos con actividad inestable. Lo más probable es que haya centros en la red, nodos con una gran cantidad de canales de pago abiertos y tendrán que hacer frente a una gran carga. Y los usuarios comunes abrirán en el mejor de los casos uno o dos canales de pago, y con uno de estos centros.
Esto sucederá porque, para abrir cada canal de pago, debe congelar un cierto número de monedas, luego solo puede aceptar y enviar pagos dentro de una cantidad limitada. Si un usuario común divide sus monedas en varias partes y abre varios canales, de hecho, recibirá una ventana muy pequeña para el pago en cada canal en comparación con la cantidad original. Al mismo tiempo, las grandes organizaciones como los desarrolladores de billeteras, los intercambios centralizados o los comerciantes populares actuarán como centros. Pueden permitirse mantener una gran cantidad de canales abiertos durante grandes cantidades y durante largos períodos de tiempo sin desconectarse.
Problemas candentes
Considere las preguntas frecuentes sobre los canales de pago y la red Lightning.
- ¿Qué tan confiables son los pagos en los canales en comparación con las transacciones regulares de Bitcoin?Por confiabilidad, los pagos en canales se pueden comparar con los ordinarios, es decir, las monedas no se retirarán y los pagos no se cancelarán. Pero hay una serie de características como la necesidad de abrir y cerrar los canales a tiempo, las restricciones en la cantidad dentro del canal, la necesidad de una sincronización constante con la red de Bitcoin, la probabilidad de congelar monedas por un tiempo.
- ¿El ancho de banda en los canales y la red de rayos es limitado?El hecho es que no hay restricciones, pero puede haber demoras asociadas con el procesamiento de canales, el reconocimiento de la red y la construcción de rutas, que dependen del desempeño de participantes específicos. Además, los nodos pueden desconectarse de manera impredecible, lo que puede tener ciertas restricciones para que otros participantes realicen pagos.
- ¿Deben los miembros del canal confiar entre sí?No, el mecanismo de los canales de pago brinda protección contra cualquier acción maliciosa de las partes que interactúan.
- ¿De qué sirven los canales para una persona que quiere enviar un solo pago?Si una persona quiere deshacerse de las últimas monedas y ya no planea aceptar y enviar pagos, entonces no tiene sentido abrir un canal, debe enviar una transacción normal en cadena. En todos los demás casos, será útil abrir un canal.
Una de las conferencias del curso en línea de Blockchain "
Canales de pago fuera de la cadena " también está dedicada a este tema.