Encaminhar o título original: Solana & Mecanismos de taxas de transação 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 pelos comentários e revisões.

Introdução

O Eclipse é o primeiro SVM L2 da Ethereum. Estamos incrivelmente entusiasmados por levar o poder do SVM existente a mais utilizadores, mas também estamos empenhados em fazer avançar a I&D em torno do próprio SVM. Estamos empenhados em garantir que o desenvolvimento do Eclipse represente um valor inegável para todas as cadeias SVM, especialmente a Solana.

Como precursor de futuros artigos sobre o nosso pensamento em torno dos mercados de taxas, este artigo analisará o atual mercado de taxas de Solana e as propostas associadas para o melhorar. Enquadramos estas propostas com os principais objectivos teóricos de qualquer mecanismo de taxas de transação (MTF), inspirando-nos em grande medida no trabalho de Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi e outros. Indicaremos as definições principais com **.

Em geral, uma TFM determina:

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

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

Visão geral de Solana & Ethereum TFMs actuais

Solana vs. Ethereum: noções básicas

Começaremos com uma visão geral da TFM do Solana e contrastá-la-emos com a do Ethereum. Deste modo, contextualizará melhor as propostas relevantes para que possamos trabalhar no sentido de modificar e melhorar o GFT. Para começar:

A taxa de base da Solana é de 5.000 lamports fixos (0,000005 SOL) por assinatura, e a maioria das transacções tem uma assinatura. Não tem em conta os recursos computacionais mais vastos de uma transação (medidos por UC).

