Constellation: uma proposta de MCP na Solana

Insights práticos

• Constellation é a primeira proposta formal, no nível do protocolo, para implementar Múltiplos Proponentes Simultâneos (MCP) em uma blockchain de produção em grande escala.
• Constellation introduz duas novas funções (ou seja, proponentes e atestadores) que restringem a autonomia do líder na construção de blocos. Aproximadamente 16 proponentes operam simultaneamente em um ciclo de 50 ms, agrupando transações em pslices codificadas para correção de apagamentos e distribuídas a 256 atestadores. O registro de atestação vincula criptograficamente o líder ao conjunto de transações incluídas. Se uma pslice for atestada por um número suficiente de atestadores, o líder não poderá excluir a transação sem produzir um bloco inválido, que será rejeitado pela rede.
• Constellation tem a propriedade de resistência à censura seletiva: em cada ciclo, ou todas as transações competitivas em taxas são incluídas, ou nenhuma é.
• Ataques de ordenação com conteúdo visível e de manipulação de tempo continuam sem solução. Sob Constellation, as transações ficam visíveis a todos os proponentes que as recebem no momento do envio. Devido à arquitetura multiproponente do MCP, isso pode, na prática, ampliar essas superfícies de ataque em vez de reduzi-las. O design atual reconhece que estratégias de latência baseadas em tempo não podem ser punidas.
• Constellation reestrutura as taxas existentes: a taxa de inclusão corresponde à taxa-base atual, e a taxa de ordenação corresponde à taxa de prioridade existente. A mudança econômica mais significativa é que a atividade atualmente direcionada a serviços de inclusão externos ao protocolo e a acordos de taxas off-chain deve retornar ao protocolo. A seleção de funções ponderada por stake preserva as atuais dinâmicas de concentração, e o impacto líquido sobre validadores individuais não poderá ser modelado até o futuro SIMD de Constellation.
• MCP aumenta a latência de sequenciamento, mas reduz a latência de inclusão. A rodada dos atestadores, a janela de ciclo de 50 ms e a montagem em lotes acrescentam tempo em relação ao caminho atual de envio direto à TPU. Hoje, a latência é maior para validadores que empacotam imediatamente as transações da TPU e menor para os que as atrasam. Sob Constellation, as transações válidas passam a ter uma garantia de inclusão limitada e imposta pelo protocolo.
• Constellation é explicitamente incompatível com modelos de Separação entre Proponente e Construtor (PBS). Quando o registro de atestação restringe a autonomia do líder, não resta nada para um construtor especializado vender. Essa abordagem representa uma filosofia fundamentalmente diferente da abordagem atual da Ethereum em relação a MEV.
• Ainda não existem benchmarks empíricos em condições de rede realistas. O dado mais importante que a Anza pode fornecer são projeções comparativas de latência para slots de 200 ms sob o protocolo atual e sob Constellation. Até que esses dados estejam disponíveis, a comunidade continuará debatendo trade-offs que não consegue quantificar. 
• Constellation é construída sobre Alpenglow, cujo lançamento na mainnet está previsto para o terceiro trimestre de 2026.

Introdução

Apesar da impressionante ausência de plantas de agave, Brennan Watt, CEO da Anza, foi ao deserto da Califórnia apresentar Constellation—uma proposta para levar Múltiplos Proponentes Simultâneos (MCP) à Solana. Esta é a atualização estruturalmente mais ambiciosa e, possivelmente, a proposta de MCP no nível do protocolo mais relevante já apresentada por uma blockchain de produção. Ela busca eliminar o monopólio temporário do líder sobre a ordenação de transações e o valor extraível que esse monopólio gera. Constellation democratiza o espaço de blocos na Solana.

Este artigo apresenta uma análise crítica de Constellation: o que ela resolve, o que deliberadamente deixa para depois e o que permanece de fato sem solução. Apresentamos uma estrutura de três camadas para avaliar a resistência à censura, comparamos Constellation ao cenário atual de MCP e examinamos se os trade-offs introduzidos são compatíveis com a identidade de desempenho construída pela Solana.

Presume-se conhecimento prévio sobre Alpenglow. 

O problema que Constellation resolve

As transações são a força vital da Solana. Elas são agrupadas e registradas permanentemente na rede na forma de blocos. Mas o processo de decidir quais transações entram nesses blocos, e em qual ordem, não é neutro. 

O monopólio do líder sobre a produção de blocos

A produção de blocos segue uma escala de líderes, na qual um validador por vez é responsável por produzir blocos em determinada janela.

Durante esse período, as transações são encaminhadas diretamente à Unidade de Processamento de Transações (TPU) do líder, onde geralmente chegam antes de serem recebidas por qualquer outro participante.

O líder ocupa uma posição de poder incomum. Ou seja, ele pode observar as transações recebidas antes que elas fiquem publicamente visíveis.

O líder pode decidir não incluir determinadas transações, reordená-las arbitrariamente ou introduzir as próprias transações.

Essa é uma característica estrutural do funcionamento atual do consenso com um único líder e está presente, em diferentes graus, em praticamente todas as blockchains de produção baseadas em Proof of Stake.

A ausência de uma mempool pública na Solana acentua essa assimetria em vez de reduzi-la. A mempool pública da Ethereum oferece aos participantes alguma visibilidade sobre transações pendentes, criando uma espécie de igualdade de condições entre agentes sofisticados que competem para explorar a ordenação das transações.

Na Solana, a vantagem informacional do líder é menos contestável devido à natureza do encaminhamento de transações. 

Valor Máximo Extraível (MEV)

Em condições normais e com validadores honestos, esse poder é pouco explorado. No entanto, o problema é que os validadores são agentes econômicos racionais. À medida que a Solana amadurece e a atividade financeira continua crescendo, o lucro disponível com a exploração do monopólio temporário do líder aumenta na mesma proporção. Um validador que decide não explorar essa posição está simplesmente deixando dinheiro na mesa. Os nós que se comportam corretamente ficam em desvantagem econômica—uma desvantagem que os incentiva a comprometer a qualidade do próprio sistema do qual participam.

Esse lucro extraível é conhecido como Valor Máximo Extraível (MEV), termo formalizado inicialmente por Daian et al. em Flash Boys 2.0 como Valor Extraível por Mineradores, antes de ser aplicado a redes Proof of Stake. Ele abrange desde arbitragem e frontrunning até ataques sanduíche, censura seletiva e qualquer estratégia que explore a vantagem informacional e posicional do líder sobre os usuários cujas transações ele processa.

A principal resposta do setor ao MEV tem sido o modelo de Separação entre Proponente e Construtor (PBS), implementado na Ethereum por meio do MEV-Boost. Sob PBS, construtores especializados competem para construir blocos que maximizem o valor extraível, enquanto os proponentes apenas selecionam o bloco mais lucrativo a ser produzido. Essa é uma reformulação pragmática do problema para democratizar o acesso ao MEV e redistribuir seus ganhos entre o conjunto de validadores, em vez de concentrá-los nos agentes mais sofisticados, pois esse modelo pressupõe que a extração de MEV é inevitável.

O problema dessa abordagem é que PBS não reduz os danos aos usuários—a extração continua ocorrendo, apenas os beneficiários mudam. PBS trata alguns dos efeitos negativos do MEV para os nós da rede, mas não reduz os danos aos usuários da rede.

A Solana tem sua própria relação, ainda em evolução, com MEV. A combinação de blocos rápidos, envio direto à TPU e um conjunto competitivo de validadores produziu um cenário distinto de MEV, caracterizado por spam, leilões de taxas de prioridade e reordenação de transações no nível dos validadores. O mecanismo de blocos da Jito pode ser considerado parcialmente análogo ao MEV-Boost, pois oferece um mecanismo de leilão off-chain no qual buscadores dão lances pela ordenação de transações, com os ganhos compartilhados entre validadores e participantes de staking. Ou seja, assim como PBS, a Jito gerencia e redistribui MEV de maneira mais democrática, em vez de eliminá-lo por completo.

Constellation busca corrigir isso. Em vez de aceitar o monopólio do líder e gerenciar suas consequências, ela busca contê-lo estruturalmente, tornando as formas mais prejudiciais de MEV impossíveis por design. O whitepaper de Constellation descreve essa ambição como a “infraestrutura dos Mercados de Capitais da Internet, um ambiente universal para a atividade econômica no qual os usuários podem confiar que a estrutura de mercado é justa”.

Os mercados financeiros tradicionais tentam impor proteções semelhantes por meio de regulamentação e supervisão jurisdicional. Essas proteções são reativas e desiguais, e repetidamente se mostram insuficientes. A ambição de Constellation é impor a equidade no nível do protocolo, de forma que ela não possa ser contornada nem aplicada seletivamente. Constellation busca fazer isso implementando Múltiplos Proponentes Simultâneos (MCP) na Solana.

Múltiplos Proponentes Simultâneos

Em uma blockchain tradicional com um único líder, um validador é responsável por produzir cada bloco. Esse validador (ou seja, o líder) detém temporariamente o controle exclusivo sobre a inclusão e a ordenação de transações. Enquanto está autorizado a produzir blocos, todos os outros participantes da rede são observadores passivos durante essa janela. Em última instância, o líder decide quais transações serão incluídas e em qual ordem.

Esse design é atraente por sua simplicidade. Ter um único validador supervisionando a produção de blocos significa não ter sobrecarga de coordenação, propostas conflitantes para resolver nem um modelo complexo de responsabilização. No entanto, também cria um ponto único de exploração. O monopólio temporário do líder é a causa fundamental do MEV, e todas as principais medidas de mitigação até agora aceitaram essa estrutura e buscaram gerenciar suas consequências.

