A expansão sempre foi um dos temas que não podem ser evitados pelo Ethereum. Se o Ethereum quiser se tornar um verdadeiro “computador mundial”, ele precisa ter escalabilidade, segurança e descentralização ao mesmo tempo. O tempo é conhecido na indústria como O “Triângulo Impossível do Blockchain” é um grande problema que não foi resolvido em toda a indústria.

No entanto, no final de 2021, o pesquisador e desenvolvedor Ethereum Dankrad Feist propôs Danksharding, uma nova solução de sharding para Ethereum, que parece ter trazido uma solução revolucionária para o “triângulo impossível do blockchain” e pode até reescrever todas as regras do jogo. .

Este relatório de pesquisa tentará explicar em linguagem simples o que é a nova solução de fragmentação do Ethereum, Danksharding, e suas origens. A razão pela qual escrevi este relatório de pesquisa é que há muito poucos artigos chineses sobre Danksharding e a maioria deles requer um alto limiar de conhecimento. Portanto, Spinach tentará decompor os princípios complexos por trás dele para você, e usará vernáculo simples para fazer um iniciante em Web3 entender a nova solução de sharding da Ethereum, Danksharding, e sua solução predecessora EIP-4844.

Autor: Espinafre Espinafre

Contagem de palavras: Este relatório de pesquisa tem mais de 10.000 palavras e o tempo estimado de leitura é de 21 minutos

Índice

  • Por que o Ethereum precisa se expandir?

    • Histórico de dimensionamento do Ethereum

    • O que é o triângulo impossível do blockchain?

    • Quais são as soluções de dimensionamento atuais para Ethereum?

  • Solução de fragmentação inicial do Ethereum Sharding 1.0

    • Como funciona o mecanismo de consenso POS do Ethereum?

    • Qual é a solução de fragmentação inicial Sharding1.0?

    • Quais são as desvantagens da solução de fragmentação inicial Sharding1.0?

  • O que é a nova solução de sharding do Ethereum, Danksharding?

    • Solução preliminar EIP-4844: Proto-Danksharding — Novo tipo de transação Blob

    • Danksharding — Solução de dimensionamento completa

      • Amostragem de disponibilidade de dados

      • Codificação de apagamento

      • Compromisso KZG

      • Separação Proponente/Construtor

      • Lista de resistentes à censura (crList)

      • 双槽 PBS (Separação de dois slots do proponente-construtor)

  • Resumir

  • Referências

Por que o Ethereum precisa se expandir?

Depois que o fundador da Ethereum, Vitalik Buterin, publicou o white paper da Ethereum “A próxima geração de contratos inteligentes e plataforma de aplicativos descentralizados” em 2014, o blockchain inaugurou uma nova era. O nascimento dos contratos inteligentes permite que as pessoas criem aplicativos descentralizados (DApps) no Ethereum e também traz uma série de inovações ao ecossistema blockchain, como NFT, DeFi, GameFi, etc.

Histórico de dimensionamento do Ethereum

À medida que o ecossistema da cadeia Ethereum cresce, mais e mais pessoas começam a usar o Ethereum, e os problemas de desempenho do Ethereum começam a ser expostos. Quando muitas pessoas interagem no Ethereum ao mesmo tempo, o blockchain ficará "congestionado", assim como o tempo do semáforo em uma estrada é fixo, e um certo número de veículos não causará engarrafamentos, mas de repente muitos carros estão dirigindo em direção a esta estrada durante a hora do rush, e o número de veículos saindo da estrada quando o semáforo está verde é muito menor do que o número de novos veículos entrando na estrada esperando o semáforo, o que causará um grande congestionamento, e o tempo para todos os veículos passarem por esta estrada será estendido. O mesmo é verdade no blockchain, e o tempo de confirmação para as solicitações de interação de todos será estendido.

Mas no blockchain, não é apenas o tempo que é prolongado, mas também as altas taxas de Gas (as taxas de Gas podem ser entendidas como a taxa de trabalho duro paga aos mineradores, que são responsáveis ​​por empacotar e processar todas as transações no blockchain). Como os mineradores darão prioridade às transações com os lances mais altos, isso fará com que todos aumentem a taxa de Gas para obter uma confirmação mais rápida das solicitações de interação, desencadeando uma "Guerra do Gas". Um incidente bem conhecido foi a explosão de popularidade do CryptoKitties, um projeto NFT em 2017, que empurrou a taxa de gás para várias centenas de dólares por interação. É muito caro gastar dezenas ou mesmo centenas de dólares em taxas de gás para uma interação no Ethereum.

O principal motivo para taxas de gás tão caras é que o desempenho do Ethereum não consegue mais atender às necessidades de interação dos usuários existentes. Em termos de cálculo de desempenho, o Ethereum é diferente do Bitcoin. Como o Bitcoin é apenas um livro-razão simples que processa informações de transferência, seu TPS é fixado em 7 transações por segundo, mas é diferente no Ethereum.

