Encaminhar o título original：Solana & Mecanismos de taxa de transação da Ethereum: Propostas para melhorar o TFM da Solana

Agradecemos a Andrew Fitzgerald, Harsh Patel, Jon Charbonneau, Kevin Galler, Lanre Ige, Mert Mumtaz, Pranav Garimidi, Ryan Chern, Tao Zhu e Tarun Chitra pelo feedback e pela revisão.

Introdução

O Eclipse é o primeiro SVM L2 da Ethereum. Estamos incrivelmente empolgados em levar o poder do SVM existente a mais usuários, mas também nos dedicamos a levar adiante a P&D em andamento em torno do próprio SVM. Estamos concentrados em garantir que o desenvolvimento do Eclipse retorne inegavelmente valor a todas as cadeias SVM, especialmente a Solana.

Como precursor de futuros artigos sobre nosso pensamento em relação aos mercados de tarifas, este artigo analisará o mercado de tarifas existente em Solana e as propostas associadas para melhorá-lo. Apresentamos essas propostas juntamente com os principais objetivos teóricos de qualquer Mecanismo de Taxa de Transação (TFM), inspirados em grande parte no trabalho de Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi e outros. Indicaremos as principais definições com **.

Em geral, um TFM determina:

1. Quais transações estão incluídas em um determinado bloco,
2. As taxas que uma determinada transação paga, e
3. Como (e para quem) as taxas de transação acumuladas são distribuídas.

Em última análise, este artigo tem como objetivo combinar a riqueza da pesquisa de TFM centrada no Ethereum com a engenharia inovadora da Solana.

Visão geral do Solana & Ethereum TFMs atuais

Noções básicas de Solana vs. Ethereum

Começaremos com uma visão geral do TFM da Solana e o compararemos com o da Ethereum. Isso contextualizará melhor as propostas relevantes para que possamos trabalhar para modificar e aprimorar o TFM. Para começar:

A taxa básica da Solana é de 5.000 lamports fixos (0,000005 SOL) por assinatura, e a maioria das transações tem uma assinatura. Ele não leva em conta os recursos computacionais mais amplos de uma transação (conforme medido por CUs).

Taxa básica de Solana Tx = (5.000 Lamports) x (número de assinaturas em Tx)

O mecanismo de taxa básica da Ethereum difere de duas maneiras principais:

1. Dinâmica - a taxa básica da Ethereum (medida em gwei por unidade de gás) flutua com base na demanda do mercado.
2. Cobrança mais granular por unidade de computação - a taxa básica por transação da Ethereum é linear na quantidade de gás consumido.

Portanto, a taxa básica por transação da Ethereum é:

Taxa básica de tx da Ethereum =(preço do gás em vigor em gwei) x (gás usado em tx)

Os usuários do Solana também podem adicionar taxas de prioridade opcionais para aumentar a probabilidade de inclusão. Diferentemente da taxa básica, a taxa de prioridade é cobrada por UC solicitada para uma transação. As transações do Solana podem incluir as seguintes instruções de Compute Budget:

1. SetComputeUnitLimit - As transações podem definir uma quantidade máxima de CUs que podem consumir (com um máximo de 1,4 milhão de CUs por transação). Quando executada, a transação pode usar até o limite de CU solicitado. Se nenhuma instrução SetComputeUnitLimit for fornecida, o limite de CU da transação será calculado como (número de instruções na transação) x(200k CUs).
2. SetComputeUnitPrice - Número de micro-lamports por CU solicitada que a transação oferece para pagar em sua taxa de prioridade.

Juntando os dois:

Tarifa de prioridade Tx = (Limite da UC Tx) x (Preço da UC)

Observe que essa taxa de prioridade é paga contra todas as CUs solicitadas (independentemente de a transação usar o valor total solicitado), ao contrário do Ethereum, em que a taxa é uma função da quantidade de gás que a transação realmente usa.

Fee Burn vs. Validator Rewards

Embora o incentivo para que os validadores priorizem as transações de alta taxa esteja fora do consenso, é imposto no consenso que tanto a taxa básica quanto a taxa prioritária sejam 50/50 queimadas/enviadas para o líder (produtor do bloco atual) em Solana:

1. Taxa básica - Obrigatória para inclusão no bloco. As transações que não tiverem a taxa básica necessária serão rejeitadas.
2. Taxa de prioridade - Não é obrigatória para inclusão no bloco. Usado para priorizar opcionalmente as transações que desejam aumentar a probabilidade de inclusão rápida.

Um usuário não pode evitar o pagamento da taxa básica, mas pode evitar a taxa de prioridade e sinalizar seu desejo de ser priorizado de outra forma. Já vemos isso na prática - os leilões da Jito-Solana pagam 100% (menos uma taxa) ao líder fora da banda. O SIMD-0096 oferece uma solução simples para esse problema, recompensando 100% da taxa de prioridade para o validador.

Transferência direta*: Coordenada por meio de leilões MEV-Boost / Jito-Solana

