Novo artigo de Vitalik: O futuro possível do Ethereum, The Surge
No roteiro do Ethereum, inicialmente havia duas estratégias de escalabilidade: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma pequena parte das transações, enquanto os protocolos Layer 2 mantêm a maior parte dos dados e cálculos fora da blockchain principal. Essas duas abordagens acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propõe uma divisão simples de trabalho: o Ethereum L1 se concentra 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 perseguir 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, conduzindo a humanidade em direção 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ários Rollups da Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como "fragmentos" com suas próprias regras e lógicas internas, e a diversidade e a pluralidade na implementação dos fragmentos tornaram-se agora uma realidade. Mas, como vimos, seguir este caminho também enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é concluir o roteiro centrado em Rollup e resolver esses problemas, mantendo ao mesmo tempo a robustez e a descentralização que são características do Ethereum L1.
The Surge: Objetivos Chave
No futuro, o Ethereum poderá alcançar mais de 100.000 TPS através do L2.
Manter a descentralização e robustez do L1;
Pelo menos alguns L2 herdaram completamente as propriedades centrais do Ethereum, como a confiança, a abertura e a resistência à censura (;
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste 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
Melhorias na interoperabilidade entre L2
Expandir a execução no L1
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade é uma ideia proposta em 2017, que sugere 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 ) número elevado de transações processadas ( e segurança ) os atacantes precisam comprometer uma grande parte dos nós na rede para falhar em uma única transação (.
É importante notar que o paradoxo triangular não é um teorema, e os posts que introduzem o paradoxo triangular também não incluem prova matemática. Ele realmente apresenta um argumento matemático heurístico: se um nó amigável à descentralização ), por exemplo, um laptop de consumo (, pode verificar 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 será descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; em vez disso, ele visa mostrar que quebrar o paradoxo ternário é difícil, e requer, de certa forma, sair do quadro de pensamento implícito que o argumento sugere.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam que resolveram o triângulo das bermudas sem mudar fundamentalmente a arquitetura, geralmente aplicando técnicas de engenharia de software para otimizar os nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós em Ethereum. Este artigo irá explorar por que isso acontece e por que apenas a engenharia de software do cliente L1 não é suficiente para escalar 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 uma certa quantidade de dados como disponíveis, e que uma certa quantidade de etapas de cálculo foram executadas corretamente, com apenas o download de uma pequena quantidade de dados e a execução de um número mínimo 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 básicas de uma cadeia que não pode ser escalonada, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceites pela rede.
Uma outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza uma tecnologia inteligente para transferir a responsabilidade pela disponibilidade dos dados monitorados para os usuários de uma maneira compatível com incentivos. Desde 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade de computação, o Plasma tinha limitações significativas na 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 um leque mais amplo de cenários de uso do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
) Que problemas 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 aproximadamente 125 kB a cada 12 segundos, ou uma largura de banda de dados disponível de cerca de 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 TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor teórico máximo do calldata do Ethereum ###: cada slot 30 milhões de Gas / cada byte 16 gas = cada slot 1.875.000 bytes (, isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, o que, combinado com melhorias na compressão de dados Rollup, trará ~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 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 de 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 atualmente: qualquer 64 de 128 amostras possíveis ).
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo sample de qualquer blob e solicita aos pares na rede p2p global ( quem irá escutar diferentes sub-redes ) para obter os blobs que precisa nas outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam na prova de participação usem o SubnetDAS, enquanto outros nós (, ou seja, clientes ), usem o PeerDAS.
Teoricamente, 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 o objetivo de 16 MB, enquanto cada nó de amostragem de disponibilidade de dados tem 16 amostras * 128 blobs * 512 bytes por amostra por blob = 1 MB de largura de banda de dados por slot. Isso está apenas marginalmente 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 aumentará o custo de reconstrução.
Portanto, queremos avançar ainda mais e realizar a amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Utilizando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um novo conjunto de blobs virtuais, que codificam redundantemente a mesma informação.
Assim, no final, queremos ir ainda mais longe, realizando 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 proposta é 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) é essencialmente também 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. Em seguida, o número de blobs no PeerDAS será continuamente aumentado, enquanto se observa a rede de perto e se melhora o software para garantir a segurança, sendo este um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e outras versões do DAS, bem como as interações com questões de segurança, como as regras de escolha de forks.
Em estágios futuros mais distantes, precisaremos 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 que seja segura contra quântica e não exija configuração confiável. Atualmente, ainda não está claro quais opções candidatas são amigáveis para a construção de blocos distribuídos. Mesmo usando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, porque, 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 DAS 2D ideal;
Persistir no uso do 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 completamente o Plasma como a principal arquitetura Layer2 em que estamos focados.
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso porque, se a camada L1 tiver que lidar com um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter uma maneira eficiente de 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 demanda por DAS 2D diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS teoricamente seja amigável à 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 bifurcações ao seu redor.
Compressão de Dados
) Que problema estamos resolvendo?
Cada transação no Rollup ocupa uma grande quantidade de espaço de dados on-chain: 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 tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudermos resolver não só o problema do numerador, mas também o problema do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
( O que é, 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])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
Na compressão de zeros, substituímos cada sequência longa de zeros por dois bytes, indicando quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de assinaturas: mudamos de assinaturas ECDSA para assinaturas BLS, a característica das assinaturas BLS é que há várias assinaturas.
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.
9 Curtidas
Recompensa
9
5
Repostar
Compartilhar
Comentário
0/400
FortuneTeller42
· 08-09 22:34
O Vitalik está a fazer promessas vazias novamente.
Ver originalResponder0
MevHunter
· 08-09 22:30
O V está a fazer promessas vazias outra vez.
Ver originalResponder0
0xSoulless
· 08-09 22:27
idiotas são idiotas, fazem as pessoas de parvas e continuam a fazê-lo.
Ver originalResponder0
SandwichTrader
· 08-09 22:21
Ethereum realmente tem potencial, eh
Ver originalResponder0
AllInAlice
· 08-09 22:15
Ninguém consegue distinguir o L2, certo? Estou cansado.
Vitalik analisa o roteiro de escalabilidade do Ethereum: Os objetivos e desafios do plano The Surge
Novo artigo de Vitalik: O futuro possível do Ethereum, The Surge
No roteiro do Ethereum, inicialmente havia duas estratégias de escalabilidade: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma pequena parte das transações, enquanto os protocolos Layer 2 mantêm a maior parte dos dados e cálculos fora da blockchain principal. Essas duas abordagens acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propõe uma divisão simples de trabalho: o Ethereum L1 se concentra 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 perseguir 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, conduzindo a humanidade em direção 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ários Rollups da Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como "fragmentos" com suas próprias regras e lógicas internas, e a diversidade e a pluralidade na implementação dos fragmentos tornaram-se agora uma realidade. Mas, como vimos, seguir este caminho também enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é concluir o roteiro centrado em Rollup e resolver esses problemas, mantendo ao mesmo tempo a robustez e a descentralização que são características do Ethereum L1.
The Surge: Objetivos Chave
No futuro, o Ethereum poderá alcançar mais de 100.000 TPS através do L2.
Manter a descentralização e robustez do L1;
Pelo menos alguns L2 herdaram completamente as propriedades centrais do Ethereum, como a confiança, a abertura e a resistência à censura (;
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste capítulo
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade é uma ideia proposta em 2017, que sugere 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 ) número elevado de transações processadas ( e segurança ) os atacantes precisam comprometer uma grande parte dos nós na rede para falhar em uma única transação (.
É importante notar que o paradoxo triangular não é um teorema, e os posts que introduzem o paradoxo triangular também não incluem prova matemática. Ele realmente apresenta um argumento matemático heurístico: se um nó amigável à descentralização ), por exemplo, um laptop de consumo (, pode verificar 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 será descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; em vez disso, ele visa mostrar que quebrar o paradoxo ternário é difícil, e requer, de certa forma, sair do quadro de pensamento implícito que o argumento sugere.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam que resolveram o triângulo das bermudas sem mudar fundamentalmente a arquitetura, geralmente aplicando técnicas de engenharia de software para otimizar os nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós em Ethereum. Este artigo irá explorar por que isso acontece e por que apenas a engenharia de software do cliente L1 não é suficiente para escalar 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 uma certa quantidade de dados como disponíveis, e que uma certa quantidade de etapas de cálculo foram executadas corretamente, com apenas o download de uma pequena quantidade de dados e a execução de um número mínimo 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 básicas de uma cadeia que não pode ser escalonada, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceites pela rede.
Uma outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza uma tecnologia inteligente para transferir a responsabilidade pela disponibilidade dos dados monitorados para os usuários de uma maneira compatível com incentivos. Desde 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade de computação, o Plasma tinha limitações significativas na 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 um leque mais amplo de cenários de uso do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
) Que problemas 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 aproximadamente 125 kB a cada 12 segundos, ou uma largura de banda de dados disponível de cerca de 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 TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor teórico máximo do calldata do Ethereum ###: cada slot 30 milhões de Gas / cada byte 16 gas = cada slot 1.875.000 bytes (, isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, o que, combinado com melhorias na compressão de dados Rollup, trará ~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 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 de 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 atualmente: qualquer 64 de 128 amostras possíveis ).
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo sample de qualquer blob e solicita aos pares na rede p2p global ( quem irá escutar diferentes sub-redes ) para obter os blobs que precisa nas outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam na prova de participação usem o SubnetDAS, enquanto outros nós (, ou seja, clientes ), usem o PeerDAS.
Teoricamente, 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 o objetivo de 16 MB, enquanto cada nó de amostragem de disponibilidade de dados tem 16 amostras * 128 blobs * 512 bytes por amostra por blob = 1 MB de largura de banda de dados por slot. Isso está apenas marginalmente 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 aumentará o custo de reconstrução.
Portanto, queremos avançar ainda mais e realizar a amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Utilizando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um novo conjunto de blobs virtuais, que codificam redundantemente a mesma informação.
Assim, no final, queremos ir ainda mais longe, realizando 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 proposta é 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) é essencialmente também 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. Em seguida, o número de blobs no PeerDAS será continuamente aumentado, enquanto se observa a rede de perto e se melhora o software para garantir a segurança, sendo este um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e outras versões do DAS, bem como as interações com questões de segurança, como as regras de escolha de forks.
Em estágios futuros mais distantes, precisaremos 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 que seja segura contra quântica e não exija configuração confiável. Atualmente, ainda não está claro quais opções candidatas são amigáveis para a construção de blocos distribuídos. Mesmo usando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, porque, 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 porque, se a camada L1 tiver que lidar com um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter uma maneira eficiente de 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 demanda por DAS 2D diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS teoricamente seja amigável à 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 bifurcações ao seu redor.
Compressão de Dados
) Que problema estamos resolvendo?
Cada transação no Rollup ocupa uma grande quantidade de espaço de dados on-chain: 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 tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudermos resolver não só o problema do numerador, mas também o problema do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
( O que é, 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])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
Na compressão de zeros, substituímos cada sequência longa de zeros por dois bytes, indicando quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de assinaturas: mudamos de assinaturas ECDSA para assinaturas BLS, a característica das assinaturas BLS é que há várias assinaturas.