Devido à existência de contratos inteligentes no Ethereum, o conteúdo de cada transação é diferente, então quantas transações cada bloco pode processar (TPS) depende da quantidade de dados contidos em um bloco. A quantidade de dados para cada transação é determinada de acordo com a demanda em tempo real. Podemos aprender sobre o mecanismo de desempenho do Ethereum: (As informações a seguir são úteis para entender o Danksharding, certifique-se de lê-las~)

  • O Ethereum define o limite superior da quantidade de dados em um bloco de acordo com a taxa de gás. Um bloco pode carregar no máximo 30 milhões de GAS de dados.

  • O Ethereum não quer que a quantidade de dados em cada bloco seja muito grande, então cada bloco tem uma meta de gás de 15 milhões de gás.

  • O Ethereum tem um conjunto de padrões de consumo de dados para Gas. Diferentes tipos de dados consomem diferentes quantidades de Gas. No entanto, de acordo com nossas estimativas, cada bloco tem cerca de 5kb a 160kb de tamanho, e o tamanho médio de um bloco é de cerca de 60 a 70kb.

  • Uma vez que o consumo de gás de um bloco exceda a meta de gás, que é 15 milhões de gás, a taxa básica do próximo bloco será 12,5% mais cara. Se for menor, a taxa básica será reduzida. Este mecanismo é um mecanismo de ajuste dinâmico automatizado que pode aumentar o custo para aliviar o congestionamento durante os horários de pico de negociação e reduzir o custo para atrair mais transações durante os horários de baixa negociação.

Ao entender o mecanismo acima, podemos saber que o TPS do Ethereum é flutuante. **Podemos usar o navegador de blockchain para ver o número de transações em cada bloco para calcular o TPS aproximado. De acordo com a figura abaixo, podemos ver que, em média, há cerca de 160 transações em um bloco com base no Gas Target, e o mais alto pode atingir mais de 300 transações. Com base no tempo de bloco de 12 segundos para cada bloco, o TPS é de aproximadamente 13 a 30 transações, mas de acordo com o conhecimento atual, o TPS do Ethereum pode atingir até 45 transações por segundo.

图源：Mainnet | Beacon Chain Explorer (Fase 0) para Ethereum 2.0 – BeaconScan

Se pegarmos o mundialmente famoso sistema de transações VISA, que pode processar dezenas de milhares de transações por segundo, o Ethereum, que quer se tornar o "computador do mundo", só consegue processar no máximo 45 transações por segundo, o que é muito fraco. Portanto, o Ethereum precisa urgentemente expandir sua capacidade de resolver problemas de desempenho, o que está relacionado ao futuro do Ethereum, mas a expansão não é uma tarefa fácil porque existe um "triângulo impossível" na indústria de blockchain.

O que é o triângulo impossível do blockchain?

O "Triângulo Impossível do Blockchain" se refere ao fato de que um blockchain público não pode atender simultaneamente a três características: descentralização, segurança e escalabilidade.

  • Descentralização: refere-se ao grau de descentralização dos nós. Quanto mais nós houver, mais descentralizados eles serão.

  • Segurança: refere-se à segurança de toda a rede blockchain. Quanto maior o custo do ataque, mais seguro ele é.

  • Escalabilidade: refere-se ao desempenho do blockchain no processamento de transações. Quanto mais transações podem ser processadas por segundo, mais escalável ele é.

Se olharmos para a importância desses três pontos, descobriremos que a descentralização e a segurança têm os maiores pesos. A descentralização é a pedra angular do Ethereum. É a descentralização que dá ao Ethereum neutralidade, resistência à censura, abertura, propriedade de dados e segurança quase inquebrável. A importância da segurança é autoevidente, mas a visão do Ethereum é atingir a escalabilidade, mantendo a descentralização e a segurança. A dificuldade de atingir isso pode ser imaginada, então isso também é chamado de “triângulo impossível do blockchain”.

Fonte da imagem: Ethereum Vision | ethereum.org

Quais são as soluções de dimensionamento atuais para Ethereum?

Sabemos que no "Blockchain Impossible Triangle", a premissa para o Ethereum atingir a expansão é garantir a descentralização e a segurança. Para garantir a descentralização e a segurança, os requisitos de capacidade para nós não devem ser aumentados muito durante a expansão. Como os nós são um papel indispensável na manutenção de toda a rede Ethereum, nós de alta exigência impedirão que mais pessoas se tornem nós e a tornarão cada vez mais centralizada. Claro, quanto menor o limite para nós, melhor. Nós de baixo limite permitirão que mais pessoas participem e tornarão o Ethereum mais descentralizado e seguro.

Atualmente, há dois planos de expansão para Ethereum: Layer 2 e Sharding. Layer 2 é uma solução off-chain para expandir o blockchain subjacente (Layer 1). O princípio é executar solicitações no blockchain off-chain. Existem várias soluções Layer2. Este relatório de pesquisa foca apenas em uma solução Layer2, que é Rollup: O princípio do Rollup é empacotar centenas de transações em uma transação como panquecas off-chain e enviá-las para Ethereum para atingir a expansão de capacidade. Dessa forma, o custo de upload do Ethereum para todos será muito barato, ao mesmo tempo em que herda a segurança do Ethereum.

