Bitcoin Magazine
The Core Issue: Cluster Mempool, os problemas são mais fáceis em pedaços
Cluster Mempool1 é uma reformulação completa de como a mempool gere a organização e ordenação de transações, concetualizada e implementada por Suhas Daftuar e Pieter Wuille. O design visa simplificar a arquitetura geral, alinhar melhor a lógica de ordenação de transações com os incentivos dos mineradores e melhorar a segurança dos protocolos de segunda camada. Foi integrado no Bitcoin Core no PR #336292 a 25 de novembro de 2025.
A mempool é um conjunto gigante de transações pendentes que o seu nó tem de monitorizar por várias razões: estimativa de taxas de transação, validação de substituição de transações e construção de blocos se for um minerador.
São muitos objetivos diferentes para uma única função do seu nó. O Bitcoin Core até à versão 30.0 organiza a mempool de duas formas diferentes para ajudar nestas funções, ambas do ponto de vista relativo de qualquer transação: taxa combinada olhando para a frente da transação e seus filhos (descendant feerate), e taxa combinada olhando para trás da transação e seus pais (ancestor feerate).
Estas são usadas para decidir quais transações remover da sua mempool quando está cheia e quais incluir primeiro ao construir um novo modelo de bloco.
Quando um minerador está a decidir se inclui uma transação no seu bloco, o seu nó analisa essa transação e quaisquer ancestrais que devam ser confirmados primeiro para que seja válida num bloco, e observa a taxa média por byte em todos eles em conjunto, considerando as taxas individuais que pagaram como um todo. Se esse grupo de transações couber dentro do limite de tamanho do bloco enquanto supera outros em taxas, é incluído no próximo bloco. Isto é feito para cada transação.
Quando o seu nó está a decidir quais transações remover da sua mempool quando está cheia, analisa cada transação e quaisquer filhos que tenha, removendo a transação e todos os seus filhos se a mempool já estiver cheia com transações (e seus descendentes) a pagar uma taxa mais alta.
Observe o gráfico de exemplo de transações acima, as taxas são mostradas entre parênteses (ancestor feerate, descendant feerate). Um minerador ao analisar a transação E provavelmente incluí-la-ia no próximo bloco, uma pequena transação a pagar uma taxa muito alta com um único ancestral pequeno. No entanto, se a mempool de um nó estivesse a encher, analisaria a transação A com dois filhos enormes a pagar uma taxa relativa baixa, e provavelmente removê-la-ia ou não a aceitaria se acabasse de ser recebida.
Estas duas classificações, ou ordenações, estão completamente em desacordo uma com a outra. A mempool deve propagar de forma fiável o que os mineradores vão minerar, e os utilizadores devem confiar que a sua mempool local prevê com precisão o que os mineradores vão minerar.
O funcionamento da mempool desta forma é importante para:
O comportamento atual da mempool não se alinha totalmente com a realidade dos incentivos de mineração, o que cria pontos cegos que podem ser problemáticos para a segurança de segunda camada ao criar incerteza sobre se uma transação chegará a um minerador, bem como pressão para canais de transmissão não públicos para mineradores, potencialmente piorando o primeiro problema.
Isto é especialmente problemático quando se trata de substituir transações não confirmadas, seja simplesmente para incentivar os mineradores a incluir uma substituição mais cedo, ou como parte de um protocolo de segunda camada a ser aplicado on-chain.
A substituição de acordo com o comportamento existente torna-se imprevisível dependendo da forma e tamanho da rede de transações em que a sua está envolvida. Numa situação simples de aumento de taxa, isto pode falhar em propagar e substituir uma transação, mesmo quando minerar a substituição seria melhor para um minerador.
No contexto de protocolos de segunda camada, a lógica atual permite que os participantes potencialmente consigam remover transações ancestrais necessárias da mempool, ou tornem impossível que outro participante submeta uma transação filha necessária à mempool sob as regras atuais devido a transações filhas que o participante malicioso criou, ou à remoção de transações ancestrais necessárias.
Todos estes problemas são o resultado destas classificações inconsistentes de inclusão e remoção e dos desalinhamentos de incentivos que criam. Ter uma única classificação global resolveria estes problemas, mas reordenar globalmente toda a mempool para cada nova transação é impraticável.
Transações que dependem umas das outras são um grafo, ou uma série direcionada de "caminhos". Quando uma transação gasta outputs criados por outra no passado, está ligada a essa transação passada. Quando adicionalmente gasta outputs criados por uma segunda transação passada, liga ambas as transações históricas.
Quando não confirmadas, cadeias de transações como esta devem ter as transações anteriores confirmadas primeiro para que as posteriores sejam válidas. Afinal, não se pode gastar outputs que ainda não foram criados.
Este é um conceito importante para compreender a mempool, está explicitamente ordenada direcionalmente.
É tudo apenas um grafo.
No cluster mempool, o conceito de cluster é um grupo de transações não confirmadas que estão diretamente relacionadas entre si, ou seja, gastando outputs criados por outras no cluster ou vice-versa. Isto torna-se uma unidade fundamental da nova arquitetura da mempool. Analisar e ordenar toda a mempool é uma tarefa impraticável, mas analisar e ordenar clusters é muito mais gerível.
Cada cluster é dividido em chunks, pequenos conjuntos de transações do cluster, que são depois ordenados por ordem de taxa mais alta por byte para a mais baixa, respeitando as dependências direcionais. Por exemplo, digamos que da taxa mais alta para a mais baixa os chunks no cluster (A) são: [A,D], [B,E], [C,F], [G, J], e por último [I, H].
Isto permite pré-ordenar todos estes chunks e clusters, e uma ordenação mais eficiente de toda a mempool no processo.
Os mineradores podem agora simplesmente pegar nos chunks de taxa mais alta de cada cluster e colocá-los no seu modelo, se ainda houver espaço podem descer para os próximos chunks de taxa mais alta, continuando até o bloco estar aproximadamente cheio e só precisar de descobrir as últimas transações que pode encaixar. Este é aproximadamente o método ótimo de construção de modelo de bloco assumindo acesso a todas as transações disponíveis.
Quando as mempools dos nós ficam cheias, podem simplesmente pegar nos chunks de taxa mais baixa de cada cluster e começar a removê-los da sua mempool até não ultrapassar o limite configurado. Se isso não for suficiente, passa para os próximos chunks de taxa mais baixa, e assim por diante, até estar dentro dos seus limites de mempool. Feito desta forma, remove casos extremos estranhos desalinhados com os incentivos de mineração.
A lógica de substituição também é drasticamente simplificada. Compare o cluster (A) com o cluster (B) onde a transação K substituiu G, I, J e H. O único critério que precisa de ser cumprido é o novo chunk [K] deve ter uma taxa de chunk mais alta que [G, J] e [I, H], [K] deve pagar mais em taxas totais do que [G, J, I, H], e K não pode ultrapassar um limite superior de quantas transações está a substituir.
Num paradigma de cluster, todos estes diferentes usos estão alinhados entre si.
Esta nova arquitetura permite-nos simplificar os limites de grupo de transações, removendo limitações anteriores sobre quantos ancestrais não confirmados uma transação na mempool pode ter e substituindo-os por um limite global de cluster de 64 transações e 101 kvB por cluster.
Este limite é necessário para manter o custo computacional de pré-ordenação dos clusters e seus chunks suficientemente baixo para ser prático para os nós realizarem numa base constante.
Esta é a verdadeira perceção-chave do cluster mempool. Ao manter os chunks e clusters relativamente pequenos, torna simultaneamente a construção de um modelo de bloco ótimo barata, simplifica a lógica de substituição de transações (aumento de taxa) e, portanto, melhora a segurança de segunda camada, e corrige a lógica de remoção, tudo de uma vez.
Acabaram-se os cálculos caros e lentos em tempo real para construção de modelos, ou comportamento imprevisível no aumento de taxas. Ao corrigir o desalinhamento de incentivos na forma como a mempool estava a gerir a organização de transações em diferentes situações, a mempool funciona melhor para todos.
O cluster mempool é um projeto que está em desenvolvimento há anos e terá um impacto material em garantir que modelos de bloco lucrativos estão abertos a todos os mineradores, que os protocolos de segunda camada têm comportamentos de mempool sólidos e previsíveis para construir, e que o Bitcoin pode continuar a funcionar como um sistema monetário descentralizado.
Para aqueles interessados em mergulhar mais profundamente nos pormenores de como o cluster mempool é implementado e funciona por dentro, aqui estão dois tópicos do Delving Bitcoin que pode ler:
Visão geral de implementação de alto nível (com fundamentação de design): https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393
Como funcionam os diagramas de taxas do Cluster Mempool: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553
Obtenha a sua cópia de The Core Issue hoje!
Não perca a sua oportunidade de ter The Core Issue — com artigos escritos por muitos programadores Core a explicar os projetos em que trabalham!
Este artigo é a Carta do Editor apresentada na última edição impressa da Bitcoin Magazine, The Core Issue. Estamos a partilhá-lo aqui como uma antevisão das ideias exploradas em toda a edição completa.
[1] https://github.com/bitcoin/bitcoin/issues/27677
[2] https://github.com/bitcoin/bitcoin/pull/33629
Este post The Core Issue: Cluster Mempool, Problems Are Easier In Chunks apareceu primeiro na Bitcoin Magazine e foi escrito por Shinobi.


