O roteiro do Ethereum incluía inicialmente duas estratégias de escalonamento: sharding e protocolos Layer2. O sharding permite que cada nó valide e armazene apenas uma parte das transações, enquanto o Layer2 constrói uma rede sobre o Ethereum, aproveitando sua segurança, mas mantendo a maior parte dos dados e cálculos fora da cadeia principal. Essas duas abordagens acabaram se fundindo em um roteiro centrado em Rollup, que ainda é a estratégia de escalonamento do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o Ethereum L1 foca em se tornar uma camada de base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é muito comum na sociedade: o sistema judicial (L1) existe para proteger contratos e propriedade, enquanto os empreendedores (L2) constroem sobre essa base, impulsionando o desenvolvimento humano.
Este ano, o roteiro centrado em Rollup fez progressos importantes: o lançamento dos blobs EIP-4844 aumentou significativamente a largura de banda de dados do Ethereum L1, 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, e a diversidade nas formas de implementar fragmentos tornou-se uma realidade. No entanto, esse caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar o roteiro centrado em Rollup, resolver esses problemas, mantendo a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos-chave
O futuro do Ethereum pode atingir mais de 100.000 TPS através do L2;
Manter a descentralização e robustez do L1;
Pelo menos parte do L2 herda completamente as propriedades centrais do Ethereum: ( confiança, abertura, resistência à censura );
Ethereum deve parecer um ecossistema unificado, em vez de 34 blockchains diferentes.
Paradoxo da Triângulo de Escalabilidade
O paradoxo do triângulo da escalabilidade afirma que há uma contradição entre três características da blockchain: descentralização ( custo baixo dos nós de execução ) escalabilidade ( grande quantidade de transações processadas ) e segurança ( os atacantes precisam comprometer uma grande parte dos nós na rede para fazer uma única transação falhar ).
O paradoxo triangular não é um teorema, e os posts que o apresentam não incluem uma prova matemática. Ele oferece um argumento matemático heurístico: se um nó amigável e descentralizado pode validar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então: (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza. O artigo visa demonstrar que quebrar o paradoxo ternário é difícil, exigindo, de certa forma, sair da estrutura de pensamento implícita no argumento.
Durante anos, algumas blockchains de alto desempenho afirmam resolver o dilema trilema sem mudar fundamentalmente a arquitetura, geralmente otimizando os nós. Isso é sempre enganoso, pois executar nós nessas blockchains é muito mais difícil do que executar nós no 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 etapas de cálculo foi executada corretamente, baixando apenas uma quantidade reduzida de dados e realizando um número mínimo de cálculos. Os SNARKs são sem necessidade de 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 blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema trilema é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade pela disponibilidade dos dados de monitoramento para os usuários de uma maneira compatível com incentivos. Já em 2017-2019, quando apenas tínhamos a prova de fraude como meio para expandir a capacidade computacional, a Plasma tinha limitações significativas em termos de execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para cenários de uso mais amplos do que nunca.
Progresso adicional na amostragem da 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 aproximadamente 125 kB a cada 12 segundos, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS 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 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 grande melhoria para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, que, se combinado com melhorias na compressão de dados Rollup, trará cerca de ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus 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 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 atualmente propostos: qualquer 64 de 128 amostras possíveis ( pode recuperar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute uma quantidade limitada de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e, ao perguntar aos pares na rede p2p global quem irá escutar diferentes sub-redes ), solicita os blobs de outras sub-redes que precisa. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem questionar a camada de pares adicionalmente. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto outros nós (, ou seja, 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, e na amostragem de disponibilidade de dados, cada nó terá 16 amostras * 128 blobs * 512 bytes por amostra por 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 conseguem 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 ir mais longe e realizar a amostragem 2D (2D sampling), este método não só realiza a amostragem aleatória dentro do blob, mas também entre os blobs. Usando a propriedade linear do compromisso KZG, expandimos um conjunto de blobs em um bloco com um novo conjunto de blobs virtuais, que codificam redundante as mesmas informações.
Portanto, no final, queremos ir mais além e realizar amostragem 2D, que não apenas amostra aleatoriamente dentro do blob, mas também entre os blobs. A propriedade linear do compromisso KZG é usada para expandir 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 blocos só precisam ter o compromisso KZG de 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 compensações?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentaremos continuamente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, sendo este um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como suas interações com a segurança das regras de escolha de forks.
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, eventualmente, poder mudar do KZG para uma alternativa que seja segura quânticamente e não exija configurações confiáveis. Atualmente, ainda não está claro quais candidatos são amigáveis à 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, 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.
O caminho de realidade de longo prazo que eu considero é:
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.
Abandonar o DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer 2 de foco.
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção existe. Isso 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 Rollup), como ZK-EVM e DAS).
( Como interagir com as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para 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 seleção de fork ao seu redor.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.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 amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot 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 no Rollup ocupasse menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
Na compressão de zero bytes, substituímos cada sequência longa de zero bytes por dois bytes que indicam quantos zero bytes 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 várias assinaturas podem ser combinadas em uma única assinatura, que pode provar todos os originais.
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.
6 Curtidas
Recompensa
6
4
Compartilhar
Comentário
0/400
FloorSweeper
· 08-04 04:06
Não pergunte por quê, L2 é incrível.
Ver originalResponder0
RamenDeFiSurvivor
· 08-04 04:05
Wala L2 é realmente bom
Ver originalResponder0
ShadowStaker
· 08-04 04:02
hmm a eficiência do mev nos l2s ainda precisa de trabalho, para ser sincero... a topologia da rede ainda não está lá.
Ver originalResponder0
BearMarketBuyer
· 08-04 03:59
Está a puxar para o nível 2 ou está vazio? Vamos dar uma olhada.
Ethereum escalabilidade nova fase: Análise profunda do roteiro The Surge
O futuro possível do Ethereum: The Surge
O roteiro do Ethereum incluía inicialmente duas estratégias de escalonamento: sharding e protocolos Layer2. O sharding permite que cada nó valide e armazene apenas uma parte das transações, enquanto o Layer2 constrói uma rede sobre o Ethereum, aproveitando sua segurança, mas mantendo a maior parte dos dados e cálculos fora da cadeia principal. Essas duas abordagens acabaram se fundindo em um roteiro centrado em Rollup, que ainda é a estratégia de escalonamento do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o Ethereum L1 foca em se tornar uma camada de base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é muito comum na sociedade: o sistema judicial (L1) existe para proteger contratos e propriedade, enquanto os empreendedores (L2) constroem sobre essa base, impulsionando o desenvolvimento humano.
Este ano, o roteiro centrado em Rollup fez progressos importantes: o lançamento dos blobs EIP-4844 aumentou significativamente a largura de banda de dados do Ethereum L1, 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, e a diversidade nas formas de implementar fragmentos tornou-se uma realidade. No entanto, esse caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar o roteiro centrado em Rollup, resolver esses problemas, mantendo a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos-chave
Paradoxo da Triângulo de Escalabilidade
O paradoxo do triângulo da escalabilidade afirma que há uma contradição entre três características da blockchain: descentralização ( custo baixo dos nós de execução ) escalabilidade ( grande quantidade de transações processadas ) e segurança ( os atacantes precisam comprometer uma grande parte dos nós na rede para fazer uma única transação falhar ).
O paradoxo triangular não é um teorema, e os posts que o apresentam não incluem uma prova matemática. Ele oferece um argumento matemático heurístico: se um nó amigável e descentralizado pode validar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então: (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza. O artigo visa demonstrar que quebrar o paradoxo ternário é difícil, exigindo, de certa forma, sair da estrutura de pensamento implícita no argumento.
Durante anos, algumas blockchains de alto desempenho afirmam resolver o dilema trilema sem mudar fundamentalmente a arquitetura, geralmente otimizando os nós. Isso é sempre enganoso, pois executar nós nessas blockchains é muito mais difícil do que executar nós no 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 etapas de cálculo foi executada corretamente, baixando apenas uma quantidade reduzida de dados e realizando um número mínimo de cálculos. Os SNARKs são sem necessidade de 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 blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema trilema é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade pela disponibilidade dos dados de monitoramento para os usuários de uma maneira compatível com incentivos. Já em 2017-2019, quando apenas tínhamos a prova de fraude como meio para expandir a capacidade computacional, a Plasma tinha limitações significativas em termos de execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para cenários de uso mais amplos do que nunca.
Progresso adicional na amostragem da 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 aproximadamente 125 kB a cada 12 segundos, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS 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 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 grande melhoria para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, que, se combinado com melhorias na compressão de dados Rollup, trará cerca de ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus 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 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 atualmente propostos: qualquer 64 de 128 amostras possíveis ( pode recuperar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute uma quantidade limitada de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e, ao perguntar aos pares na rede p2p global quem irá escutar diferentes sub-redes ), solicita os blobs de outras sub-redes que precisa. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem questionar a camada de pares adicionalmente. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto outros nós (, ou seja, 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, e na amostragem de disponibilidade de dados, cada nó terá 16 amostras * 128 blobs * 512 bytes por amostra por 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 conseguem 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 ir mais longe e realizar a amostragem 2D (2D sampling), este método não só realiza a amostragem aleatória dentro do blob, mas também entre os blobs. Usando a propriedade linear do compromisso KZG, expandimos um conjunto de blobs em um bloco com um novo conjunto de blobs virtuais, que codificam redundante as mesmas informações.
Portanto, no final, queremos ir mais além e realizar amostragem 2D, que não apenas amostra aleatoriamente dentro do blob, mas também entre os blobs. A propriedade linear do compromisso KZG é usada para expandir 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 blocos só precisam ter o compromisso KZG de 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 compensações?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentaremos continuamente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, sendo este um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como suas interações com a segurança das regras de escolha de forks.
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, eventualmente, poder mudar do KZG para uma alternativa que seja segura quânticamente e não exija configurações confiáveis. Atualmente, ainda não está claro quais candidatos são amigáveis à 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, 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.
O caminho de realidade de longo prazo que eu considero é:
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção existe. Isso 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 Rollup), como ZK-EVM e DAS).
( Como interagir com as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para 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 seleção de fork ao seu redor.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.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 amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot 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 no Rollup ocupasse menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
Na compressão de zero bytes, substituímos cada sequência longa de zero bytes por dois bytes que indicam quantos zero bytes 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 várias assinaturas podem ser combinadas em uma única assinatura, que pode provar todos os originais.