O roteiro do Ethereum incluía inicialmente duas estratégias de escalonamento: sharding e protocolos Layer 2. À medida que a pesquisa avançava, esses dois caminhos se fundiram, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalonamento atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o Ethereum L1 foca em se tornar uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é comum na sociedade: a existência do sistema judicial (L1) não é para buscar super velocidade e eficiência, mas para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) devem construir sobre essa camada base sólida, impulsionando o desenvolvimento humano.
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 consideravelmente, e vários Rollups do Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica internas, e a diversidade e pluralidade das formas de implementação de partições tornaram-se uma realidade. Mas, como vimos, seguir por este caminho também apresenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, enquanto mantemos a robustez e a descentralização que são características do Ethereum L1.
The Surge: Objetivos chave
O Ethereum no futuro poderá alcançar mais de 100.000 TPS através de L2;
Manter a descentralização e robustez do L1;
Pelo menos algumas L2 herdaram completamente as propriedades centrais do Ethereum ( de não confiar, serem abertas e resistentes à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Este capítulo
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
Melhoria da interoperabilidade entre L2
Expandir a execução na L1
Paradoxo da Tríade da Escalabilidade
O triângulo da escalabilidade é uma ideia proposta em 2017, que afirma que há uma contradição entre três características da blockchain: a descentralização (, mais especificamente: o baixo custo de operação dos nós ), a escalabilidade (, que lida com o grande número de transações ), e a segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para fazer uma única transação falhar ).
É importante notar que a paradoxo triangular não é um teorema, e os posts que introduzem a paradoxo triangular não incluem uma prova matemática. Ele realmente apresenta um argumento matemático heurístico: se um nó amigável e descentralizado (, por exemplo, um laptop de consumo ) 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) seu nó se tornará poderoso, enquanto sua cadeia não se descentraliza. O objetivo deste artigo nunca foi provar que quebrar a paradoxo triangular é impossível; ao contrário, ele visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair do quadro de pensamento implícito no argumento.
Ao longo dos anos, algumas blockchains de alto desempenho têm afirmado que resolveram o triângulo das bermudas sem alterar fundamentalmente a arquitetura, geralmente otimizando os nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas blockchains é muito mais difícil do que executar nós no Ethereum. Este artigo irá 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 a paradoxo triangular: 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, mesmo baixando apenas uma pequena quantidade de dados e realizando um número muito limitado de cálculos. Os 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 de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceitos pela rede.
Outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza uma tecnologia engenhosa para transferir a responsabilidade de monitorar a disponibilidade de dados de forma compatível com incentivos para os usuários. Já em 2017-2019, quando só tínhamos a prova de fraude como meio de expandir a capacidade computacional, o Plasma era muito limitado na execução segura, mas com a popularização dos SNARKs(, provas zero-knowledge concisas e não interativas), a arquitetura Plasma tornou-se mais viável para um conjunto de cenários de uso mais amplo do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
Em 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de cerca de 125 kB a cada 12 segundos de slot, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados das transações sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS do Rollup no Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum (: 30 milhões de Gas por slot / 16 gas por byte = 1.875.000 bytes por slot ), isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará de 463 a 926 TPS para o calldata.
Esta é uma grande melhoria para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, e se combinarmos com melhorias na compressão de dados Rollup, isso resultará em ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 no 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 com base nos parâmetros propostos: qualquer 64 de 128 amostras possíveis ( pode recuperar o blob.
O funcionamento do PeerDAS é fazer com que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob e solicita, perguntando a pares na rede p2p global quem vai escutar diferentes sub-redes ), os blobs que precisa de outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem perguntas adicionais à camada de pares. A proposta atual é que os nós participantes da prova de participação utilizem o SubnetDAS, enquanto os outros nós (, ou clientes ), utilizem o PeerDAS.
Em teoria, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256( com um objetivo de 128), então podemos atingir a meta de 16MB, enquanto a amostragem de disponibilidade de dados em cada nó tem 16 amostras * 128 blobs * 512 bytes por amostra de cada blob = 1 MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite de tolerância: é viável, mas isso 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 aumentaria os custos de reconstrução.
Portanto, queremos ir mais longe e realizar uma amostragem 2D (2D sampling). Este método não apenas realiza amostragem aleatória dentro do blob, mas também entre blobs. Utilizando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco com um novo conjunto de blobs virtuais, que codificam redundantemente a mesma informação.
Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não só ocorre dentro do blob, mas também entre os blobs de forma aleatória. A propriedade linear do compromisso KZG é utilizada para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais que codificam redundantemente as mesmas informações.
É crucial que a extensão do compromisso de cálculo não exija blobs, portanto, esta abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas ter o compromisso KZG dos blobs e podem confiar na amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade dos blocos 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 concessõ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 atentamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalho acadêmico para regular o PeerDAS e outras versões do DAS e sua interação com questões de segurança, como as regras de escolha de fork.
Num estágio mais distante 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 conseguir mudar do KZG para uma alternativa que seja segura contra quântica e que não exija uma configuração confiável. No momento, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo ao usar técnicas "brutais" e caras, ou seja, usando STARKs recursivos 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.
O caminho de realidade de longo prazo que eu vejo é:
Implementar o DAS 2D ideal;
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.
Desistir do DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer2 de interesse.
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 lidar com uma grande quantidade de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup), como ZK-EVM e DAS).
( Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a necessidade de DAS 2D será reduzida ou pelo menos adiada, e 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 para a reconstrução distribuída, na prática isso precisa ser combinado com a proposta de lista de inclusão de pacotes e os mecanismos de escolha de fork ao seu redor.
![Vitalik nova publicação: Ethereum possível futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compressão de Dados
) Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudéssemos resolver não apenas os problemas do numerador, mas também os problemas do denominador, permitindo 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:
Na compressão de zeros, substituímos cada sequência longa de zeros por dois bytes, indicando quantos zeros existem. Além disso, aproveitamos propriedades específicas das transações:
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.
11 Curtidas
Recompensa
11
3
Repostar
Compartilhar
Comentário
0/400
RuntimeError
· 07-14 20:38
Bom trabalho eth
Ver originalResponder0
ChainMelonWatcher
· 07-14 20:34
Está a correr bastante bem~
Ver originalResponder0
DegenWhisperer
· 07-14 20:27
Aqui estamos a brincar com a estrutura em camadas, e está muito bem falado.
Ethereum The Surge: Do 100.000 TPS ao caminho da escalabilidade para um ecossistema unificado
O futuro do Ethereum: The Surge
O roteiro do Ethereum incluía inicialmente duas estratégias de escalonamento: sharding e protocolos Layer 2. À medida que a pesquisa avançava, esses dois caminhos se fundiram, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalonamento atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o Ethereum L1 foca em se tornar uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é comum na sociedade: a existência do sistema judicial (L1) não é para buscar super velocidade e eficiência, mas para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) devem construir sobre essa camada base sólida, impulsionando o desenvolvimento humano.
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 consideravelmente, e vários Rollups do Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica internas, e a diversidade e pluralidade das formas de implementação de partições tornaram-se uma realidade. Mas, como vimos, seguir por este caminho também apresenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, enquanto mantemos a robustez e a descentralização que são características do Ethereum L1.
The Surge: Objetivos chave
O Ethereum no futuro poderá alcançar mais de 100.000 TPS através de L2;
Manter a descentralização e robustez do L1;
Pelo menos algumas L2 herdaram completamente as propriedades centrais do Ethereum ( de não confiar, serem abertas e resistentes à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Este capítulo
Paradoxo da Tríade da Escalabilidade
O triângulo da escalabilidade é uma ideia proposta em 2017, que afirma que há uma contradição entre três características da blockchain: a descentralização (, mais especificamente: o baixo custo de operação dos nós ), a escalabilidade (, que lida com o grande número de transações ), e a segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para fazer uma única transação falhar ).
É importante notar que a paradoxo triangular não é um teorema, e os posts que introduzem a paradoxo triangular não incluem uma prova matemática. Ele realmente apresenta um argumento matemático heurístico: se um nó amigável e descentralizado (, por exemplo, um laptop de consumo ) 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) seu nó se tornará poderoso, enquanto sua cadeia não se descentraliza. O objetivo deste artigo nunca foi provar que quebrar a paradoxo triangular é impossível; ao contrário, ele visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair do quadro de pensamento implícito no argumento.
Ao longo dos anos, algumas blockchains de alto desempenho têm afirmado que resolveram o triângulo das bermudas sem alterar fundamentalmente a arquitetura, geralmente otimizando os nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas blockchains é muito mais difícil do que executar nós no Ethereum. Este artigo irá 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 a paradoxo triangular: 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, mesmo baixando apenas uma pequena quantidade de dados e realizando um número muito limitado de cálculos. Os 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 de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceitos pela rede.
Outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza uma tecnologia engenhosa para transferir a responsabilidade de monitorar a disponibilidade de dados de forma compatível com incentivos para os usuários. Já em 2017-2019, quando só tínhamos a prova de fraude como meio de expandir a capacidade computacional, o Plasma era muito limitado na execução segura, mas com a popularização dos SNARKs(, provas zero-knowledge concisas e não interativas), a arquitetura Plasma tornou-se mais viável para um conjunto de cenários de uso mais amplo do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
Em 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de cerca de 125 kB a cada 12 segundos de slot, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados das transações sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS do Rollup no Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum (: 30 milhões de Gas por slot / 16 gas por byte = 1.875.000 bytes por slot ), isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará de 463 a 926 TPS para o calldata.
Esta é uma grande melhoria para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, e se combinarmos com melhorias na compressão de dados Rollup, isso resultará em ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 no 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 com base nos parâmetros propostos: qualquer 64 de 128 amostras possíveis ( pode recuperar o blob.
O funcionamento do PeerDAS é fazer com que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob e solicita, perguntando a pares na rede p2p global quem vai escutar diferentes sub-redes ), os blobs que precisa de outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem perguntas adicionais à camada de pares. A proposta atual é que os nós participantes da prova de participação utilizem o SubnetDAS, enquanto os outros nós (, ou clientes ), utilizem o PeerDAS.
Em teoria, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256( com um objetivo de 128), então podemos atingir a meta de 16MB, enquanto a amostragem de disponibilidade de dados em cada nó tem 16 amostras * 128 blobs * 512 bytes por amostra de cada blob = 1 MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite de tolerância: é viável, mas isso 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 aumentaria os custos de reconstrução.
Portanto, queremos ir mais longe e realizar uma amostragem 2D (2D sampling). Este método não apenas realiza amostragem aleatória dentro do blob, mas também entre blobs. Utilizando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco com um novo conjunto de blobs virtuais, que codificam redundantemente a mesma informação.
Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não só ocorre dentro do blob, mas também entre os blobs de forma aleatória. A propriedade linear do compromisso KZG é utilizada para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais que codificam redundantemente as mesmas informações.
É crucial que a extensão do compromisso de cálculo não exija blobs, portanto, esta abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas ter o compromisso KZG dos blobs e podem confiar na amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade dos blocos 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 concessõ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 atentamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalho acadêmico para regular o PeerDAS e outras versões do DAS e sua interação com questões de segurança, como as regras de escolha de fork.
Num estágio mais distante 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 conseguir mudar do KZG para uma alternativa que seja segura contra quântica e que não exija uma configuração confiável. No momento, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo ao usar técnicas "brutais" e caras, ou seja, usando STARKs recursivos 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.
O caminho de realidade de longo prazo que eu vejo é:
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 lidar com uma grande quantidade de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup), como ZK-EVM e DAS).
( Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a necessidade de DAS 2D será reduzida ou pelo menos adiada, e 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 para a reconstrução distribuída, na prática isso precisa ser combinado com a proposta de lista de inclusão de pacotes e os mecanismos de escolha de fork ao seu redor.
![Vitalik nova publicação: Ethereum possível futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compressão de Dados
) Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudéssemos resolver não apenas os problemas do numerador, mas também os problemas do denominador, permitindo 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:
Na compressão de zeros, substituímos cada sequência longa de zeros por dois bytes, indicando quantos zeros existem. Além disso, aproveitamos propriedades específicas das transações:
Agregação de Assinaturas: Nós de