Taxa de base de Solana Tx = (5 000 Lamports) x (# de assinaturas em Tx)

O mecanismo de taxa de base do Ethereum difere em dois aspectos principais:

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

Assim, a taxa de base por transação do Ethereum é:

Taxa de base Ethereum Tx =(preço do gás em vigor em gwei) x (gás utilizado em tx)

Os utilizadores do Solana podem também adicionar taxas de prioridade opcionais para melhorar a sua probabilidade de inclusão. Ao contrário da taxa de base, a taxa de prioridade tem um preço por UC solicitada para uma transação. As transacções Solana podem incluir as seguintes instruções de cálculo do orçamento:

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

Ponha-os juntos:

Taxa de prioridade Tx = (limite da CU Tx) x (preço da CU)

Note que esta taxa de prioridade é paga contra a totalidade das UCs solicitadas (independentemente de a transação utilizar ou não o montante total solicitado), ao contrário do Ethereum, onde a taxa é uma função da quantidade de gás que a transação realmente utiliza.

Queima de taxas vs. Recompensas do validador

Embora o incentivo para que os validadores dêem prioridade às transacções com taxas elevadas esteja fora do consenso, é imposto no consenso que tanto a taxa de base como a taxa de prioridade são 50/50 queimadas/enviadas para o líder (produtor do bloco atual) em Solana:

1. Taxa de base - Obrigatória para a inclusão no bloco. As transacções sem a taxa de base necessária serão rejeitadas.
2. Taxa de prioridade - Não é obrigatória para a inclusão no bloco. Utilizado para, opcionalmente, dar prioridade às transacções que pretendem aumentar a sua probabilidade de inclusão rápida.

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

Transferência direta*: Coordenada através dos leilões MEV-Boost / Jito-Solana

É importante notar que os validadores Solana votam em cada bloco com transacções na cadeia. Pagam a taxa de base por cada uma destas transacções.

A Solana tem vindo a registar ultimamente os seus máximos históricos em termos de taxas de rede, impulsionados por um forte aumento das taxas de prioridade. As recentes divisões de taxas são apresentadas abaixo:

Fonte: Solana Compass

Ethereum Block Builder vs. Solana Scheduler

A produção de blocos do Ethereum é geralmente mais fácil de compreender, pelo que começaremos por aí. Quase todos os validadores (a.k.a. os proponentes) subcontratam a produção de blocos a construtores fora do protocolo através do MEV-Boost. Os construtores criam blocos a cada 12 segundos (o tempo de slot do Ethereum) e passam estes blocos inteiros para o proponente (através de um relé), que selecciona o bloco de maior valor.

Tanto no Ethereum como no Solana, os produtores de blocos têm o poder de ordenar transacções arbitrariamente dentro de um bloco. São incentivados a fazê-lo de forma a maximizar o seu lucro. Por exemplo, diferentes construtores de Ethereum podem competir executando algoritmos proprietários que maximizam mais eficazmente os lucros em relação aos concorrentes.

Isto significa que, mesmo no Ethereum, o envio de uma taxa de alta prioridade não alcança qualquer garantia determinística in-protocolo de inclusão ou ordenação de blocos. No entanto, é muito provável que atinja o resultado esperado devido à natureza do atual processo de construção de blocos do Ethereum, em que 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 elevada (por exemplo, superior a todas as outras transacções elegíveis combinadas) ao construtor, solicitando a sua inclusão no topo do bloco e a exclusão total da transação do bloco se não obtiver a posição no topo do bloco. Neste caso, um construtor racional que maximize o lucro incluirá esta transação no topo do bloco, mesmo que só a tenha recebido perto do fim da sua janela de 12 segundos.

Repare que há duas garantias diferentes que as taxas estão a tentar alcançar aqui:

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

O mecanismo EIP-1559 do Ethereum provou ser bastante eficaz, permitindo aos utilizadores licitar facilmente a inclusão de blocos com uma elevada probabilidade de sucesso. Existe um preço de reserva global que todos sabem que devem pagar, e o seu pagamento (normalmente acompanhado de uma taxa de prioridade nominal) deve permitir que a transação de um utilizador seja incluída rapidamente. No entanto, o mecanismo não procura dar quaisquer garantias em matéria de ordenação (ou seja, acesso prioritário ao estado), ao passo que os mecanismos fora do protocolo são fiáveis para os utilizadores que procuram essas garantias (diretamente dos construtores, por exemplo).

O processo de construção de blocos de Solana funciona de forma muito diferente. Os agentes de validação não subcontratam a produção de blocos completos em intervalos de tempo discretos a 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 constrói blocos continuamente.

Além disso, as transacções Solana especificam quais as contas que devem ser bloqueadas para leitura e escrita para execução. Isto permite ao programador ordenar iterativamente quais as transacções que podem ser executadas em simultâneo - uma vez que as transacções que não tocam no mesmo estado podem ser executadas em paralelo.

Dentro de um bloco, pode ser utilizado um máximo de 12.000.000 CUs para escritas sequenciais numa única conta ("piece of state"). Esta é aproximadamente a quantidade de CUs que pode ser processada por um único thread por slot de 400ms em requisitos de nó razoáveis. O limite por bloco de Solana é então de 48.000.000 CUs. A implementação atual do agendador utiliza quatro threads para transacções que não são de voto, e 12M x 4 = 48M. Em teoria, isso significa usar mais núcleos = aumentar os limites de CU. Escalonamento com hardware.

O programador dá prioridade, de forma não determinística, às transacções com taxas de prioridade mais elevadas. No entanto, isto fornece geralmente garantias de priorização menos fiáveis do que mecanismos como os descritos atualmente no caso do Ethereum.

Em Solana, os validadores que executam o agendador predefinido constroem blocos continuamente, pelo que as transacções podem ser adicionadas a um bloco em curso e executadas antes de esperar pelo fim da ranhura para as organizar apenas por taxa de prioridade. A intenção é que o programador maximize o lucro, dando prioridade às transacções com base no seu preço total de CU.

O agendador multi-threaded predefinido do Solana também introduz "jitter" adicional. As transacções são atribuídas aleatoriamente a uma das quatro threads, sendo que cada thread mantém a sua própria fila de transacções à espera de execução. As taxas de prioridade são então utilizadas para dar prioridade às transacções intra-thread. No entanto, não ajudam a dar prioridade às transacções entre threads.

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

Note que estão planeadas alterações ao agendador predefinido do Solana, que visam resolver alguns dos problemas com a implementação atual, baseando-se num grafo de dependências de transacções e agendando as transacções desbloqueadas (não bloqueadas por escrita) de maior prioridade no grafo - abordaremos isto mais tarde neste artigo.

Embora esteja fora do âmbito deste artigo, o cliente Jito-Solana permite aos pesquisadores capturar o valor extraível máximo (MEV) de forma mais eficiente, de modo a minimizar as externalidades negativas em Solana. O Jito-Solana desvia-se do agendador predefinido do Solana introduzindo leilões de pacotes discretos de 200 milissegundos do tipo Flashbots fora do protocolo, que são executados em paralelo com a produção de blocos contínua predefinida e um mempool privado (que mais uma vez se desvia do TFM predefinido do Solana). A adoção do cliente Jito-Solana pelos validadores Solana (>50% dos validadores utilizam-no atualmente) ajudou a resolver alguns dos problemas com o TFM Solana existente - nomeadamente, a prevalência de spam com MEV.

Deficiências da atual GFT de Solana

Embora a TFM de Javier Solana seja muito promissora, também apresenta, por enquanto, algumas deficiências potenciais:

Incentivo ao spam

Como já foi referido, as transacções são ordenadas, de certa forma, segundo o princípio "primeiro a entrar, primeiro a sair" (FIFO), logo 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 contribuir para a probabilidade de inclusão em determinadas circunstâncias, continua a existir um incentivo substancial para que as transacções sejam enviadas para maximizar a probabilidade de inclusão mais rápida (por exemplo, um pesquisador que procura liquidar uma posição em incumprimento num mercado de empréstimos). A imagem abaixo, da Jito Labs, ajuda a demonstrar a natureza subóptima das transacções de spam.

Fonte: Fundação Jito

Leilão de primeiro preço

Num leilão ingénuo de primeiro preço (FPA), os utilizadores limitam-se a apresentar propostas, sendo a mais elevada incluída no bloco. Um problema com os APP é que não são muito fáceis de utilizar. Os utilizadores têm de adivinhar o que os outros utilizadores estão a licitar, pensando no que estão dispostos a licitar e, potencialmente, diminuindo a sua licitação para não pagarem a mais com base no que pensam que os outros estão a licitar, por exemplo.

Mais formalmente, o modelo FPA é não-DSIC:

**Estratégia dominante de incentivo compatível (DSIC): Partindo do princípio de que o produtor de blocos implementa honestamente a TFM, a estratégia de licitação prescrita deve ser a estratégia dominante para os utilizadores. Isto significa que os utilizadores licitarão (em taxas de transação) o valor exato que atribuem à inclusão da transação [Chu22].

A DSIC é uma das principais propriedades que os criadores da EIP-1559 pretendiam introduzir na TFM da Ethereum com a sua implementação e, tal como descrevemos anteriormente, pode ser considerada um sucesso. Os utilizadores sabem mais facilmente o preço de reserva público a incluir no bloco num determinado momento (através da taxa de base dinâmica), pelo que o seu pagamento (mais qualquer taxa de prioridade nominal) fará com que a sua transação seja quase sempre incluída rapidamente.

Por outro lado, o GFT de Solana é um APP ingénuo. Não dispõe de um mecanismo fiável que permita aos utilizadores exprimir com precisão a 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 difícil. Isto favorece desproporcionadamente os participantes sofisticados, que são mais capazes de contornar os desvios da rede e do programador (por exemplo, através de co-localização ou de transacções de spam).

50/50 Burn/Validator Payout

Como referido anteriormente, o Ethereum queima 100% da taxa de base e envia 100% da taxa de prioridade para o produtor do bloco, enquanto que para o Solana, tanto a taxa de base como a taxa de prioridade são 50/50 queimadas/pagas ao produtor do bloco. Por este motivo, 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 utilizadores e o produtor do bloco pode melhorar o resultado da TFM para um determinado bloco [Rou21]. Um protocolo c-SCP é resistente à possibilidade de uma coligação do produtor do bloco e de até c utilizadores poderem lucrar ao desviarem-se da informação verdadeira.

Vemos um exemplo claro disso com os leilões fora do protocolo da Jito-Solana, que pagam 100% das licitações (menos a parte da Jito) aos produtores de blocos, em vez de queimarem 50% - a Jito-Solana é um exemplo de um acordo fora da cadeia utilizado pelos produtores de blocos. No entanto, notamos que as gorjetas Jito-Solana não são equivalentes às taxas de prioridade, uma vez que 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 utilizado pelo leilão fora do protocolo do Jito-Solana) no protocolo como uma instrução nativa.

