O roteiro do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer2. O sharding permite que cada nó verifique e armazene apenas uma pequena parte das transações, enquanto os protocolos Layer2 constroem uma rede sobre o Ethereum. Esses dois caminhos acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a principal estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propôs uma divisão de trabalho clara: a L1 do Ethereum foca em se tornar uma camada base poderosa e descentralizada, enquanto a L2 assume a tarefa de ajudar a expandir o ecossistema. Este modelo é comum na sociedade, como o sistema judicial (L1) que fornece garantias básicas, enquanto os empreendedores (L2) impulsionam o desenvolvimento sobre essa base.
Este ano, 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 entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica internas. A diversidade e a pluralidade das formas de implementação de fragmentos tornaram-se uma realidade. No entanto, este caminho também enfrenta alguns desafios únicos. A nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, ao mesmo tempo em que mantemos a robustez e a descentralização 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 herdaram completamente as propriedades centrais do Ethereum ( de confiança, abertura e resistência à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste capítulo
Paradoxo do triângulo da escalabilidade
Avanços adicionais na amostragem de disponibilidade de dados
Compressão de dados
Plasma Generalizado
Sistema de prova L2 maduro
Melhorias na interoperabilidade entre L2
Expandir a execução na L1
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre as três características da blockchain: descentralização, escalabilidade e segurança. Este conceito não é um teorema matemático rigoroso, mas sim um argumento heurístico. Ele aponta que, 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 ou cada transação pode ser vista por apenas 1/k dos nós, o que reduz a segurança, ou os nós se tornam poderosos, o que reduz a descentralização.
Algumas cadeias de alto desempenho afirmam resolver o paradoxo triangular, mas na verdade é mais difícil executar nós dessas cadeias do que nós do 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 grandes volumes de dados e a correção dos passos de cálculo, baixando apenas uma pequena quantidade de dados e realizando um número muito limitado de cálculos.
Uma outra forma de resolver o paradoxo triangular é a arquitetura Plasma, que transfere a responsabilidade pela disponibilidade dos dados para os usuários. Com a popularização dos SNARKs, a arquitetura Plasma torna-se viável para um conjunto mais amplo de cenários de uso.
Avanços adicionais na amostragem de disponibilidade de dados
( Que problema estamos a resolver?
Após a atualização Dencun em março de 2024, cada slot do Ethereum a cada 12 segundos terá 3 blobs de aproximadamente 125 kB, ou seja, cerca de 375 kB de largura de banda de dados disponível por slot. Supondo que os dados das transações sejam publicados diretamente na blockchain, uma transferência ERC20 tem cerca de 180 bytes, então o TPS máximo do Rollup no Ethereum é de 173,6. Com a calldata do Ethereum, pode chegar a 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, fornecendo 463-926 TPS para a calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. O nosso objetivo a médio prazo é de 16 MB por slot, combinando melhorias na compressão de dados Rollup, o que resultará em cerca de 58000 TPS.
) O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "amostragem 1D". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Transmitimos as partes do polinômio, 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 conjunto de 4096 pode restaurar o blob.
PeerDAS permite que cada cliente escute uma quantidade reduzida de sub-redes e solicite blobs em outras sub-redes, perguntando a pares na rede p2p global. O SubnetDAS, mais conservador, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam da prova de participação utilizem SubnetDAS, enquanto os outros nós utilizem PeerDAS.
Teoricamente, podemos escalar a amostragem "1D" para um tamanho muito grande, mas isso fará com que os clientes com largura de banda limitada não consigam amostrar. Portanto, no final, queremos amostragem 2D, que não só realiza amostragem aleatória dentro do blob, mas também entre os blobs.
( Quais são os links com as pesquisas existentes?
Apresentação do post original sobre a disponibilidade de dados )2018###
Documento de acompanhamento
Artigo explicativo sobre o DAS, paradigma
Disponibilidade 2D com compromisso KZG
PeerDAS e artigos no ethresear.ch
EIP-7594
SubnetDAS no ethresear.ch
Diferenças sutis na recuperabilidade da amostragem 2D
O que mais precisa ser feito? Quais são os trade-offs?
A seguir, está a conclusão da implementação e lançamento do PeerDAS, seguido pelo aumento contínuo do número de blobs no PeerDAS. Ao mesmo tempo, esperamos ter mais trabalhos académicos para normatizar o DAS e a sua interação com questões de segurança, como as regras de escolha de fork.
Em estágios futuros mais distantes, precisamos determinar a versão ideal do DAS 2D e provar suas propriedades de segurança. Também esperamos eventualmente transitar do KZG para uma alternativa segura contra quântica e sem necessidade de configuração confiável.
O caminho da realidade a longo prazo pode ser:
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 Layer2 de interesse.
Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por DAS 2D diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em um Rollup consome uma grande quantidade de espaço de dados na cadeia: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com a amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudé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 é e como funciona?
Na compressão de zeros, usamos dois bytes para substituir cada sequência longa de zeros, indicando quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de assinaturas: mudando de assinaturas ECDSA para assinaturas BLS, várias assinaturas podem ser combinadas em uma única assinatura.
Substituir endereços por pointers: Se já utilizamos um determinado endereço anteriormente, podemos substituir o endereço de 20 bytes por um pointer de 4 bytes que aponta para uma posição na história.
Serialização personalizada de valores de transação: usar um formato decimal de ponto flutuante personalizado para representar a maioria dos valores monetários.
( Quais são os links com as pesquisas existentes?
Explorar sequence.xyz
Contrato de otimização de Calldata L2
Diferenças de estado de Rollups baseadas em provas de validade em vez de transações
Carteira BLS - Implementação da agregação BLS através do ERC-4337
) O que mais precisa ser feito, quais são os compromissos?
O que se deve fazer a seguir é a implementação prática da proposta mencionada acima. As principais considerações incluem:
Mudar para a assinatura BLS requer um grande esforço e diminuirá a compatibilidade com chips de hardware confiáveis.
A compressão dinâmica 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 deixem de funcionar.
Como interagir com outras partes do roteiro?
Adotar o ERC-4337 e, finalmente, incorporar parte do seu conteúdo no L2 EVM pode acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 no L1 pode acelerar sua implementação no L2.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
Plasma Generalizado
Que problema estamos a resolver?
Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente à demanda 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. Uma das opções atuais é o uso de Validium, que armazena 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 os fundos de todos os usuários. Mas podemos fazer melhor.
O que é, como funciona?
Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando as raízes Merkle desses blocos na cadeia. Para cada bloco, o operador envia a cada usuário uma ramificação Merkle para provar quais mudanças ocorreram nos ativos desse usuário, ou se não houve mudanças. Os usuários podem retirar seus ativos fornecendo a ramificação Merkle. É importante notar que essa ramificação não precisa ter como raiz o estado mais recente. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem restaurar seus ativos retirando seu estado mais recente disponível.
As versões iniciais do Plasma só podiam lidar com casos de pagamento, não conseguindo se expandir efetivamente. No entanto, se exigirmos que cada raiz seja verificada com SNARK, então o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, pois eliminamos 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 classes de ativos. Finalmente, na ausência de trapaça dos operadores, os usuários podem retirar fundos imediatamente, sem precisar esperar o período de disputa de uma semana.
Uma visão chave é que o sistema Plasma não precisa ser perfeito. Mesmo que você só consiga proteger um subconjunto de ativos (, por exemplo, apenas os tokens que não foram movidos na última semana ), você já melhorou significativamente o estado atual da EVM super escalável ###, ou seja, Validium ###.
Outra classe de estruturas é a mistura Plasma/Rollup, como o Intmax. Essas construções colocam uma quantidade mínima de dados de cada usuário na cadeia (, por exemplo, 5 bytes ), fazendo isso é possível obter certas características entre Plasma e Rollup: no caso do Intmax, você pode alcançar uma escalabilidade e privacidade muito altas, embora mesmo com uma capacidade de 16 MB, teoricamente isso esteja limitado a cerca de 16.000.000 / 12 / 5 = 266.667 TPS.
( Quais são os links relacionados com a pesquisa existente?
Documento original do Plasma
Plasma Cash
Plasma Cashflow
Intmax )2023(
) O que mais precisa ser feito? Quais são as compensações?
A principal tarefa restante é colocar o sistema Plasma em produção real. Qualquer Validium pode, pelo menos em certa medida, melhorar suas propriedades de segurança ao incorporar características do Plasma em seu mecanismo de saída. O foco da pesquisa está em obter as melhores propriedades para o EVM ### em termos de requisitos de confiança, custo de Gas L1 no pior caso e capacidade de resistir a ataques DoS.
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.
22 Curtidas
Recompensa
22
6
Repostar
Compartilhar
Comentário
0/400
RektButAlive
· 07-22 15:03
L2fazer dinheiro L1beber sopa estável
Ver originalResponder0
StablecoinGuardian
· 07-22 13:24
O limiar de uso do L2 é tão alto~
Ver originalResponder0
LayerHopper
· 07-21 05:02
Um explorador L2 agora está totalmente investido em L2, sabendo das oportunidades de agitar na cadeia. Ocasionalmente, faz alguns validadores para ganhar um pouco de dinheiro.
Ver originalResponder0
PanicSeller
· 07-21 04:53
Sem layer3, não estou otimista quanto a cair.
Ver originalResponder0
FlyingLeek
· 07-21 04:50
Manter sempre um respeito pelo mercado. Esta onda de行情 realmente valeu a pena.
Ver originalResponder0
WinterWarmthCat
· 07-21 04:41
É muito estúpido implementar a expansão dirigindo, não é?
Progresso da escalabilidade do Ethereum: Análise do Surge e perspectiva do roteiro Rollup
O futuro possível do Ethereum: The Surge
O roteiro do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer2. O sharding permite que cada nó verifique e armazene apenas uma pequena parte das transações, enquanto os protocolos Layer2 constroem uma rede sobre o Ethereum. Esses dois caminhos acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a principal estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propôs uma divisão de trabalho clara: a L1 do Ethereum foca em se tornar uma camada base poderosa e descentralizada, enquanto a L2 assume a tarefa de ajudar a expandir o ecossistema. Este modelo é comum na sociedade, como o sistema judicial (L1) que fornece garantias básicas, enquanto os empreendedores (L2) impulsionam o desenvolvimento sobre essa base.
Este ano, 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 entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica internas. A diversidade e a pluralidade das formas de implementação de fragmentos tornaram-se uma realidade. No entanto, este caminho também enfrenta alguns desafios únicos. A nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, ao mesmo tempo em que mantemos a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos Chave
Conteúdo deste capítulo
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre as três características da blockchain: descentralização, escalabilidade e segurança. Este conceito não é um teorema matemático rigoroso, mas sim um argumento heurístico. Ele aponta que, 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 ou cada transação pode ser vista por apenas 1/k dos nós, o que reduz a segurança, ou os nós se tornam poderosos, o que reduz a descentralização.
Algumas cadeias de alto desempenho afirmam resolver o paradoxo triangular, mas na verdade é mais difícil executar nós dessas cadeias do que nós do 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 grandes volumes de dados e a correção dos passos de cálculo, baixando apenas uma pequena quantidade de dados e realizando um número muito limitado de cálculos.
Uma outra forma de resolver o paradoxo triangular é a arquitetura Plasma, que transfere a responsabilidade pela disponibilidade dos dados para os usuários. Com a popularização dos SNARKs, a arquitetura Plasma torna-se viável para um conjunto mais amplo de cenários de uso.
Avanços adicionais na amostragem de disponibilidade de dados
( Que problema estamos a resolver?
Após a atualização Dencun em março de 2024, cada slot do Ethereum a cada 12 segundos terá 3 blobs de aproximadamente 125 kB, ou seja, cerca de 375 kB de largura de banda de dados disponível por slot. Supondo que os dados das transações sejam publicados diretamente na blockchain, uma transferência ERC20 tem cerca de 180 bytes, então o TPS máximo do Rollup no Ethereum é de 173,6. Com a calldata do Ethereum, pode chegar a 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, fornecendo 463-926 TPS para a calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. O nosso objetivo a médio prazo é de 16 MB por slot, combinando melhorias na compressão de dados Rollup, o que resultará em cerca de 58000 TPS.
) O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "amostragem 1D". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Transmitimos as partes do polinômio, 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 conjunto de 4096 pode restaurar o blob.
PeerDAS permite que cada cliente escute uma quantidade reduzida de sub-redes e solicite blobs em outras sub-redes, perguntando a pares na rede p2p global. O SubnetDAS, mais conservador, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam da prova de participação utilizem SubnetDAS, enquanto os outros nós utilizem PeerDAS.
Teoricamente, podemos escalar a amostragem "1D" para um tamanho muito grande, mas isso fará com que os clientes com largura de banda limitada não consigam amostrar. Portanto, no final, queremos amostragem 2D, que não só realiza amostragem aleatória dentro do blob, mas também entre os blobs.
( Quais são os links com as pesquisas existentes?
O que mais precisa ser feito? Quais são os trade-offs?
A seguir, está a conclusão da implementação e lançamento do PeerDAS, seguido pelo aumento contínuo do número de blobs no PeerDAS. Ao mesmo tempo, esperamos ter mais trabalhos académicos para normatizar o DAS e a sua interação com questões de segurança, como as regras de escolha de fork.
Em estágios futuros mais distantes, precisamos determinar a versão ideal do DAS 2D e provar suas propriedades de segurança. Também esperamos eventualmente transitar do KZG para uma alternativa segura contra quântica e sem necessidade de configuração confiável.
O caminho da realidade a longo prazo pode ser:
Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por DAS 2D diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em um Rollup consome uma grande quantidade de espaço de dados na cadeia: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com a amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudé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 é e como funciona?
Na compressão de zeros, usamos dois bytes para substituir cada sequência longa de zeros, indicando quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:
( Quais são os links com as pesquisas existentes?
) O que mais precisa ser feito, quais são os compromissos?
O que se deve fazer a seguir é a implementação prática da proposta mencionada acima. As principais considerações incluem:
Como interagir com outras partes do roteiro?
Adotar o ERC-4337 e, finalmente, incorporar parte do seu conteúdo no L2 EVM pode acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 no L1 pode acelerar sua implementação no L2.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
Plasma Generalizado
Que problema estamos a resolver?
Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente à demanda 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. Uma das opções atuais é o uso de Validium, que armazena 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 os fundos de todos os usuários. Mas podemos fazer melhor.
O que é, como funciona?
Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando as raízes Merkle desses blocos na cadeia. Para cada bloco, o operador envia a cada usuário uma ramificação Merkle para provar quais mudanças ocorreram nos ativos desse usuário, ou se não houve mudanças. Os usuários podem retirar seus ativos fornecendo a ramificação Merkle. É importante notar que essa ramificação não precisa ter como raiz o estado mais recente. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem restaurar seus ativos retirando seu estado mais recente disponível.
As versões iniciais do Plasma só podiam lidar com casos de pagamento, não conseguindo se expandir efetivamente. No entanto, se exigirmos que cada raiz seja verificada com SNARK, então o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, pois eliminamos 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 classes de ativos. Finalmente, na ausência de trapaça dos operadores, os usuários podem retirar fundos imediatamente, sem precisar esperar o período de disputa de uma semana.
Uma visão chave é que o sistema Plasma não precisa ser perfeito. Mesmo que você só consiga proteger um subconjunto de ativos (, por exemplo, apenas os tokens que não foram movidos na última semana ), você já melhorou significativamente o estado atual da EVM super escalável ###, ou seja, Validium ###.
Outra classe de estruturas é a mistura Plasma/Rollup, como o Intmax. Essas construções colocam uma quantidade mínima de dados de cada usuário na cadeia (, por exemplo, 5 bytes ), fazendo isso é possível obter certas características entre Plasma e Rollup: no caso do Intmax, você pode alcançar uma escalabilidade e privacidade muito altas, embora mesmo com uma capacidade de 16 MB, teoricamente isso esteja limitado a cerca de 16.000.000 / 12 / 5 = 266.667 TPS.
( Quais são os links relacionados com a pesquisa existente?
) O que mais precisa ser feito? Quais são as compensações?
A principal tarefa restante é colocar o sistema Plasma em produção real. Qualquer Validium pode, pelo menos em certa medida, melhorar suas propriedades de segurança ao incorporar características do Plasma em seu mecanismo de saída. O foco da pesquisa está em obter as melhores propriedades para o EVM ### em termos de requisitos de confiança, custo de Gas L1 no pior caso e capacidade de resistir a ataques DoS.