Rollup é atualmente dividido em dois tipos: Optimism Rollup e ZK Rollup (Rollup de prova de conhecimento zero). A diferença entre esses dois Rollups é simplesmente que o Optimism Rollup assume que todas as transações são honestas e confiáveis, comprime muitas transações em uma transação e as envia para o Ethereum. Após o envio, haverá um período de tempo (período de desafio - atualmente uma semana), e qualquer um pode questionar e iniciar um desafio para verificar a autenticidade da transação. No entanto, se o usuário quiser transferir ETH no OP Rollup para o Ethereum, ele precisa esperar até que o período de desafio termine antes de obter a confirmação final.

O ZK Rollup gera uma prova de conhecimento zero para provar que todas as transações são válidas e carrega as alterações de estado final após todas as transações serem executadas no Ethereum. Comparado com o Optimism Rollup, o ZK Rollup é mais promissor. O ZK Rollup não precisa carregar todos os detalhes da transação compactados como o Optimism Rollup. Ele só precisa carregar uma prova de conhecimento zero e os dados finais de mudança de estado. Isso significa que ele pode compactar mais dados do que o OP Rollup em termos de escalabilidade, e não há necessidade de esperar por um período de desafio de uma semana como o OP Rollup. No entanto, a maior desvantagem do ZK Rollup é que ele é extremamente difícil de desenvolver, então, no curto prazo, o Optimism Rollup ocupará um grande mercado L2.

Além do Layer2, há outra solução de expansão, que é o Sharding, o protagonista deste artigo. Sabemos que o Layer2 coloca transações no Ethereum off-chain para processamento. Mas não importa como a Layer2 processa os dados, o desempenho do Ethereum em si permanece inalterado, então o efeito de expansão que a Layer2 pode alcançar não é tão significativo.

O objetivo do sharding é alcançar a expansão no nível da Camada 1 do Ethereum, mas sabemos que a premissa de alcançar a expansão no Ethereum é garantir a descentralização e a segurança do Ethereum, então não podemos aumentar muito a carga sobre os nós.

O plano de implementação específico do sharding sempre foi um tópico de discussão na comunidade Ethereum. O plano mais recente é o Danksharding, o assunto deste artigo. Também é mencionado que o Danksharding é o plano de sharding mais recente. Antes de falar sobre o Danksharding, também apresentaremos brevemente como é o antigo plano de sharding e por que ele não foi adotado.

Solução de fragmentação inicial do Ethereum Sharding 1.0

Antes de falar sobre a solução Sharding 1.0, preciso primeiro apresentar como o mecanismo de consenso POS atual do Ethereum funciona, porque esse é o conhecimento pré-requisito necessário para entender a solução Sharding 1.0 e o Danksharding. Vou resumir brevemente quando falar sobre a solução Sharding 1.0 (basta saber o que fazer aproximadamente).

Como funciona o mecanismo de consenso POS do Ethereum? [7]

O mecanismo de consenso é um sistema que permite que todos os nós no blockchain que mantêm a rede cheguem a um consenso. Sua importância é autoevidente. Em 15 de setembro de 2022, o Ethereum concluiu "The Merge" na fase de atualização do Ethereum 2.0, ou seja, a mainnet Ethereum de prova de trabalho POW e a cadeia de beacon do mecanismo de prova de participação POS foram mescladas. O mecanismo de prova de participação POS substituiu oficialmente o mecanismo de prova de trabalho POW e se tornou o mecanismo de consenso do Ethereum.

Sabemos que no mecanismo de prova de trabalho POW, os mineradores competem pelo direito de produzir blocos empilhando seu poder de computação. No mecanismo de prova de participação POS, os mineradores competem pelo direito de produzir blocos em staking de 32 ETH para se tornarem nós de verificação do Ethereum (o método de staking não será introduzido em detalhes aqui).

Além das mudanças no mecanismo de consenso, o tempo de bloco do Ethereum também mudou do tempo de bloco flutuante anterior para um tempo fixo, que é dividido em duas unidades: slot e época: o slot tem 12 segundos e a época tem 6,4 minutos. Uma Epoch contém 32 slots. Em termos simples, um bloco é produzido a cada 12 segundos, e 32 blocos são produzidos em 6,4 minutos como um ciclo (Epoch).

Quando um minerador promete 32 ETH para se tornar um nó de verificação, a cadeia de beacon usará um algoritmo aleatório para selecionar um nó de verificação como um nó produtor de blocos para empacotar blocos. Um nó produtor de blocos será selecionado aleatoriamente para cada bloco. Ao mesmo tempo, em cada Época, a cadeia de beacons atribuirá de forma uniforme e aleatória todos os nós de verificação a um grupo de "Comitês" composto por pelo menos 128 nós de verificação para cada bloco.