É importante ressaltar que os validadores do Solana votam em cada bloco com transações na cadeia. Eles pagam a taxa básica para cada uma dessas transações.

A Solana tem gerado seus maiores índices de taxas de rede ultimamente, impulsionada por um aumento acentuado nas taxas de prioridade. As divisões de taxas recentes são mostradas abaixo:

Fonte: Solana Compass

Ethereum Block Builder vs. Solana Scheduler

A produção de blocos da Ethereum é geralmente mais fácil de entender, portanto, começaremos por ela. Quase todos os validadores (também conhecidos como proponentes) terceirizam a produção de blocos para construtores fora do protocolo por meio do MEV-Boost. Os construtores criam blocos a cada 12 segundos (o tempo de slot da Ethereum) e passam esses blocos inteiros para o proponente (por meio de um relé), que seleciona o bloco de maior valor.

Tanto no Ethereum quanto no Solana, os produtores de blocos têm o poder de ordenar transações arbitrariamente dentro de um bloco. Eles são incentivados a fazer isso de forma a maximizar seus lucros. Por exemplo, diferentes construtores de Ethereum podem competir executando algoritmos proprietários que maximizam os lucros de forma mais eficaz em relação aos concorrentes.

Isso significa que, mesmo na Ethereum, o envio de uma taxa de alta prioridade não alcança nenhuma garantia determinística no protocolo de inclusão ou ordenação de blocos. No entanto, é muito provável que o resultado esperado seja alcançado devido à natureza do atual processo de construção de blocos da Ethereum, no qual o construtor constrói um bloco completo que maximiza o lucro no final de cada slot discreto.

Por exemplo, um pesquisador pode enviar uma transação de arbitragem com uma taxa de prioridade incrivelmente alta (por exemplo, mais alta do que todas as outras transações qualificadas combinadas) para o construtor, solicitando sua inclusão no topo do bloco e a exclusão total da transação do bloco se ela não obtiver a posição no topo do bloco. Nesse caso, um construtor racional que maximiza o lucro incluirá essa transação no topo do bloco, mesmo que a tenha recebido apenas no final de seu intervalo de 12 segundos.

O senhor notará que há duas garantias diferentes que as taxas estão tentando alcançar aqui:

1. Inclusão - Um usuário deseja que sua transação seja incluída nesse bloco, mas não se importa com a posição em que ela se encontra no bloco.
2. Ordenação - Um usuário não quer apenas ser incluído no bloco em qualquer lugar; ele quer acesso prioritário a um estado específico em um determinado momento.

O mecanismo EIP-1559 da Ethereum provou ser bastante eficaz ao permitir que os usuários façam lances facilmente para a inclusão de blocos com uma alta probabilidade de sucesso. Há um preço de reserva global que todos sabem que devem pagar, e pagá-lo (geralmente junto com uma taxa de prioridade nominal) deve fazer com que a transação de um usuário seja incluída imediatamente. No entanto, o mecanismo não procura fornecer nenhuma garantia em relação ao pedido (ou seja, acesso prioritário ao estado), enquanto os mecanismos fora do protocolo são confiáveis para os usuários que buscam essas garantias (diretamente dos criadores, por exemplo).

O processo de formação de blocos de Solana funciona de forma muito diferente. Os validadores não terceirizam a produção de blocos completos em intervalos de tempo discretos para construtores fora do protocolo. O "scheduler" é o algoritmo padrão incluído no cliente validador da Solana Labs, que agenda as transações para execução e cria blocos continuamente.

Além disso, as transações Solana especificam quais contas devem ser bloqueadas para leitura e gravação para execução. Isso permite que o agendador classifique iterativamente quais transações podem ser executadas simultaneamente, pois as transações que não tocam o mesmo estado podem ser executadas em paralelo.

Em um bloco, um máximo de 12.000.000 CUs pode ser usado para gravações sequenciais em uma única conta ("parte do estado"). Essa é aproximadamente a quantidade de CUs que pode ser processada por um único thread por slot de 400 ms em requisitos de nó razoáveis. O limite por bloco do Solana é então de 48.000.000 CUs. A implementação atual do agendador usa quatro threads para transações sem voto, e 12M x 4 = 48M. Em teoria, isso significa usar mais núcleos = aumentar os limites de CU. Dimensionamento com hardware.

O agendador prioriza de forma não determinística as transações com taxas de prioridade mais altas. No entanto, isso geralmente oferece garantias de priorização menos confiáveis do que mecanismos como os descritos no caso da Ethereum hoje.

No Solana, os validadores que executam o agendador padrão constroem blocos continuamente, de modo que as transações podem ser adicionadas a um bloco em andamento e executadas antes de esperar até o final do slot para organizá-las apenas por taxa de prioridade. A intenção é que o agendador maximize o lucro de forma muito aproximada, priorizando as transações com base em seu preço total de CU.

