Taxas da Solana na teoria e na prática

Introdução

A estrutura de taxas da Solana foi projetada para manter o desempenho da rede e, ao mesmo tempo, equilibrar choques não uniformes de oferta e demanda. Em qualquer blockchain, as taxas servem para evitar spam e incentivar validadores. Na Solana, algumas dessas taxas são ajustadas dinamicamente com base nas condições da rede, permitindo que ela precifique a demanda com mais precisão em um determinado momento.

As taxas na Solana são um tema em destaque, com “mercados locais de taxas” que dão à Solana alguma flexibilidade para precificar com mais precisão o espaço em bloco e contas específicas. A implementação atual está longe de ser perfeita, mas oferece garantias flexíveis de ordenação por conta. Embora a Solana ainda esteja em seus estágios iniciais, o aumento do stake e da atividade na rede exige discussões e análises mais profundas sobre os efeitos de primeira e segunda ordem de qualquer mudança no protocolo, como alterações no modelo de taxas.

Neste artigo, abordaremos as taxas na teoria e como elas se manifestam on-chain. Embora algumas pessoas tenham criticado a Solana por ser centralizada e por apresentar forças centralizadoras devido ao design ponderado por stake de QoS e do Turbine, há uma clara discrepância entre essas críticas e o que ocorre na prática, mesmo após muitos anos. Da mesma forma, nosso objetivo é analisar de forma abrangente como as taxas se manifestam no comportamento on-chain.

Taxas na teoria

O sistema de taxas da Solana consiste em dois componentes: a taxa-base e a taxa de prioridade. Em termos gerais, cada componente deve cumprir a seguinte função:

• Taxas-base: direito de usar os recursos da rede
• Taxas de prioridade: determinam a ordem na fila de transações de um líder

Taxa-base

A taxa-base, atualmente definida em 0,000005 SOL (5.000 lamports) por assinatura, forma a base do custo de uma transação. Essa taxa é paga por um endereço para obter o direito de usar os recursos da rede. Trata-se de um único pagamento fixo feito antecipadamente à rede, independentemente da quantidade real de recursos usados para executar a transação — ou até mesmo de ela ser executada. As transações da Solana solicitam antecipadamente um número específico de unidades de computação (CUs) e, se esse número for excedido, a transação falhará. Isso significa que, atualmente, os desenvolvedores têm pouco ou nenhum incentivo financeiro para minimizar as solicitações de unidades de computação.

Taxas de prioridade

Além disso, os usuários podem pagar uma taxa de prioridade para agilizar suas transações e aumentar a probabilidade de inclusão em um bloco. Essa é uma garantia não determinística para usuários que pagam por prioridade. Há iniciativas em andamento para melhorar o determinismo das transações, com mudanças significativas no agendador previstas para chegar na versão 1.18.

Como observação, as transações de voto não têm uma taxa de prioridade associada e são tratadas de forma diferente das transações padrão.

O incentivo para que os validadores incluam transações com taxas de prioridade existe fora do runtime. Os líderes recebem 50% da taxa de prioridade por incluir a transação em seu bloco, enquanto os outros 50% são queimados.

Hoje, a maioria dos validadores (mais de 80%) executa versões não modificadas do cliente Solana Labs ou Jito-Solana. Isso significa que esses validadores terceirizam a “produção de blocos” para o agendador padrão — algumas pessoas na Solana chamam a “ordenação de blocos” de “produção de blocos”, embora isso tenha um significado completamente diferente na Ethereum. Algumas equipes modificaram o código do cliente e implementaram um agendador mais complexo que oferece maior controle sobre o fluxo de ordenação, permitindo que algumas extraiam MEV reordenando transações ou colocando-as em esquemas de sandwich.

Indeterminismo das taxas de prioridade

A implementação atual do agendador não garante que transações com taxas de prioridade mais altas sejam incluídas em um determinado bloco. Em vez disso, oferece uma garantia flexível de que transações com taxas de prioridade têm maior probabilidade de serem incluídas em um determinado bloco. A implementação atual do agendador usa quatro núcleos de execução, com dois núcleos adicionais reservados para transações de voto.

Cada thread opera sua própria fila e prioriza pacotes de forma independente, sem conhecer os pacotes processados pelas outras threads. Cada thread percorre continuamente sua fila do início ao fim, tentando bloquear e executar transações. Quando uma thread conclui seu ciclo atual, ela coleta mais pacotes e inicia o ciclo novamente.

