Gossip e o Grafo de Canais

Como os nos descobrem canais publicos, politicas de roteamento e caminhos possiveis

Lightning · Técnico

No roteamento onion, a origem precisa conhecer uma rota antes de montar o pacote criptografado. Mas a Lightning nao tem um servidor central dizendo quais canais existem. Cada no aprende a rede por gossip: mensagens assinadas que anunciam canais publicos, metadados de nos e politicas de roteamento.

O resultado local desse processo e o grafo de canais. Nesse grafo, os vertices sao node ids, as arestas sao canais publicos e cada direcao da aresta tem uma politica propria: fee base, fee proporcional, CLTV delta, valor minimo, valor maximo e flag de disponibilidade. A busca de caminho usa esse grafo para escolher uma rota, mas o gossip nao garante que a rota tenha liquidez real.

A especificacao principal e a BOLT 7. Ela conecta Lightning diretamente ao Bitcoin on-chain, porque um canal publico so deve ser aceito se apontar para uma funding transaction existente.

Conteúdo

Modelo mental

Gossip nao e o pagamento. Gossip e o mapa publico aproximado que permite calcular uma rota. O pagamento real ainda usa HTLCs, commitments e onion routing.

  1. Dois peers abrem um canal on-chain com uma funding transaction.
  2. Se quiserem tornar o canal publico, eles trocam assinaturas de anuncio.
  3. Depois que a funding output tem profundidade suficiente, um channel_announcement pode ser propagado.
  4. Cada lado publica seu proprio channel_update, porque a politica de encaminhamento e direcional.
  5. Os node ids envolvidos podem publicar node_announcement com alias, cor, enderecos e features.
  6. Outros nos validam, armazenam e repassam essas mensagens para montar seu proprio grafo.
Tres mensagens de gossip: channel_announcement anuncia o canal, channel_update anuncia a politica direcional e node_announcement anuncia metadados do no.
O grafo nasce de mensagens assinadas e propagadas entre peers.
Descricao longa do diagrama

O diagrama mostra varios nos Lightning conectados. Uma mensagem channel_announcement destaca a existencia de um canal publico. Mensagens channel_update aparecem em cada direcao do canal, indicando taxas e CLTV. Uma mensagem node_announcement aparece ligada a um no, indicando alias e endereco. Setas simples mostram as mensagens sendo repassadas pela rede.

Mensagens BOLT 7

A BOLT 7 nao define apenas tres mensagens publicas. Ela tambem define mensagens de consulta e filtros para sincronizar o grafo sem depender de receber tudo por inundacao.

Mensagens relevantes de gossip e sincronizacao
Tipo Mensagem Escopo Funcao
259 announcement_signatures entre os dois peers do canal Troca assinaturas antes de publicar um canal publico.
256 channel_announcement gossip publico Prova que um canal publico existe e liga dois node ids a uma funding output on-chain.
258 channel_update gossip publico Anuncia a politica de roteamento de uma direcao do canal.
257 node_announcement gossip publico Anuncia metadados do no: alias, cor, enderecos e features.
261 query_short_channel_ids sincronizacao Pede anuncios e updates para uma lista de SCIDs.
263 query_channel_range sincronizacao Pede os SCIDs conhecidos em uma faixa de blocos.
265 gossip_timestamp_filter sincronizacao Filtra updates por timestamp para receber apenas informacao recente.

Essas mensagens viajam dentro do protocolo wire. Portanto, elas seguem a moldura geral da BOLT 1: type de 2 bytes e payload especifico da mensagem.

Antes do anuncio publico

O canal publico nao aparece magicamente no gossip. Primeiro, os dois peers precisam trocar announcement_signatures. Essa mensagem e enviada entre os participantes do canal, nao como gossip global. Ela permite que cada lado obtenha as assinaturas necessarias para construir um channel_announcement completo.

Essa etapa importa porque um anuncio publico precisa provar duas coisas ao mesmo tempo:

Sem essa dupla prova, qualquer pessoa poderia inventar canais falsos entre node ids conhecidos ou apontar para saidas Bitcoin que nao controla.

channel_announcement

O channel_announcement e o certificado publico de existencia do canal. Ele diz: "existe um canal publico nesta blockchain, localizado por este short channel id, entre estes dois node ids, com estas chaves Bitcoin na funding output".

Campos principais de channel_announcement
Campo Tamanho Funcao
node_signature_1/2 64 bytes cada Assinaturas dos dois node ids sobre o anuncio.
bitcoin_signature_1/2 64 bytes cada Assinaturas das duas chaves Bitcoin que controlam a funding output.
features variavel Feature bits do canal, codificados como vetor de features.
chain_hash 32 bytes Identifica a blockchain onde a funding transaction existe, como Bitcoin mainnet ou testnet.
short_channel_id 8 bytes Localizacao compacta da funding output: bloco, indice da transacao e indice da saida.
node_id_1/2 33 bytes cada Chaves publicas comprimidas dos dois nos Lightning.
bitcoin_key_1/2 33 bytes cada Chaves publicas Bitcoin usadas na saida de financiamento 2-de-2.

O ponto anti-spam esta aqui: para anunciar um canal publico, o anunciante precisa apontar para bitcoin realmente travado em uma saida de transacao. Verificar essa saida exige conceitos de altura de bloco, txid, vout, UTXO e P2WSH ou outro formato de script usado pela funding output.

ao receber channel_announcement:

1. conferir se chain_hash e da rede esperada
2. decodificar short_channel_id em bloco, txindex e outputindex
3. localizar a transacao no bloco indicado
4. conferir se a saida indicada existe e ainda corresponde a funding output valida
5. verificar as bitcoin_signature_1/2 contra as bitcoin_key_1/2
6. verificar as node_signature_1/2 contra os node_id_1/2
7. aceitar o canal no grafo somente se as provas baterem

A validacao exata depende do estado da cadeia visto pelo no. Uma reorganizacao, uma funding transaction ainda rasa ou um fechamento de canal podem mudar se aquele canal deve permanecer no grafo local.

Short Channel ID (SCID)

O Short Channel ID e um identificador compacto de 8 bytes. Ele nao e um hash aleatorio. Ele codifica a localizacao da funding output dentro da blockchain:

SCID = blockheight x txindex x outputindex
SCID numerico = (blockheight << 40) | (txindex << 16) | outputindex
Partes do short channel id
Parte Tamanho Exemplo Significado
blockheight 24 bits 700000 Altura do bloco que confirmou a funding transaction.
txindex 24 bits 1337 Posicao da funding transaction dentro daquele bloco.
outputindex 16 bits 0 Indice da funding output dentro da transacao.

Na forma humana, o mesmo valor costuma aparecer como 700000x1337x0. O x e apenas separador. Por baixo, os tres campos sao empacotados em um inteiro de 64 bits.

Short Channel ID dividido em altura do bloco, indice da transacao e indice da saida, apontando para uma funding output na blockchain.
O SCID aponta para a saida de financiamento, nao para o saldo atual do canal.
Descricao longa do diagrama

O diagrama mostra uma pilha simples de blocos. Um bloco especifico esta marcado pela altura. Dentro dele ha uma lista de transacoes, com uma transacao marcada pelo indice. Dentro dessa transacao ha saidas numeradas, e a saida zero esta destacada como funding output. Ao lado, o valor 700000x1337x0 e decomposto em bloco, transacao e saida.

channel_update

O channel_announcement diz que o canal existe. O channel_update diz se uma direcao daquele canal pode ser usada para roteamento e quanto custa usar essa direcao.

Isso e direcional. Um canal entre Alice e Bob pode ter uma politica para Alice -> Bob e outra para Bob -> Alice. Por isso, um canal publico normalmente tem dois updates ativos, um por sentido.