O agendador multithread padrão do Solana também introduz um "jitter" adicional. As transações são atribuídas aleatoriamente a um dos quatro threads, sendo que cada thread mantém sua própria fila de transações aguardando execução. As taxas de prioridade são então usadas para priorizar as transações intra-thread. No entanto, eles não ajudam a priorizar as transações entre threads.

Por exemplo, dois pesquisadores podem enviar uma transação simultaneamente para capturar a mesma oportunidade de arbitragem, e aquele que envia uma taxa de prioridade mais baixa pode até ganhar, pois entra em uma fila menos congestionada por acaso. Isso reduz a eficácia das taxas de prioridade e aumenta o incentivo ao spam em relação à Ethereum, especialmente porque a inclusão de transações também depende de quando, em um determinado intervalo, uma transação chega ao produtor do bloco atual.

Observe que há mudanças planejadas para o agendador padrão do Solana, que visam resolver alguns dos problemas com a implementação atual, baseando-se em um gráfico de dependências de transações e agendando as transações desbloqueadas (sem bloqueio de gravação) de maior prioridade no gráfico - trataremos disso mais adiante no artigo.

Embora esteja fora do escopo deste artigo, o cliente Jito-Solana permite que os pesquisadores capturem o valor extraível máximo (MEV) do minerador de forma mais eficiente, de modo a minimizar as externalidades negativas em Solana. O Jito-Solana se desvia do agendador padrão do Solana, introduzindo leilões de pacotes discretos de 200 milissegundos, no estilo Flashbots, que são executados em paralelo à produção padrão de blocos contínuos e a um mempool privado (que novamente se desvia do TFM padrão do Solana). A adoção do cliente Jito-Solana pelos validadores do Solana (>50% dos validadores o utilizam atualmente) ajudou a resolver alguns dos problemas com o TFM existente do Solana, ou seja, a prevalência de spam orientado por MEV.

Deficiências do atual TFM de Solana

Embora o TFM de Solana seja altamente promissor, ele também tem algumas possíveis deficiências por enquanto:

Incentivo ao spam

Conforme mencionado acima, as transações são ordenadas, de certa forma, como primeiro a entrar, primeiro a sair (FIFO), assim que chegam ao produtor do bloco. Além disso, eles estão sujeitos ao não determinismo tanto do jitter da rede quanto da alocação aleatória de threads do agendador padrão. Embora as taxas de prioridade possam ajudar a probabilidade de inclusão em determinadas circunstâncias, ainda existe um incentivo substancial para que as transações de spam maximizem a probabilidade de inclusão mais rápida (por exemplo, um buscador correndo para liquidar uma posição inadimplente em um mercado de empréstimos). A imagem abaixo, da Jito Labs, ajuda a demonstrar a natureza subótima das transações de spam.

Fonte: Fundação Jito

Leilão de primeiro preço

Em um leilão de primeiro preço (FPA) ingênuo, os usuários apenas enviam lances, sendo que o mais alto é incluído no bloco. Um problema com os FPAs é que eles não são muito fáceis de usar. Os usuários devem adivinhar o que os outros usuários estão oferecendo, pensando no que estão dispostos a oferecer, possivelmente diminuindo o valor do lance para não pagar a mais com base no que acreditam que os outros estão oferecendo, por exemplo.

Em termos mais formais, o modelo FPA é não-DSIC:

**Estratégia dominante de incentivo compatível (DSIC): Supondo que o produtor de blocos implemente o TFM honestamente, a estratégia de lance prescrita deve ser a estratégia dominante para os usuários. Isso significa que os usuários farão lances (em taxas de transação) com o valor exato que atribuem à inclusão da transação [Chu22].

O DSIC é uma das principais propriedades que os criadores da EIP-1559 pretendiam introduzir no TFM da Ethereum com sua implementação e, como descrevemos anteriormente, pode ser considerado um sucesso. Os usuários sabem com mais facilidade o preço de reserva público a ser incluído no bloco em um determinado momento (por meio da taxa básica dinâmica), portanto, pagá-lo (mais qualquer taxa de prioridade nominal) quase sempre fará com que sua transação seja incluída rapidamente.

Por outro lado, o TFM de Solana é um FPA ingênuo. Ele não possui um mecanismo confiável para que os usuários expressem com precisão sua preferência pela inclusão de blocos e não é DSIC. Na prática, tentar definir exatamente a taxa de prioridade certa no momento certo é incrivelmente desafiador. Isso favorece desproporcionalmente os participantes sofisticados que são mais capazes de contornar o jitter da rede e do agendador (por exemplo, por meio de co-localização ou transações de spam).

Pagamento de 50/50 Burn/Validator

Conforme observado anteriormente, o Ethereum queima 100% da taxa básica e envia 100% da taxa de prioridade para o produtor do bloco, enquanto no Solana, tanto a taxa básica quanto a taxa de prioridade são 50/50 queimadas/pagas ao produtor do bloco. Como resultado disso, o Solana TFM não é à prova de OCA:

