Canales de estado

¿Qué son los canales de estado en cripto?

Los canales de estado son sistemas de escalabilidad off-chain que permiten a dos o más participantes actualizar un estado compartido de blockchain de forma privada y rápida, y liquidar después el resultado final on-chain.

En criptomonedas, un canal de estado suele abrirse bloqueando activos o el estado de una aplicación en un contrato inteligente o una estructura multifirma en la blockchain base.

Una vez abierto el canal, los participantes intercambian mensajes firmados off-chain en lugar de enviar cada acción a la blockchain.

Cada mensaje firmado representa una versión más reciente del estado del canal.

Cuando los participantes terminan, pueden cerrar el canal y enviar el último estado acordado a la blockchain para su liquidación.

La documentación oficial de canales de estado de Ethereum explica que los canales de estado permiten a los participantes realizar transacciones off-chain y liquidar la finalidad con Ethereum Mainnet.

Esto hace que los canales de estado sean útiles para pagos, juegos, interacciones de trading, micropagos, pagos en streaming y transacciones repetidas entre partes conocidas.

Reducen la congestión on-chain porque normalmente solo la apertura y el cierre del canal necesitan transacciones de blockchain.

También pueden reducir las comisiones, ya que se pueden realizar muchas actualizaciones off-chain sin pagar gas por cada una.

En términos sencillos, un canal de estado es un espacio privado off-chain donde los usuarios actualizan saldos o el estado de una aplicación muchas veces y, después, llevan solo el resultado final a la blockchain.

Por qué son importantes los canales de estado

Los canales de estado son importantes porque las blockchains públicas tienen un espacio de bloque limitado.

Si cada pago pequeño, movimiento de juego o actualización de una aplicación debe enviarse on-chain, los usuarios pueden afrontar comisiones más altas y tiempos de confirmación más lentos cuando la red está congestionada.

Los canales de estado trasladan las interacciones repetidas off-chain, mientras siguen utilizando la blockchain como capa de liquidación final y resolución de disputas.

Esto puede hacer que las aplicaciones cripto parezcan más rápidas porque los participantes no necesitan esperar confirmaciones de bloque tras cada actualización.

También puede hacer más prácticos los pagos de pequeño valor, ya que los usuarios no tienen que pagar una comisión on-chain por cada transferencia.

La documentación oficial sobre escalabilidad de Ethereum describe los canales de estado como un método de escalabilidad que utiliza contratos multisig para que los participantes puedan realizar transacciones rápida y libremente off-chain, y liquidar la finalidad on-chain.

Este diseño es importante porque preserva parte de la seguridad de la blockchain y reduce la carga de trabajo on-chain.

Los participantes no necesitan confiar en un operador centralizado para actualizar los saldos correctamente.

Dependen de mensajes firmados y de la capacidad de disputar estados antiguos o no válidos on-chain.

Por tanto, los canales de estado son una de las ideas de escalabilidad de Layer 2 más tempranas e importantes en cripto.

Cómo funcionan los canales de estado

Un canal de estado suele tener tres etapas: apertura, actualización y cierre.

En la etapa de apertura, los participantes crean una transacción on-chain que bloquea activos o inicializa el estado de la aplicación en un contrato o salida multifirma.

Esta transacción de apertura define las reglas del canal.

Puede definir los participantes, saldos, periodos de disputa, requisitos de firma, reglas de tiempo de espera y condiciones de salida.

En la etapa de actualización, los participantes intercambian mensajes firmados off-chain.

Cada mensaje representa un estado nuevo, como una nueva distribución de saldos o una posición de juego.

Los participantes conservan el último estado firmado, ya que podría ser el que necesiten utilizar si surge una disputa.

En la etapa de cierre, los participantes liquidan el canal on-chain.

Si todos cooperan, pueden cerrarlo rápidamente enviando el último estado acordado.

Si un participante intenta hacer trampas o desaparece, el otro puede utilizar el proceso de disputa para enviar un estado válido más reciente.

Canales de estado frente a canales de pago

Un canal de pago es un tipo específico de canal de estado centrado únicamente en pagos.

Un canal de estado es más amplio porque puede actualizar cualquier estado de aplicación compatible, no solo saldos.

Por ejemplo, un canal de pago puede permitir a Alice y Bob enviarse valor mutuamente muchas veces antes de liquidar el saldo final.

Un canal de estado también puede admitir una partida de ajedrez, un juego por turnos, una interacción de marketplace, una suscripción o un acuerdo de servicio repetido.

La documentación de Lightning Network describe un sistema descentralizado en el que las transacciones se envían mediante una red de canales de micropagos, también llamados canales de pago o canales de transacciones.

Los canales de pago son más fáciles de entender porque su estado suele limitarse a quién posee qué cantidad de valor.

Los canales de estado generales son más flexibles porque su estado puede incluir lógica de aplicación.

Esta flexibilidad también hace que sea más difícil diseñarlos de forma segura.

Cada participante debe poder verificar cada actualización off-chain y aplicar el estado final correcto si es necesario.

La forma más sencilla de recordar la diferencia es que todos los canales de pago son canales de estado, pero no todos los canales de estado son únicamente canales de pago.

