A estratégia de escalabilidade do Ethereum tinha inicialmente duas abordagens: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma parte das transações, enquanto o Layer 2 constrói uma rede sobre o Ethereum. 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 simples de trabalho: Ethereum L1 foca em se tornar uma camada base poderosa e descentralizada, enquanto L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é amplamente presente na sociedade, como o sistema judicial (L1) que protege contratos e direitos de propriedade, e os empreendedores (L2) que constroem sobre essa base.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: os blobs do EIP-4844 aumentaram significativamente a largura de banda de dados do Ethereum L1, e múltiplos Rollups da Máquina Virtual Ethereum alcançaram a primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica, e a diversidade e pluralidade nas formas de implementação da partição tornaram-se realidade. Mas este 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
O futuro do Ethereum através do L2 pode alcançar mais de 100.000 TPS;
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.
Resumo do Conteúdo
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
Melhoria da interoperabilidade entre L2
Expandir a execução na L1
Paradoxo da Tríade da Escalabilidade
O paradoxo da escalabilidade sugere que existe uma contradição entre três características da blockchain: descentralização (, custo baixo dos nós de execução ), escalabilidade ( para processar um grande número de transações ) e segurança (, onde um atacante precisa comprometer uma grande proporção de nós para fazer uma única transação falhar ).
O paradoxo triangular não é um teorema, e a postagem que o apresenta não inclui uma prova matemática. Ele fornece um argumento heurístico: se nós temos nós amigáveis descentralizados que podem 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, um atacante só precisa comprometer alguns nós para realizar transações maliciosas, ou (ii) seus nós se tornarão mais poderosos, e a cadeia não será descentralizada. O artigo nunca pretende provar que quebrar o paradoxo triangular é impossível, mas sim mostrar que é difícil, exigindo sair do quadro de pensamento implícito dessa argumentação.
Durante anos, algumas cadeias de alto desempenho afirmaram ter resolvido o dilema trilema sem mudar fundamentalmente a arquitetura, geralmente otimizando nós através de técnicas de engenharia de software. Isso é sempre enganador, pois executar nós nessas cadeias é mais difícil do que no Ethereum. Este artigo irá explorar por que isso é assim e por que apenas a engenharia de software do cliente L1 não pode escalar o Ethereum.
No entanto, a amostragem de disponibilidade de dados combinada com SNARKs realmente resolve o paradoxo do triângulo: permite que os clientes baixem apenas uma pequena quantidade de dados e realizem poucos cálculos para verificar que uma certa quantidade de dados está disponível e que certos passos de cálculo foram executados corretamente. SNARKs não requerem confiança. A amostragem de disponibilidade de dados tem um modelo de confiança sutil de few-of-N, mas preserva as características fundamentais de uma cadeia não escalável, onde mesmo um ataque de 51% não pode forçar blocos ruins a serem aceites pela rede.
Outra forma de resolver o dilema dos três é a arquitetura Plasma, que habilmente transfere a responsabilidade pela verificação da disponibilidade dos dados para os usuários. De 2017 a 2019, quando tínhamos apenas provas de fraude para expandir a capacidade computacional, a Plasma tinha limitações na execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais 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?
Em 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 por slot, ou seja, a largura de banda de dados disponível por slot será 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, então o TPS máximo do Rollup na Ethereum será: 375000 / 12 / 180 = 173,6 TPS.
Adicionando o valor máximo teórico de calldata do Ethereum (: por slot 30 milhões de Gas / por byte 16 gas = por slot 1,875,000 bytes ), o que resulta em 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O objetivo a médio prazo é de 16 MB por slot, combinado com melhorias na compressão de dados Rollup, o que trará cerca de ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo de primos de 253 bits. Nós transmitimos as shares do polinômio, cada share 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 recuperar o blob com base nos parâmetros da proposta atual: qualquer 64 de 128 amostras possíveis ).
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e solicita a outros blobs em sub-redes diferentes perguntando aos pares da rede global p2p quem irá escutar as diferentes sub-redes (. A versão mais conservadora SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual permite que os nós de prova de participação utilizem o SubnetDAS, enquanto os outros nós ), ou seja, os clientes ( utilizam o PeerDAS.
Teoricamente, podemos escalar o "1D sampling" para um tamanho muito grande: se aumentarmos o número máximo de blobs para 256), com um alvo de 128(, podemos atingir um objetivo de 16MB, enquanto na amostragem de disponibilidade de dados, cada nó tem 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas no limite da tolerância: é viável, mas significa que 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 resultará em custos de reconstrução mais altos.
Portanto, queremos ir mais longe e realizar amostragem 2D, que não só amostra aleatoriamente dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos um conjunto de blobs em um bloco através de um novo conjunto de blobs virtuais, onde esses blobs virtuais codificam redundantemente as mesmas informações.
É importante notar que a expansão do compromisso de cálculo não requer um blob, portanto, este esquema é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas ter o compromisso KZG do blob, podendo confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional também é, essencialmente, amigável à construção de blocos distribuídos.
![Vitalik nova publicação: o futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.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 continuamente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, num processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho académico para normatizar o PeerDAS e outras versões do DAS e a sua interação com questões de segurança, como as regras de escolha de fork.
Em estágios mais avançados no futuro, precisamos de mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente transitar do KZG para alternativas que sejam seguras quânticamente e não exijam configurações de confiança. Neste momento, não está claro quais opções candidatas são amigáveis para a construção de blocos distribuídos. Mesmo utilizando a cara técnica de "força bruta", ou seja, usando STARK recursivos para gerar provas de validade para a reconstrução de linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho do STARK seja O###log(n( * log)log(n() hash ) usando STIR(, na prática, o STARK é quase do mesmo tamanho que o blob inteiro.
Eu acho que o caminho da realidade a longo prazo é:
Implementar um 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.
Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa opção 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 métodos eficientes para validar 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 realizada, a demanda por 2D DAS será reduzida ou, pelo menos, adiada. Se o Plasma for amplamente utilizado, a demanda será ainda mais reduzida. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS teoricamente seja amigável à reconstrução distribuída, na prática, isso precisa ser combinado com a proposta da lista de inclusão de pacotes e os mecanismos de seleção de forks ao seu redor.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compressão de Dados
) Que problema estamos a resolver?
Cada transação em Rollup ocupa uma grande quantidade de espaço de dados on-chain: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com amostragem de disponibilidade de dados ideal, isso limita a escalabilidade do protocolo Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos resolver não apenas os problemas do numerador, mas também os problemas do denominador, permitindo que cada transação em Rollup ocupe menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
Na compressão de zero bytes, usamos dois bytes para substituir cada sequência longa de zero bytes, indicando quantos zero bytes existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de Assinaturas: Mudamos 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. Na camada L1, devido ao alto custo computacional da verificação, mesmo com a agregação, não se considera o uso de assinaturas BLS. Mas em ambientes L2, onde os dados são escassos, o uso de assinaturas BLS faz sentido. A característica de agregação 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 de valores de transação personalizada: 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 de base máximas e as taxas de prioridade também são semelhantes. Portanto, podemos usar um formato decimal flutuante personalizado para representar a maioria dos valores monetários.
) ainda precisa fazer o quê, quais são as compensações?
A próxima etapa é implementar efetivamente a solução acima. As principais considerações incluem:
A transição para assinaturas BLS exige um grande esforço e diminuirá a compatibilidade com chips de hardware confiáveis que podem aumentar a segurança. É possível usar um encapsulamento ZK-SNARK com 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, fazendo com que muitos softwares ), como exploradores de blocos (, não funcionem.
) Como interagir com outras partes do roteiro?
Adotando o ERC-4337, e, finalmente, incorporando parte do seu conteúdo.
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.
24 gostos
Recompensa
24
6
Partilhar
Comentar
0/400
LongTermDreamer
· 07-22 01:04
Daqui a três anos, todos terão que olhar para a nossa cara L2. Acumular um pouco não é prejuízo.
Ver originalResponder0
alpha_leaker
· 07-19 10:23
Durante um bull run, é preciso usar L2 para ganhar dinheiro.
Ver originalResponder0
GasDevourer
· 07-19 01:26
Não percebi o L2, perdi as calças!
Ver originalResponder0
TrustlessMaximalist
· 07-19 01:21
Rollup é muito bom, entrar numa posição é o certo.
Ver originalResponder0
consensus_whisperer
· 07-19 01:11
Quando é que consegue alcançar 10k tps, diga-me com certeza.
Ver originalResponder0
GateUser-3824aa38
· 07-19 01:10
Continuamente, ainda é o Bitcoin que funciona melhor.
Caminho da escalabilidade do Ethereum: Análise do The Surge e perspectivas de desenvolvimento do L2
O futuro possível do Ethereum: The Surge
A estratégia de escalabilidade do Ethereum tinha inicialmente duas abordagens: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma parte das transações, enquanto o Layer 2 constrói uma rede sobre o Ethereum. 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 simples de trabalho: Ethereum L1 foca em se tornar uma camada base poderosa e descentralizada, enquanto L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é amplamente presente na sociedade, como o sistema judicial (L1) que protege contratos e direitos de propriedade, e os empreendedores (L2) que constroem sobre essa base.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: os blobs do EIP-4844 aumentaram significativamente a largura de banda de dados do Ethereum L1, e múltiplos Rollups da Máquina Virtual Ethereum alcançaram a primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica, e a diversidade e pluralidade nas formas de implementação da partição tornaram-se realidade. Mas este 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
Resumo do Conteúdo
Paradoxo da Tríade da Escalabilidade
O paradoxo da escalabilidade sugere que existe uma contradição entre três características da blockchain: descentralização (, custo baixo dos nós de execução ), escalabilidade ( para processar um grande número de transações ) e segurança (, onde um atacante precisa comprometer uma grande proporção de nós para fazer uma única transação falhar ).
O paradoxo triangular não é um teorema, e a postagem que o apresenta não inclui uma prova matemática. Ele fornece um argumento heurístico: se nós temos nós amigáveis descentralizados que podem 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, um atacante só precisa comprometer alguns nós para realizar transações maliciosas, ou (ii) seus nós se tornarão mais poderosos, e a cadeia não será descentralizada. O artigo nunca pretende provar que quebrar o paradoxo triangular é impossível, mas sim mostrar que é difícil, exigindo sair do quadro de pensamento implícito dessa argumentação.
Durante anos, algumas cadeias de alto desempenho afirmaram ter resolvido o dilema trilema sem mudar fundamentalmente a arquitetura, geralmente otimizando nós através de técnicas de engenharia de software. Isso é sempre enganador, pois executar nós nessas cadeias é mais difícil do que no Ethereum. Este artigo irá explorar por que isso é assim e por que apenas a engenharia de software do cliente L1 não pode escalar o Ethereum.
No entanto, a amostragem de disponibilidade de dados combinada com SNARKs realmente resolve o paradoxo do triângulo: permite que os clientes baixem apenas uma pequena quantidade de dados e realizem poucos cálculos para verificar que uma certa quantidade de dados está disponível e que certos passos de cálculo foram executados corretamente. SNARKs não requerem confiança. A amostragem de disponibilidade de dados tem um modelo de confiança sutil de few-of-N, mas preserva as características fundamentais de uma cadeia não escalável, onde mesmo um ataque de 51% não pode forçar blocos ruins a serem aceites pela rede.
Outra forma de resolver o dilema dos três é a arquitetura Plasma, que habilmente transfere a responsabilidade pela verificação da disponibilidade dos dados para os usuários. De 2017 a 2019, quando tínhamos apenas provas de fraude para expandir a capacidade computacional, a Plasma tinha limitações na execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais 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?
Em 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 por slot, ou seja, a largura de banda de dados disponível por slot será 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, então o TPS máximo do Rollup na Ethereum será: 375000 / 12 / 180 = 173,6 TPS.
Adicionando o valor máximo teórico de calldata do Ethereum (: por slot 30 milhões de Gas / por byte 16 gas = por slot 1,875,000 bytes ), o que resulta em 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O objetivo a médio prazo é de 16 MB por slot, combinado com melhorias na compressão de dados Rollup, o que trará cerca de ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo de primos de 253 bits. Nós transmitimos as shares do polinômio, cada share 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 recuperar o blob com base nos parâmetros da proposta atual: qualquer 64 de 128 amostras possíveis ).
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e solicita a outros blobs em sub-redes diferentes perguntando aos pares da rede global p2p quem irá escutar as diferentes sub-redes (. A versão mais conservadora SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual permite que os nós de prova de participação utilizem o SubnetDAS, enquanto os outros nós ), ou seja, os clientes ( utilizam o PeerDAS.
Teoricamente, podemos escalar o "1D sampling" para um tamanho muito grande: se aumentarmos o número máximo de blobs para 256), com um alvo de 128(, podemos atingir um objetivo de 16MB, enquanto na amostragem de disponibilidade de dados, cada nó tem 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas no limite da tolerância: é viável, mas significa que 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 resultará em custos de reconstrução mais altos.
Portanto, queremos ir mais longe e realizar amostragem 2D, que não só amostra aleatoriamente dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos um conjunto de blobs em um bloco através de um novo conjunto de blobs virtuais, onde esses blobs virtuais codificam redundantemente as mesmas informações.
É importante notar que a expansão do compromisso de cálculo não requer um blob, portanto, este esquema é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas ter o compromisso KZG do blob, podendo confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional também é, essencialmente, amigável à construção de blocos distribuídos.
![Vitalik nova publicação: o futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.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 continuamente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, num processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho académico para normatizar o PeerDAS e outras versões do DAS e a sua interação com questões de segurança, como as regras de escolha de fork.
Em estágios mais avançados no futuro, precisamos de mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente transitar do KZG para alternativas que sejam seguras quânticamente e não exijam configurações de confiança. Neste momento, não está claro quais opções candidatas são amigáveis para a construção de blocos distribuídos. Mesmo utilizando a cara técnica de "força bruta", ou seja, usando STARK recursivos para gerar provas de validade para a reconstrução de linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho do STARK seja O###log(n( * log)log(n() hash ) usando STIR(, na prática, o STARK é quase do mesmo tamanho que o blob inteiro.
Eu acho que o caminho da realidade a longo prazo é:
Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa opção 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 métodos eficientes para validar 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 realizada, a demanda por 2D DAS será reduzida ou, pelo menos, adiada. Se o Plasma for amplamente utilizado, a demanda será ainda mais reduzida. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS teoricamente seja amigável à reconstrução distribuída, na prática, isso precisa ser combinado com a proposta da lista de inclusão de pacotes e os mecanismos de seleção de forks ao seu redor.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compressão de Dados
) Que problema estamos a resolver?
Cada transação em Rollup ocupa uma grande quantidade de espaço de dados on-chain: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com amostragem de disponibilidade de dados ideal, isso limita a escalabilidade do protocolo Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos resolver não apenas os problemas do numerador, mas também os problemas do denominador, permitindo que cada transação em Rollup ocupe menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
Na compressão de zero bytes, usamos dois bytes para substituir cada sequência longa de zero bytes, indicando quantos zero bytes existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de Assinaturas: Mudamos 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. Na camada L1, devido ao alto custo computacional da verificação, mesmo com a agregação, não se considera o uso de assinaturas BLS. Mas em ambientes L2, onde os dados são escassos, o uso de assinaturas BLS faz sentido. A característica de agregação 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 de valores de transação personalizada: 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 de base máximas e as taxas de prioridade também são semelhantes. Portanto, podemos usar um formato decimal flutuante personalizado para representar a maioria dos valores monetários.
) ainda precisa fazer o quê, quais são as compensações?
A próxima etapa é implementar efetivamente a solução acima. As principais considerações incluem:
A transição para assinaturas BLS exige um grande esforço e diminuirá a compatibilidade com chips de hardware confiáveis que podem aumentar a segurança. É possível usar um encapsulamento ZK-SNARK com 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, fazendo com que muitos softwares ), como exploradores de blocos (, não funcionem.
) Como interagir com outras partes do roteiro?
Adotando o ERC-4337, e, finalmente, incorporando parte do seu conteúdo.