**Prova de acordo fora da cadeia (OCA-proofness ou SCP): Nenhum acordo fora da cadeia entre os usuários e o produtor do bloco pode melhorar o resultado do TFM para um determinado bloco [Rou21]. Um protocolo c-SCP é resistente a uma coalizão do produtor de blocos e a até c usuários que possam lucrar desviando-se de relatórios verdadeiros.

Vemos um exemplo claro disso com os leilões fora do protocolo da Jito-Solana, que pagam 100% dos lances (menos a parte da Jito) aos produtores de blocos, em vez de queimar 50% - a Jito-Solana é um exemplo de acordo fora da cadeia usado pelos produtores de blocos. No entanto, observamos que as gorjetas Jito-Solana não são equivalentes às taxas de prioridade, pois as primeiras só são pagas se a transação associada (e o pacote) for executada com êxito.

O SIMD-0109, recentemente proposto, introduziria um mecanismo de gorjeta (semelhante ao usado pelo leilão fora do protocolo do Jito-Solana) no protocolo como uma instrução nativa.

Falta de tipos de transações privilegiadas

As transações de voto do Solana são publicadas na cadeia e devem ser incluídas em blocos, mas cada validador deve pagar pelos custos dessas transações. Isso representa um custo fixo significativo (pago de forma privada pelos validadores), apesar da externalidade positiva da inclusão de transações de votos. Esse custo é exacerbado pelo fato de que as transações de voto são cobradas a mais em relação às UCs consumidas (ou seja, elas usam relativamente poucas UCs em comparação com a transação média). A economia cria um efeito centralizador aqui, pois o custo total da votação é praticamente constante para qualquer validador, enquanto as recompensas obtidas são proporcionais ao peso da participação.

Fonte: Ceteris, Solana, o Monólito

Como um aparte, uma lógica semelhante poderia ser estendida para incluir atualizações confiáveis do oráculo, pelas quais as redes normalmente cobram, apesar da externalidade positiva dos feeds de preços precisos na cadeia. Uma cadeia mais opinativa que obtém alto valor de um oráculo robusto específico pode optar por consagrar um mecanismo que subsidie seu custo.

Mercado de taxas locais de Solana

A aproximação de Solana de um mecanismo de taxa local existe porque nenhuma conta pode gravar mais de 12 milhões de CUs por limite de bloco de 48 milhões. Isso, juntamente com a natureza multithread do agendador padrão do Solana, significa que um máximo de 25% das transações em um bloco pode corresponder a uma única parte do estado sob demanda. Em teoria, os usuários do estado com menos demanda não deveriam ter que aumentar suas taxas de prioridade para obter garantias de inclusão fortes em comparação com os usuários do estado com demanda.

Sem dúvida, esse não é um mecanismo genuíno de taxa local. O mecanismo não é aplicado por consenso (é apenas no nível do agendador), e a relação entre as taxas de prioridade e a inclusão de blocos é bastante não determinística (conforme mencionado anteriormente). Também carece de uma noção de "elasticidade" quando existem limites de recursos máximos e objetivos.

Uso ineficiente da UC & Requests

Como a taxa básica do Solana não leva em conta as UCs, ela não incentiva as transações:

1. Use as UCs de forma eficiente - Uma transação com 1,4 milhão de UCs acarreta a mesma tarifa básica que uma com 100 mil UCs, se tudo o mais for igual.
2. Solicite CUs de forma eficiente - Mesmo que uma transação use 50 mil CUs, ela terá a mesma tarifa básica se solicitar 100 mil CUs ou 1 milhão de CUs.

Isso pode levar a uma superestimação da computação necessária em um determinado bloco pelo agendador e a uma perda de eficiência em comparação com os recursos exigidos pelo produtor do bloco em um determinado slot. Um DSIC TFM resolveria esse problema, pois a estratégia dominante de um usuário seria a estratégia de lance prescrita - nesse caso, representando com precisão o uso esperado de UCs.

Sem custo para escrever contas de bloqueio

Conforme mencionado anteriormente, as transações Solana especificam antecipadamente todas as contas que serão lidas ou gravadas durante a execução. No entanto, esse mecanismo pode ser abusado hoje para bloquear globalmente qualquer conta sem nenhum custo. Por exemplo:

1. Envio_TxA, que especifica que ele gravará na_AccountA.
2. O líder recebe o_TxA, agenda-o e começa a executá-lo. A_contaA agora está bloqueada - nenhuma outra transação que toque na_contaA pode ser executada até que a_TxA termine de ser executada.

O problema decorre do fato de que qualquer pessoa pode enviar transações que bloqueiam a gravação de qualquer conta que desejar. Não há custo para bloquear contas, e as transações podem até mesmo bloquear contas que não são usadas, o que é um claro vetor de ataque de spam. Além disso, os proprietários de contas não têm controle sobre quem pode bloquear sua própria conta.

Propostas de TFM & Frameworks

