Introdução

Em 13 de maio de 2024, Vitalik propôs o EIP-7706, sugerindo um plano complementar ao modelo de gás existente. Esta proposta isola o cálculo de gás de calldata e personaliza um mecanismo de precificação de taxa básica semelhante ao gás Blob, reduzindo ainda mais os custos operacionais da Camada 2 (L2). As propostas relacionadas datam da EIP-4844, proposta em fevereiro de 2022. Dado o intervalo de tempo significativo, este artigo analisa os materiais relevantes para fornecer uma visão geral dos desenvolvimentos mais recentes no mecanismo Ethereum Gas, permitindo que os leitores entendam rapidamente as atualizações.

Modelos de gás Ethereum suportados atualmente: EIP-1559 e EIP-4844

Em seu projeto inicial, o Ethereum adotou um mecanismo de leilão simples para precificar as taxas de transação, exigindo que os usuários licitassem ativamente suas transações definindo um preço de gás. Geralmente, como as taxas de transação pagas pelos usuários vão para os mineradores, os mineradores priorizam as transações com base nos lances mais altos, assumindo que não há considerações de Valor Extraível do Minerador (MEV). Os principais desenvolvedores identificaram quatro problemas principais com esse mecanismo:

Descompasso entre a volatilidade da taxa de transação e os custos de consenso: Para um blockchain ativo, há ampla demanda por inclusão de transações, o que significa que os blocos podem ser facilmente preenchidos. No entanto, tal também resulta numa volatilidade significativa das taxas. Por exemplo, quando o preço médio do gás é de 10 Gwei, o custo marginal de adicionar outra transação a um bloco é dez vezes maior do que quando o preço médio do gás é de 1 Gwei, o que é inaceitável.

Atrasos desnecessários para os usuários: Devido ao limite de gás rígido por bloco e às flutuações naturais no volume histórico de transações, as transações geralmente esperam que vários blocos sejam incluídos. Isso é ineficiente para a rede geral porque não há mecanismo de flexibilidade para permitir que um bloco seja maior e o próximo seja menor para atender à demanda variável bloco a bloco.

Ineficiência na fixação de preços: O simples mecanismo de leilão conduz a uma descoberta de preços ineficiente, dificultando aos utilizadores a fixação de um preço razoável. Isso geralmente resulta em usuários pagando a mais pelas taxas de transação.

Instabilidade em um blockchain sem recompensas de bloco: Quando as recompensas de bloco da mineração são removidas e um modelo de taxa pura é adotado, isso pode levar à instabilidade, como a criação de "blocos de tio" que roubam taxas de transação, aumentando os vetores para poderosos ataques egoístas de mineração.

Com a introdução e implementação do EIP-1559, o modelo Gas sofreu sua primeira iteração significativa. Proposto por Vitalik e outros desenvolvedores principais em 13 de abril de 2019 e adotado durante a atualização de Londres em 5 de agosto de 2021, esse mecanismo abandonou o modelo de leilão em favor de um modelo de preço duplo que consiste em uma taxa básica e uma taxa de prioridade. A taxa de base é ajustada quantitativamente através de um modelo matemático predeterminado baseado no consumo de gás no bloco pai em relação a um alvo de gás flutuante e recursivo.

Cálculo e Efeitos da Taxa Base: Se o uso de gás no bloco anterior exceder a meta de gás, a taxa Base aumenta; se ficar aquém da meta do gás, a taxa base diminui. Este ajustamento reflete bem a dinâmica da oferta e da procura e melhora a precisão de previsões razoáveis de gás, evitando preços de gás exorbitantes devido a mau funcionamento, uma vez que o cálculo da taxa de base é determinado pelo sistema e não especificado pelo utilizador. O código específico para o cálculo é o seguinte:

A partir do conteúdo, podemos inferir que quando o parent_gas_used é maior do que o parent_gas_target, a taxa base do bloco atual será aumentada em comparação com a taxa base do bloco anterior por um valor de compensação. Este desvio é determinado multiplicando o parent_base_fee pelo desvio da utilização total de gás em relação ao alvo de gás no bloco anterior, tomando então o resto do alvo de gás e uma constante, e o valor máximo entre este restante e 1. Por outro lado, a lógica aplica-se de forma semelhante quando o parent_gas_used é inferior ao parent_gas_target.

