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. Essas duas estratégias acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão simples de trabalho: Ethereum L1 concentra-se em se tornar uma camada base poderosa e descentralizada, enquanto 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 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 máquina virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica internas, e a diversidade e pluralidade na implementação dos fragmentos 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, mantendo ao mesmo tempo a robustez e a descentralização que são características do Ethereum L1.
The Surge: Objetivos Chave
O Ethereum no futuro pode alcançar mais de 100.000 TPS através do L2.
Manter a descentralização e robustez do L1;
Pelo menos algumas L2 herdaram completamente as propriedades centrais do Ethereum de confiar, serem abertas e resistentes à censura (;
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(
) O conteúdo deste capítulo
Paradoxo da Tríade 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 do triângulo da escalabilidade
O paradoxo do triângulo da escalabilidade é uma ideia proposta em 2017, que afirma que existe uma contradição entre três características da blockchain: descentralização ### mais especificamente: o custo de operação dos nós é baixo (, escalabilidade ) quantidade de transações processadas é alta ( e segurança ) os atacantes precisam comprometer uma grande parte dos nós da rede para falhar uma única transação (.
Vale a pena notar que a paradoxia triangular não é um teorema, e os posts que apresentam a paradoxia triangular não incluem provas matemáticas. Ele realmente 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 será descentralizada. O objetivo deste artigo nunca foi provar que quebrar a paradoxia triangular é impossível; ao contrário, ele visa mostrar que quebrar a paradoxia ternária é difícil, e que isso requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Durante anos, algumas cadeias de alto desempenho afirmaram que resolveram o paradoxo trino sem alterar fundamentalmente a arquitetura, geralmente através da aplicação de técnicas de engenharia de software para otimizar nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar 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 consegue 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 que uma certa quantidade de dados está disponível e que uma certa quantidade de passos de cálculo foi executada corretamente, mesmo baixando apenas uma pequena quantidade de dados e realizando um número mínimo 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 preserva 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.
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 dos dados para os usuários de maneira compatível com incentivos. Entre 2017 e 2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, a Plasma era muito limitada em termos de execução segura, mas com a popularização das SNARKs), provas de conhecimento zero concisas e não interativas(, a arquitetura Plasma tornou-se mais viável para um espectro de casos de uso mais amplo do que nunca.
![Vitalik novo artigo: O futuro potencial do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
) Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
No dia 13 de março de 2024, quando a atualização Dencun estiver online, 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 por slot de cerca de 375 kB. Supondo que os dados de transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS para Rollup 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 tornaria 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, 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 "amostragem 1D". No Ethereum, cada blob é um polinômio de 4096 graus no campo primo de 253 bits ###. Nós transmitimos as partes dos polinômios, onde cada parte contém 16 valores de avaliação a partir de 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 ) pode recuperar o blob.
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 exemplo de qualquer blob, e solicita aos pares na rede p2p global ( quem ouvirá as 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 à camada de pares. A proposta atual é que os nós que participam do proof of stake utilizem o SubnetDAS, enquanto os outros nós (, ou clientes ), utilizem o PeerDAS.
Em teoria, podemos escalar uma "amostragem 1D" 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 16MB, e com a amostragem de disponibilidade de dados, cada nó tem 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas no limite do nosso intervalo de tolerância: é viável, mas isso significa que clientes com largura de banda limitada não conseguem 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 maior.
Assim, queremos ir mais longe e realizar a amostragem 2D (2D sampling), este método realiza amostragem aleatória não apenas 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 conjunto de novos blobs virtuais que codificam redundantemente a mesma informação.
Assim, no final, queremos ir mais longe e realizar amostragem 2D, que não só faz amostragem aleatória 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 de forma redundante com as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, essa solução é 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 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 compensações?
A próxima etapa é concluir a implementação e o lançamento do PeerDAS. Depois, aumentar constantemente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de escolha de fork.
Em fases futuras mais distantes, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos poder eventualmente mudar do KZG para uma alternativa quântica segura e sem necessidade de configuração confiável. No momento, ainda não temos clareza sobre quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo utilizando 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, pois, embora tecnicamente o tamanho de um STARK seja O)log(n) * log###log(n() hash ( usando STIR(, na prática, o STARK é quase tão grande quanto o blob inteiro.
Eu acho que o caminho de realidade a longo prazo é:
Implementar o DAS 2D ideal;
Persistir no 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 plenamente 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 escolha 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 uma maneira eficiente de verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que Rollup), como ZK-EVM e DAS).
(# Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS poderá 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 seja teoricamente amigável à reconstrução distribuída, na prática, isso requer uma combinação com a proposta da 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-5d1a322bd6b6dfef0dbb78017226633d.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: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem de disponibilidade de dados ideal, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos resolver não apenas o problema do numerador, mas também o problema do denominador, fazendo com que cada transação em um Rollup ocupasse menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
Na compressão de bytes zero, substituímos cada sequência longa de bytes zero por dois bytes, indicando quantos bytes zero existem. Além disso, aproveitamos 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.
22 gostos
Recompensa
22
8
Republicar
Partilhar
Comentar
0/400
BearHugger
· 08-19 09:26
A razão para ganhar dinheiro é se envolver.
Ver originalResponder0
MEVSupportGroup
· 08-17 12:40
A L2 centralizada me fez rir. Não é isso que é construir uma base de dados própria?
Ver originalResponder0
GasWaster
· 08-17 00:14
ainda pagando 500 gwei para a ponte... quando lua ser?
Ver originalResponder0
ForkPrince
· 08-16 19:07
A rota de atualização, no fundo, ainda é para fazer as pessoas de parvas no mundo crypto.
Ver originalResponder0
OnchainDetective
· 08-16 19:06
Alguém notou que o padrão de transações do endereço da carteira no artigo do V神 é muito suspeito? Aguardando uma análise de um colega.
Ver originalResponder0
ProveMyZK
· 08-16 19:04
Vitalik Buterin pavimenta o caminho para beneficiar o web3
Vitalik analisa o Ethereum The Surge: Meta de 100 mil TPS e o caminho da expansão L2
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. Essas duas estratégias acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão simples de trabalho: Ethereum L1 concentra-se em se tornar uma camada base poderosa e descentralizada, enquanto 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 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 máquina virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica internas, e a diversidade e pluralidade na implementação dos fragmentos 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, mantendo ao mesmo tempo a robustez e a descentralização que são características do Ethereum L1.
The Surge: Objetivos Chave
O Ethereum no futuro pode alcançar mais de 100.000 TPS através do L2.
Manter a descentralização e robustez do L1;
Pelo menos algumas L2 herdaram completamente as propriedades centrais do Ethereum de confiar, serem abertas e resistentes à censura (;
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(
) O conteúdo deste capítulo
paradoxo do triângulo da escalabilidade
O paradoxo do triângulo da escalabilidade é uma ideia proposta em 2017, que afirma que existe uma contradição entre três características da blockchain: descentralização ### mais especificamente: o custo de operação dos nós é baixo (, escalabilidade ) quantidade de transações processadas é alta ( e segurança ) os atacantes precisam comprometer uma grande parte dos nós da rede para falhar uma única transação (.
Vale a pena notar que a paradoxia triangular não é um teorema, e os posts que apresentam a paradoxia triangular não incluem provas matemáticas. Ele realmente 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 será descentralizada. O objetivo deste artigo nunca foi provar que quebrar a paradoxia triangular é impossível; ao contrário, ele visa mostrar que quebrar a paradoxia ternária é difícil, e que isso requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Durante anos, algumas cadeias de alto desempenho afirmaram que resolveram o paradoxo trino sem alterar fundamentalmente a arquitetura, geralmente através da aplicação de técnicas de engenharia de software para otimizar nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar 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 consegue 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 que uma certa quantidade de dados está disponível e que uma certa quantidade de passos de cálculo foi executada corretamente, mesmo baixando apenas uma pequena quantidade de dados e realizando um número mínimo 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 preserva 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.
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 dos dados para os usuários de maneira compatível com incentivos. Entre 2017 e 2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, a Plasma era muito limitada em termos de execução segura, mas com a popularização das SNARKs), provas de conhecimento zero concisas e não interativas(, a arquitetura Plasma tornou-se mais viável para um espectro de casos de uso mais amplo do que nunca.
![Vitalik novo artigo: O futuro potencial do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
) Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
No dia 13 de março de 2024, quando a atualização Dencun estiver online, 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 por slot de cerca de 375 kB. Supondo que os dados de transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS para Rollup 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 tornaria 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, 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 "amostragem 1D". No Ethereum, cada blob é um polinômio de 4096 graus no campo primo de 253 bits ###. Nós transmitimos as partes dos polinômios, onde cada parte contém 16 valores de avaliação a partir de 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 ) pode recuperar o blob.
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 exemplo de qualquer blob, e solicita aos pares na rede p2p global ( quem ouvirá as 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 à camada de pares. A proposta atual é que os nós que participam do proof of stake utilizem o SubnetDAS, enquanto os outros nós (, ou clientes ), utilizem o PeerDAS.
Em teoria, podemos escalar uma "amostragem 1D" 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 16MB, e com a amostragem de disponibilidade de dados, cada nó tem 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas no limite do nosso intervalo de tolerância: é viável, mas isso significa que clientes com largura de banda limitada não conseguem 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 maior.
Assim, queremos ir mais longe e realizar a amostragem 2D (2D sampling), este método realiza amostragem aleatória não apenas 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 conjunto de novos blobs virtuais que codificam redundantemente a mesma informação.
Assim, no final, queremos ir mais longe e realizar amostragem 2D, que não só faz amostragem aleatória 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 de forma redundante com as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, essa solução é 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 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 compensações?
A próxima etapa é concluir a implementação e o lançamento do PeerDAS. Depois, aumentar constantemente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de escolha de fork.
Em fases futuras mais distantes, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos poder eventualmente mudar do KZG para uma alternativa quântica segura e sem necessidade de configuração confiável. No momento, ainda não temos clareza sobre quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo utilizando 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, pois, embora tecnicamente o tamanho de um STARK seja O)log(n) * log###log(n() hash ( usando STIR(, na prática, o STARK é quase tão grande quanto o blob inteiro.
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 escolha 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 uma maneira eficiente de verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que Rollup), como ZK-EVM e DAS).
(# Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS poderá 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 seja teoricamente amigável à reconstrução distribuída, na prática, isso requer uma combinação com a proposta da 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-5d1a322bd6b6dfef0dbb78017226633d.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: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem de disponibilidade de dados ideal, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos resolver não apenas o problema do numerador, mas também o problema do denominador, fazendo com que cada transação em um Rollup ocupasse menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
Na compressão de bytes zero, substituímos cada sequência longa de bytes zero por dois bytes, indicando quantos bytes zero existem. Além disso, aproveitamos propriedades específicas das transações:
Agregação de assinaturas: nós