Canales de estado frente a rollups

Los canales de estado y los rollups son métodos de escalabilidad de Layer 2, pero funcionan de forma muy distinta.

Un canal de estado suele ser más adecuado para interacciones repetidas entre un conjunto conocido de participantes.

Un rollup suele ser mejor para aplicaciones abiertas en las que muchos usuarios pueden unirse sin abrir canales directos entre sí.

En un canal de estado, la mayoría de las actualizaciones se realizan de forma privada entre participantes y no se publican en la cadena base salvo que el canal se cierre o entre en disputa.

En un rollup, muchas transacciones se ejecutan fuera de la capa base, pero los datos de transacciones o las pruebas se vuelven a publicar en la capa base conforme al diseño del rollup.

La documentación oficial sobre rollups de conocimiento cero de Ethereum explica que los zk-rollups envían pruebas de validez para verificar que las transiciones de estado son correctas.

Los canales de estado suelen ofrecer interacciones muy rápidas entre participantes, pero son menos prácticos para aplicaciones públicas amplias con muchos usuarios cambiantes.

Los rollups pueden admitir una actividad de contratos inteligentes más general, pero pueden seguir implicando secuenciadores, retrasos de bridges, costes de datos y sistemas de pruebas.

Los canales de estado son como carriles privados entre usuarios conocidos.

Los rollups son como entornos de ejecución independientes que agrupan a muchos usuarios.

Canales de estado frente a sidechains

Una sidechain es una blockchain independiente que funciona junto a otra blockchain.

Un canal de estado no es una blockchain independiente.

Es un acuerdo off-chain entre participantes que puede aplicarse mediante la cadena base.

Las sidechains suelen tener sus propios validadores, reglas de consenso, bloques y supuestos de seguridad.

Los canales de estado dependen más directamente de la cadena base para la liquidación final y la resolución de disputas.

Esta diferencia importa porque los usuarios de sidechains normalmente confían en el conjunto de validadores de la sidechain o en el diseño del bridge.

Los usuarios de canales de estado dependen de firmas criptográficas, fondos bloqueados y la capacidad de impugnar estados no válidos.

Una sidechain puede admitir muchos usuarios y aplicaciones de forma más abierta.

Un canal de estado suele estar más limitado a participantes concretos y a una lógica de aplicación específica.

La mejor herramienta de escalabilidad depende del caso de uso, el modelo de confianza, la experiencia de usuario y los requisitos de seguridad.

Apertura de un canal de estado

Abrir un canal de estado requiere una transacción on-chain.

Esta transacción suele bloquear fondos o comprometer el estado inicial en un contrato.

Los participantes deben acordar los saldos iniciales, las reglas y los parámetros del canal.

En cadenas de contratos inteligentes basadas en cuentas, el canal puede gestionarse mediante un contrato inteligente.

En cadenas basadas en UTXO, un canal de pago puede anclarse mediante una salida multifirma.

La transacción de apertura crea la base de seguridad del canal.

Si el estado de apertura es incorrecto, las actualizaciones off-chain posteriores también pueden ser incorrectas.

Los usuarios deben verificar el importe bloqueado, las contrapartes, las reglas de tiempo de espera y las condiciones de cierre antes de abrir un canal.

Abrir un canal puede conllevar una comisión on-chain, pero ese coste puede repartirse entre muchas actualizaciones off-chain posteriores.

Por este motivo, los canales de estado son más útiles cuando los participantes prevén interactuar muchas veces.

Actualización de un canal de estado

La actualización de un canal de estado se realiza off-chain.

Los participantes firman mensajes que representan el estado acordado más reciente.

Una actualización de pago puede modificar la distribución de saldos entre participantes.

Una actualización de juego puede modificar las posiciones de los jugadores, las puntuaciones o el orden de turnos.

Una actualización de servicio puede registrar cuánto trabajo se ha entregado y pagado.

Cada nueva actualización debe hacer que las actualizaciones anteriores no sean seguras de enviar o sean fáciles de impugnar.

Esto suele gestionarse mediante números de secuencia, nonces, marcas de tiempo, penalizaciones o reglas de disputa.

Los participantes deben almacenar de forma segura la última actualización firmada.

Si una contraparte envía posteriormente un estado antiguo, el participante honesto necesita el estado más reciente para impugnarlo.

Las actualizaciones de canales son rápidas porque no necesitan confirmación de bloque hasta la liquidación o la disputa.

Cierre de un canal de estado

Cerrar un canal de estado devuelve el resultado final a la cadena.

Un cierre cooperativo se produce cuando todos los participantes necesarios acuerdan el estado final y lo envían conjuntamente.

Un cierre cooperativo suele ser más rápido y barato que un cierre disputado.

Un cierre unilateral se produce cuando un participante cierra el canal sin la cooperación plena de los demás.

Esto puede activar un periodo de disputa.

Durante el periodo de disputa, los demás participantes pueden enviar un estado válido más reciente si quien cerró el canal presentó un estado desactualizado.

Si no se presenta ninguna impugnación válida antes de que venza el plazo, el estado enviado puede finalizarse.