Ou seja, cada bloco receberá 1/32 do número de nós de verificação de todos os nós, e os "Comitês" compostos por esses nós de verificação precisam verificar e votar nos blocos empacotados por cada nó produtor de blocos. Quando o nó produtor do bloco empacota o bloco, o bloco pode ser produzido com sucesso se mais de dois terços dos nós de verificação votarem a favor.

Qual é a solução de fragmentação inicial Sharding1.0? [7]

No conceito de design da solução de fragmentação inicial Sharding1.0, o Ethereum foi projetado a partir da cadeia principal original para um máximo de 64 cadeias de fragmentos, e a expansão foi alcançada pela adição de várias novas cadeias. Neste esquema, cada cadeia de shard é responsável por processar dados do Ethereum e entregá-los à cadeia de beacon, que é responsável por coordenar todo o Ethereum. Os nós de bloco e comitês de cada cadeia de shard são atribuídos aleatoriamente pela cadeia de beacon.

A cadeia de beacon e a cadeia de shard são vinculadas por meio de crosslinks. O bloco da cadeia de beacon dará um valor hash ao bloco de shard do mesmo bloco e, então, o bloco de shard dará esse valor hash ao próximo bloco de beacon para obter crosslinks. Se for perdido, será dado ao próximo bloco de beacon.

Quais são as desvantagens da solução de fragmentação inicial Sharding1.0?

Simplificando, a solução do Sharding 1.0 é dividir o Ethereum em muitas cadeias de fragmentos para processar dados juntos e então entregar os dados para a cadeia de beacon para alcançar a expansão, mas essa solução tem muitas desvantagens:

**Dificuldades de desenvolvimento: **Dividir o Ethereum em 64 cadeias de shards e, ao mesmo tempo, garantir a operação normal é tecnicamente muito difícil de ser alcançado, e quanto mais complexo o sistema, maior a probabilidade de ter algumas vulnerabilidades imprevisíveis. Uma vez que um problema ocorra, causará muitos problemas para repará-lo.

**Problema de sincronização de dados: **A cadeia de beacons reorganizará os "comitês" responsáveis ​​pela verificação a cada Época. Portanto, cada realocação de nós de verificação é uma sincronização de dados de rede em larga escala, porque se um nó for atribuído a uma nova cadeia de shard, ele precisa sincronizar os dados dessa cadeia de shard. Como a largura de banda de desempenho dos nós varia, é difícil garantir que a sincronização possa ser concluída dentro do tempo especificado. No entanto, se os nós tiverem permissão para sincronizar diretamente os dados de todas as cadeias de fragmentos, a carga sobre os nós aumentará muito, o que tornará o Ethereum cada vez mais centralizado. [2]

**Problema de crescimento do volume de dados: **Embora a velocidade de processamento do Ethereum tenha aumentado muito, o processamento simultâneo de dados por múltiplas cadeias de shard também levou a um grande aumento na quantidade de dados armazenados. A taxa de expansão do volume de dados do Ethereum será muitas vezes mais rápida do que antes, e os requisitos de desempenho de armazenamento para nós continuarão a aumentar, levando a mais centralização.

**Não há como resolver o problema do MEV:** O Valor Máximo Extraível (MEV) é a quantia máxima que pode ser extraída da produção de blocos além da recompensa de bloco padrão e taxas de gás, adicionando e excluindo transações de blocos e alterando a ordem das transações nos blocos. Após uma transação ser iniciada no Ethereum, a transação será colocada no mempool (um pool que armazena transações a serem executadas) e aguardará para ser empacotada pelos mineradores. Então, os mineradores podem ver todas as transações no mempool, e os mineradores têm grande poder. Os mineradores controlam a inclusão, exclusão e ordem das transações. Se alguém lucra pagando mais taxas de gás para subornar mineradores para ajustar a ordem das transações no pool de transações, esse é um MEV de valor máximo extraível. [6]

Por exemplo:

  • Existe um método MEV chamado "ataque sanduíche" ou "ataque clamp". Este método de extração de MEV é monitorar grandes transações DEX na cadeia. Por exemplo, alguém quer comprar uma moeda cottage no valor de 1 milhão de dólares americanos no Uniswap, e esta transação aumentará muito o preço desta moeda cottage. Quando esta transação é colocada no mempool, o robô de monitoramento pode detectar esta transação. Neste momento, o robô suborna o minerador que embala este bloco para colocar uma operação de compra desta moeda cottage na frente desta pessoa, e então realiza uma operação de venda após a operação de compra desta pessoa, assim como um sanduíche, imprensando a pessoa que conduz grandes transações DEX no meio. Desta forma, a pessoa que lança o "ataque sanduíche" obtém o lucro da moeda cottage por causa da transação em larga escala desta pessoa, enquanto a pessoa que conduz transações em larga escala sofre perdas. [6]

