Uma vez que o Ethereum seguiu o plano centrado em rollups, toda a comunidade acreditava que os rollups seriam a solução para o problema de escalabilidade do Ethereum. No entanto, até hoje, os rollups ainda são inferiores a algumas L1s de alto desempenho em termos de poder de computação.
Isto é provavelmente devido ao facto de as equipas de rollup terem de lidar não apenas com a execução, mas também com vários sistemas de prova, pontes e outras coisas nos seus esforços para escalar o Ethereum.
Mas temos um tipo de rollup que emergiu para potencializar o poder dos rollups: rollups da Gigagas. Em nossa série anterior, exploramos rollups baseados, rollups impulsionadores e rollups nativos. Neste artigo, iremos examinar os rollups da Gigagas, analisando o que eles estão tentando resolver e como funcionam.
O principal problema de desempenho para L2s centrou-se no problema de DA. No entanto, com os recentes avanços em soluções de DA externas 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 um único segmento, o que significa que utilizam apenas um núcleo da CPU de cada vez, embora 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 requeridas na EVM, gestão de estado e estrutura de transação. Entretanto, pesquisas recentes por @VangelisAndr, mostrou que64.85% das transações Ethereumpode ser paralelizado, imagine quantas transações podem ser paralelizadas nos L2s para impulsionar ainda mais o desempenho.
Outro desafio surge ao aumentar o limite de gás do bloco em L2s para obter maior throughput, pois isso pode comprometer os mecanismos de prova. Se as provas de fraude exigirem a submissão de blocos inteiros, elas poderão conflitar 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 no cliente de execução, afastando-se dos conceitos tradicionais da L1.
Um desafio significativo é alcançar a sequenciação compartilhada para melhorar a interoperabilidade da L2, mantendo a descentralização. No entanto, esta abordagem ainda é nova, e os principais rollups podem resistir a ceder o controle da sequenciação a terceiros, uma vez que os benefícios da maior composição não estão claros e o desempenho pode sofrer.
O Ethereum utiliza árvores Merkle-Patricia modificadas (MPTs) para gerir e verificar os seus dados chave-valor. A EVM não especifica como o estado deve ser armazenado, permitindo assim que os clientes de nós experimentem diferentes soluções. Atualmente, implementações como LevelDB, PebbleDB e MDBX estão em uso, mas carecem das propriedades inerentes de armazenamento de dados chave-valor autenticados, tais 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, impactando a eficiência e a segurança.
Para a maioria dos rollups, o desempenho é tipicamente medido por transações em vez de gás. No entanto, antes de explorarmos como os rollups de gigagas abordam as questões 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 ela.
O desempenho em rollups 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'. Esta medida indica a capacidade computacional da rede a cada segundo, sendo que 'gás' representa o custo computacional de executar operações como transações ou contratos inteligentes.
No entanto, o TPS não considera a complexidade e as diferentes demandas de recursos de diferentes transações e operações, o que o torna um indicador incompleto e muitas vezes enganador do desempenho da rede. Uma rede pode lidar com mais transações a um custo computacional mais baixo, mas o TPS não refletiria 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 o gás é importante porque reflete a quantidade de trabalho que a rede pode lidar, fornecendo uma imagem mais clara da escalabilidade e eficiência. O preç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 as 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 gigagas rollups especificamente?
O Gigagas mede a largura de banda em bilhões de unidades de gás por segundo, fornecendo uma medição superior da capacidade em relação ao TPS. Os rollups de gigagás são essencialmente rollups concebidos para gerir uma largura de banda de 1 gigagás por segundo, processando 1 bilião de unidades de gás por segundo. Embora o conceito seja simples, a sua implementação é um desafio. Atualmente, mesmo com sequenciamento centralizado, nenhum rollup 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.
Fonte:rollup.wtf
Os rollups 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 a sobrecarga mínima e a capacidade máxima de processamento.
Várias equipes estão desenvolvendo ativamente rollups gigagas. Por exemplo, @Abundance_xyzestá criando uma pilha completa de rollups gigagas, enquanto@rise_chainestá focada na construção de gigagas rollup, introduzindo modificações e otimizações extensivas ao EVM e além. Vamos explorar como os gigagas rollups funcionam, com ênfase especial no RISE.
RISE é uma plataforma L2 projetada para lidar com os problemas de desempenho de rollup do Ethereum. Apesar dos avanços, as soluções L2 atuais não podem igualar a velocidade da Solana. RISE usa um EVM paralelo, execução contínua e uma nova arquitetura de estado no RethSDK para aumentar a taxa de transferência. RISE tem como objetivo uma largura de banda superior a 1 Gigagas por segundo.
A arquitetura da RISE inclui um mecanismo de execução paralela da EVM totalmente open source chamado pevm, que suporta execução contínua através de um pipeline de blocos. Para acesso ao estado, a RISE utiliza Árvores Merkle Versionadas para otimizar o desempenho e um banco de dados personalizado, RiseDB, adaptado para estados de cadeias EVM.
A pilha RISE é construída em cima do 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 usa sequenciamento baseado para descentralizar a produção de blocos. Se você não sabe o que são rollups baseados, pode dar uma olhada emo primeiro artigo desta série, que examina seus prós e contras.
Nos setups 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 cálculo simultâneo de estado raiz. Isso permite uma utilização de quase 100% do tempo de bloco para execução de transações, melhorando significativamente a eficiência em relação aos métodos tradicionais.
O Ethereum utiliza um sistema de estado em duas camadas com uma Merkle Patricia Trie (MPT). A MPT garante a integridade dos dados, mas leva a uma amplificação alta de leitura e gravação devido à sua estrutura e à natureza de árvore LSM (Log-Structured-Merge) do banco de dados. Isso resulta em numerosas operações de I/O para consultas de estado. A MPT utiliza nós de extensão para reduzir a redundância, mas os desafios incluem o uso ineficiente de SSD, sobrecarga significativa de compactação e subutilização da CPU durante as esperas de I/O.
O RISE combate esses problemas usando uma Árvore Merkle Versionada, que melhora a eficiência de armazenamento com chaves versionadas. Também utiliza a abordagem LETUS com codificação delta e arquivos log-estruturados para reduzir os efeitos de amplificação. Isso resulta em um melhor gerenciamento de armazenamento e recuperação de dados mais eficiente.
Existem muitas razões pelas quais nem todos os rollups se tornarão um rollup gigagas. Nem todas as aplicações requerem um desempenho tão elevado, 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 rollups priorizam outros aspectos, como facilidade de uso, privacidade ou aplicações específicas do setor, em vez de simplesmente a capacidade. Também existe um equilíbrio entre escalabilidade e descentralização, onde alguns preferem manter uma estrutura mais descentralizada em vez de buscar um desempenho gigagas. A escalabilidade incremental pode ser mais prática, evitando a necessidade de mudanças extensivas no sistema.
Mudar para níveis gigagas pode perturbar integrações existentes ou complicar interações do usuário sem necessidade. A escolha de se tornar um rollup gigagas depende fortemente de recursos, objetivos estratégicos e posicionamento geral da cadeia.
As rollups da Gigagas representam um avanço significativo na jornada de escalabilidade do Ethereum, introduzindo várias melhorias na pilha de rollup. Com esses novos recursos, as rollups da Gigagas abordam gargalos principais, como execução de thread única, gerenciamento de merkleização e ineficiências de armazenamento de estado que as rollups L2 tradicionais enfrentam atualmente.
No entanto, alcançar um desempenho de nível 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 Gigagas.
Além de tudo isso, parece que os rollups da gigagas proporcionarão grandes oportunidades para a comunidade Ethereum demonstrar o verdadeiro poder do Ethereum.
Ao longo desta série de rollups, mergulhamos a fundo em diferentes tipos de escalonamento do Ethereum: desdecom rollups baseados na Parte Iparabooster rollups em Parte II,rollups nativos na Parte III, e finalmente gigagas rollups nesta parte final. Este artigo conclui nossa exploração dos rollups, mas está longe do 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 plano centrado em rollups, toda a comunidade acreditava que os rollups seriam a solução para o problema de escalabilidade do Ethereum. No entanto, até hoje, os rollups ainda são inferiores a algumas L1s de alto desempenho em termos de poder de computação.
Isto é provavelmente devido ao facto de as equipas de rollup terem de lidar não apenas com a execução, mas também com vários sistemas de prova, pontes e outras coisas nos seus esforços para escalar o Ethereum.
Mas temos um tipo de rollup que emergiu para potencializar o poder dos rollups: rollups da Gigagas. Em nossa série anterior, exploramos rollups baseados, rollups impulsionadores e rollups nativos. Neste artigo, iremos examinar os rollups da Gigagas, analisando o que eles estão tentando resolver e como funcionam.
O principal problema de desempenho para L2s centrou-se no problema de DA. No entanto, com os recentes avanços em soluções de DA externas 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 um único segmento, o que significa que utilizam apenas um núcleo da CPU de cada vez, embora 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 requeridas na EVM, gestão de estado e estrutura de transação. Entretanto, pesquisas recentes por @VangelisAndr, mostrou que64.85% das transações Ethereumpode ser paralelizado, imagine quantas transações podem ser paralelizadas nos L2s para impulsionar ainda mais o desempenho.
Outro desafio surge ao aumentar o limite de gás do bloco em L2s para obter maior throughput, pois isso pode comprometer os mecanismos de prova. Se as provas de fraude exigirem a submissão de blocos inteiros, elas poderão conflitar 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 no cliente de execução, afastando-se dos conceitos tradicionais da L1.
Um desafio significativo é alcançar a sequenciação compartilhada para melhorar a interoperabilidade da L2, mantendo a descentralização. No entanto, esta abordagem ainda é nova, e os principais rollups podem resistir a ceder o controle da sequenciação a terceiros, uma vez que os benefícios da maior composição não estão claros e o desempenho pode sofrer.
O Ethereum utiliza árvores Merkle-Patricia modificadas (MPTs) para gerir e verificar os seus dados chave-valor. A EVM não especifica como o estado deve ser armazenado, permitindo assim que os clientes de nós experimentem diferentes soluções. Atualmente, implementações como LevelDB, PebbleDB e MDBX estão em uso, mas carecem das propriedades inerentes de armazenamento de dados chave-valor autenticados, tais 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, impactando a eficiência e a segurança.
Para a maioria dos rollups, o desempenho é tipicamente medido por transações em vez de gás. No entanto, antes de explorarmos como os rollups de gigagas abordam as questões 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 ela.
O desempenho em rollups 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'. Esta medida indica a capacidade computacional da rede a cada segundo, sendo que 'gás' representa o custo computacional de executar operações como transações ou contratos inteligentes.
No entanto, o TPS não considera a complexidade e as diferentes demandas de recursos de diferentes transações e operações, o que o torna um indicador incompleto e muitas vezes enganador do desempenho da rede. Uma rede pode lidar com mais transações a um custo computacional mais baixo, mas o TPS não refletiria 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 o gás é importante porque reflete a quantidade de trabalho que a rede pode lidar, fornecendo uma imagem mais clara da escalabilidade e eficiência. O preç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 as 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 gigagas rollups especificamente?
O Gigagas mede a largura de banda em bilhões de unidades de gás por segundo, fornecendo uma medição superior da capacidade em relação ao TPS. Os rollups de gigagás são essencialmente rollups concebidos para gerir uma largura de banda de 1 gigagás por segundo, processando 1 bilião de unidades de gás por segundo. Embora o conceito seja simples, a sua implementação é um desafio. Atualmente, mesmo com sequenciamento centralizado, nenhum rollup 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.
Fonte:rollup.wtf
Os rollups 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 a sobrecarga mínima e a capacidade máxima de processamento.
Várias equipes estão desenvolvendo ativamente rollups gigagas. Por exemplo, @Abundance_xyzestá criando uma pilha completa de rollups gigagas, enquanto@rise_chainestá focada na construção de gigagas rollup, introduzindo modificações e otimizações extensivas ao EVM e além. Vamos explorar como os gigagas rollups funcionam, com ênfase especial no RISE.
RISE é uma plataforma L2 projetada para lidar com os problemas de desempenho de rollup do Ethereum. Apesar dos avanços, as soluções L2 atuais não podem igualar a velocidade da Solana. RISE usa um EVM paralelo, execução contínua e uma nova arquitetura de estado no RethSDK para aumentar a taxa de transferência. RISE tem como objetivo uma largura de banda superior a 1 Gigagas por segundo.
A arquitetura da RISE inclui um mecanismo de execução paralela da EVM totalmente open source chamado pevm, que suporta execução contínua através de um pipeline de blocos. Para acesso ao estado, a RISE utiliza Árvores Merkle Versionadas para otimizar o desempenho e um banco de dados personalizado, RiseDB, adaptado para estados de cadeias EVM.
A pilha RISE é construída em cima do 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 usa sequenciamento baseado para descentralizar a produção de blocos. Se você não sabe o que são rollups baseados, pode dar uma olhada emo primeiro artigo desta série, que examina seus prós e contras.
Nos setups 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 cálculo simultâneo de estado raiz. Isso permite uma utilização de quase 100% do tempo de bloco para execução de transações, melhorando significativamente a eficiência em relação aos métodos tradicionais.
O Ethereum utiliza um sistema de estado em duas camadas com uma Merkle Patricia Trie (MPT). A MPT garante a integridade dos dados, mas leva a uma amplificação alta de leitura e gravação devido à sua estrutura e à natureza de árvore LSM (Log-Structured-Merge) do banco de dados. Isso resulta em numerosas operações de I/O para consultas de estado. A MPT utiliza nós de extensão para reduzir a redundância, mas os desafios incluem o uso ineficiente de SSD, sobrecarga significativa de compactação e subutilização da CPU durante as esperas de I/O.
O RISE combate esses problemas usando uma Árvore Merkle Versionada, que melhora a eficiência de armazenamento com chaves versionadas. Também utiliza a abordagem LETUS com codificação delta e arquivos log-estruturados para reduzir os efeitos de amplificação. Isso resulta em um melhor gerenciamento de armazenamento e recuperação de dados mais eficiente.
Existem muitas razões pelas quais nem todos os rollups se tornarão um rollup gigagas. Nem todas as aplicações requerem um desempenho tão elevado, 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 rollups priorizam outros aspectos, como facilidade de uso, privacidade ou aplicações específicas do setor, em vez de simplesmente a capacidade. Também existe um equilíbrio entre escalabilidade e descentralização, onde alguns preferem manter uma estrutura mais descentralizada em vez de buscar um desempenho gigagas. A escalabilidade incremental pode ser mais prática, evitando a necessidade de mudanças extensivas no sistema.
Mudar para níveis gigagas pode perturbar integrações existentes ou complicar interações do usuário sem necessidade. A escolha de se tornar um rollup gigagas depende fortemente de recursos, objetivos estratégicos e posicionamento geral da cadeia.
As rollups da Gigagas representam um avanço significativo na jornada de escalabilidade do Ethereum, introduzindo várias melhorias na pilha de rollup. Com esses novos recursos, as rollups da Gigagas abordam gargalos principais, como execução de thread única, gerenciamento de merkleização e ineficiências de armazenamento de estado que as rollups L2 tradicionais enfrentam atualmente.
No entanto, alcançar um desempenho de nível 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 Gigagas.
Além de tudo isso, parece que os rollups da gigagas proporcionarão grandes oportunidades para a comunidade Ethereum demonstrar o verdadeiro poder do Ethereum.
Ao longo desta série de rollups, mergulhamos a fundo em diferentes tipos de escalonamento do Ethereum: desdecom rollups baseados na Parte Iparabooster rollups em Parte II,rollups nativos na Parte III, e finalmente gigagas rollups nesta parte final. Este artigo conclui nossa exploração dos rollups, mas está longe do fim da jornada. Fique ligado para novas séries e artigos detalhados sobre as últimas inovações que moldam o futuro do Ethereum!