Múltiplos Proponentes Simultâneos (MCP) são uma classe de design de protocolo que elimina esse monopólio no nível estrutural. Em vez de alternar para um único líder que detém direitos exclusivos de produção de blocos, MCP permite que vários nós proponham transações simultaneamente. Nenhum proponente controla o conjunto completo de transações. Em vez disso, suas propostas são combinadas, geralmente por uma função restrita de montagem, de acordo com as regras do protocolo.

Um usuário que envia uma transação a vários proponentes ao mesmo tempo deixa de depender de um único nó, pois passa a ter vários caminhos independentes para inclusão. Um líder que tente excluir sua transação precisa lidar com o fato de que outros proponentes já a viram e que os atestadores já a atestaram. Um único líder monta o bloco final, mas sua autonomia é fortemente restrita.

O principal trade-off do MCP é a complexidade de coordenação. Permitir que vários nós proponham transações simultaneamente levanta questões que designs com um único líder evitam por completo. Como resolver transações conflitantes quando dois proponentes incluem a mesma transação? Como determinar a ordenação entre propostas? Como impedir que um proponente sofisticado manipule as regras de combinação? Isso acrescenta uma complexidade considerável ao protocolo—as equipes precisam lidar com desafios de coordenação envolvendo novas funções de nós, lógica de agendamento, premissas criptográficas e modos de falha, todos exigindo testes rigorosos.

É importante ser preciso neste ponto, pois MCP é usado de forma ampla em todo o setor para descrever diversos designs com propriedades significativamente diferentes. No nível mais básico, MCP oferece resistência probabilística à censura—uma transação enviada a vários proponentes é mais difícil de censurar, pois isso exige coordenação entre vários nós. No nível mais avançado, MCP pode oferecer resistência estrutural à censura—torna-se matematicamente impossível para o líder produzir um bloco que censure uma transação atestada por um quórum suficiente. É isso que Constellation busca, e a diferença é extremamente importante para aplicações financeiras que exigem garantias rígidas.

Constellation: como funciona

Constellation é um protocolo para implementar MCP na Solana. Ele complementa Alpenglow: Alpenglow cuida do consenso (ou seja, segurança, vivacidade e finalidade), enquanto Constellation cuida da estrutura de mercado—quem pode propor transações, como essas propostas são reconhecidas e o que o líder pode fazer com elas. Constellation produz a carga útil que Alpenglow finaliza.

Arquitetura

Constellation introduz duas novas funções na pilha de protocolos da Solana, cada uma com uma responsabilidade distinta, além de modificar as funções de líderes e validadores.

Os proponentes são o ponto de entrada das transações. A qualquer momento, aproximadamente 16 proponentes ficam ativos simultaneamente, selecionados aleatoriamente com base no stake e alternados a cada 32 ciclos (ou seja, ~1,6 segundo). Os usuários enviam suas transações diretamente a um ou mais proponentes de sua escolha. Um proponente pode aceitar ou rejeitar qualquer transação, desde que as transações aceitas sejam válidas. Não há nenhuma regra de protocolo que imponha a inclusão de transações nessa etapa; a garantia de resistência à censura surge mais adiante no pipeline. Cada proponente opera em um ciclo de 50 milissegundos. Em cada ciclo, um proponente agrupa as transações aceitas em uma estrutura chamada pslice—o prefixo “p” é mudo e serve apenas para diferenciá-la das slices de Alpenglow. A pslice é codificada para correção de apagamentos em 256 partes menores, chamadas pshreds, e uma pshred é distribuída a cada um dos 256 atestadores ativos. A codificação para correção de apagamentos usa um limiar de recuperação de 64, o que significa que quaisquer 64 das 256 pshreds são suficientes para reconstruir a pslice completa. Cada pshred contém um compromisso de hash criptográfico com a lista completa de transações, garantindo que o líder não possa substituir transações nem alterar a ordenação dentro de uma pslice após a aprovação dos atestadores.

Os atestadores recebem pshreds de um proponente e as encaminham imediatamente aos próximos ~2 líderes, para compensar eventuais falhas ou ausências, além de registrar o hash de compromisso da pslice recebida. Ao final de cada ciclo, o atestador assina uma atestação—uma declaração criptograficamente vinculante que lista todos os hashes de compromisso de pslices observados durante o ciclo. Essa atestação é enviada ao líder e funciona como o registro comprobatório que restringe quais transações ele pode incluir. O registro é ponderado por stake e assinado, o que significa que não pode ser forjado nem silenciosamente ignorado. 

O líder em Constellation é o mesmo líder de Alpenglow—o nó responsável por produzir o bloco final que entra em consenso. A diferença sob Constellation é que a autonomia do líder fica fortemente restrita pelo registro de atestação. Constellation impõe dois limiares distintos. Para que a atestação agregada seja válida, pelo menos 60% dos atestadores devem participar. Se esse limiar não for atingido, o bloco inteiro será ignorado. Dentro desse conjunto, qualquer pslice atestada por pelo menos 40% dos atestadores deve ser incluída pelo líder. Não fazer isso produz um bloco inválido, que será rejeitado pela rede. Esse design com dois limiares separa a validade no nível do bloco da inclusão por proponente. Ou seja, o líder pode produzir um bloco válido mesmo que os dados de alguns proponentes não tenham alcançado atestadores suficientes, mas não pode excluir seletivamente os proponentes cujos dados alcançaram. Depois que o líder compila todas as pslices atestadas em um lote, ele transmite esse lote aos validadores por meio do Rotor de Alpenglow. 

Os validadores recebem lotes do líder por meio do Rotor e realizam a execução em pipeline conforme eles chegam. Depois que o bloco completo é recebido, os validadores o verificam em relação ao registro de atestação para confirmar que cada pslice atestada tem um envio correspondente no bloco. Somente se todas as verificações forem aprovadas o validador votará para finalizá-lo; se elas falharem, os validadores votarão para ignorar toda a janela do líder por meio da chamada TrySkipWindow. 

Ciclos e blocos

Um ciclo é a unidade fundamental de tempo de Constellation. Trata-se de uma janela de 50 milissegundos derivada do horário UTC ao dividir o timestamp Unix em nanossegundos por 50.000.000. É importante destacar que os ciclos não estão alinhados aos slots de Alpenglow. Um slot contém vários ciclos, e os lotes produzidos ao longo desses ciclos constituem a carga útil do bloco do líder. Essa distinção é importante porque o ciclo de 50 ms é o pulso econômico (ou seja, a janela em que a resistência à censura é imposta), enquanto o slot continua sendo a unidade de consenso de Alpenglow.

O whitepaper especifica uma tolerância para a diferença de relógio entre proponentes e atestadores e ajusta a janela de atestação de acordo com ela. Para ilustrar por que isso é importante, suponha que o relógio de um proponente esteja 5 ms adiantado em relação ao conjunto de atestadores. As pshreds desse proponente podem chegar aos atestadores antes do esperado em relação ao limite do ciclo, dando às transações dessa pslice uma janela ligeiramente maior para acumular atestações. Por outro lado, um proponente cujo relógio esteja atrasado pode ter suas pshreds recebidas tarde o suficiente para ficarem completamente fora da janela de atestação, mesmo que tenham sido enviadas “no prazo”. Em ambientes de data center que usam ferramentas como chrony ou receptores GPS, a sincronização de relógios é uma prática comum, e a variação costuma ser inferior a um milissegundo, bem dentro dos limites de tolerância de Constellation. A preocupação é que Constellation introduz uma nova variável que não existia no modelo de tempo puramente lógico de Alpenglow e para a qual o futuro SIMD de Constellation deve especificar limites de monitoramento.

À medida que Constellation se aproxima do fim de uma época, proponentes e atestadores podem ficar brevemente incertos sobre o início da próxima época. Durante essa janela, Constellation opera simultaneamente nas duas épocas, com dois conjuntos de proponentes e atestadores ativos ao mesmo tempo. O consenso de Alpenglow resolve naturalmente quais ciclos pertencem a cada época.

Ciclo de vida e taxas das transações

Uma transação precisa passar por quatro etapas antes de ser executada:

• Ela deve ser aceita e incluída em uma pslice por um proponente.
• Essa pslice deve acumular atestações suficientes para ser incluída no lote do líder.
• A transação deve ter um lance alto o bastante para ser selecionada para execução dentro do limite de computação do lote.
• O bloco que contém o lote deve ser confirmado pelo consenso de Alpenglow.

Cada transação inclui um lance (ou seja, a taxa de execução por unidade de computação) que determina sua ordem dentro do mesmo lote. Lances maiores são executados primeiro.

Constellation divide o custo de uma transação em duas taxas distintas:

• Uma taxa de inclusão.
• Uma taxa de ordenação.

A taxa de inclusão é uma cobrança pequena e fixa, baseada no tamanho da transação e no número de assinaturas. Ela é paga ao proponente que incluiu a transação em sua pslice e é cobrada a partir do momento em que a transação ultrapassa o limiar de atestação, independentemente de ser executada ou não. Isso é análogo à taxa-base do sistema atual da Solana, mas com uma ressalva importante: se um usuário enviar a mesma transação a três proponentes para obter redundância, ele pagará a taxa de inclusão três vezes (ou seja, uma vez por proponente), pois cada proponente realizou de forma independente o trabalho de incluí-la. Portanto, se um usuário enviar a mesma transação a n proponentes diferentes para obter redundância, pagará a taxa de inclusão n vezes.

