Pular para o conteúdo
buybitcoinsmart

Glossário / Lightning e camada 2

Bit de funcionalidade

O que é um bit de funcionalidade?
Um bit de funcionalidade avisa os outros nós Lightning de que o seu nó oferece suporte a uma extensão específica do protocolo, e os números ímpares marcam essa extensão como opcional, enquanto os números pares a marcam como obrigatória.

A Lightning não carrega nenhum número de versão para os pares compararem, então dois nós descobrem o que podem fazer juntos trocando um campo de bits no momento em que se conectam. O BOLT 9 atribui 25 pares nomeados, que vão do bit 0 até o bit 67, e ninguém pode definir os dois bits de um mesmo par. Se a sua carteira recusa uma fatura que outra carteira paga, um bit de funcionalidade ausente é uma coisa a verificar.

Como funciona

Os bits de funcionalidade são contados a partir do bit menos significativo de um campo de bits, começando no bit 0, que tem o valor 0x1 e conta como par.

Eles são distribuídos em pares, e o emparelhamento é todo o truque: o bit ímpar significa que o nó oferece suporte à funcionalidade, o bit par significa que o nó exige a funcionalidade. Assim, uma capacidade pode ser lançada como opcional, se espalhar sem alarde e mais tarde ser promovida a obrigatória, o que, segundo o BOLT 9, os nós desatualizados vão recusar, de modo que a incompatibilidade aparece quando dois nós se encontram, e não no meio de um pagamento. Os requisitos dizem o resto com clareza: um nó de origem não deve definir os dois bits de um par, e um nó receptor que, ainda assim, vê os dois trata a funcionalidade como obrigatória.

Algumas funcionalidades dependem de outras, e o remetente carrega a cadeia inteira. Os pagamentos multiparte básicos ocupam os bits 16 e 17 e dependem de payment_secret; os canais zeroconf ocupam 50 e 51 e dependem de option_scid_alias; o option_onion_messages_only_channels, em 66 e 67, depende das mensagens onion comuns. O nó de origem deve definir toda dependência transitiva, então o código protegido por uma única funcionalidade pode presumir que os bits de suporte estão presentes, em vez de validá-los de novo.

Cinco dos 25 pares agora dizem apenas ASSUMED: 0/1, 8/9, 12/13, 14/15 e 44/45. Cada um se tornou tão difundido que se presume que todo nó o possui, e sua semântica sobrevive apenas em revisões anteriores da especificação. A tabela também pula números, sem nada atribuído em 2/3, 20/21, 30/31, 32/33, de 52 a 59 nem em 64/65, então as lacunas são normais.

Onde você vê isso

Os bits de funcionalidade viajam em vários lugares separados, e a coluna Context da tabela do BOLT 9 indica a quais deles cada par pertence, em branco em seis das 25 linhas.

I marca a mensagem init que dois pares trocam ao se conectar, N marca um node_announcement transmitido ao grafo de gossip, C marca um channel_announcement, 9 marca uma fatura BOLT 11, B marca o campo allowed_features de um caminho cego e T marca o channel_type acordado quando um canal é aberto. Muitos bits aparecem em um único contexto: o option_payment_metadata, bits 48 e 49, aparece apenas em faturas, enquanto o option_anchors, em 22 e 23, aparece no init, no gossip e como tipo de canal, mas nunca em uma fatura.

Quando dois contextos discordam, a fatura vence: a justificativa do BOLT 9 afirma que, para os sinalizadores presentes tanto no node_announcement quanto no BOLT 11, os valores da fatura prevalecem sobre os anunciados. É por isso que uma carteira lê as capacidades na fatura que você colou, e não no que o destino anunciou à rede de gossip horas antes.

A Phoenix, criada pela ACINQ sobre a sua implementação Eclair, roda um nó real no seu celular, então se ela aceita um pagamento multiparte ou uma rota cega é decidido por um campo de bits trocado com o seu par, e não por uma página de marketing. A Muun mostra on-chain e Lightning como um único saldo, e seus pagamentos Lightning ainda dependem dos bits na fatura.

Bit de funcionalidade vs bit de versão

Um bit de funcionalidade negocia capacidade entre dois pares Lightning; um bit de versão sinaliza um soft fork em um cabeçalho de bloco de bitcoin. O BIP-9 dá aos mineradores os bits 0 a 28 do campo de versão do cabeçalho e fixa uma implantação em 1.916 de uma janela de 2.016 blocos na mainnet, após o que ela fica ativa em todos os blocos seguintes. Um bit de funcionalidade não vincula ninguém: é uma afirmação entre dois pares, verdadeira em uma conexão e falsa na seguinte, sem limiar, sem tempo limite e sem ativação em toda a rede. A Lightning negocia o que dois nós farão um pelo outro; o bitcoin decide o que todos devem aceitar.

Não confundir com

Perguntas frequentes

Por que os bits de funcionalidade da Lightning são atribuídos em pares?

Para que uma funcionalidade possa começar como opcional e mais tarde se tornar obrigatória. O bit ímpar de um par diz que o nó oferece suporte à funcionalidade e o bit par diz que ele a exige, e o BOLT 9 observa que um bit par obrigatório será recusado por nós desatualizados, então a incompatibilidade aparece quando dois nós se conectam, e não no meio de um pagamento.

O que acontece se a outra parte não oferecer suporte a um bit de funcionalidade de que o meu pagamento precisa?

O pagamento falha e o seu dinheiro fica onde está. A negociação de funcionalidades acontece antes de qualquer coisa ser comprometida, então uma capacidade sem suporte aparece como uma conexão recusada ou uma rota que a sua carteira não vai tentar, e não como um saldo travado.

Preciso definir um bit de funcionalidade marcado como ASSUMED?

Não. O BOLT 9 marca cinco pares como ASSUMED, nos bits 0/1, 8/9, 12/13, 14/15 e 44/45, porque essas funcionalidades se tornaram tão difundidas que se presume que todo nó as possui e os sinalizadores podem ser ignorados sem problema.

Leia a seguir

Termos relacionados

Mais em Lightning e camada 2

Ler esta página em inglês