Como resultado, uma transação de alta prioridade pode estar no topo da fila de uma thread enquanto, simultaneamente, outra thread conclui sua própria fila processando uma transação que envolve a mesma conta.

Os detalhes específicos da implementação atual e futura do agendador serão abordados em outro artigo. Basta entender que as taxas de prioridade funcionam apenas intra-thread (dentro da própria faixa), e não inter-thread (entre faixas), para perceber que o agendador está longe de ser perfeito e apresenta “jitter”.

Taxas na prática

Confirmação de transações

Embora as taxas sejam um fator importante para determinar se uma transação será confirmada, elas não são o único fator determinante. Por exemplo, transações podem não ser confirmadas simplesmente devido à perda de um pacote de rede UDP. Durante períodos de alta atividade na rede, os validadores podem receber mais transações do que conseguem processar. Embora possam encaminhar transações excedentes por meio do mecanismo tpu_forwards, eles só conseguem processar um volume finito de dados, e cada transação só pode ser retransmitida um número limitado de vezes, até o blockhash expirar. A qualidade de serviço ponderada por stake reduz alguns desses problemas para endereços com mais stake, oferecendo largura de banda reservada e aumentando a probabilidade de inclusão da transação.

Também existem dois motivos menos discutidos para o descarte de transações. O primeiro envolve discrepâncias dentro de um pool de RPC. Um segmento do pool de RPC pode avançar mais rápido que os demais, criando problemas de coordenação. Por exemplo, se o recentBlockhash de uma transação for obtido de um segmento mais atualizado e depois enviado a um segmento mais lento, este poderá não reconhecer o blockhash atualizado e, consequentemente, descartar a transação. Os desenvolvedores podem identificar esses problemas no momento do envio se as verificações de preflight estiverem ativadas na função sendTransaction.

Outro problema surge em torno de forks temporários da rede. Se um validador se atrasar no processamento de seus blocos, as transações poderão acabar em um fork minoritário que não se tornará canônico. Quando um cliente referencia em sua transação um recentBlockhash que existe apenas nesse fork minoritário e a rede abandona o fork antes de processar a transação, ela será descartada porque o blockhash não poderá mais ser encontrado.

Taxas de prioridade

Na prática, há evidências de que, embora as taxas de prioridade estejam longe de ser perfeitas, elas funcionam em escala macro. Transações que incluem taxas de prioridade têm maior probabilidade de serem incluídas em blocos, e aquelas que definem taxas de prioridade mais altas têm uma probabilidade ainda maior de inclusão.

Com base nos dados do Helius RPC, vemos que transações com taxas de prioridade têm maior probabilidade de serem confirmadas e, quando isso acontece, elas são confirmadas mais rapidamente em todos os casos:

Em 21 de janeiro, houve um pico nas taxas médias de prioridade devido ao airdrop mockJUP, em preparação para o airdrop real de JUP na semana seguinte. Embora tenham ocorrido mudanças significativas na demanda por espaço em bloco, os usuários reais sentiram relativamente pouca diferença na taxa e no tempo de confirmação das transações.

Essa UX é viabilizada principalmente pelo método RPC da Solana getRecentPrioritizationFees, que permite aos desenvolvedores determinar com precisão a taxa de prioridade a ser adicionada a uma transação. O endpoint retorna uma lista das taxas de prioridade dos últimos 150 blocos que foram usadas para confirmar com sucesso pelo menos uma transação com o respectivo endereço e os parâmetros de entrada. Isso fornece uma visão instantânea do valor mínimo necessário para as taxas de prioridade, mas sua utilidade é relativamente limitada. Como alternativa, a Helius oferece uma API de taxas de prioridade que realiza cálculos adicionais para fornecer uma estimativa melhor da taxa de prioridade.

Embora, na teoria, as taxas de prioridade funcionem parcialmente como previsto, as próximas mudanças no agendador da versão 1.18 proporcionarão mais determinismo para a inclusão de transações. Isso deve reduzir a quantidade de spam que chega à blockchain, pois a estratégia dominante não exigirá mais inundar a rede com transações para conseguir inclusão.

Taxa-base

