Introdução: por que minhas transações não estão incluídas?

Uma transação Solanajornadada submissão do usuário à inclusão no bloco pode ser árduo. Mesmo uma vez que a transação alcance o líder atual, ela deve competir com outras transações por espaço limitado no bloco. Incluir transações de forma puramente por ordem de chegada encoraja spam e pode bloquear transações de alto valor de usuários comuns. Para resolver esse problema, precisamos de um mecanismo de taxa.

Taxas prioritárias para o resgate?​

Taxas de prioridade resolvem esse problema, correto? Infelizmente, não para a maioria dos usuários.

Imagine este cenário. Você quer ir ao cinema da sua cidade, que tem 100 lugares, mas o cinema tem um sistema de venda de ingressos anormal: eles não publicam o preço do ingresso. Em vez disso, você tem que dizer a eles quanto você está disposto a pagar. (Digamos que seja $50.) Se a demanda for alta e pelo menos outras 100 pessoas apresentarem um preço mais alto, azar o seu. Se a demanda for baixa, você conseguiu! O problema: você está pagando $50 mesmo que o cinema esteja vazio. Mas a experiência de compra de ingressos não termina aí. Este sistema tem outra peculiaridade: você tem que dizer ao cinema sua disposição de pagar antes de sair de casa. Obviamente, conseguir um ingresso de cinema neste sistema é potencialmente uma experiência difícil para o indivíduo comum. Pessoas ricas e sofisticadas, por outro lado, podem estimar com precisão o preço do ingresso. Elas podem instalar câmeras ao lado do cinema para monitorar o tráfego em tempo real. Elas podem usar esse tráfego e os dados históricos coletados para estimar a demanda em um determinado dia. E até podem comprar um helicóptero para ir mais rápido ao cinema depois de dizer ao cinema sua disposição de pagar. Embora seja possível usar este sistema de venda de ingressos de forma eficaz, a experiência é horrível para a maioria das pessoas que querem ir ao cinema. Quando o cinema está lotado, muitas dessas pessoas podem nem se incomodar em tentar ir.

Da mesma forma, a taxa de prioridade "verdadeira" necessária para uma transação Solana é difícil de estimar.Isso flutua muitoDurante períodos de alta congestão, as carteiras usando médias recentes provavelmente superestimarão a taxa necessária, fazendo com que os usuários paguem a mais pela inclusão da transação. (E mesmo com uma taxa de prioridade alta, uma transação ainda pode não estar incluídoDevido à natureza da produção contínua de blocos multi-threaded.) Na teoria, as taxas prioritárias podem alocar de forma ótima o espaço do bloco. Na prática, elas falham completamente. Felizmente, existem maneiras de resolver esses problemas, resultando em transações mais baratas com uma melhor chance de inclusão para a maioria dos usuários. Antes de mergulharmos na solução, vamos examinar algumas propriedades do recurso que estamos tentando alocar: espaço de bloco.

Espaço de bloco: oferta fixa, demanda extremamente fluctuante​

Transações na Solana são verificadas e executadas de forma independente por uma rede descentralizada de validadores. Como esses validadores têm recursos computacionais limitados, a Solana limita os recursos computacionais totais, medidos em unidades de computação (CUs), que podem ser utilizados por bloco. Quando a demanda por espaço em bloco aumenta além da oferta limitada, esse recurso fixo deve ser alocado entre transações concorrentes.

De certa forma, o mercado pode lidar com a alocação de espaço de bloco através da precificação; transações com maior utilidade para o remetente estão dispostas a pagar um preço mais alto. No entanto, esse mecanismo não funciona quando os usuários não sabem qual é o preço do espaço de bloco! Como discutido acima, uma taxa de prioridade sozinha leva a preços de transação difíceis de estimar para a maioria dos usuários e tem garantias de inclusão de transação ruins. Outras blockchains resolveram esse problema implementando um mecanismo de taxa de transação (por exemplo, EIP-1559 no Ethereum, e taxas multidimensionais em AvalancheePenumbraEsses mecanismos de taxa implementam uma taxa base fácil de estimar que fornece uma "taxa de entrada" previsível para a rede; essa taxa base se aproxima do preço real para a inclusão da transação.

Revisão: Taxas Solana hoje​

Solana implementa atualmente dois mecanismos de taxa: uma taxa base e uma taxa de prioridade. Podemos pensar na taxa base como uma "taxa de entrada" para usar a rede e na taxa de prioridade como uma gorjeta extra para incentivar os validadores a incluir uma transação em vez de outra. A taxa base da Solana é de 5000 lamports fixos por assinatura (geralmente uma por transação). Como resultado, os usuários que enviam transferências simples pagam a mesma taxa base que os usuários que jogam jogos pesados em computação on-chain e os pesquisadores que tentam capturar oportunidades complicadas de MEV. Assim, a taxa base atualmente cobrada não captura com precisão o uso de recursos de uma transação (e a "externalidade", na linguagem econômica), resultando potencialmente empouco utilizado espaço de bloco.

No nosso exemplo de teatro, uma taxa base igualmente fixa cobraria o mesmo preço de um espectador que compra 1 assento e de outro que compra todos os 100 assentos.

Por que um mecanismo de taxa base?​

As taxas base devem, em vez disso, ser uma função dos recursos utilizados. Este consumo é atualmente medido em unidades de computação (CUs), mas também poderia incluir outros recursos, como acesso à conta. Queremos que o usuário tenha um custo de participação mais previsível, dado por uma taxa base dinâmica. Estas taxas são difíceis de serem definidas corretamente. (Há muita pesquisa acadêmica,incluindo o nosso próprioNo entanto, qualquer pessoa que tenha sofrido com transações falhadas devido à congestão de rede sabe que as taxas também são importantes para acertar se quisermos que uma rede cresça.

No final, muitos usuários que desejam enviar transações não têm certeza do que pagar pelas taxas prioritárias. Superestimam essas taxas e pagam muito. Subestimam essas taxas e a transação não será incluída. Por outro lado, para as taxas básicas, os usuários pagam exatamente a taxa publicada atualmente. Gostaríamos que a taxa básica capturasse com precisão o verdadeiro custo de inclusão para transações. Aqui, assumimos que todas as transações alcançam o escalonador, mas competem por um espaço limitado de bloco, incluindo acesso computacional e de conta. Durante períodos de alta demanda, nem todas as transações podem ser incluídas. Neste post, delineamos os passos rumo a um mecanismo dinâmico de taxa básica que pode ajudar a desobstruir a rede e fornecer uma inclusão de transação mais previsível.

Além disso: taxas de prioridade e MEV​

Taxas de prioridade podem ser vistas alternativamente como pagamentos por oportunidades específicas que são limitadas por algo que não seja o consumo de recursos. Por exemplo, se dois pesquisadores enviam simultaneamente transações para liquidar um empréstimo específico, apenas uma dessas transações pode ser executada com sucesso; apenas a primeira transação no bloco liquida com sucesso o empréstimo. Portanto, as taxas de prioridade muitas vezes pagam pela ordenação de transações e não apenas pela inclusão. Esse uso de taxas de prioridade para capturar oportunidades de MEV é algo um pouco distinto deste post—vejaMEV na Solanapara mais discussão. Neste post, concentramo-nos nas taxas base e na inclusão de transações.

Blocos ótimos

Antes de discutir como definir taxas base, consideraremos um mecanismo fictício para inclusão de blocos: um designer de rede onisciente escolhe transações para cada bloco que maximizam o bem-estar dos usuários (a utilidade total ou 'felicidade' de uma transação ser incluída), menos o custo de consumo de recursos da rede, sujeito a restrições de transação (por exemplo, restrições de contratos inteligentes, limites de computação, etc.). Claro, o bem-estar do usuário é desconhecido e inquantificável pelo designer de rede na prática, e o designer de rede não constrói os blocos. No entanto, podemos usar esse problema como um ponto de referência mental para um bloco 'ótimo' construído a partir das transações que chegam ao escalonador. Nosso objetivo é projetar um mecanismo de taxa que se aproxime desse ponto de referência.

Embora esse mecanismo de construção de blocos fictício seja intratável, acaba por se verificar que podemos criar um mecanismo equivalente que é implementável na prática. Esse mecanismo equivalente busca encontrar os preços dos recursos que minimizam a diferença entre o bem-estar da rede e o dos seus usuários. A definição correta dos preços dos recursos alinha os incentivos de forma que os custos dos recursos para a rede sejam exatamente equilibrados pela utilidade obtida pelos usuários e validadores, mesmo que a rede não tenha ideia do que é essa utilidade e os usuários nunca a especifiquem explicitamente. Esses preços levam então a blocos que são “ótimos” em média. Assim, podemos nos concentrar apenas na definição desses preços. (Para mais detalhes técnicos, confiraeste papel.)

Em direção a um mecanismo

Como, então, definimos preços para incentivar blocos ótimos, como discutido acima? Uma primeira abordagem pode ser cobrar uma quantia fixa por unidade de computação usada por uma transação. Infelizmente, esta abordagem não funcionará. Se a demanda for baixa, então este preço fixo por UC fará com que os usuários não enviem transações, e os blocos podem estar quase vazios. Se a demanda for alta, então este preço fixo pode ser muito baixo e, como resultado, não fará nada para aliviar a congestão da rede ou aproximar o verdadeiro custo da inclusão da transação (nosso objetivo original!). Assim, precisamos ter alguma forma de aumentar e diminuir a taxa base com base na demanda da rede, e também alguma forma de estimar essa demanda.

Taxas base dinâmicas

O próximo passo é adicionar um controlador que ajuste a taxa por unidade de cálculo com base no uso passado. Por exemplo, se houver uma meta de uso por bloco (ou seja, um uso ideal em estado estável para a cadeia), podemos aumentar ou diminuir a taxa base com base na utilização ou na diferença desta meta. Muitos mecanismos, incluindo aqueles como EIP-1559, implemente essa ideia. Podemos ser tentados a atualizar dinamicamente a taxa base dentro de um único bloco usando a demanda em tempo real, ou a incentivar cada líder a escolher suas próprias regras de atualização de taxa. No entanto, essas mudanças reduziriam a previsibilidade da taxa base, derrotando o propósito original desse mecanismo de taxa. A escolha do mecanismo determina, em última instância, a experiência do usuário.

Felizmente, os tempos de bloco rápido da Solana permitem algoritmos agressivos para definir a taxa base. Por exemplo, podemos aumentar rapidamente o preço durante períodos de alta demanda (por exemplo, o dobro do preço para cada bloco cheio) e, em seguida, diminuir o preço mais lentamente à medida que a demanda diminui. O preço ainda cairá razoavelmente rápido devido aos curtos tempos de bloco da Solana. Intuitivamente, quando um recurso específico está "sobrecarregado", a rede está significativamente cobrando menos e obtendo menos informações sobre qual deve ser o preço ótimo. Tipos semelhantes de algoritmos são usados na prática em Controle de congestionamento TCP, a camada de ligação de dados das comunicações sem fio, e otimização do mercado.

Taxas multidimensionais: mercados de taxas locais

A discussão anterior considerou um recurso conjunto compartilhado por todas as transações: unidades de cálculo (globais). No entanto, o acesso ao estado no Solana também impacta significativamente o uso de recursos da transação. Se muitas transações acessam a mesma parte do estado, elas não podem ser executadas em paralelo e, portanto, reduzem a taxa de transferência da rede. Naturalmente, gostaríamos que essas transações pagassem uma taxa base mais alta, motivando mercados de taxas por conta (locais). (A questão de quem recebe essas taxas está além do escopo deste post; mais sobre isso no futuro.)

Como exemplo concreto, vamos considerar um popular lançamento de NFT. Sem mercados de taxas por conta, esse lançamento aumentaria significativamente a taxa base para todas as outras transações. Com taxas por conta, o custo de enviar transações para reivindicar um NFT (e acessar essa parte do estado) pode aumentar, enquanto as taxas para outras transações (como completar o colateral em um empréstimo) permanecem em grande parte inalteradas. Esse tipo de design de mercado de taxas local por conta está sendo considerado em um Rascunho do Documento de Melhoria da Solana.

Essas taxas multidimensionais também podem levar em conta correlações entre contratos. Por exemplo, se duas trocas de cNFT negociam muitas das mesmas coleções, seus contratos requerem acesso a muitas das mesmas contas. Se o volume de negociação aumentar dramaticamente para uma coleção específica em uma dessas trocas, então a taxa base aumentará para essa coleção na outra, pois a taxa para a conta subjacente aumentou para ambas. Dessa forma, as taxas "locais" por conta se correlacionam de forma adequada de maneira "global", e as taxas multidimensionais impedem a manipulação do sistema lançando vários contratos para a mesma aplicação.

Por outro lado, se o estado da aplicação em si for paralelizado, as taxas serão mais baixas. Esta propriedade é desejada; a paralelização aumenta a taxa de transferência, pois permite que diferentes transações que acessam a mesma aplicação sejam colocadas em threads diferentes quando as contas subjacentes não se sobrepõem (ver Ciclo de vida de uma Transação Solana.

O controlador de preços para esses mercados locais de taxas por conta pode ser diferente daquele usado para unidades de computação. Talvez para as contas que não cobramos nenhuma taxa até que o estado seja significativamente contestado, momento em que a taxa aumenta rapidamente. A análise de períodos passados de congestionamento pode ajudar a informar essas decisões de design.

Mecanismos alternativos​

As opções discutidas acima não são as únicas maneiras de definir taxas. A maioria dos mecanismos de taxas base segue mais ou menos o mesmo procedimento iterativo: em cada bloco...

1. olhe para o consumo de recursos dos blocos mais recentes (resultado das transações incluídas);
2. calcular uma função deste consumo (por exemplo, desvio de uma meta);
3. e depois atualize os preços dos recursos usando a saída da etapa 2 e uma regra simples.

Nos exemplos discutidos acima, usamos escolhas diferentes para os recursos na etapa 1 e o mecanismo de atualização nas etapas 2 e 3. Um método para transformar preferências de utilização de recursos em uma regra de atualização de taxas concretas é discutido emeste documento.

Este negócio multidimensional funciona?

Embora nosso trabalho acadêmico seja principalmente teórico, exemplos simples de brinquedos mostram que precificar recursos, como contas, separadamente, pode aumentar a eficiência da rede e torná-la mais robusta contra ataques de DoS ou mudanças nos tipos de transações enviadas. Nesta seção, destacamos a diferença entre um mecanismo de taxa unidimensional e multidimensional simples (consulte a seção 4 denosso papel para detalhes).

Comportamento em estado estacionário​

Primeiro simulamos o comportamento de estado estável de um mecanismo de taxa multidimensional com transações que requerem quantidades aproximadamente iguais de recurso 1 e recurso 2. Sob o comportamento de estado estável, a precificação uniforme causa uma maior divergência das metas de uso de recursos (esquerda). O uso menos eficiente também leva a uma menor taxa de transferência (direita).

Distribuição de mudanças​

Também testamos o comportamento do mecanismo sob uma mudança de distribuição: adicionamos 150 transações no bloco 10 que requerem uma quantidade significativa de recurso 2. Este cenário pode aparecer em uma cunhagem de NFT, por exemplo. O preço multidimensional leva a um throughput significativamente maior quando a distribuição muda (esquerda) ajustando os preços dos recursos conforme necessário (direita).

Analisando o uso individual de recursos, vemos que a precificação multidimensional (esquerda) facilita a capacidade de explosão rápida, enquanto a precificação uniforme (direita) não.

Conclusão

As blockchains têm recursos computacionais finitos. Quando a demanda do usuário é alta, isso requer alocar esses recursos finitos entre transações de usuários concorrentes de maneira previsível. Essa alocação deve ser feita implicitamente por meio de uma taxa base de transação dinâmica.

Propomos um mecanismo fundamentado teoricamente para definir essa taxa, que não apenas pode aumentar a taxa de transferência da rede durante períodos de alta demanda, mas também melhorar a experiência do usuário ao desvincular transações não relacionadas e fornecer um custo previsível para a inclusão da transação. Para mais detalhes sobre o mecanismo, confiraA palestra de Tarun no Breakpointenosso papel!

Aviso Legal：

1. Este artigo foi reproduzido de [umbraresearchEncaminhar o Título Original 'Rumo a Taxas Solana Multidimensionais', Todos os direitos autorais pertencem ao autor original@theo_diamandis、@tarunchitra、@0xShitTrader]. Se houver objeções a esta reimpressão, entre em contato com oGate Learnequipe e eles resolverão prontamente.

2. Isenção de responsabilidade: As opiniões expressas 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 Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.-