Falta de tipos de transacções privilegiadas

As transacções de votos Solana são lançadas na cadeia e devem ser incluídas em blocos, mas cada validador deve pagar os custos dessas transacções. Isto representa um custo fixo significativo (pago a título privado pelos agentes de validação), apesar da externalidade positiva da inclusão das transacções de voto. Este custo é exacerbado pelo facto de as transacções de votação serem sobretaxadas em relação às UC consumidas (ou seja, utilizam relativamente poucas UC em comparação com a transação média). A economia cria aqui um efeito centralizador, uma vez que o custo total da votação é praticamente constante para qualquer validador, enquanto as recompensas ganhas são proporcionais ao peso da aposta.

Fonte: Ceteris, Solana o Monólito

Como um aparte, uma lógica semelhante poderia ser estendida para incluir actualizações fiáveis de oráculos, que as redes normalmente cobram, apesar da externalidade positiva de preços precisos na cadeia. Uma cadeia mais opinativa que valorize muito um determinado oráculo robusto pode optar por consagrar um mecanismo que subsidie o seu custo.

Mercado local de taxas de Solana

A aproximação de Solana de um mecanismo de taxa local existe porque nenhuma conta pode escrever mais de 12M CUs por limite de bloco de 48M. Isto, juntamente com a natureza multi-threaded do agendador padrão do Solana, significa que um máximo de 25% das transacções num bloco pode corresponder a uma única peça de estado a pedido. Em teoria, os utilizadores de estados menos solicitados não deveriam ter de aumentar as suas taxas de prioridade para obterem garantias de inclusão fortes, em comparação com os utilizadores de estados mais solicitados.