Além disso, a taxa base não será mais distribuída como recompensa aos mineradores, mas será queimada. Isso torna o modelo econômico da ETH deflacionário, ajudando a estabilizar seu valor. Por outro lado, a taxa de prioridade, semelhante a uma gorjeta de usuários para mineradores, pode ser precificada livremente, permitindo algum grau de reutilização nos algoritmos de classificação dos mineradores.

Em 2021, o desenvolvimento do Rollup entrou em um estágio maduro. Sabemos que tanto o OP Rollup quanto o ZK Rollup envolvem a compactação de dados L2 e o upload de alguns dados de prova via calldata para a cadeia para disponibilidade de dados ou verificação on-chain direta. Isso leva a custos significativos de gás na manutenção da finalidade L2, que são, em última análise, suportados pelos usuários, resultando em custos mais altos do que o previsto para a maioria dos protocolos L2.

Simultaneamente, o Ethereum enfrentou o desafio da competição de espaço de bloco. Cada bloco tem um limite de gás, o que significa que o consumo total de gás de todas as transações em um bloco não pode exceder esse limite. Com o limite de gás atual definido em 30.000.000, teoricamente, há um limite de 1.875.000 bytes (30.000.000 / 16) por bloco, onde são necessárias 16 unidades de gás para cada byte de calldata processado pelo EVM, resultando em uma capacidade máxima de dados de cerca de 1,79 MB por bloco. Os dados relacionados ao Rollup gerados pelos sequenciadores L2 são normalmente grandes, criando concorrência com as transações de outros usuários da rede principal e reduzindo o número de transações que podem ser incluídas em um único bloco, afetando assim o TPS da rede principal.

Para resolver esse problema, os principais desenvolvedores propuseram o EIP-4844 em 5 de fevereiro de 2022, que foi implementado após a atualização do Dencun no início do segundo trimestre de 2024. Esta proposta introduziu um novo tipo de transação chamado Blob Transaction. Ao contrário das transações tradicionais, a Transação de Blob inclui um novo tipo de dados, os dados de Blob, que, ao contrário dos dados de chamada, não podem ser acessados diretamente pelo EVM, mas apenas por meio de seu hash, também conhecido como VersionedHash. Além disso, as transações de Blob têm um ciclo de GC mais curto em comparação com as transações regulares, evitando que os dados de bloco fiquem muito inchados. Os dados de Blob também vêm com um mecanismo de gás inerente, semelhante ao EIP-1559, mas usa uma função exponencial natural em seu modelo matemático, proporcionando melhor estabilidade no tratamento de flutuações de tamanho de transação. A inclinação da função exponencial natural também é uma função exponencial natural, o que significa que, independentemente do estado atual dos tamanhos das transações de rede, a taxa base do gás blob reage mais plenamente a picos rápidos de transações, efetivamente restringindo a atividade de transação. Outra característica importante é que o valor da função é 1 quando o eixo horizontal é 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Aqui, MIN_BASE_FEE_PER_BLOB_GAS e BLOB_BASE_FEE_UPDATE_FRACTION são constantes, enquanto excess_blob_gas é determinado pela diferença entre o consumo total de gás de bolha no bloco pai e uma constante TARGET_BLOB_GAS_PER_BLOCK. Quando o consumo total de gás blob excede o valor-alvo, tornando a diferença positiva, e**(excess_blob_gas/BLOB_BASE_FEE_UPDATE_FRACTION) é superior a 1, fazendo com que o base_fee_per_blob_gas aumente, e vice-versa.

Esse mecanismo permite a execução de baixo custo de cenários onde a capacidade de consenso do Ethereum é utilizada para registrar grandes volumes de dados para garantir a disponibilidade sem ocupar a capacidade de empacotamento de transações. Por exemplo, os sequenciadores de Rollup podem usar Transações de Blob para encapsular informações L2 importantes em dados de blob e obter verificação on-chain por meio de VersionedHash dentro do EVM.

