A verdade sobre os mercados de taxas locais da Solana

Insights práticos

• Os mercados de taxas locais (LFMs) permitem que a Solana defina taxas granulares para partes individuais do estado com base no nível de contenção. As transações pagam taxas de acordo com o estado específico no qual gravam, evitando que pontos de alta demanda localizados aumentem as taxas em toda a blockchain. 
• Os LFMs são essenciais para concretizar a visão da Solana de uma camada base unificada e escalável, na qual todas as aplicações coexistam sem atritos. Sem LFMs, picos de taxas em uma parte da blockchain aumentam as taxas de todas as transações — um problema comum em outras redes que dependem apenas de mercados globais de taxas para precificar o espaço de bloco.
• Quando a atividade econômica na Solana começou a acelerar no fim de 2023, várias falhas críticas na implementação original dos LFMs ficaram evidentes. A mais notável era a priorização não determinística do escalonador. As transações eram ordenadas principalmente pelo momento de chegada ao produtor do bloco, e as taxas de prioridade eram apenas um critério secundário.
• Com a atualização v1.18 do cliente Agave, em maio de 2024, foram introduzidos um novo escalonador de transações e uma fórmula refinada de prioridade de transações. O escalonador cria um grafo de dependências para gerenciar melhor o processamento e a priorização de transações conflitantes entre threads. Essa grande atualização melhorou significativamente a capacidade do protocolo de ordenar transações de forma determinística.
• Uma métrica útil para avaliar LFMs que funcionam de maneira eficaz é a comparação entre a mediana e a média das taxas de prioridade das transações. Espera-se que as taxas envolvendo estados sem contenção (mediana do 50º percentil) permaneçam baixas. As taxas para estados com contenção devem disparar conforme a demanda aumenta, elevando a média. Dados recentes confirmam esse padrão. Em novembro de 2024, as taxas médias de transações sem voto atingiram o recorde histórico de mais de 0,0003 SOL. No entanto, as taxas medianas permaneceram estáveis em 0,00000861 SOL, cerca de 35 vezes menores.
• Hoje, os LFMs da Solana estão funcionais, mas ainda há bastante espaço para melhorias. Uma análise das cargas de trabalho das threads do estágio bancário, realizada por engenheiros da Anza, indica que um bug no escalonador impede o cliente validador de usar toda a sua capacidade. Como resultado, o cliente Agave opera com apenas uma fração de seu potencial. Além disso, não existe uma especificação formal para a ordenação das transações.
• As APIs atuais de taxas de prioridade não têm a sofisticação necessária para oferecer resultados determinísticos aos desenvolvedores. Cada grande provedor de RPC oferece sua própria API personalizada de taxas de prioridade, o que pode se tornar uma forma branda de dependência de fornecedor. A implementação principal e de código aberto da API RPC não considera dinâmicas críticas da rede, como a influência da Jito, resultando em estimativas de taxas imprecisas.
• Sem um método determinístico para calcular taxas de prioridade, os desenvolvedores costumam adotar uma abordagem cautelosa e pagar a mais para garantir que suas transações sejam processadas. Como alternativa, podem usar gorjetas da Jito em excesso, mesmo em transações nas quais não é necessário garantir o topo do bloco.
• Várias estratégias foram propostas para aprimorar ainda mais a estrutura de taxas da Solana. Entre elas estão taxas exponenciais de bloqueio de escrita e taxas-base dinâmicas. A rede ainda precisa descobrir como aplicar contrapressão econômica para desincentivar spam e, ao mesmo tempo, manter taxas baixas para usuários humanos legítimos.

Introdução

Mercados de taxas são mecanismos econômicos criados para alocar com eficiência o escasso espaço de bloco às transações de maior valor por meio do ajuste dinâmico das taxas de transação. A disposição de uma transação para pagar taxas funciona como uma aproximação de seu valor. Os LFMs refinam esse conceito geral ao definir taxas granulares para partes individuais do estado com base no nível de contenção. Duas transações são consideradas conflitantes quando acessam o mesmo estado — seja por duas escritas ou por uma leitura e uma escrita na mesma conta.