Cada blockchain deve, em última instância, decidir como alocar o recurso escasso de seu espaço de blocos finito entre os usuários, o que é feito por meio de seu TFM. A seguir, discutiremos várias propostas e estruturas relevantes de TFM que podem ser úteis para Solana.

Mercados multidimensionais de taxas de blockchain

A maioria dos mercados de taxas existentes é unidimensional, construída em torno de uma única unidade de conta fungível (por exemplo, gás na Ethereum). No entanto, esse único recurso adquirido é um proxy para muitos recursos subjacentes não fungíveis (por exemplo, largura de banda, computação e armazenamento).

Por exemplo, cada código de operação do Ethereum carrega uma determinada quantidade fixa de gás que consome (por exemplo, ADD usa 3 gases, enquanto MUL usa 5). O preço do gás para cada opcode foi definido como uma aproximação grosseira dos recursos subjacentes que eles usam e o quanto eles são considerados caros para os nós da rede. Por exemplo, essa medida implícita do custo de uma operação pode ser determinada pela execução de benchmarks em hardware do mundo real.

Entretanto, também é possível construir mercados de taxas multidimensionais que precificam individualmente esses diferentes recursos não fungíveis em vez de combiná-los em uma única unidade. O EIP-4844 é um mercado de taxas bidimensional direto, pois os blobs de dados têm seu próprio mercado de taxas independente do gás de execução da Ethereum.

Este artigo de 2022 de Diamandis, Evans, Chitra e Angeris analisa como construir mercados de taxas multidimensionais como esse. O trabalho deles enquadra o problema de construção da TFM sob a perspectiva de um projetista de rede com o objetivo de maximizar o bem-estar (ou utilidade total) dos usuários da cadeia de blocos menos o consumo de recursos desses usuários, sujeito às restrições de transações e blocos da cadeia (por exemplo, limites de contratos inteligentes ou limites de CU/gás). O principal resultado do artigo é que, apesar de o bem-estar ser desconhecido, eles projetam um mecanismo que o maximiza e mostram como construir explicitamente esse mecanismo.

**Maximização do bem-estar: As regras de alocação e pagamento pretendidas implicam que a soma do excedente do consumidor e do minerador é (aproximadamente) maximizada.

Sua principal descoberta é que é possível implementar um TFM equivalente, que é aquele em que o preço do recurso é definido para minimizar a diferença entre o bem-estar dos validadores e de seus usuários - esse preço deve levar a blocos que, em teoria, são ideais do ponto de vista da maximização do bem-estar. Embora esse trabalho possa ser visto mais como uma estrutura acadêmica para projetar TFMs ideais, ele ajuda a mostrar que a precificação de recursos separadamente pode tornar uma blockchain mais eficiente e mais resistente a períodos de alto congestionamento ou spam. Mecanismos de taxa básica baseados em controladores, como o EIP-1559, são destacados como uma abordagem em potencial que poderia funcionar excepcionalmente bem nas cadeias Solana e SVM, devido aos curtos tempos de bloqueio, permitindo que a taxa básica se ajuste rapidamente às mudanças na demanda do usuário e na disponibilidade de recursos.

Conforme mencionado anteriormente, uma conclusão do artigo é que é possível projetar maneiras sistemáticas e computacionalmente eficientes para ajudar a definir e atualizar o preço de recursos multidimensionais para blockchains. No entanto, uma pergunta natural deveria ser: quais recursos fariam sentido ter preços distintos? Alguns trabalhos práticos foram realizados em outros contextos de blockchain para tomar essas decisões. Por exemplo, a Penumbra implementou uma forma de precificação multidimensional de recursos para definir o preço dos recursos usados por nós completos e dispositivos de usuários finais separadamente em seu blockchain centrado na privacidade.

Embora o documento de 2022 discuta, em geral, a precificação multidimensional de recursos básicos (por exemplo, computação, largura de banda, armazenamento), também é possível implementar a precificação multidimensional de recursos por conta (ou seja, por "parte do estado"). Cada conta é tratada como um recurso diferente. Isso é discutido neste artigo recente, que se baseia no artigo original. A precificação individual de contas (em vez de computação, armazenamento, largura de banda etc.) como o recurso subjacente também pode ser mais simples de implementar com um risco reduzido de ataques de exaustão de recursos.

Tarifa exponencial para contas com bloqueio de gravação

Após a recente publicação de Anatoly sobre a economia de execução de SVM, Tao Zhu, em colaboração com Anatoly, propôs o SIMD-0110. Sua principal motivação é impedir o spam com contrapressão econômica (ou seja, aumentar as taxas de forma direcionada ao longo do tempo para reduzir o incentivo ao spam), resultando em uma utilização mais eficiente dos recursos da rede. As transações de arbitragem fracassadas continuam a preencher cerca de metade (ou mais) do espaço de blocos de Solana porque é racional e incrivelmente barato fazer spam.

