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

Uma transação Solanaviagemda submissão do usuário à inclusão no bloco pode ser árduo. Mesmo quando a transação alcança o líder atual, ela deve competir com outras transações por um 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 de prioridade para o resgate?​

Taxas prioritárias resolvem este problema, certo? Infelizmente, não para a maioria dos utilizadores.

Imagine este cenário. Você quer ir ao cinema da sua cidade com 100 lugares, mas o cinema tem um sistema de bilheteira anormal: eles não publicam um preço de bilhete. Em vez disso, você tem que dizer-lhes quanto está disposto a pagar. (Digamos que seja $50.) Se a procura for alta e pelo menos outras 100 pessoas submeterem um preço mais alto, azar o seu. Se a procura for baixa, você consegue! Apanhando: você paga $50 mesmo que o cinema esteja vazio. Mas a experiência de compra de bilhetes não termina aí. Este sistema tem outra peculiaridade: você tem que dizer ao cinema a sua disposição para pagar antes de sair de casa. Obviamente, conseguir um bilhete de cinema neste sistema é uma experiência potencialmente problemática para o cidadão comum. Pessoas ricas e sofisticadas, por outro lado, conseguem estimar com precisão o preço do bilhete. Elas podem instalar câmaras ao lado do cinema para monitorizar o tráfego em tempo real. Podem usar esse tráfego e os dados históricos recolhidos para estimar a procura num determinado dia. E até podem comprar um helicóptero para viajar mais rápido para o cinema depois de dizer ao cinema a sua disposição para pagar. Embora seja possível utilizar eficazmente este sistema de bilheteira, a experiência é horrível para a maioria das pessoas que querem ir ao cinema. Quando o cinema está cheio, muitas destas pessoas podem nem se dar ao trabalho de tentar ir.

Da mesma forma, a "verdadeira" taxa de prioridade necessária para uma transação Solana é difícil de estimar. Flutua muitoDurante períodos de alta congestão, as carteiras que utilizam médias recentes provavelmente vão sobreestimar a taxa necessária, fazendo com que os utilizadores 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 de prioridade 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 mergulhar na solução, vamos examinar algumas propriedades do recurso que estamos tentando alocar: espaço do bloco.

Blockspace: oferta fixa, demanda altamente flutuante​

As 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 de bloco aumenta além da oferta limitada, este recurso fixo deve ser alocado entre as transações concorrentes.

De certa forma, o mercado pode lidar com a alocação de espaço de bloco através de preços; 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 do 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 taxas implementam uma taxa base fácil de estimar que fornece uma previsível "taxa de entrada" para a rede; esta taxa base aproxima-se do preço real para a inclusão da transação.

Rever: 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 on-chain pesados em computação e os que tentam capturar oportunidades complicadas de MEV. Assim, a taxa base atual cobrada não captura com precisão o uso de recursos de uma transação (e a "externalidade", no jargão econômico), resultando potencialmente em mal usado espaço de bloco.

No nosso exemplo de teatro, uma taxa de base igualmente fixa cobraria ao espectador que compra 1 lugar e ao que compra todos os 100 lugares o mesmo preço.

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 utilizador tenha um custo de participação mais previsível, dado por uma taxa base dinâmica. Estas taxas são difíceis de definir corretamente. (Há muita pesquisa acadêmica,incluindo o nosso próprio, no entanto, qualquer pessoa que tenha sofrido com transações falhadas devido à congestionamento na rede sabe que as taxas também são importantes para acertar se queremos 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 de prioridade. Superestimar essas taxas significa pagar muito. Subestimar essas taxas significa que a transação não será incluída. Por outro lado, para as taxas base, os usuários pagam exatamente a taxa publicada atual. Gostaríamos que a taxa base capturasse com precisão o verdadeiro custo da inclusão das transações. Aqui, assumimos que todas as transações alcançam o agendador, mas competem por espaço limitado em 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 passos em direção a um mecanismo de taxa base dinâmica que pode ajudar a desobstruir a rede e fornecer uma inclusão de transações mais previsível.

Além disso: taxas prioritárias e MEV​

Taxas prioritárias 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 enviarem 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 liquidará com sucesso o empréstimo. As taxas prioritárias, portanto, frequentemente pagam pela ordenação das transações, e não apenas pela inclusão. Esse uso de taxas prioritárias para capturar oportunidades de MEV é algo ortogonal a este post—ver MEV em Solanapara mais discussão. Neste post, concentramo-nos nas taxas base e na inclusão de transações.

Blocos ótimos

Antes de discutirmos como definir as taxas base, consideraremos um mecanismo fictício para a 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 referencial mental para um bloco 'ótimo' construído a partir das transações que alcançam o agendador. Nosso objetivo é projetar um mecanismo de taxa que se aproxime desse referencial.

Embora este mecanismo de construção de blocos fictício seja intratável, verifica-se que podemos conceber um mecanismo equivalente que é implementável na prática. Este mecanismo equivalente procura encontrar os preços dos recursos que minimizam a diferença entre o bem-estar da rede e o dos seus utilizadores. A definição correta dos preços dos recursos alinha os incentivos de forma a que os custos dos recursos para a rede sejam exatamente equilibrados pela utilidade obtida pelos utilizadores e validadores, mesmo que a rede não tenha ideia do que é essa utilidade e os utilizadores nunca a especifiquem explicitamente. Estes preços levam então a blocos que são “ótimos” em média. Assim, podemos focar-nos apenas na definição destes preços. (Para mais detalhes técnicos, consulteeste papel.)

Para um mecanismo

Como podemos então definir 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 CU fará com que os usuários não enviem transações, e os blocos podem estar perto do vazio. 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 ajusta a taxa por unidade de computação com base no uso passado. Por exemplo, se houver um objetivo de uso por bloco (ou seja, um uso ideal em estado estacionário para a cadeia), podemos aumentar ou diminuir a taxa base com base na utilização ou na divergência deste objetivo. Muitos mecanismos, incluindo alguns como EIP-1559implementar esta 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 alterações reduziriam a previsibilidade da taxa base, derrotando o objetivo original deste 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 ex., dobrar o preço para cada bloco completo) e, em seguida, baixar 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á "esgotado", a rede está significativamente a cobrar menos e a obter menos informações sobre qual deve ser o preço ideal. Tipos semelhantes de algoritmos são utilizados na prática emControlo de congestão TCP, a camada de ligação de dados das comunicações sem fios, e otimização do mercado.

Taxas multidimensionais: mercados de taxas locais​

A discussão anterior considerou um recurso comum partilhado por todas as transações: unidades de computação (globais). No entanto, o acesso ao estado no Solana também afeta significativamente o uso de recursos de transação. Se muitas transações acederem à mesma parte do estado, 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á fora do âmbito deste post; mais sobre isso no futuro.)

Como exemplo concreto, vamos considerar um lançamento popular de NFT. Sem mercados de taxas por conta, este 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 ter acesso a essa parte do estado) pode aumentar, enquanto as taxas para outras transações (como complementar o colateral em um empréstimo) permanecem em grande parte inalteradas. Este tipo de design de mercado de taxas local por conta está a ser considerado em umRascunho do Documento de Melhoria da Solana.

Essas taxas multidimensionais também podem levar em conta as 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 drasticamente para uma coleção específica em uma dessas trocas, então a taxa base aumentará para essa coleção na outra, visto que a taxa para a conta subjacente aumentou para ambas. Dessa forma, as taxas "locais" por conta correlacionam adequadamente de forma "global", e as taxas multidimensionais impedem a manipulação do sistema ao liberar vários contratos para a mesma aplicação.

Por outro lado, se o estado da própria aplicação for paralelizado, as taxas serão mais baixas. Esta propriedade é desejada; a paralelização aumenta o débito, pois permite que diferentes transações que acedem à mesma aplicação sejam colocadas em threads diferentes quando as contas subjacentes não se sobrepõem (verCiclo de Vida de uma Transação Solana).

O controlador de preços para estes mercados locais de taxas por conta pode ser diferente do usado para unidades de computação. Talvez para as contas não cobremos 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 formas de definir taxas. A maioria dos mecanismos de taxa base segue aproximadamente o mesmo procedimento iterativo: em cada bloco...

1. verifique 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 um objetivo);
3. e depois atualizar os preços dos recursos usando a saída do passo 2 e uma regra simples.

Nos exemplos discutidos acima, usamos diferentes escolhas para os recursos no passo 1 e o mecanismo de atualização nos passos 2 e 3. Um método para transformar preferências de utilização de recursos numa regra de atualização de taxa concreta é discutido emeste papel.

Este material multidimensional funciona?

Embora o 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 tornar a rede mais robusta a ataques de negação de serviço ou a alterações nos tipos de transações submetidas. Nesta secção, destacamos a diferença entre um mecanismo de taxas unidimensional e multidimensional simples (ver secção 4 de nosso papelpara detalhes).

Comportamento em estado estacionário​

Primeiro simulamos o comportamento em estado estacionário de um mecanismo de taxas multidimensional com transações que requerem quantidades aproximadamente iguais do recurso 1 e do recurso 2. Sob o comportamento em estado estacionário, a fixação de preços uniformes causa maior desvio das metas de uso de recursos (esquerda). O uso menos eficiente também leva a uma menor capacidade de processamento (direita).

Mudanças na distribuição

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 recursos 2. Este cenário pode aparecer em uma cunhagem de NFT, por exemplo. A precificação multidimensional leva a uma throughput significativamente maior quando a distribuição muda (esquerda) ajustando os preços dos recursos de acordo (direita).

Olhando para a utilização 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 forma previsível. Essa alocação deve ser feita implicitamente através de uma taxa de base de transação dinâmica.

Propomos um mecanismo teoricamente fundamentado para definir esta taxa, que não só pode aumentar o débito da rede durante períodos de grande procura, mas também melhorar a experiência do utilizador ao desvincular transações não relacionadas e fornecer um custo previsível de inclusão da transação. Para mais detalhes sobre o mecanismo, consulteA palestra de Tarun no Breakpointenosso papel!

Aviso Legal：

1. Este artigo é reproduzido a partir de [umbraresearch], Encaminhe o título original 'Towards Multidimensional Solana Fees', Todos os direitos autorais pertencem ao autor original [@theo_diamandis、@tarunchitra、@0xShitTrader]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles vão tratar disso prontamente.

2. Aviso 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. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.