Não se trata de um verdadeiro mecanismo de taxas locais. O mecanismo não é aplicado por consenso (é apenas ao nível do programador) e a relação entre as taxas de prioridade e a inclusão de blocos é bastante não-determinística (como mencionado anteriormente). Falta-lhe também uma noção de "elasticidade" quando existem limites de recursos máximos e objectivos.

Utilização ineficiente da UC & Pedidos

Uma vez que a taxa de base da Solana não tem em conta as UC, não incentiva as transacções a:

1. Utilize as UCs de forma eficiente - Uma transação com 1,4 milhões de UCs acarreta a mesma comissão de base que uma transação com 100 mil UCs, se tudo o resto for igual.
2. Solicite CUs de forma eficiente - Mesmo que uma transação utilize 50k CUs, tem a mesma taxa de base quer solicite 100k CUs ou 1M CUs.

Isto pode levar a uma sobrestimação da computação necessária num determinado bloco pelo programador e a uma perda de eficiência em comparação com os recursos exigidos pelo produtor do bloco numa determinada faixa horária. Uma TFM DSIC resolveria este problema, uma vez que a estratégia dominante de um utilizador seria a da estratégia de licitação prescrita - neste caso, representando com precisão a utilização esperada das UC.

Não tem custos para escrever contas de bloqueio

Como mencionado anteriormente, as transacções Solana especificam antecipadamente todas as contas que irão ler ou escrever durante a execução. No entanto, este mecanismo pode ser abusado atualmente para bloquear globalmente qualquer conta sem qualquer custo. Por exemplo:

1. Envio_TxA que especifica que vai escrever na_ContaA.
2. O líder recebe_TxA, agenda-o e começa a executá-lo. A_contaA está agora bloqueada - nenhuma outra transação que toque na_contaA pode ser executada até que_TxA termine a sua execução.

O problema resulta do facto de qualquer pessoa poder enviar transacções que bloqueiam por escrito as contas que quiser. Não há qualquer custo para bloquear contas e as transacções podem até bloquear contas que não utilizam, o que é um claro vetor de ataque de spam. Além disso, os proprietários da conta não têm controlo sobre quem pode bloquear a sua própria conta.

Propostas de GFT & Quadros

Cada blockchain deve, em última análise, decidir como atribuir o escasso recurso do seu espaço de blocos finito entre os utilizadores, o que faz através do seu TFM. De seguida, discutiremos várias propostas e quadros relevantes de GFT que poderão ser úteis para Solana.

Mercados multidimensionais de taxas de cadeia de blocos

A maioria dos mercados de taxas existentes são unidimensionais, construídos em torno de uma única unidade de conta fungível (por exemplo, gás em Ethereum). No entanto, este recurso único adquirido é um substituto 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 Ethereum tem uma certa 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 código de operação foi definido como uma aproximação grosseira dos recursos subjacentes que utilizam e do seu custo para os nós da rede. Por exemplo, esta medida implícita do custo de uma operação pode ser determinada através da execução de testes de referência em hardware do mundo real.

