Autor Original: @Web3 Mario

Introdução: Em 13 de maio de 2024, a Vitalik lançou a proposta EIP-7706, propondo uma solução complementar ao modelo de gás existente, separando o cálculo gás dos dados de chamada e personalizando um mecanismo de precificação de taxa básica semelhante ao Blob gás para Gota ainda mais o custo operacional do L2. A proposta relacionada também precisa ser rastreada até EIP-4844 proposta em fevereiro de 2022, que é um longo tempo atrás, então confira os materiais relevantes para fornecer uma visão geral do mecanismo de gás Ethereum mais recente para você entender rapidamente.

Os modelos Ethereum Gas atualmente suportados - EIP-1559 e EIP-4844

No projeto original, a Ethereum utiliza um mecanismo de leilão simples para precificar Lavagem de dinheiro, o que exige que os usuários licitem ativamente para suas próprias transações, ou seja, para definir um preço do gás, normalmente, porque a taxa de transação paga pelos usuários será vesting de Mineiro, então o Mineiro determinará o ordem de embalagem da transação de acordo com o princípio da otimização econômica, de acordo com o nível de licitação, note que isso é no caso de ignorar MEV. Aos olhos dos principais desenvolvedores da época, esse mecanismo enfrentava os seguintes quatro problemas:

• Flutuação no nível de Lavagem de dinheiro e no custo de consenso das transações: Em um Blockchain ativo, há demanda suficiente para embalagens de transações, o que significa que os blocos podem ser facilmente preenchidos, mas isso muitas vezes também significa que o Flutuação geral da taxa é extremamente alto. Por exemplo, quando o preço do gás médio é de 10 Gwei, o custo marginal da rede para aceitar mais uma transação em um bloco é 10 vezes maior do que o preço do gás médio de 1 Gwei, o que é inaceitável.
• latência desnecessárias para os usuários: Devido ao limite de gás difícil de cada bloco, juntamente com a flutuação natural do histórico de volume, as transações geralmente esperam que vários blocos sejam empacotados, mas isso é ineficiente para a rede geral; Ou seja, não existe um mecanismo de "folga" que permita que um Bloco seja maior e o Bloco seguinte menor para atender às diferenças de necessidades que são Bloco caso a caso.
• Fixação ineficiente dos preços: A utilização de um mecanismo simples de leilão conduz a uma descoberta ineficaz de preços justos, o que significa que será difícil para os utilizadores darem um preço razoável, o que significa que, em casos muito longo, os utilizadores pagam taxas elevadas.
• Blockchain livres de Recompensa de bloco serão instáveis: Quando o Recompensa de bloco trazido pela Mineração é removido e um modelo de taxa pura é adotado, isso pode levar a uma instabilidade muito longo, como incentivar a mineração a roubar Lavagem de dinheiro "blocos irmãos", abrir extração egoísta Vetor de Ataque mais poderosos, etc.

Foi só quando EIP-1559 foi proposto e implementado que houve uma primeira iteração do modelo Gas, que foi proposto por desenvolvedores principais, como a Vitalik, em 13 de abril de 2019, e adotado na atualização de Londres em 5 de agosto de 2021, que abandonou o mecanismo de leilão em favor de um modelo de preço duplo de taxa básica e taxa prioritária, onde a taxa base seria baseada no gás já gerado na Bloco mãe A relação entre o consumo e uma meta de gás flutuante e recursiva é calculada quantitativamente através de um modelo matemático estabelecido, e o efeito intuitivo é que, se o uso de gás no Bloco anterior exceder a meta de gás predeterminada, a taxa básica será aumentada e, se for menor do que a meta gás, a taxa base será reduzida, o que pode não apenas refletir melhor a relação entre oferta e demanda, mas também tornar a previsão de gás razoável mais precisa. Não haverá grandes preço do gás devido ao mau funcionamento, porque o cálculo da taxa base é diretamente determinado pelo sistema e não livremente especificado pelo usuário. O código específico é o seguinte:

Pode-se ver que quando parent\gás_used é maior que parent_gás_target, então a taxa base do Bloco atual será comparada com a taxa base do Bloco anterior mais um valor de compensação, e o valor de deslocamento é tomado como pai_base_fee multiplicado pelo deslocamento do uso total do Bloco gás anterior em relação a gás destino, e o valor máximo do restante de 1 com gás destino e uma constante. A lógica inversa é semelhante.

Além disso, a taxa base não mais longo será distribuída aos mineiros como recompensa, mas será queimada diretamente, de modo que o modelo econômico de ETH esteja em estado deflacionário, o que é propício à estabilidade do valor. Por outro lado, a taxa de prioridade é equivalente à gorjeta do usuário ao Mineiro, e o preço pode ser definido livremente, o que pode permitir que a Algoritmo de triagem do Mineiro seja reutilizada até certo ponto.

À medida que o tempo avança para 2021, quando o desenvolvimento do Rollup entra gradualmente em um estado melhor, sabemos que tanto o OP Rollup quanto o ZK Rollup significam que alguns dados de prova após a compactação de dados L2 precisam ser carregados para o na cadeia através de calldata para alcançar a disponibilidade de dados ou entregues diretamente ao na cadeia para verificação. Como resultado, essas soluções de rollup enfrentam custos gás significativos ao manter a finalidade L2, e esses custos são repassados aos usuários, de modo que a maioria dos custos de uso de L2 protocolo não são tão baixos quanto se imaginava.

Ao mesmo tempo, Ethereum também está enfrentando o dilema da concorrência entre Bloco curto, sabemos que há uma limite de gás para cada Bloco, o que significa que o consumo total de gás de todas as transações na Bloco corrente não pode exceder esse valor, com base no limite de gás atual de 300000000, há um limite teórico de 30, 000, 000 / 16 = 1, 875, 000 bytes, onde 16 se refere ao consumo de 16 por byte de calldata processado pelo EVM Isso significa que o longo máximo de um único Bloco pode transportar dados é de cerca de 1,79 MB. Os dados relacionados ao rollup gerados pelo sequenciador L2 geralmente são em grande escala, o que o faz competir com as confirmações de transações de outros usuários cadeia principal, resultando em um volume menor que pode ser empacotado em um único bloco, o que, por sua vez, afeta a TPS do cadeia principal.

Para resolver esse dilema, os principais desenvolvedores propuseram EIP-4844 em 5 de fevereiro de 2022, que foi implementado após a atualização de Dencun no início do segundo trimestre de 2024. A proposta propõe um novo tipo de transação chamado Blob Transaction, que se baseia em um novo tipo de dados, Blob data, que é um novo tipo de dados, Blob data, em comparação com o tipo tradicional de Transação. Ao contrário do tipo calldata, os dados de blob não podem ser acessados diretamente pelo EVM, mas apenas seu hash, também conhecido como VersionedHash. Além disso, há dois designs que o acompanham, um é que, em comparação com transações comuns, o período GC de transações de blob é mais curto, de modo a garantir que os dados de bloco não sejam muito inchados, e o segundo é que os dados de blob têm um mecanismo de gás nativo, que geralmente apresenta um efeito semelhante ao EIP-1559, mas escolhe a função exponencial natural no modelo matemático, para que possa ter um melhor desempenho em estabilidade ao lidar com flutuações de tamanho de transação, porque a inclinação da função exponencial natural também é uma função exponencial natural, Isso significa que, independentemente do estado em que o tamanho da transação de rede está neste momento, quando o tamanho da transação aumenta rapidamente, a taxa base do blob gás responde mais completamente, reduzindo efetivamente a atividade de transação, e a função também tem uma característica importante, quando a abscissa é 0, o valor da função é 1.

base_fee_per_blob_gás = MIN_BASE_FEE_PER_BLOB_GAS * e**(excesso_blob_gás / BLOB_BASE_FEE_UPDATE_FRACTION)