A existência do MEV também vem trazendo alguns impactos negativos para o Ethereum, como as perdas e pior experiência do usuário causadas pelo "sandwich attack", congestionamento de rede causado pela competição de front-runner, altas taxas de gás e até mesmo problemas de centralização de nós. Isso ocorre porque os nós que obtêm mais valor de MEV podem continuar a ocupar uma fatia maior na rede por meio da renda, porque mais renda = mais ETH = mais capital apostado. Além disso, o alto custo trazido pelo MEV (congestionamento de rede e alto GAS causado pelo front-running) fará com que os usuários do Ethereum continuem a perder usuários. Mesmo que o valor do MEV exceda significativamente a recompensa do bloco, isso fará com que o consenso e a segurança de todo o Ethereum sejam instáveis. A solução Sharding 1.0 não pode resolver a série de problemas trazidos pelo MEV.

Depois que o pesquisador e desenvolvedor do Ethereum Dankrad Feist propôs a nova solução de fragmentação do Ethereum, Danksharding, no final de 2021, o Danksharding foi unanimemente reconhecido pela comunidade Ethereum como a melhor solução para alcançar a expansão da fragmentação e pode até mesmo trazer uma nova revolução para o Ethereum.

Danksharding usa uma nova ideia de sharding para resolver o problema de escalabilidade do Ethereum, ou seja, uma solução de sharding baseada no Rollup da Layer2. Esta nova solução de sharding pode resolver o problema de escalabilidade sem aumentar significativamente a carga do nó e garantir a descentralização e a segurança, ao mesmo tempo em que resolve o impacto negativo do MEV.

Podemos ver na figura abaixo que os objetivos dos próximos estágios de atualização do Ethereum "The Surge" e "The Scourge" são: atingir mais de 100.000 TPS no Rollup e evitar a centralização trazida pelo MEV e outros riscos do protocolo.

Imagem / Fonte: vitalik.eth Tradução: ethereum.cn

Então, como o Danksharding resolve o problema de escalabilidade do Ethereum? Vamos começar com o antecessor de Danksharding, EIP-4844: Proto-Danksharding.

Solução preliminar EIP-4844: Proto-Danksharding — Novo tipo de transação Blob

EIP-4844 introduz um novo tipo de transação para Ethereum - Blob Transcation. Este novo tipo de transação Blob pode fornecer um banco de dados plug-in adicional para Ethereum:

  • O tamanho de um Blob é de aproximadamente 128 KB

  • Uma transação pode transportar até dois blobs - 256 KB

  • Cada bloco tem 8 Blobs de destino de 1 MB e pode transportar no máximo 16 Blobs de 2 MB (o conceito de destino é mencionado no plano de fundo da expansão)

  • Os dados do blob são armazenados temporariamente e serão apagados após um período de tempo (atualmente a comunidade recomenda 30 dias)

Atualmente, o tamanho médio de cada bloco Ethereum é de apenas cerca de 85 KB. O espaço de armazenamento adicional que o Blob traz para o Ethereum é enorme. Deve-se notar que o tamanho total dos dados de todos os livros-razão do Ethereum desde o nascimento do Ethereum é de apenas cerca de 1 TB, e o Blob pode trazer 2,5 TB a 5 TB de dados adicionais para o Ethereum a cada ano, o que é várias vezes o tamanho dos dados de todo o livro-razão do Ethereum.

A transação Blob introduzida pelo EIP-4844 pode ser considerada feita sob medida para o Rollup. Os dados do Rollup são carregados para o Ethereum na forma de Blob. O espaço de dados adicional permite que o Rollup alcance TPS mais alto e custos mais baixos, ao mesmo tempo em que libera o espaço de bloco originalmente ocupado pelo Rollup para mais usuários.

Como os dados Blob são armazenados temporariamente, o aumento repentino no volume de dados não causará um fardo crescente no desempenho de armazenamento do nó. Se apenas um mês de dados Blob for armazenado temporariamente, então, da perspectiva da quantidade de dados sincronizados, cada nó de bloco precisa baixar 1MB~2MB adicionais de dados, o que não parece ser um fardo nos requisitos de largura de banda do nó. Da perspectiva do armazenamento de dados, os nós só precisam baixar e salvar uma quantidade fixa de dados de cerca de 200~400 GB (dados de um mês). Ao mesmo tempo em que garantem a descentralização e a segurança, eles só pagam o custo de aumentar um pouco a carga do nó. Em troca, o aumento do TPS e a redução do custo são calculados em dezenas ou mesmo centenas de vezes. Esta é uma excelente solução para resolver o problema de escalabilidade do Ethereum.

E se os dados forem apagados e o usuário quiser acessar os dados anteriores?

Em primeiro lugar, o objetivo do protocolo de consenso Ethereum não é garantir o armazenamento permanente de todos os dados históricos. Em vez disso, o objetivo é fornecer um quadro de avisos em tempo real altamente seguro e armazenamento de longo prazo para outros protocolos descentralizados. O propósito do quadro de avisos é garantir que os dados postados no quadro de avisos permaneçam por tempo suficiente. Qualquer usuário ou protocolo que queira esses dados tem tempo suficiente para capturar e salvar os dados. Portanto, a responsabilidade de salvar esses dados Blob é dada a outras funções, como partes do projeto Layer2, protocolos de armazenamento descentralizados, etc. [3]

Danksharding — Solução de dimensionamento completa