No entanto, também é possível construir mercados de taxas multidimensionais que atribuem preços individuais a estes diferentes recursos não fungíveis, em vez de os combinarem numa única unidade. O EIP-4844 é um mercado de taxas bidimensional simples, uma vez que os blobs de dados têm o seu próprio mercado de taxas independente do gás de execução Ethereum.

Este documento de 2022 de Diamandis, Evans, Chitra e Angeris analisa a forma de construir mercados de taxas multidimensionais como este. O seu trabalho enquadra o problema de construção da TFM na perspetiva de um projetista de rede que pretende maximizar o bem-estar (ou utilidade total) dos utilizadores da cadeia de blocos menos o consumo de recursos desses utilizadores, sujeito às restrições de transação e de blocos da cadeia (por exemplo, limites de contratos inteligentes ou limites de CU/gás). O principal resultado do documento é que, apesar de o bem-estar ser desconhecido, concebe um mecanismo que o maximiza e mostra como construir explicitamente esse mecanismo.

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

A sua principal conclusão é que é possível implementar uma TFM equivalente, ou seja, uma TFM em que o preço do recurso é fixado de modo a minimizar a diferença entre o bem-estar dos validadores e dos seus utilizadores - esse preço deve conduzir a blocos que, em teoria, são óptimos do ponto de vista da maximização do bem-estar. Embora este trabalho possa ser visto mais como um quadro académico para a conceção de TFMs óptimos, ajuda a mostrar que a fixação de preços de recursos separadamente pode tornar uma cadeia de blocos mais eficiente e mais resistente a períodos de elevado congestionamento ou spam. Os mecanismos de taxa de base baseados em controladores, como a EIP-1559, são destacados como uma abordagem potencial que poderia funcionar excecionalmente bem nas cadeias Solana e SVM, dados os curtos tempos de bloqueio, permitindo que a taxa de base se ajuste rapidamente às mudanças na procura dos utilizadores e na disponibilidade de recursos.

Como mencionado anteriormente, uma das conclusões do documento é que é possível conceber formas sistemáticas e computacionalmente eficientes de ajudar a definir e atualizar o preço dos recursos multidimensionais para as cadeias de blocos. No entanto, uma pergunta natural deveria ser: que recursos faria sentido atribuir um preço distinto? Foram realizados alguns trabalhos práticos noutros contextos de cadeias de blocos para tomar essas decisões. Por exemplo, a Penumbra implementou uma forma de fixação de preços de recursos multidimensionais para fixar o preço dos recursos utilizados por nós completos e dispositivos de utilizador final separadamente na sua cadeia de blocos centrada na privacidade.

Embora o documento de 2022 aborde geralmente a fixação de preços multidimensionais de recursos de base (por exemplo, computação, largura de banda, armazenamento), também é possível implementar a fixação de preços multidimensionais de recursos por conta (ou seja, por "pedaço de estado"). Cada conta é tratada como um recurso diferente. Esta questão é discutida neste artigo recente, que se baseia no artigo original. O estabelecimento de preços individuais para as contas (em vez de computação, armazenamento, largura de banda, etc.) como recurso subjacente pode também ser mais simples de implementar, com um risco reduzido de ataques de esgotamento de recursos.

Taxa exponencial para contas com bloqueio de escrita

No seguimento do recente post de Anatoly sobre a Economia da Execução de SVM, Tao Zhu, em colaboração com Anatoly, propôs o SIMD-0110. A sua principal motivação é dissuadir o spam através de uma contrapressão económica (ou seja, aumentando as taxas de uma forma orientada ao longo do tempo para reduzir o incentivo ao spam), o que resulta numa utilização mais eficiente dos recursos da rede. As transacções de arbitragem falhadas continuam a preencher cerca de metade (ou mais) do espaço de blocos de Solana porque é racional e incrivelmente barato fazer spam.

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

