---
title: "Canais de estado"
description: "Canais de estado permitem que participantes fixos troquem estados assinados fora da cadeia e mantenham um caminho para impor na cadeia o resultado válido mais recente."
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.
# Canais de estado
> Somente para fins educacionais; não é orientação de investimento nem de segurança. Os fundos do canal podem ser perdidos se chaves, estado atual, monitoramento ou capacidade de responder on-chain estiverem indisponíveis.
## Resposta direta
Um canal de estado é um protocolo em que participantes fixos bloqueiam ativos ou estabelecem regras executáveis numa blockchain e depois trocam atualizações autenticadas fora dela. A blockchain não processa cada atualização; funciona como árbitro final no fechamento ou numa divergência.
Cada atualização aceita vincula o canal, o estado ou alocação do aplicativo e um valor de ordem crescente, como turno ou nonce. O estado válido mais novo substitui o anterior conforme as regras. Um canal de pagamento é o caso restrito a saldos; um canal geral também representa jogadas, negociações ou outros dados determinísticos.
Há baixa latência, alguma privacidade frente ao histórico público e nenhuma taxa da camada base por atualização comum. Em contrapartida, participantes e capital costumam ficar fixos na sessão, todos precisam guardar a prova para impor o último estado e a cadeia base deve estar disponível e ter custo suportável numa disputa.
## Como funciona
1. **Abrir e financiar.** As partes acertam identidades, regras, duração da contestação e alocação inicial. Bloqueiam fundos num árbitro on-chain ou derivam o canal de outro já financiado; esse valor não é saldo comum enquanto garante o canal.
2. **Trocar estados assinados.** Calculam o próximo estado válido e trocam assinaturas ou mensagens que o sustentam. Identificador único e ordem crescente impedem substituir uma assinatura de outro canal ou rodada antiga.
3. **Guardar o pacote de execução.** Carteira ou nó conserva estado recente, assinaturas, transferências condicionais e dados de revogação ou segredos exigidos. A frase-semente pode recuperar chaves, mas não necessariamente esses dados mutáveis.
4. **Continuar fora da cadeia.** Muitas atualizações dispensam transação base. A capacidade limita envios à alocação e reservas naquela direção; rotas por vários canais acrescentam dependências de liquidez e atividade em cada salto.
5. **Fechar em cooperação.** As partes assinam o resultado final e enviam a transação mínima exigida. Em geral isso evita a corrida de contestação e liquida mais rápido ou barato que o fechamento unilateral.
6. **Levar a disputa à cadeia.** Se alguém some ou propõe estado obsoleto, outra parte apresenta prova executável. O árbitro aplica ordem, prazos e transições. Alguns desenhos desafiam estado velho com novo; canais estilo Lightning usam compromissos e revogações, não uma disputa genérica pelo maior nonce.
7. **Finalizar após os prazos.** Terminado o desafio ou timelock, reclama-se o resultado. Até resolver todas as saídas, pode ser preciso monitorar reorganizações e aumentar a taxa de transações urgentes.
## Exemplo
Alice e Bob abrem um canal bilateral com `5 ETH` cada, controlando `10 ETH`. O estado inicial assinado é o turno `0`: Alice recebe `5 ETH` e Bob recebe `5 ETH` na liquidação.
Alice paga `1 ETH` a Bob. Eles validam e assinam o turno `1`, com `4 ETH` para Alice e `6 ETH` para Bob. Depois Bob paga `2 ETH` a Alice; o turno `2` atribui `6 ETH` a Alice e `4 ETH` a Bob. Com cooperação, só financiamento e liquidação final chegam à cadeia base.
Se Bob apresentar depois o turno `1`, num desenho de maior turno Alice deve entregar o turno `2` plenamente sustentado antes do prazo. O contrato rejeita o antigo e liquida o turno `2`. Se ela perdeu o turno `2`, não acessa a chave, não tem ativo base para taxas ou fica offline além do prazo, o protocolo não adivinha o histórico privado. O resultado executável pode diferir do último acordo.
É um exemplo conceitual. Protocolos reais definem assinaturas, transições, pagamentos condicionais, chamadas e prazos exatos. Não transfira fundos apenas com base nessa aritmética simplificada.
## Riscos e controles
- **Liquidação obsoleta.** Guarde o pacote completo recente e teste a restauração. Entenda dados e poderes antes de usar uma torre de vigilância.
- **Prazo perdido.** Monitore a cadeia certa até tudo finalizar, com margem realista para falhas, reorganizações, congestionamento e resposta humana.
- **Taxas e congestionamento.** Reserve ativo base livre e forma de elevar taxas. Disputas simultâneas podem encarecer justamente a saída urgente.
- **Perda de chave ou estado.** Use o backup documentado. Não restaure canal ativo de snapshot antigo sem garantia explícita do protocolo.
- **Falha de capacidade ou rota.** Confira liquidez de entrada e saída, reservas, máximos condicionais, vencimentos e intermediários. Saldo total não é capacidade utilizável.
- **Contraparte e disponibilidade.** A contraparte normalmente não altera resultado protegido, mas pode negar atualização ou fechamento conjunto e forçar disputa lenta.
- **Implementação.** Falhas em cliente, árbitro, domínio de assinatura, transições ou upgrades podem anular garantias. Verifique implantação e auditorias.
- **Vazamento de privacidade.** Fora da cadeia não é sinônimo de anonimato: pares, roteadores, observadores, backups e disputa final podem revelar relações ou dados.
## Equívocos comuns
- **“Fora da cadeia significa sem confiança e sem blockchain.”** O caminho confiável on-chain limita a confiança na contraparte; segurança, disponibilidade e custo continuam importantes.
- **“Qualquer estado assinado por ambos liquida.”** Ordem, validade, finalidade, revogação e prazo específicos decidem qual prova é executável.
- **“A frase-semente restaura todo o canal.”** Em geral restaura chaves, não necessariamente estado recente, segredos, pagamentos pendentes ou base de pares.
- **“O usuário pode ficar offline para sempre.”** Muitos desenhos exigem observação e resposta num prazo, diretamente ou por serviço delegado.
- **“A capacidade é igual ao saldo da carteira.”** Fundos precisam ser comprometidos, e a capacidade depende de direção, reservas, pendências e liquidez da rota.
- **“Canais substituem rollups em tudo.”** Funcionam melhor em interações repetidas entre partes conhecidas; adesão aberta, estado global ou ampla composição podem favorecer rollups ou execução on-chain.
## Tópicos relacionados
- [Taxa de gas](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [Camada 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [Contrato inteligente](/crypto/smart-contract/)
## Fontes
- [Redes gerais de canais de estado](https://doi.org/10.1145/3243734.3243856) - ACM (acesso: 2026-08-21)
- [Protocolo Nitro](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive (acesso: 2026-08-21)
- [Estados e canais](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels (acesso: 2026-08-21)
- [BOLT #2: protocolo entre pares para gestão de canais](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications (acesso: 2026-08-21)
- [BOLT #5: recomendações para transações on-chain](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications (acesso: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/state-channels/index.mdx