Uma vez que o Ethereum seguiu o roadmap centrado em acúmulos, toda a comunidade acreditava que os acúmulos seriam a solução para o problema de escalabilidade do Ethereum. No entanto, até o momento, os acúmulos ainda são inferiores a alguns L1s de alto desempenho em termos de poder de computação.
Provavelmente, isso se deve ao fato de que as equipes de acúmulos têm que lidar não apenas com a execução, mas também com vários sistemas de prova, pontes e outras coisas em seus esforços para escalar o Ethereum.
Mas temos um tipo de acúmulos que surgiu para trazer à tona o verdadeiro poder dos acúmulos: acúmulos Gigagas. Em nossa série anterior, exploramos acúmulos baseados, acúmulos booster e acúmulos nativos. Neste artigo, examinaremos os acúmulos Gigagas, analisando o que eles estão tentando resolver e como eles funcionam.
O principal problema de desempenho para L2s tem se concentrado no problema do DA. No entanto, com os avanços recentes em soluções externas do DA, como @eigen_dae introdução de blobs, DA já não é o gargalo. Em vez disso, agora nos deparamos com várias novas restrições.
Uma das maiores razões para o problema de desempenho é que as implementações do EVM geralmente são de única thread, o que significa que elas utilizam apenas um núcleo da CPU por vez, mesmo que as CPUs modernas tenham vários núcleos capazes de lidar com diferentes tarefas simultaneamente. Como resultado, o limite de desempenho é definido pela velocidade do relógio de um único núcleo.
A transição para a execução paralela é complexa devido às mudanças necessárias no EVM, gerenciamento de estado e estrutura de transação. Enquanto isso, pesquisas recentes por@VangelisAndr, mostrou que64,85% das transações do Ethereumpode ser paralelizado, imagine quantas transações podem ser paralelizadas em L2s para impulsionar ainda mais o desempenho.
Outro desafio surge ao aumentar o limite de gás do bloco em L2s para obter maior rendimento, pois isso pode comprometer os mecanismos de prova. Se as provas de fraude exigirem a submissão de blocos inteiros, elas podem entrar em conflito com os próprios limites de tamanho de bloco do Ethereum. A produção de blocos L2 difere da L1, oferecendo oportunidades de otimização e paralelização no sequenciador e cliente de execução, afastando-se dos conceitos tradicionais da L1.
Um desafio significativo é alcançar uma sequenciação compartilhada para aprimorar a interoperabilidade da L2, mantendo a descentralização. No entanto, essa abordagem ainda é inovadora, e os principais acúmulos podem resistir a entregar o controle da sequenciação a terceiros, já que os benefícios do aumento da composabilidade não são claros e o desempenho pode ser comprometido.
O Ethereum usa Merkle-Patricia Tries (MPTs) modificados para gerenciar e verificar seus dados de chave-valor. A EVM não especifica como o estado deve ser armazenado, permitindo que os clientes experimentem soluções diferentes. Atualmente, implementações como LevelDB, PebbleDB e MDBX estão em uso, mas elas não possuem as propriedades inerentes das lojas de chave-valor autenticadas, como provas criptográficas de integridade. Isso aumenta as suposições de confiança, complica as provas de fraude e adiciona sobrecarga à verificação de alterações de estado, afetando a eficiência e a segurança.
Para a maioria dos acúmulos, o desempenho é tipicamente medido por transações em vez de gás. No entanto, antes de analisarmos como os acúmulos gigagas abordam os problemas de escalabilidade, vamos explorar por que o gás, em vez de TPS, é uma métrica mais significativa e por que devemos prestar atenção a isso.
O desempenho em acúmulos e no próprio Ethereum é frequentemente medido por Transações por Segundo (TPS), mas uma métrica mais precisa pode ser 'gás por segundo'. Essa medida indica a capacidade computacional da rede a cada segundo, sendo que 'gás' representa o custo computacional da execução de operações como transações ou contratos inteligentes.
TPS, no entanto, negligencia a complexidade e as demandas de recursos variáveis de diferentes transações e operações, tornando-se um indicador incompleto e muitas vezes enganoso do desempenho da rede. Uma rede pode lidar com mais transações a um custo computacional mais baixo, no entanto, TPS falharia em refletir a verdadeira capacidade do sistema.
Adotar gás por segundo como uma métrica de desempenho padrão fornece uma imagem mais clara e precisa da capacidade e eficiência de um blockchain. Você pode ler um artigo de@paramonowwsobre o porquêTPS é uma métrica boba.
Preocupar-se com as taxas de gás é importante porque isso reflete a quantidade de trabalho que a rede pode lidar, fornecendo uma imagem mais clara de escalabilidade e eficiência. A precificação do gás influencia a economia da rede, afetando as taxas de transação e recompensas, o que, por sua vez, impacta o comportamento do usuário e a segurança da rede. Portanto, enquanto transações por segundo oferecem uma visão geral, o gás por segundo oferece uma compreensão mais profunda das verdadeiras capacidades de desempenho de uma blockchain.
Agora que entendemos o gás, o que são gigagas e os acúmulos de gigagas especificamente?
Gigagas mede a largura de banda em bilhões de unidades de gás por segundo, proporcionando uma medição superior de capacidade em relação ao TPS. Os acúmulos de gigagas são essencialmente acúmulos projetados para gerenciar uma largura de banda de 1 gigaga por segundo, processando 1 bilhão de unidades de gás por segundo. Embora o conceito seja direto, sua implementação é desafiadora. Atualmente, mesmo com sequenciamento centralizado, nenhum acúmulo Ethereum chega perto desse benchmark, com todo o ecossistema gerenciando apenas cerca de 60 Mgas (60 milhões de unidades de gás) por segundo.
Origem:acúmulos.wtf
Os acúmulos da Gigagas aumentariam a capacidade de processamento lidando com transações em gigagas, permitindo volumes de transações vastos ou operações complexas rapidamente. Eles melhorariam a eficiência por meio de inovações na compressão de dados, geração de provas e publicação de dados da cadeia principal, visando mínima sobrecarga e máxima capacidade de processamento.
Várias equipes estão desenvolvendo ativamente acúmulos gigagas. Por exemplo, @Abundance_xyz está construindo uma pilha completa de acúmulos gigagas, enquanto @rise_chainestá focando na construção de acúmulos de gigagas, introduzindo modificações e otimizações extensivas no EVM e além. Vamos analisar como os acúmulos de gigagas funcionam, com ênfase especial no RISE.
RISE é uma plataforma L2 projetada para lidar com os problemas de desempenho de acúmulos do Ethereum. Apesar dos avanços, as soluções L2 atuais não conseguem igualar a velocidade da Solana. RISE utiliza um EVM paralelo, execução contínua e uma nova arquitetura de estado no RethSDK para aumentar a capacidade de processamento. RISE tem como objetivo largura de banda acima de 1 Gigagas por segundo.
A arquitetura da RISE inclui um mecanismo de execução paralelo EVM totalmente de código aberto chamado pevm, que suporta execução contínua através de um pipeline de blocos. Para acesso ao estado, a RISE utiliza Árvores de Merkle Versionadas para otimizar o desempenho e um banco de dados personalizado, RiseDB, adaptado para os estados da cadeia EVM.
A pilha RISE é construída em Reth. Em relação à disponibilidade de dados, a arquitetura requer largura de banda alta e é modular para acomodar várias soluções de disponibilidade de dados. A RISE também utiliza sequenciamento baseado para descentralizar a produção de blocos. Se você não sabe o que são acúmulos baseados, você pode dar uma olhada emo primeiro artigo desta série, que examina seus prós e contras.
Nos cenários típicos da Camada 2, apenas cerca de 8% do tempo de bloco é gasto na execução devido a um processo sequencial envolvendo consenso, execução e merklização. Isso se torna ineficiente, pois o consenso pode levar de 40 a 80% e a merklização até 60% do tempo restante. O Continuous Block Pipeline (CBP) da RISE melhora isso com execução paralela, processamento contínuo de transações e computação simultânea da raiz do estado. Isso permite uma utilização quase 100% do tempo de bloco para a execução de transações, melhorando significativamente a eficiência em relação aos métodos tradicionais.
O Ethereum usa um sistema de estado em duas camadas com uma árvore Merkle Patricia Trie (MPT). O MPT garante a integridade dos dados, mas leva a uma alta amplificação de leitura e gravação devido à sua estrutura e à natureza da árvore LSM (Log-Structured-Merge) do banco de dados. Isso resulta em numerosas operações de E / S para consultas de estado. O MPT emprega nós de extensão para reduzir a redundância, mas os desafios incluem uso ineficiente de SSD, sobrecarga significativa de compactação e subutilização de CPU durante as esperas de E / S.
RISE enfrenta esses problemas usando uma Árvore de Merkle Versionada, que melhora a eficiência de armazenamento com chaves versionadas. Também emprega a abordagem LETUS com codificação delta e arquivos de estrutura de log para reduzir os efeitos de amplificação. Isso resulta em uma melhor gestão de armazenamento e recuperação de dados mais eficiente.
Existem muitas razões pelas quais nem todos os acúmulos se tornarão um acúmulo gigagas. Nem todas as aplicações exigem um desempenho tão alto, e a complexidade e o custo associados à tecnologia gigagas podem não ser justificados para projetos com necessidades de transação mais baixas ou casos de uso mais simples.
Alguns acúmulos priorizam outros aspectos como facilidade de uso, privacidade ou aplicativos específicos do setor em vez de apenas rendimento. Também existe o equilíbrio entre escalabilidade e descentralização, onde alguns preferem manter uma estrutura mais descentralizada em vez de buscar um desempenho gigantesco. A escalabilidade incremental pode ser mais prática, evitando a necessidade de extensas alterações no sistema.
Mover para níveis gigagas pode perturbar integrações existentes ou complicar interações do usuário sem necessidade. A escolha de se tornar um acúmulo de gigagas depende muito de recursos, objetivos estratégicos e posicionamento geral da cadeia.
Os rollups gigagas representam um avanço significativo na jornada de escalabilidade do Ethereum, introduzindo várias melhorias na pilha de rollup. Com esses novos recursos, os rollups gigagas abordam gargalos principais, como execução de thread única, gerenciamento de merkleização e ineficiências de armazenamento de estado que os rollups L2 tradicionais enfrentam atualmente.
No entanto, alcançar um desempenho de gigagas requer uma mudança arquitetônica relativamente complexa e transformadora. Além disso, envolve compensações, como o equilíbrio entre escalabilidade e descentralização. Como resultado, não é necessário que cada rollup no ecossistema seja um rollup de Gigagas.
Além de tudo isso, parece que os acúmulos da gigagas proporcionarão ótimas oportunidades para a comunidade Ethereum demonstrar o verdadeiro poder do Ethereum.
Ao longo desta série de acúmulos, mergulhamos a fundo em diferentes tipos de escalonamento do Ethereum: deacúmulos baseados em Parte Iparaacúmulos de impulso na Parte II,acúmulos nativos na Parte IIIe finalmente gigagas acúmulos nesta parte final. Este artigo encerra nossa exploração dos acúmulos, mas está longe de ser o fim da jornada. Fique ligado para novas séries e artigos detalhados sobre as últimas inovações que moldam o futuro do Ethereum!
Uma vez que o Ethereum seguiu o roadmap centrado em acúmulos, toda a comunidade acreditava que os acúmulos seriam a solução para o problema de escalabilidade do Ethereum. No entanto, até o momento, os acúmulos ainda são inferiores a alguns L1s de alto desempenho em termos de poder de computação.
Provavelmente, isso se deve ao fato de que as equipes de acúmulos têm que lidar não apenas com a execução, mas também com vários sistemas de prova, pontes e outras coisas em seus esforços para escalar o Ethereum.
Mas temos um tipo de acúmulos que surgiu para trazer à tona o verdadeiro poder dos acúmulos: acúmulos Gigagas. Em nossa série anterior, exploramos acúmulos baseados, acúmulos booster e acúmulos nativos. Neste artigo, examinaremos os acúmulos Gigagas, analisando o que eles estão tentando resolver e como eles funcionam.
O principal problema de desempenho para L2s tem se concentrado no problema do DA. No entanto, com os avanços recentes em soluções externas do DA, como @eigen_dae introdução de blobs, DA já não é o gargalo. Em vez disso, agora nos deparamos com várias novas restrições.
Uma das maiores razões para o problema de desempenho é que as implementações do EVM geralmente são de única thread, o que significa que elas utilizam apenas um núcleo da CPU por vez, mesmo que as CPUs modernas tenham vários núcleos capazes de lidar com diferentes tarefas simultaneamente. Como resultado, o limite de desempenho é definido pela velocidade do relógio de um único núcleo.
A transição para a execução paralela é complexa devido às mudanças necessárias no EVM, gerenciamento de estado e estrutura de transação. Enquanto isso, pesquisas recentes por@VangelisAndr, mostrou que64,85% das transações do Ethereumpode ser paralelizado, imagine quantas transações podem ser paralelizadas em L2s para impulsionar ainda mais o desempenho.
Outro desafio surge ao aumentar o limite de gás do bloco em L2s para obter maior rendimento, pois isso pode comprometer os mecanismos de prova. Se as provas de fraude exigirem a submissão de blocos inteiros, elas podem entrar em conflito com os próprios limites de tamanho de bloco do Ethereum. A produção de blocos L2 difere da L1, oferecendo oportunidades de otimização e paralelização no sequenciador e cliente de execução, afastando-se dos conceitos tradicionais da L1.
Um desafio significativo é alcançar uma sequenciação compartilhada para aprimorar a interoperabilidade da L2, mantendo a descentralização. No entanto, essa abordagem ainda é inovadora, e os principais acúmulos podem resistir a entregar o controle da sequenciação a terceiros, já que os benefícios do aumento da composabilidade não são claros e o desempenho pode ser comprometido.
O Ethereum usa Merkle-Patricia Tries (MPTs) modificados para gerenciar e verificar seus dados de chave-valor. A EVM não especifica como o estado deve ser armazenado, permitindo que os clientes experimentem soluções diferentes. Atualmente, implementações como LevelDB, PebbleDB e MDBX estão em uso, mas elas não possuem as propriedades inerentes das lojas de chave-valor autenticadas, como provas criptográficas de integridade. Isso aumenta as suposições de confiança, complica as provas de fraude e adiciona sobrecarga à verificação de alterações de estado, afetando a eficiência e a segurança.
Para a maioria dos acúmulos, o desempenho é tipicamente medido por transações em vez de gás. No entanto, antes de analisarmos como os acúmulos gigagas abordam os problemas de escalabilidade, vamos explorar por que o gás, em vez de TPS, é uma métrica mais significativa e por que devemos prestar atenção a isso.
O desempenho em acúmulos e no próprio Ethereum é frequentemente medido por Transações por Segundo (TPS), mas uma métrica mais precisa pode ser 'gás por segundo'. Essa medida indica a capacidade computacional da rede a cada segundo, sendo que 'gás' representa o custo computacional da execução de operações como transações ou contratos inteligentes.
TPS, no entanto, negligencia a complexidade e as demandas de recursos variáveis de diferentes transações e operações, tornando-se um indicador incompleto e muitas vezes enganoso do desempenho da rede. Uma rede pode lidar com mais transações a um custo computacional mais baixo, no entanto, TPS falharia em refletir a verdadeira capacidade do sistema.
Adotar gás por segundo como uma métrica de desempenho padrão fornece uma imagem mais clara e precisa da capacidade e eficiência de um blockchain. Você pode ler um artigo de@paramonowwsobre o porquêTPS é uma métrica boba.
Preocupar-se com as taxas de gás é importante porque isso reflete a quantidade de trabalho que a rede pode lidar, fornecendo uma imagem mais clara de escalabilidade e eficiência. A precificação do gás influencia a economia da rede, afetando as taxas de transação e recompensas, o que, por sua vez, impacta o comportamento do usuário e a segurança da rede. Portanto, enquanto transações por segundo oferecem uma visão geral, o gás por segundo oferece uma compreensão mais profunda das verdadeiras capacidades de desempenho de uma blockchain.
Agora que entendemos o gás, o que são gigagas e os acúmulos de gigagas especificamente?
Gigagas mede a largura de banda em bilhões de unidades de gás por segundo, proporcionando uma medição superior de capacidade em relação ao TPS. Os acúmulos de gigagas são essencialmente acúmulos projetados para gerenciar uma largura de banda de 1 gigaga por segundo, processando 1 bilhão de unidades de gás por segundo. Embora o conceito seja direto, sua implementação é desafiadora. Atualmente, mesmo com sequenciamento centralizado, nenhum acúmulo Ethereum chega perto desse benchmark, com todo o ecossistema gerenciando apenas cerca de 60 Mgas (60 milhões de unidades de gás) por segundo.
Origem:acúmulos.wtf
Os acúmulos da Gigagas aumentariam a capacidade de processamento lidando com transações em gigagas, permitindo volumes de transações vastos ou operações complexas rapidamente. Eles melhorariam a eficiência por meio de inovações na compressão de dados, geração de provas e publicação de dados da cadeia principal, visando mínima sobrecarga e máxima capacidade de processamento.
Várias equipes estão desenvolvendo ativamente acúmulos gigagas. Por exemplo, @Abundance_xyz está construindo uma pilha completa de acúmulos gigagas, enquanto @rise_chainestá focando na construção de acúmulos de gigagas, introduzindo modificações e otimizações extensivas no EVM e além. Vamos analisar como os acúmulos de gigagas funcionam, com ênfase especial no RISE.
RISE é uma plataforma L2 projetada para lidar com os problemas de desempenho de acúmulos do Ethereum. Apesar dos avanços, as soluções L2 atuais não conseguem igualar a velocidade da Solana. RISE utiliza um EVM paralelo, execução contínua e uma nova arquitetura de estado no RethSDK para aumentar a capacidade de processamento. RISE tem como objetivo largura de banda acima de 1 Gigagas por segundo.
A arquitetura da RISE inclui um mecanismo de execução paralelo EVM totalmente de código aberto chamado pevm, que suporta execução contínua através de um pipeline de blocos. Para acesso ao estado, a RISE utiliza Árvores de Merkle Versionadas para otimizar o desempenho e um banco de dados personalizado, RiseDB, adaptado para os estados da cadeia EVM.
A pilha RISE é construída em Reth. Em relação à disponibilidade de dados, a arquitetura requer largura de banda alta e é modular para acomodar várias soluções de disponibilidade de dados. A RISE também utiliza sequenciamento baseado para descentralizar a produção de blocos. Se você não sabe o que são acúmulos baseados, você pode dar uma olhada emo primeiro artigo desta série, que examina seus prós e contras.
Nos cenários típicos da Camada 2, apenas cerca de 8% do tempo de bloco é gasto na execução devido a um processo sequencial envolvendo consenso, execução e merklização. Isso se torna ineficiente, pois o consenso pode levar de 40 a 80% e a merklização até 60% do tempo restante. O Continuous Block Pipeline (CBP) da RISE melhora isso com execução paralela, processamento contínuo de transações e computação simultânea da raiz do estado. Isso permite uma utilização quase 100% do tempo de bloco para a execução de transações, melhorando significativamente a eficiência em relação aos métodos tradicionais.
O Ethereum usa um sistema de estado em duas camadas com uma árvore Merkle Patricia Trie (MPT). O MPT garante a integridade dos dados, mas leva a uma alta amplificação de leitura e gravação devido à sua estrutura e à natureza da árvore LSM (Log-Structured-Merge) do banco de dados. Isso resulta em numerosas operações de E / S para consultas de estado. O MPT emprega nós de extensão para reduzir a redundância, mas os desafios incluem uso ineficiente de SSD, sobrecarga significativa de compactação e subutilização de CPU durante as esperas de E / S.
RISE enfrenta esses problemas usando uma Árvore de Merkle Versionada, que melhora a eficiência de armazenamento com chaves versionadas. Também emprega a abordagem LETUS com codificação delta e arquivos de estrutura de log para reduzir os efeitos de amplificação. Isso resulta em uma melhor gestão de armazenamento e recuperação de dados mais eficiente.
Existem muitas razões pelas quais nem todos os acúmulos se tornarão um acúmulo gigagas. Nem todas as aplicações exigem um desempenho tão alto, e a complexidade e o custo associados à tecnologia gigagas podem não ser justificados para projetos com necessidades de transação mais baixas ou casos de uso mais simples.
Alguns acúmulos priorizam outros aspectos como facilidade de uso, privacidade ou aplicativos específicos do setor em vez de apenas rendimento. Também existe o equilíbrio entre escalabilidade e descentralização, onde alguns preferem manter uma estrutura mais descentralizada em vez de buscar um desempenho gigantesco. A escalabilidade incremental pode ser mais prática, evitando a necessidade de extensas alterações no sistema.
Mover para níveis gigagas pode perturbar integrações existentes ou complicar interações do usuário sem necessidade. A escolha de se tornar um acúmulo de gigagas depende muito de recursos, objetivos estratégicos e posicionamento geral da cadeia.
Os rollups gigagas representam um avanço significativo na jornada de escalabilidade do Ethereum, introduzindo várias melhorias na pilha de rollup. Com esses novos recursos, os rollups gigagas abordam gargalos principais, como execução de thread única, gerenciamento de merkleização e ineficiências de armazenamento de estado que os rollups L2 tradicionais enfrentam atualmente.
No entanto, alcançar um desempenho de gigagas requer uma mudança arquitetônica relativamente complexa e transformadora. Além disso, envolve compensações, como o equilíbrio entre escalabilidade e descentralização. Como resultado, não é necessário que cada rollup no ecossistema seja um rollup de Gigagas.
Além de tudo isso, parece que os acúmulos da gigagas proporcionarão ótimas oportunidades para a comunidade Ethereum demonstrar o verdadeiro poder do Ethereum.
Ao longo desta série de acúmulos, mergulhamos a fundo em diferentes tipos de escalonamento do Ethereum: deacúmulos baseados em Parte Iparaacúmulos de impulso na Parte II,acúmulos nativos na Parte IIIe finalmente gigagas acúmulos nesta parte final. Este artigo encerra nossa exploração dos acúmulos, mas está longe de ser o fim da jornada. Fique ligado para novas séries e artigos detalhados sobre as últimas inovações que moldam o futuro do Ethereum!