Matt Corallo

No GitHub, Matt Corallo usa TheBlueMatt. O perfil informa que muitos repositórios foram transferidos para git.bitcoin.ninja. Um repositório guarda o código-fonte e o histórico de alterações; um endereço antigo vazio não significa necessariamente que o projeto foi abandonado. Para perceber quem contribuiu com o quê, convém consultar esse histórico, as propostas e os seus autores. No caso de Corallo, o percurso vai da transmissão mais eficiente de blocos às ferramentas para Lightning. [1]

Os computadores que verificam Bitcoin trocam continuamente transações por confirmar. Quando chega um bloco, podem já conhecer grande parte do conteúdo. O Compact Block Relay aproveita essa situação. A especificação técnica pública BIP 152 identifica Corallo como autor e agradece a Gregory Maxwell a ideia inicial, o trabalho de conceção e os testes. O objetivo principal é poupar dados transmitidos. A transmissão também pode ficar mais rápida, mas as regras de validade dos blocos não mudam. [2]

Imagine uma lista partilhada de documentos: já tem a maioria e só precisa de saber quais integram o novo conjunto. A BIP 152 usa de forma semelhante identificadores curtos de transações e o mempool, o conjunto local de transações por confirmar. O destinatário pede os dados em falta através de getblocktxn. Os identificadores podem colidir, ou seja, atribuir a mesma designação curta a transações diferentes. Poupar tráfego não dispensa obter os dados reais e verificar se o bloco foi reconstruído corretamente. [2]

Em condições definidas, a BIP 152 permite anunciar um bloco compacto antes de verificar completamente todas as suas transações. Isso não autoriza o envio de dados arbitrários: é necessário verificar o cabeçalho, a ligação à cadeia validada, a prova de trabalho e o compromisso com as transações incluídas. Depois de reconstruído, o bloco é processado normalmente. O destinatário continua a verificar se são gastos fundos existentes segundo as regras. «O bloco chegou» não equivale a «o bloco é válido». [2]

Na Internet, os dados viajam em pequenos pacotes. Quando um se perde, esperar pelo reenvio aumenta o atraso. Em 7 de julho de 2016, Corallo descreveu FIBRE: combina blocos compactos com UDP, um transporte sem reenvio automático de pacotes perdidos, e FEC, uma codificação para recuperar partes em falta. Os dados adicionais ajudam o destinatário a reconstruir o conteúdo sem outro pedido. Em contrapartida, transmite-se mais informação; não há garantia de transmissão perfeita em todas as circunstâncias. [3]

FIBRE pode reenviar pacotes antes de os verificar. Ganha tempo, mas exige forte confiança interna entre os nós. Não significa aceitar indiscriminadamente ligações não verificadas. O código público permite criar outras redes, embora o operador de uma rede concreta possa escolher os seus pares. Segundo a FAQ, w0xlt e Justin, da Localhost Research, assumiram a manutenção em 2025, com o aconselhamento de Corallo e Maxwell. O projeto prossegue, assim, através do trabalho de outras pessoas. [4]

Outra parte do trabalho de Corallo envolve Lightning, uma rede de pagamentos por canais sobre Bitcoin. O manifesto, isto é, a descrição do pacote lightning em rust-lightning, indica Matt Corallo como autor. A biblioteca, escrita em Rust, fornece funções centrais de Lightning e permite que a aplicação escolha como tratar a carteira, a interação com a cadeia, o armazenamento e a rede. A atribuição não significa que uma pessoa tenha escrito todas as alterações posteriores nem que a biblioteca seja, por si só, uma carteira acabada. [5]

LDK integra-se na aplicação como um SDK, um conjunto de ferramentas para programadores. É necessário ligar o armazenamento e os outros componentes. O resultado de um pagamento pode não chegar no momento em que é iniciado: LDK comunica depois o sucesso ou a falha através de um evento que a aplicação processa. Iniciar a operação não confirma o sucesso. Para quem utiliza a carteira, a exigência é simples: o ecrã deve distinguir um pagamento em curso de um pagamento concluído. [6]