A taxa-base da Solana é definitivamente baixa demais. Como os blocos ficam saturados e a taxa não é dinâmica, ela não consegue alcançar um preço de equilíbrio de mercado para o espaço em bloco. Na Ethereum, a taxa-base dinâmica é obtida por meio do mecanismo de controle da EIP-1559, que analisa os blocos recentes e busca uma taxa de utilização de 50%.

A Solana define estaticamente o preço de 5.000 lamports por assinatura — normalmente, uma assinatura por transação. Isso a torna uma taxa ineficaz, pois a taxa-base não expressa nenhuma mudança na demanda por espaço em bloco nem no uso dos recursos dos validadores. Na prática, isso externaliza a taxa de prioridade para que ela funcione como uma alternativa baseada no mercado à própria taxa de prioridade, congestionando ainda mais a rede enquanto os validadores processam transações adicionais que provavelmente nunca seriam incluídas. Além disso, a estratégia dominante é enviar um grande número de transações com taxas de prioridade mínimas para tentar obter inclusão. Isso impõe grandes externalidades à UX de todos os participantes da rede.

Incentivos

Os RPCs têm o incentivo de transmitir as informações corretas aos destinos subsequentes para oferecer a maior taxa de inclusão de transações com o menor custo. A integração com os validadores que têm mais stake permite que os RPCs tenham uma visão mais precisa do estado atual da rede, pois muitos mecanismos da Solana são ponderados por stake. Surge uma relação simbiótica na qual validadores com stake significativo e RPCs integrados podem aumentar a eficiência e a confiabilidade do processamento de transações, potencialmente criando um ciclo de retroalimentação que consolida ainda mais a posição dos validadores com mais stake.

Além disso, os RPCs — atualmente tratados como validadores sem stake — passarão a ser ponderados por stake. Os próprios RPCs poderão buscar atrair stake sem formar parceria com um validador. Não é incomum que as próprias aplicações operem seus próprios validadores para obter mais integração vertical, possibilitando maior controle sobre a experiência do usuário final e a cadeia de suprimentos de transações/MEV.

Apesar de o incentivo econômico sugerir uma tendência à centralização do stake, a Solana não apresentou uma aglomeração de capital em larga escala para obter ganhos ponderados por stake. Isso pode ocorrer por vários motivos:

• Os indivíduos podem considerar a maximização local da descentralização como a estratégia dominante para gerar ganhos de longo prazo para a rede, impulsionada principalmente pela cultura e pela camada social da Solana.
• Os participantes da Solana têm sido, em grande parte, investidores de varejo e prossumidores, e não são tão sensíveis aos retornos quanto as empresas profissionais. À medida que o nível de atividade e os retornos absolutos aumentarem, isso poderá incentivar mudanças na composição demográfica dos participantes e na sensibilidade aos retornos.
• Os indivíduos não estão bem coordenados no marketing de seus produtos diferenciados.

Conclusão

Neste artigo, descrevemos em detalhes a teoria geral do mecanismo de taxas da Solana e como ele afeta a rede on-chain. As taxas determinam incentivos que geram grandes externalidades e afetam o comportamento de todos os participantes da Solana.

Mecanismos como a taxa-base e a taxa de prioridade da Solana não são perfeitos em sua implementação atual. A taxa-base não pode ser ajustada e não reflete o equilíbrio atual entre oferta e demanda. Isso causa problemas como congestionamento da rede e alocação ineficiente de recursos. As taxas de prioridade apresentam certo grau de indeterminismo devido à implementação atual do agendador. Atualizações futuras, como as mudanças previstas no agendador, prometem trazer mais determinismo e eficiência ao processamento de transações, podendo transformar o comportamento on-chain que observamos hoje.

Há novas propostas no horizonte, como as taxas exponenciais para contas com bloqueio de escrita, que buscam precificar o custo das transações com mais precisão ao bloquear arbitrariamente o acesso às contas. Também há discussões sobre um mecanismo dinâmico de taxa-base que precifique o acesso ao estado com mais precisão.

A interação entre taxas, validadores e RPCs forma uma rede complexa de incentivos. Em teoria, validadores e RPCs têm o incentivo de se integrar e aumentar o peso de seu stake, o que pode gerar preocupações com a centralização. Na prática, porém, a Solana conseguiu manter um conjunto descentralizado de operadores e de stake, provavelmente devido à governança orientada pela comunidade, às barreiras técnicas, aos contraincentivos econômicos e às funções de otimização que, atualmente, não são movidas principalmente por retornos.