A taxa de ordenação é o componente maior, baseado em prioridade, calculado ao multiplicar o total de unidades de computação da transação por seu lance. Ela é cobrada apenas uma vez, pois a transação só pode ser executada uma vez, independentemente de quantos proponentes a incluam. Por exemplo, uma transação que solicita 200.000 unidades de computação com um lance de 0,00001 SOL por unidade de computação paga uma taxa de ordenação de 2 SOL. Se essa mesma transação for enviada a quatro proponentes para obter redundância, o usuário pagará quatro taxas de inclusão e uma única taxa de ordenação de 2 SOL. A taxa de ordenação é devolvida ao ecossistema proporcionalmente ao stake dos nós—o whitepaper deixa o design desse mecanismo para o futuro SIMD.

Toda conta pagadora de taxas deve manter um saldo mínimo de reserva de aproximadamente 0,001 SOL para evitar a manipulação de taxas entre proponentes simultâneos. Isso garante que as taxas de inclusão sempre possam ser pagas, mesmo quando vários proponentes incluem simultaneamente transações que interagem com a mesma conta.

Constellation e Alpenglow

Alpenglow é o protocolo de consenso da Solana. Ele determina quais blocos são válidos, a ordem em que são finalizados e como a rede se recupera de falhas. Seus componentes Votor e Rotor substituem o Tower BFT e a propagação de votos baseada em gossip, reduzindo significativamente o tempo até a finalidade. Alpenglow não determina quem propõe transações nem como a ordenação é definida dentro de um bloco.

Constellation é uma camada de estrutura de mercado que restringe o que o líder de Alpenglow pode fazer com os blocos que monta—ela define quem propõe transações e como a ordenação é determinada dentro de cada bloco. Os lotes produzidos por Constellation tornam-se a carga útil dos blocos de Alpenglow. Em seguida, o Votor de Alpenglow autentica esses blocos de acordo com suas regras de votação predefinidas. Os dois protocolos são combinados de modo que Alpenglow ofereça segurança e vivacidade, enquanto Constellation oferece equidade na ordenação.

Essa composibilidade significa que Constellation também herda as premissas de segurança de Alpenglow sem enfraquecê-las. Constellation não altera as garantias de Alpenglow. Em vez disso, introduz novas garantias e premissas para as novas funções de proponente e atestador, além da sincronização com o horário UTC em seu novo modelo de temporização baseado em ciclos.

Constellation é a primeira proposta formal no nível do protocolo para implementar MCP em uma blockchain de produção escalável. É uma adição importante para introduzir resistência à censura na Solana—o próximo capítulo de um roadmap de protocolo viabilizado por Alpenglow.

O que a resistência à censura realmente exige

Historicamente, a literatura sobre MEV abordou o problema por várias perspectivas distintas que, em conjunto, delineiam uma visão mais unificada do que qualquer proposta de resistência à censura realmente precisa resolver. Com base na taxonomia fundamental de ataques de front-running de Eskandari et al., no framework formal de duas propriedades para protocolos MCP de Garimidi et al. e na análise de Landers e Marsh sobre canais de MEV específicos de MCP, propomos organizar a superfície de ataque em três camadas distintas, cada uma exigindo uma classe diferente de solução. Este framework é nossa própria síntese, apresentada aqui para avaliar o design da Constellation.

Camada 1: censura rígida

Censura rígida refere-se à capacidade de um líder ou propositor se recusar a incluir uma transação identificada. Essa é a forma mais evidente de manipulação e uma que a Constellation resolve estruturalmente. Com a Constellation, torna-se criptograficamente impossível para um líder produzir um bloco válido que exclua uma transação com taxa competitiva atestada por um quórum suficiente de atestadores. Slashing não é necessário para isso, pois a imposição é arquitetural.

Camada 2: ordenação com conteúdo visível

A segunda camada é mais difícil de resolver. Embora os propositores não possam censurar diretamente, eles ainda podem observar o conteúdo das transações antes da ordenação final e tentar explorar essa visibilidade (por exemplo, aplicando um ataque sanduíche a uma negociação grande). É isso que Garimidi et al. formalizam como a propriedade de ocultação: um adversário não deve conseguir ver o conteúdo das transações antes que sejam confirmadas. A Constellation implementa ocultação parcial. Ou seja, uma transação fica visível somente para o propositor que a recebe — não para todos os propositores —, e o líder vê o conteúdo da transação apenas depois que o prazo do ciclo termina. Isso é melhor do que visibilidade total, mas não satisfaz por completo a propriedade de ocultação de Garimidi et al., que exige que o conteúdo de uma transação permaneça invisível para todas as partes antes da confirmação. O propositor receptor ainda pode observar e explorar o conteúdo das transações que recebe.

A preocupação mais profunda com a Constellation é que MCP com envio público de transações pode ampliar a exploração baseada em conteúdo visível. Isso introduz um sistema no qual cada propositor observa as transações que recebe e pode explorar essa visibilidade dentro de sua própria pslice. A superfície de ataque difere daquela do modelo de líder único, pois várias entidades podem ver, cada uma, um subconjunto. Um usuário que envia para um único propositor expõe sua transação apenas a esse propositor. Mas um usuário que envia para vários propositores em busca de redundância amplia proporcionalmente sua exposição. Landers e Marsh formalizam essa dinâmica: a produção concorrente de blocos cria jogos de timing, oportunidades de duplicação no mesmo tick e a ausência estrutural de um único ponto de estrangulamento no builder, que hoje limita o número de tentativas de extração que podem ser efetivadas por transação da vítima. Descentralizar o conjunto de propositores sem resolver a visibilidade do conteúdo multiplica a superfície de ataque de MEV em vez de reduzi-la.

A análise de Landers e Marsh sobre canais de MEV específicos de MCP pressupõe uma visibilidade de conteúdo mais ampla do que a oferecida pela Constellation. Sob a ocultação parcial da Constellation, a ampliação da exploração baseada em conteúdo visível depende da estratégia de envio do usuário, em vez de ser uma inevitabilidade arquitetural. Um usuário que envia para um único propositor confiável tem praticamente o mesmo perfil de exposição de conteúdo do modelo atual de líder único. A contrapartida é que o envio para um único propositor sacrifica a redundância da qual depende a resistência à censura. 

Camada 3: manipulação de timing e latência

A camada mais sutil e mais difícil de punir diz respeito à manipulação de timing e latência. Na Constellation, um propositor pode atrasar o encaminhamento de pshreds aos atestadores apenas o suficiente para que a transação de um concorrente fique fora da janela de atestação, ou explorar desvios no relógio UTC para manipular quais transações acumulam atestações suficientes. Essa lacuna é reconhecida diretamente pelo whitepaper da Constellation: a entrega tardia de mensagens “não pode ser punida”, pois é indistinguível de um atraso genuíno da rede. É nessa camada que slashing pode se tornar relevante, além de ser a principal questão em aberto que o futuro SIMD da Constellation precisará resolver. 

Uma premissa fundamental por trás do design da Constellation é que a relação entre propositor e usuário não é anônima — trata-se de uma interação recorrente na qual a confiança pode ser medida e a reputação importa. Com aproximadamente 16 propositores ativos a qualquer momento, um usuário que recebe tratamento consistentemente ruim de um propositor pode começar a enviar para um dos outros 15. Embora isso não crie nenhum artefato onchain que possa ser usado para punir diretamente um agente mal-intencionado, cria consequências econômicas para propositores que exploram sua posição. Até que ponto essa pressão reputacional é suficiente para inibir a manipulação de timing, em comparação com uma solução como slashing, é uma questão em aberto que provavelmente dependerá de quão transparente o comportamento dos propositores se tornará para os usuários ao longo do tempo. 

Impacto sobre validadores e usuários

Validadores

A Constellation redistribui as oportunidades de MEV entre validadores, em vez de eliminá-las por completo. A fonte de receita mais evidente e diretamente extraível disponível hoje aos líderes (ou seja, censura rígida) torna-se impossível por design. Porém, ela é substituída por um conjunto de canais de timing mais sutis e difíceis de punir, que favorecem validadores com vantagens de latência, sincronização precisa de relógio e sofisticação para explorar de forma consistente as janelas de encaminhamento de pshreds. O efeito líquido é uma mudança na forma como os validadores extraem valor, não uma redução da superfície total de extração. A única ressalva é que a extração se torna significativamente mais difícil.

A Constellation não introduz fluxos de taxas fundamentalmente novos, mas reestrutura os existentes. A taxa de inclusão é análoga à taxa-base atual, e a taxa de ordenação corresponde à taxa de prioridade existente. Espera-se que as divisões sejam semelhantes ao que os validadores recebem hoje. A diferença é principalmente operacional. Ou seja, bons operadores devem obter mais taxas de inclusão como propositores, criando um gradiente baseado em desempenho dentro da economia existente, em vez de uma categoria de receita separada. A função de atestador não é remunerada separadamente no design atual. A justificativa é que, assim como a participação atual no Turbine, espera-se que ela seja desempenhada por ter um efeito líquido positivo para a rede. A mudança econômica mais significativa está na atividade que hoje passa por serviços de landing fora do protocolo, leilões baseados no mercado e acordos de taxas offchain, que deve retornar ao protocolo para beneficiar os validadores mais diretamente. Contudo, até que o SIMD especifique a mecânica exata, o impacto econômico líquido sobre validadores individuais — especialmente os menores, para os quais a seleção ponderada por stake reduz a frequência como propositor e o overhead de infraestrutura eleva o custo mínimo — continua sendo uma questão em aberto.