Com os LFMs, as transações pagam taxas de acordo com o estado específico no qual gravam, evitando que pontos de alta demanda localizados aumentem as taxas em toda a blockchain. Transações que acessam estados muito disputados ou com contenção pagam taxas maiores, enquanto aquelas que interagem com estados de menor demanda pagam taxas menores. Isso é importante porque a Solana processa melhor transações sem contenção graças à execução paralela.

Em comparação, os mercados globais de taxas aplicam um custo universal para acessar o estado da rede. Isso significa que todas as transações competem igualmente pela inclusão, independentemente das contas com as quais interagem. O modelo de taxas da Ethereum, implementado na EIP-1559, é um exemplo pertinente de mercado global de taxas. A EIP-1559 ajusta uma taxa-base dinâmica de acordo com a demanda da rede para manter o uso ideal de computação (gas) por bloco. Conforme a capacidade do bloco é preenchida, as taxas aumentam para todas as transações. As carteiras calculam as taxas com base na taxa-base atual e no limite de gas da transação. Essa abordagem é aplicada pelo protocolo e oferece cálculos de taxas previsíveis. No entanto, ela não consegue isolar da rede geral os pontos de alta demanda. Quando as taxas disparam, isso acontece para todas as transações.

A questão da alta demanda por partes específicas do estado não é exclusiva das blockchains. Esse desafio reflete o problema das chaves de alta demanda, muitas vezes chamado de "problema da celebridade", comum em aplicações sociais da Web2.

Com este artigo, buscamos oferecer uma análise acessível dos LFMs da Solana. O trabalho está dividido nas seguintes seções:

• Fundamentos das taxas da Solana: Apresenta aos leitores uma compreensão básica de como as transações são processadas atualmente na Solana.
• Problemas iniciais dos mercados de taxas locais: Explora os problemas iniciais das primeiras implementações dos LFMs e suas limitações.
• A atualização do escalonador central v1.18: Destaca uma atualização crucial de 2024 que melhorou significativamente a funcionalidade dos LFMs.
• Medição da eficácia dos mercados de taxas locais: Apresenta dados relevantes para compreender o estado dos LFMs em sua operação atual na Solana.
• Problemas persistentes e áreas para melhorias: Esta seção aborda problemas ainda não resolvidos e áreas que exigem atenção para que os LFMs alcancem todo o seu potencial.
• Soluções propostas: Analisa soluções propostas para aperfeiçoar os LFMs e introduzir melhores incentivos econômicos para uma precificação mais granular do espaço de bloco.

Quem já conhece as estruturas de taxas de transação da Solana pode pular a próxima seção sobre os fundamentos das taxas.

Fundamentos das taxas da Solana

As transações da Solana são compostas por duas taxas: a taxa-base e a taxa de prioridade. Atualmente, a taxa-base é fixa em 5.000 lamports por assinatura. A maioria das transações da Solana tem uma assinatura. A taxa de prioridade é denominada em microlamports (ou seja, um milionésimo de lamport) por unidade computacional (CU) solicitada. As taxas são debitadas da conta pagadora da taxa (o signatário). A transação é descartada se o pagador não tiver lamports suficientes para pagá-la. No momento da redação deste artigo, 50% da taxa-base e da taxa de prioridade ficam com o produtor do bloco como incentivo para incluir a transação no bloco. Os outros 50% são queimados. Após a aprovação em votação de governança da proposta SIMD-096 em maio do ano passado, isso mudará para que 100% das taxas de prioridade fiquem com o produtor do bloco. Por exemplo: 

Uma transação tem uma assinatura e solicita 500.000 CUs. O remetente define uma taxa de prioridade de 50.000 microlamports por CU solicitada. A taxa total da transação é de 5.000 lamports + (500.000 CUs solicitadas * 50.000 microlamports por CU solicitada) = 25.000 lamports, ou 0,000025 SOL.

