No Ethereum, os recursos eram até recentemente limitados e com preços, usando um único recurso chamado "gás". O gás é uma medida da quantidade de "esforço computacional" necessário para processar uma determinada transação ou bloco. O gás combina vários tipos de "esforço", principalmente:
- Cálculo bruto (por exemplo, ADICIONAR, MULTIPLICAR)- Ler e escrever no armazenamento do Ethereum (por exemplo, SSTORE, SLOAD, transferências de ETH)- 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. Isto é dividido entre (i) um custo base de 21000 gás, (ii) 1556 gás para os bytes nos dados de chamada incluídos na 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 utilizador 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 através do @vbuterinMecanismo 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 num recurso virtual único, conduz a um design de mercado muito simples. Otimizar uma transação para minimizar os custos é fácil, otimizar um bloco para recolher as taxas mais altas possíveis é relativamente fácil (não incluindoMEV) e não existem incentivos estranhos que encorajem algumas transações a agrupar-se com outras transações para poupar 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 este problema é olhar para este diagrama:
O limite de gás impõe uma restrição de
𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛- Transações que são pesadas num recurso ainda são cobradas desnecessariamente uma grande quantidade, mesmo que todas as outras transações no bloco usem pouco desse recurso.- Cria incentivos para transações com grande volume de dados e computação se unirem num pacote para poupar custos.Eu argumentaria que uma regra no estilo EIP-7623, tanto para os dados da transação quanto para outros recursos, pode trazer benefícios suficientemente grandes para valer a pena, mesmo apesar dessas desvantagens. No entanto, se e quando estivermos dispostos a dedicar 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.
Rastreamos um parâmetro, excess_blobs. Durante cada bloco, definimos:
excess_blobs O EIP-1559 está de volta em 2020. Com o EIP-4844, agora temos dois preços flutuantes separados 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 irei expandir na próxima seção.
Para os usuários, a experiência é notavelmente semelhante à de hoje: 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 ótima é a mesma de hoje: incluir tudo o que for válido. A maioria dos blocos não está cheia - nemem gásnemem manchas. O caso desafiador é quando há gás suficiente ou blobs suficientes para exceder o limite do bloco, e o construtor precisa potencialmente resolver um problema da mochila multidimensionalpara maximizar o seu lucro. No entanto, mesmo existindo algoritmos de aproximação bastante bons, e os ganhos ao desenvolver algoritmos proprietários para otimizar lucros neste caso são muito menores do que os ganhos ao fazer o mesmo com MEV.
Para os programadores, o desafio principal é a necessidade de redesenhar as funcionalidades da EVM e da sua infraestrutura envolvente, que está desenhada em torno de um preço e de um limite hoje em dia, para um design que acomode múltiplos preços e múltiplos limites. Um problema para os programadores de aplicações é que a otimização se torna ligeiramente mais difícil: em alguns casos, já não se pode dizer de forma inequívoca que A é mais eficiente do que B, porque se A utiliza mais calldata mas B utiliza mais execução, então A pode ser mais barato quando a calldata é barata e mais caro quando a calldata é cara. No entanto, os programadores ainda conseguem obter resultados razoavelmente bons ao otimizar com base nos preços médios históricos a longo prazo.
Preços multidimensionais, o EVM e sub-chamadasHá um problema que não apareceu com blobs e não aparecerá com EIP-7623 ou mesmo com uma implementação de preços multidimensionais 'completos' para calldata, mas aparecerá se tentarmos precificar separadamente os acessos ao estado, ou qualquer outro recurso: limites de gás em sub-chamadas.
Os limites de gás no EVM existem em dois lugares. Em primeiro lugar, 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 restante 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 destinatário uma quantidade limitada de gás, para garantir que a chamada externa possa continuar mesmo que o destinatário 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 subchamadas 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 as 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 assim nada dentro do EVM precisa mudar para tornar a calldata ou blobs separadamente precificados.
Podemos pensar numa solução do 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:
execution_gás + 10000 *operações de armazenamento - min(7500 *operações de armazenamento, gás de execução)
Que equivale a:
max(execution_gás + 2500 operações de armazenamento, 10000storage_operations)
Este espelha a estrutura do EIP-7623. Outra maneira de o fazer é seguir as storage_operations e execution_gas em tempo real e cobrar 2500 ou 10000, dependendo de quanto max(execution_gas + 2500operações de armazenamento, 10000A quantidade de gás consumida pelas operações de armazenamento (storage_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 através de reembolsos.
Não obtemos permissões detalhadas para subchamadas: uma subchamada pode consumir toda a "permissão" de uma transação para operações de armazenamento baratas. 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 preços multidimensionais mais simples 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 de CHAMADA seja chamado, com limite de gás de sub-chamada
𝑆
. Deixa
𝑠1=𝑆
, e depois
𝑠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 para que a sub-chamada obtenha a mesma percentagem de gás disponível em cada tipo. Isto é 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 a pena salientar que, uma vez que comece a introduzir gás de execução multidimensional, o nível inerente de feiura aumenta, e isso parece difícil de evitar. Portanto, a nossa tarefa é fazer um compromisso complicado: aceitamos um pouco mais de feiura ao nível do EVM, a fim de desbloquear com segurança ganhos significativos de escalabilidade L1, e, em caso afirmativo, qual proposta específica funciona melhor para a economia do protocolo e para os desenvolvedores de aplicações? Muito provavelmente, não é nenhuma das que mencionei acima, e ainda há espaço para encontrar algo mais elegante e melhor.
Aviso legal:- Este artigo é reproduzido de [[Vitalik Buterin]], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o [Gate Learn](https://www.Gate.com/questionnaire/3967equipa e eles tratarão disso prontamente.- Responsabilidade de Isenção: 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.