La lógica de cierre es una de las partes más importantes de la seguridad de los canales de estado.

Si el proceso de disputa es demasiado corto, los usuarios honestos podrían no tener tiempo suficiente para responder.

Si es demasiado largo, los fondos pueden permanecer bloqueados más tiempo del que desean los usuarios.

Periodos de disputa

Un periodo de disputa es el intervalo durante el cual los participantes pueden impugnar un cierre de canal propuesto.

Los periodos de disputa protegen a los usuarios frente a contrapartes que intentan liquidar un estado antiguo o deshonesto.

Por ejemplo, una contraparte podría intentar cerrar el canal utilizando un saldo anterior en el que poseía más fondos.

Si el usuario honesto tiene un estado firmado más reciente, puede enviarlo durante el periodo de disputa.

El contrato puede entonces reconocer el estado más reciente y rechazar o penalizar el desactualizado, según el diseño.

Los periodos de disputa implican una compensación.

Un periodo más largo da a los usuarios honestos más tiempo para responder.

Un periodo más largo también retrasa la retirada final de fondos.

Un periodo más corto mejora la velocidad, pero exige que los usuarios o las watchtowers supervisen los canales más estrechamente.

El periodo de disputa adecuado depende de la cadena, la aplicación, el comportamiento de los usuarios y el modelo de amenazas.

Watchtowers

Una watchtower es un servicio o sistema que supervisa la blockchain en nombre de los usuarios para detectar cierres de canal deshonestos.

Las watchtowers son especialmente importantes cuando los usuarios pueden desconectarse.

Si un usuario está desconectado durante un periodo de disputa, podría perder la oportunidad de impugnar un estado desactualizado.

Una watchtower puede vigilar intentos de cierre de canal y responder con los datos correctos si es necesario.

La documentación de canales de pago de Lightning describe los canales de pago como contratos multifirma entre pares que pueden liquidarse en la blockchain.

Dado que la liquidación puede implicar riesgo de estado antiguo, la supervisión es una parte importante de la seguridad del canal.

Las watchtowers pueden mejorar la seguridad de los usuarios, pero también pueden introducir consideraciones de privacidad y confianza.

Puede que un usuario no quiera revelar demasiada información del canal a una watchtower.

Un buen diseño de watchtower debe minimizar la confianza necesaria y seguir proporcionando una supervisión útil.

Los usuarios deben comprender si su cartera incluye supervisión o requiere un servicio independiente.

Contratos multifirma

Muchos canales de estado utilizan estructuras multifirma para bloquear fondos o estado.

Una configuración multifirma requiere más de una firma para mover fondos en condiciones normales.

Esto evita que un participante pueda robar unilateralmente los fondos mientras el canal opera con normalidad.

En un canal de pago entre dos partes, ambos participantes pueden controlar inicialmente la salida bloqueada o el estado del contrato mediante un acuerdo compartido.

Las actualizaciones firmadas off-chain definen cómo deben distribuirse los fondos si el canal se cierra.

Multisig es útil porque crea una bóveda compartida para los activos del canal.

El contrato o script del canal define entonces cómo puede liquidarse esa bóveda.

Multisig no resuelve todos los problemas por sí solo.

El canal sigue necesitando reglas de actualización, reglas de disputa, reglas de tiempo de espera y un comportamiento seguro de la cartera.

Multisig es el mecanismo de bloqueo, mientras que el protocolo del canal es el sistema completo de liquidación off-chain.

Canales de pago y Lightning Network

Lightning Network es la red de canales de pago más conocida en cripto.

La descripción general oficial de Lightning Network la presenta como una red de pagos peer-to-peer que utiliza canales de pago anclados en la blockchain de Bitcoin para liquidaciones casi instantáneas y de bajo coste.

Lightning muestra cómo los canales de pago individuales pueden conectarse en una red más amplia.

Un usuario no necesita tener un canal directo con cada posible destinatario si el enrutamiento de pagos puede encontrar una ruta entre canales conectados.

Los pagos pueden desplazarse por varios canales utilizando condiciones criptográficas que reducen la necesidad de confiar en intermediarios.

Este modelo de red es más flexible que los canales aislados entre dos partes.

Sin embargo, el enrutamiento introduce retos de liquidez, fiabilidad, privacidad y operativa.

Los canales deben tener suficiente liquidez en la dirección correcta para que los pagos tengan éxito.

Puede que los nodos deban permanecer online o utilizar infraestructura de apoyo.

Lightning es un ejemplo de canal de pago, mientras que el concepto más amplio de canal de estado puede aplicarse a más cosas que los pagos.

Canales virtuales

Un canal virtual es un canal creado a través de uno o más canales intermediarios sin abrir un nuevo canal on-chain directo entre los participantes finales.

Los canales virtuales pueden mejorar la usabilidad porque los usuarios quizá no necesiten abrir un canal on-chain con cada contraparte.

El sitio del proyecto State Channels describe los canales de estado como una tecnología de escalabilidad para Ethereum que permite interacciones peer-to-peer instantáneas y analiza los canales virtuales como una forma de crear una red de canales de estado.