Os validadores têm recursos computacionais finitos, e o protocolo limita o total de recursos computacionais por bloco a 48 milhões de CUs. Esse número foi escolhido empiricamente com base no volume que os validadores conseguem processar de forma razoável para atingir tempos de bloco de 400 milissegundos. O máximo de CUs por conta em cada bloco é limitado a 12 milhões, e o máximo de computação por transação é definido em 1,4 milhão de CUs. As mensagens de transação também têm o tamanho máximo limitado a 1.232 bytes, que corresponde à unidade mínima de transmissão do IPv6 (1.280 bytes) menos os cabeçalhos.

Para evitar o uso indevido de recursos computacionais, cada transação na Solana recebe um orçamento computacional. Por padrão, a rede define um limite máximo de 200.000 unidades computacionais (CU) por instrução. No entanto, as transações podem especificar um limite personalizado de unidades computacionais ao incluir uma instrução `SetComputeUnitLimit`, permitindo uma alocação mais eficiente de recursos. A base de código do cliente Agave lista os custos em CU de várias operações.

A Solana exige que todas as transações especifiquem uma lista completa dos endereços de contas que serão lidos ou gravados durante a transação. O tamanho máximo dessa lista é de 35 endereços e pode ser ampliado por meio de Address Lookup Tables on-chain. Criar listas de endereços gera trabalho adicional para os desenvolvedores, mas é essencial para viabilizar muitas das otimizações da Solana, incluindo a execução paralela de transações e os mercados de taxas locais.

Problemas iniciais dos mercados de taxas locais da Solana

Quando a atividade econômica na Solana começou a acelerar no fim de 2023, várias falhas críticas na implementação original dos LFMs ficaram evidentes. Nessa época, Eugene Chen, da Ellipsis Labs, apresentou uma análise abrangente desses desafios no artigo Solana Fees, Part 1, da Umbra Research. Veja abaixo um resumo dos principais pontos levantados por Chen.

Falta de incentivos para solicitar CUs com precisão

A estrutura de taxas da Solana cobra taxas-base por assinatura sem considerar as unidades computacionais (CUs) usadas ou solicitadas. Enquanto isso, as taxas de prioridade oferecem apenas um incentivo limitado para reduzir o uso de CUs durante períodos de congestionamento. Esse modelo dá aos remetentes das transações pouca motivação para otimizar o uso computacional ou adequar suas solicitações de CUs às necessidades reais. Consequentemente, as transações frequentemente solicitam CUs em excesso, gerando ineficiências no processo de escalonamento da rede.

Incentivos para usar mecanismos de prioridade fora do protocolo

A queima de 50% das taxas de prioridade incentiva os remetentes de transações a contornar o protocolo, fazendo acordos com produtores de blocos e organizando pagamentos off-chain em troca de acesso prioritário. Esse comportamento fica evidente no uso crescente dos leilões da Jito. Validadores que executam o cliente Jito-Agave se beneficiam de receitas maiores com taxas e podem distribuir esses lucros de forma eficiente aos stakers delegantes por meio das recompensas de comissão de MEV da Jito. Com a crescente adoção dos clientes Jito-Agave, os bundles da Jito se mostraram um serviço superior de entrega de transações em muitos cenários. 

Priorização não determinística do escalonador

Nem o consenso da Solana nem o escalonador impõem uma ordenação rígida das transações com base nas taxas de prioridade. As transações são ordenadas principalmente pelo momento de chegada ao produtor do bloco, e as taxas de prioridade são apenas um critério secundário. Taxas de prioridade maiores podem aumentar a probabilidade de inclusão em estados com contenção, mas o processo de ordenação continua não determinístico. A variação da rede antes de alcançar a unidade de processamento de transações (TPU) e a variação interna do escalonador geram ainda mais imprevisibilidade.