O EIP-4844 concretiza o primeiro passo da expansão do Ethereum em torno do Rollup, mas o efeito de expansão alcançado pelo EIP-4844 está longe de ser suficiente para o Ethereum. A solução completa Danksharding expande ainda mais a quantidade de dados que o Blob pode transportar de 1 a 2 MB por bloco para 16 MB a 32 MB e propõe um novo mecanismo, a separação entre produtor e empacotador de blocos (PBS), para resolver os problemas causados ​​pelo MEV.

Então precisamos saber quais dificuldades surgirão se continuarmos a expandir a capacidade com base no EIP-4844:

**Os nós estão sobrecarregados: **Sabemos que o aumento da carga sobre os nós devido a blobs de apenas 1 a 2 MB no EIP-4844 é completamente aceitável, mas se o tamanho dos blobs for aumentado 16 vezes para 16 a 32 MB, a carga na sincronização e no armazenamento de dados deixará os nós sobrecarregados, reduzindo assim o grau de descentralização do Ethereum.

**Problema de disponibilidade de dados: **Se o nó não baixar todos os dados do Blob, ele enfrentará o problema de disponibilidade de dados, porque os dados não estão abertos na cadeia e acessíveis a qualquer momento. Por exemplo, o nó Ethereum tem dúvidas sobre uma transação no Optimism Rollup e quer contestá-la, mas o Optimism Rollup não entrega os dados. Então, sem os dados originais, ele não pode provar que a transação é problemática. Portanto, para resolver o problema de disponibilidade de dados, é necessário garantir que os dados estejam abertos e acessíveis a qualquer momento.

Então como Danksharding resolve esses problemas?

Amostragem de disponibilidade de dados

Danksharding propôs uma solução - Amostragem de Disponibilidade de Dados para reduzir a carga do nó e, ao mesmo tempo, garantir a disponibilidade dos dados.

A ideia do Data Availability Sampling (DAS) é cortar os dados no Blob em fragmentos de dados e deixar que os nós alternem entre baixar dados do Blob e verificar aleatoriamente os fragmentos de dados do Blob, de modo que os fragmentos de dados do Blob fiquem espalhados em cada nó do Ethereum, mas os dados completos do Blob sejam armazenados em todo o livro-razão do Ethereum, desde que haja nós suficientes e eles sejam descentralizados.

Por exemplo, se os dados de um Blob forem cortados em 10 fragmentos, e houver 100 nós em toda a rede, cada nó selecionará e baixará aleatoriamente um fragmento de dados e enviará o número do fragmento selecionado para o bloco. Contanto que todos os fragmentos numerados possam ser reunidos em um bloco, o Ethereum assumirá que os dados deste Blob estão disponíveis, e os dados originais podem ser restaurados juntando os fragmentos. No entanto, há uma probabilidade extremamente baixa de que nenhum dos 100 nós desenhe um fragmento com um determinado número, então os dados estarão ausentes, o que reduzirá a segurança até certo ponto, mas é aceitável em termos de probabilidade.

Danksharding usa duas tecnologias para atingir a Amostragem de Disponibilidade de Dados (DAS): Codificação de Apagamento e Compromisso KZG

Codificação de apagamento

Erasure Coding é uma tecnologia tolerante a falhas de codificação. Usar a erasure encoding para dividir dados permite que todos os nós Ethereum restaurem os dados originais quando apenas mais de 50% dos fragmentos de dados estão disponíveis, o que reduz muito a probabilidade de perda de dados. O princípio de implementação específico é relativamente complicado. Aqui usamos uma fórmula matemática para dar um exemplo para explicar aproximadamente o princípio: [2]

  • Primeiro, construa uma função f(x) = ax + b e selecione aleatoriamente 4 valores de x

  • Assumindo m = f(0) = b, n = f(1) = a + b, podemos concluir que a = n – b, b = m

  • Seja p = f(2) e q = f(3), podemos obter p = 2a + b = 2n – m, q = 3a + b = 3n – 2m

  • Então os quatro fragmentos m, n, p e q são espalhados entre os nós de toda a rede.

  • De acordo com a fórmula matemática, precisamos apenas encontrar dois fragmentos para descobrir quais são os outros dois fragmentos.

  • Se encontrarmos n e m, podemos calcular diretamente q=3n-2m e p=2n-m

  • Se encontrarmos q e p, podemos adicionar (2p=4n-2m)-(q=3n-2m) para obter 2p-q=n e então podemos calcular m diretamente.

Simplificando, os códigos de apagamento usam princípios matemáticos para cortar dados Blob em muitos fragmentos de dados. Os nós Ethereum não precisam coletar todos os fragmentos de dados. Eles só precisam coletar mais de 50% dos fragmentos para restaurar os dados originais do Blob. Isso reduz muito a probabilidade de coleta insuficiente de fragmentos, e a probabilidade pode ser ignorada.

Compromisso KZG