Los canales virtuales pueden reducir el número de transacciones on-chain necesarias para admitir muchas relaciones off-chain.

También pueden mejorar los efectos de red porque los usuarios pueden conectarse a través de rutas de canal existentes.

Sin embargo, los canales virtuales añaden complejidad.

Requieren enrutamiento, gestión de garantías, coordinación de participantes y una lógica de liquidación correcta en múltiples relaciones.

Si están mal diseñados, los canales virtuales pueden provocar bloqueo de liquidez o complejidad en las disputas.

Son una dirección importante de investigación e ingeniería porque los canales aislados pueden ser demasiado limitados para un uso a gran escala.

El objetivo es lograr que las interacciones off-chain parezcan conectadas sin obligar a cada par de usuarios a abrir un canal directo.

Redes de canales de estado

Una red de canales de estado conecta muchos canales individuales para que los participantes puedan interactuar sin abrir canales directos con todos los demás participantes.

Las redes de canales de pago son el ejemplo más sencillo porque el valor puede enrutarse a través de rutas de liquidez conectadas.

Las redes de canales de estado generales son más difíciles porque el estado puede representar una lógica de aplicación más compleja que los saldos de pago.

Una red necesita coordinación de enrutamiento, liquidez, garantías, tiempos de espera y disputas.

También necesita estándares para que las carteras y aplicaciones puedan comprender las actualizaciones de canales de forma segura.

Las redes de canales pueden mejorar la escalabilidad porque muchas interacciones off-chain pueden producirse mientras la cadena base sigue siendo una capa de liquidación.

También pueden mejorar la experiencia de usuario porque quizá no sea necesario crear un nuevo contrato on-chain para cada interacción.

El principal reto es que los canales requieren coordinación online y capital bloqueado.

Una red con poca liquidez puede no enrutar pagos o interacciones de forma fiable.

Una red con una supervisión deficiente puede exponer a los usuarios a ataques con estados desactualizados.

Canales de estado y contratos inteligentes

Los contratos inteligentes hacen que los canales de estado sean más flexibles.

Un contrato inteligente puede definir las reglas de apertura, validación de actualizaciones, proceso de disputa y liquidación de un canal.

También puede aplicar reglas específicas de una aplicación si una disputa llega a la cadena.

Por ejemplo, el contrato de un canal de juego puede verificar movimientos firmados y decidir el ganador si los participantes no están de acuerdo.

Un contrato de canal de pago puede verificar actualizaciones de saldo firmadas y distribuir los fondos en consecuencia.

Un contrato de canal de trading puede liquidar los saldos finales tras muchas operaciones off-chain.

Los canales de contratos inteligentes son potentes porque pueden admitir estados complejos más allá de los pagos simples.

También son arriesgados porque los errores de contrato pueden bloquear fondos, permitir salidas incorrectas o hacer que las disputas fracasen.

Los desarrolladores deben diseñar cuidadosamente los contratos de canal y probar todos los casos límite.

El contrato on-chain es el árbitro que aplica el acuerdo off-chain cuando falla la cooperación.

Canales de estado y comisiones de gas

Los canales de estado pueden reducir los costes de gas trasladando las actualizaciones repetidas off-chain.

Abrir un canal cuesta gas.

Cerrar un canal cuesta gas.

Disputar un canal cuesta gas.

Sin embargo, entre la apertura y el cierre pueden producirse miles de actualizaciones off-chain sin pagar gas por cada actualización.

Esto hace que los canales de estado sean más eficientes cuando los usuarios interactúan repetidamente.

Un pago único puede no justificar el coste de apertura del canal.

Un flujo de pagos de larga duración puede beneficiarse considerablemente de la economía de los canales.

El ahorro de gas depende de la frecuencia de uso del canal, del coste de las transacciones on-chain y del coste de las disputas.

Los usuarios deben comparar los costes de configuración del canal con la actividad prevista antes de elegir un canal de estado.

Canales de estado y latencia

La latencia es el tiempo que los usuarios esperan antes de que una acción parezca completada.

Los canales de estado pueden reducir la latencia porque las actualizaciones off-chain pueden intercambiarse casi instantáneamente.

Los participantes no necesitan esperar la inclusión en un bloque tras cada actualización.

Esto puede mejorar los juegos, los micropagos, los servicios en tiempo real y las interacciones de alta frecuencia.

Sin embargo, la liquidación final sigue dependiendo de la cadena base.

Si un canal debe cerrarse on-chain, los usuarios pueden tener que esperar la confirmación de la transacción y posiblemente un periodo de disputa.

Esto significa que los canales de estado ofrecen una respuesta off-chain rápida, pero no siempre una retirada final instantánea.

La experiencia de usuario depende de si los participantes cooperan.

Los canales cooperativos pueden parecer muy rápidos.

Los canales disputados pueden parecer más lentos porque recurren al proceso de liquidación de la blockchain.

Canales de estado y privacidad

Los canales de estado pueden mejorar la privacidad porque las actualizaciones off-chain no se publican en la blockchain.

Los observadores pueden ver las transacciones de apertura y cierre del canal, pero quizá no vean cada actualización intermedia.

