O roteiro do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer 2. Esses dois caminhos acabaram se fundindo, formando um roteiro centrado em Rollup, que continua a ser a estratégia de escalabilidade atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o L1 do Ethereum foca em se tornar uma camada base forte e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é onipresente na sociedade: a existência do sistema judicial (L1) não é para buscar super velocidade e eficiência, mas sim para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) devem construir sobre essa camada base sólida, levando a humanidade a Marte.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e várias máquinas virtuais Ethereum (EVM)Rollup entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógicas internas, e a diversidade e a pluralidade nas formas de implementação dos fragmentos tornaram-se uma realidade. Mas, como vimos, seguir esse caminho também enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, mantendo ao mesmo tempo a robustez e a descentralização características do Ethereum L1.
The Surge: Objetivos-chave
O futuro do Ethereum através do L2 pode alcançar mais de 100 mil TPS;
Manter a descentralização e robustez do L1;
Pelo menos alguns L2 herdaram completamente as propriedades centrais do Ethereum (, como confiança, abertura e resistência à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste capítulo
O paradoxo do triângulo da escalabilidade
Avanços adicionais na amostragem de disponibilidade de dados
Compressão de dados
Plasma Generalizado
Sistema de prova L2 maduro
Melhorias na interoperabilidade entre L2
Expandir a execução na L1
Paradoxo da Triângulo de Escalabilidade
O triângulo da escalabilidade é uma ideia proposta em 2017, que argumenta que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: baixo custo de operação dos nós ), escalabilidade (, quantidade de transações processadas ) e segurança (, onde um atacante precisa comprometer uma grande parte dos nós na rede para falhar em uma única transação ).
É importante notar que a paradoxo triangular não é um teorema, e as postagens que introduzem o paradoxo triangular não acompanham prova matemática. Ele realmente oferece um argumento matemático heurístico: se um nó amigável e descentralizado (, por exemplo, um laptop comum ) pode validar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza. O objetivo deste artigo não é provar que quebrar o paradoxo triangular é impossível; em vez disso, visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam que resolveram o trilema sem mudar fundamentalmente a arquitetura, geralmente otimizando nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois rodar nós nessas cadeias é muito mais difícil do que rodar nós no Ethereum. Este artigo explorará por que isso acontece e por que a engenharia de software do cliente L1 por si só não pode escalar o Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo do triângulo: permite que os clientes verifiquem que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, com apenas o download de uma pequena quantidade de dados e a execução de muito poucos cálculos. SNARKs são sem confiança. A amostragem de disponibilidade de dados possui um sutil modelo de confiança few-of-N, mas mantém as características fundamentais que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade de monitorar a disponibilidade de dados para os usuários de uma maneira compatível com incentivos. Já em 2017-2019, quando só tínhamos a prova de fraude como meio para expandir a capacidade computacional, o Plasma tinha limitações significativas em termos de execução segura, mas com a popularização dos SNARKs( e das provas de conhecimento zero concisas e não interativas), a arquitetura Plasma tornou-se mais viável para uma gama mais ampla de cenários de uso do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Estamos a resolver que problema?
No dia 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de aproximadamente 125 kB a cada slot de 12 segundos, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS do Rollup em Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum (: cada slot 30 milhões de Gas / por byte 16 gas = cada slot 1.875.000 bytes ), isso se torna 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma grande melhoria para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, que, se combinado com melhorias na compressão de dados Rollup, trará ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 sobre o campo primo de 253 bits (. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação em 16 coordenadas adjacentes de um total de 8192 coordenadas. Desses 8192 valores de avaliação, qualquer 4096 ) pode ser recuperado de acordo com os parâmetros propostos atualmente: qualquer 64 de 128 amostras possíveis (.
![Vitalik nova artigo: O futuro possível do Ethereum, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob, e solicita aos pares na rede p2p global quem irá escutar diferentes sub-redes ) para pedir os blobs de que precisa nas outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam da prova de participação usem o SubnetDAS, enquanto outros nós (, ou seja, clientes ), usem o PeerDAS.
Em teoria, podemos escalar uma "amostragem 1D" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256(, com uma meta de 128), podemos alcançar a meta de 16MB, onde em cada nó de amostragem de disponibilidade de dados temos 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite de tolerância: é viável, mas significa que clientes com largura de banda limitada não podem amostrar. Podemos otimizar isso até certo ponto, reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentará os custos de reconstrução.
Assim, queremos avançar ainda mais, realizando 2D sampling(, este método não apenas realiza amostragem aleatória dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco por meio de um novo conjunto de blobs virtuais, que codificam redundantemente as mesmas informações.
Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não apenas amostra aleatoriamente dentro do blob, mas também entre os blobs. A propriedade linear do compromisso KZG é usada para expandir o conjunto de blobs em um bloco, que contém uma nova lista de blobs virtuais com codificação redundante das mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija um blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos só precisam ter o compromisso KZG do blob, e podem confiar na amostragem de disponibilidade de dados )DAS( para verificar a disponibilidade do bloco de dados. A amostragem de disponibilidade de dados unidimensional )1D DAS( também é essencialmente amigável à construção de blocos distribuídos.
) O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos mais trabalhos acadêmicos para normalizar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de seleção de forks.
Em fases mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente poder mudar do KZG para uma alternativa quântica segura e sem configuração confiável. Atualmente, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando técnicas "brutas" caras, ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log)n( * log)log###n(( hash ) usando STIR(, na prática o STARK é quase do tamanho de todo o blob.
Eu acho que o caminho de realidade a longo prazo é:
Implementar o ideal DAS 2D;
Manter o uso de 1D DAS, sacrificando a eficiência da largura de banda de amostragem, aceitando um limite de dados mais baixo em prol da simplicidade e robustez.
Abandonar DA e aceitar totalmente o Plasma como nossa principal arquitetura Layer2.
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso ocorre porque, se a camada L1 tiver que processar um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que Rollup(, como ZK-EVM e DAS).
) Como interagir com as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS será reduzida, ou pelo menos adiada; se o Plasma for amplamente utilizado, a demanda será ainda mais reduzida. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável à reconstrução distribuída, na prática isso precisa ser combinado com propostas de listas de inclusão de pacotes e os mecanismos de escolha de bifurcações ao seu redor.
Compressão de Dados
( Que problema estamos a resolver?
Cada transação no Rollup ocupa uma grande quantidade de espaço de dados na cadeia: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos não apenas resolver o problema do numerador, mas também resolver o problema do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
O que é isso, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
![Vitalik novo artigo: o futuro possível do Ethereum, The Surge])
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
12 Curtidas
Recompensa
12
6
Compartilhar
Comentário
0/400
DeFiVeteran
· 08-03 08:54
L2赛道 entrou em empreender um grande esforço.
Ver originalResponder0
SquidTeacher
· 08-02 08:18
Ainda há muito trabalho no L2...
Ver originalResponder0
DevChive
· 08-02 08:12
Não consegui aproveitar a promoção, comprei para prolongar a vida.
Ver originalResponder0
GraphGuru
· 08-02 08:06
L2 ecossistema Até à lua, BTC ainda está a cair
Ver originalResponder0
ZKProofEnthusiast
· 08-02 08:00
gás vai subir
Ver originalResponder0
MidsommarWallet
· 08-02 07:57
L2 ainda tem que trabalhar para L1, não importa o quão grande seja.
Ethereum The Surge: 100 mil TPS, L2 herdando propriedades centrais, visão de um ecossistema unificado
O futuro do Ethereum: The Surge
O roteiro do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer 2. Esses dois caminhos acabaram se fundindo, formando um roteiro centrado em Rollup, que continua a ser a estratégia de escalabilidade atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o L1 do Ethereum foca em se tornar uma camada base forte e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é onipresente na sociedade: a existência do sistema judicial (L1) não é para buscar super velocidade e eficiência, mas sim para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) devem construir sobre essa camada base sólida, levando a humanidade a Marte.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e várias máquinas virtuais Ethereum (EVM)Rollup entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógicas internas, e a diversidade e a pluralidade nas formas de implementação dos fragmentos tornaram-se uma realidade. Mas, como vimos, seguir esse caminho também enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, mantendo ao mesmo tempo a robustez e a descentralização características do Ethereum L1.
The Surge: Objetivos-chave
O futuro do Ethereum através do L2 pode alcançar mais de 100 mil TPS;
Manter a descentralização e robustez do L1;
Pelo menos alguns L2 herdaram completamente as propriedades centrais do Ethereum (, como confiança, abertura e resistência à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste capítulo
Paradoxo da Triângulo de Escalabilidade
O triângulo da escalabilidade é uma ideia proposta em 2017, que argumenta que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: baixo custo de operação dos nós ), escalabilidade (, quantidade de transações processadas ) e segurança (, onde um atacante precisa comprometer uma grande parte dos nós na rede para falhar em uma única transação ).
É importante notar que a paradoxo triangular não é um teorema, e as postagens que introduzem o paradoxo triangular não acompanham prova matemática. Ele realmente oferece um argumento matemático heurístico: se um nó amigável e descentralizado (, por exemplo, um laptop comum ) pode validar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza. O objetivo deste artigo não é provar que quebrar o paradoxo triangular é impossível; em vez disso, visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam que resolveram o trilema sem mudar fundamentalmente a arquitetura, geralmente otimizando nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois rodar nós nessas cadeias é muito mais difícil do que rodar nós no Ethereum. Este artigo explorará por que isso acontece e por que a engenharia de software do cliente L1 por si só não pode escalar o Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo do triângulo: permite que os clientes verifiquem que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, com apenas o download de uma pequena quantidade de dados e a execução de muito poucos cálculos. SNARKs são sem confiança. A amostragem de disponibilidade de dados possui um sutil modelo de confiança few-of-N, mas mantém as características fundamentais que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade de monitorar a disponibilidade de dados para os usuários de uma maneira compatível com incentivos. Já em 2017-2019, quando só tínhamos a prova de fraude como meio para expandir a capacidade computacional, o Plasma tinha limitações significativas em termos de execução segura, mas com a popularização dos SNARKs( e das provas de conhecimento zero concisas e não interativas), a arquitetura Plasma tornou-se mais viável para uma gama mais ampla de cenários de uso do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Estamos a resolver que problema?
No dia 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de aproximadamente 125 kB a cada slot de 12 segundos, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS do Rollup em Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum (: cada slot 30 milhões de Gas / por byte 16 gas = cada slot 1.875.000 bytes ), isso se torna 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma grande melhoria para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, que, se combinado com melhorias na compressão de dados Rollup, trará ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 sobre o campo primo de 253 bits (. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação em 16 coordenadas adjacentes de um total de 8192 coordenadas. Desses 8192 valores de avaliação, qualquer 4096 ) pode ser recuperado de acordo com os parâmetros propostos atualmente: qualquer 64 de 128 amostras possíveis (.
![Vitalik nova artigo: O futuro possível do Ethereum, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob, e solicita aos pares na rede p2p global quem irá escutar diferentes sub-redes ) para pedir os blobs de que precisa nas outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam da prova de participação usem o SubnetDAS, enquanto outros nós (, ou seja, clientes ), usem o PeerDAS.
Em teoria, podemos escalar uma "amostragem 1D" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256(, com uma meta de 128), podemos alcançar a meta de 16MB, onde em cada nó de amostragem de disponibilidade de dados temos 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite de tolerância: é viável, mas significa que clientes com largura de banda limitada não podem amostrar. Podemos otimizar isso até certo ponto, reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentará os custos de reconstrução.
Assim, queremos avançar ainda mais, realizando 2D sampling(, este método não apenas realiza amostragem aleatória dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco por meio de um novo conjunto de blobs virtuais, que codificam redundantemente as mesmas informações.
Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não apenas amostra aleatoriamente dentro do blob, mas também entre os blobs. A propriedade linear do compromisso KZG é usada para expandir o conjunto de blobs em um bloco, que contém uma nova lista de blobs virtuais com codificação redundante das mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija um blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos só precisam ter o compromisso KZG do blob, e podem confiar na amostragem de disponibilidade de dados )DAS( para verificar a disponibilidade do bloco de dados. A amostragem de disponibilidade de dados unidimensional )1D DAS( também é essencialmente amigável à construção de blocos distribuídos.
) O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos mais trabalhos acadêmicos para normalizar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de seleção de forks.
Em fases mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente poder mudar do KZG para uma alternativa quântica segura e sem configuração confiável. Atualmente, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando técnicas "brutas" caras, ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log)n( * log)log###n(( hash ) usando STIR(, na prática o STARK é quase do tamanho de todo o blob.
Eu acho que o caminho de realidade a longo prazo é:
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso ocorre porque, se a camada L1 tiver que processar um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que Rollup(, como ZK-EVM e DAS).
) Como interagir com as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS será reduzida, ou pelo menos adiada; se o Plasma for amplamente utilizado, a demanda será ainda mais reduzida. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável à reconstrução distribuída, na prática isso precisa ser combinado com propostas de listas de inclusão de pacotes e os mecanismos de escolha de bifurcações ao seu redor.
Compressão de Dados
( Que problema estamos a resolver?
Cada transação no Rollup ocupa uma grande quantidade de espaço de dados na cadeia: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos não apenas resolver o problema do numerador, mas também resolver o problema do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
O que é isso, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
![Vitalik novo artigo: o futuro possível do Ethereum, The Surge])