Campos principais de channel_update
Campo Tamanho Funcao
signature 64 bytes Assinatura do node id responsavel por esta direcao.
chain_hash 32 bytes Blockchain da funding output.
short_channel_id 8 bytes Canal ao qual esta politica pertence.
timestamp 4 bytes Versao temporal do update; updates antigos sao ignorados.
message_flags 1 byte Indica se campos opcionais, como htlc_maximum_msat, aparecem.
channel_flags 1 byte Indica a direcao e se aquela direcao esta desabilitada.
cltv_expiry_delta 2 bytes Diferenca minima de CLTV exigida entre HTLC de entrada e de saida.
htlc_minimum_msat 8 bytes Menor HTLC que o no aceita encaminhar por essa direcao.
fee_base_msat 4 bytes Taxa fixa cobrada por encaminhamento nessa direcao.
fee_proportional_millionths 4 bytes Taxa proporcional em partes por milhao do valor encaminhado.
htlc_maximum_msat 8 bytes opcional Maior HTLC aceito nessa direcao, se anunciado.

A formula de fee anunciada para um hop e:

fee_msat = fee_base_msat + floor(amount_to_forward_msat * fee_proportional_millionths / 1_000_000)

O cltv_expiry_delta entra no calculo de timeout da rota. Cada hop exige que o HTLC de entrada tenha mais blocos de folga que o HTLC de saida. Isso da tempo para reagir a falhas e fechamentos unilaterais. Veja a relacao com locktime e com a operacao de HTLCs em canais.

canal: 700000x1337x0
direcao: node_id_1 -> node_id_2

fee_base_msat = 1000
fee_proportional_millionths = 250
cltv_expiry_delta = 40
htlc_minimum_msat = 1000
htlc_maximum_msat = 500000000

valor a encaminhar = 200000 msat
fee = 1000 + floor(200000 * 250 / 1000000)
fee = 1050 msat

Nao confunda politica de roteamento com liquidez. O gossip pode dizer que uma direcao cobra 1050 msat para encaminhar, mas nao revela se ha saldo remoto suficiente para encaminhar aquele pagamento agora.

node_announcement

O node_announcement descreve um no publico. Ele ajuda carteiras, exploradores e peers a exibirem e encontrarem aquele no, mas nao cria canal sozinho. Um no sem canal publico relevante nao e util para o grafo de roteamento publico.

Campos principais de node_announcement
Campo Funcao
signature Assinatura do node id sobre o anuncio.
features Features do no, como suporte a campos opcionais e extensoes.
timestamp Versao temporal do anuncio.
node_id Chave publica comprimida que identifica o no Lightning.
rgb_color Cor publica exibida por exploradores e UIs.
alias Nome curto publico, nao confiavel e nao unico.
addresses Enderecos de rede onde outros peers podem tentar conexao.

Alias e cor nao sao identidade forte. A identidade forte e o node id, uma chave publica comprimida. Dois nos podem escolher aliases parecidos, e um alias pode mudar ao longo do tempo.

Sincronizacao de gossip

Um no recem-conectado nao precisa esperar passivamente o mundo inteiro reenviar todos os anuncios. A BOLT 7 define mensagens de consulta para sincronizar o grafo por faixas de blocos, listas de SCIDs e janelas de timestamp.

Mensagens de consulta e filtro
Mensagem Uso
query_channel_range Pergunta quais SCIDs existem em uma faixa de alturas de bloco.
reply_channel_range Responde com uma lista compacta de SCIDs e pode indicar se a resposta esta completa.
query_short_channel_ids Pede os anuncios e updates correspondentes a SCIDs especificos.
reply_short_channel_ids_end Marca o fim da resposta para uma consulta por SCID.
gossip_timestamp_filter Pede apenas mensagens com timestamp dentro de uma janela.

Na pratica, a rede precisa equilibrar atualidade e custo. Flooding agressivo demais desperdicaria banda. Flooding lento demais deixaria carteiras calculando rotas com politicas antigas. Por isso, implementacoes fazem deduplicacao, ignoram updates antigos, aplicam limites de frequencia e podam canais fechados ou obsoletos.