Esto es útil para pagos, juegos, estrategias de trading e interacciones empresariales que los usuarios no quieren hacer plenamente públicas.

Sin embargo, los canales de estado no garantizan una privacidad completa.

La transacción de apertura puede revelar a los participantes y los importes bloqueados.

La transacción de cierre puede revelar el estado final.

El enrutamiento en redes de canales puede revelar información a intermediarios.

Las watchtowers o proveedores de servicios pueden conocer metadatos según la implementación.

La privacidad también depende del comportamiento de la cartera, el enrutamiento de red, la reutilización de direcciones y los patrones temporales.

Los canales de estado pueden reducir la exposición de datos on-chain, pero no son por defecto un sistema completo de anonimato.

Canales de estado y eficiencia de capital

La eficiencia de capital es uno de los mayores retos de los canales de estado.

Los participantes suelen necesitar bloquear fondos en un canal antes de utilizarlo.

Los fondos bloqueados no pueden utilizarse en otro lugar hasta que el canal se cierre o reequilibre.

Un canal de pago con liquidez en el lado incorrecto puede no enviar pagos aunque el canal tenga capacidad total.

Por ello, la gestión de liquidez del canal es importante.

Los usuarios pueden necesitar reequilibrar canales, abrir canales nuevos o depender de la liquidez de enrutamiento.

Las aplicaciones que requieren grandes depósitos de garantía pueden ser menos atractivas si los usuarios no interactúan con frecuencia.

Los canales de estado pueden ser extremadamente eficientes para actividad repetida, pero ineficientes para interacciones poco frecuentes.

El valor económico de un canal depende de cuánta actividad admite en relación con el capital bloqueado.

El bloqueo de capital es una razón por la que los rollups se hicieron más populares para muchas aplicaciones de contratos inteligentes de propósito general.

Canales de estado y disponibilidad de contraparte

Los canales de estado suelen requerir que los participantes estén disponibles para las actualizaciones off-chain.

Si una contraparte está desconectada, es posible que el canal no pueda progresar normalmente.

Esto es distinto de una transacción on-chain normal, en la que un remitente puede difundir una transacción a la red sin que el destinatario esté online.

Algunos diseños de canales permiten un progreso limitado o una salida unilateral cuando desaparece una contraparte.

Sin embargo, la mejor experiencia de usuario suele requerir la cooperación de ambas partes.

La disponibilidad también importa durante las disputas.

Un usuario debe poder responder dentro del periodo de disputa si alguien envía un estado antiguo.

Las watchtowers pueden ayudar con este problema, pero no eliminan todos los riesgos operativos.

Los usuarios deben comprender si su cartera gestiona la supervisión automáticamente.

Los canales de estado son rápidos porque dependen de la coordinación off-chain, y esa coordinación requiere disponibilidad de los participantes.

Canales de estado y seguridad

La seguridad de los canales de estado depende de las firmas, el seguimiento del último estado, las reglas de disputa, las reglas de tiempo de espera, la corrección del contrato y la supervisión.

Cada actualización off-chain debe estar firmada por los participantes necesarios.

Los participantes deben rechazar actualizaciones no válidas antes de firmarlas.

Deben conservar una copia del último estado válido.

Deben poder enviar ese estado si surge una disputa.

El contrato on-chain debe identificar correctamente qué estado es el más reciente y válido.

Los tiempos de espera deben dar a los usuarios honestos suficiente tiempo para reaccionar.

Las claves privadas deben estar protegidas porque una clave robada puede firmar actualizaciones perjudiciales.

El software debe ser fiable porque la pérdida de datos de estado puede debilitar la posición de un usuario en una disputa.

Un canal de estado solo es seguro cuando la criptografía, la lógica del contrato, el almacenamiento de la cartera y la supervisión funcionan conjuntamente.

Canales de estado y pérdida de datos

La pérdida de datos es un riesgo grave en los canales de estado.

Si un usuario pierde el último estado firmado, podría no poder demostrar el saldo final correcto durante una disputa.

Esto es diferente de muchos sistemas on-chain, donde el último estado es visible en la blockchain.

En un canal de estado, las actualizaciones intermedias suelen almacenarse por los participantes, no por la cadena pública.

Los usuarios necesitan copias de seguridad, almacenamiento de cartera y procedimientos de recuperación fiables.

Una cartera de canal debe proteger los estados firmados con el mismo cuidado que las claves privadas.

Algunos sistemas pueden utilizar watchtowers, copias de seguridad en la nube, almacenamiento cifrado o dispositivos redundantes para reducir el riesgo de pérdida de datos.

Sin embargo, cada método de copia de seguridad puede introducir compensaciones de privacidad o seguridad.

Los desarrolladores deben diseñar clientes de canales que automaticen las copias de seguridad seguras del estado.

Los usuarios no deben asumir que el estado off-chain puede recuperarse de la blockchain hasta que se liquide.

Canales de estado y juegos

Los canales de estado son adecuados para algunos juegos de blockchain.

Un juego puede requerir muchos movimientos rápidos entre un pequeño número de jugadores.

Enviar cada movimiento on-chain sería lento y caro.

