---
title: "Canales de estado"
description: "Los canales de estado permiten que un conjunto fijo de participantes intercambie estados firmados fuera de la cadena y conserve una vía para imponer en cadena el último resultado válido."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Canales de estado

> Solo con fines educativos; no es asesoramiento de inversión ni de seguridad. Los fondos del canal pueden perderse si no están disponibles las claves, el estado actual, la vigilancia o la capacidad de responder en cadena.

<a id="answer"></a>

## Respuesta directa

Un canal de estado es un protocolo en el que un conjunto fijo de participantes bloquea activos o establece reglas exigibles en una cadena de bloques y después intercambia actualizaciones autenticadas fuera de ella. La cadena no procesa cada actualización: actúa como árbitro final al cerrar el canal o surgir un desacuerdo.

Cada actualización aceptada vincula el canal, el estado o reparto de la aplicación y un valor de orden creciente, como un turno o nonce. El estado válido más reciente sustituye al anterior según las reglas. Un canal de pago es el caso limitado a saldos; uno general también puede representar jugadas, operaciones u otros datos deterministas.

Ofrece poca latencia, cierta privacidad frente al historial público y ninguna comisión de capa base por actualización ordinaria. A cambio, participantes y capital suelen quedar fijados durante la sesión, todos deben conservar la prueba necesaria y la cadena base debe estar disponible y ser asequible durante una disputa.

<a id="mechanism"></a>

## Cómo funciona

1. **Abrir y financiar.** Se acuerdan identidades, reglas, duración del desafío y reparto inicial. Los fondos se bloquean en un árbitro en cadena o el canal deriva de otro ya financiado; mientras garantizan el canal no son saldo gastable normal.
2. **Intercambiar estados firmados.** Las partes calculan el siguiente estado válido e intercambian firmas o mensajes que lo respaldan. El identificador único y el orden creciente impiden sustituir una firma de otro canal o ronda antigua.
3. **Guardar el paquete de ejecución.** La cartera conserva último estado, firmas, transferencias condicionales y datos de revocación o secretos exigidos. Una frase semilla puede recuperar claves, pero no necesariamente estos datos cambiantes.
4. **Continuar fuera de cadena.** Pueden hacerse muchas actualizaciones sin transacción base. La capacidad limita los envíos a la asignación y reservas disponibles en esa dirección; una ruta multicanal añade dependencias de liquidez y actividad en cada salto.
5. **Cerrar de común acuerdo.** Las partes firman el resultado final y envían la mínima transacción necesaria. Así suelen evitar una carrera de impugnación y liquidar antes o más barato que con un cierre unilateral.
6. **Elevar la disputa a la cadena.** Si alguien desaparece o presenta un estado obsoleto, otra parte entrega prueba exigible. El árbitro aplica orden, plazos y transiciones. Algunos diseños permiten desafiar con un estado nuevo; los canales tipo Lightning usan compromisos y revocaciones, no una competencia genérica por el nonce mayor.
7. **Finalizar tras los plazos.** Vencido el desafío o bloqueo temporal, se reclama el resultado. Hasta resolver todas las salidas puede ser preciso vigilar reorganizaciones y elevar la comisión de transacciones urgentes.

<a id="example"></a>

## Ejemplo

Alice y Bob abren un canal bilateral con `5 ETH` cada uno, que controla `10 ETH`. El estado inicial firmado es el turno `0`: al liquidar, Alice recibe `5 ETH` y Bob recibe `5 ETH`.

Alice paga `1 ETH` a Bob. Validan y firman el turno `1`, con `4 ETH` para Alice y `6 ETH` para Bob. Luego Bob paga `2 ETH` a Alice; el turno `2` asigna `6 ETH` a Alice y `4 ETH` a Bob. Con cooperación, solo la financiación y la liquidación final llegan a la cadena base.

Si Bob presenta después el turno `1`, en un diseño de turno máximo Alice debe aportar el turno `2` plenamente respaldado antes del plazo. El contrato rechazará el antiguo y liquidará el turno `2`. Si Alice perdió el turno `2`, no puede usar su clave, carece del activo base para comisiones o sigue desconectada hasta vencer el plazo, el protocolo no puede adivinar el historial privado. El resultado exigible puede diferir del último acordado.

Es un ejemplo conceptual. Los protocolos reales definen las firmas, transiciones, pagos condicionales, llamadas y plazos exactos. No transfiera fondos basándose solo en esta aritmética simplificada.

<a id="risks"></a>

## Riesgos y controles

- **Liquidación obsoleta.** Conserve el paquete completo más reciente y pruebe su restauración. Entienda datos y facultades antes de usar una torre de vigilancia.
- **Plazo perdido.** Vigile la cadena correcta hasta resolver todo y deje margen realista para fallos, reorganizaciones, congestión y respuesta humana.
- **Comisiones y congestión.** Reserve activo base libre y una vía para elevar comisiones. Muchas disputas simultáneas pueden encarecer justo la salida urgente.
- **Pérdida de clave o estado.** Use el método de copia documentado. No restaure un canal activo desde una instantánea antigua salvo garantía explícita del protocolo.
- **Fallo de capacidad o ruta.** Revise liquidez entrante y saliente, reservas, máximos condicionales, vencimientos e intermediarios. El saldo total no es capacidad utilizable.
- **Contraparte e inactividad.** La contraparte no suele poder alterar un resultado protegido, pero puede negar actualizaciones o el cierre conjunto y forzar la disputa lenta.
- **Implementación.** Fallos del cliente, árbitro, dominio de firma, transiciones o actualizaciones pueden anular garantías. Verifique el despliegue y sus auditorías.
- **Filtración de privacidad.** Fuera de cadena no significa anónimo: pares, enrutadores, observadores, copias y la disputa final pueden revelar relaciones o datos.

<a id="misconceptions"></a>

## Errores frecuentes

- **«Fuera de cadena significa sin confianza y sin cadena».** La vía creíble de ejecución en cadena limita la confianza; su seguridad, disponibilidad y coste importan.
- **«Cualquier estado firmado por ambos se liquida».** El orden, validez, finalidad, revocación y plazos específicos determinan qué prueba es exigible.
- **«La frase semilla restaura todo el canal».** Suele restaurar claves, no necesariamente estado reciente, secretos, pagos pendientes o base de pares.
- **«Se puede estar desconectado indefinidamente».** Muchos diseños exigen observar y responder dentro de un plazo, directamente o mediante un servicio delegado.
- **«La capacidad equivale al saldo de la cartera».** Los fondos deben comprometerse y la capacidad depende de dirección, reservas, pendientes y liquidez de ruta.
- **«Los canales sustituyen universalmente a los rollups».** Funcionan mejor para interacciones repetidas entre partes conocidas; membresía abierta, estado global o amplia composición pueden encajar mejor en rollups o en cadena.

<a id="related"></a>

## Temas relacionados

- [Comisión de gas](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [Capa 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [Contrato inteligente](/crypto/smart-contract/)

<a id="sources"></a>

## Fuentes

- [Redes generales de canales de estado](https://doi.org/10.1145/3243734.3243856) - ACM (consulta: 2026-08-21)
- [Protocolo Nitro](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive (consulta: 2026-08-21)
- [Estados y canales](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels (consulta: 2026-08-21)
- [BOLT #2: protocolo entre pares para gestionar canales](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications (consulta: 2026-08-21)
- [BOLT #5: recomendaciones para transacciones en cadena](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications (consulta: 2026-08-21)

Source: https://wiki.fcontext.com/es/crypto/state-channels/index.mdx