Propositores e atestadores são selecionados por peso de stake, o que significa que as mesmas dinâmicas de concentração que moldam a economia dos validadores também moldam a participação nessas funções. Se um pequeno número de validadores com alto stake dominar a seleção de propositores, a garantia de resistência à censura continuará formalmente intacta, mas a diversidade prática do conjunto de propositores diminuirá, embora ainda represente uma melhoria em relação ao que a Solana tem hoje (ou seja, n escolhe 1 versus n escolhe 16). Na prática, a premissa de independência começa a enfraquecer, mesmo que se sustente na teoria. Essa é uma preocupação que merece atenção diante do surgimento de ofertas de Validator-as-a-Service (VaaS), nas quais uma única entidade pode operar vários validadores com alto stake. Se o SIMD introduzirá mecanismos anticoncentração ou incentivos para a seleção de propositores é uma questão de design com implicações diretas para a robustez das garantias anunciadas pela Constellation. 

Usuários

Para os usuários, uma transação com taxa competitiva enviada a um número suficiente de propositores passa, pela primeira vez, a ser protegida por uma garantia rígida do protocolo contra exclusão seletiva. Agora, aplicações financeiras podem ser criadas com garantias que simplesmente não existiam antes, transformando o que só é possível na Solana. 

Usuários de alta frequência e sensíveis a preço agora precisam enviar transações a vários propositores para obter redundância. A preocupação é que descentralizar o conjunto de propositores sem resolver a visibilidade do conteúdo pode aumentar a exposição a ataques sanduíche — cada propositor pode observar e agir sobre as transações enviadas a ele, o que significa que usuários que enviam a vários propositores para obter redundância aumentam proporcionalmente o número de partes que veem o conteúdo de suas transações. Isso remove, por natureza, o ponto de estrangulamento do líder único e transmite a intenção da transação a um conjunto maior de adversários em potencial. Na prática, usuários mais sofisticados precisarão desenvolver novas estratégias de envio que equilibrem redundância e exposição, provavelmente envolvendo, por exemplo, o direcionamento seletivo a propositores com base em reputação ou stake, em vez de estratégias amplas de múltiplos envios.

Especificamente para formadores de mercado, a garantia de inclusão da Constellation elimina o risco adversarial de a infraestrutura determinar a qualidade da execução. O que resta é pura assimetria de informação, o mesmo perfil de risco que os formadores de mercado enfrentam hoje nos melhores ambientes tradicionais. Essa convergência é o que torna concreto, e não apenas aspiracional, o argumento favorável à inclusão e à redução da latência. Essa convergência é discutida em mais detalhes na seção “Questões em aberto”.

A mudança líquida na experiência percebida pelo usuário médio provavelmente será marginal, mas a garantia de inclusão representa uma melhoria relevante na confiabilidade. Enquanto aguardamos benchmarks futuros, o impacto líquido na latência de sequenciamento continua sendo uma questão empírica em aberto.

Panorama: como a Constellation se compara

Sei Giga

Sei Giga é o análogo mais próximo da Constellation no panorama atual de MCP. Ou seja, uma blockchain pronta para produção que trata MCP como prioridade arquitetural de primeira ordem, não como um objetivo de pesquisa futuro. Comparar as duas é instrutivo, pois elas fazem concessões diferentes na mesma camada.

A base de consenso da Giga se chama Autobahn, um protocolo BFT com múltiplos propositores no qual cada validador opera continuamente sua própria “pista” de propostas em paralelo. Em vez de depender de um único líder, cada node dissemina continuamente seu próprio stream de propostas de dados em pistas independentes, e a camada de consenso confirma periodicamente um “tip cut”, um snapshot compacto que agrega as propostas mais recentes de cada pista. Isso difere arquiteturalmente do modelo da Constellation, no qual aproximadamente 16 propositores selecionados operam em um ciclo fixo de 50ms. O modelo baseado em pistas da Autobahn permite que qualquer validador mantenha uma pista contínua de propostas, em vez de ser selecionado de um subconjunto rotativo e ponderado por stake, ampliando drasticamente a participação na produção de blocos.

A diferença mais relevante diz respeito à ordenação com conteúdo visível. A Autobahn viabiliza a execução assíncrona ao separar a ordenação das transações de sua execução, uma decisão de design que a Constellation adia. Como discutido na próxima seção, a execução assíncrona reduz a superfície de ataque da ordenação com conteúdo visível ao impedir que os propositores simulem resultados de execução com base em um estado final conhecido no momento da ordenação.

A Giga oferece resistência probabilística à censura, enquanto a Constellation fornece garantias estruturais. A premissa da Giga é que uma transação enviada a vários propositores é mais difícil de censurar, pois cada propositor opera com informações incompletas, e a utilidade da censura pode desaparecer se outro propositor incluir a transação no mesmo tick. Em comparação, um líder que exclui uma transação suficientemente atestada produz um bloco inválido na Constellation. A resistência probabilística eleva o custo da censura, enquanto a resistência estrutural torna a censura criptograficamente impossível. Para as aplicações financeiras que ambos os protocolos buscam viabilizar, a diferença importa. 

Vale ser transparente sobre a diferença de ambição entre os dois designs. A Constellation é uma especificação de protocolo que comprova propriedades de correção, define condições de falha, especifica limites de quórum e deve ser apresentada como proposta formal para uma rede de produção escalável com bilhões em valor em stake. O whitepaper da Sei Giga tem outra orientação, voltada a alegações de throughput e compatibilidade com EVM, tratando MEV e resistência à censura como benefícios emergentes da arquitetura de múltiplos propositores, em vez de garantias formalmente especificadas. A execução assíncrona aponta na direção certa, mas a Giga não oferece o mesmo nível de garantias formais que a Constellation em relação a restrições de ordenação, quóruns de atestadores ou condições de falha. Isso não é uma crítica às escolhas de sequenciamento da Giga, mas um reflexo de contextos distintos — a Constellation está sendo proposta sobre a blockchain de produção com o maior throughput do mundo, o que exige e entrega um padrão de especificação proporcionalmente mais alto.

O ideal acadêmico

A referência teórica para o design de MCP é Multiple Concurrent Proposers: Why and How (2025), de Garimidi e Neu, da a16z Crypto Research, e Max Resnick, da Anza. O artigo propõe um protocolo MCP com duas propriedades que, segundo os autores, qualquer design resistente à censura precisa satisfazer: resistência à censura seletiva e ocultação. A primeira garante que um adversário não possa atrasar transações seletivamente, enquanto a segunda garante que o conteúdo das transações permaneça invisível antes da confirmação. É o único design de MCP na literatura atual que alcança formalmente as duas propriedades ao mesmo tempo.

O mecanismo que viabiliza a ocultação é o HECC — Hiding Erasure-Correcting Code. Ele é parametrizado de modo que quaisquer T shreds não revelem nenhuma informação sobre o lote de transações subjacente, enquanto K + T shreds permitam a reconstrução completa. O detalhe crucial é que os relays transmitem seus shreds armazenados somente depois que o consenso confirma quais lotes estão incluídos. Isso impede qualquer observação do conteúdo das transações antes da confirmação, eliminando por completo a superfície de ataque da ordenação com conteúdo visível por meio de uma garantia baseada em teoria da informação. 

Ao mapear esse design de protocolo para o framework desenvolvido anteriormente, ele é o único que trata a Camada 1 com resistência estrutural à censura, a Camada 2 com ocultação e limita a Camada 3 graças às garantias de resistência à censura fornecidas pela ocultação. Nem a Constellation nem a Giga conseguem isso por completo.

O que torna essa comparação particularmente interessante é que Resnick, coautor do ideal teórico, também é coautor da Constellation, um protocolo que se afasta dele de forma consciente. Isso reflete uma avaliação deliberada de que o design completo baseado em HECC ainda não pode ser implantado em uma rede de produção na escala da Solana, e de que a resistência estrutural à censura é o problema mais urgente a resolver primeiro. O artigo serve como norte para a Constellation: uma especificação formal da direção que o protocolo está seguindo, mesmo que não possa entregar tudo de uma só vez. 

Ethereum Braid

Braid é a principal proposta de MCP da Ethereum, apresentada por Max Resnick, e está atualmente em avaliação como parte do roadmap Scourge da Ethereum, junto ao design concorrente de listas de inclusão FOCIL. Sua inclusão aqui tem menos relação com uma comparação técnica e mais com o contexto: todo o setor tenta resolver os mesmos problemas estruturais, mas a partir de pontos de partida diferentes.

A Braid implementa MCP permitindo que vários propositores criem blocos simultaneamente em chains paralelas dentro do mesmo slot, enquanto a camada de execução agrega, elimina duplicatas e ordena as transações de acordo com regras predeterminadas. Ela não introduz funções adicionais no protocolo. A diferença mais importante é que a segurança da Braid depende fortemente de mempools criptografados, tornando a ocultação um pré-requisito, e não algo a ser adiado. A Braid continua sendo uma proposta de pesquisa ainda não implantada, e a comunidade Ethereum ainda não chegou a um consenso sobre adotá-la em vez da FOCIL.

O que a Braid confirma, em última análise, é que o argumento estrutural a favor de MCP transcende qualquer chain específica. Também vale observar que Resnick trabalhou em três das quatro iniciativas desta seção, talvez o sinal mais claro de que a Constellation é fruto de uma reflexão contínua, rigorosa academicamente e aplicada em diferentes contextos sobre um problema que resiste a soluções fáceis.

Uma observação sobre PBS