Montando o grafo de canais

Cada no constroi seu proprio grafo local. Nao existe "o grafo oficial" da Lightning. Existem visoes locais que convergem razoavelmente, mas podem divergir por latencia, filtros, conexoes, canais privados, politicas recentes e informacoes que ainda nao chegaram.

Como mensagens viram grafo
Mensagem Elemento no grafo Dados usados
channel_announcement aresta SCID, dois node ids, chaves Bitcoin e prova on-chain do canal.
channel_update aresta direcional fees, CLTV delta, limites de HTLC, flag disabled e timestamp.
node_announcement vertice alias, cor, enderecos e features do no. 
para montar o grafo:

1. guardar channel_announcement valido como canal publico
2. anexar channel_update de cada direcao ao canal
3. ignorar update com timestamp mais antigo que o conhecido
4. marcar direcao como indisponivel quando o bit disabled estiver ativo
5. guardar node_announcement somente para node id ligado a canal conhecido
6. podar canais fechados ou inconsistentes com a cadeia
7. entregar o grafo resultante para a busca de caminho
Grafo de canais montado a partir de anuncios de canais, updates direcionais e anuncios de nos.
A busca de caminho trabalha sobre uma visao local do grafo publico.
Descricao longa do diagrama

O diagrama mostra um grafo com varios nos conectados por canais. Os nos aparecem como circulos e os canais como linhas. Algumas linhas possuem setas em sentidos diferentes, indicando que cada direcao pode ter politica propria. Uma caixa lateral lista dados vindos de channel_announcement, channel_update e node_announcement.

Canais publicos vs. privados

Nem todo canal entra no gossip. Um canal privado, ou nao anunciado, existe entre dois peers, mas nao aparece no grafo publico. Ele ainda pode receber ou enviar pagamentos, desde que o pagador receba informacao suficiente por outro caminho.

Em invoices BOLT 11, isso aparece como routing hints no campo r. O recebedor inclui uma pequena rota final com node id, SCID, fee base, fee proporcional e CLTV delta para que o pagador consiga chegar ate um canal que nao descobriria pelo gossip publico.

Essa diferenca e importante para privacidade: canal privado reduz exposicao no grafo publico, mas nao torna o pagamento invisivel para os peers envolvidos. Tambem aumenta a dependencia de hints corretos e atualizados na invoice.

Ferramenta: Short Channel ID

A ferramenta abaixo converte entre a forma humana blocoxtxxsaida, decimal e hexadecimal do SCID. Ela e didatica e roda somente no navegador. Nao cole dados sensiveis de carteira; SCID de canal publico pode ser publico, mas exemplos educativos devem usar valores ficticios.

Short Channel ID

Short Channel ID

O SCID identifica um canal pela localização da sua saída de financiamento na blockchain: bloco, índice da transação e índice da saída, empacotados em 64 bits (escritos como blocoxtxxsaída).

Compor

Limites: bloco e transação usam 24 bits; saída usa 16 bits.

SCID (string):
SCID (decimal):
SCID (hex):
Bytes (bloco | tx | saída):

Decompor

O valor deve caber em 64 bits. Um alias pode não representar uma localização on-chain.

Bloco: · Tx: · Saída:
SCID (string):
SCID (decimal):
SCID (hex):

Privacidade, seguranca e limites

Gossip e publico por design. Isso ajuda roteamento e auditoria, mas expõe metadados:

Do ponto de vista de seguranca, a regra mais importante e nao aceitar gossip sem validacao. Assinaturas, chain hash, SCID, funding output e timestamps existem para impedir spam barato, impersonacao e atualizacoes antigas sobrescrevendo informacao mais nova.

Armadilhas comuns

Mapa de dependências conceituais

Antes de ler esta página

Depois desta página

Referências técnicas usadas

Com o grafo em maos, o proximo problema e escolher uma rota que provavelmente funcione, pese fees, respeite CLTV e lide com falhas. Esse e o assunto da busca de caminho.