O Erlay é uma proposta de melhoria do Bitcoin que torna a propagação de transações entre os nodes muito mais eficiente, reduzindo o tráfego de rede sem alterar nenhuma regra de consenso. Em vez de depender apenas dos anúncios individuais de cada nova transação, ele permite que os nodes comparem resumos matemáticos compactos de suas mempools e troquem somente aquilo que está faltando, usando uma técnica chamada Set Reconciliation apoiada na biblioteca Minisketch. O resultado é uma rede capaz de manter mais conexões com menos banda, o que fortalece a descentralização do Bitcoin.
Quando falamos em escalar o Bitcoin, a conversa quase sempre gira em torno de blocos, taxas e soluções de segunda camada como a camada 2 do protocolo Ark. Existe, porém, uma camada menos comentada e igualmente decisiva, que é a forma como os nodes conversam entre si para manter a rede sincronizada. É exatamente nesse ponto que o Erlay atua e é por isso que muitos desenvolvedores do Bitcoin Core consideram essa uma das melhorias mais promissoras já pensadas para a camada P2P.
Este conteúdo foi escrito pelo professor Rafael Penna, colaborador da Bitcoin Coders, e é voltado para programadores e desenvolvedores que querem entender o Erlay por dentro, inclusive com experimentos práticos usando o Bitcoin Core e o bitcoin-cli.
O que você vai aprender neste artigo
- Como os nodes anunciam novas transações hoje através das mensagens
inv,getdataetx, tema que se conecta com a anatomia das transações no Bitcoin Core. - Por que esse modelo gera tráfego redundante conforme o número de conexões aumenta.
- A observação central que motivou o Erlay, que é o fato de as mempools dos nodes honestos serem quase idênticas.
- Como funciona o Set Reconciliation e de que forma a biblioteca Minisketch recupera apenas as diferenças entre dois conjuntos.
- Um laboratório prático em regtest para observar a propagação atual, no mesmo espírito dos nossos tutoriais de SegWit em Signet com bitcoin-cli e de criação de transações no Bitcoin Core.
- Por que o Erlay importa para a descentralização e qual é o estágio atual da discussão entre os desenvolvedores.
Como os nodes anunciam novas transações
Quando um node recebe uma transação válida, ele não envia imediatamente a transação completa para todos os seus peers. O primeiro passo é enviar uma mensagem chamada inv (inventory). Essa mensagem contém apenas o identificador da transação (txid) e funciona como um aviso:
“Eu conheço uma nova transação.”
Se o peer ainda não possuir essa transação em sua mempool, ele responde com uma mensagem getdata. Somente então a transação completa é transmitida através de uma mensagem tx.
O fluxo simplificado é:
Node A recebe uma nova transação A → inv → B A → inv → C A → inv → D B → getdata → A C → getdata → A D → getdata → A A → tx → B A → tx → C A → tx → D
Esse mecanismo é extremamente robusto. Mesmo que alguns peers estejam lentos ou desconectados, a informação encontra diversos caminhos alternativos para percorrer a rede.
Onde está o problema?
À primeira vista, esse modelo parece perfeito. O detalhe é que a rede Bitcoin possui milhares de nodes e um fluxo constante de novas transações. Sempre que uma nova transação aparece, ela é anunciada para diversos peers. Muitos desses peers provavelmente receberão a mesma informação por outros caminhos também.
Imagine uma rede simplificada:
B
|
D --- A --- C
|
E
Uma nova transação chega ao Node A. Ele anuncia essa transação para B, C, D e E. Mas talvez B também receba a mesma transação através de outro node conectado. O mesmo vale para C, D e E.
Essa redundância é intencional e ajuda a tornar a rede resiliente. O problema é que ela gera um volume significativo de mensagens. Quanto mais conexões um node mantém, maior tende a ser o tráfego necessário para anunciar novas transações.
A observação por trás do Erlay
Os desenvolvedores perceberam algo interessante. Embora novas transações apareçam continuamente, as mempools dos nodes honestos costumam ser extremamente parecidas.
Imagine dois nodes:
Node 1
100.000 transações
Node 2
99.998 transações
Na prática, ambos já conhecem quase tudo o que existe na rede naquele momento. Talvez o Node 1 tenha recebido primeiro duas transações que ainda não chegaram ao Node 2. Ou talvez o Node 2 conheça algumas transações que ainda não foram vistas pelo Node 1. Mas, no geral, os conjuntos são quase idênticos.
Essa observação levou à seguinte pergunta:
Se as mempools já são quase iguais, precisamos continuar dependendo apenas de anúncios individuais para mantê-las sincronizadas?
É justamente essa pergunta que o Erlay tenta responder.
Como o Erlay funciona
A ideia central do Erlay não é transmitir mempools completas. Isso seria inviável. Também não significa que as novas transações deixarão de ser propagadas normalmente. O que muda é a forma como os nodes verificam se estão sincronizados.
Imagine a seguinte situação.
Node 1
tx1 tx2 tx3 tx4 tx5 tx6
Node 2
tx1 tx2 tx3 tx4 tx5 tx7
As transações tx6 e tx7 chegaram por caminhos diferentes na rede. Talvez tx6 tenha sido recebida primeiro por um peer conectado ao Node 1, enquanto tx7 chegou primeiro ao Node 2. Nesse cenário:
Node 1 não possui tx7 Node 2 não possui tx6
Todo o restante já é conhecido por ambos. Com o protocolo atual, a sincronização depende principalmente dos anúncios individuais das novas transações.
O Erlay introduz um mecanismo complementar chamado Set Reconciliation. Em vez de depender exclusivamente desses anúncios, os nodes podem comparar periodicamente resumos matemáticos compactos de suas mempools.
Ao fazer essa comparação, eles descobrem rapidamente quais transações estão faltando em cada lado. Após a reconciliação:
Node 1: tx1 tx2 tx3 tx4 tx5 tx6 tx7 Node 2: tx1 tx2 tx3 tx4 tx5 tx6 tx7
Agora ambos possuem exatamente o mesmo conjunto.
Quando esses nodes realizarem novas reconciliações com outros peers da rede, não será necessário transmitir novamente tx6 ou tx7, pois elas já estarão presentes em suas mempools.
Em outras palavras, conforme os nodes vão trocando apenas as diferenças, as mempools convergem rapidamente para o mesmo estado, reduzindo a necessidade de novos anúncios e sincronizações futuras.
Minisketch e Set Reconciliation
Para realizar essa comparação eficiente, a proposta utiliza uma técnica chamada Set Reconciliation. A implementação é baseada em uma estrutura conhecida como Minisketch.
A ideia é elegante. Em vez de enviar listas enormes de txids, cada node gera um pequeno resumo matemático de sua mempool. Vamos imaginar um exemplo simplificado.
Node 1
10 20 30 40 50 60
Node 2
10 20 30 40 50 70
A diferença entre os conjuntos é:
60 70
Uma solução simples seria transmitir toda a lista de elementos de cada lado. Porém, conforme o conjunto cresce, isso rapidamente se torna inviável.
O Minisketch utiliza uma abordagem diferente. Cada node gera um resumo matemático compacto do conjunto que possui. Esse resumo não contém a lista completa dos elementos, mas preserva informações suficientes para que as diferenças possam ser recuperadas posteriormente.
Quando os resumos são comparados, o algoritmo consegue reconstruir apenas os elementos que diferem entre os conjuntos:
60 70
sem que seja necessário transmitir todos os demais elementos.
O importante é perceber que o Minisketch não tenta reconstruir o conjunto inteiro. Ele foi projetado especificamente para recuperar apenas as diferenças. Por isso ele funciona tão bem quando os conjuntos são quase iguais, como costuma acontecer com as mempools dos nodes Bitcoin.
Tecnicamente, o Minisketch utiliza técnicas de codificação de erro semelhantes às usadas em telecomunicações para reconstruir apenas as diferenças entre conjuntos, mas os detalhes matemáticos estão além do escopo deste artigo.
Laboratório: observando a propagação atual
Vamos visualizar o modelo atual utilizando quatro nodes em regtest.
Passo 1 — Conectando os nodes
Considere quatro instâncias do Bitcoin Core rodando em regtest:
Node A (port=28441) Node B (port=28542) Node C (port=28643) Node D (port=28744)
No Node A, conecte os demais peers:
bitcoin-cli -datadir="." addnode 127.0.0.1:28542 onetry bitcoin-cli -datadir="." addnode 127.0.0.1:28643 onetry bitcoin-cli -datadir="." addnode 127.0.0.1:28744 onetry
Ainda no Node A, confirme as conexões:
bitcoin-cli -datadir="." getpeerinfo
**[
{
"id": 0,
"addr": "127.0.0.1:28542",...
},
{
"id": 1,
"addr": "127.0.0.1:28643",...
},
{
"id": 2,
"addr": "127.0.0.1:28744",...
}
]**
Passo 2 — Gerando moedas
No Node A, crie uma carteira e um endereço:
bitcoin-cli -datadir="." createwallet CarteiraA bitcoin-cli -datadir="." getnewaddress bcrt1q8haacpalx68njrff0znzj35m0u6r73n3qv62dl
Gere 101 blocos:
bitcoin-cli -datadir="." generatetoaddress 101 bcrt1q8haacpalx68njrff0znzj35m0u6r73n3qv62dl
Agora o Node A possui moedas maduras para gastar.
Passo 3 — Criando uma transação
Ainda no Node A, gere um endereço de destino:
bitcoin-cli -datadir="." getnewaddress bcrt1qn84ejc5cfzg2qfx8rmtv6p74expjlaem4apreg
Em seguida:
bitcoin-cli -datadir="." sendtoaddress bcrt1qn84ejc5cfzg2qfx8rmtv6p74expjlaem4apreg 1 8ee1b4dd410a94be754cef5ba796defb15cc952b710fbea25a10b6d6b94f2802
A transação será inserida na mempool e anunciada aos peers conectados.
Passo 4 — Verificando a propagação
No Node A:
bitcoin-cli -datadir="." getrawmempool [ "8ee1b4dd410a94be754cef5ba796defb15cc952b710fbea25a10b6d6b94f2802" ]
No Node B:
bitcoin-cli -datadir="." getrawmempool [ "8ee1b4dd410a94be754cef5ba796defb15cc952b710fbea25a10b6d6b94f2802" ]
No Node C:
bitcoin-cli -datadir="." getrawmempool [ "8ee1b4dd410a94be754cef5ba796defb15cc952b710fbea25a10b6d6b94f2802" ]
No Node D:
bitcoin-cli -datadir="." getrawmempool [ "8ee1b4dd410a94be754cef5ba796defb15cc952b710fbea25a10b6d6b94f2802" ]
Após alguns instantes, o mesmo txid deverá aparecer nos quatro nodes. Essa é justamente a propagação tradicional da rede Bitcoin.
Passo 5 — Observando o tráfego
No Node A:
bitcoin-cli -datadir="." getpeerinfo
O Node A está conectado a três peers. Após criar uma transação, o getpeerinfo mostrou estatísticas de tráfego para cada conexão.
Em cada peer apareceu algo semelhante a:
"bytessent_per_msg": {
"inv":122,
"tx":246
},
"bytesrecv_per_msg": {
"getdata":266
}
Esses três campos mostram exatamente o fluxo descrito anteriormente:
Node A → inv → peer peer → getdata → Node A Node A → tx → peer
No experimento, o Node A enviou mensagens inv para anunciar a nova transação, recebeu mensagens getdata dos peers que solicitaram o conteúdo e, em seguida, enviou a transação completa através de mensagens tx.
Como o Node A estava conectado a três peers, esse processo aconteceu em três conexões diferentes. Por isso os mesmos tipos de mensagem aparecem repetidos nas estatísticas de cada peer.
Esse é o ponto central do modelo atual: uma nova transação é anunciada individualmente aos peers conectados. O mecanismo é robusto, mas gera tráfego redundante quando muitos nodes acabam recebendo a mesma transação por caminhos diferentes.
Passo 6 — Relacionando com o Erlay
No experimento acima observamos apenas uma transação. Mas imagine uma situação mais próxima da rede real. Suponha que cada node possua uma mempool contendo:
100.000 transações
e que apenas:
3 transações
sejam diferentes entre eles.
Hoje a sincronização depende principalmente dos anúncios individuais das novas transações.
O Erlay utilizaria Minisketch para descobrir algo equivalente a:
Node B precisa de txA Node C precisa de txB Node D precisa de txC
Sem precisar comunicar informações sobre as outras 99.997 transações que todos já conhecem. Essa é a principal ideia por trás da proposta: quanto mais parecidas forem as mempools, maior será a economia de banda obtida pela reconciliação dos conjuntos.
Experimentando o Minisketch na prática
Até agora vimos o conceito de Set Reconciliation de forma abstrata. Mas o Minisketch já é uma biblioteca real, desenvolvida por Pieter Wuille, que pode ser utilizada para comparar conjuntos e recuperar apenas suas diferenças.
O exemplo abaixo cria dois conjuntos com aproximadamente 100.000 elementos cada. O primeiro conjunto não possui o elemento 50000 e contém o elemento adicional 999999. O segundo conjunto não possui o elemento 70000 e contém o elemento adicional 888888.
O objetivo é descobrir apenas as diferenças entre os conjuntos.
#include <stdio.h>
#include <stdint.h>
#include <sys/types.h>
#include <minisketch.h>
int main() {
/* Esperamos recuperar no máximo 4 diferenças. */
minisketch* sketch1 = minisketch_create(32, 0, 4);
minisketch* sketch2 = minisketch_create(32, 0, 4);
/* Simula dois conjuntos com 100.000 elementos. */
for (uint64_t i = 1; i <= 100000; i++) {
if (i != 50000) {
minisketch_add_uint64(sketch1, i);
}
if (i != 70000) {
minisketch_add_uint64(sketch2, i);
}
}
/* Elementos exclusivos de cada conjunto. */
minisketch_add_uint64(sketch1, 999999);
minisketch_add_uint64(sketch2, 888888);
/* Combina os sketches. Elementos comuns se cancelam. */
minisketch_merge(sketch1, sketch2);
uint64_t output[4];
/* Recupera as diferenças. */
ssize_t count = minisketch_decode(sketch1, 4, output);
printf("Diferenças encontradas:\\n");
for (int i = 0; i < count; i++) {
printf("%lu\\n", output[i]);
}
minisketch_destroy(sketch1);
minisketch_destroy(sketch2);
return 0;
}
Ao executar o programa, o resultado é:
50000 70000 888888 999999
Nenhum dos 99.998 elementos compartilhados entre os conjuntos aparece na saída. Observe o que aconteceu. Os dois conjuntos continham 100.000 elementos cada, mas o algoritmo retornou apenas os quatro elementos que diferiam entre eles. Mais interessante ainda: o custo da reconciliação depende principalmente da quantidade de diferenças e não do tamanho total dos conjuntos.
Em outras palavras, recuperar quatro diferenças entre conjuntos com cem elementos ou entre conjuntos com cem mil elementos é essencialmente o mesmo tipo de problema para o Minisketch.
Essa é justamente a propriedade explorada pelo Erlay. Na rede Bitcoin, cada node possui uma mempool contendo dezenas ou centenas de milhares de transações. Como as mempools dos nodes honestos costumam ser muito parecidas, a quantidade de diferenças entre elas tende a ser pequena. Em vez de transmitir informações sobre todas as transações conhecidas, os nodes podem trocar sketches compactos e recuperar apenas aquilo que está faltando.
Na prática, ninguém sabe antecipadamente quantas diferenças existem entre duas mempools. Por isso, os sketches são criados com uma capacidade estimada. Caso a quantidade real de diferenças seja maior do que a capacidade escolhida, a decodificação falha e os nodes precisam utilizar um sketch maior ou outro mecanismo de sincronização.
Essa combinação entre sketches compactos e mempools quase idênticas é o que torna o Erlay uma proposta tão promissora para reduzir o tráfego da rede Bitcoin.
Por que o Erlay importa?
O Erlay não aumenta o tamanho dos blocos. Não altera a mineração. Não muda o mecanismo de consenso. Ainda assim, seu impacto pode ser significativo.
Ao reduzir o custo da propagação de transações, torna-se mais barato manter muitas conexões simultâneas. Isso permite uma rede mais conectada, mais robusta e potencialmente mais descentralizada. Por esse motivo, muitos desenvolvedores consideram o Erlay uma das melhorias mais importantes já propostas para a camada P2P do Bitcoin.
Embora a ideia do Erlay exista há alguns anos, ela continua sendo tema de discussão entre os desenvolvedores do Bitcoin Core. Durante o encontro de desenvolvedores em Barcelona, uma das sessões foi justamente dedicada ao tema “Erlay Redesign”.
O foco atual não é mais provar que a ideia funciona, mas sim discutir detalhes de implementação, simplificação da arquitetura e integração com o protocolo P2P existente. Isso mostra que o assunto continua ativo e relevante para o futuro da rede Bitcoin.
Confira o paper original que descreve a proposta.
Conclusão
Grande parte das discussões sobre escalabilidade do Bitcoin gira em torno de blocos, transações e soluções de segunda camada. O Erlay olha para um problema diferente: a eficiência da comunicação entre os nodes.
A proposta parte de uma observação simples: as mempools dos nodes honestos já são quase idênticas. Em vez de depender exclusivamente de anúncios individuais para sincronizá-las, os nodes podem comparar resumos compactos de seus conjuntos de transações e trocar apenas aquilo que realmente está faltando.
Se implementado, o Erlay poderá reduzir significativamente o tráfego da rede, permitindo que os nodes mantenham mais conexões e fortalecendo ainda mais a descentralização do Bitcoin.
O Erlay mostra que ainda existe muito espaço para otimizar o Bitcoin sem mexer nas regras que tornam a rede confiável. Ele não altera o tamanho dos blocos, não muda a mineração e não interfere no consenso, e mesmo assim ataca um custo real e silencioso, que é o tráfego gerado para manter milhares de nodes sincronizados o tempo todo.
Se você quer continuar explorando o protocolo nesse nível de profundidade, vale seguir pelos guias práticos de Bitcoin Core na prática, pela leitura sobre taxas e estimativa de fees e pelo material que explica as assinaturas Schnorr, área em que o próprio Pieter Wuille, autor do Minisketch, deixou contribuições importantes. Para quem está montando sua própria infraestrutura, os tutoriais de node com Umbrel e de node Lightning ajudam a colocar a mão na massa.
Perguntas frequentes sobre o Erlay
O que é o Erlay no Bitcoin?
O Erlay é uma proposta de melhoria do protocolo P2P do Bitcoin que reduz o tráfego usado na propagação de transações. Em vez de depender apenas dos anúncios individuais de cada transação nova, os nodes comparam resumos matemáticos compactos de suas mempools e trocam somente as transações que faltam, sem alterar nenhuma regra de consenso da rede.
Como o Erlay reduz o tráfego da rede Bitcoin?
Ele parte do fato de que as mempools dos nodes honestos são quase idênticas. Como a quantidade de diferenças entre elas tende a ser pequena, os nodes podem trocar sketches compactos e recuperar apenas aquilo que está faltando, em vez de reanunciar transações que todos já conhecem. Assim, o custo da sincronização passa a depender principalmente do número de diferenças e não do tamanho total da mempool.
O que é Set Reconciliation e Minisketch?
Set Reconciliation é a técnica que permite a dois nodes descobrirem as diferenças entre seus conjuntos de transações sem trocar as listas completas. O Minisketch é a biblioteca que implementa essa ideia, desenvolvida por Pieter Wuille, e usa codificação de erro parecida com a das telecomunicações para reconstruir apenas os elementos que diferem entre os conjuntos comparados.
O Erlay muda as regras de consenso do Bitcoin?
Não. O Erlay atua apenas na camada de comunicação entre os nodes, ou seja, no protocolo P2P. Ele não aumenta o tamanho dos blocos, não altera a mineração e não interfere no consenso. Por isso pode ser adotado como uma otimização de rede sem exigir mudanças nas regras que validam transações e blocos.
O Erlay já está em uso no Bitcoin Core?
Ainda não de forma definitiva. A ideia existe há alguns anos e segue em discussão ativa entre os desenvolvedores do Bitcoin Core, com sessões dedicadas ao tema do Erlay Redesign. O foco atual está nos detalhes de implementação, na simplificação da arquitetura e na integração com o protocolo P2P existente, o que mostra que o assunto continua relevante para o futuro da rede.
Compartilhe em suas redes sociais:
Professor universitário, pesquisador em tecnologias digitais e colaborador voluntário Bitcoin Coders. Doutor em Educação em Ciências (FURG, 2015), Mestre em Computação (UFRGS, 2007) e Engenheiro de Computação (FURG, 2004). Realizou pós-doutorado na UFSC (2024–2025).
Curtiu esse artigo? Considere nos pagar um cafezinho para continuarmos escrevendo novos conteúdos! ☕