onde MIN_BASE_FEE_PER_BLOB_GAS e BLOB_BASE_FEE_UPDATE_FRACTION são duas constantes, enquanto o excesso_blob_gás é determinado pela diferença entre o total de blobs no Bloco gás pai e uma constante TARGET_BLOB_GAS_PER_BLOCK, quando o total de blobs gás Quando o consumo excede o valor-alvo, ou seja, quando a diferença é positiva, e**(excesso_blob_gás / BLOB_BASE_FEE_UPDATE_FRACTION) é maior que 1, então base_fee_per_blob_gás torna-se maior e vice-versa torna-se menor.

Dessa forma, para alguns cenários que desejam usar apenas a capacidade de consenso do Ethereum para armazenar alguns dados em grande escala para garantir a disponibilidade, ele pode ser executado a baixo custo sem excluir a capacidade de empacotamento de transações do bloco. Tomando o sequenciador de rollup como exemplo, as principais informações de L2 podem ser encapsuladas em dados de blob por meio de transação de blob, e a lógica de verificação de na cadeia pode ser implementada usando versionedHash através de design inteligente no EVM.

Deve-se acrescentar que as configurações atuais TARGET_BLOB_GAS_PER_BLOCK e MAX_BLOB_GAS_PER_BLOCK introduzem um limite de Rede principal de 3 blobs (0,375 MB) por Bloco e um máximo de 6 blobs (0,75 MB) por longo. Esses limites iniciais são projetados para minimizar a pressão sobre a rede a partir desse EIP e espera-se que aumentem em atualizações futuras, à medida que a rede demonstra confiabilidade em blocos maiores.

Refina o modelo de consumo de gás para o ambiente de execução - EIP-7706

Agora que o atual modelo de Ethereum gás foi esclarecido, vamos dar uma olhada nos objetivos e detalhes de implementação da proposta EIP-7706. A proposta foi apresentada por Vitalik em 13 de maio de 2024. Semelhante aos dados de blob, esta proposta retira o modelo de gás para outro campo de dados especial, que é calldata. E a lógica de implementação de código correspondente foi otimizada.

Em princípio, a lógica de cálculo da taxa base dos dados de chamada é a mesma da taxa base para dados de blob em EIP-4844, que usa uma função exponencial e calcula o escalonamento da taxa base atual com base no valor de desvio do valor real de consumo de gás no bloco pai do valor-alvo em relação ao 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 razão de destino da classe de operação Gas, LIMIT_TARGET_RATIOS[ 1 ] representa a razão de destino da classe de dados Blob Gas, e LIMIT_TARGET_RATIOS [ 2 ] representa os calldata A razão alvo da classe Gas, este vetor é usado para calcular os gás valores-alvo correspondentes às três classes de gás no Bloco pai, e a lógica de cálculo é a seguinte, ou seja, o limite de gás é divisível por LIMIT_TARGET_RATIOS respectivamente:

A lógica de gás_limits é a seguinte:

gás_limits[ 0 ] deve seguir a fórmula de ajuste existente

gás_limits[ 1 ] deve ser igual a MAX_BLOB_GAS_PER_BLOCK

gás_limits[ 2 ] deve ser igual a gás_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO

Sabemos que o gás_limits[ 0 ] atual é 30000000, e CALLDATA_GAS_LIMIT_RATIO é predefinido como 4, o que significa que o destino atual do gás calldata é de cerca de 300000000 // 4 // 4 = 1875000, e porque de acordo com a lógica de cálculo de gás de dados de chamada atual, cada byte diferente de zero consome 16 gás e zero bytes consome 4 gás. Supondo que a distribuição de bytes diferentes de zero e zero em um determinado segmento de calldata seja responsável por 50% cada, leva em média 10 gás para processar 1 byte de calldata. Portanto, o destino atual de gás de dados de chamada deve lidar com 187500 bytes de dados de dados de chamada, o que é cerca de 2 vezes o uso médio atual.

A vantagem disso é que a probabilidade de calldata chegar ao limite de gás é muito reduzida, e o uso de calldata é mantido em um estado mais consistente por meio de modelagem econômica, e o abuso de calldata também é eliminado. A razão para este design é abrir caminho para o desenvolvimento de L2, e com dados de blob, o custo do sequenciador é ainda mais reduzido.