Introdução

Os mecanismos de taxas são uma característica importante dos blockchains. Os mantenedores de rede, como os validadores, têm recursos finitos, por isso é importante cobrar por recursos escassos de uma forma que reflita o custo para a rede. As taxas também criam incentivos para os participantes da rede, tais como utilizadores, programadores de aplicações e validadores.

Nesta série, exploraremos o atual mecanismo de taxas de Solana, formalizaremos o espaço de design de um mecanismo de taxas e analisaremos algumas alterações propostas ao mecanismo de taxas de Solana.

Esta peça é a primeira da série. Aqui explicamos como as taxas da Solana funcionam hoje, com foco nas taxas baseadas em transações.

Definições

Estas são definições específicas da Solana necessárias para compreender o mecanismo de taxas.

Assinatura: pelo menos uma, e normalmente exatamente uma incluída por transação.

Lamport: a menor unidade atómica do SOL. 1 SOL é igual a mil milhões (10^9) lamports.

Unidade de computação (UC): uma unidade de computação, por instrução Solana-BPF, destinada a aproximar o custo para executar a instrução. Semelhante às unidades de gás no Ethereum.

UC utilizada: o número de unidades computacionais utilizadas para executar uma transação. Apenas conhecido após a execução.

UC solicitada: especificado pela transação; se a transação exceder este orçamento de cálculo durante a execução, a execução é interrompida e a transação falha. A UC máxima solicitada (e utilizada) por transação é de 1.400.000 CUs.

Conta: Um único pedaço de estado na cadeia de blocos Solana.

Scheduler: o mecanismo de construção de blocos contínuos, incluído por defeito no cliente Solana construído pela Solana Labs.

Taxas da Solana

Taxas de Transação

Hoje, uma transação Solana inclui duas taxas: uma taxa base e uma taxa de prioridade.

A taxa base é fixada por assinatura em 5000 lamports (0.000005 SOL, $0.0003 a $60/SOL) por assinatura; a grande maioria das transações Solana tem uma assinatura.

A taxa de prioridade opcional é especificada na transação e é denominada em microlâmpadas por UC solicitada. Note que isso não é por UC utilizada, porque as CUs utilizadas não são conhecidas até que uma transação seja executada. As transações com taxa de prioridade mais alta são priorizadas não deterministicamente pelo agendador. O mecanismo específico está descrito no Ciclo de vida de uma transação Solana.

As taxas são debitadas do pagador de taxas no início da execução da transação. Se o pagador não puder pagar a taxa exigida, a execução é ignorada, a transação é considerada inválida e não está incluída.

Tanto para a taxa base como para a taxa de prioridade, 50% é mantido pelo líder como um incentivo para incluir transações em blocos e 50% é queimado.

Neste exemplo de transação, a transação solicita 600.000 unidades de computação e define uma taxa de prioridade de 2500 microlamports por UC solicitada. Como a transação tem uma assinatura, a taxa total para a transação é de 5000 lamports + 600.000 UC solicitados* 2500 microlamports/UC solicitados = 6500 lamports, ou 0.0000065 SOL.

Taxas Estaduais

Solana cobra adicionalmente uma taxa para criar um novo estado chamado isenção de renda (termo legado). O custo atual da isenção de renda é de 6,96 SOL estático por MB. Quando uma nova conta é criada, a taxa é atribuída à conta; quando a conta é removida, a sua taxa de isenção de renda pode ser recolhida novamente.

Comentário

Incentivos para a Eficiência

Como a taxa base não é sensível à UC usada ou à UC solicitada, não há incentivo na taxa base para otimizar o uso de computação, nem para solicitar CUs próximas de quantas são realmente utilizadas. Na prática, muitas transações em Solana pedem muito mais UCs do que acabam por ser utilizadas. Isto cria ineficiências no agendador.

No exemplo de transação acima, a transação solicita 600.000 UCs mas usa menos de 250.000.

Embora a taxa de prioridade inclua um incentivo para reduzir as UCs solicitadas e, portanto, as UCs utilizadas, este incentivo é fraco na maior parte do tempo e só entra em vigor em períodos de congestionamento. Uma modificação simples seria expandir a taxa base para também exigir uma taxa por UC solicitada. Isto incentivaria os programadores e os remetentes de transações a reduzirem a sua utilização de computação e a solicitar apenas os recursos necessários.

Compatibilidade de incentivos

Um mecanismo é compatível com incentivos se todos os participantes no mecanismo alcançarem o seu melhor resultado agindo de acordo com as suas verdadeiras preferências. No contexto de um mecanismo de taxas, isso significa aproximadamente que o validador maximiza as taxas executando o algoritmo de construção de blocos padrão, e que os remetentes de transações maximizam o bem-estar enviando transações com taxas prioritárias de acordo com a sua verdadeira vontade de pagar.