Vale mencionar Proposer-Builder Separation (PBS) aqui como contraponto, não como um design comparável. Enquanto todas as iniciativas desta seção tentam restringir estruturalmente o monopólio temporário do líder, PBS o aceita e otimiza o sistema ao redor dele para redistribuir os ganhos de MEV. A Constellation é explicitamente incompatível com PBS — quando a autonomia do líder é restringida pelo registro de atestações, não resta nada para um builder especializado vender. O fato de PBS ter se tornado a principal mitigação de MEV na Ethereum, apesar de não fazer nada para reduzir o prejuízo aos usuários, é precisamente o modo de falha que MCP foi projetado para evitar.

O precedente fora do protocolo

Antes mesmo do lançamento da Constellation, o ecossistema da Solana já reproduz fora do protocolo alguns aspectos de MCP. A Harmonic, por exemplo, é uma camada aberta de agregação para construção de blocos que coleta e avalia continuamente propostas de blocos de vários builders independentes, apresentando-as aos validadores para seleção competitiva em tempo real. Isso não é MCP no sentido formal, pois não há resistência à censura imposta pelo protocolo, quórum de atestação nem restrição criptográfica à autonomia do líder. Porém, os validadores que executam a Harmonic já escolhem entre várias propostas concorrentes de blocos, o mecanismo central que MCP busca consolidar. Junto com a BAM, as duas representam a tentativa do ecossistema de resolver problemas de estrutura de mercado sem aguardar uma imposição no nível do protocolo. Esses sistemas fora do protocolo demonstram que a demanda por propriedades semelhantes às de MCP é real o bastante para que os builders não esperem pelo lançamento da Constellation.

Questões em aberto

O whitepaper da Constellation é uma especificação de protocolo. Ele comprova propriedades de correção sob as premissas declaradas e, corretamente, deixa todo o restante para depois, algo apropriado para uma proposta v0.9. O que segue não é uma lista de falhas da Constellation, mas um mapa do que seu futuro SIMD e suas próximas iterações precisarão abordar para levar MCP à Solana de forma eficaz. 

Essas questões não têm o mesmo grau de dificuldade. Algumas são trabalho de especificação: decisões de design que a Anza pode e deve resolver pelo processo normal de SIMD. Outras são problemas genuinamente em aberto que a comunidade mais ampla de pesquisa sobre MCP ainda não resolveu, mas dos quais precisamos estar cientes enquanto abrimos caminho para nos tornar a primeira blockchain em escala a implementar MCP. Nenhum SIMD, isoladamente, pode resolver esses problemas. A distinção importa porque confundir os dois pode tanto exagerar as lacunas da Constellation quanto subestimar o trabalho restante.

O trabalho direto do SIMD inclui:

• Distribuição de taxas: a divisão das taxas de prioridade entre propositores, atestadores e o conjunto mais amplo de validadores é descrita, mas não totalmente detalhada. O whitepaper afirma que as taxas de prioridade retornam ao ecossistema em proporção ao stake, mas o mecanismo exato de distribuição entre propositores, atestadores e validadores não está definido.
• Estrutura de recompensas dos validadores: como os propositores são remunerados em relação às recompensas existentes dos validadores e se a remoção das taxas de transações de voto na Alpenglow altera o cálculo para validadores menores.
• Sequenciamento da implantação: a Constellation depende da Alpenglow, prevista para o terceiro trimestre de 2026. O SIMD precisa especificar explicitamente essa dependência e abordar o que acontece durante a janela de transição da Alpenglow padrão para Constellation+Alpenglow. Há algum SIMD que deva chegar à mainnet primeiro como pré-requisito?
• Governança dos parâmetros das funções: a quantidade de propositores (p ≈ 16), a quantidade de atestadores (q ≈ 256), a duração do ciclo (△cycle = 50ms) e outros parâmetros da Tabela 1 do whitepaper da Constellation são apresentados apenas como sugestões. O SIMD precisa especificar como esses parâmetros devem ser definidos, governados e possivelmente alterados ao longo do tempo.

As questões mais difíceis (por exemplo, execução assíncrona, slashing e privacidade na camada de envio) são abordadas nas subseções a seguir. São questões nas quais a comunidade de pesquisa sobre MCP trabalha ativamente e que precisamos considerar, pois as escolhas de design da Constellation podem estreitar ou ampliar o caminho para determinadas soluções futuras.

Execução assíncrona

Na execução síncrona, um propositor que recebe uma transação em texto simples, ou que consegue decodificá-la antecipadamente em um modelo de envio ingênuo, conhece o conteúdo da transação e pode simular seu resultado. O propositor pode executar a transação sobre o estado atual para calcular exatamente qual será o resultado da execução, incluindo preços de swaps, alterações nos saldos das accounts e oportunidades de arbitragem subsequentes. É isso que torna os ataques sanduíche mecanicamente precisos. Os invasores podem identificar swaps grandes e calcular quanto é necessário para fazer front-running e maximizar seu lucro.

A execução assíncrona elimina a segunda metade dessa vantagem, mas somente quando combinada com MCP. Se o consenso confirmar a ordenação das transações antes da execução, um propositor que consegue ver o conteúdo da transação não pode simular os resultados da execução com base em um estado final conhecido, pois esse estado não existe no momento da ordenação. A vantagem informacional se reduz efetivamente de “sei o que esta transação faz e em qual ordem ela é executada” para “sei qual é esta transação, mas não o que ela fará em relação ao conjunto final ordenado”. Esse benefício depende de o propositor não controlar a ordenação final. Em um modelo de líder único, a execução assíncrona sozinha não oferece essa proteção, pois o líder ainda tem total autonomia sobre a ordenação e pode posicionar vantajosamente suas próprias transações, independentemente de quando a execução ocorrer. É a combinação de ordenação restrita e execução adiada que reduz a superfície de ataque.

Observe que a execução assíncrona não elimina completamente a Camada 2. Um propositor sofisticado ainda pode fazer inferências categóricas. Ou seja, ele ainda pode ver que uma transação interage com um pool de liquidez específico, por exemplo, e inferir sua provável direção sem conhecer o resultado exato. Isso aumenta significativamente a dificuldade das formas mais mecânicas e lucrativas de exploração e representa o caminho arquitetural mais claro para reduzir a Camada 2 sem exigir ocultação criptográfica na camada de consenso. Notavelmente, essa foi a abordagem escolhida pela Sei Giga, que trata a execução assíncrona como prioridade arquitetural de primeira ordem junto com MCP.

Isso levanta uma pergunta natural que merece reflexão: Por que a execução assíncrona não foi priorizada? Ela reduz a Camada 2 e poderia, em princípio, ter sido implementada como uma mudança delimitada na camada de execução, sem introduzir a complexidade adicional de MCP no protocolo (ou seja, novas funções de node, requisitos de sincronização de relógio UTC, um design de slashing ainda não resolvido e o dobro de overhead de shredding). 

O argumento mais forte para esse sequenciamento é que a execução assíncrona e MCP resolvem problemas diferentes. MCP fornece restrições estruturais de ordenação que a execução assíncrona sozinha não consegue oferecer — um validador que não consegue simular os resultados da execução, mas ainda pode ver o conteúdo da transação, consegue exercer autonomia sobre a ordenação dentro da janela permitida pelo protocolo. O argumento para priorizar MCP é que ele restringe estruturalmente a Camada 1, que representa a ameaça mais evidente e economicamente imediata. Adaptar a execução assíncrona ao modelo de execução síncrona existente da Solana, considerando suas premissas de composabilidade e arquitetura de programas, é um problema de engenharia mais difícil do que incorporá-la a uma nova chain desde o início. A Sei Giga tem o luxo de projetar para execução assíncrona desde o primeiro dia; a Solana, não. Essa assimetria prática pode ser tão importante quanto o argumento de prioridade teórica para explicar por que MCP foi priorizado. A arquitetura da Alpenglow também torna MCP mais viável do que teria sido com Tower BFT, algo que exploramos na subseção seguinte sobre complexidade do protocolo.

Se esse sequenciamento está correto é uma questão razoável ainda em aberto. A Constellation mantém intacta a Camada 2, o que é problemático diante dos novos vetores de ataque que MCP introduz na Camada 3. Isso, por sua vez, pode tornar os ataques da Camada 2 mais lucrativos, pois as duas superfícies de ataque são complementares. Por exemplo, um propositor que consegue ver uma grande transação em uma DEX pode atrasar seus pshreds para empurrá-la para fora da janela do lote atual enquanto faz front-running com sua própria transação na mesma janela. A visibilidade da Camada 2 e os jogos de timing da Camada 3 são armas integrantes da mesma superfície de ataque e só ficarão mais sofisticados conforme a Solana amadurecer.

Slashing

A imposição criptográfica funciona bem quando o comportamento indevido de um agente produz um artefato verificável (por exemplo, assinaturas conflitantes, falhas em verificações de validade ou compromissos comprovadamente malformados). A Constellation resolve de forma tão limpa as preocupações da Camada 1 relacionadas à resistência à censura porque um líder que exclui uma transação atestada produz um bloco inválido, e essa invalidade pode ser demonstrada matematicamente. Jogos de timing e manipulação de latência não produzem esse tipo de artefato. A dificuldade está no fato de que esse comportamento indevido é indistinguível de um atraso legítimo da rede quando cada ação é analisada isoladamente. O comportamento indevido existe como uma ausência, e isso não pode ser comprovado criptograficamente. A única ferramenta disponível é a dissuasão econômica, que exige slashing. 

O desafio do slashing é que, tradicionalmente, ele exige uma infração comprovável. Os mecanismos de testemunha de falha da Constellation tratam o caso em que um propositor que assina dois pshreds conflitantes pode ser identificado e excluído. Porém, a manipulação estratégica de latência não produz uma testemunha de falha. Não há equivocation, assinatura dupla nem vestígio onchain. Um propositor que simplesmente atrasa de forma consistente e seletiva o encaminhamento de pshreds por alguns milissegundos não deixa nada que possa ser punido com slashing. 