O KZG Commitment é uma técnica criptográfica usada para resolver o problema de integridade de dados de códigos de eliminação. Como o nó apenas verifica aleatoriamente os fragmentos de dados após serem cortados pelo código de apagamento, o nó não sabe se o fragmento de dados realmente vem dos dados originais do Blob, então a função responsável pela codificação também precisa gerar um comprometimento polinomial KZG para provar que o fragmento de dados do código de apagamento é de fato parte dos dados originais. A função do KZG é um pouco semelhante à árvore de Merkle, mas o formato é diferente. Todas as provas KZG estão no mesmo polinômio.

Danksharding implementa Data Availability Sampling (DAS) por meio de códigos de apagamento e compromissos polinomiais KZG, o que reduz muito a carga sobre os nós quando os dados adicionais transportados pelo Blob são expandidos para 16 MB~32 MB. A comunidade Ethereum também propôs uma solução chamada esquema 2D KZG para cortar ainda mais os fragmentos de dados para reduzir a largura de banda e os requisitos de computação, mas a comunidade ainda está discutindo o algoritmo específico a ser usado, incluindo o design do DAS, que também está sendo continuamente otimizado e aprimorado.

Para Ethereum, a Amostragem de Disponibilidade de Dados (DAS) resolve o problema de expandir o volume de dados do Blob para 16 MB~32 MB, ao mesmo tempo que reduz a carga sobre os nós, mas parece haver um problema: quem codificará os dados originais?

Se você quiser codificar os dados brutos do Blob, o pré-requisito é que o nó que está fazendo a codificação tenha os dados brutos completos. Para conseguir isso, requisitos mais altos serão colocados no nó. Como mencionado antes, Danksharding propôs um novo mecanismo **Blocker-Packager Separation (PBS)** para resolver os problemas causados ​​pelo MEV. Na verdade, essa solução não só resolve o problema do MEV, mas também resolve o problema da codificação.

Separação Proponente/Construtor

Primeiro de tudo, sabemos que o Data Availability Sampling (DAS) reduz o fardo da verificação de nós de Blobs e realiza uma verificação descentralizada e de baixa configuração. No entanto, para criar este bloco, é necessário ter dados completos do Blob e codificá-los, o que aumenta os requisitos para muitos nós completos do Ethereum. A Separação Proposer-Packard (PBS) propõe dividir os nós em duas funções: Builder e Proposer. Os nós com alto desempenho podem se tornar Builders, enquanto os nós com baixo desempenho podem se tornar Proposers.

Atualmente, existem dois tipos de nós Ethereum: nós completos e nós leves. Os nós completos precisam sincronizar todos os dados no Ethereum, como listas de transações e corpos de blocos, etc. Os nós completos desempenham duas funções: empacotamento de blocos e verificação de blocos. Como o nó completo pode ver todas as informações no bloco, ele pode reordenar, adicionar ou excluir transações no bloco para obter o valor MEV. Os nós leves não precisam sincronizar todos os dados, eles só precisam sincronizar o cabeçalho do bloco e verificar o bloco. [1]

Após implementar a separação proponente-empacotador (PBS):

  • Nós com configuração de alto desempenho podem se tornar empacotadores (Builders). Os empacotadores são responsáveis ​​apenas por baixar dados Blob para codificação e criação de blocos, e então transmiti-los para outros nós para verificações pontuais. Para empacotadores (Builders), devido aos altos requisitos para volume de dados sincronizados e largura de banda, ele será relativamente centralizado.

  • Nós com configuração de desempenho mais baixo podem se tornar proponentes. Os proponentes precisam apenas verificar a validade dos dados e criar e transmitir o cabeçalho do bloco. No entanto, para os proponentes, os requisitos de volume de dados de sincronização e largura de banda são menores, então será descentralizado.

O PBS realiza a divisão de trabalho entre os nós separando as funções de empacotamento e verificação. Os nós com configuração de alto desempenho são responsáveis ​​por baixar todos os dados para codificação e distribuição, enquanto os nós com configuração de baixo desempenho são responsáveis ​​por verificações pontuais e verificação. Então, como o problema MEV é resolvido?

Lista de resistentes à censura (crList)

Como o PBS separa o trabalho de empacotamento e verificação, o empacotador (Builder) na verdade tem uma capacidade maior de censurar transações. O empacotador pode ignorar deliberadamente certas transações e arbitrariamente classificar e inserir as transações que ele quer inserir para obter MEV, mas a lista anticensura (crList) resolve esses problemas.

O mecanismo da lista anticensura (crList):[1]

  • Antes que o Builder empacotasse a transação em bloco, o Proponente primeiro publicará uma lista resistente à censura (crList), que contém todas as transações no mempool.

  • O Builder só pode escolher empacotar e classificar as transações em crList, o que significa que o Builder não pode inserir suas próprias transações privadas para obter MEV, nem pode rejeitar deliberadamente uma transação (a menos que o limite de Gas esteja cheio)

  • Após o Builder empacotar a lista de transações, ele transmite a versão final do Hash da lista de transações para o Proposer. O Proposer seleciona uma das listas de transações para gerar um cabeçalho de bloco e transmiti-lo.

  • Quando um nó sincroniza dados, ele obtém o cabeçalho do bloco do proponente e, em seguida, obtém o corpo do bloco do construtor para garantir que o corpo do bloco seja a versão final selecionada.