Essa falta de determinismo reduz a previsibilidade e a confiabilidade da execução das transações, levando os usuários a inundar a rede com spam de transações para aumentar suas chances de inclusão mais rápida. No entanto, elevar as taxas de prioridade gera retornos decrescentes acima de determinado limite, comprometendo sua eficácia como mecanismo para um melhor posicionamento das transações. O espaço de bloco compartilhado da Solana acabou sendo vítima de uma clássica "tragédia dos comuns". Agentes individuais, agindo em benefício próprio, contribuíram para o uso excessivo e a ineficiência desse recurso público.

A atualização do escalonador central v1.18

A implementação inicial do escalonador do cliente Agave oferecia apenas uma garantia limitada de que transações com taxas de prioridade altas teriam mais chances de inclusão em determinado bloco. A Unidade de Processamento de Transações (TPU) do líder opera com seis threads paralelas: quatro processam transações sem voto e duas são reservadas para transações de voto. Cada uma das quatro threads de transações sem voto mantém sua própria fila, na qual as transações recebidas aguardam o agrupamento em entradas para execução. Antes, as transações eram atribuídas aleatoriamente a essas threads, e as filas priorizavam pacotes de forma independente, sem conhecimento dos pacotes processados pelas outras threads.

Nesse sistema, cada thread percorre sua fila e tenta bloquear e executar transações. Quando uma thread conclui o ciclo atual, ela coleta pacotes adicionais e reinicia o processo. Essa estrutura dificulta o uso eficaz das taxas de prioridade. Por exemplo, enquanto uma transação de alta prioridade pode estar no início da fila de uma thread, outra thread pode processar simultaneamente uma transação com taxa de prioridade menor, envolvendo a mesma conta, a partir do fim de sua fila. As taxas de prioridade influenciavam a ordenação das transações apenas dentro de cada thread (intra-thread), e não entre todas as threads (inter-thread). Como resultado, cada fila aplicava um mecanismo híbrido de ordenação que combinava processamento por ordem de chegada (FIFO) com considerações sobre a taxa de prioridade. No entanto, nenhuma ordenação global era imposta entre as threads.

Quando uma thread se prepara para executar uma transação, primeiro precisa obter os bloqueios de conta necessários. Se os bloqueios de escrita necessários não estiverem disponíveis, a transação volta para a fila. A atribuição aleatória de transações às threads agrava esse problema, pois o mesmo tipo de transação pode ocupar posições diferentes no sistema de escalonamento multithread. Essa natureza estocástica do escalonador introduz variação, criando diferenças na posição que uma transação pode ocupar dentro de um bloco.

Com a atualização v1.18 do cliente Agave, em maio de 2024, surgiu um novo escalonador de transações, também conhecido como escalonador central. Nessa estrutura revisada, o escalonador central cria um grafo de dependências, conhecido como prio-graph, para gerenciar melhor o processamento e a priorização de transações conflitantes entre todas as threads. Essa grande atualização melhorou significativamente a capacidade da Solana de ordenar transações de forma determinística, aumentando a probabilidade de inclusão nos blocos para transações com taxas de prioridade maiores.

O prio-graph é um grafo acíclico direcionado (DAG) atualizado dinamicamente conforme novas transações são adicionadas. As transações são organizadas no grafo para formar cadeias de execução processadas em ordem de prioridade temporal. Para transações conflitantes, a taxa de prioridade determina a ordem de inserção. Essa abordagem minimiza a contenção de bloqueios, permite que lotes de transações sejam executados sem interrupções e reduz atrasos causados por conflitos de recursos. A verificação da pré-compilação das transações foi transferida para threads de trabalho a fim de melhorar o desempenho e permitir um processamento mais eficiente. 

