Skip to main content
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.
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 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, onde os cancelamentos correm antes das colocações agressivas no mesmo bloco — não da colocação em fila.