A proposta recomenda o rastreamento da média móvel exponencial (EMA) da utilização da UC de cada conta por bloco para atingir esse objetivo. O custo de bloqueio de gravação de uma conta aumentaria exponencialmente com base em sua respectiva utilização de CU, impedindo o spam. A lógica central é semelhante à forma como a EIP-1559 define a taxa básica global da Ethereum como uma função do uso de gás em blocos posteriores. No entanto, esse SIMD é muito mais granular na definição dos mercados de taxas básicas locais por conta.

A ideia básica de implementação da taxa variável de bloqueio de gravação baseada em contas seria a seguinte:

1. Acompanhe a utilização da unidade de computação da EMA de cada conta contenciosa nos últimos 150 slots.
2. O número máximo de contas que serão rastreadas é 2048, sendo que apenas as contas mais contenciosas com a maior taxa de custo de bloqueio de gravação são rastreadas.
3. Se a utilização da unidade de computação EMA de uma conta for >50% do seu limite máximo de CU, sua taxa de custo de bloqueio de gravação aumentará em X%. Se for <50% do seu limite, a taxa de custo diminuirá em X%.
4. A V0 recomenda uma taxa de custo inicial de bloqueio de gravação de 1.000 microlamports/CU e uma taxa de ajuste da taxa de custo de 1% por slot (observe que as porcentagens exatas aqui estão sujeitas a alterações, dada a natureza inicial da proposta).
5. A tarifa de bloqueio de gravação de uma conta em um determinado bloco é calculada multiplicando-se a taxa de custo de bloqueio de gravação pelas CUs solicitadas da transação.
6. As transações continuam a pagar taxas de assinatura e as taxas de prioridade opcionais também permanecem.
7. As taxas de bloqueio de gravação coletadas são 100% queimadas.
8. As taxas de prioridade cobradas são 100% recompensadas.
9. As taxas de assinatura coletadas são 50% queimadas e 50% recompensadas.

Essa proposta tornaria o recurso de bloqueio de gravação do Solana (geralmente) DSIC semelhante à forma como o EIP-1559 tornou o TFM do Ethereum (geralmente) DSIC e MMIC [Rou23] - exceto na presença de picos repentinos de taxas.

Podemos definir a propriedade MMIC da seguinte forma:

**Compatibilidade de incentivo do minerador míope (MMIC): O produtor do bloco maximiza sua utilidade ao não criar transações falsas e seguir as regras declaradas do TFM. Míope significa que essa meta só diz respeito ao bloco atual ao julgar a maximização da utilidade [Rou21].

Qualquer mecanismo de rastreamento é imperfeito, pois pode não representar com precisão o estado atual exato da demanda. Por exemplo, a demanda pode ser baixa por um longo período de tempo (e, portanto, a taxa básica dinâmica é baixa) e, em seguida, aumentar repentinamente para uma hortelã NFT. Esse pode ser o caso em nível global (como no TFM da Ethereum) e pode ser ainda mais volátil em um nível local por conta (como é considerado no SIMD-0110).

No entanto, o Solana também se beneficia de seus tempos de bloqueio incrivelmente baixos. Isso pode permitir que a tarifa básica se ajuste mais rapidamente a um choque repentino na demanda, dependendo da agressividade com que a curva é definida para se mover. O formato do controlador de taxas aqui é extremamente importante.

O fato de essa taxa de bloqueio de gravação ser cobrada sobre as UCs solicitadas também incentiva adequadamente os usuários e desenvolvedores a estimar com precisão o uso da UC de uma transação. Isso evita o problema que discutimos anteriormente, em que a base de assinatura plana atual não tem nenhuma penalidade por solicitar muito mais CUs do que o necessário (mesmo até o máximo de CUs de 1,4 mm). Caso contrário, apenas a taxa de prioridade tem esse incentivo hoje (já que também é cobrada pelas UCs solicitadas).

Uma possível crítica aqui é que os mercados de tarifas locais baseados em contas (especialmente essa proposta, que exige que uma EMA contínua seja calculada para cada conta) podem ser computacionalmente caros. Esse tipo de taxa multidimensional não tem limites, já que qualquer conta pode ser congestionada, o que provavelmente apresentaria dificuldades para esse TFM. No entanto, no caso do SIMD-0110, isso é evitado com a definição de um limite superior para o número de contas cuja EMA de uso da CU pode ser rastreada em um determinado momento.

**Computável de forma eficiente: O mecanismo de leilão de blocos deve ser projetado de forma que possa ser computado com eficiência para um determinado produtor (ou construtor) de blocos - os slots do Eclipse e do Solana são inferiores a 400 ms, o que impõe uma restrição rígida ao tempo máximo de computação para um determinado bloco.

Como a inclusão de blocos do Solana ainda seria não determinística, mesmo com essa proposta implementada, ainda pode haver problemas com os usuários que atualizam com precisão seus lances em tempo real para garantir que suas transações sejam incluídas nos blocos. Para resolver isso, são necessárias alterações no agendador, conforme discutiremos na próxima seção.

Alterações no agendador padrão do Solana

