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 pelos recursos escassos de uma forma que reflita o custo para a rede. As taxas também criam incentivos para os participantes da rede, como usuários, desenvolvedores de aplicativos e validadores.

Nesta série, exploraremos o atual mecanismo de taxas de Solana, formalizaremos o espaço de design para 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 funcionam as taxas da Solana hoje, com foco nas taxas baseadas em transações.

Definições

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

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

Lamport: a menor unidade atômica do SOL. 1 SOL é igual a um bilhão (10 ^ 9) de lamports.

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

CU usado: o número de unidades de computação usadas para executar uma transação. Apenas pós-execução conhecida.

UC solicitada: especificada pela transação; se a transação exceder esse orçamento de computação durante a execução, a execução será interrompida e a transação falhará. O máximo de UC solicitadas (e utilizadas) por transação é de 1.400.000 UCs.

Conta: uma única parte do estado no blockchain Solana.

Agendador: o mecanismo de construção contínua de blocos, incluído por padrão no cliente Solana desenvolvido pela Solana Labs.

Honorários de Solana

Taxas de transação

Hoje, uma transação Solana inclui duas taxas: uma taxa básica e uma taxa prioritária.

A taxa básica é fixada por assinatura em 5.000 lamports (0,000005 SOL, US$ 0,0003 a US$ 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 microlamports por UC solicitada. Observe que isso não é por UC usada, porque as UCs usadas não são conhecidas até que uma transação seja executada. As transações com taxa de prioridade mais alta são priorizadas de forma não determinística pelo escalonador. O mecanismo específico é descrito em Ciclo de Vida de uma Transação Solana.

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

Tanto para a taxa básica quanto para a taxa prioritária, 50% fica com o líder como 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 2.500 microlamports por CU solicitada. Como a transação tem uma assinatura, a taxa total da transação é de 5.000 lamports + 600.000 CU solicitados * 2.500 microlamports / CU solicitados = 6.500 lamports, ou 0,0000065 SOL.

Taxas estaduais

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

Comentário

Incentivos à Eficiência

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

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

Embora a taxa de prioridade inclua um incentivo para reduzir as UCs solicitadas e, portanto, as UCs utilizadas, esse incentivo é fraco na maioria das vezes e só entra em vigor em períodos de congestionamento. Uma modificação simples seria expandir a taxa base para exigir também uma taxa por UC solicitada. Isso incentivaria os desenvolvedores e remetentes de transações a reduzir o uso 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, isto 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 submetendo transações com taxas prioritárias de acordo com a sua verdadeira disposição a pagar.

O mecanismo de taxas de Solana não é compatível com incentivos para validadores e remetentes de transações hoje. Conforme descrito acima, 50% da taxa de transação fica com o líder e 50% é queimado. Como nem toda a taxa vai para o líder, isso cria um incentivo para o remetente da transação conspirar com o líder: em vez de especificar uma taxa prioritária para obter inclusão prioritária, o remetente pode, em vez disso, criar um acordo paralelo com o líder para pagar o taxa de prioridade fora da rede, eliminando o consumo e ainda recebendo prioridade.

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

Além da integração vertical direta, a principal forma de vermos esse side deal no mercado hoje é por meio dos leilões Jito. Os validadores que executam o Jito-Solana (uma modificação do cliente do Solana Labs) quebram o mecanismo contínuo de construção de blocos, executando um leilão de blockspace na primeira metade de seus slots.

Não observamos outros negócios paralelos no mercado hoje. Isto é porque:

• O cliente validador e seu escalonador são difíceis de modificar, portanto o custo de criação de tal arranjo requer um alto custo fixo. Softwares fora do protocolo, como Jito-Solana, e acordos de construção de blocos delegados, como PBS no Ethereum, amortizam o custo fixo de todos os validadores participantes.
• A grande maioria da receita do validador vem de recompensas inflacionárias, e 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 da transação especifiquem quais partes do estado são necessárias para executar a transação. Isto desbloqueia a execução paralela de transações e mercados de taxas localizadas, onde diferentes partes do estado cobram taxas diferentes com base no grau de controvérsia de uma determinada parte do estado. Um hotspot estadual localizado não precisa aumentar a contenção ou taxas em todo o blockchain.

Um equívoco comum sobre Solana é que hoje ele apresenta mercados de taxas locais. Embora seja verdade que uma transação que paga uma taxa de prioridade mais alta tem maior probabilidade de ser incluída em uma posição mais alta no bloco, e que o estado contestado provavelmente exigirá uma prioridade mais alta, esse comportamento não é determinístico e é resultado da implementação do padrão de inadimplência de Solana. algoritmo de agendamento. Exploramos isso mais detalhadamente em 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 escalonador. A construção contínua de blocos e a propagação de blocos do Solana evitam a ordenação determinística, a menos que grandes mudanças (por exemplo ordenação determinística e execução assíncrona) são implementadas.

Uma taxa base previsível e imposta por consenso para o acesso estatal, com base na contenção histórica, poderia melhorar a eficiência e a UX no acesso a estados altamente contestados. Isso aumentaria o custo do spam e, ao mesmo tempo, incentivaria os remetentes de transações a bloquear a quantidade mínima de estado de que realmente necessitam. Isso não resolveria a causa raiz do spam, que vem da construção contínua de blocos (portanto, a latência é importante) e do jitter. Exploraremos esse design posteriormente nesta série.

Externalidades

Como as transações são ordenadas principalmente por quando chegam ao líder (agendador), e esta ordem está sujeita tanto ao jitter quanto ao jitter da rede 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. possível. Tais transações trazem uma externalidade negativa na rede na forma de spam chegando à cadeia (em janeiro de 2023, 58% da computação na cadeia de Solana é usada na reversão de transações) e spam chegando ao líder.

Dos Laboratórios Jito

Conclusão

Neste artigo, descrevemos como funciona hoje o mecanismo de taxas de Solana e suas implicações na rede. Sugerimos algumas propriedades que um mecanismo de taxas ideal satisfaria, como dicas precisas para o escalonador (solicitado por CU), compatibilidade de incentivos e mercados de taxas verdadeiramente localizados. Na próxima parte, definiremos um formalismo para os objetivos que o mecanismo de taxas deve otimizar. Isto será utilizado para analisar o actual mecanismo de taxas, bem como as alterações propostas ao mecanismo, com mais rigor do que o aqui expresso.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [Umbra Research]. Todos os direitos autorais pertencem ao autor original [@0xShitTrader]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho 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.