O design atualizado do escalonador melhora significativamente a escalabilidade e a flexibilidade, permitindo possíveis aumentos no número de threads sem o risco de intensificar conflitos de bloqueio. Além disso, a abordagem de escalonamento centralizado melhorou a geração de recompensas, aumentando os ganhos de muitos operadores de validadores.

Para uma análise mais detalhada do escalonador central, consulte nosso artigo anterior no blog da Helius sobre a atualização 1.18 do Agave.

Cálculo de prioridade mais eficaz

Em conjunto com a atualização do escalonador, a fórmula de prioridade das transações foi refinada para favorecer transações com menor demanda computacional, beneficiando desenvolvedores e transações com uso mínimo de recursos. 

A fórmula revisada é:

Prioridade = (Taxa de prioridade * Unidades computacionais solicitadas) + Taxa-base / 

(1 + CUs de execução solicitadas + CUs de assinatura + CUs de bloqueio de escrita)

Esse novo cálculo considera todos os custos computacionais e operacionais associados a uma transação, garantindo que os níveis de prioridade representem com precisão o consumo real de recursos. Consequentemente, transferências simples de tokens ou transações nativas de SOL sem taxas de prioridade adicionais têm a garantia de um nível básico de prioridade na fila. Em transações mais complexas, os desenvolvedores que não especificam um limite personalizado de CUs usando a instrução `SetComputeUnitLimit` ficam em desvantagem na priorização das transações em comparação com aqueles que o fazem.

Medição da eficácia dos mercados de taxas locais

Esta seção examinará dados relevantes para os LFMs da Solana. 

Mediana versus média das taxas de transação

Com LFMs funcionando de forma eficaz, espera-se que as taxas de transações envolvendo estados sem contenção, como transferências simples de stablecoins, permaneçam baixas. Enquanto isso, as taxas de transações que acessam estados com contenção, como tokens especulativos com baixa liquidez, devem disparar junto com a demanda. Uma métrica útil para avaliar essa dinâmica é a comparação entre a mediana e a média das taxas de prioridade das transações. A taxa mediana representa a taxa paga pelo usuário no 50º percentil e reflete os custos típicos, enquanto a taxa média considera todas as taxas divididas pelo número total de transações, destacando as tendências gerais.

Dados recentes confirmam esse padrão esperado. Novembro de 2024 registrou o maior nível de atividade econômica na Solana até hoje, com as taxas médias de transações sem voto atingindo o recorde histórico de mais de 0,0003 SOL. Apesar disso, as taxas medianas permaneceram estáveis em 0,00000861 SOL, cerca de 35 vezes menores. Isso contrasta com abril de 2024, quando um aumento semelhante na atividade econômica fez as taxas médias ultrapassarem 0,0002 SOL, acompanhado por um aumento correspondente da taxa mediana para 0,00001862 SOL, cerca de 10 vezes menor. Essa divergência ressalta a eficácia do isolamento das taxas para proteger usuários comuns contra picos de custo durante períodos de alta demanda e preservar a experiência do usuário em casos de uso não motivados por especulação.

Observamos uma forte correlação entre a mediana e a média das taxas de transação ao analisar dados semelhantes de uma rede baseada em EVM, como a Base, uma L2 da Ethereum operada pela Coinbase e que não tem LFMs. A média e a mediana das taxas se movem de forma relativamente sincronizada devido ao aumento das taxas-base globais quando a demanda cresce. Além disso, a diferença entre a mediana e a média das taxas de transação é consideravelmente menor. Por exemplo, em 5 de dezembro de 2024, as taxas médias de transação na Base dispararam para US$ 0,1115, enquanto as taxas medianas também subiram e chegaram a US$ 0,0228 — um valor cerca de cinco vezes menor.

Taxas de transações revertidas

Outra tendência útil a ser examinada é a taxa de transações revertidas. Durante os períodos de alta atividade econômica em abril e maio de 2024, os usuários da Solana relataram amplamente uma piora na experiência do usuário enquanto a blockchain sofria com um grande volume de spam. A falta de determinismo reduziu a previsibilidade e a confiabilidade da execução das transações, levando os usuários a inundar a rede com spam de transações para aumentar suas chances de inclusão mais rápida. 

