A estratégia de escalabilidade do Ethereum inicialmente tinha duas abordagens: sharding e Layer2. O sharding permite que cada nó verifique e armazene apenas uma pequena parte das transações, enquanto o Layer2 coloca 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 do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: Ethereum L1 foca em se tornar uma camada base forte e descentralizada, enquanto 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, impulsionando o desenvolvimento humano.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: O lançamento dos blobs EIP-4844 aumentou significativamente a largura de banda de dados do Ethereum L1, e vários EVM Rollups entraram na primeira fase. Cada L2 existe como um "shard" com regras e lógicas internas, e a diversidade na implementação de shards tornou-se uma realidade. Mas este caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar este roteiro e resolver esses problemas, enquanto mantemos a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos principais
No futuro, o Ethereum poderá alcançar mais de 100 mil TPS através do L2.
Manter a descentralização e robustez do L1
Pelo menos algumas L2 herdam 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 de 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 afirma que existe uma contradição entre as três características da descentralização, escalabilidade e segurança do blockchain. Não é um teorema, mas apresenta um argumento 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 ou cada transação só pode ser vista por 1/k dos nós, ou seus nós se tornarão fortes, e a cadeia não será descentralizada.
Algumas cadeias de alto desempenho afirmam resolver o paradoxo trino, geralmente otimizando o software de nós. Mas isso muitas vezes é enganoso, pois executar nós nessas cadeias é mais difícil do que no Ethereum. Apenas 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 a disponibilidade de grandes quantidades de dados e a execução correta dos passos de cálculo, realizando apenas o download de uma pequena quantidade de dados e executando um número muito reduzido de cálculos. Os SNARKs são sem necessidade de confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil de few-of-N, mas mantém as características fundamentais de uma cadeia não escalável.
A arquitetura Plasma é outra solução que transfere a responsabilidade pela disponibilidade dos dados aos usuários. Com a popularização dos SNARKs, o Plasma se torna viável para uma gama mais ampla de cenários.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
Após a atualização Dencun em 13 de março de 2024, o Ethereum terá 3 blobs de aproximadamente 125kB a cada 12 segundos por slot, com uma largura de banda de dados disponível de cerca de 375kB/slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, então o TPS máximo de Rollup no Ethereum será de 173,6.
Com calldata, pode atingir 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, fornecendo 463-926 TPS para calldata.
Esta é uma melhoria significativa para o L1, mas ainda não é suficiente. O nosso objetivo a médio prazo é de 16MB por slot, combinando a compressão de dados Rollup, o que resultará em ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação simples de "1D sampling". No Ethereum, cada blob é um polinómio de 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinómio, cada parte contendo 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 um pequeno número de sub-redes, a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob e solicita blobs de outras sub-redes perguntando a pares na rede p2p global. SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares. A proposta atual permite que os nós envolvidos na prova de participação utilizem SubnetDAS, enquanto outros nós utilizem PeerDAS.
Teoricamente, podemos escalar o "1D sampling" para um tamanho muito maior: se aumentarmos o número máximo de blobs para 256, podemos atingir a meta de 16MB, com cada nó precisando de 1MB de largura de banda de dados por slot. Isso é apenas viável, mas clientes com largura de banda limitada não conseguem amostrar. Podemos otimizar reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso tornará o custo de reconstrução mais alto.
Portanto, queremos amostragem 2D, não apenas amostragem aleatória 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 novos blobs virtuais, que codificam redundantemente as mesmas informações.
A amostragem 2D é amigável para a construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas do compromisso KZG blob e podem contar com o DAS para verificar a disponibilidade. O DAS 1D também é essencialmente amigável para a construção de blocos distribuídos.
Quais são as ligações com as pesquisas existentes?
Introdução ao post original sobre a disponibilidade de dados (2018)
Documento de acompanhamento
Artigo explicativo sobre o DAS
Disponibilidade 2D com compromisso KZG
PeerDAS e artigos no ethresear.ch
EIP-7594
SubnetDAS no ethresear.ch
Nuances de recuperabilidade na amostragem 2D
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, aumentar continuamente o número de blobs no PeerDAS, enquanto observa cuidadosamente a rede e melhora o software para garantir a segurança. Esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e sua interação com questões de segurança, como as regras de escolha de forks.
No futuro, será necessário determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Esperamos, em última instância, conseguir transitar do KZG para uma alternativa segura quântica e que não exija uma configuração confiável. Atualmente, não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos.
O caminho real 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, para aceitar um limite de dados mais baixo em prol da simplicidade e robustez.
Abandonar o DA e aceitar completamente o Plasma como a principal arquitetura Layer 2.
Mesmo que decidamos expandir a execução diretamente na camada L1, essa opção existe. Porque se a L1 tiver que lidar com um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes precisarão de métodos de verificação eficientes, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup.
Como interagir com as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS diminuirá ou será adiada, e 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 precisa ser combinado com a proposta de lista de inclusão de pacotes e seus mecanismos de escolha de fork associados.
Compressão de Dados
Que problema estamos a resolver?
Uma grande quantidade de espaço de dados em cadeia é ocupada por cada transação no Rollup: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot tem 16MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos fazer com que as transações no Rollup ocupassem menos bytes na cadeia?
O que é, como funciona?
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 que indicam quantos bytes zero existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de assinaturas: a transição de ECDSA para assinaturas BLS, onde várias assinaturas podem ser combinadas em uma única assinatura, provando a validade de todas as assinaturas originais. No L1, devido ao alto custo computacional de verificação, o uso de BLS não é considerado, mas no L2, em um ambiente onde os dados são escassos, o uso de BLS faz sentido. As características de agregação do ERC-4337 fornecem um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: se já usamos um determinado endereço antes, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição no histórico.
Serialização personalizada de valores de transação: A maioria dos valores de transação tem poucas casas decimais, como 0,25 ETH representado como 250.000.000.000.000.000 wei. A taxa básica máxima e a taxa prioritária também são semelhantes. Portanto, podemos usar um formato decimal de ponto flutuante personalizado para representar a maioria dos valores monetários.
Quais são os links com a pesquisa existente?
Explorar sequence.xyz
Otimização de contrato L2 Calldata
Diferenças de estado de Rollups baseadas na prova 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 as considerações?
A seguir, o foco será na implementação prática da proposta acima. As principais considerações incluem:
Mudar para assinaturas BLS requer um grande esforço e reduzirá a compatibilidade com chips de hardware confiáveis. Alternativamente, pode-se usar pacotes ZK-SNARK com outros esquemas de assinatura.
Compressão dinâmica ( usar pointers para substituir endereços ) tornará o código do cliente mais complexo.
Publicar as diferenças de estado na cadeia em vez de transação, irá reduzir a auditabilidade, fazendo com que muitos softwares ( como exploradores de blocos ) não consigam funcionar.
Como interagir com as outras partes do roteiro?
Ao adotar o ERC-4337 e, por fim, integrar parte dele no EVM L2, é possível acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do ERC-4337 no L1 pode acelerar sua implementação no L2.
Plasma Generalizado
Que problema estamos a resolver?
Mesmo usando blobs de 16MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às demandas de alto consumo de largura de banda, como pagamentos de consumidores e redes sociais descentralizadas, especialmente considerando que fatores de privacidade podem reduzir a escalabilidade em 3 a 8 vezes. Atualmente, a escolha para cenários de alto volume de transações e baixo valor é o Validium, que armazena dados fora da cadeia, adotando um modelo de segurança: 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.
O que é isso, como funciona?
Plasma é uma solução de escalabilidade, onde os operadores publicam blocos fora da cadeia, colocando apenas a raiz Merkle desses blocos na cadeia. Para cada bloco, os operadores enviam a cada usuário uma prova Merkle que demonstra a alteração ou a imutabilidade dos ativos desse usuário. Os usuários podem retirar ativos fornecendo a prova Merkle. É importante notar que essa prova não precisa ter o estado mais recente como raiz. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar ativos extraindo o estado mais recente disponível. Se um usuário enviar uma prova inválida, a propriedade dos ativos pode ser determinada através do mecanismo de contestação na cadeia.
As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não conseguindo ser amplamente promovidas. Mas
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.
Ethereum O Surge: O objetivo e os desafios da expansão de 100.000 TPS através do L2
Ethereum: O Surge
A estratégia de escalabilidade do Ethereum inicialmente tinha duas abordagens: sharding e Layer2. O sharding permite que cada nó verifique e armazene apenas uma pequena parte das transações, enquanto o Layer2 coloca 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 do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: Ethereum L1 foca em se tornar uma camada base forte e descentralizada, enquanto 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, impulsionando o desenvolvimento humano.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: O lançamento dos blobs EIP-4844 aumentou significativamente a largura de banda de dados do Ethereum L1, e vários EVM Rollups entraram na primeira fase. Cada L2 existe como um "shard" com regras e lógicas internas, e a diversidade na implementação de shards tornou-se uma realidade. Mas este caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar este roteiro e resolver esses problemas, enquanto mantemos a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos principais
Conteúdo deste capítulo
Paradoxo do Triângulo da Escalabilidade
O paradoxo do triângulo da escalabilidade afirma que existe uma contradição entre as três características da descentralização, escalabilidade e segurança do blockchain. Não é um teorema, mas apresenta um argumento 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 ou cada transação só pode ser vista por 1/k dos nós, ou seus nós se tornarão fortes, e a cadeia não será descentralizada.
Algumas cadeias de alto desempenho afirmam resolver o paradoxo trino, geralmente otimizando o software de nós. Mas isso muitas vezes é enganoso, pois executar nós nessas cadeias é mais difícil do que no Ethereum. Apenas 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 a disponibilidade de grandes quantidades de dados e a execução correta dos passos de cálculo, realizando apenas o download de uma pequena quantidade de dados e executando um número muito reduzido de cálculos. Os SNARKs são sem necessidade de confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil de few-of-N, mas mantém as características fundamentais de uma cadeia não escalável.
A arquitetura Plasma é outra solução que transfere a responsabilidade pela disponibilidade dos dados aos usuários. Com a popularização dos SNARKs, o Plasma se torna viável para uma gama mais ampla de cenários.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
Após a atualização Dencun em 13 de março de 2024, o Ethereum terá 3 blobs de aproximadamente 125kB a cada 12 segundos por slot, com uma largura de banda de dados disponível de cerca de 375kB/slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, então o TPS máximo de Rollup no Ethereum será de 173,6.
Com calldata, pode atingir 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, fornecendo 463-926 TPS para calldata.
Esta é uma melhoria significativa para o L1, mas ainda não é suficiente. O nosso objetivo a médio prazo é de 16MB por slot, combinando a compressão de dados Rollup, o que resultará em ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação simples de "1D sampling". No Ethereum, cada blob é um polinómio de 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinómio, cada parte contendo 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 um pequeno número de sub-redes, a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob e solicita blobs de outras sub-redes perguntando a pares na rede p2p global. SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares. A proposta atual permite que os nós envolvidos na prova de participação utilizem SubnetDAS, enquanto outros nós utilizem PeerDAS.
Teoricamente, podemos escalar o "1D sampling" para um tamanho muito maior: se aumentarmos o número máximo de blobs para 256, podemos atingir a meta de 16MB, com cada nó precisando de 1MB de largura de banda de dados por slot. Isso é apenas viável, mas clientes com largura de banda limitada não conseguem amostrar. Podemos otimizar reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso tornará o custo de reconstrução mais alto.
Portanto, queremos amostragem 2D, não apenas amostragem aleatória 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 novos blobs virtuais, que codificam redundantemente as mesmas informações.
A amostragem 2D é amigável para a construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas do compromisso KZG blob e podem contar com o DAS para verificar a disponibilidade. O DAS 1D também é essencialmente amigável para a construção de blocos distribuídos.
Quais são as ligações com as pesquisas existentes?
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, aumentar continuamente o número de blobs no PeerDAS, enquanto observa cuidadosamente a rede e melhora o software para garantir a segurança. Esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e sua interação com questões de segurança, como as regras de escolha de forks.
No futuro, será necessário determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Esperamos, em última instância, conseguir transitar do KZG para uma alternativa segura quântica e que não exija uma configuração confiável. Atualmente, não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos.
O caminho real de longo prazo que eu considero é:
Mesmo que decidamos expandir a execução diretamente na camada L1, essa opção existe. Porque se a L1 tiver que lidar com um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes precisarão de métodos de verificação eficientes, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup.
Como interagir com as outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS diminuirá ou será adiada, e 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 precisa ser combinado com a proposta de lista de inclusão de pacotes e seus mecanismos de escolha de fork associados.
Compressão de Dados
Que problema estamos a resolver?
Uma grande quantidade de espaço de dados em cadeia é ocupada por cada transação no Rollup: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot tem 16MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos fazer com que as transações no Rollup ocupassem menos bytes na cadeia?
O que é, como funciona?
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 que indicam quantos bytes zero existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de assinaturas: a transição de ECDSA para assinaturas BLS, onde várias assinaturas podem ser combinadas em uma única assinatura, provando a validade de todas as assinaturas originais. No L1, devido ao alto custo computacional de verificação, o uso de BLS não é considerado, mas no L2, em um ambiente onde os dados são escassos, o uso de BLS faz sentido. As características de agregação do ERC-4337 fornecem um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: se já usamos um determinado endereço antes, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição no histórico.
Serialização personalizada de valores de transação: A maioria dos valores de transação tem poucas casas decimais, como 0,25 ETH representado como 250.000.000.000.000.000 wei. A taxa básica máxima e a taxa prioritária também são semelhantes. Portanto, podemos usar um formato decimal de ponto flutuante personalizado para representar a maioria dos valores monetários.
Quais são os links com a pesquisa existente?
O que mais precisa ser feito, quais são as considerações?
A seguir, o foco será na implementação prática da proposta acima. As principais considerações incluem:
Mudar para assinaturas BLS requer um grande esforço e reduzirá a compatibilidade com chips de hardware confiáveis. Alternativamente, pode-se usar pacotes ZK-SNARK com outros esquemas de assinatura.
Compressão dinâmica ( usar pointers para substituir endereços ) tornará o código do cliente mais complexo.
Publicar as diferenças de estado na cadeia em vez de transação, irá reduzir a auditabilidade, fazendo com que muitos softwares ( como exploradores de blocos ) não consigam funcionar.
Como interagir com as outras partes do roteiro?
Ao adotar o ERC-4337 e, por fim, integrar parte dele no EVM L2, é possível acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do ERC-4337 no L1 pode acelerar sua implementação no L2.
Plasma Generalizado
Que problema estamos a resolver?
Mesmo usando blobs de 16MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às demandas de alto consumo de largura de banda, como pagamentos de consumidores e redes sociais descentralizadas, especialmente considerando que fatores de privacidade podem reduzir a escalabilidade em 3 a 8 vezes. Atualmente, a escolha para cenários de alto volume de transações e baixo valor é o Validium, que armazena dados fora da cadeia, adotando um modelo de segurança: 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.
O que é isso, como funciona?
Plasma é uma solução de escalabilidade, onde os operadores publicam blocos fora da cadeia, colocando apenas a raiz Merkle desses blocos na cadeia. Para cada bloco, os operadores enviam a cada usuário uma prova Merkle que demonstra a alteração ou a imutabilidade dos ativos desse usuário. Os usuários podem retirar ativos fornecendo a prova Merkle. É importante notar que essa prova não precisa ter o estado mais recente como raiz. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar ativos extraindo o estado mais recente disponível. Se um usuário enviar uma prova inválida, a propriedade dos ativos pode ser determinada através do mecanismo de contestação na cadeia.
As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não conseguindo ser amplamente promovidas. Mas