Deve-se notar que as configurações atuais para TARGET_BLOB_GAS_PER_BLOCK e MAX_BLOB_GAS_PER_BLOCK impõem uma limitação na rede principal, com um alvo médio de processamento de 3 blobs (0,375 MB) por bloco e um máximo de 6 blobs (0,75 MB) por bloco. Esses limites iniciais visam minimizar o estresse da rede causado por esta EIP, com a expectativa de aumentar esses limites em futuras atualizações, à medida que a rede demonstra confiabilidade sob tamanhos de bloco maiores.

Refinando o Modelo de Consumo de Gás para Ambientes de Execução: EIP-7706

Depois de entender o modelo atual do Ethereum Gas, vamos nos aprofundar nos objetivos e detalhes de implementação da proposta EIP-7706. Esta proposta, apresentada por Vitalik em 13 de maio de 2024, visa redefinir o modelo Gas para um campo de dados específico conhecido como calldata, muito parecido com as mudanças anteriores para dados Blob. Além disso, a proposta otimiza a lógica de código correspondente.

Conceitos Fundamentais

A lógica de cálculo da taxa de base para dados de chamada no EIP-7706 reflete o cálculo da taxa base para dados de blob, conforme especificado no EIP-4844. Ambos utilizam uma função exponencial para ajustar a taxa base com base no desvio entre o consumo real de gás e o valor-alvo no bloco pai.

Um aspeto digno de nota desta proposta é a introdução de um novo desenho de parâmetros, LIMIT_TARGET_RATIOS = [2, 2, 4]. Aqui está o detalhamento:

LIMIT_TARGET_RATIOS[0]: Rácio-alvo para a execução da operação de gás.

LIMIT_TARGET_RATIOS[1]: Relação alvo para gás de dados Blob.

LIMIT_TARGET_RATIOS[2]: Rácio-alvo para o gás calldata.

Estes rácios são utilizados para calcular os valores-alvo de gás para os três tipos de gás no bloco precursor, dividindo o limite de gás pelas respetivas relações.

Os limites de gás são fixados do seguinte modo:

• gas_limits[0] segue a fórmula de ajustamento existente.

• gas_limits[1] igual a MAX_BLOB_GAS_PER_BLOCK.

• gas_limits[2] igual a gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO.

Dado que a corrente gas_limits[0] é de 30 000 000 e que está CALLDATA_GAS_LIMIT_RATIO predefinida para 4, isto significa que o objetivo atual calldata do gás é aproximadamente:

[ \frac{30.000.000}{4 \vezes 4} = 1.875.000 ]

De acordo com a lógica atual calldata de cálculo do gás:

• Cada byte diferente de zero consome 16 gás.

• Cada zero byte consome 4 Gás.

Supondo uma distribuição uniforme de bytes diferentes de zero e zero em um segmento de , o consumo médio de gás por byte é de calldata10 Gás. Assim, o alvo de gás atual calldata corresponde a aproximadamente 187.500 bytes de , o que é cerca de calldataduas vezes o uso médio atual.

Vantagens da proposta

Esse ajuste reduz significativamente a probabilidade de atingir o limite de gás, mantendo calldata o uso em um nível consistente por meio de modelagem econômica e prevenção de calldata abusos. A intenção principal deste design é facilitar o crescimento das soluções de Camada 2, reduzindo os custos do sequenciador quando usado ao lado de dados de blob.

Em conclusão, o EIP-7706 não apenas refina o modelo calldata de gás, mas também posiciona estrategicamente o Ethereum para o escalonamento eficiente de soluções de camada 2, controlando e otimizando o consumo de gás relacionado a dados.

Declaração de exoneração de responsabilidade:

1. Este artigo é reproduzido a partir de [Web3Mario], Todos os direitos autorais pertencem ao autor original [Web3Mario]. Se houver objeções a essa reimpressão, entre em contato com a equipe do Gate Learn e eles lidarão com isso imediatamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.