Os searchers frequentemente enviam transações para negociações oportunistas sem considerar a probabilidade de sucesso. Transações de arbitragem com taxas de prioridade inadequadamente baixas ainda são válidas. O protocolo as processará depois de outras transações com taxas de prioridade maiores, e elas provavelmente serão revertidas devido à lógica de slippage. 

As transações revertidas atingiram o pico em abril de 2024, representando 75,7% de todas as transações sem voto. Esse percentual caiu significativamente após o lançamento de atualizações importantes, incluindo o escalonador central do Agave 1.18.

Uma análise de coorte da Blockworks Research referente aos últimos sete dias (6 a 13 de janeiro de 2024) revela diferentes taxas de reversão entre diversos níveis de atividade. Endereços que realizam de 1 a 5 transações diárias (principalmente usuários de varejo) apresentam uma taxa de reversão de 1,4%, que aumenta para 4,6% entre aqueles com 6 a 50 transações diárias. Vale destacar que os endereços que realizam mais de 10.000 transações diárias apresentam taxas de reversão que chegam a 66,7%. Além disso, endereços de alta atividade com mais de 100.000 transações diárias (bots) são responsáveis por 95,2% de todas as transações revertidas. Em dezembro de 2024, a taxa geral de reversão de todas as transações sem voto foi de 41,2%, indicando que uma grande parte dos recursos computacionais da rede é consumida pelo processamento de arbitragens malsucedidas.

Problemas persistentes e áreas para melhorias

Apesar dos avanços significativos, o escalonador do cliente validador Agave ainda enfrenta desafios. A análise a seguir das cargas de trabalho das threads do estágio bancário, realizada pelo engenheiro da Anza Alessandro Decina, destaca as ineficiências existentes e as áreas para melhorias.

Thread do escalonador: Esta é a thread mais importante para produzir blocos. O escalonador recebe todas as transações de entrada e depois as classifica e agenda para execução. 

Threads de transações de voto: Duas threads dedicadas processam transações de voto, garantindo que sejam tratadas separadamente das transações dos usuários.

Threads de transações sem voto: Quatro threads recebem as transações conforme o agendamento feito pelo escalonador e processam as transações dos usuários.

Threads de ingestão QUIC: Threads do Tokio gerenciam a ingestão de transações pelo protocolo QUIC quando o validador é o líder. Durante o período de congestionamento no início de 2024, essas threads foram um gargalo significativo.

A visualização acima revela que, embora todas as threads de trabalho executem transações em paralelo no início do primeiro bloco do líder, esse paralelismo rapidamente se deteriora e dá lugar à execução sequencial. Especificamente, apenas uma thread de transações sem voto (a thread três) continua processando transações, enquanto as demais ficam ociosas.

Esse comportamento sugere que um bug no escalonador impede o cliente validador de usar toda a sua capacidade. Como resultado, o sistema opera com apenas uma fração de seu potencial, o que indica que, se o problema fosse resolvido, o validador poderia processar até quatro vezes a carga atual.

Observabilidade

As APIs atuais de taxas para estimar a inclusão previsível de transações não têm a sofisticação necessária para oferecer resultados determinísticos. Cada grande provedor de RPC oferece sua própria API personalizada de taxas de prioridade, enquanto a implementação principal e de código aberto da API RPC continua abaixo do ideal. Ela não considera dinâmicas críticas da rede, como a influência da Jito, resultando em estimativas de taxas menos precisas. 