O mecanismo de taxas da Solana não é compatível com incentivos para validadores e remetentes de transações hoje. Como descrito acima, 50% da taxa de transação é mantida pelo líder e 50% é queimada. Porque nem toda a taxa vai para o líder, isso cria um incentivo para um remetente da transação entrar em conluio com o líder: em vez de especificar uma taxa de prioridade para obter a inclusão prioritária, o remetente pode criar um acordo paralelo com o líder para pagar a taxa de prioridade fora da rede, cortando a queima enquanto ainda recebe a prioridade.

Os validadores que executam esse mecanismo em teoria recebem mais taxas e, portanto, podem oferecer recompensas mais altas aos seus participantes delegados, criando uma força centralizadora.

Para além da integração vertical direta, a principal forma de vermos este negócio paralelo no mercado hoje é através dos leilões Jito. Os validadores que executam o Jito-Solana (uma modificação no cliente da Solana Labs) quebram o mecanismo de construção de blocos contínuos, executando um leilão de blockspace na primeira metade dos seus slots.

Não observamos outros acordos paralelos no mercado hoje. Isto é porque:

• O cliente validador e o seu programador são difíceis de modificar, pelo que o custo de criar tal arranjo requer um custo fixo elevado. Software fora de protocolo como o Jito-Solana e arranjos de construção de blocos delegados como o PBS no Ethereum amortizam o custo fixo em todos os validadores participantes.
• A grande maioria das receitas do validador vem de recompensas inflacionárias, não de taxas de transação, portanto o benefício é relativamente baixo.

Mercados de Taxas Locais

Ao contrário da maioria dos outros blockchains, Solana exige que os remetentes das transações especifiquem quais partes do estado são necessárias para executar a transação. Isso desbloqueia a execução de transações paralelas e mercados de taxas localizados, onde diferentes partes do estado têm taxas diferentes com base no quão controverso é um determinado pedaço de estado. Um ponto de acesso de estado localizado não precisa aumentar a contenção ou as taxas em todo o blockchain.

Um equívoco comum sobre Solana é que hoje apresenta mercados de taxas locais. Embora seja o caso de uma transação que paga uma taxa de prioridade mais alta ter maior probabilidade de ser incluída mais alto no bloco, e esse estado contestado provavelmente exigirá maior prioridade, esse comportamento não é determinístico e é resultado da implementação do algoritmo de agendamento padrão de Solana. Exploramos isso mais no Ciclo de vida de uma transação Solana.

Em particular, este comportamento não é imposto por consenso, e a ordenação determinística por taxa de prioridade não é garantida, nem por consenso nem pela implementação do programador. A construção contínua de blocos e a propagação de blocos de Solana evitam a ordenação determinística, a menos que grandes alterações (por exemplo a ordenação determinística e a execução assíncrona) são implementadas.

Uma taxa base previsível e imposta por consenso para o acesso do Estado, com base em controvérsias históricas, poderia melhorar a eficiência e a experiência do utilizador para aceder a um estado altamente contestado. Isso aumentaria o custo do spam, incentivando adicionalmente os remetentes das transações a bloquearem a quantidade mínima de estado que realmente exigem. Não resolveria a causa raiz do spam, que vem da construção contínua de blocos (portanto, a latência é importante) e trepidez. Exploraremos este design mais tarde nesta série.

Externalidades

Como as transações são ordenadas principalmente quando chegam ao líder (agendador), e esta ordem está sujeita a trepidação da rede e instação devido à implementação do agendador paralelizado, há incentivo para transações de spam quando o remetente deseja que uma seja incluída o mais rápido possível. Tais transações trazem uma externalidade negativa na rede nas formas de spam que aterram na cadeia (a partir de janeiro de 2023, 58% do computador na cadeia de Solana é usado para reverter transações) e spam a chegar ao líder.

De Jito Labs

Conclusão

Nesta peça, descrevemos como o mecanismo de taxas da Solana funciona hoje e as suas implicações na rede. Demos a entender algumas propriedades que um mecanismo de taxa ideal satisfaria, tais como dicas precisas para o programador (UC solicitada), compatibilidade de incentivos e verdadeiros mercados de taxas localizados. Na próxima peça, definiremos um formalismo para os objetivos para os quais o mecanismo de taxas deve otimizar. Isso será usado para analisar o mecanismo de taxas atual, bem como as modificações propostas ao mecanismo, com mais rigor do que foi expresso aqui.

Isenção de responsabilidade：

1. Este artigo foi reimpresso da [Umbra Research]. Todos os direitos de autor pertencem ao autor original [@0xShitTrader]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.