Un canal de estado puede permitir que los jugadores firmen movimientos off-chain y liquiden solo el resultado final o el resultado disputado on-chain.

Esto puede admitir juegos por turnos, apuestas, juegos de estrategia e interacciones repetidas de partidas.

El contrato puede actuar como árbitro si los jugadores no están de acuerdo.

Sin embargo, los canales de juego requieren un diseño cuidadoso.

El contrato debe verificar los movimientos legales o disponer de un proceso de disputa que pueda determinar el resultado correcto.

La aleatoriedad, la información oculta, los tiempos de espera y la inactividad de los jugadores pueden complicar el diseño.

Los canales de estado funcionan mejor para juegos en los que las reglas de transición de estado son claras y la resolución de disputas es eficiente.

Canales de estado y micropagos

Los micropagos son uno de los casos de uso más sólidos de los canales de estado.

Los pagos pequeños pueden no ser económicos on-chain si la comisión de transacción es elevada en comparación con el importe del pago.

Un canal de pago permite a los usuarios enviar muchos pagos pequeños off-chain y liquidar posteriormente el resultado neto.

Esto puede respaldar pagos en streaming, API de pago por uso, pagos de contenido, mercados de ancho de banda, recompensas de juegos y pagos de máquina a máquina.

Lightning Network es un ejemplo destacado de canales de pago utilizados para admitir pagos de bitcoin pequeños y rápidos.

Los canales de estado pueden ampliar la misma idea a estados de aplicación más generales.

Los canales de micropagos son más útiles cuando los pagos son frecuentes y las contrapartes mantienen una relación continuada.

Son menos útiles cuando cada pago es una interacción única con un destinatario nuevo.

Las redes de enrutamiento y los canales virtuales pueden ayudar a reducir esta limitación.

La idea básica es hacer prácticos los pagos diminutos evitando una transacción on-chain por cada pago.

Canales de estado y DeFi

Los canales de estado pueden admitir algunas interacciones de finanzas descentralizadas (DeFi), pero no son ideales para todos los casos de uso de DeFi.

Pueden ser útiles para trading repetido entre partes conocidas, negociación de órdenes off-chain o acuerdos bilaterales privados.

También pueden admitir actualizaciones rápidas en aplicaciones donde los participantes son conocidos y los cambios de estado son limitados.

Sin embargo, muchos protocolos DeFi dependen de la participación abierta y la liquidez compartida.

Un mercado de préstamos, un creador de mercado automatizado o un sistema de liquidación puede necesitar que muchos usuarios interactúen con un estado público.

Este tipo de componibilidad suele ser más sencilla on-chain o dentro de rollups que dentro de canales aislados.

Los canales de estado pueden fragmentar la liquidez si cada canal bloquea fondos por separado.

También pueden dificultar que terceros observen y actúen sobre el estado público.

Para DeFi, los canales de estado son más útiles en diseños limitados de interacción repetida que en sistemas amplios de liquidez pública.

Los desarrolladores deben elegir canales solo cuando la aplicación se adapte al modelo de canal.

Canales de estado y NFT

Los canales de estado pueden admitir casos de uso de NFT cuando la titularidad o el estado de juego cambia con frecuencia entre participantes.

Por ejemplo, un juego podría mantener las transferencias de objetos o las acciones de una partida off-chain y liquidar el resultado final posteriormente.

Un acuerdo de alquiler o acceso a NFT podría utilizar una estructura similar a un canal para actualizaciones repetidas.

Sin embargo, los canales de estado de NFT son más complejos que los canales de pago simples.

Los NFT son únicos, por lo que las disputas deben identificar exactamente qué token o derecho se transfiere.

Los metadatos, las aprobaciones, los royalties y las interacciones de marketplace pueden no encajar fácilmente en un canal bilateral.

Si un NFT necesita interactuar con un mercado público amplio, mantenerlo bloqueado en un canal puede reducir la liquidez.

Por tanto, los canales de estado son útiles para flujos de trabajo de NFT específicos, pero no constituyen una solución universal de escalabilidad para NFT.

Los mejores casos de uso de canales de NFT suelen implicar interacciones repetidas entre partes conocidas o lógica específica de juegos.

Para la actividad de marketplaces abiertos, otros métodos de escalabilidad pueden ser más prácticos.

Canales de estado y diseño de aplicaciones

El diseño de aplicaciones es crucial para los canales de estado.

Una buena aplicación de canal debe tener participantes claros, interacciones frecuentes, lógica de disputa sencilla y reglas de liquidación predecibles.

Debe minimizar la cantidad de lógica que debe resolverse on-chain durante una disputa.

Debe facilitar a los usuarios hacer una copia de seguridad del último estado.

Debe explicar claramente los fondos bloqueados, los tiempos de espera y los procedimientos de cierre.

Debe gestionar de forma segura a los participantes desconectados.

Debe reducir las oportunidades de griefing, en las que un participante hace perder tiempo a otro o bloquea fondos innecesariamente.

Los canales de estado no son solo un recurso de escalabilidad de backend.

Afectan a todo el flujo del producto porque los usuarios deben comprender la apertura, actualización, supervisión y cierre.