A ideia básica de implementação da taxa variável de bloqueio de escrita baseada na conta 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 monitorizadas é 2048, sendo que apenas as contas mais contenciosas com a taxa de custo de bloqueio de escrita mais elevada são monitorizadas.
3. Se a utilização da unidade de computação EMA de uma conta for >50% do seu limite máximo de CU, a sua taxa de custo de bloqueio de escrita 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 escrita de 1000 micro-lamports/CU e uma taxa de ajustamento da taxa de custo de 1% por slot (note que as percentagens exactas aqui estão todas sujeitas a alterações, dada a natureza inicial da proposta).
5. A taxa de bloqueio de escrita para uma conta num determinado bloco é calculada multiplicando a taxa de custo de bloqueio de escrita pelas UCs solicitadas da transação.
6. As transacções continuam a pagar taxas de assinatura e as taxas de prioridade opcionais também se mantêm.
7. As taxas de bloqueio de escrita cobradas são 100% queimadas.
8. As taxas de prioridade cobradas são 100% recompensadas.
9. As taxas de assinatura cobradas são 50% queimadas e 50% recompensadas.

Esta proposta tornaria a funcionalidade de bloqueio de escrita do Solana (normalmente) DSIC semelhante à forma como a EIP-1559 tornou o TFM do Ethereum (normalmente) DSIC e MMIC [Rou23] - exceto na presença de picos súbitos de taxas.

Pode definir a propriedade MMIC da seguinte forma:

**Compatibilidade de incentivos do mineiro míope (MMIC): O produtor de blocos maximiza a sua utilidade não criando transacções falsas e seguindo as regras estabelecidas da TFM. Míope significa que este objetivo só diz respeito ao bloco atual quando se julga a maximização da utilidade [Rou21].

Qualquer mecanismo de rastreio é imperfeito, na medida em que pode não representar com precisão a situação atual exacta da procura. Por exemplo, a procura pode ser baixa durante um longo período de tempo (e, por conseguinte, a taxa de base dinâmica é baixa) e, em seguida, aumentar subitamente para uma hortelã NFT. Este pode ser o caso a nível global (como na TFM do Ethereum) e pode ser ainda mais volátil a nível local por conta (como é considerado no SIMD-0110).

No entanto, Solana também beneficia dos seus tempos de bloqueio incrivelmente baixos. Estes podem permitir que a taxa de base se ajuste mais rapidamente a um choque súbito da procura, dependendo da agressividade com que a curva é definida para se mover. A forma do controlador de taxas é aqui extremamente importante.

O facto de esta taxa de bloqueio de escrita ser cobrada sobre as UC solicitadas também incentiva adequadamente os utilizadores e os programadores a estimarem com precisão a utilização de uma UC de uma transação. Isto evita a questão que discutimos anteriormente, em que a atual base de assinatura plana não tem qualquer penalização por pedir muito mais CUs do que o necessário (mesmo até ao máximo de CUs de 1,4 mm). Caso contrário, apenas a taxa de prioridade tem atualmente este incentivo (uma vez que também é cobrada pelas UC solicitadas).

Uma crítica potencial a este respeito é que os mercados de taxas locais baseados em contas (especialmente esta proposta, que exige o cálculo contínuo de uma EMA para cada conta) podem ser computacionalmente dispendiosos. Este tipo de taxa multidimensional não tem limites, uma vez que qualquer conta pode estar congestionada, o que provavelmente apresentaria dificuldades para uma TFM deste tipo. No entanto, no caso do SIMD-0110, isto é evitado através da definição de um limite superior para o número de contas cuja EMA de utilização da CU pode ser monitorizada num determinado momento.

**Computável de forma eficiente: O mecanismo de leilão de blocos deve ser concebido de forma a poder ser computado eficientemente para um determinado produtor (ou construtor) de blocos - as ranhuras do Eclipse e do Solana são inferiores a 400ms, o que impõe uma restrição rigorosa ao tempo máximo de computação para um determinado bloco.

Dado que a inclusão de blocos Solana continuaria a ser não determinística, mesmo com esta proposta implementada, pode ainda haver problemas com os utilizadores que actualizam com precisão as suas ofertas em tempo real para garantir que as suas transacções são incluídas nos blocos. Para resolver este problema, são necessárias alterações ao programador, como discutiremos na próxima secção.

Alterações ao agendador predefinido do Solana

Como discutido anteriormente, o "scheduler" é o algoritmo padrão incluído no cliente validador da Solana Labs, que agenda as transações para execução e constrói blocos continuamente. Desempenha um papel extremamente importante no mercado de taxas do Solana, embora o seu comportamento por defeito não seja aplicado no protocolo, uma vez que os validadores podem optar por executar outros algoritmos. Vamos concentrar-nos no atual agendador e nas próximas alterações propostas, que estão a ser trabalhadas por Andrew Fitzgerald.