O impacto negativo do MEV, como o "ataque sanduíche", é resolvido por meio da lista resistente à censura (crList), e os nós não podem mais obter MEV semelhantes inserindo transações privadas.

O plano de implementação específico do Ethereum para o PBS ainda está em discussão, e o possível plano de implementação inicial atual é um PBS de dois slots.

双槽 PBS (Separação de dois slots do proponente-construtor)

O PBS de dois slots usa um modelo de licitação para determinar o bloco: [2]

  1. Após receber crList, o Builder cria o cabeçalho do bloco da lista de transações e faz um lance.

  2. O proponente seleciona o cabeçalho do bloco final bem-sucedido e o empacotador (Builder), e o proponente recebe incondicionalmente a taxa de lance vencedora (independentemente de um bloco válido ser gerado)

  3. O comitê de verificação (Comitês) confirma o cabeçalho do bloco vencedor

  4. O Construtor divulga o bloco vencedor Corpo

  5. O comitê de verificação confirma o corpo do bloco vencedor e realiza uma votação de verificação (se for aprovado, o bloco será produzido. Se o empacotador deliberadamente não fornecer um corpo do bloco, o bloco será considerado inexistente)

Embora os construtores ainda possam obter MEV ajustando a ordem da transação, o mecanismo de lances do PBS de slot duplo causa "involução" entre esses construtores. Quando todos tiverem que dar lances e competir por blocos, os lucros obtidos por empacotadores centralizados por meio do MEV serão continuamente espremidos, e os lucros finais serão distribuídos para proponentes descentralizados. Isso resolve o problema de empacotadores centralizados se tornando cada vez mais centralizados pela obtenção do MEV.

No entanto, o PBS de dois slots tem uma falha de design: podemos ver que o nome deste design contém "dois slots", o que significa que há dois slots. Isso significa que o tempo de bloco efetivo neste esquema é estendido para 24 segundos (um slot = 12 segundos). Como resolver este problema tem sido muito discutido na comunidade Ethereum.

Resumir

Danksharding fornece uma solução revolucionária para o Ethereum resolver o "triângulo impossível do blockchain", ou seja, alcançar escalabilidade e ao mesmo tempo garantir a descentralização e a segurança do Ethereum:

  • O novo tipo de transação Blob é introduzido por meio da pré-solução EIP-4844: Proto-Danksharding. Os 1MB~2MB de dados adicionais transportados pelo Blob podem ajudar o Ethereum a atingir TPS mais alto e custos mais baixos no Rollup.

  • A Amostragem de Disponibilidade de Dados (DAS) é implementada por meio de codificação de eliminação e comprometimento polinomial KZG, permitindo que os nós verifiquem a disponibilidade dos dados verificando apenas alguns fragmentos de dados e reduzindo a carga sobre os nós.

  • Ao implementar o Data Availability Sampling (DAS), o volume de dados adicional do Blob é expandido para 16 MB~32 MB, tornando o efeito de expansão ainda melhor.

  • Por meio da separação proponente-empacotador (PBS), o trabalho de verificação e empacotamento de blocos é separado em duas funções de nó, alcançando a descentralização parcial dos nós de empacotamento e a descentralização dos nós de verificação.

  • O impacto negativo do MEV é bastante reduzido por meio da lista anticensura (crList) e do PBS de slot duplo. O empacotador não pode inserir transações privadas ou censurar uma transação.

Se nada inesperado acontecer, a solução predecessora EIP-4844 da Danksharding será oficialmente implementada na atualização de Cancun após a atualização de Shanghai da Ethereum. Após a solução EIP-4844 ser implementada, o benefício mais direto será o Rollup na Camada 2 e o ecossistema no Rollup. TPS mais alto e custos mais baixos são muito adequados para aplicações de alta frequência na cadeia. Podemos muito bem imaginar que algumas "aplicações matadoras" podem nascer. A produção centralizada de blocos + verificação descentralizada + anticensura alcançada pelo Danksharding trará uma nova rodada de narrativa de cadeia pública para o Ethereum. Além da Layer2, que tipo de reação química o blockchain modular e o Ethereum após o Danksharding produzirão?

Acreditamos que a implementação do Danksharding reescreverá as regras do jogo e o Ethereum levará a indústria de blockchain a uma nova era!

Referências

[1] Disponibilidade de dados, expansão de armazenamento de blockchain

[2] Um artigo para entender o novo plano de atualização do Ethereum Danksharding

[3] Perguntas frequentes sobre Proto-Danksharding – HackMD

[4] O que é “Danksharding”?

[5] V God recomenda: Para obter uma compreensão mais profunda do roteiro de fragmentação do Ethereum, basta ler este relatório

[6] Artigo do Buidler DAO: Como resgatar NFTs de hackers após uma carteira ser roubada?

[7] A história se repete? Ethereum 2.0 e Hard Fork explicados