- Tópico
77k Popularidade
33k Popularidade
10k Popularidade
4k Popularidade
4k Popularidade
29k Popularidade
16k Popularidade
22k Popularidade
13k Popularidade
3k Popularidade
- Pino
77k Popularidade
33k Popularidade
10k Popularidade
4k Popularidade
4k Popularidade
29k Popularidade
16k Popularidade
22k Popularidade
13k Popularidade
3k Popularidade
Ethereum expansão novo capítulo: Análise Profundidade do roteiro The Surge
O futuro possível do Ethereum: The Surge
O roteiro do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer 2. Essas duas abordagens acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade atual do Ethereum.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o L1 do Ethereum foca em se tornar uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é comum na sociedade: a existência do sistema judiciário (L1) é para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) constroem sobre essa base, promovendo o desenvolvimento humano.
Este ano, o roteiro centrado em Rollup fez importantes progressos: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e vários Rollups da máquina virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica internas, e a diversidade e pluralidade na implementação de 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 que sã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 herdam completamente as propriedades centrais do Ethereum de forma a permitir confiança, abertura e 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 afirma que existe uma contradição entre três características da blockchain: descentralização ) o custo de operação dos nós é baixo ( escalabilidade ) o número de transações processadas é alto ( e segurança ) os atacantes precisam comprometer uma grande parte dos nós na rede para falhar uma única transação (.
![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
É importante notar que a paradoxalidade triangular não é um teorema, nem tem uma prova matemática. Ela apresenta um argumento matemático heurístico: se um nó amigável à descentralização 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( seus nós se tornarão poderosos, enquanto sua cadeia não se tornará descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é impossível; ao contrário, ele visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair do quadro de pensamento implícito por esse argumento.
Ao longo dos anos, algumas cadeias de alto desempenho afirmam frequentemente que resolveram o paradoxo tríplice sem mudar fundamentalmente a arquitetura, geralmente através da aplicação de 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 irá 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 o cliente verifique que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, baixando apenas uma quantidade mínima de dados e realizando um número muito limitado de cálculos. Os SNARKs são de confiança zero. 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 blocos ruins a serem aceitos pela rede.
Uma outra forma de resolver o dilema das três dificuldades é a arquitetura Plasma, que utiliza técnicas engenhosas para transferir a responsabilidade pela disponibilidade dos dados de monitorização para os utilizadores de uma forma compatível com incentivos. Entre 2017 e 2019, quando só tínhamos 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 zero-knowledge concisas e não interativas(, 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, a blockchain Ethereum terá 3 blobs de aproximadamente 125 kB a cada 12 segundos, ou uma largura de banda de dados disponível de cerca de 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 é de aproximadamente 180 bytes, portanto, o TPS máximo para Rollups na Ethereum será: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum ###: 30 milhões de Gas por slot / 16 gas por byte = 1.875.000 bytes por slot (, isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará entre 463-926 TPS para o calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, o que, combinado com melhorias na compressão de dados Rollup, resultará em ~58000 TPS.
![Vitalik nova publicação: Ethereum possível futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus no campo primo de 253 bits ###. Nós transmitimos as shares do polinômio, onde cada share contém 16 valores de avaliação em 16 coordenadas adjacentes a partir de um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 ( pode recuperar o blob com base nos parâmetros propostos atualmente: qualquer 64 de 128 possíveis amostras ).
O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, nas quais a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob, e solicita a outros nós da rede p2p global ( quem irá escutar diferentes sub-redes ) para obter os blobs adicionais que necessita. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto os outros nós (, ou seja, os clientes ), utilizem o PeerDAS.
Teoricamente, podemos escalar uma "amostragem 1D" bastante grande: se aumentarmos o número máximo de blobs para 256( com um alvo de 128), então podemos atingir a meta de 16MB, e a amostragem de disponibilidade de dados em cada nó terá 16 amostras * 128 blobs * 512 bytes por amostra de cada 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 e realizar a amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre 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 redundante as mesmas informações.
Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não apenas amostra aleatoriamente dentro do blob, mas também entre blobs. A propriedade linear do compromisso KZG é usada para expandir um conjunto de blobs em um bloco, que contém uma nova lista de blobs virtuais codificados de forma redundante com as mesmas informações.
É 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 apenas precisam ter o compromisso KZG do blob, e podem confiar na amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade do bloco de dados. A amostragem de disponibilidade de dados unidimensional (1D DAS) é essencialmente também amigável à construção de blocos distribuídos.
( O que mais precisa ser feito? Que trade-offs existem?
A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, ao mesmo tempo que observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como a interação com questões de segurança relacionadas às regras de escolha de forks.
Em estágios 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 ser capazes de eventualmente transitar do KZG para uma alternativa que seja segura quântica e que não exija um setup confiável. Atualmente, ainda não está claro quais candidatos são amigáveis para a construção de blocos distribuídos. Mesmo usando a cara técnica 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 o tamanho de um STARK seja O)log(n) * log###log(n() hash ( usando STIR(, na prática, o STARK é quase do tamanho de todo o blob.
Eu acredito que o caminho da realidade a longo prazo é:
Por favor, note que, mesmo que decidamos expandir a execução diretamente no nível L1, essa opção ainda existe. Isso se deve ao fato de que, se o nível L1 tiver que processar um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão uma maneira eficiente de verificar sua correção; portanto, teremos que usar no nível L1 as mesmas tecnologias que o Rollup), como ZK-EVM e DAS).
( Como interagir com as outras partes do roteiro?
Se a compressão de dados for realizada, a demanda por 2D DAS 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 teoricamente seja 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 fork circundante.
Compressão de Dados
) Que problema estamos a resolver?
Cada transação no Rollup ocupa uma grande quantidade de espaço de dados na cadeia: a transferência ERC20 requer cerca de 180 bytes. Mesmo com uma amostragem de disponibilidade de dados ideal, isso limita a escalabilidade dos protocolos Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se pudermos resolver não apenas o problema dos numeradores, mas também o problema dos denominadores, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?
O que é isso e como funciona?
Na minha opinião, a melhor explicação é esta imagem de há dois anos:
Na compressão de zero bytes, cada sequência longa de zero bytes é substituída por dois 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 da verificação, mesmo com a agregação, não consideramos o uso de assinaturas BLS.