O atual programador do Solana introduz "jitter" no tratamento das transacções dos utilizadores, atribuindo-as aleatoriamente a uma das quatro threads de transacções que não são de voto (duas threads adicionais estão reservadas para o processamento de transacções de voto) antes de tentar ordenar as transacções pendentes por taxa de prioridade e verificar os bloqueios relevantes ("lock grab"), como mostra o diagrama abaixo. Vários lotes de transacções são retirados para serem atribuídos a threads durante a "Fase Bancária" - o processo executado por um validador Solana em que as transacções são processadas e no âmbito do qual ocorre o processo de programação.

Fonte: Andrew Fitzgerald, responsável pelo planeamento e pela fase bancária de Solana

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 transacções com os mesmos bloqueios de leitura ou escrita ou com bloqueios sobrepostos, o que significa que essas transacções devem ser reprogramadas para execução posterior. O resultado disto, no entanto, é que, no pior dos casos, apenas um dos quatro threads do programador predefinido pode estar a executar transacções num determinado momento.

O ponto crucial da atualização do agendador padrão do Solana está na transição da abordagem legada (chamada de modo ThreadLocalMultiIterator) para a nova abordagem de agendamento, chamada de modo CentralScheduler. O presente artigo apresenta apenas uma panorâmica e uma análise das alterações. No entanto, pode encontrar mais informações no artigo de Andrew Fitzgerald e num 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 equipa Tiny Dancer. Apresenta-se de seguida uma síntese do novo processo de programação.

Fonte: Andrew Fitzgerald, responsável pelo planeamento e pela fase bancária de Solana

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

O programador utiliza um algoritmo designado por "prio-graph", que é um gráfico acrílico direto que começa com as transacções de prioridade mais elevada (taxa) e linhas (ou, mais precisamente, arestas) entre uma dada transação de prioridade mais elevada e as seguintes transacções de prioridade mais elevada que entram em conflito com ela devido a bloqueios sobrepostos. Isto é feito (provisoriamente) para uma janela de "look-ahead" de um tamanho pré-configurado de 2.048 (sujeito a alterações) transacções, que podem ser adicionadas ao gráfico - os gráficos seguintes mostram o funcionamento do prio-gráfico para um determinado conjunto de transacções em que as arestas entre elas representam bloqueios em conflito.

Para além de adotar o programador de grafos primários, esta versão introduz eficiências adicionais para ajudar a reduzir a sobrecarga de processamento, como a remoção dos elementos redundantes da fase bancária. O novo agendador deve melhorar, reduzindo significativamente a probabilidade de falhas de escrita e bloqueio de leitura durante os períodos de grande atividade em 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 escrita de conta rebatível de programa (PRAW)

Da autoria de Godmode Galactus e Max Schneider, o SIMD-0016 propõe taxas de Program Rebatable Account Write (PRAW). Dariam um controlo significativo aos criadores de aplicações, uma vez que estes poderiam definir os critérios de pagamento e de descontos destas taxas, permitindo-lhes incentivar e desincentivar o comportamento dos utilizadores como entenderem.

Atualmente, os programas Solana não têm a capacidade de penalizar as transacções por adquirirem bloqueios de escrita sobre o seu estado. As taxas PRAW permitiriam aos proprietários de contas Solana cobrar por transacções falhadas que bloqueiam o seu estado. Estas taxas seriam transferidas para a conta escriturável que estão a bloquear. No entanto, os proprietários de contas podem definir estas taxas de modo a que sejam devolvidas ao utilizador no final da transação, se esta cumprir os critérios especificados.

Em particular, isto pode dissuadir os utilizadores de bloquear por escrito contas que não utilizam efetivamente na execução da transação. Isto é atualmente possível, uma vez que Solana não dispõe de controlos para verificar se uma determinada conta seria utilizada, a priori, por uma determinada transação que a bloqueou por escrito. Os PRAWs oferecem aos programas uma forma de desincentivar as transacções que bloqueiam o estado do programa numa tentativa de identificar uma oportunidade com a intenção de reverter se a oportunidade já não for válida no momento da execução. Estas taxas seriam aplicadas mesmo que a transação falhasse durante a execução.

