- Tema
41k Popularidade
20k Popularidade
33k Popularidade
31k Popularidade
4k Popularidade
97k Popularidade
29k Popularidade
27k Popularidade
7k Popularidade
18k Popularidade
- Marcar
41k Popularidade
20k Popularidade
33k Popularidade
31k Popularidade
4k Popularidade
97k Popularidade
29k Popularidade
27k Popularidade
7k Popularidade
18k Popularidade
Ethereum O roteiro da Surge: do Rollup ao caminho de escalabilidade de 100 mil TPS
O possível futuro 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ó valide e armazene apenas uma pequena parte das transações, enquanto o Layer2 constrói uma rede sobre o Ethereum, aproveitando sua segurança e mantendo 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 principal estratégia de escalabilidade do Ethereum.
O roteiro centrado em Rollup propõe uma divisão clara de tarefas: o Ethereum L1 foca em se tornar uma camada base poderosa e descentralizada, enquanto o L2 assume a responsabilidade de ajudar a expandir o ecossistema. Este modelo é comum na sociedade, semelhante ao sistema judicial (L1) que existe para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) inovam com base nisso.
Este ano, este roteiro fez progressos importantes: o lançamento dos blobs EIP-4844 aumentou significativamente a largura de banda de dados do Ethereum L1, e vários EVM Rollups já entraram na primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica, e a diversidade nas formas de implementação das partições tornou-se uma realidade. Mas este caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar o roteiro centrado em Rollup, resolver esses problemas, mantendo ao mesmo tempo a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos Chave
Conteúdo deste capítulo
Paradoxo da Escalabilidade
O paradoxo do triângulo da escalabilidade afirma que existe uma contradição entre a descentralização, escalabilidade e segurança das blockchains. Não é um teorema, mas indica que quebrar o paradoxo do triângulo é difícil e requer sair do pensamento estabelecido. Algumas cadeias de alto desempenho afirmam ter resolvido o paradoxo do triângulo, mas isso geralmente é enganoso, pois executar nós nessas cadeias é mais difícil do que na Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo triangular: permite que os clientes baixem apenas uma pequena quantidade de dados e realizem um número muito reduzido de cálculos para verificar a disponibilidade de uma grande quantidade de dados e a correção dos passos de cálculo. Os SNARKs não requerem confiança, enquanto a amostragem de disponibilidade de dados possui um sutil modelo de confiança few-of-N, mas mantém as características fundamentais das cadeias não escaláveis.
A arquitetura Plasma é outra solução que transfere a responsabilidade pela disponibilidade de dados aos usuários de uma forma incentivada. Com a popularização dos SNARKs, o Plasma torna-se viável para cenários de uso mais amplos.
Progresso adicional na amostragem de disponibilidade de dados
Estamos a resolver que problema?
Atualmente, o Ethereum tem 3 blobs de cerca de 125 kB a cada 12 segundos de slot, com uma largura de banda de dados disponível de cerca de 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 máximo TPS do Rollup no Ethereum é de 173,6. Juntando com calldata, pode chegar a 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, oferecendo 463-926 TPS para calldata.
Esta é uma melhoria significativa, mas ainda não é suficiente. O nosso objetivo intermédio é de 16 MB por slot, que combinado com as melhorias na compressão de dados Rollup, trará cerca de 58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus sobre um corpo de números primos de 253 bits. Transmitimos as ações do polinômio, onde cada ação contém 16 valores de avaliação nos 16 coordenadas adjacentes entre 8192 coordenadas. Qualquer 4096 valores de avaliação podem recuperar o blob.
PeerDAS permite que cada cliente escute uma pequena quantidade de sub-redes, a i-ésima sub-rede transmite qualquer blob do i-ésimo exemplo, e o cliente solicita blobs de outras sub-redes perguntando a pares na rede p2p global. SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual permite que os nós que participam da prova de participação utilizem SubnetDAS, enquanto outros nós utilizam PeerDAS.
Na teoria, podemos escalar o "1D sampling" a uma grande dimensão: se aumentarmos o número máximo de blobs para 256, podemos alcançar o objetivo de 16MB, enquanto cada nó precisa processar 1 MB de dados por slot. Isso é apenas viável, mas significa que os 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.
Assim, queremos finalmente realizar a amostragem 2D, não apenas dentro do blob, mas também amostrando aleatoriamente entre os blobs. Usando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam de forma redundante 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 só precisam ter a promessa KZG do blob e podem confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A DAS 1D também é essencialmente amigável para a construção de blocos distribuídos.
O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é concluir a implementação e 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. Também precisamos de mais trabalho acadêmico para normatizar o PeerDAS e suas interações com questões de segurança, como as regras de seleção de fork.
No futuro, precisamos determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também queremos mudar do KZG para uma alternativa segura quântica e sem configuração confiável, mas atualmente não está claro quais opções são amigáveis à construção de blocos distribuídos.
Eu acho que o caminho real a longo prazo é:
Mesmo que decidamos expandir a execução diretamente na camada L1, essa opção está disponível. Se a L1 tiver que processar uma grande quantidade de TPS, os blocos da L1 se tornarão muito grandes, e os clientes precisarão verificar sua correção de forma eficiente, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup.
Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por DAS 2D diminuirá ou será atrasada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável à reconstrução distribuída, na prática, isso precisa ser combinado com a proposta de lista de inclusão de pacotes e seu mecanismo de escolha de bifurcação ao redor.
Compressão de Dados
Que problema estamos resolvendo?
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 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 ocupe menos bytes na cadeia?
O que é isso, como funciona?
Na compressão de zeros, cada sequência longa de zeros é substituída por dois bytes, que representam quantos zeros existem. Além disso, aproveitamos propriedades específicas das transações:
Agregação de assinaturas: a mudança de assinaturas ECDSA para assinaturas BLS, as assinaturas BLS 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 assinaturas BLS não é considerado. Mas em L2, um ambiente com escassez de dados, o uso de assinaturas BLS faz sentido. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: se já utilizou um determinado endereço, 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 poucos dígitos, por exemplo, 0,25 ETH é representado como 250.000.000.000.000.000 wei. A taxa base 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.
O que mais precisa ser feito, quais são as compensações?
O principal a fazer a seguir é implementar na prática o plano acima mencionado. As principais considerações incluem:
Mudar para assinaturas BLS requer um grande esforço e diminuirá a compatibilidade com chips de hardware confiáveis. Pode-se utilizar encapsulamentos ZK-SNARK de outros esquemas de assinatura como alternativa.
Compressão dinâmica (, substituir endereços por pointers ) tornaria 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 ) deixem de funcionar.
Como interagir com as outras partes do roadmap?
A adoção do ERC-4337 e, em última instância, a inclusão de parte do seu conteúdo na EVM L2 pode 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
Estamos a resolver que problema?
Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às necessidades de pagamentos dos consumidores, redes sociais descentralizadas ou outras áreas de alta largura de banda, especialmente quando consideramos fatores de privacidade, o que pode reduzir a escalabilidade em 3 a 8 vezes. Para cenários de alta transação e baixo valor, uma das opções atuais é usar 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 temporária ou permanentemente todos os fundos dos usuários. Mas podemos fazer melhor.
O que é, como funciona?
Plasma é uma solução de escalabilidade, envolvendo operadores que publicam blocos fora da cadeia e colocam a raiz Merkle desses blocos na cadeia. Para cada bloco, o operador envia a cada usuário uma prova de ramificação Merkle que mostra a alteração ou a falta de alteração dos ativos desse usuário. Os usuários podem retirar ativos fornecendo a ramificação Merkle. É importante notar que essa ramificação não precisa ter a raiz no estado mais recente. Assim, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar ativos retirando o estado mais recente disponível. Se um usuário enviar uma ramificação inválida, a propriedade dos ativos pode ser determinada através de um mecanismo de desafio on-chain.
As versões iniciais do Plasma só podiam lidar com casos de pagamento, não conseguindo ser promovidas de forma eficaz. No entanto, se exigir que cada raiz seja verificada com SNARK, o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser muito simplificado, uma vez que excluímos a maioria das possíveis rotas de trapaça dos operadores. Ao mesmo tempo, isso abre novas rotas, permitindo que a tecnologia Plasma se expanda para uma gama mais ampla de classes de ativos. Por fim, na ausência de trapaça por parte dos operadores, os usuários podem retirar fundos imediatamente, sem precisar esperar uma semana pelo período de desafio.
Uma forma de criar uma cadeia Plasma EVM ( não é o único método ): usar ZK-SNARK para construir uma árvore UTXO paralela, refletindo as alterações de saldo feitas pelo EVM, e definir um mapeamento único do "mesmo token" em diferentes pontos no tempo. Então, pode-se construir a estrutura Plasma sobre isso.
Uma percepção chave é que o sistema Plasma não precisa ser perfeito. Mesmo que você só consiga proteger um subconjunto de ativos (, como apenas o passado.