> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Mempool
> Como as transações são admitidas, guardadas, ordenadas e disseminadas antes de o consenso as confirmar num bloco.
O mempool é o que está entre uma transação assinada e um bloco confirmado. Decide o que vale a pena guardar, por que ordem as transações de um emissor se tornam elegíveis, que pares ficam a saber de uma transação e o que é descartado quando a procura excede a capacidade.
Para uma rede de negociação isto é estrutural, não acessório. O tráfego de ordens e de cancelamentos é irregular, concentrado em poucos emissores e sensível à latência de forma assimétrica: um cancelamento que chega tarde é pior do que uma ordem que chega tarde. As estruturas abaixo existem porque uma única fila FIFO não lida bem com nada disto.
O caminho de entrada
Transação assinada
Validaçãoassinatura · formato · estado da conta · o emissor consegue pagar?
Descartada, com motivo devolvidonão em silêncio — quem submeteu sabe porquê
Repositório de transações
Difusão a pares
Formação de lotes, depois consenso
A validação é barata e local, para que os recursos caros a jusante sejam gastos apenas em transações que poderiam realmente executar.
rejeitada
aceite
Uma transação é validada antes sequer de ser guardada. A validação é barata e local — assinatura, formato, estado da conta e se o emissor consegue pagar o que está a pedir — e existe para que os recursos caros a jusante sejam gastos apenas em transações que poderiam realmente executar. Uma rejeição aqui devolve um motivo a quem submeteu, em vez de desaparecer em silêncio.
Como as transações são guardadas
As transações aceites não são mantidas numa única fila plana. O repositório mantém várias vistas sobre o mesmo conjunto, cada uma respondendo a uma pergunta diferente.
Um conjunto de transações aceitescinco vistas, não cinco filas
Ordenação por contaPara este emissor, qual é a próxima transação?
Índice de prioridadeEntre todos os emissores, o que oferecer primeiro ao consenso?
Índice de expiraçãoO que ultrapassou o prazo?
Índice de cronologiaQue transações este par ainda não conhece?
Zona de esperaO que é bem formado mas ainda não é elegível?
A zona de espera é onde um erro de integração se torna visível: uma transação válida que ainda não é a próxima do seu emissor fica em espera, não é rejeitada — torna-se elegível assim que a lacuna à sua frente fecha.
| Vista | Pergunta a que responde |
| ------------------------ | ------------------------------------------------------------------------ |
| **Ordenação por conta** | Para este emissor, qual é a próxima transação? |
| **Índice de prioridade** | Entre todos os emissores, o que deve ser oferecido primeiro ao consenso? |
| **Índice de expiração** | O que ultrapassou o prazo e deve ser removido? |
| **Índice de cronologia** | Que transações este par ainda não conhece? |
| **Zona de espera** | O que está bem formado mas ainda não é elegível? |
A **zona de espera** merece a maior atenção, porque é aí que se torna visível uma classe de erros de integração. Uma transação pode ser perfeitamente válida e ainda assim não ser a próxima da fila do seu emissor — na maior parte das vezes porque uma transação anterior da mesma conta não chegou ou não foi confirmada. Uma transação assim fica em espera em vez de ser rejeitada: mantém-se disponível e torna-se elegível assim que a lacuna à sua frente for fechada. Um cliente que submeta fora de ordem sofre, portanto, um atraso e não uma falha, mas um cliente que nunca preencha a lacuna deixa trabalho em espera até expirar.
O **índice de cronologia** é o que torna incremental a disseminação entre pares. Cada par é acompanhado pelo ponto da cronologia até onde já foi servido, pelo que uma difusão envia o que falta a esse par em vez de reenviar todo o conjunto. A cronologia é dividida em compartimentos em vez de ser uma fila única, o que impede que um emissor pesado monopolize todos os slots de difusão.
Disseminação e equidade
Os nós não ficam a saber das transações cada um por si. Um nó que aceita uma transação difunde-a aos seus pares, e os pares não são tratados de forma idêntica — os pares a montante são priorizados, para que uma transação se desloque na direção dos validadores que podem agir sobre ela em vez de se difundir uniformemente pela rede.
A equidade é acompanhada ao longo do histórico recente em vez de ser imposta mensagem a mensagem. O mempool mantém um registo deslizante de que emissores e que tipos de tráfego consumiram capacidade recentemente e usa-o para moldar o que é servido a seguir. É este o mecanismo que impede que a tempestade de ordens e cancelamentos de uma única conta expulse o resto da rede, sem precisar de um rate limit rígido por conta que penalizaria o market making legítimo.
Passagem ao consenso
O consenso não retira as transações do mempool uma a uma. As transações são reunidas em **lotes**, os lotes são disseminados pelos validadores em segundo plano e cada lote recolhe confirmações de receção até o seu originador conseguir provar que uma parte suficiente da rede o detém. Só então uma proposta de bloco o pode referenciar.
A consequência é que uma proposta de bloco transporta digests de lotes e não corpos de transações, pelo que o tamanho das mensagens de consenso se mantém constante à medida que o débito sobe — e um bloco confirmado é sempre reexecutável, porque os dados por detrás dele foram provados disponíveis antes de serem referenciados. Ver [IntentionBFT](/pt/protocol/architecture/intention-bft) para saber como essa prova é formada e usada.
É também por isto que a admissão no mempool não é o mesmo que inclusão. Uma transação aceite, guardada e difundida entrou na fila; não foi ordenada. Nada sobre o destino de uma transação está fechado até o consenso confirmar o bloco que a contém.
O que isto significa para um cliente
* **Uma rejeição na submissão é informativa.** Aconteceu antes de a transação ser guardada, e o motivo descreve algo que o cliente pode corrigir.
* **Silêncio não é rejeição.** Uma transação pode estar em espera atrás de uma lacuna criada pelo próprio cliente. Acompanhar o que foi submetido e o que foi confirmado, em vez de assumir que a falta de uma confirmação significa que se perdeu.
* **A ordem dentro de uma conta importa; a ordem entre contas não.** Duas transações do mesmo emissor têm uma sequência definida. Duas transações de emissores diferentes são ordenadas pelo consenso, não por quem submeteu primeiro.
* **Os cancelamentos não são privilegiados no mempool.** A prioridade de cancelamento é uma propriedade da [execução do kernel](/pt/protocol/architecture/kernel), onde os cancelamentos correm antes das colocações agressivas no mesmo bloco — não da colocação em fila.