Se os pshreds de um propositor chegarem sistematicamente aos atestadores nos últimos milissegundos da janela do ciclo — ao longo de muitos ciclos, para transações que por acaso competem com os próprios envios do propositor —, um mecanismo de slashing bem especificado poderia tratar esse padrão como evidência de manipulação sistemática sem que exista um único ato comprovadamente malicioso. O slashing tradicional não pode resolver isso diretamente. Em sua forma canônica, slashing exige uma prova inequívoca e autocontida, e não existe tal prova para um propositor que simplesmente atrasou o encaminhamento por alguns milissegundos. O que muda é o padrão.

É aqui que as finanças tradicionais podem, de fato, oferecer lições às finanças descentralizadas sobre a abordagem dos reguladores à manipulação baseada em latência. A fiscalização de spoofing conforme a Lei Dodd-Frank, por exemplo, se baseia na detecção de padrões estatísticos (como proporções entre cancelamentos e execuções, distribuições do timing de cancelamentos e correlações de impacto sobre preços), em vez de provar a intenção por trás de cada ordem individual. Nenhuma ocorrência isolada é comprovadamente intencional. Porém, o padrão é. A mesma lógica se aplica porque a regularidade estatística é objetiva, mesmo quando os atos individuais não são. Além disso, o incentivo econômico para manipular existe tanto em conjuntos permissionless de propositores quanto entre traders de alta frequência nas finanças tradicionais. A analogia deixa de funcionar na aplicação das regras. Ou seja, a Dodd-Frank depende de um regulador com poder de intimação, enquanto um contexto trustless exige que os mecanismos de detecção e penalidade sejam incorporados ao próprio protocolo.

Propomos adaptar fisherman nodes como possível mecanismo para resolver essa lacuna. Apresentados originalmente na pesquisa de Vitalik sobre disponibilidade de dados, fisherman nodes poderiam ser adaptados como uma classe de observadores que monitoram dados de atestação ao longo de muitos ciclos e enviam provas estatísticas de fraude a um protocolo de arbitragem incorporado. Uma chegada tardia individual é subjetiva. Porém, o padrão calculado de forma determinística ao longo de n ciclos é objetivo. Essa é a mesma ideia que fundamenta as provas de fraude em optimistic rollups, mas aplicada ao comportamento de timing em vez de transições de estado. Além disso, um protocolo de arbitragem incorporado para provas estatísticas de fraude não é categoricamente diferente das novas ferramentas de governança atualmente em desenvolvimento, que permitiriam aos stakers substituir os votos de seus validadores em futuras propostas de governança. Se a Solana estiver preparada para ter infraestrutura que permita aos stakers substituir votos, as bases técnicas de um sistema de arbitragem baseado em fisherman podem estar mais próximas do que parecem.

Essa investigação sobre fisherman nodes representa uma direção mais plausível do que ampliar o slashing canônico para abranger atos que não deixam um único vestígio onchain, e uma direção que o atual desenvolvimento da infraestrutura de governança do protocolo talvez já esteja preparado para sustentar. Ainda assim, qualquer especificação concreta precisaria resolver três limitações. Primeiro, realizar uma análise estatística dos dados de timing de atestações ao longo de milhares de ciclos não é trivial e poderia facilmente elevar os requisitos de hardware dos validadores. Isso aumenta os custos operacionais e cria a possibilidade de a função de detecção de fraudes se concentrar em um grupo seleto de agentes sofisticados. Segundo, qualquer especificação de limites precisa ser robusta o suficiente para distinguir a variação genuína da rede da manipulação estratégica, sem ser excessivamente conservadora a ponto de gerar falsos positivos. Terceiro, o próprio protocolo de arbitragem introduz uma nova superfície de ataque pela qual esse novo sistema baseado em fisherman poderia ser manipulado por meio de denúncias coordenadas. O design de qualquer protocolo de arbitragem precisaria considerar isso, possivelmente com mecanismos de incentivo que tornem a operação de fisherman viável para participantes menores ou com esquemas de agregação que distribuam o processamento pelo conjunto de fisherman.

A pergunta concreta de pesquisa que propomos é: pode-se especificar um framework de provas estatísticas de fraude — definindo parâmetros de limite, considerando a variação da rede e determinando como as penalidades escalam — que seja ao mesmo tempo robusto o suficiente para inibir a manipulação sistêmica de latência, conservador o suficiente para evitar penalizar variações legítimas e simples o bastante para resistir à manipulação adversarial por operadores sofisticados? Esse está entre os problemas em aberto mais exigentes tecnicamente na literatura sobre MCP, e a comunidade de pesquisa mais ampla ainda não o resolveu.

Ocultação

Slashing não é a única solução para jogos de manipulação de timing e latência. A ocultação resolve tanto os problemas de ordenação com conteúdo visível quanto os de manipulação de timing e latência, algo que nem a execução assíncrona nem slashing conseguem fazer isoladamente. A Constellation implementa ocultação parcial (ou seja, o conteúdo da transação fica visível apenas para o(s) propositor(es) receptor(es) e para o líder após o prazo do ciclo), mas não alcança a propriedade de ocultação completa. A superfície de ataque cresce com o número de propositores aos quais o usuário decide enviar. Embora essa ocultação parcial reduza a superfície de ataque em relação à visibilidade total, ela não a elimina. A ocultação completa, na qual nenhuma parte observa o conteúdo da transação antes da confirmação, continua sendo um problema em aberto para a Constellation.

O ideal teórico é a abordagem descrita por Garimidi et al., que usa Hiding Erasure-Correcting Code (HECC) como primitiva. Ao contrário do Reed-Solomon padrão da Constellation, HECC fornece uma garantia baseada em teoria da informação de que um adversário que coleta menos shreds do que o limite não descobre nada sobre o conteúdo das transações. A Constellation optou por continuar usando a codificação de apagamento atualmente ativa na Solana por meio do Turbine.

O desenvolvimento recente mais relevante é o Block Assembly Marketplace (BAM) da Jito, que usa Trusted Execution Environments (TEEs) para criar um mempool criptografado no qual as transações permanecem privadas até a execução. A BAM demonstra que há uma demanda concreta e crescente por privacidade de conteúdo na Solana. Porém, a ocultação baseada em TEE tem limitações e transfere as premissas de confiança para fabricantes de hardware, uma restrição relevante para um protocolo que busca operar de forma trustless. Um caminho futuro no qual a criptografia de limiar seja usada para oferecer uma alternativa com bases mais sólidas deve ser explorado em profundidade.

A BAM é importante por representar uma tentativa fora do protocolo de resolver o problema de visibilidade do conteúdo que a Constellation deixa para depois. A Jito está operacionalmente posicionada para fornecer privacidade de transações em escala via BAM antes mesmo do lançamento da Constellation. Isso levanta a questão de se a ocultação no nível do protocolo continua sendo urgente quando uma solução na camada de aplicação já pode oferecê-la. A resposta depende totalmente das premissas de confiança e de os fabricantes de hardware serem considerados confiáveis “o suficiente” em comparação com o que o protocolo poderia, em tese, garantir. Ainda assim, isso não pode ser tratado como uma solução permanente. O caminho provável é que a BAM forneça privacidade no curto prazo, enquanto futuras iterações da Constellation explorem a criptografia de limiar como alternativa de longo prazo.

Para um protocolo que busca ser a infraestrutura dos Mercados de Capitais da Internet, a ocultação parcial é um avanço significativo, mas não é o destino final. A lacuna restante é a diferença entre uma estrutura de mercado justa e outra que é apenas menos injusta do que a existente hoje. 

Complexidade do protocolo

A Constellation é a atualização estruturalmente mais ambiciosa proposta para a Solana desde sua criação. Ela introduz três novas funções de node, um novo modelo de timing que depende da sincronização do relógio UTC, novas etapas de codificação de apagamento, novos tipos de mensagem e novos modos de falha, tudo sobre a Alpenglow, que ainda não está ativa na mainnet. A questão de este ser o momento certo para assumir essa complexidade é séria e exige mais do que mero otimismo.

No passado, a Solana conquistou uma reputação notória pelas várias interrupções que afetaram a rede durante 2021 e 2022. Essas interrupções compartilham um tema: foram causadas pela dificuldade inerente de raciocinar sobre casos extremos em um protocolo inovador e de alto throughput sob condições reais de carga. Os mais de dois anos de disponibilidade ininterrupta que a rede alcançou desde então são um marco genuíno, forjado nas dificuldades da iteração. Esse histórico sustenta a confiança na maturidade da Solana. 

Agora, qualquer mudança no nível do protocolo da magnitude da Constellation exige implementação simultânea tanto no Agave quanto no Firedancer. Isso exige alinhamento entre duas equipes independentes de desenvolvimento sobre semântica do protocolo, casos extremos e premissas de timing que são novas para ambas. A complexidade de fazer isso apenas para a Alpenglow já é significativa, e a Constellation só irá ampliá-la. Isso não é um argumento contra prosseguir. É, na verdade, um argumento de que o futuro SIMD da Constellation precisa incluir um plano claro para implementação com múltiplos clientes.

Instituições financeiras estão começando a migrar para onchain. Os riscos de uma interrupção significativa são materialmente maiores do que em 2021, tanto em termos de danos reputacionais quanto econômicos. Nós, como comunidade, precisamos ser francos sobre a complexidade introduzida pela Constellation. O futuro SIMD precisa ser abordado com o rigor que um sistema financeiro global exige. 