Las mejores aplicaciones de canales de estado ocultan la complejidad técnica y preservan el control del usuario.

Ventajas de los canales de estado

La primera ventaja de los canales de estado es la interacción off-chain rápida.

Los participantes pueden actualizar el estado sin esperar un bloque nuevo tras cada acción.

La segunda ventaja es un menor uso de comisiones on-chain.

Muchas actualizaciones pueden comprimirse en una liquidación final.

La tercera ventaja es una menor congestión de la blockchain.

Normalmente, solo las transacciones de apertura, cierre y disputa del canal necesitan espacio on-chain.

La cuarta ventaja es una mayor privacidad para las actualizaciones intermedias.

La mayoría de los mensajes off-chain no se convierten en datos públicos de blockchain.

La quinta ventaja es una sólida seguridad de liquidación cuando la lógica de disputas es correcta.

Los participantes pueden utilizar la cadena base para aplicar el último estado válido.

La sexta ventaja es la idoneidad para aplicaciones en tiempo real.

Los juegos, los pagos en streaming y los servicios repetidos pueden beneficiarse de actualizaciones instantáneas.

Riesgos y limitaciones de los canales de estado

La primera limitación es el bloqueo de capital.

Los fondos o el estado suelen tener que bloquearse antes de que pueda utilizarse el canal.

La segunda limitación es la disponibilidad de los participantes.

Los canales suelen funcionar mejor cuando los participantes están online y responden.

La tercera limitación es la supervisión de disputas.

Los usuarios deben responder si una contraparte envía un estado antiguo.

La cuarta limitación es el riesgo de copias de seguridad de datos.

Perder el último estado firmado puede debilitar la capacidad de un usuario para disputar.

La quinta limitación es un ajuste deficiente para aplicaciones abiertas con muchos usuarios.

Los canales son más sólidos cuando los participantes son conocidos e interactúan repetidamente.

La sexta limitación es la fragmentación de liquidez.

Los fondos bloqueados en un canal pueden no ser fáciles de utilizar en otro lugar.

La séptima limitación es la complejidad del contrato.

Los errores en contratos de canal o software de cartera pueden provocar pérdidas graves.

Malentendidos habituales sobre los canales de estado

Un malentendido habitual es que los canales de estado son lo mismo que los rollups.

Los canales de estado son acuerdos off-chain específicos para participantes, mientras que los rollups son sistemas de ejecución más amplios que agrupan a muchos usuarios.

Otro malentendido es que los canales de estado solo sirven para pagos.

Los canales de pago son un tipo de canal de estado, pero los canales de estado también pueden admitir juegos y otros estados de aplicación.

Un tercer malentendido es que los canales de estado son totalmente trustless sin acción del usuario.

Los usuarios siguen necesitando firmas seguras, copias de seguridad, supervisión y respuesta ante disputas.

Un cuarto malentendido es que todas las aplicaciones se benefician de los canales de estado.

Las aplicaciones con muchos usuarios desconocidos y liquidez compartida pueden encajar mejor con rollups o ejecución on-chain.

Un quinto malentendido es que off-chain significa inseguro.

Las actualizaciones off-chain pueden ser seguras cuando están respaldadas por firmas y reglas de disputa aplicables on-chain.

Cómo evaluar un sistema de canales de estado

Empieza comprobando qué activos o estado de aplicación se bloquean en el canal.

A continuación, comprueba quiénes son los participantes y cómo firman las actualizaciones.

Revisa cómo decide el sistema cuál es el último estado válido.

Revisa el periodo de disputa y si los usuarios pueden responder de forma realista a tiempo.

Comprueba si hay soporte de watchtower o supervisión.

Revisa cómo la cartera almacena y hace copias de seguridad de los estados firmados.

Comprueba si la aplicación exige que los participantes permanezcan online.

Revisa si la liquidez del canal puede reequilibrarse o enrutarse.

Comprueba si el contrato on-chain ha sido auditado o revisado formalmente.

Pregunta si el caso de uso realmente implica interacciones repetidas que justifiquen abrir un canal.

Buenas prácticas para usuarios

Utiliza canales de estado principalmente cuando esperes interactuar repetidamente con la misma contraparte o red.

Mantén actualizado el software de tu cartera de canal.

No elimines datos de la cartera salvo que comprendas si contienen estados de canal.

Utiliza servicios de supervisión o watchtower cuando estén disponibles y sean adecuados.

Comprende el periodo de disputa antes de bloquear fondos significativos.

Empieza con importes pequeños al probar una nueva aplicación de canal.

Cierra los canales sin usar si ya no necesitas los fondos bloqueados.

Vigila la dirección de la liquidez, porque un canal con capacidad podría no enviar en la dirección que necesitas.

No firmes actualizaciones de canal que no entiendas.

Recuerda que las actualizaciones off-chain rápidas siguen dependiendo de reglas correctas de liquidación on-chain.

Buenas prácticas para desarrolladores

Diseña protocolos de canal en los que cada actualización de estado sea explícita, esté firmada y ordenada.

Utiliza números de secuencia u otros mecanismos para identificar el último estado válido.