Conforme discutido anteriormente, o "agendador" é o algoritmo padrão incluído no cliente validador da Solana Labs, que agenda as transações para execução e cria blocos continuamente. Ele desempenha uma função extremamente importante no mercado de taxas do Solana, embora seu comportamento padrão não seja aplicado no protocolo, pois os validadores podem optar por executar outros algoritmos. Vamos nos concentrar aqui no agendador atual e nas próximas alterações propostas, que estão sendo trabalhadas por Andrew Fitzgerald.

O agendador atual do Solana introduz "jitter" no tratamento das transações dos usuários, atribuindo-as aleatoriamente a um dos quatro threads de transação que não são de votação (outros dois threads são reservados para o processamento de transações de votação) antes de tentar classificar as transações pendentes por taxa de prioridade e verificar os bloqueios relevantes ("lock grab"), como mostra o diagrama abaixo. Vários lotes de transações são puxados para serem alocados em threads durante o "Banking Stage" - o processo executado por um validador Solana no qual as transações são processadas e no qual ocorre o processo de agendamento.

Fonte: Andrew Fitzgerald, Solana Banking Stage e Scheduler

Um problema significativo com o agendador padrão é que, durante períodos de intensa atividade na rede, a fila de cada thread é frequentemente preenchida com transações conflitantes (por exemplo, antes de uma cunhagem de NFT ou de um evento de geração de token amplamente antecipado). Cada thread pode conter transações com bloqueios de leitura ou gravação iguais ou sobrepostos, o que significa que essas transações devem ser reprogramadas para execução posterior. O resultado disso, no entanto, é que, no pior dos casos, apenas um dos quatro threads do agendador padrão poderia estar executando transações em um determinado momento.

O ponto crucial da atualização do agendador padrão do Solana está na transição da abordagem herdada (denominada modo ThreadLocalMultiIterator) para a nova abordagem de agendamento, denominada modo CentralScheduler. Este artigo fornecerá apenas uma visão geral e uma análise das mudanças. No entanto, mais informações podem ser encontradas no artigo de Andrew Fitzgerald e em um artigo que o acompanha <a href="https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7"> summary blogpost por Harsh Patel da equipe Tiny Dancer. Uma visão geral do novo processo de agendamento é mostrada abaixo.

Fonte: Andrew Fitzgerald, Solana Banking Stage e Scheduler

O novo agendador envolve um único agendador central que recebe transações do canal antes de verificar os bloqueios relevantes. Após esse ponto, as transações são atribuídas a determinados threads de trabalho paralelo para execução. O agendador central tem uma visão dos vários bloqueios de leitura e gravação usados por um determinado thread de trabalho, o que lhe permite determinar o melhor thread para uma nova transação. À medida que as transações são executadas e processadas por um determinado thread de trabalho, uma mensagem é enviada de volta ao agendador central para que ele possa reavaliar quais partes do estado do Solana são consideradas bloqueadas.

O escalonador usa um algoritmo conhecido como "prio-graph", que é um gráfico acrílico direto que começa com as transações de prioridade mais alta (taxa) e linhas (ou, mais precisamente, bordas) entre uma determinada transação de prioridade mais alta e as seguintes transações de prioridade mais alta que entram em conflito com ela devido a bloqueios sobrepostos. Isso é feito (provisoriamente) para uma janela de "look-ahead" de um tamanho pré-configurado de 2.048 (sujeito a alterações) transações, que podem ser adicionadas ao gráfico - os gráficos a seguir mostram o funcionamento do prio-gráfico para um determinado conjunto de transações em que as bordas entre elas representam bloqueios conflitantes.

Além de adotar o agendador de gráficos primários, essa versão introduz eficiências adicionais para ajudar a reduzir a sobrecarga de processamento, como a remoção dos elementos redundantes do estágio bancário. O novo agendador deve melhorar, reduzindo significativamente a probabilidade de falhas de gravação e bloqueio de leitura durante períodos de alta atividade no Solana. Poderíamos esperar uma redução no jitter devido ao novo agendador padrão. Ainda assim, dada a natureza contínua do processo de construção de blocos, continuará a haver não determinismo na inclusão de blocos.

Taxas de gravação de conta rebatível de programa (PRAW)

De autoria de Godmode Galactus e Max Schneider, o SIMD-0016 propõe taxas de Program Rebatable Account Write (PRAW). Elas dariam um controle significativo aos desenvolvedores de aplicativos, pois poderiam definir os critérios de pagamento e descontos dessas taxas, permitindo que incentivassem e desincentivassem o comportamento do usuário conforme considerassem adequado.

Atualmente, os programas Solana não têm a capacidade de penalizar as transações por adquirirem bloqueios de gravação em seu estado. As taxas PRAW permitiriam que os proprietários de contas Solana cobrassem por transações fracassadas que bloqueiam seu estado. Essas taxas seriam transferidas para a conta gravável que estão bloqueando. No entanto, os proprietários de contas podem definir essas taxas de modo que elas sejam devolvidas ao usuário no final da transação, se ela atender aos critérios especificados.

