O roteiro do Ethereum incluía inicialmente 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 o Layer 2 mantém a maior parte dos dados e cálculos fora da cadeia principal. Essas duas abordagens 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ôs uma divisão simples de funções: o L1 do Ethereum foca em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Este modelo é comum na sociedade: o sistema judicial (L1) existe para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) constroem sobre essa base.
Este ano, o roteiro centrado em Rollup fez progressos significativos: o lançamento de blobs EIP-4844 aumentou drasticamente a largura de banda de dados do Ethereum L1, e vários EVM Rollups entraram na primeira fase. Cada L2 existe como um "shard" independente, e a diversidade nas formas de implementação dos shards 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, enquanto mantemos a robustez e a descentralização 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 herdam completamente as propriedades centrais do Ethereum (: confiar, aberto, resistente à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Paradoxo da Triângulo de Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre as três características do blockchain: descentralização, escalabilidade e segurança. Ele apresenta um argumento matemático heurístico: se um nó amigável à descentralização 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 permanecerá descentralizada.
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 a disponibilidade de uma certa quantidade de dados e que uma certa quantidade de etapas de cálculo seja executada corretamente, baixando apenas uma pequena quantidade de dados e executando um número muito reduzido de cálculos. Outra solução é a arquitetura Plasma, que transfere a responsabilidade de monitorar a disponibilidade de dados para os usuários. Com a popularização dos SNARKs, a arquitetura Plasma torna-se mais viável para cenários de uso mais amplos.
Avanços adicionais na amostragem de disponibilidade de dados
Atualmente, cada slot de 12 segundos no Ethereum possui 3 blobs de cerca de 125 kB, com uma largura de banda de dados disponível de aproximadamente 375 kB. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo do Rollup no Ethereum é de 173,6. Nosso objetivo de médio prazo é 16 MB por slot e, se combinado com melhorias na compressão de dados do Rollup, isso trará cerca de 58000 TPS.
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus sobre um 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 entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 pode ser usado para 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 sample de qualquer blob e solicita os blobs de outras sub-redes que precisa, questionando pares na rede p2p global. A versão mais conservadora SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares.
Teoricamente, podemos escalar o "sampling 1D" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256( com um alvo de 128), conseguiremos atingir o objetivo de 16MB, enquanto cada nó no sampling de disponibilidade de dados precisa processar 1 MB de largura de banda por slot. Isso está apenas dentro do nosso limite de tolerância, o que significa que clientes com largura de banda limitada não conseguem realizar o sampling.
Portanto, queremos avançar ainda mais 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 é utilizada para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais codificados redundante com as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, esta abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos só precisam ter o compromisso KZG do blob, e eles podem confiar na amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade dos blocos de dados.
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos atentamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Também esperamos mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como a interação delas com questões de segurança, como as regras de escolha de forks.
Em fases mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos ser capazes de passar do KZG para uma alternativa que seja segura contra quânticos e que não exija configuração confiável.
Eu acho que o caminho de realidade a longo prazo é:
Implementar o DAS 2D ideal;
Manter o uso de 1D DAS, sacrificando a eficiência da largura de banda de amostragem, para aceitar um limite de dados mais baixo em prol da simplicidade e robustez.
Abandonar DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer2 em que nos concentramos.
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso ocorre porque, se a camada L1 tiver que lidar com um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup(, como ZK-EVM e DAS).
Compressão de Dados
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 a 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 pudermos resolver não apenas os problemas do numerador, mas também os problemas do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
Existem várias maneiras de compressão de dados:
Compressão de zero bytes: substitui cada sequência longa de zero bytes por dois bytes, indicando quantos zero bytes existem.
Agregação de assinaturas: mudar de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, e essa assinatura pode provar a validade de todas as assinaturas originais.
Substituir endereços por pointers: Se já utilizou um determinado endereço, podemos substituir o endereço de 20 bytes por um pointer de 4 bytes que aponta para uma posição em um histórico.
Serialização personalizada de valores de transação: A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 Éter é representado como 250.000.000.000.000.000 wei. As taxas básicas máximas e as taxas prioritárias também são semelhantes. Assim, podemos usar um formato decimal de ponto flutuante personalizado para representar a maioria dos valores monetários.
Diferenças de estado de Rollups baseadas em provas de validade em vez de transações.
O que se deve fazer a seguir é implementar na prática a solução acima. As principais considerações incluem:
Mudar para a assinatura BLS requer um grande esforço e diminuirá a compatibilidade com os chips de hardware confiáveis que podem melhorar a segurança. Pode-se usar o encapsulamento ZK-SNARK de outros esquemas de assinatura como alternativa.
Compressão dinâmica ( Por exemplo, substituir endereços ) por ponteiros tornará o código do cliente mais complexo.
Publicar as diferenças de estado na cadeia em vez de transações reduzirá a auditabilidade e fará com que muitos softwares (, como exploradores de blocos ), não funcionem.
A adoção do ERC-4337 e a incorporação de parte do seu conteúdo no EVM da L2 podem acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 na L1 pode acelerar sua implementação na L2.
Plasma Generalizado
Mesmo com um blob de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender totalmente às necessidades de pagamentos de consumidores, redes sociais descentralizadas ou outros campos de alta largura de banda, especialmente quando começamos a considerar fatores de privacidade, o que pode reduzir a escalabilidade em 3 a 8 vezes. Para cenários de aplicação de alto volume de transações e baixo valor, uma escolha atual é usar Validium, que mantém os dados fora da cadeia e adota um modelo de segurança interessante: os operadores não podem roubar os fundos dos usuários, mas podem congelar temporariamente ou permanentemente todos os fundos dos usuários. Mas podemos fazer melhor.
Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando a raiz Merkle desses blocos na cadeia (. Diferente do Rollup, o Rollup coloca blocos completos na cadeia ). Para cada bloco, o operador envia a cada usuário uma ramificação Merkle para provar quais mudanças ocorreram em seus ativos ou se não houve mudanças. Os usuários podem retirar seus ativos fornecendo a ramificação Merkle. É importante que essa ramificação não precise ter o estado mais recente como raiz. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos retirando seu estado mais recente disponível. Se um usuário enviar uma ramificação inválida (, por exemplo, retirando ativos que já enviou para outras pessoas, ou se o operador criar um ativo do nada ), a legitimidade da posse dos ativos pode ser determinada por meio do mecanismo de desafio da cadeia.
As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não sendo eficazes para uma promoção mais ampla. No entanto, se exigirmos que cada raiz seja verificada com SNARK, o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, pois excluímos a maioria das possíveis rotas de trapaça dos operadores. Ao mesmo tempo, novas rotas são abertas, permitindo que a tecnologia Plasma se expanda para uma gama mais ampla de categorias de ativos. Por fim, na ausência de trapaças por parte dos operadores, os usuários podem retirar fundos imediatamente, sem precisar esperar uma semana pelo período de desafio.
Uma visão chave é que o sistema Plasma não precisa ser perfeito. Mesmo que você consiga proteger apenas um subconjunto de ativos (, por exemplo, apenas os tokens que não foram movidos na última semana ), você já melhorou significativamente a situação atual do EVM super escalável (, ou seja, o Validium ).
Outra classe de estruturas é a Plasma/Rollup híbrida, como a Intmax. Essas construções colocam uma quantidade mínima de dados de cada usuário na cadeia (, por exemplo, 5 bytes ). Isso permite obter certas características entre Plasma e Rollup: no caso da Intmax, você pode obter uma escalabilidade e privacidade muito altas, embora mesmo com uma capacidade de 16 MB, esteja teoricamente limitado a cerca de 16.
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.
10 Curtidas
Recompensa
10
5
Compartilhar
Comentário
0/400
DeFiCaffeinator
· 18h atrás
L2 novos idiotas fazer as pessoas de parvas
Ver originalResponder0
BlockchainTherapist
· 18h atrás
eth é o rei das montanhas
Ver originalResponder0
CryptoHistoryClass
· 18h atrás
*verifica padrões históricos* mais uma narrativa de escalabilidade do eth... assim como a hype do plasma de 2018 na minha opinião
Ver originalResponder0
Rugman_Walking
· 18h atrás
A ecologia do Eth é o caminho a seguir, não precisa pensar muito.
Ver originalResponder0
MidnightTrader
· 18h atrás
Os jogadores do ecossistema L2 estão realmente a ganhar muito.
Ethereum The Surge: a visão de 100 mil TPS e a solução para o problema da escalabilidade
O possível futuro do Ethereum: The Surge
O roteiro do Ethereum incluía inicialmente 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 o Layer 2 mantém a maior parte dos dados e cálculos fora da cadeia principal. Essas duas abordagens 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ôs uma divisão simples de funções: o L1 do Ethereum foca em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Este modelo é comum na sociedade: o sistema judicial (L1) existe para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) constroem sobre essa base.
Este ano, o roteiro centrado em Rollup fez progressos significativos: o lançamento de blobs EIP-4844 aumentou drasticamente a largura de banda de dados do Ethereum L1, e vários EVM Rollups entraram na primeira fase. Cada L2 existe como um "shard" independente, e a diversidade nas formas de implementação dos shards 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, enquanto mantemos 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 argumenta que existe uma contradição entre as três características do blockchain: descentralização, escalabilidade e segurança. Ele apresenta um argumento matemático heurístico: se um nó amigável à descentralização 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 permanecerá descentralizada.
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 a disponibilidade de uma certa quantidade de dados e que uma certa quantidade de etapas de cálculo seja executada corretamente, baixando apenas uma pequena quantidade de dados e executando um número muito reduzido de cálculos. Outra solução é a arquitetura Plasma, que transfere a responsabilidade de monitorar a disponibilidade de dados para os usuários. Com a popularização dos SNARKs, a arquitetura Plasma torna-se mais viável para cenários de uso mais amplos.
Avanços adicionais na amostragem de disponibilidade de dados
Atualmente, cada slot de 12 segundos no Ethereum possui 3 blobs de cerca de 125 kB, com uma largura de banda de dados disponível de aproximadamente 375 kB. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo do Rollup no Ethereum é de 173,6. Nosso objetivo de médio prazo é 16 MB por slot e, se combinado com melhorias na compressão de dados do Rollup, isso trará cerca de 58000 TPS.
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus sobre um 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 entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 pode ser usado para 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 sample de qualquer blob e solicita os blobs de outras sub-redes que precisa, questionando pares na rede p2p global. A versão mais conservadora SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares.
Teoricamente, podemos escalar o "sampling 1D" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256( com um alvo de 128), conseguiremos atingir o objetivo de 16MB, enquanto cada nó no sampling de disponibilidade de dados precisa processar 1 MB de largura de banda por slot. Isso está apenas dentro do nosso limite de tolerância, o que significa que clientes com largura de banda limitada não conseguem realizar o sampling.
Portanto, queremos avançar ainda mais 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 é utilizada para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais codificados redundante com as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, esta abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos só precisam ter o compromisso KZG do blob, e eles podem confiar na amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade dos blocos de dados.
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos atentamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Também esperamos mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como a interação delas com questões de segurança, como as regras de escolha de forks.
Em fases mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos ser capazes de passar do KZG para uma alternativa que seja segura contra quânticos e que não exija configuração confiável.
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 ocorre 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 um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup(, como ZK-EVM e DAS).
Compressão de Dados
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 a 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 pudermos resolver não apenas os problemas do numerador, mas também os problemas do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
Existem várias maneiras de compressão de dados:
Compressão de zero bytes: substitui cada sequência longa de zero bytes por dois bytes, indicando quantos zero bytes existem.
Agregação de assinaturas: mudar de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, e essa assinatura pode provar a validade de todas as assinaturas originais.
Substituir endereços por pointers: Se já utilizou um determinado endereço, podemos substituir o endereço de 20 bytes por um pointer de 4 bytes que aponta para uma posição em um histórico.
Serialização personalizada de valores de transação: A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 Éter é representado como 250.000.000.000.000.000 wei. As taxas básicas máximas e as taxas prioritárias também são semelhantes. Assim, podemos usar um formato decimal de ponto flutuante personalizado para representar a maioria dos valores monetários.
Diferenças de estado de Rollups baseadas em provas de validade em vez de transações.
O que se deve fazer a seguir é implementar na prática a solução acima. As principais considerações incluem:
Mudar para a assinatura BLS requer um grande esforço e diminuirá a compatibilidade com os chips de hardware confiáveis que podem melhorar a segurança. Pode-se usar o encapsulamento ZK-SNARK de outros esquemas de assinatura como alternativa.
Compressão dinâmica ( Por exemplo, substituir endereços ) por ponteiros tornará o código do cliente mais complexo.
Publicar as diferenças de estado na cadeia em vez de transações reduzirá a auditabilidade e fará com que muitos softwares (, como exploradores de blocos ), não funcionem.
A adoção do ERC-4337 e a incorporação de parte do seu conteúdo no EVM da L2 podem acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 na L1 pode acelerar sua implementação na L2.
Plasma Generalizado
Mesmo com um blob de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender totalmente às necessidades de pagamentos de consumidores, redes sociais descentralizadas ou outros campos de alta largura de banda, especialmente quando começamos a considerar fatores de privacidade, o que pode reduzir a escalabilidade em 3 a 8 vezes. Para cenários de aplicação de alto volume de transações e baixo valor, uma escolha atual é usar Validium, que mantém os dados fora da cadeia e adota um modelo de segurança interessante: os operadores não podem roubar os fundos dos usuários, mas podem congelar temporariamente ou permanentemente todos os fundos dos usuários. Mas podemos fazer melhor.
Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando a raiz Merkle desses blocos na cadeia (. Diferente do Rollup, o Rollup coloca blocos completos na cadeia ). Para cada bloco, o operador envia a cada usuário uma ramificação Merkle para provar quais mudanças ocorreram em seus ativos ou se não houve mudanças. Os usuários podem retirar seus ativos fornecendo a ramificação Merkle. É importante que essa ramificação não precise ter o estado mais recente como raiz. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos retirando seu estado mais recente disponível. Se um usuário enviar uma ramificação inválida (, por exemplo, retirando ativos que já enviou para outras pessoas, ou se o operador criar um ativo do nada ), a legitimidade da posse dos ativos pode ser determinada por meio do mecanismo de desafio da cadeia.
As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não sendo eficazes para uma promoção mais ampla. No entanto, se exigirmos que cada raiz seja verificada com SNARK, o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, pois excluímos a maioria das possíveis rotas de trapaça dos operadores. Ao mesmo tempo, novas rotas são abertas, permitindo que a tecnologia Plasma se expanda para uma gama mais ampla de categorias de ativos. Por fim, na ausência de trapaças por parte dos operadores, os usuários podem retirar fundos imediatamente, sem precisar esperar uma semana pelo período de desafio.
Uma visão chave é que o sistema Plasma não precisa ser perfeito. Mesmo que você consiga proteger apenas um subconjunto de ativos (, por exemplo, apenas os tokens que não foram movidos na última semana ), você já melhorou significativamente a situação atual do EVM super escalável (, ou seja, o Validium ).
Outra classe de estruturas é a Plasma/Rollup híbrida, como a Intmax. Essas construções colocam uma quantidade mínima de dados de cada usuário na cadeia (, por exemplo, 5 bytes ). Isso permite obter certas características entre Plasma e Rollup: no caso da Intmax, você pode obter uma escalabilidade e privacidade muito altas, embora mesmo com uma capacidade de 16 MB, esteja teoricamente limitado a cerca de 16.