Haz que la lógica de disputa sea lo bastante sencilla para verificarla on-chain.

Da a los usuarios tiempo suficiente para impugnar estados antiguos.

Admite una supervisión compatible con watchtowers cuando los usuarios puedan desconectarse.

Almacena los estados de canal de forma segura y proporciona herramientas de copia de seguridad seguras.

Minimiza la cantidad de capital que los usuarios deben bloquear antes de recibir valor.

Prueba cierres cooperativos, cierres unilaterales, rutas de tiempo de espera, ataques de estados desactualizados y escenarios de pérdida de datos.

Explica claramente en la interfaz de usuario los saldos bloqueados, las liquidaciones pendientes y los periodos de disputa.

Utiliza documentación oficial y frameworks de canales probados, como la documentación de Nitro State Channel Framework, al evaluar patrones de implementación.

Preguntas frecuentes

¿Qué significa canal de estado en cripto?

Un canal de estado es un acuerdo off-chain en el que los participantes actualizan un estado compartido mediante mensajes firmados y liquidan el resultado final on-chain.

¿Cuál es la diferencia entre un canal de estado y un canal de pago?

Un canal de pago se utiliza para pagos, mientras que un canal de estado puede admitir un estado de aplicación más amplio, como juegos, saldos, operaciones o acuerdos de servicio.

¿Los canales de estado son Layer 2?

Sí. Los canales de estado suelen considerarse un método de escalabilidad de Layer 2 porque trasladan actividad fuera de la cadena base, mientras utilizan esa cadena para liquidaciones y disputas.

¿Los canales de estado requieren confianza?

Los canales de estado reducen la confianza necesaria mediante firmas y reglas de disputa on-chain, pero los usuarios siguen teniendo que gestionar claves, copias de seguridad, supervisión y disponibilidad de contrapartes.

¿Por qué son rápidos los canales de estado?

Los canales de estado son rápidos porque la mayoría de las actualizaciones se firman e intercambian off-chain sin esperar a que cada actualización se incluya en un bloque.

¿Qué ocurre si alguien envía un estado de canal antiguo?

El participante honesto normalmente puede impugnar el estado antiguo durante el periodo de disputa enviando un estado válido más reciente.

¿Qué es una watchtower?

Una watchtower es un servicio de supervisión que vigila cierres de canal deshonestos y puede ayudar a los usuarios a responder durante un periodo de disputa.

¿Para qué son más adecuados los canales de estado?

Los canales de estado son más adecuados para interacciones repetidas entre participantes conocidos, como micropagos, juegos, pagos en streaming y flujos de trabajo de trading bilaterales.

¿En qué no son buenos los canales de estado?

Los canales de estado son menos adecuados para aplicaciones abiertas con muchos usuarios que necesitan liquidez compartida, componibilidad pública y acceso fácil para participantes que cambian constantemente.

¿Siguen siendo relevantes los canales de estado?

Sí. Los canales de estado siguen siendo relevantes para casos de uso específicos de alta frecuencia e interacción repetida, aunque los rollups se han convertido en la principal vía de escalabilidad de propósito general para muchos ecosistemas de contratos inteligentes.

Conclusión

Los canales de estado son un método de escalabilidad cripto que permite a los participantes actualizar un estado compartido off-chain y liquidar el resultado final on-chain.

Se basan en activos o estado de aplicación bloqueados, actualizaciones off-chain firmadas, seguimiento del último estado y resolución de disputas.

Los canales de pago son el tipo de canal de estado más conocido, y Lightning Network es la red de canales de pago más conocida.

Los canales de estado generales pueden admitir más que pagos, incluidos juegos, acuerdos de servicio, trading repetido y otros flujos de trabajo específicos de aplicaciones.

Las principales ventajas de los canales de estado son la velocidad, un menor uso de comisiones on-chain, menor congestión y una mayor privacidad para las actualizaciones intermedias.

Las principales limitaciones son el bloqueo de capital, la disponibilidad de contrapartes, la supervisión de disputas, el riesgo de copias de seguridad de datos y un peor ajuste para aplicaciones abiertas con muchos usuarios.

Los canales de estado se diferencian de los rollups porque suelen ser acuerdos específicos para participantes, en lugar de entornos amplios de ejecución pública.

También se diferencian de las sidechains porque no crean una blockchain independiente con su propio conjunto de validadores.

Para los usuarios, los canales de estado son más útiles cuando las interacciones repetidas justifican abrir y mantener un canal.

Para los desarrolladores, los canales de estado son potentes cuando las reglas de la aplicación son claras, la lógica de disputa es sencilla y los usuarios pueden protegerse de los riesgos de desconexión y pérdida de datos.

En el contexto del glosario cripto, State Channels significa canales off-chain en los que los participantes intercambian actualizaciones de estado firmadas y dependen de la blockchain base solo para la apertura, el cierre y la liquidación de disputas.

La idea clave es que los canales de estado pueden hacer que las interacciones cripto sean casi instantáneas y de bajo coste para los casos de uso adecuados, pero requieren un diseño cuidadoso en torno a la liquidez, la supervisión, las copias de seguridad y la seguridad en disputas.