No roteiro do Ethereum, inicialmente havia 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 foca em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir 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 vários Rollups da Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como um "shard" com suas próprias regras e lógica internas, e a diversidade e a pluralidade das implementações de shards tornaram-se uma realidade. No entanto, esse caminho também enfrenta alguns desafios únicos. 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 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.
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: baixo custo de operação dos nós ), escalabilidade (, número elevado de transações processadas ) e segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para falhar uma única transação ).
É importante notar que a paradoxo triangular não é um teorema, e as postagens que apresentam o paradoxo triangular não incluem uma prova matemática. De fato, apresenta um argumento matemático heurístico: se um nó amigável à descentralização (, por exemplo, um laptop de consumo ), pode verificar 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 nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não estará descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; em vez disso, visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Durante anos, algumas cadeias de alto desempenho afirmaram que resolveram o trilema sem alterar fundamentalmente a arquitetura, geralmente aplicando técnicas de engenharia de software para otimizar os nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo explorará por que isso acontece e por que apenas a engenharia de software do cliente L1 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 passos computacionais foi executada corretamente, tudo isso baixando apenas uma quantidade mínima de dados e realizando muito poucos cálculos. Os SNARKs são sem 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 básicas que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema dos três é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade de monitorizar a disponibilidade de dados para os utilizadores de uma forma compatível com incentivos. Já em 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, o Plasma tinha limitações significativas na execução segura, mas com a popularização dos SNARKs(, provas de conhecimento zero concisas e não interativas), a arquitetura Plasma tornou-se mais viável para uma gama mais ampla de cenários de uso do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos resolvendo?
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 de slot, 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 máximo de TPS do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do 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. Usando 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, que, se combinado com melhorias na compressão de dados Rollup, trará ~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 o campo primo de 253 bits (. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação nas 16 coordenadas adjacentes de um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 ) podem ser recuperados com base nos parâmetros propostos atualmente: qualquer 64 de 128 amostras possíveis ( podem restaurar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob e solicita, perguntando a pares na rede p2p global quem irá escutar diferentes sub-redes ), os blobs necessários em outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares. A proposta atual é que os nós que participam da prova de participação usem o SubnetDAS, enquanto outros nós (, ou seja, 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 alcançar a meta de 16 MB, e a amostragem de disponibilidade de dados em cada nó é 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 significa que clientes com largura de banda limitada não podem 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 e realizar a amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um novo conjunto de blobs virtuais, que codificam redundantemente as mesmas informações.
Portanto, no final, queremos ir mais longe e realizar amostragens 2D, que não só ocorrem dentro do blob, mas também entre os blobs de forma aleatória. As propriedades lineares do compromisso KZG são usadas para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais com codificação redundante das mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, essa proposta é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos só precisam ter o compromisso KZG do 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) também é essencialmente amigável à construção de blocos distribuídos.
( O que mais precisa ser feito? Quais são as concessões?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de seleção de bifurcação.
Em fases mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos finalmente conseguir fazer a transição de KZG para uma alternativa que seja segura contra quântica e não exija uma configuração de confiança. No momento, não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos. Mesmo utilizando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O)log(n) * log###log(n() valor hash ( usando STIR(, na prática, o STARK é quase do tamanho de todo o blob.
O caminho da realidade a longo prazo que eu acho que é:
Implementar o DAS 2D ideal;
Manter o uso de 1D DAS, sacrificando a eficiência da largura de banda de amostragem, aceitando limites de dados mais baixos em prol da simplicidade e robustez.
Abandonar o DA e aceitar totalmente o Plasma como a nossa principal arquitetura Layer2 em 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 um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que Rollup), como ZK-EVM e DAS).
( Como interagir com outras partes do roteiro?
Se a compressão de dados for realizada, a necessidade de DAS 2D diminuirá, ou pelo menos será adiada, e se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também desafia 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 seus mecanismos de escolha de fork ao redor.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Compressão de Dados
) Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade 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 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 é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
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, que pode provar a validade de todas as assinaturas originais. Na camada L1, devido ao alto custo computacional de validação mesmo após a agregação, a utilização de assinaturas BLS não é considerada. Mas em ambientes L2, onde os dados são escassos, usar assinaturas BLS faz sentido. A característica de agregação do ERC-4337 oferece um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: Se já utilizou um determinado endereço anteriormente, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma determinada posição no histórico.
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.
19 Curtidas
Recompensa
19
9
Compartilhar
Comentário
0/400
HashBard
· 07-19 15:02
ser... rollups são como poesia em movimento fr fr. em alta nesta narrativa de alta repentina ngl
Ver originalResponder0
FUDwatcher
· 07-19 07:32
Finalmente podemos ter gás barato.
Ver originalResponder0
MemeCurator
· 07-17 19:11
Esta onda de l2 vai até à lua novamente.
Ver originalResponder0
ImpermanentPhobia
· 07-17 03:56
v确实猛 L2Até à lua了属于是
Ver originalResponder0
DAOdreamer
· 07-17 03:56
Rollup chegou e ainda não vai até à lua?
Ver originalResponder0
GateUser-5854de8b
· 07-17 03:54
Este v irmão lançou algo novo novamente.
Ver originalResponder0
SelfRugger
· 07-17 03:53
v神 insistiu em seguir l2 e realmente estava certo!
Ethereum The Surge: Nova estratégia de escalonamento centrada em Rollup
O futuro possível do Ethereum: The Surge
No roteiro do Ethereum, inicialmente havia 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 foca em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir 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 vários Rollups da Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como um "shard" com suas próprias regras e lógica internas, e a diversidade e a pluralidade das implementações de shards tornaram-se uma realidade. No entanto, esse caminho também enfrenta alguns desafios únicos. 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 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.
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: baixo custo de operação dos nós ), escalabilidade (, número elevado de transações processadas ) e segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para falhar uma única transação ).
É importante notar que a paradoxo triangular não é um teorema, e as postagens que apresentam o paradoxo triangular não incluem uma prova matemática. De fato, apresenta um argumento matemático heurístico: se um nó amigável à descentralização (, por exemplo, um laptop de consumo ), pode verificar 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 nós, o que significa que um atacante só precisa comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não estará descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; em vez disso, visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.
Durante anos, algumas cadeias de alto desempenho afirmaram que resolveram o trilema sem alterar fundamentalmente a arquitetura, geralmente aplicando técnicas de engenharia de software para otimizar os nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo explorará por que isso acontece e por que apenas a engenharia de software do cliente L1 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 passos computacionais foi executada corretamente, tudo isso baixando apenas uma quantidade mínima de dados e realizando muito poucos cálculos. Os SNARKs são sem 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 básicas que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema dos três é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade de monitorizar a disponibilidade de dados para os utilizadores de uma forma compatível com incentivos. Já em 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, o Plasma tinha limitações significativas na execução segura, mas com a popularização dos SNARKs(, provas de conhecimento zero concisas e não interativas), a arquitetura Plasma tornou-se mais viável para uma gama mais ampla de cenários de uso do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Que problema estamos resolvendo?
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 de slot, 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 máximo de TPS do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do 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. Usando 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, que, se combinado com melhorias na compressão de dados Rollup, trará ~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 o campo primo de 253 bits (. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação nas 16 coordenadas adjacentes de um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 ) podem ser recuperados com base nos parâmetros propostos atualmente: qualquer 64 de 128 amostras possíveis ( podem restaurar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob e solicita, perguntando a pares na rede p2p global quem irá escutar diferentes sub-redes ), os blobs necessários em outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares. A proposta atual é que os nós que participam da prova de participação usem o SubnetDAS, enquanto outros nós (, ou seja, 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 alcançar a meta de 16 MB, e a amostragem de disponibilidade de dados em cada nó é 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 significa que clientes com largura de banda limitada não podem 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 e realizar a amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um novo conjunto de blobs virtuais, que codificam redundantemente as mesmas informações.
Portanto, no final, queremos ir mais longe e realizar amostragens 2D, que não só ocorrem dentro do blob, mas também entre os blobs de forma aleatória. As propriedades lineares do compromisso KZG são usadas para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais com codificação redundante das mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, essa proposta é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos só precisam ter o compromisso KZG do 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) também é essencialmente amigável à construção de blocos distribuídos.
( O que mais precisa ser feito? Quais são as concessões?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de seleção de bifurcação.
Em fases mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos finalmente conseguir fazer a transição de KZG para uma alternativa que seja segura contra quântica e não exija uma configuração de confiança. No momento, não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos. Mesmo utilizando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O)log(n) * log###log(n() valor hash ( usando STIR(, na prática, o STARK é quase do tamanho de todo o blob.
O caminho da realidade a longo prazo que eu acho que é:
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 um método eficiente para verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que Rollup), como ZK-EVM e DAS).
( Como interagir com outras partes do roteiro?
Se a compressão de dados for realizada, a necessidade de DAS 2D diminuirá, ou pelo menos será adiada, e se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também desafia 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 seus mecanismos de escolha de fork ao redor.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Compressão de Dados
) Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade 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 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 é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
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, que pode provar a validade de todas as assinaturas originais. Na camada L1, devido ao alto custo computacional de validação mesmo após a agregação, a utilização de assinaturas BLS não é considerada. Mas em ambientes L2, onde os dados são escassos, usar assinaturas BLS faz sentido. A característica de agregação do ERC-4337 oferece um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: Se já utilizou um determinado endereço anteriormente, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma determinada posição no histórico.
Sequência personalizada do valor da transação