A Helius oferece o método RPC `getPriorityFeeEstimate`, que fornece recomendações de taxas com base em dados históricos dos mercados globais e dos LFMs. Os desenvolvedores podem inserir uma transação serializada e assinada ou uma lista das chaves de conta envolvidas na transação. O método oferece níveis personalizados de taxas de prioridade, classificados em seis percentis: mínimo, baixo, médio, alto, muito alto e máximo inseguro. O nível médio (50º percentil) é definido como recomendação padrão. As taxas são calculadas usando dados dos 50 slots mais recentes.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Acima: exemplo de payload para getPriorityFeeEstimate usando uma transação serializada codificada em base58.

Sem um método determinístico para calcular taxas de prioridade, os desenvolvedores costumam adotar uma abordagem cautelosa e pagar a mais para garantir que suas transações sejam processadas. Como alternativa, podem usar gorjetas da Jito em excesso, mesmo em transações nas quais não é necessário garantir o topo do bloco. Essas gorjetas são frequentemente usadas como substitutas das taxas de prioridade. Vale destacar que a maioria das gorjetas observadas em 2024 não está vinculada a atividades tradicionais de MEV, como arbitragem ou sandwiching, mas busca obter uma inclusão mais rápida das transações. Os validadores colhem os benefícios dessa ineficiência ao receber recompensas de bloco e comissões de MEV maiores.

Outro desafio surge quando os desenvolvedores não implementam uma lógica para ajustar dinamicamente suas taxas de prioridade em resposta às oscilações das condições on-chain. Durante grandes eventos, como movimentos significativos do mercado, as taxas para acessar contas de estado específicas podem disparar. Aplicações sem mecanismos de taxas dinâmicas terão dificuldades nesses cenários, pois suas configurações estáticas de taxas não são suficientes para garantir uma execução no prazo adequado.

Soluções propostas

Várias estratégias foram propostas para aprimorar ainda mais a estrutura de taxas da Solana. Essas propostas buscam otimizar a alocação dos recursos da rede e reduzir os incentivos ao spam.

Taxas exponenciais de bloqueio de escrita

Proposta em janeiro de 2023 por Tao Zhu (Anza) e Anatoly Yakavenko, a SIMD-0110 apresenta um novo mecanismo para gerenciar o congestionamento por meio da cobrança de taxas dinâmicas sobre contas com contenção. Esse mecanismo acompanha a média móvel exponencial (EMA) da utilização de unidades computacionais (CU) em contas com bloqueio de escrita e aumenta o custo de bloquear para escrita as contas que apresentam alta utilização de forma consistente.

Para implementar esse sistema, o runtime da Solana mantém um cache LRU (Least Recently Used) de chaves públicas das contas com contenção e seus respectivos Compute Unit Pricers (CUPs). Os CUPs monitoram a utilização EMA de CUs de uma conta e fornecem uma taxa de custo atualizada quando consultados.

O mecanismo ajusta dinamicamente as taxas de bloqueio de escrita. A taxa de custo do bloqueio de escrita aumenta se a utilização EMA de CUs de uma conta ultrapassar um limite-alvo. Por outro lado, se a utilização ficar abaixo da meta, a taxa de custo diminui. Os parâmetros iniciais incluem:

• Uma utilização-alvo de 25% do limite máximo de CUs da conta.
• Uma taxa de custo inicial de bloqueio de escrita de 1.000 microlamports por CU.
• Uma taxa de ajuste de custo de 1% por bloco.

A taxa de bloqueio de escrita de uma conta é calculada multiplicando sua taxa de custo pelas CUs solicitadas pela transação. Nesse sistema, as taxas totais da transação correspondem à soma de três componentes: a taxa-base de assinatura, a taxa de prioridade e a taxa de bloqueio de escrita. As taxas de bloqueio de escrita são 100% queimadas.

Quando foi lançada, a SIMD-0110 gerou um debate intenso na comunidade. No entanto, a proposta está inativa no momento e, desde então, foi marcada como encerrada.

Taxas-base dinâmicas

Outra solução de prazo mais longo para melhorar o LFM da Solana seria introduzir taxas-base dinâmicas (DBFs) globais e por conta. Jarry Xiao e Eugene Chen, da Ellipsis Labs, estão entre os principais defensores dessa abordagem.