Em particular, isso pode impedir que os usuários bloqueiem por escrito contas que não são realmente usadas na execução da transação. Isso é possível no momento, pois o Solana não tem verificações para saber se uma determinada conta seria usada, a priori, por uma determinada transação que a bloqueou para gravação. Os PRAWs oferecem aos programas uma maneira de desincentivar as transações que bloqueiam o estado do programa na tentativa de identificar uma oportunidade com a intenção de reverter se a oportunidade não for mais válida no momento da execução. Essas taxas seriam aplicadas mesmo se a transação falhasse durante a execução.

Por outro lado, os usuários podem especificar o valor máximo de taxas de PRAW que estão dispostos a pagar em uma transação. Qualquer taxa especificada na transação acima da taxa atual do PRAW para uma determinada conta bloqueada por gravação será reembolsada.

Os membros da comunidade Solana apontaram problemas com essa proposta: a capacidade de diferentes programas operarem de forma totalmente autônoma parece não ser ideal, e a capacidade de estimar as taxas com precisão seria difícil. Além disso, há maneiras potencialmente mais simples e uniformes de lidar com esses problemas de griefing em relação a contas bloqueadas por gravação, como o SIMD-0110.

**Resistência ao Griefing: Um subconjunto do DSIC em que os usuários não são incentivados a deturpar suas listas de acesso - deturpando os recursos necessários para sua transação[Gar23].

A proposta do PRAW poderia não impedir o spam, pois depende suficientemente dos desenvolvedores de aplicativos: 1) serem capazes de distinguir spam de "comportamento normal" e 2) optarem voluntariamente por cobrar mais por uma externalidade negativa pela qual são parcialmente responsáveis, quando talvez não seja de seu interesse fazê-lo, e eles podem simplesmente optar por não fazê-lo.

Por outro lado, embora os membros da comunidade de pesquisa de Solana estejam inegavelmente divididos sobre a introdução de taxas básicas de EMA, há um consenso geral sobre a adição de algum componente da taxa básica que seja escalonado com as UCs. Isso pode incentivar a estimativa precisa de UCs e o uso eficiente de UCs pelos desenvolvedores.

Pensamentos de despedida

As metas exclusivas de engenharia e desempenho da Solana exigem considerações exclusivas sobre o TFM. A simples portabilidade do mercado de taxas existente da Ethereum para o Solana não é, obviamente, a solução, mas há lições valiosas a serem aprendidas com isso. Isso é altamente relevante para mecanismos que são ambos:

1. No protocolo - TFMs reforçados por consenso (por exemplo, EIP-1559 e SIMD-0110)
2. Fora do protocolo - PBS via MEV-Boost, melhorias no agendador Solana e leilões Jito

Tanto para a Solana quanto para a Ethereum, os mecanismos dentro e fora do protocolo parecem coexistir e evoluir juntos no futuro. O equilíbrio entre eles é uma das questões fundamentais no projeto desses sistemas. O debate em torno do SIMD-0110 geralmente gira em torno de dois pontos de vista opostos:

1. As melhorias no agendador e na rede para reduzir o jitter resolverão suficientemente os problemas descritos aqui, portanto, não são necessárias grandes alterações no TFM no protocolo.
2. Embora sejam necessárias melhorias no agendador fora do protocolo e na rede, elas são inerentemente insuficientes. É necessária a contrapressão econômica no protocolo.

A precificação multidimensional de recursos de alguma forma também é claramente valiosa em ambos os casos. A Ethereum está começando a buscar esse TFM no nível de recurso básico, com o EIP-4844 separando os dados de blob do mercado de execução. Por outro lado, Solana está avançando com a precificação de recursos multidimensionais no nível da conta individual para ser pioneira em "mercados de taxas locais".

A pesquisa de TFM aqui é de ponta, e os pesquisadores estão constantemente encontrando maneiras novas e inovadoras de melhorar o funcionamento das taxas no Solana e em outras cadeias. Estamos otimistas de que as propostas discutidas aqui continuarão a tornar o Solana ainda mais eficiente, dimensionável, fácil de usar e economicamente sustentável.

À medida que o Eclipse se aproxima do lançamento de nossa mainnet, também estamos animados para compartilhar mais sobre como aplicaremos esse trabalho existente à nossa própria TFM, que certamente continuará a evoluir nos próximos anos. Pretendemos experimentar e promover mecanismos nessa área. Um benefício essencial do paradigma modular é que ele permite uma polinização cruzada mais fácil da pesquisa e da engenharia de diferentes ecossistemas. Essa taxa de experimentação continuará a aumentar, beneficiando todos os que constroem aqui a longo prazo.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[Eclipse], com o título original 'Solana & Ethereum Transaction Fee Mechanisms: Proposals to Improve Solana's TFM', Todos os direitos autorais pertencem ao autor original[Eclipse]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.