Por outro lado, os utilizadores podem especificar o montante máximo de taxas PRAW que estão dispostos a pagar numa transação. Qualquer taxa especificada na transação acima da taxa PRAW atual para uma determinada conta bloqueada por escrito será reembolsada.

Os membros da comunidade Solana assinalaram problemas com esta proposta: a possibilidade de diferentes programas funcionarem de forma totalmente autónoma parece não ser a ideal e a capacidade de estimar as taxas com precisão seria difícil. Além disso, existem maneiras potencialmente mais simples e uniformes de lidar com esses problemas de griefing em torno de contas bloqueadas por escrita, como o SIMD-0110.

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

A proposta PRAW poderá não conseguir impedir o spam, pois depende suficientemente dos criadores de aplicações: 1) serem capazes de distinguir o spam do "comportamento normal" e 2) optarem voluntariamente por cobrar mais por uma externalidade negativa pela qual são parcialmente responsáveis, quando pode não ser do seu interesse fazê-lo e podem simplesmente optar por não o fazer.

Em contrapartida, embora os membros da comunidade de investigação de Solana estejam inegavelmente divididos quanto à introdução de taxas de base da EMA, existe um acordo geral quanto à adição de uma componente da taxa de base que se adapte às UC. Isto pode incentivar uma estimativa exacta das UCs e uma utilização eficiente das UCs por parte dos promotores.

Pensamentos de despedida

Os objectivos únicos de engenharia e desempenho de Solana exigem considerações únicas sobre o TFM. A simples portabilidade do mercado de taxas existente no Ethereum para o Solana não é, obviamente, a solução, mas há lições valiosas a aprender com ele. Isto é muito importante para os mecanismos que são ambos:

1. No protocolo - TFMs reforçadas por consenso (p. ex., EIP-1559 e SIMD-0110)
2. Fora do protocolo - PBS através de MEV-Boost, melhorias do programador Solana e leilões Jito

Tanto para o Solana como para o Ethereum, os mecanismos protocolares e extra-protocolares parecem susceptíveis de coexistir e evoluir em conjunto no futuro. O equilíbrio entre eles é uma das questões fundamentais na conceção destes sistemas. O debate em torno do SIMD-0110 centra-se frequentemente em dois pontos de vista opostos:

1. Os melhoramentos do programador e da rede para reduzir o jitter resolverão suficientemente os problemas aqui descritos, pelo que não são necessárias grandes alterações à TFM no protocolo.
2. Embora sejam necessárias melhorias no agendador fora do protocolo e na rede, estas são inerentemente insuficientes. É necessária uma contrapressão económica no protocolo.

A fixação de preços multidimensionais dos recursos, sob alguma forma, é claramente valiosa também em ambos os casos. O Ethereum está a começar a procurar uma TFM deste tipo ao nível dos recursos de base, com o EIP-4844 a separar os dados de blob do mercado de execução. Por outro lado, Solana está a avançar com a fixação de preços multidimensionais dos recursos ao nível das contas individuais para criar "mercados de taxas locais".

A investigação sobre TFM é de ponta e os investigadores estão constantemente a encontrar formas novas e inovadoras de melhorar o funcionamento das taxas em Solana e noutras cadeias. Estamos optimistas quanto ao facto de as propostas aqui discutidas continuarem a tornar Solana ainda mais eficiente, escalável, fácil de utilizar e economicamente sustentável.

À medida que o Eclipse se aproxima do lançamento da nossa mainnet, estamos também entusiasmados por partilhar mais sobre a forma como vamos aplicar este trabalho existente à nossa própria TFM, que irá certamente continuar a evoluir nos próximos anos. Tencionamos experimentar e fazer avançar os mecanismos neste domínio. Uma vantagem essencial do paradigma modular é o facto de permitir uma polinização cruzada mais fácil da investigação e da engenharia de diferentes ecossistemas. Este ritmo de experimentação vai agora continuar a aumentar, beneficiando todos os que constroem aqui a longo prazo.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[Eclipse], Encaminhe o Título Original'Solana & Mecanismos de Taxa de Transação Ethereum: Propostas para melhorar o TFM de Solana', Todos os direitos autorais pertencem ao autor original[Eclipse]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.