Introdução: Em 13 de maio de 2024, Vitalik propôs o EIP-7706, que complementa o modelo Gas existente ao remover separadamente o cálculo de gas para calldata e personalizar um mecanismo de preços de taxa base semelhante ao gas Blob, reduzindo ainda mais os custos operacionais da Camada 2. Propostas relacionadas também precisam ser rastreadas até o EIP-4844 proposto em fevereiro de 2022, o que é um longo período de tempo. Portanto, ao verificar materiais relacionados, esperamos fornecer um resumo do mecanismo de Gas Ethereum mais recente para facilitar a compreensão rápida de todos.

Modelos de Gás Ethereum Suportados Atualmente - EIP-1559 e EIP-4844

No design inicial, o Ethereum adotou um mecanismo de leilão simples para precificar as taxas de transação, exigindo que os usuários licitassem ativamente por suas transações, ou seja, definindo os preços do gás. Normalmente, porque as taxas de transação pagas pelos usuários vão para os mineiros, os mineiros decidem a ordem de empacotamento das transações com base no princípio da optimalidade econômica, de acordo com o preço da licitação, ignorando a situação do MEV. Na visão dos desenvolvedores principais na época, esse mecanismo enfrentava quatro problemas:

A flutuação dos níveis de taxa de transação não corresponde ao custo do consenso das transações: Para blockchains em estado ativo, há demanda suficiente para a embalagem de transações, o que significa que os blocos podem ser facilmente preenchidos, mas isso frequentemente leva a flutuações significativas nas taxas gerais. Por exemplo, quando o Preço do Gas médio é de 10 Gwei, o custo marginal incorrido pela rede para aceitar outra transação em um bloco é dez vezes maior do que quando o Preço do Gas médio é de 1 Gwei, o que é inaceitável.

Atrasos desnecessários para os utilizadores: Devido ao limite rígido do gaslimit para cada bloco, aliado à flutuação natural dos volumes de transações históricas, as transações frequentemente têm de esperar por vários blocos para serem agrupadas, o que é ineficiente para a rede em geral. Não existe um mecanismo de "relaxamento" que permita que um bloco seja maior e o próximo bloco seja menor para se adequarem às diferenças de demanda entre blocos.

Preços ineficientes: A adoção de um mecanismo de leilão simples levou a uma baixa eficiência na descoberta do preço justo, o que significa que é difícil para os usuários darem um preço razoável, resultando em muitos casos em que os usuários pagam taxas excessivas.

Blockchain sem recompensas em bloco será instável: Quando cancelar as recompensas em bloco trazidas pela mineração e adotar um modelo de taxa pura, pode levar a muitas instabilidades, como incentivar a mineração de "blocos irmãos" para roubar taxas de transação, abrindo mais vetores de ataque de mineração egoísta mais poderosos, etc.

Até à proposta e implementação do EIP-1559, houve uma primeira iteração do modelo de Gás. O EIP-1559, proposto por Vitalik e outros desenvolvedores centrais em 13 de abril de 2019, foi adotado na atualização de Londres em 5 de agosto de 2021. Este mecanismo abandona o mecanismo de leilão e adota, em vez disso, um modelo de preços duplos de taxa Base e taxa de Prioridade. A taxa Base é calculada quantitativamente com base na relação entre o consumo de gás no bloco pai e um alvo de gás flutuante e recursivo através de um modelo matemático estabelecido. O efeito intuitivo é que se o uso de gás no bloco anterior exceder o alvo de gás predeterminado, a taxa base é aumentada e se estiver abaixo do alvo de gás, a taxa base é reduzida. Isto pode refletir melhor a oferta e a procura e tornar as previsões para um gás razoável mais precisas, evitando Preços de Gás exorbitantes devido a más operações porque o cálculo da taxa base é diretamente determinado pelo sistema em vez de especificado livremente pelos utilizadores. O código específico é o seguinte:

Pode-se inferir que quando parent_gas_used é maior que parent_gas_target, a taxa base do bloco atual será comparada com a taxa base do bloco anterior mais um valor de compensação. Quanto ao valor de compensação, é calculado multiplicando parent_base_fee pelo desvio do uso total de gás do bloco anterior em relação ao alvo de gás e fazendo o módulo com o alvo de gás e uma constante, depois pegando o valor máximo do resultado e 1. A lógica é semelhante em sentido inverso.

Além disso, a taxa base deixará de ser alocada como recompensa para os mineiros, mas será queimada diretamente, colocando assim o modelo econômico do Ethereum em um estado deflacionário, o que é propício para a estabilidade de valor. Por outro lado, a taxa de prioridade é semelhante a uma gorjeta dada pelos usuários aos mineiros e pode ser precificada livremente, o que, até certo ponto, permite que o algoritmo de sequenciamento de mineradores seja reutilizado.

À medida que o tempo avançava para 2021, o desenvolvimento dos Rollups alcançou gradualmente o pico. Sabemos que quer se trate de Rollups OP ou Rollups ZK, isso implica a necessidade de enviar certos dados de prova de dados L2 comprimidos para a cadeia via calldata para alcançar a Disponibilidade de Dados on-chain, ou serem verificados diretamente on-chain. Isso implica custos significativos de gás para manter a finalidade do L2, que são passados para os usuários. Portanto, o custo de usar a maioria dos protocolos L2 não era tão baixo quanto imaginado naquela época.

Ao mesmo tempo, Ethereum também enfrentou o dilema da competição pelo espaço de bloco. Sabemos que cada bloco tem um Limite de Gas, o que significa que o consumo total de gas de todas as transações no bloco atual não pode exceder esse valor. Calculando com base no Limite de Gas atual de 30.000.000, teoricamente há um limite de 1.875.000 bytes, onde 16 se refere ao gas consumido por byte de calldata processado pelo EVM. Isso implica que o tamanho máximo de dados que pode ser acomodado em um único bloco é aproximadamente 1,79 MB. No entanto, os dados relacionados ao Rollup gerados pelos sequenciadores L2 geralmente têm um tamanho de dados maior, o que compete com a confirmação de transações por outros usuários da main chain, resultando em uma diminuição do número de transações que podem ser empacotadas em um único bloco, afetando assim o TPS da main chain.

Para resolver este dilema, os desenvolvedores principais propuseram o EIP-4844 em 5 de fevereiro de 2022, que foi implementado após a atualização Dencun no segundo trimestre de 2024. Esta proposta introduz um novo tipo de transação chamado Transação Blob. Em contraste com os tipos de transação tradicionais, a ideia principal da Transação Blob complementa um novo tipo de dados, nomeadamente dados Blob. Ao contrário dos tipos calldata, os dados blob não podem ser acedidos diretamente pelo EVM, mas apenas aceder ao seu hash, também conhecido como VersionedHash. Além disso, são introduzidos dois designs acompanhantes. Em primeiro lugar, em comparação com as transações regulares, o ciclo GC das transações blob é mais curto, garantindo que os dados do bloco não fiquem muito inflados. Em segundo lugar, os dados blob têm um mecanismo Gas nativo. No geral, o efeito apresentado é semelhante ao EIP-1559, mas o modelo matemático seleciona uma função exponencial natural, que se comporta melhor em termos de estabilidade ao lidar com flutuações no volume de transações. Isto deve-se ao facto de a inclinação da função exponencial natural ser também uma função exponencial natural, o que significa que, independentemente do estado do volume de transações da rede, quando o volume de transações aumenta rapidamente, a taxa base do gás blob reflete-se mais completamente, limitando eficazmente a atividade de transações. Além disso, esta função tem uma característica importante em que o valor da função é 1 quando a abcissa é 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GASe*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Onde MIN_BASE_FEE_PER_BLOB_GAS e BLOB_BASE_FEE_UPDATE_FRACTION são duas constantes, e excess_blob_gas é determinado pela diferença entre o consumo total de blob gas no bloco pai e uma constante TARGET_BLOB_GAS_PER_BLOCK. Quando o consumo total de blob gas excede o valor alvo, ou seja, a diferença é positiva, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) é maior que 1, e base_fee_per_blob_gas aumenta, caso contrário, diminui.

