O roteiro do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer 2. Esses dois caminhos 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: o Ethereum L1 se concentra em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a escalar o ecossistema.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e múltiplos 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 multiplicidade das formas de implementação dos fragmentos tornaram-se uma realidade. No entanto, este caminho também enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, enquanto mantemos a robustez e a descentralização características do Ethereum L1.
The Surge: Objetivos principais
O Ethereum no futuro pode 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, (, que são de confiança, abertos e resistentes à 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 afirma que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: custo baixo de operação dos nós ), escalabilidade (, grande quantidade de transações processadas ) e segurança (, onde um atacante precisa comprometer uma grande parte dos nós na rede para falhar em uma única transação ).
É importante notar que a paradoxalidade triangular não é um teorema, e as postagens que introduzem o paradoxo triangular não incluem prova matemática. No entanto, oferece um argumento matemático heurístico: se um nó amigável à descentralização (, por exemplo, um laptop de consumo ) 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 dos nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seu nó se tornará poderoso, enquanto sua cadeia não se descentralizará. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; ao contrário, visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Ao longo dos anos, algumas cadeias de alto desempenho afirmam frequentemente que resolveram o trilema sem alterar fundamentalmente a arquitetura, geralmente otimizando nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo discutirá por que isso acontece e por que a engenharia de software do cliente L1 por si só não pode escalar o Ethereum.
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 que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, mesmo baixando apenas uma pequena quantidade de dados e realizando muito poucos 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 que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceitos pela rede.
Uma outra maneira de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade de monitorar a disponibilidade de dados para os usuários de forma compatível com incentivos. Já em 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, a Plasma tinha limitações significativas na execução segura, mas com a popularização dos SNARKs(, provas zero-knowledge concisas e não interativas), a arquitetura Plasma tornou-se mais viável para um conjunto de casos de uso mais amplo do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
No dia 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 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 TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico de 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. Com 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 ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, e se combinado com melhorias na compressão de dados Rollup, isso trará ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 no 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. Desses 8192 valores de avaliação, qualquer 4096 ) pode ser recuperado de acordo com os parâmetros propostos atualmente: qualquer 64 entre 128 amostras possíveis (.
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, nas quais a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob, e solicita a outros nós no p2p global ) quem irá escutar diferentes sub-redes ( para requisitar os blobs que precisa nas outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é permitir que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto os outros nós ), ou clientes (, utilizem o PeerDAS.
Teoricamente, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256) com o 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 poderão 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 avançar ainda mais, realizando amostragem 2D)2D sampling(. Este método não apenas realiza amostragem aleatória dentro do blob, mas também entre blobs. Aproveitando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco por meio de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
Assim, no final, queremos ir mais além e realizar amostragens 2D, que não só ocorrem 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 com codificação redundante da mesma informação.
É 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 os blocos só precisam ter o compromisso KZG de blob, 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( é essencialmente também amigável à construção de blocos distribuídos.
![Vitalik novo artigo: o futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
) O que mais precisa ser feito? Quais são as compensações?
A seguir está a implementação e lançamento do PeerDAS. Depois, aumentar constantemente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e outras versões do DAS e sua interação com questões de segurança, como as regras de seleção de fork.
Em estágios mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do DAS 2D e provar suas propriedades de segurança. Também esperamos poder eventualmente passar do KZG para uma alternativa que seja segura contra quântica e que não necessite de configurações confiáveis. No momento, não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando a cara tecnologia de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para a reconstrução de linhas e colunas, não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log)n### * log(log(n)( hash ( usando STIR), na prática, o STARK é quase do mesmo tamanho que todo o blob.
Eu acredito 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, aceitando um limite de dados mais baixo em prol da simplicidade e robustez.
Abandonar o DA, aceitando completamente o Plasma como a nossa principal arquitetura Layer2 de foco.
Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda 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 uma maneira eficiente de verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup), como ZK-EVM e DAS(.
) 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: embora o DAS seja teoricamente amigável para reconstrução distribuída, na prática isso precisa ser combinado com a proposta da lista de inclusão de pacotes e seus mecanismos de escolha de bifurcação.
Compressão de dados
Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma quantidade significativa de espaço de dados na cadeia: 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 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudermos não apenas resolver o problema do numerador, mas também resolver o problema do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
O que é isso, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
Na compressão de zero bytes, dois bytes substituem cada sequência longa de zero bytes, indicando quantos zero bytes existem. Além disso, aproveitamos as transações.
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.
11 Curtidas
Recompensa
11
4
Compartilhar
Comentário
0/400
Ser_Liquidated
· 16h atrás
Abrir o que, armadilha? De qualquer forma, eu já estou dentro.
Ver originalResponder0
ThatsNotARugPull
· 23h atrás
Difícil de encontrar este artigo que não está a fazer promessas.
Ver originalResponder0
SellTheBounce
· 23h atrás
Outra onda de planos para fazer as pessoas de parvas. A história já nos ensinou que devemos vender.
Ver originalResponder0
SchroedingerAirdrop
· 23h atrás
Ainda está em rollup? Vendendo, vendendo e já não há.
Ethereum The Surge: O caminho e os desafios da 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 Layer 2. Esses dois caminhos 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: o Ethereum L1 se concentra em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a escalar o ecossistema.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e múltiplos 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 multiplicidade das formas de implementação dos fragmentos tornaram-se uma realidade. No entanto, este caminho também enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, enquanto mantemos a robustez e a descentralização características do Ethereum L1.
The Surge: Objetivos principais
O Ethereum no futuro pode 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, (, que são de confiança, abertos e resistentes à censura, );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste capítulo
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade afirma que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: custo baixo de operação dos nós ), escalabilidade (, grande quantidade de transações processadas ) e segurança (, onde um atacante precisa comprometer uma grande parte dos nós na rede para falhar em uma única transação ).
É importante notar que a paradoxalidade triangular não é um teorema, e as postagens que introduzem o paradoxo triangular não incluem prova matemática. No entanto, oferece um argumento matemático heurístico: se um nó amigável à descentralização (, por exemplo, um laptop de consumo ) 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 dos nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seu nó se tornará poderoso, enquanto sua cadeia não se descentralizará. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; ao contrário, visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Ao longo dos anos, algumas cadeias de alto desempenho afirmam frequentemente que resolveram o trilema sem alterar fundamentalmente a arquitetura, geralmente otimizando nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo discutirá por que isso acontece e por que a engenharia de software do cliente L1 por si só não pode escalar o Ethereum.
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 que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, mesmo baixando apenas uma pequena quantidade de dados e realizando muito poucos 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 que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceitos pela rede.
Uma outra maneira de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade de monitorar a disponibilidade de dados para os usuários de forma compatível com incentivos. Já em 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, a Plasma tinha limitações significativas na execução segura, mas com a popularização dos SNARKs(, provas zero-knowledge concisas e não interativas), a arquitetura Plasma tornou-se mais viável para um conjunto de casos de uso mais amplo do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos a resolver?
No dia 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 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 TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico de 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. Com 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 ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, e se combinado com melhorias na compressão de dados Rollup, isso trará ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 no 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. Desses 8192 valores de avaliação, qualquer 4096 ) pode ser recuperado de acordo com os parâmetros propostos atualmente: qualquer 64 entre 128 amostras possíveis (.
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, nas quais a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob, e solicita a outros nós no p2p global ) quem irá escutar diferentes sub-redes ( para requisitar os blobs que precisa nas outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é permitir que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto os outros nós ), ou clientes (, utilizem o PeerDAS.
Teoricamente, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256) com o 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 poderão 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 avançar ainda mais, realizando amostragem 2D)2D sampling(. Este método não apenas realiza amostragem aleatória dentro do blob, mas também entre blobs. Aproveitando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco por meio de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
Assim, no final, queremos ir mais além e realizar amostragens 2D, que não só ocorrem 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 com codificação redundante da mesma informação.
É 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 os blocos só precisam ter o compromisso KZG de blob, 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( é essencialmente também amigável à construção de blocos distribuídos.
![Vitalik novo artigo: o futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
) O que mais precisa ser feito? Quais são as compensações?
A seguir está a implementação e lançamento do PeerDAS. Depois, aumentar constantemente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e outras versões do DAS e sua interação com questões de segurança, como as regras de seleção de fork.
Em estágios mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do DAS 2D e provar suas propriedades de segurança. Também esperamos poder eventualmente passar do KZG para uma alternativa que seja segura contra quântica e que não necessite de configurações confiáveis. No momento, não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando a cara tecnologia de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para a reconstrução de linhas e colunas, não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log)n### * log(log(n)( hash ( usando STIR), na prática, o STARK é quase do mesmo tamanho que todo o blob.
Eu acredito 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 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 uma maneira eficiente de verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup), como ZK-EVM e DAS(.
) 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: embora o DAS seja teoricamente amigável para reconstrução distribuída, na prática isso precisa ser combinado com a proposta da lista de inclusão de pacotes e seus mecanismos de escolha de bifurcação.
Compressão de dados
Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma quantidade significativa de espaço de dados na cadeia: 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 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudermos não apenas resolver o problema do numerador, mas também resolver o problema do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
O que é isso, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
Na compressão de zero bytes, dois bytes substituem cada sequência longa de zero bytes, indicando quantos zero bytes existem. Além disso, aproveitamos as transações.