Novo artigo de Vitalik: O futuro potencial do Ethereum, The Surge
O roteiro do Ethereum inicialmente incluía duas estratégias de escalabilidade: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma parte das transações, enquanto o Layer 2 constrói redes sobre o Ethereum, aproveitando sua segurança e mantendo a maior parte dos dados e cálculos fora da cadeia principal. À medida que a pesquisa avançava, essas duas abordagens se fundiram, formando um roteiro centrado em Rollup, que até hoje é a estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propõe uma divisão simples: o Ethereum L1 se concentra em ser uma camada básica poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo está presente em toda a 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 básica 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ários Rollups da máquina virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um "shard" com suas próprias regras internas e lógica, e a diversidade e pluralidade na implementação de shards tornaram-se uma realidade. Mas, como vimos, seguir este caminho também enfrenta 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
No futuro, o Ethereum pode alcançar mais de 100.000 TPS através do L2;
Manter a descentralização e robustez do L1;
Pelo menos alguns L2 herdam completamente as propriedades centrais do Ethereum de ( confiança, abertura, 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
Melhoria da interoperabilidade entre L2
Expandir a execução na 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 para executar nós ), escalabilidade ( um grande número de transações processadas ) e segurança ( um atacante precisaria comprometer uma grande parte dos nós da rede para falhar uma única transação ).
É importante notar que a paradoxo triangular não é um teorema, e o post que apresenta o paradoxo triangular também não inclui uma prova matemática. De fato, ele oferece um argumento matemático heurístico: se um nó amigável à descentralização (, 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 descentralizará. O objetivo deste artigo não é provar que quebrar o paradoxo triangular é impossível; ao contrário, ele visa mostrar que quebrar o paradoxo ternário é difícil, e que é necessário, de certa forma, sair da estrutura de pensamento implícita nesse argumento.
Ao longo dos anos, algumas cadeias de alto desempenho afirmam frequentemente que resolveram o teorema do trilema sem mudar fundamentalmente a arquitetura, geralmente através da aplicação de 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 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 o paradoxo triangular: permite que os clientes verifiquem a disponibilidade de uma certa quantidade de dados e que uma certa quantidade de etapas de cálculo foram executadas corretamente, enquanto baixam apenas uma pequena quantidade de dados e realizam um número muito limitado de cálculos. Os SNARKs são sem confiança. A amostragem de disponibilidade de dados tem um modelo de confiança sutil de few-of-N, mas mantém as características básicas de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.
Outra abordagem para resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade pela disponibilidade de dados de monitoramento 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 na execução segura, mas com a popularização das provas de conhecimento zero concisas e não interativas SNARKs(, a arquitetura Plasma tornou-se mais viável para uma gama de cenários de uso mais ampla do que nunca.
![Vitalik nova publicação: Ethereum possível futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Avanços adicionais na amostragem de disponibilidade de dados
) Estamos a resolver que problema?
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 seja, 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 para Rollups na 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á entre 463 e 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 é de 16 MB por slot e, se combinado com melhorias na compressão de dados Rollup, isso resultará em ~58000 TPS.
) O que é? 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 shares do polinômio, onde cada share contém 16 valores de avaliação de 16 coordenadas adjacentes entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 ( pode ser restaurado com base nos parâmetros apresentados: qualquer 64 entre 128 possíveis amostras ).
O funcionamento do PeerDAS é permitir que cada cliente ouça um pequeno número de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e solicita, perguntando a pares na rede p2p global (, quem irá ouvir diferentes sub-redes ) para requisitar os blobs de que precisa em outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível dos pares. A proposta atual é permitir que os nós participantes da prova de participação utilizem o SubnetDAS, enquanto outros nós (, ou seja, clientes ), utilizam o PeerDAS.
Em teoria, podemos escalar um "amostragem 1D" bastante grande: se aumentarmos o número máximo de blobs para 256( com um objetivo de 128), então podemos alcançar a meta de 16MB, e na amostragem de disponibilidade de dados, cada nó terá 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas ligeiramente 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 tornará o custo de reconstrução mais alto.
Portanto, queremos avançar ainda mais e realizar amostragem 2D (2D sampling), este método não apenas realiza amostragem aleatória dentro do blob, mas também entre blobs. Utilizando a propriedade linear do compromisso KZG, expandimos um conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais que codificam redundantemente as mesmas informações.
Assim, no final, queremos ir mais longe e realizar amostragens 2D, que não só realizam amostragens aleatórias dentro do blob, mas também entre os blobs. 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 codificados redundantemente com as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, 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 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 é completar a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos de perto a rede e melhoramos o software para garantir a segurança, é 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 suas interações com questões de segurança, como regras de seleção de fork.
Em fases futuras 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 poder, finalmente, transitar do KZG para uma alternativa que seja segura contra quânticos e que não exija um setup confiável. Atualmente, não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos. Mesmo com o uso de técnicas "brute force" 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, um STARK é quase do tamanho de todo o blob.
Eu acredito que o caminho de realidade a longo prazo é:
Implementar o DAS 2D ideal;
Continuar a utilizar 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 o DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer2 em foco.
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 processar um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão 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 as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por DAS 2D diminuirá ou, pelo menos, será atrasada; 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 seja teoricamente 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.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.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 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 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:
![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 bytes nulos, usamos dois bytes para substituir cada sequência longa de bytes nulos, indicando quantos bytes nulos existem. Além disso, aproveitamos as propriedades específicas das transações:
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
15 gostos
Recompensa
15
4
Partilhar
Comentar
0/400
CryptoTarotReader
· 7h atrás
Esta onda de L2 vai Até à lua!
Ver originalResponder0
NightAirdropper
· 19h atrás
O Imperador do Fígado V está a começar a desenhar BTC novamente.
Ver originalResponder0
LayerZeroHero
· 07-19 20:54
Os dados não podem ser executados, a estratégia de divisão de trabalho inevitavelmente levará ao rollup.
Vitalik interpreta o futuro do Ethereum: A estratégia The Surge e a superação do dilema da escalabilidade.
Novo artigo de Vitalik: O futuro potencial do Ethereum, The Surge
O roteiro do Ethereum inicialmente incluía duas estratégias de escalabilidade: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma parte das transações, enquanto o Layer 2 constrói redes sobre o Ethereum, aproveitando sua segurança e mantendo a maior parte dos dados e cálculos fora da cadeia principal. À medida que a pesquisa avançava, essas duas abordagens se fundiram, formando um roteiro centrado em Rollup, que até hoje é a estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propõe uma divisão simples: o Ethereum L1 se concentra em ser uma camada básica poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo está presente em toda a 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 básica 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ários Rollups da máquina virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um "shard" com suas próprias regras internas e lógica, e a diversidade e pluralidade na implementação de shards tornaram-se uma realidade. Mas, como vimos, seguir este caminho também enfrenta 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
No futuro, o Ethereum pode alcançar mais de 100.000 TPS através do L2;
Manter a descentralização e robustez do L1;
Pelo menos alguns L2 herdam completamente as propriedades centrais do Ethereum de ( confiança, abertura, 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 para executar nós ), escalabilidade ( um grande número de transações processadas ) e segurança ( um atacante precisaria comprometer uma grande parte dos nós da rede para falhar uma única transação ).
É importante notar que a paradoxo triangular não é um teorema, e o post que apresenta o paradoxo triangular também não inclui uma prova matemática. De fato, ele oferece um argumento matemático heurístico: se um nó amigável à descentralização (, 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 descentralizará. O objetivo deste artigo não é provar que quebrar o paradoxo triangular é impossível; ao contrário, ele visa mostrar que quebrar o paradoxo ternário é difícil, e que é necessário, de certa forma, sair da estrutura de pensamento implícita nesse argumento.
Ao longo dos anos, algumas cadeias de alto desempenho afirmam frequentemente que resolveram o teorema do trilema sem mudar fundamentalmente a arquitetura, geralmente através da aplicação de 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 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 o paradoxo triangular: permite que os clientes verifiquem a disponibilidade de uma certa quantidade de dados e que uma certa quantidade de etapas de cálculo foram executadas corretamente, enquanto baixam apenas uma pequena quantidade de dados e realizam um número muito limitado de cálculos. Os SNARKs são sem confiança. A amostragem de disponibilidade de dados tem um modelo de confiança sutil de few-of-N, mas mantém as características básicas de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.
Outra abordagem para resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade pela disponibilidade de dados de monitoramento 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 na execução segura, mas com a popularização das provas de conhecimento zero concisas e não interativas SNARKs(, a arquitetura Plasma tornou-se mais viável para uma gama de cenários de uso mais ampla do que nunca.
![Vitalik nova publicação: Ethereum possível futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Avanços adicionais na amostragem de disponibilidade de dados
) Estamos a resolver que problema?
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 seja, 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 para Rollups na 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á entre 463 e 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 é de 16 MB por slot e, se combinado com melhorias na compressão de dados Rollup, isso resultará em ~58000 TPS.
) O que é? 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 shares do polinômio, onde cada share contém 16 valores de avaliação de 16 coordenadas adjacentes entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 ( pode ser restaurado com base nos parâmetros apresentados: qualquer 64 entre 128 possíveis amostras ).
O funcionamento do PeerDAS é permitir que cada cliente ouça um pequeno número de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e solicita, perguntando a pares na rede p2p global (, quem irá ouvir diferentes sub-redes ) para requisitar os blobs de que precisa em outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível dos pares. A proposta atual é permitir que os nós participantes da prova de participação utilizem o SubnetDAS, enquanto outros nós (, ou seja, clientes ), utilizam o PeerDAS.
Em teoria, podemos escalar um "amostragem 1D" bastante grande: se aumentarmos o número máximo de blobs para 256( com um objetivo de 128), então podemos alcançar a meta de 16MB, e na amostragem de disponibilidade de dados, cada nó terá 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas ligeiramente 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 tornará o custo de reconstrução mais alto.
Portanto, queremos avançar ainda mais e realizar amostragem 2D (2D sampling), este método não apenas realiza amostragem aleatória dentro do blob, mas também entre blobs. Utilizando a propriedade linear do compromisso KZG, expandimos um conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais que codificam redundantemente as mesmas informações.
Assim, no final, queremos ir mais longe e realizar amostragens 2D, que não só realizam amostragens aleatórias dentro do blob, mas também entre os blobs. 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 codificados redundantemente com as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, 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 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 é completar a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos de perto a rede e melhoramos o software para garantir a segurança, é 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 suas interações com questões de segurança, como regras de seleção de fork.
Em fases futuras 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 poder, finalmente, transitar do KZG para uma alternativa que seja segura contra quânticos e que não exija um setup confiável. Atualmente, não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos. Mesmo com o uso de técnicas "brute force" 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, um STARK é quase do tamanho de todo o blob.
Eu acredito 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 processar um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão 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 as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por DAS 2D diminuirá ou, pelo menos, será atrasada; 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 seja teoricamente 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.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.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 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 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:
![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 bytes nulos, usamos dois bytes para substituir cada sequência longa de bytes nulos, indicando quantos bytes nulos existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de assinaturas: Nós da ECD