Naturalmente, surge a pergunta: por que agora? Queremos mesmo assumir o risco de uma atualização desse porte? Não existem atualizações incrementais que poderíamos fazer ao longo do tempo para suavizar essa mudança? As explorações mencionadas sobre execução assíncrona e slashing, por exemplo, sugerem que uma alternativa incremental é possível. É possível imaginar uma versão do roadmap da Constellation na qual o ecossistema se beneficie de implantações em etapas de várias atualizações complementares. Se isso será visto como prudência ou desaceleracionismo é uma questão tanto de valores quanto técnica, e pessoas razoáveis podem discordar. Estamos construindo tanto um sistema de significado quanto um sistema para finanças.

Isso já acontece na prática. A Anza confirmou que slots de 200ms e janelas de liderança de dois slots serão lançados antes da Constellation. Isso significa que a Solana terá melhorias relevantes de desempenho que resolvem parte das preocupações sobre latência de sequenciamento levantadas pela comunidade, tema que discutiremos na próxima seção, sem exigir toda a complexidade de MCP. Se slots de 200ms aproximarem o caminho de confirmação da Solana o suficiente do overhead projetado da Constellation para que o custo marginal de MCP seja pequeno, o argumento político se tornará consideravelmente mais fácil de defender. Porém, se os participantes dominantes do mercado atual considerarem 200ms “bom o suficiente”, a urgência da Constellation diminuirá. Projeções comparativas de latência que mostrem slots de 200ms versus slots de 200ms com Constellation podem ajudar a comunidade a avaliar o custo incremental em relação à garantia incremental. Naturalmente, teremos de aguardar o futuro SIMD e a implementação proposta da Constellation.

O argumento mais forte para prosseguir é a oportunidade criada pela Alpenglow. A Constellation herda o modelo de segurança da Alpenglow, usa Rotor como sua camada de disseminação de dados e se beneficia da remoção da complexidade da Tower BFT. O custo marginal de adicionar MCP sobre a Alpenglow é menor do que o custo de começar do zero com um futuro design de consenso. Esperar não é gratuito, considerando as explorações dos concorrentes para levar MCP onchain e o fato de que adiar a resistência à censura para um futuro ciclo de atualização inevitavelmente trará sua própria complexidade e obstáculos políticos.

Se não agora, quando?

A complexidade é justificável, mas essa justificativa precisa ser conquistada por meio de uma especificação rigorosa, implantações em etapas e validação empírica das alegações sobre latência e largura de banda que a comunidade debate hoje apenas com base na teoria. 

A Constellation está alinhada à IBRL?

Latência de sequenciamento versus latência de inclusão

A reação inicial da comunidade Solana à Constellation foi, no mínimo, polarizada. Essa reação trouxe à tona um debate importante que merece uma resposta precisa, não diplomática. A formulação mais incisiva veio do tweet de Cavey, afirmando que “MCP e IBRL são fundamentalmente incompatíveis”. Ele argumenta que MCP reduz direta e indiscutivelmente a largura de banda e aumenta a latência na tentativa de melhorar a estrutura do mercado. A resposta de Toly foi igualmente direta: “Você está errado. Não há como reduzir a latência de inclusão sem MCP.”

Tecnicamente, ambos estão corretos; eles estão medindo coisas diferentes.

MCP reduz a latência de inclusão e aumenta a latência de sequenciamento. Elas não são a mesma propriedade, e confundi-las é a origem da maior parte da confusão no debate atual.

Latência de sequenciamento é o tempo entre o envio de uma transação e sua execução. Ela aumenta inerentemente com MCP, pois a rodada de atestadores, a janela de ciclo de 50ms e a etapa de montagem do lote acrescentam tempo que não existe no caminho atual de envio pela TPU a um líder cooperativo. A crítica de que agentes racionais que enviam a vários propositores consomem mais largura de banda está correta. A janela de coalescência adicionar latência também está correto. Todos esses são custos reais que devem ser medidos e apresentados à comunidade como contrapartidas pela eliminação da censura rígida.

Latência de inclusão é a janela de tempo garantida na qual uma transação válida e com taxa competitiva será incluída. Essa garantia é essencialmente ilimitada no modelo atual de líder único. Ou seja, um líder que queira atrasar ou excluir determinada transação pode fazê-lo, e não há nenhum mecanismo no protocolo que impeça isso. A latência que os usuários já enfrentam inclui todo o atrito causado por retenção, agendamento e jogos de timing, além da ordenação seletiva imposta pelos líderes. O contraponto de que os tempos de confirmação no mundo real incluem a latência causada por esses jogos e, portanto, a experiência líquida do usuário poderia melhorar é coerente com esse enquadramento e encontra respaldo nas discussões da comunidade que ocorrem atualmente no X. 

A verdadeira questão é qual latência otimizar.

FIFO versus FCFS versus FBO

Antes de analisar qual latência deve ser otimizada, vale entender um debate relacionado que a comunidade vem conduzindo simultaneamente: se MCP é compatível com FIFO.

FIFO (First In, First Out) é um princípio geral de ordenação em que as transações são processadas na ordem em que chegam. Umberto argumentou extensamente que a resposta é inerentemente cheia de nuances. O MCP pode produzir o chamado “FIFO probabilístico”, mas apenas sob condições específicas de infraestrutura. Essencialmente, se um usuário estiver geograficamente próximo de proponentes suficientes para evitar censura, e esses proponentes estiverem próximos o bastante dos atestadores para atingir rapidamente o limite de 40% de atestação que garante a inclusão, então, na prática, o usuário terá uma experiência de inclusão FIFO. Ou seja, sua transação será incluída antes que qualquer concorrente tenha tempo de observá-la e reagir a ela. A disputa termina na inclusão, e não na execução. Nessas condições, o MCP se aproxima do FIFO como uma propriedade emergente, e não como uma regra do protocolo.

O problema é que a infraestrutura atual da Solana não atende a essas condições. O stake está concentrado em poucas regiões, o que faz com que a formação de quórum fique limitada pela necessidade de alcançar bolsões densos de stake. Essa concentração cria uma janela na qual um observador “geograficamente favorecido” pode executar frontrunning contra uma transação em trânsito. Saber se a implantação da Constellation será acompanhada pela distribuição geográfica e pela densidade de atestadores exigidas pelo FIFO probabilístico é tão importante quanto o próprio design do protocolo. Um protocolo que garanta resistência à censura, mas permita frontrunning baseado em latência devido a uma infraestrutura geograficamente dispersa e escassa, não oferecerá a equidade de mercado prometida em seu whitepaper.

Uma questão relacionada, mas distinta, é se a Constellation poderia ter implementado FCFS, mas optou por não fazê-lo. Enquanto o FIFO é uma propriedade emergente da infraestrutura, o FCFS (First Come, First Served) é uma regra específica do protocolo que garante que a primeira transação a chegar seja processada de forma determinística. Vale observar que a Constellation de fato ordena de forma determinística — as transações são classificadas pela taxa de prioridade dentro de cada lote —, portanto, a questão não é se a ordenação é imposta pelo protocolo, mas se o horário de chegada deve determinar essa ordenação em relação às taxas de prioridade.

Um debate recente levantou uma objeção mais fundamental do que a apresentada inicialmente: o FCFS pode ser completamente inaplicável em um contexto trustless. Os validadores podem simplesmente representar de forma incorreta a ordem de chegada das transações sem deixar nenhum artefato onchain. Esse é o mesmo problema de ausência de evidências que torna a manipulação de tempo não passível de slashing no sentido tradicional e pode exigir soluções mais criativas, como a abordagem de detecção de padrões estatísticos desenvolvida na subseção sobre slashing. Uma regra de protocolo que validadores honestos seguiriam e que validadores desonestos poderiam ignorar silenciosamente não constitui uma garantia significativa. Isso reformula a omissão do FCFS pela Constellation: em vez de uma preferência de design que exige explicação, ela passa a ser o reconhecimento de que, em um conjunto de validadores permissionless, o FCFS talvez ainda não possa ser implementado na Solana como uma propriedade rígida do protocolo, pelo menos sob as premissas atuais. Se o FCFS for de fato inaplicável em um conjunto de validadores permissionless sob as premissas atuais, a tarefa do SIMD será declarar explicitamente essa limitação e justificar a ordenação por taxa de prioridade como o padrão de design correto. Deixar que a comunidade debata o FCFS como se fosse uma alternativa viável que a Constellation optou por não implementar, em vez de apresentá-lo como uma propriedade que talvez não possa ser implementada, gerará ainda mais atrito na comunidade.

A ordenação por taxa de prioridade em um intervalo fixo não é uma solução de compromisso nova. Ela é conhecida como leilão frequente em lotes (FBA), um design de microestrutura de mercado com amplo respaldo acadêmico. Budish, Cramton e Shim, por exemplo, argumentam em A corrida armamentista do trading de alta frequência: leilões frequentes em lotes como resposta de design de mercado (2015) que leilões em lotes de tempo discreto com preços uniformes de liquidação eliminam a corrida por velocidade criada pelos mercados de tempo contínuo. Isso substitui a concorrência baseada em latência pela concorrência baseada em preço. A Constellation parte desse conceito para introduzir o Fixed Batch Ordering (FBO) com base nas taxas de prioridade. Assim, o ciclo de 50 ms da Constellation implementa esse modelo: as transações competem por taxas, e não pelo horário de chegada dentro de cada lote, e todas as transações no mesmo lote recebem o mesmo tratamento de ordenação. Essa é precisamente a classe de aplicações identificada anteriormente como ainda inexistente em escala na Solana. 