Isso permite a execução de baixo custo em cenários em que apenas a capacidade de consenso do Ethereum é desejada para armazenar dados em grande escala para garantir a disponibilidade, sem monopolizar a capacidade de empacotamento de transações do bloco. Tomando o sequenciador Rollup como exemplo, as informações críticas da L2 podem ser encapsuladas em dados de blob por meio de transações de blob, e a lógica para verificação on-chain pode ser implementada no EVM por meio de designs sofisticados usando versionedHash.

Deve ser notado que a configuração atual de TARGET_BLOB_GAS_PER_BLOCK e MAX_BLOB_GAS_PER_BLOCK impõe uma limitação na mainnet, nomeadamente um objetivo de processar em média 3 blobs (0,375 MB) por bloco e um limite máximo de 6 blobs (0,75 MB) por bloco. Estes limites iniciais têm como objetivo minimizar a pressão que o EIP coloca na rede, e espera-se que sejam aumentados em futuras atualizações à medida que a rede demonstre fiabilidade com blocos maiores.

Refinamento do Modelo de Consumo de Gás para Ambiente de Execução - EIP-7706

Após esclarecer o modelo Gas atual do Ethereum, vamos dar uma olhada nos objetivos e detalhes de implementação da proposta EIP-7706. Esta proposta foi introduzida por Vitalik em 13 de maio de 2024. Semelhante aos dados Blob, esta proposta separa o modelo Gas para outro campo de dados especial, ou seja, calldata, e otimiza a lógica de implementação de código correspondente.

Em princípio, a lógica de cálculo da taxa base para calldata é a mesma que a taxa base para dados blob em EIP-4844, ambas usando uma função exponencial para calcular o fator de escala para a taxa base atual com base na discrepância entre o valor real de consumo de gás no bloco pai e o valor alvo.

Vale a pena notar um novo design de parâmetro, LIMIT_TARGET_RATIOS=[2,2,4], onde LIMIT_TARGET_RATIOS[0] representa a taxa alvo de Gas para operações de execução, LIMIT_TARGET_RATIOS[1] representa a taxa alvo de Gas para dados Blob e LIMIT_TARGET_RATIOS[2] representa a taxa alvo de Gas para calldata. Este vetor é usado para calcular os valores alvo de gas para os três tipos de gas no bloco pai, usando os LIMIT_TARGET_RATIOS para a divisão inteira no limite de gas da seguinte forma:

A lógica de configuração para limites de gás é a seguinte:

gas_limits[0] deve seguir a fórmula de ajuste existente.

os limites de gas[1] devem ser iguais a MAX_BLOB_GAS_PER_BLOCK.

os limites de gas[2] devem ser iguais aos limites de gas[0] // CALLDATA_GAS_LIMIT_RATIO.

Sabemos que o gas_limits[0] atual é 30000000 e o CALLDATA_GAS_LIMIT_RATIO está predefinido como 4. Isso significa que o alvo de gas calldata atual é aproximadamente 30000000 // 4 // 4 = 1875000. Uma vez que, de acordo com a lógica atual de cálculo de gas calldata, cada byte diferente de zero consome 16 Gas e os bytes zero consomem 4 Gas, assumindo que a distribuição de bytes diferentes de zero e zero em um segmento de calldata é de 50%, o processamento médio de 1 byte de calldata requer 10 Gas. Portanto, o alvo de gas calldata atual deve corresponder a dados calldata de 187500 bytes, aproximadamente o dobro do uso médio atual.

O benefício desta abordagem é reduzir significativamente a probabilidade de a calldata atingir o limite de gás, mantendo a utilização de calldata a um nível relativamente consistente através do modelo econômico e prevenindo abusos de calldata. A razão para este design é pavimentar o caminho para o desenvolvimento de L2, juntamente com dados blob, para reduzir ainda mais o custo do sequenciador.

Aviso Legal:

1. Este artigo é reproduzido a partir de [TechFlow]. Todos os direitos de autor pertencem ao autor original [Web3Mario]. Se houver objeções a esta reimpressão, por favor 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 unicamente as 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.