Encaminhe o título original: "Estamos finalmente prontos para um aumento do limite de gás?"
Tem havido uma discussão crescente em torno da possibilidade de aumentar a produção de gás do Ethereum, seja aumentando o limite de gás ou reduzindo o tempo de slot. O principal argumento a favor disso é que os requisitos de hardware para executar um validador diminuíram constantemente nos últimos quatro anos.
Além disso, 2 abordagens para aumentar o Limite de Gás surgiram:
Neste post, vou analisar os cenários potenciais de pior caso e caso médio em termos de largura de banda, requisitos computacionais e de armazenamento se o limite de gás fosse duplicado.
Quando o Ethereum foi lançado em 2015, o limite de gás foi inicialmente definido para 5.000 gás por bloco. Ao longo do tempo, esse limite sofreu mudanças significativas:
– Após o hard fork Tangerine Whistle e, mais especificamente, a implementação do EIP-150, o limite de gás foi aumentado para 5,5 milhões. Este ajuste foi feito como parte de uma nova fixação de certos opcodes intensivos em E/S em resposta a ataques de negação de serviço (DoS).
– Em julho de 2017, o limite de gás foi elevado para 6,7 milhões, e continuou a aumentar:
- Dezembro de 2017: ~8 milhões
– Setembro de 2019: ~10 milhões
– Agosto de 2020: 12,5 milhões
- Abril de 2021: 15 milhões
Sob o EIP-1559, também há um limite máximo (ou "limite rígido") de gás, que é definido como o dobro do alvo. Isso significa que um bloco pode incluir transações com até 30 milhões de gás.
E por quase quatro anos, não houve nenhum aumento no limite de gás.
Para responder a esta pergunta, precisamos analisar três aspectos dos requisitos de hardware: largura de banda, computação e armazenamento, se o limite de gás fosse aumentado para 60 milhões hoje.
Ao considerar um aumento no limite de gás, o armazenamento se destaca como o maior gargalo e preocupação para a rede Ethereum. A razão para isso reside no crescimento histórico do tamanho do estado da Ethereum e na tensão contínua que isso impõe aos validadores.
Existem dois tipos de “crescimento” no Ethereum:
Crescimento Estatal
Crescimento histórico
O estado do Ethereum – a coleta de todos os saldos de conta, código de contrato inteligente e armazenamento – continua a se expandir à medida que mais transações são processadas e contratos inteligentes são implantados. Desde sua criação, o tamanho do estado cresceu significativamente, com períodos de crescimento acelerado impulsionados pelo congestionamento da rede, aumento da atividade de transações e o aumento das finanças descentralizadas (DeFi) e NFTs. Atualmente, o crescimento do estado é de aproximadamente 2,5 GB por mês, ou 30 GB por ano.
Esse crescimento do estado pode levar aos seguintes problemas:
– Tempos de acesso mais lentos ao disco
– Requisitos de hardware aumentados
No entanto, até o momento em que escrevo, nenhuma dessas questões é particularmente significativa. Na verdade, a diferença no tempo de acesso entre sistemas de armazenamento que diferem em apenas algumas dezenas de gigabytes é bastante insignificante devido à complexidade algorítmica da consulta, que normalmente é logarítmica. Os requisitos de armazenamento também são insignificantes, já que o custo do novo hardware está diminuindo a uma taxa que supera em muito o crescimento relativamente pequeno no tamanho do estado de 30 GB por ano. Mesmo se aumentada para 60 GB/ano, a diferença provavelmente não se destacaria e ainda seria superada pelo progresso tecnológico em hardware de qualquer maneira.
Este aumento no tamanho do estado ainda está sendo superado pelo progresso tecnológico por uma margem significativa. Mesmo que o limite de gás dobrasse, o custo do hardware continua a diminuir exponencialmente, tornando o hardware necessário mais barato ao longo do tempo.
No entanto, vale ressaltar que em breve, os stakers individuais precisarão de mais de 2 TB de armazenamento para executar um validador no Ethereum. Isso efetivamente elevará o requisito para 4 TB de armazenamento, já que a maioria do hardware é vendida em potências de dois. Paradoxalmente, isso significa que o Ethereum poderia muito bem fazer uso do armazenamento adicional, já que os validadores já precisariam investir em hardware de maior capacidade, independentemente de o limite de gás ser aumentado ou não.
NOTA: Não há análise média vs pior caso no armazenamento porque manipular consistentemente blocos por um longo período de tempo (semanas e meses) é um empreendimento insanamente caro.
Para justificar minhas afirmações de que o custo de armazenamento tem diminuído em taxas exponenciais, podemos dar uma olhada nas flutuações de preço em USD de 1 GB de SSD nos últimos quatro anos:
Desculpe a má qualidade, mas a publicação que tirei tinha assim
Parece que a cada dois anos, o custo de um GB de SSD tende a reduzir pela metade.
Se compararmos isso com o crescimento de armazenamento e estado, a diferença é negligenciável. O crescimento atual do Ethereum é linear, enquanto os custos de hardware tendem a diminuir em uma taxa exponencial.
Encontrei um gráfico mais revelador sobre essa tendência com os custos de armazenamento, mas ele é de um post no Reddit e não de uma publicação científica real (embora os resultados sejam compatíveis).
O caso médio para a largura de banda no Ethereum parece algo como 2MB/s; no entanto, a maioria desse número vem dos blocos de gossiping CL e aggreGates. Quando se trata de aumentar o limite de gás, a única coisa a se observar é o tamanho do bloco.
Atualmente, o tamanho máximo do bloco registrado é de 270 KB, e o tamanho atual do bloco pós-Deneb é de 75 KB. Se dobrássemos isso, a mudança seria equivalente a um aumento de 0,5-2 blocos em relação ao máximo histórico e média atual, o que seria equivalente a um aumento de ≈ 2-5% na largura de banda do nó (de entrada e saída). Portanto, no caso médio, não é uma mudança significativa. Na verdade, três blocos adicionais seriam muito mais prejudiciais.
O pior caso foi calculado em 1,7 MB, que se tornaria 3,4 MB (+50% de largura de banda necessária para o pico). Isso não é muito, mas ainda é significativo. A razão pela qual eu acho que isso não é muito é que um ataque de DoS desse tipo seria bastante caro e o pico seria +50% dos requisitos médios atuais, o que já está contabilizado. Como eu estava dizendo, preencher blocos no valor de 15 milhões de gás até a borda por vários blocos sucessivos é muito caro. Portanto, mesmo que um atacante possa potencialmente lançar um ataque de DoS por alguns blocos, eles teriam que gastar uma quantia significativa de dinheiro para fazê-lo. Além disso, eles teriam que competir com outras transações para entrar no bloco, o que torna isso ainda mais caro.
Em qualquer caso, independentemente das opiniões sobre os números, um aumento no custo do calldata resolveria esse problema completamente, então não estou preocupado com isso em nenhum caso. Além disso, se o limite de gás for elevado através do EIP-7783, esses riscos são insignificantes e controláveis.
A computação e os tempos de bloco nunca foram um problema desde o início, mas aqui vamos nós.
O caso médio para a computação de blocos geralmente é <1 segundo, mesmo para máquinas lentas com discos ruins. Não há muito do que discutir aqui - em média, isso nunca foi o gargalo.
O pior caso parece ser incerto e depende do cliente. Após conversar com algumas equipes de clientes, parece que o consenso é que o único problema seria que alguns opcodes não têm uma boa escalabilidade (como MODEXP).
No entanto, quaisquer vetores DoS aqui podem ser corrigidos com um repreço, e se o aumento do limite de gás for feito com EIP-7783, esses riscos são insignificantes.
No geral, parece que o crescimento do armazenamento não é o gargalo para aumentar o limite de gás, já que hardware como armazenamento é fácil de atualizar. No entanto, a largura de banda representa uma ameaça maior, pois é muito mais difícil de escalar. Felizmente, com o EIP-7783, os riscos relacionados à largura de banda e potenciais aumentos na computação são efetivamente mitigados. No entanto, pode ser sensato reprecificar o custo dos dados de chamada para garantir segurança adicional (embora, na minha opinião, provavelmente não seja necessário).
Na minha opinião pessoal, é possível aumentar atualmente o Limite de Gás em 33% ou até mesmo dobrá-lo hoje, se feito com o aumento gradual introduzido pelo EIP-7783.
Eu acho que ainda é muito cedo para fazer isso através do EIP-7782, pois seria punitivo para DVT e SSF. No entanto, uma vez que esses problemas forem resolvidos - uma redução nos tempos de slot é definitivamente necessária.
Encaminhe o título original: "Estamos finalmente prontos para um aumento do limite de gás?"
Tem havido uma discussão crescente em torno da possibilidade de aumentar a produção de gás do Ethereum, seja aumentando o limite de gás ou reduzindo o tempo de slot. O principal argumento a favor disso é que os requisitos de hardware para executar um validador diminuíram constantemente nos últimos quatro anos.
Além disso, 2 abordagens para aumentar o Limite de Gás surgiram:
Neste post, vou analisar os cenários potenciais de pior caso e caso médio em termos de largura de banda, requisitos computacionais e de armazenamento se o limite de gás fosse duplicado.
Quando o Ethereum foi lançado em 2015, o limite de gás foi inicialmente definido para 5.000 gás por bloco. Ao longo do tempo, esse limite sofreu mudanças significativas:
– Após o hard fork Tangerine Whistle e, mais especificamente, a implementação do EIP-150, o limite de gás foi aumentado para 5,5 milhões. Este ajuste foi feito como parte de uma nova fixação de certos opcodes intensivos em E/S em resposta a ataques de negação de serviço (DoS).
– Em julho de 2017, o limite de gás foi elevado para 6,7 milhões, e continuou a aumentar:
- Dezembro de 2017: ~8 milhões
– Setembro de 2019: ~10 milhões
– Agosto de 2020: 12,5 milhões
- Abril de 2021: 15 milhões
Sob o EIP-1559, também há um limite máximo (ou "limite rígido") de gás, que é definido como o dobro do alvo. Isso significa que um bloco pode incluir transações com até 30 milhões de gás.
E por quase quatro anos, não houve nenhum aumento no limite de gás.
Para responder a esta pergunta, precisamos analisar três aspectos dos requisitos de hardware: largura de banda, computação e armazenamento, se o limite de gás fosse aumentado para 60 milhões hoje.
Ao considerar um aumento no limite de gás, o armazenamento se destaca como o maior gargalo e preocupação para a rede Ethereum. A razão para isso reside no crescimento histórico do tamanho do estado da Ethereum e na tensão contínua que isso impõe aos validadores.
Existem dois tipos de “crescimento” no Ethereum:
Crescimento Estatal
Crescimento histórico
O estado do Ethereum – a coleta de todos os saldos de conta, código de contrato inteligente e armazenamento – continua a se expandir à medida que mais transações são processadas e contratos inteligentes são implantados. Desde sua criação, o tamanho do estado cresceu significativamente, com períodos de crescimento acelerado impulsionados pelo congestionamento da rede, aumento da atividade de transações e o aumento das finanças descentralizadas (DeFi) e NFTs. Atualmente, o crescimento do estado é de aproximadamente 2,5 GB por mês, ou 30 GB por ano.
Esse crescimento do estado pode levar aos seguintes problemas:
– Tempos de acesso mais lentos ao disco
– Requisitos de hardware aumentados
No entanto, até o momento em que escrevo, nenhuma dessas questões é particularmente significativa. Na verdade, a diferença no tempo de acesso entre sistemas de armazenamento que diferem em apenas algumas dezenas de gigabytes é bastante insignificante devido à complexidade algorítmica da consulta, que normalmente é logarítmica. Os requisitos de armazenamento também são insignificantes, já que o custo do novo hardware está diminuindo a uma taxa que supera em muito o crescimento relativamente pequeno no tamanho do estado de 30 GB por ano. Mesmo se aumentada para 60 GB/ano, a diferença provavelmente não se destacaria e ainda seria superada pelo progresso tecnológico em hardware de qualquer maneira.
Este aumento no tamanho do estado ainda está sendo superado pelo progresso tecnológico por uma margem significativa. Mesmo que o limite de gás dobrasse, o custo do hardware continua a diminuir exponencialmente, tornando o hardware necessário mais barato ao longo do tempo.
No entanto, vale ressaltar que em breve, os stakers individuais precisarão de mais de 2 TB de armazenamento para executar um validador no Ethereum. Isso efetivamente elevará o requisito para 4 TB de armazenamento, já que a maioria do hardware é vendida em potências de dois. Paradoxalmente, isso significa que o Ethereum poderia muito bem fazer uso do armazenamento adicional, já que os validadores já precisariam investir em hardware de maior capacidade, independentemente de o limite de gás ser aumentado ou não.
NOTA: Não há análise média vs pior caso no armazenamento porque manipular consistentemente blocos por um longo período de tempo (semanas e meses) é um empreendimento insanamente caro.
Para justificar minhas afirmações de que o custo de armazenamento tem diminuído em taxas exponenciais, podemos dar uma olhada nas flutuações de preço em USD de 1 GB de SSD nos últimos quatro anos:
Desculpe a má qualidade, mas a publicação que tirei tinha assim
Parece que a cada dois anos, o custo de um GB de SSD tende a reduzir pela metade.
Se compararmos isso com o crescimento de armazenamento e estado, a diferença é negligenciável. O crescimento atual do Ethereum é linear, enquanto os custos de hardware tendem a diminuir em uma taxa exponencial.
Encontrei um gráfico mais revelador sobre essa tendência com os custos de armazenamento, mas ele é de um post no Reddit e não de uma publicação científica real (embora os resultados sejam compatíveis).
O caso médio para a largura de banda no Ethereum parece algo como 2MB/s; no entanto, a maioria desse número vem dos blocos de gossiping CL e aggreGates. Quando se trata de aumentar o limite de gás, a única coisa a se observar é o tamanho do bloco.
Atualmente, o tamanho máximo do bloco registrado é de 270 KB, e o tamanho atual do bloco pós-Deneb é de 75 KB. Se dobrássemos isso, a mudança seria equivalente a um aumento de 0,5-2 blocos em relação ao máximo histórico e média atual, o que seria equivalente a um aumento de ≈ 2-5% na largura de banda do nó (de entrada e saída). Portanto, no caso médio, não é uma mudança significativa. Na verdade, três blocos adicionais seriam muito mais prejudiciais.
O pior caso foi calculado em 1,7 MB, que se tornaria 3,4 MB (+50% de largura de banda necessária para o pico). Isso não é muito, mas ainda é significativo. A razão pela qual eu acho que isso não é muito é que um ataque de DoS desse tipo seria bastante caro e o pico seria +50% dos requisitos médios atuais, o que já está contabilizado. Como eu estava dizendo, preencher blocos no valor de 15 milhões de gás até a borda por vários blocos sucessivos é muito caro. Portanto, mesmo que um atacante possa potencialmente lançar um ataque de DoS por alguns blocos, eles teriam que gastar uma quantia significativa de dinheiro para fazê-lo. Além disso, eles teriam que competir com outras transações para entrar no bloco, o que torna isso ainda mais caro.
Em qualquer caso, independentemente das opiniões sobre os números, um aumento no custo do calldata resolveria esse problema completamente, então não estou preocupado com isso em nenhum caso. Além disso, se o limite de gás for elevado através do EIP-7783, esses riscos são insignificantes e controláveis.
A computação e os tempos de bloco nunca foram um problema desde o início, mas aqui vamos nós.
O caso médio para a computação de blocos geralmente é <1 segundo, mesmo para máquinas lentas com discos ruins. Não há muito do que discutir aqui - em média, isso nunca foi o gargalo.
O pior caso parece ser incerto e depende do cliente. Após conversar com algumas equipes de clientes, parece que o consenso é que o único problema seria que alguns opcodes não têm uma boa escalabilidade (como MODEXP).
No entanto, quaisquer vetores DoS aqui podem ser corrigidos com um repreço, e se o aumento do limite de gás for feito com EIP-7783, esses riscos são insignificantes.
No geral, parece que o crescimento do armazenamento não é o gargalo para aumentar o limite de gás, já que hardware como armazenamento é fácil de atualizar. No entanto, a largura de banda representa uma ameaça maior, pois é muito mais difícil de escalar. Felizmente, com o EIP-7783, os riscos relacionados à largura de banda e potenciais aumentos na computação são efetivamente mitigados. No entanto, pode ser sensato reprecificar o custo dos dados de chamada para garantir segurança adicional (embora, na minha opinião, provavelmente não seja necessário).
Na minha opinião pessoal, é possível aumentar atualmente o Limite de Gás em 33% ou até mesmo dobrá-lo hoje, se feito com o aumento gradual introduzido pelo EIP-7783.
Eu acho que ainda é muito cedo para fazer isso através do EIP-7782, pois seria punitivo para DVT e SSF. No entanto, uma vez que esses problemas forem resolvidos - uma redução nos tempos de slot é definitivamente necessária.