- Tema
15751 Popularidade
2166 Popularidade
2795 Popularidade
41270 Popularidade
16144 Popularidade
59642 Popularidade
30113 Popularidade
2441 Popularidade
110853 Popularidade
26666 Popularidade
- Marcar
15751 Popularidade
2166 Popularidade
2795 Popularidade
41270 Popularidade
16144 Popularidade
59642 Popularidade
30113 Popularidade
2441 Popularidade
110853 Popularidade
26666 Popularidade
Ethereum A Visão do Surge: Superar 100.000 TPS e Unidade Ecológica
O futuro possível do Ethereum: The Surge
The Surge: Objetivos Chave
No futuro, o Ethereum poderá alcançar mais de 100.000 TPS através do L2;
Manter a descentralização e a robustez da L1;
Pelo menos algumas L2 herdam completamente as propriedades centrais do Ethereum (desconfiança, abertura, resistência à 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 é uma ideia proposta em 2017, que sugere que existe uma contradição entre três características da blockchain: descentralização (mais especificamente: baixo custo para operar nós), escalabilidade (grande número de transações processadas) e segurança (os atacantes precisam comprometer uma grande parte dos nós na rede para falhar em uma única transação).
É importante notar que a paradoxo triangular não é um teorema, e as postagens que introduzem a paradoxo triangular não incluem uma prova matemática. No entanto, ele apresenta 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 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 se descentralizará. O objetivo deste artigo não é provar que é impossível quebrar a paradoxo triangular; em vez disso, ele visa mostrar que quebrar a paradoxo ternária é difícil e requer, de certa forma, sair da estrutura de pensamento implícita naquele argumento.
Durante anos, algumas cadeias de alta performance afirmaram resolver o trilema da escalabilidade sem mudar fundamentalmente a arquitetura, geralmente otimizando os 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 irá explorar por que isso ocorre e por que a engenharia de software do cliente L1 por si só não consegue escalar o Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo 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 é executada corretamente, tudo isso 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 sutil modelo de confiança few-of-N, mas preserva as características fundamentais de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceitos pela rede.
Outra forma 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 uma maneira compatível com incentivos. Desde 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 não interativas de conhecimento zero), a arquitetura Plasma tornou-se mais viável para uma gama de cenários de uso mais ampla do que nunca.
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, haverá 3 blobs de cerca de 125 kB a cada slot de 12 segundos, 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, portanto, o máximo de TPS no Rollup será: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o calldata (valor máximo teórico: 30 milhões de Gas por slot / 16 gas por byte = 1.875.000 bytes por slot), isso se tornaria 607 TPS. Usando 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 L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é de 16 MB por slot, o que, combinado com melhorias na compressão de dados Rollup, trará ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples do "1D sampling". Em cada blob, é um polinômio de 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores avaliados em 16 coordenadas adjacentes dentre um total de 8192 coordenadas. Dentre esses 8192 valores avaliados, qualquer 4096 (de acordo com os parâmetros atualmente propostos: qualquer 64 dentre 128 amostras possíveis) pode ser usado para recuperar 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 os blobs necessários em outras sub-redes, perguntando a pares na rede p2p global (que escutarão diferentes sub-redes). A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem questionar a camada de pares adicional. A proposta atual é que os nós participantes do proof of stake utilizem o SubnetDAS, enquanto outros nós (ou seja, clientes) utilizem o PeerDAS.
Em teoria, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256 (com o objetivo de 128), conseguiremos atingir a meta de 16MB, onde cada nó em amostragem de disponibilidade de dados possui 16 amostras * 128 blobs * 512 bytes por blob por amostra = 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 ir mais longe e realizar a amostragem 2D (2D sampling), um método que não apenas realiza amostragem aleatória dentro de blobs, mas também entre blobs. Utilizando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco com um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
Assim, no final, queremos ir mais longe, realizando amostragem 2D, que não só é feita dentro do blob, mas também entre blobs de forma aleatória. 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 necessite de blobs, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos precisam apenas 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) também é essencialmente amigável à construção de blocos distribuídos.
O que mais precisa ser feito? Quais são as considerações?
A seguir está a implementação e o lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs na PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos mais trabalho académico para normalizar o PeerDAS e outras versões do DAS e a interação delas com questões de segurança relacionadas às regras de escolha de fork.
Em estágios futuros mais distantes, precisaremos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente poder passar de KZG para uma alternativa que seja segura contra quântica e que não exija configuração confiável. No momento, não está claro quais opções candidatas são amigáveis para a 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 reconstruir linhas e colunas, não é suficiente para atender à demanda, pois, embora tecnicamente, um STARK tenha tamanho O(log(n) * log(log(n)) hash (usando STIR), na prática, o STARK é quase do tamanho de todo o blob.
O caminho real a longo prazo que eu vejo é:
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 um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter uma maneira eficiente de validar 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 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 à reconstrução distribuída, na prática isso requer uma combinação com a proposta de lista de inclusão de pacotes e os mecanismos de escolha de bifurcação ao seu redor.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer aproximadamente 180 bytes. Mesmo com amostragem de disponibilidade de dados ideal, isso limita a escalabilidade do protocolo Layer. Cada slot tem 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
O que aconteceria se conseguíssemos resolver não apenas os problemas do numerador, mas também os problemas do denominador, fazendo com que cada transação em um Rollup ocupasse menos bytes na cadeia?
O que é isso, como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
Na compressão de zero bytes, substituímos cada sequência longa de zero bytes por dois bytes que indicam quantos zero bytes existem. Para ir além, 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. No nível 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 um ambiente L2, onde os dados são escassos, o uso de assinaturas BLS faz sentido. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.