Embora as taxas de prioridade sejam opcionais, as taxas-base são obrigatórias. Atualmente, a taxa-base da Solana é fixa em 5.000 lamports por assinatura. Usuários que enviam transferências simples de tokens pagam a mesma taxa-base que aqueles que realizam swaps complexos em várias plataformas ou que os searchers que tentam executar arbitragens de MEV complexas. As taxas-base não refletem com precisão o uso computacional de uma transação.

Com taxas-base dinâmicas, uma transação de arbitragem com taxas-base inadequadas pode ser considerada inválida e descartada antes de chegar ao escalonador. Aumentar as taxas-base incentiva os spammers a enviar menos transações.

As taxas-base acabarão atingindo um equilíbrio, e o preço das transações será definido de acordo com o valor do mercado de espaço de bloco. Como a taxa-base aumenta progressivamente, ela acabará atingindo o custo marginal no qual o envio da transação deixa de compensar o custo de oportunidade da negociação. As taxas não podem ficar altas demais, pois isso afetaria a atividade dos usuários. O ideal é um valor máximo que seja alto demais para bots, mas geralmente aceitável para os usuários. Nesse sistema, contas que enviam spam de transações para obter inclusão acabarão queimando todo o seu SOL.

Os blocos rápidos da Solana permitem que algoritmos agressivos definam as taxas-base. Durante períodos de alta demanda, as taxas podem ser ajustadas rapidamente — possivelmente dobrando a cada bloco — para refletir o congestionamento da rede. Por outro lado, conforme a demanda diminui, as taxas podem ser reduzidas de forma mais gradual. Graças aos curtos tempos de bloco da Solana, as reduções de taxas ainda ocorrem com relativa rapidez, garantindo que a rede se adapte rapidamente às mudanças nas condições.

Um exemplo de uma forma semelhante de contrapressão econômica é o programa Metaplex Candy Machine, que instituiu uma taxa para bots como mecanismo antispam em 2022. A taxa para bots é uma cobrança opcional aplicada a transações inválidas. Normalmente, seria um valor razoavelmente pequeno para evitar afetar usuários reais que cometeram um erro legítimo. Essa taxa se mostrou eficaz: os recursos dos bots de mint foram rapidamente esgotados, e o spam cessou.

Conclusão

Os LFMs da Solana estão funcionais, mas ainda há bastante espaço para melhorias:

• Aprimorar os mecanismos de taxas de prioridade: As chamadas RPC de taxas de prioridade precisam melhorar. O ideal é que os desenvolvedores tenham uma forma simples e determinística de definir taxas que garantam a inclusão da transação em um dos próximos blocos.
• Desincentivar economicamente o spam: A rede precisa descobrir formas de aplicar contrapressão econômica contra bots durante períodos de alta atividade econômica, mantendo ao mesmo tempo taxas baixas para usuários humanos legítimos.
• Capacitar os desenvolvedores: Os desenvolvedores precisam parar de definir taxas estáticas para as transações das aplicações e depender menos de mecanismos fora do protocolo, como a Jito, em transações rotineiras.
• Otimizar ainda mais o escalonador: O escalonador de transações precisa de mais otimizações para garantir que todas as threads de trabalho sejam utilizadas durante períodos de alta demanda.

Como aponta Anatoly Yakovenko, cofundador da Solana, esses desafios são principalmente “apenas problemas de engenharia” — solucionáveis com o devido foco técnico.

Recursos adicionais

• Taxas da Solana, parte 1 - Umbra Research
• Rumo a taxas multidimensionais na Solana - Umbra Research
• Mercados de taxas locais são necessários para escalar a Ethereum - Eclipse Labs
• Os mercados de taxas locais da Solana não são reais | Eugene Chen - Lightspeed Podcast
• Estágio bancário e escalonador da Solana - A.Fitzgerald