Autor: @Web3Mario

Introdução: Vitalik lançou a proposta EIP-7706 em 13 de maio de 2024, propondo um esquema complementar ao modelo de gás existente, abandonando o cálculo gás de dados de chamada e personalizando um mecanismo de precificação de taxa básica semelhante ao Blob gás para reduzir 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 fazer uma visão geral do mais recente mecanismo de gás Ethereum para todos entenderem rapidamente.

Atualmente suportado Ethereum modelos a gás - EIP-1559 e EIP-4844

No projeto inicial, Ethereum utiliza um mecanismo de leilão simples para precificar Lavagem de dinheiro, que exige que os usuários licitem ativamente para suas próprias transações, ou seja, para definir um preço do gás, geralmente, porque a taxa de transação paga pelo usuário será vesting do que o 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:

Existe um desfasamento entre o Flutuação do nível de Lavagem de dinheiro e o custo da transação Consenso:* Para Blockchain ativos, a demanda de embalagem para a transação é suficiente, o que significa que o Bloco pode ser facilmente preenchido, mas também muitas vezes significa que o custo total é extremamente Flutuação. Por exemplo, quando o preço do gás médio é de 10 Gwei, o custo marginal da rede para aceitar outra 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ários para os utilizadores: Devido ao limite rígido de gaslimit por Bloco, juntamente com o Flutuação natural de volume histórica, as transações muitas vezes esperam alguns Bloco antes de serem embaladas, mas isso é ineficiente para a rede em 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 de preços ineficiente: A utilização de um mecanismo de leilão simples conduz a uma descoberta ineficiente 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. Uma Blockchain sem Recompensa de bloco será instável: quando o Recompensa de bloco trazido pelo Mineração é removido e um modelo de taxa pura é adotado, pode levar a uma instabilidade muito longo, como incentivar a mineração a roubar o "bloco irmão" do Lavagem de dinheiro, abrir um extração egoísta Vetor de Ataque mais poderoso, etc.

Até EIP-1559 foi proposto e executado, houve uma primeira iteração do modelo Gas, EIP-1559 foi proposto por Vitalik e outros desenvolvedores principais em 13 de abril de 2019 e adotado na atualização de Londres em 5 de agosto de 2021 taxa será baseada no consumo de gás gerado no Bloco-mãe e um gás flutuante e recursivo A relação entre a meta é calculada quantitativamente através de um modelo matemático estabelecido, e o efeito intuitivo é que, se o uso gás no Bloco anterior exceder a meta de gás predeterminada, a taxa base será aumentada e, se for inferior gás meta, a taxa base será reduzida, o que pode refletir melhor a relação entre oferta e demanda. Também pode tornar a previsão de gás razoável mais precisa, e não haverá preço do gás altíssimos causados por mau funcionamento, porque o cálculo da taxa básica é 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 for maior que parent_gás_target, 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 será tomado como pai_base_fee multiplicado pelo deslocamento do uso total do Bloco gás anterior em relação ao destino gás, e o valor máximo do restante e 1 do destino gás 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á diretamente queimada, 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, que pode ser precificada livremente, o que pode permitir que a Algoritmo de triagem do Mineiro seja reutilizada até certo ponto.

Com o avanço do tempo para 2021, quando o desenvolvimento do Rollup entrou gradualmente em uma situação melhor, sabemos que tanto o OP Rollup quanto o ZK Rollup significam que alguns dados de prova após a compressã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 grandes custos de gás ao manter a finalidade L2, e esses custos acabarão sendo repassados aos usuários, de modo que a maioria dos custos de uso do 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 EVM que processa cada calldata Os bytes consomem 16 unidades de gás, o que significa que um único Bloco pode transportar cerca de 1,79 MB de dados longo. Os dados relacionados ao rollup gerados pelo sequenciador L2 geralmente têm uma grande escala de dados, o que o torna competitivo com as confirmações de transações de outros usuários cadeia principal, resultando em um volume menor de transações que podem ser empacotadas em um único bloco, o que, por sua vez, afeta a TPS do cadeia principal.

Para resolver esse dilema, os desenvolvedores principais enviaram uma proposta para EIP-4844 em 5 de fevereiro de 2022, que foi implementada após a atualização do Dencun no início do segundo trimestre de 2024. A proposta propõe um novo tipo de transação chamado Blob Transaction, que é complementado com 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 da transação de blob é mais curto, de modo a garantir que os dados de Bloco não estejam muito inchados, e o outro é que os dados de blob têm um mecanismo de Gas nativo, e o efeito geral é semelhante ao EIP-1559, mas a função exponencial natural é selecionada no modelo matemático, de modo que ele tem um melhor desempenho em termos de estabilidade em resposta às flutuações de tamanho da 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 sobe rapidamente, a taxa base do blob gás responde mais plenamente, 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, e o excesso_blob_gás é determinado pela diferença entre o total de blobs no Bloco gás pai consumido por uma constante TARGET_BLOB_GAS_PER_BLOCK, quando o total de blobs gás consumo exceder o valor-alvo, ou seja, quando a diferença for positiva, e**(excesso_blob_gás / BLOB_BASE_FEE_UPDATE_FRACTION) for maior que 1, base_fee_per_blob__gás se torna maior e vice-versa.

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 e não excluirá a capacidade de empacotamento de transações do bloco. Tomando o sequenciador 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 realizada usando versionedHash através de design engenhoso 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.

Re-refinamento do ambiente de execução gás modelo de consumo - EIP-7706

Agora que o atual modelo Ethereum Gas 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 correspondente a 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 desvio entre o valor real de consumo de gás e o valor-alvo no bloco pai.

Vale a pena notar um novo desenho paramétrico, LIMIT_TARGET_RATIOS=[2,2,4], onde LIMIT_TARGET_RATIOS[0][1]Indica a taxa de destino da operação gás, LIMIT_TARGET_RATIOS[2]Indica a taxa de destino da classe de dados de blob Gas, que é LIMIT_TARGET_RATIOSEste vetor é usado para calcular o valor alvo gás correspondente às três classes de gás no Bloco pai, e a lógica de cálculo é a seguinte, ou seja, LIMIT_TARGET_RATIOS é usado para dividir o limite de gás dividindo o limite:

A lógica de configuração gás_limits é a seguinte:

gás_limits[0]A fórmula de ajustamento existente deve ser seguida

gás_limits[1]Deve ser igual a MAX_BLOB_GAS_PER_BLOCK

gás_limits[2][0]Deve ser igual a gás_limits CALLDATA_GAS_LIMIT_RATIO

Conhecemos o gás_limits atual[0]é 30000000, 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 Bytes diferente de zero consome 16 Gas e zero Bytes consome 4 Gas. Por exemplo, se a distribuição de bytes diferentes de zero e zero em um determinado segmento de calldata representa 50% cada, o processamento médio de 1 byte de calldata consome 10 gás. Portanto, o destino atual de gás de dados de chamada deve lidar com 187.500 bytes de dados de dados de chamada, o que é cerca de duas 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 é Gota o desenvolvimento de L2, e com dados de blob, o custo do sequenciador é ainda mais reduzido.