Os debates sobre FIFO, FCFS e FBO tratam, em grande parte, da mesma questão subjacente: quem controla a ordenação depois que a resistência à censura é garantida e se a estrutura de mercado que a Constellation busca criar é realmente justa ou apenas menos injusta do que a existente hoje. A Constellation elimina a forma mais evidente de manipulação. O que a substituirá dependerá das decisões que o whitepaper deixa para o SIMD.     

Então, para o que estamos otimizando?

A latência de sequenciamento é mais importante para as aplicações de trading existentes, como AMMs, mesas proprietárias e CLOBs. Essas aplicações são projetadas com base na premissa de que vence quem for mais rápido e competitivo nas taxas, e elas construíram sua infraestrutura de acordo com isso. O trading deve estar limitado apenas pelas leis da física, proporcionando uma experiência de usuário incomparável na Solana. Para alguns desses usuários, a Constellation representa um retrocesso na métrica que mais importa para eles. A preocupação é que a Solana possa estar cometendo o mesmo erro fatal que a Ethereum cometeu no passado: priorizar a estrutura de mercado em detrimento do desempenho, o que poderia fazer com que a execução deixasse a blockchain. Esse é um risco legítimo que merece ser discutido.

Para as aplicações financeiras que a Constellation foi projetada para viabilizar, como leilões onchain, livros de ordens com garantias confiáveis de inclusão e protocolos DeFi resistentes à censura, a latência de inclusão é a métrica correta. Uma ordem limitada que pode sofrer frontrunning ou ser atrasada seletivamente oferece garantias mais fracas do que uma ordem em uma exchange, independentemente da rapidez nominal da confirmação. Agora, a Solana pode comportar aplicações de trading baseadas em leilões em lotes com preços uniformes de liquidação, nas quais o sequenciamento não deveria afetar o preço de execução. Essa é uma classe de aplicações que, em grande parte, não existe hoje na Solana, justamente porque não há garantias de inclusão. Pode-se argumentar que a Constellation dá peso excessivo a um design otimizado para usuários que ainda não existem em escala na Solana, em detrimento dos usuários que já existem; um argumento que já está sendo apresentado por colaboradores centrais.   

A preocupação com a latência de sequenciamento deve ser contextualizada pelo fato de que a Solana está atualmente perdendo espaço relevante no trading de contratos perpétuos para a Hyperliquid — uma exchange de perps com sequenciador centralizado e criada especificamente para esse fim, que não tenta parecer descentralizada, mas oferece uma experiência de execução atraente abaixo de um milissegundo, exigida por traders e aplicações sofisticados. A Hyperliquid tomou a decisão deliberada de criar um produto que profissionais realmente querem usar, sacrificando princípios fundamentais do que de fato torna as criptomoedas “cripto”. O risco implícito da Constellation é que adicionar sobrecarga de comunicação e rodadas de atestação ao caminho de confirmação representa a mesma escolha feita pela Hyperliquid, mas na direção errada. Os críticos veem de forma negativa o sacrifício de qualquer possível vantagem de desempenho que hoje torna a Solana competitiva com aplicações centralizadas de trading, sem que ainda existam aplicações financeiras que justifiquem essa troca, e expressam essa opinião com bastante veemência.

Essa não é uma preocupação que deva ser descartada tão facilmente. Podemos reformular nossa pergunta anterior sobre se devemos otimizar a latência de sequenciamento ou de inclusão: considerando de onde vem a concorrência atual, a Solana pode se dar ao luxo de fazer essa troca?

No entanto, há uma questão mais profunda. A comparação com a Hyperliquid esclarece que o significado de IBRL pode ter mudado ao longo do tempo. A motivação original de Toly e Raj para criar a Solana era a resistência à censura: “Para permitir que produtos DeFi atraiam bilhões de usuários e dispositivos, precisamos escalar a resistência à censura… Esse é o problema mais importante a ser resolvido e toda a nossa motivação para criar a Solana.” O IBRL surgiu muito mais tarde como a formulação de engenharia dessa missão: construir algo rápido o bastante para que uma rede descentralizada pudesse superar uma infraestrutura centralizada nas métricas que importam. Desde então, o IBRL adquiriu um significado tecno-otimista próprio e se tornou onipresente no zeitgeist cultural da Solana. Ele é, em partes iguais, um imperativo de engenharia, um marcador cultural e uma oração secular. Para muitos, ele se tornou o objetivo, e não o meio, com a minimização da latência de sequenciamento como um fim em si mesma, dissociada do objetivo de resistência à censura ao qual deveria servir.

Se esse desvio ocorreu, como tudo indica, a Constellation enfrentará forte resistência cultural. Essa dinâmica não é nova, considerando que a comunidade rejeitou o SIMD-228, uma proposta controversa de redução da inflação que não foi aprovada na votação de governança. Até mesmo as propostas com benefícios mais amplos podem fracassar quando entram em conflito com convicções consolidadas da comunidade. A Constellation é mais complexa porque seus custos de largura de banda e latência são reais, mas o efeito líquido deles sobre a experiência do usuário ainda não foi quantificado. É prematuro chegar a conclusões definitivas em qualquer direção sem os dados. O que falta à comunidade, e o que a Anza precisará fornecer para apresentar um SIMD convincente, são dados empíricos sobre como será o caminho de confirmação em condições realistas de rede. A Alpenglow não enfrentou esse problema por estar alinhada ao IBRL: uma redução de 100 vezes no tempo até a finalidade das transações e um consenso simplificado. É mais difícil defender a Constellation de forma intuitiva, mas os benefícios não serão menos reais se benchmarks futuros os confirmarem.

Tudo indica que a comunidade avaliará uma atualização resistente à censura com base em uma métrica de desempenho para a qual ela nunca foi projetada. A pergunta mais produtiva é se essa troca vale a pena. Há um custo real e mensurável: alguma latência adicional de sequenciamento e maior uso de largura de banda em troca de uma garantia rígida, imposta pelo protocolo, de que nenhum líder possa excluir seletivamente uma transação. Esse é um pré-requisito para as aplicações financeiras que a Solana busca atrair atualmente.

Nossa visão é que a Constellation está alinhada ao IBRL sob a interpretação correta do objetivo que o IBRL sempre pretendeu alcançar. Se a comunidade chegará à mesma conclusão dependerá menos dos méritos técnicos e mais da apresentação das evidências empíricas e da explicação das decisões de design.  

Conclusão

A Constellation é a primeira proposta formal no nível do protocolo a levar o MCP a uma blockchain de produção em escala. Ela resolve estruturalmente a censura rígida, de modo que transações competitivas em taxas e atestadas por um quórum suficiente não possam ser excluídas de um bloco válido. Essa garantia criptográfica muda o que pode ser criado na Solana. 

O que a Constellation deliberadamente deixa para depois é igualmente importante. A ordenação com conteúdo visível é parcialmente mitigada pelo modelo de envio da Constellation, no qual apenas o proponente que recebe a transação vê seu conteúdo, mas a superfície de ataque residual cresce de acordo com o número de proponentes aos quais o usuário a envia. A manipulação de tempo e latência continua sendo o maior problema sem solução e, no design atual, não pode ser punida. Os possíveis caminhos, como execução assíncrona, slashing e ocultação, são identificados, mas não especificados, e cada um introduz suas próprias complexidades. O whitepaper da Constellation é transparente sobre esses limites, e seu futuro SIMD deve ser igualmente transparente.

A pergunta mais difícil levantada pela Constellation é se a Solana pode se dar ao luxo de aceitar as concessões que ela introduz. Há um custo real e mensurável na latência de sequenciamento e na largura de banda, que ainda precisa ser quantificado. Da mesma forma, há um benefício real, mas ainda não mensurado, nas garantias de inclusão, que ainda não contam com uma base de aplicações que as justifique em escala. A comunidade está sendo convidada a investir em infraestrutura para aplicações financeiras que, em grande parte, não existem hoje na Solana, possivelmente em detrimento das aplicações de trading que já existem. Se isso é visionário ou prematuro depende de dados que a comunidade ainda não possui.

O futuro da Constellation dependerá, em última análise, de seus benchmarks empíricos futuros em condições realistas. Comparar como será o caminho de confirmação apenas com slots de 200 ms e com slots de 200 ms sob a Constellation é o dado mais importante que a Anza pode fornecer. Até lá, a comunidade continuará debatendo concessões que não consegue quantificar.

Nossa visão é que a Constellation representa o próximo passo correto no roadmap do protocolo aberto pela Alpenglow. Ela está alinhada ao IBRL segundo a interpretação para a qual a Solana foi criada originalmente. No entanto, essa visão depende de o SIMD demonstrar o rigor exigido por um sistema financeiro global — em sua especificação, implantação em etapas, testes e nas evidências empíricas apresentadas à comunidade cuja adoção ele solicita.

Recursos adicionais

• Budish, E., Cramton, P., e Shim, J. (2015). A corrida armamentista do trading de alta frequência: leilões frequentes em lotes como resposta de design de mercado. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0: frontrunning, reordenação de transações e instabilidade de consenso em exchanges descentralizadas. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., e Clark, J. (2019). SoK: desonestidade transparente: ataques de front-running em blockchain. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., e Resnick, M. (2025). Múltiplos proponentes simultâneos: por quê e como. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., e Wattenhofer, R. (2026). Solana Constellation: mercados de capitais da internet. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. e Marsh, B. (2025). MEV em blockchains com múltiplos proponentes simultâneos. https://arxiv.org/abs/2511.13080
• Yakovenko, T., e Gokal, R. Desenvolvedores de blockchain estão focados no problema errado. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem