No Ethereum, os recursos eram, até recentemente, limitados e precificados usando um único recurso chamado "gás". O gás é uma medida da quantidade de "esforço computacional" necessário para processar uma transação ou bloco. O gás combina vários tipos de "esforço", principalmente:
- Cálculo bruto (por exemplo, ADICIONAR, MULTIPLICAR)- Leitura e gravação no armazenamento do Ethereum (por exemplo. SSTORE, SLOAD, ETH transfere)- Largura de banda de dados- Custo de geração de um prova ZK-SNARKdo blocoPor exemplo, esta transaçãoque enviei custou um total de 47.085 gás. Isso é dividido entre (i) um "custo base" de 21000 gás, (ii) 1556 gás para os bytes nos dados de chamada incluídos como parte da transação, (iii) 16500 gás para leitura e escrita no armazenamento, (iv) gás 2149 para fazer um registo, e o restante para a execução do EVM. A taxa de transação que um usuário deve pagar é proporcional ao gás que a transação consome. Um bloco pode conter até um máximo de 30 milhões de gás, e os preços do gás são constantemente ajustados via o@vbuterin/eip-1559-faq">Mecanismo de segmentação EIP-1559, garantindo que, em média, os blocos contenham 15 milhões de gás.
Esta abordagem tem uma eficiência principal: porque tudo é fundido em um recurso virtual, leva a um design de mercado muito simples. Otimizar uma transação para minimizar custos é fácil, otimizar um bloco para coletar as taxas mais altas possíveis é relativamente fácil (não incluindoMEV) e não há incentivos estranhos que encorajem algumas transações a se agruparem com outras transações para economizar em taxas.
Mas essa abordagem também tem uma grande ineficiência: trata diferentes recursos como sendo mutuamente conversíveis, quando os limites reais subjacentes do que a rede pode lidar não são. Uma maneira de entender essa questão é olhar para este diagrama:
O limite de gás impõe uma restrição de
𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗c𝑜m𝑝𝑢t𝑎t𝑖𝑜n- Transações que consomem muito de um recurso ainda são desnecessariamente cobradas em grande quantidade, mesmo se todas as outras transações no bloco usarem pouco desse recurso.- Cria incentivos para transações de dados pesados e de computação pesada se unirem em um pacote para economizar custos.Eu argumentaria que uma regra no estilo EIP-7623, tanto para dados de transação quanto para outros recursos, pode trazer benefícios grandes o suficiente para valer a pena, mesmo apesar dessas desvantagens. No entanto, se e quando estivermos dispostos a investir um esforço de desenvolvimento (significativamente maior), existe uma abordagem mais ideal.
Multidimensional EIP-1559: a estratégia mais difícil, mas idealVamos primeiro recapitular como funciona o EIP-1559 "regular". Vamos nos concentrar na versão que foi introduzida no EIP-4844 para blobs, porque é matematicamente mais elegante.
Nós rastreamos um parâmetro, excess_blobs. Durante cada bloco, nós definimos:
excess_blobs EIP-1559 de volta em 2020. Com o EIP-4844, agora temos dois preços separados flutuantes para gás e para blobs.
Taxa base de gás ao longo de uma hora em 08-05-2024, em gwei. Fonte: ultrasound.money.
Em princípio, poderíamos adicionar mais taxas separadas para leitura de armazenamento e outros tipos de operações, embora com uma ressalva que vou expandir na próxima seção.
Para os usuários, a experiência é notavelmente semelhante à atual: em vez de pagar uma taxa básica, você paga duas taxas básicas, mas sua carteira pode abstrair isso de você e apenas mostrar a taxa esperada e a taxa máxima que você pode esperar pagar.
Para os construtores de blocos, na maioria das vezes, a estratégia ideal é a mesma de hoje: incluir qualquer coisa que seja válida. A maioria dos blocos não está cheia - nem em gásnemem manchas. O caso desafiador é quando há gás suficiente ou bastantes blobs para exceder o limite do bloco, e o construtor precisa potencialmente resolver um problema da mochila multidimensionalpara maximizar seu lucro. No entanto, mesmo que existam algoritmos de aproximação bastante bons, os ganhos de criar algoritmos proprietários para otimizar lucros neste caso são muito menores do que os ganhos de fazer o mesmo com MEV.
Para os desenvolvedores, o principal desafio é a necessidade de redesenhar recursos do EVM e sua infraestrutura circundante, que atualmente é projetada em torno de um preço e um limite, em um design que acomode múltiplos preços e múltiplos limites. Um problema para os desenvolvedores de aplicativos é que a otimização se torna ligeiramente mais difícil: em alguns casos, você não pode mais dizer inequivocamente que A é mais eficiente que B, porque se A usar mais calldata e B usar mais execução, então A pode ser mais barato quando calldata é barato e mais caro quando calldata é caro. No entanto, os desenvolvedores ainda seriam capazes de obter resultados razoavelmente bons otimizando com base nos preços médios históricos de longo prazo.
Preços multidimensionais, o EVM e chamadas secundáriasHá um problema que não apareceu com blobs, e não aparecerá com EIP-7623 ou mesmo com uma implementação de precificação multidimensional 'completa' para calldata, mas aparecerá se tentarmos precificar separadamente os acessos ao estado, ou qualquer outro recurso: limites de gás em chamadas subsidiárias.
Os limites de gás na EVM existem em dois lugares. Primeiro, cada transação define um limite de gás, que limita a quantidade total de gás que pode ser usada nessa transação. Em segundo lugar, quando um contrato chama outro contrato, a chamada pode definir seu próprio limite de gás. Isso permite que contratos chamem outros contratos nos quais não confiam e ainda garantam que terão gás suficiente para realizar outras computações após essa chamada.
Um rastro de uma transação de abstração de conta, onde uma conta chama outra conta e dá ao chamado uma quantidade limitada de gás, para garantir que a chamada externa possa continuar mesmo que o chamado consuma todo o gás que lhe foi atribuído.
O desafio é: tornar o gás multidimensional entre diferentes tipos de execução parece que exigiria sub-chamadas para fornecer múltiplos limites para cada tipo de gás, o que exigiria uma mudança realmente profunda no EVM e não seria compatível com as aplicações existentes.
Esta é uma das razões pelas quais propostas de gás multidimensionais frequentemente param em duas dimensões: dados e execução. Os dados (seja calldata de transação ou blobs) são apenas atribuídos fora do EVM e, portanto, nada dentro do EVM precisa mudar para tornar calldata ou blobs com preços separados.
Podemos pensar em uma solução estilo “EIP-7623” para este problema. Aqui está uma implementação simples: durante a execução, cobrar 4x mais pelas operações de armazenamento; para simplificar a análise, digamos 10000 gás por operação de armazenamento. No final da transação, reembolsar min(7500 * operações_de_armazenamento, gás_de_execução). O resultado seria que, após subtrair o reembolso, um usuário é cobrado:
execução_gás + 10000 *armazenamento_operacional - min(7500 *operacoes_de_armazenamento, gas_de_execucao)
Que equivale a:
max(execution_gás + 2500operações de armazenamento, 10000storage_operations)
Isso espelha a estrutura do EIP-7623. Outra maneira de fazer é rastrear as operações de armazenamento e o gás de execução em tempo real e cobrar 2500 ou 10000, dependendo de quanto max(execução_gas + 2500operações de armazenamento, 10000storage_operations) aumenta no momento em que o opcode é chamado. Isso evita a necessidade de transações alocarem gás em excesso, pois a maior parte será devolvida por meio de reembolsos.
Não obtemos permissão detalhada para subchamadas: uma subchamada poderia consumir toda a 'permissão' de uma transação para operações baratas de armazenamento. Mas obtemos algo suficientemente bom, onde um contrato que faz uma subchamada pode definir um limite e garantir que, uma vez que a subchamada termine de executar, a chamada principal ainda tenha gás suficiente para fazer qualquer pós-processamento necessário.
A solução de precificação multidimensional completa mais fácil que consigo pensar é: tratamos os limites de gás de sub-chamada como sendo proporcionais. Ou seja, suponha que haja
𝑘
diferentes tipos de execução e cada transação define um limite multidimensional
𝐿1…𝐿𝑘
Suponha que, no ponto atual da execução, o gás restante seja
𝑔1…𝑔𝑘
Suponha que um opcode CALL seja chamado, com limite de gás de chamada sub
𝑆
. Deixe
𝑠1=𝑆
, e então
𝑠2=𝑠1𝑔1∗𝑔2
,
𝑠3=𝑠1𝑔1∗𝑔3
, e assim por diante.
Isto é, tratamos o primeiro tipo de gás (realisticamente, execução VM) como sendo uma espécie de “unidade de conta” privilegiada e, em seguida, atribuímos os outros tipos de gás de modo que a sub-chamada obtenha a mesma porcentagem de gás disponível em cada tipo. Isso é um pouco feio, mas maximiza a compatibilidade com versões anteriores. Se quisermos tornar o esquema mais “neutro” entre diferentes tipos de gás, ao custo de sacrificar a compatibilidade com versões anteriores, poderíamos simplesmente fazer com que o parâmetro de limite de gás da sub-chamada represente uma fração (por exemplo, [1…63] / 64) do gás restante no contexto atual).
Em qualquer caso, no entanto, vale ressaltar que, uma vez que você comece a introduzir gás de execução multidimensional, o nível inerente de feiura aumenta, e isso parece difícil de evitar. Portanto, nossa tarefa é fazer um trade-off complicado: aceitamos um pouco mais de feiura no nível do EVM, a fim de desbloquear com segurança ganhos significativos de escalabilidade L1, e, se sim, qual proposta específica funciona melhor para a economia do protocolo e os desenvolvedores de aplicativos? Muito provavelmente, não é nenhuma das que mencionei acima, e ainda há espaço para pensar em algo mais elegante e melhor.
Aviso legal：- Este artigo é reproduzido de [[Vitalik Buterin]], Todos os direitos autorais pertencem ao autor originalVitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o [Gate Learn](https://www.Gate.com/questionnaire/3967equipe e eles lidarão com isso prontamente.- Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.- As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Exceto quando mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.
