TL;DR

• =nil; é um zkRollup fragmentado - um novo conceito L2 para dimensionamento dinâmico e seguro do Ethereum através de uma execução paralela de transações em shards ao nível do protocolo.
• Equipado com zkSharding, =nil; oferece escalabilidade horizontal sem comprometer os benefícios de uma única camada de execução, nomeadamente liquidez unificada e segurança económica.
• =nil; fornece aplicações com total componibilidade com Ethereum através de acesso transparente e verificável aos dados do Ethereum.
• =nil; introduz um zkEVM Tipo-1 compilado com zkLLVM.
• A geração rápida de provas é garantida pela competição de mercado aberto através do =nil; Proof Market - um mercado de geração de provas sem permissão.

Introdução ao zkSharding

Hoje, as soluções de camada 2 sacrificam escalabilidade pela fragmentação de estado. Introduzimos um design de camada 2 (L2), =nil;, que empurra os limites da escalabilidade do Ethereum sem comprometer os benefícios de um ambiente de execução unificado. A solução combina um mecanismo de fragmentação dinâmica com acesso verificável aos dados do Ethereum, garantido por tecnologias de conhecimento zero. Os elementos-chave incluem:

• zkRollup com Fragmentação: O núcleo do =nil; é um protocolo de fragmentação comprovável, permitindo escalabilidade horizontal sem comprometer a segurança ou eficiência. Esta abordagem aborda algumas das limitações atuais da escalabilidade vertical (L3, L4, etc.), nomeadamente fragmentação de dados e liquidez.
• Acesso direto aos dados do Ethereum: A capacidade de chamar os dados originais do Ethereum a partir de aplicações L2 permite-nos reutilizar aplicações já implementadas. O acesso direto aos dados L1 a partir de L2 garante um ambiente mais unificado e contínuo.

Através de zkSharding =nil; beneficia das vantagens de ambos os designs monolíticos e modulares, incluindo:

• Escalabilidade

  • Sem limitações de escalabilidade, uma vez que a execução é paralela. A capacidade é estimada em cerca de 60k transferências ERC-20 por segundo com aproximadamente 400 nós.
  • A geração competitiva de provas através do Mercado de Provas fornece a maior L1-finalidade e os custos mais baixos de geração de provas.

• Ambiente de Execução Unificado

  • O ambiente de execução unificado não garante nenhuma fragmentação de segurança/liquidez, pois cada fragmento faz parte de todo o cluster.
  • Redução da necessidade de migrar liquidez do Ethereum como =nil; fornece acesso transparente aos seus dados para aplicações através da imposição de que cada validador mantenha um estado completo do Ethereum como parte da implementação, permitindo que as aplicações acessem os dados diretamente do zkEVM do =nil;.

• Segurança

  • Transições de estado asseguradas por zkEVM compiladas via zkLLVM. Fornece segurança auditável (por exemplo, segurança de restrições) porque o código é facilmente inspecionável, uma vez que os circuitos zkEVM são compilados a partir de uma implementação EVM usada em produção em linguagem de alto nível e não escritos manualmente.
  • Descentralizado desde o primeiro dia graças à geração descentralizada de provas habilitada por =nil; Mercado de Provas.

• Funcionalidade

  • Um zkEVM Tipo-1, totalmente compilado em zkLLVM, equivalente em bytecode EVM.
  • Um ambiente adaptado para aplicações que têm altas exigências relacionadas ao tempo, memória e complexidade algorítmica, aumentando a consistência de um único fragmento e introduzindo a co-localização de aplicações por fragmento para reduzir a latência. Exemplos incluem trocas descentralizadas, mercados de prova, sequenciadores/construtores descentralizados, aplicações de estado compartilhado (também conhecidas como mundos autônomos, etc).

Escalonamento componível dinâmico

No nível inferior, o estado de =nil; é particionado no shard primário e em vários shards secundários. O papel do shard principal é sincronizar e consolidar dados dos shards secundários. Usa o Ethereum tanto como sua Camada de Disponibilidade de Dados como verificador para provas de transição de estado, semelhante às operações típicas de zkRollups.

As shards secundárias funcionam como "trabalhadores", executando transações de utilizadores. Estas shards mantêm liquidez e dados unificados através de um protocolo de mensagens entre shards, eliminando qualquer fragmentação entre elas.

Cada fragmentação é supervisionada por um comité de validadores. Há uma rotação periódica destes validadores entre fragmentações. Além disso, as atualizações do estado de uma fragmentação são verificadas na fragmentação principal usando zkEVM.

Para ilustrar o fluxo de transação desde a sua iniciação por um utilizador até à confirmação na Ethereum, considere os seguintes passos:

• O utilizador assina uma transação (tx) e envia-a para a rede.
• Validadores no shard S, onde a carteira do usuário está localizada, colocam tx na mempool.
• Estes validadores criam então um novo bloco B(1/S)
• O hash de B(1/S) é registado no shard principal dentro do bloco B(1/M)
• Uma prova de transição de estado para B(1/S) é produzida e verificada pelo shard principal no bloco B(2/M)
• Uma prova de transição de estado para B(2/M) é enviada para o Ethereum para verificação e acoplada com os dados necessários para garantir a disponibilidade dos dados.
• Uma vez concluído este processo, a tx obtém confirmação pelo Ethereum.

Este esboço pressupõe que a transação do utilizador não ativa o protocolo de mensagens entre fragmentos. No entanto, neste caso, o fluxo da transação permanece o mesmo com a diferença de que a transação do utilizador pode desencadear a criação de novas transações noutros fragmentos.

Com todas as contas sendo distribuídas entre fragmentos, isso pode parecer semelhante ao problema de fragmentação de dados encontrado na abordagem de rollups específicos da aplicação. No entanto, a diferença chave está em como a comunicação entre fragmentos é tratada: ela é integrada diretamente no protocolo geral, em vez de ser gerida por pontes externas separadas.

Para garantir a segurança de cada fragmentação secundária, o seu comitê validador é obrigado a provar as transições de estado à principal para garantir que não houve fraude dentro de um grupo de validadores menor. Cada comitê de validadores de fragmento tem tarefas adicionais além da manutenção do fragmento. Os validadores são responsáveis por rastrear tipos específicos de eventos, nomeadamente mensagens entre fragmentos, dentro das "fragmentações próximas". As fragmentações próximas são determinadas com base na distância de Hamming nos identificadores de fragmento.

zkEVM via zkLLVM: Tipo-1 Seguro, Auditável e Performante zkEVM

=nil;s zkEVM é um zkEVM Tipo-1 compilado com zkLLVM. Para entender as diferenças entre zkEVMs mais tradicionais e o zkEVM do =nil;, precisamos discutir as limitações associadas ao processo de definição de circuito que sustenta os zkEVMs. O circuito zkEVM é uma parte crítica, responsável por uma prova de transição de estado ser considerada correta, sendo geralmente definida com algum zkDSL personalizado ou simplesmente uma biblioteca. Essa forma de definição de circuito traz problemas relacionados a:

• Segurança: Questõesdevido ao tamanho de um circuito e à replicação manual da lógica EVM.
• Auditabilidade: Limitadaauditabilidadeeinspectabilidadedevido à complexidade e não explicitação das zkDSLs utilizadas.
• Capacidade de atualização: Complexidade de manutenção e atualização devido a requisitos manuais de definição de restrições. No caso de ocorrer alguma alteração no EVM - a maioria dos circuitos zkEVM teria que ser refeita e reauditada do zero.
• Compatibilidade: A complexidade da implementação do circuito zkEVM realmente compatível com o bytecode (também conhecido como Tipo-1) frequentemente resulta em limitações para as aplicações devido às diferenças no comportamento do zkEVM e do EVM real.

=nil; zkEVM está a abordar eficazmente todos esses desafios por ser:

• Seguro: Um circuito deve ser gerado automaticamente a partir do mesmo código de alto nível usado nos nós Ethereum em produção real para garantir que não existam diferenças algorítmicas presentes.
• Auditable: Um circuito deve ser representado numa linguagem de programação de alto nível (por exemplo C++ ou Rust) que deve ser escrito de forma a ser facilmente legível por um programador médio.
• Atualizável: Um circuito deve ser definido de tal forma que qualquer alteração dentro do EVM possa ser facilmente traduzida/compilada para um circuito zkEVM comprovando/definindo exatamente o mesmo comportamento. Não deve surgir a necessidade de uma recompilação completa ou reauditoria de tal atualização.
• Compatível com o Bytecode (também conhecido como Tipo-1): A compilação de circuitos a partir de linguagens de alto nível traz total compatibilidade de bytecode e comportamento do EVM, reduzindo drasticamente o tempo de chegada ao mercado para aplicações EVM e o tempo/esforço de desenvolvimento necessários para alcançar essa compatibilidade.

O zkEVM compilado via zkLLVM é seguro por design, aproveitando o evmone para garantir total consistência com o EVM usado na produção do Ethereum. O zkLLVM (C++ ou Rust) compila automaticamente para o circuito, o que significa que erros humanos são removidos do processo de definição do circuito.

Além disso, porque =nil; zkEVM é compilado via zkLLVM, é naturalmente mais flexível (e, portanto, à prova de futuro) do que circuitos definidos manualmente, pois é facilmente ajustável e a geração de circuitos é automática. Também é mais auditável, o que significa que a sua segurança não vem ao custo de incluir as últimas EIPs adicionadas ao Ethereum.

zkRollup com Segurança e Disponibilidade de Dados do Ethereum

Como o fragmento primário e o fragmento secundário são diferentes em relação às suas tarefas dedicadas - os fragmentos secundários se concentram no processamento de transações, enquanto o fragmento primário se concentra na sincronização de dados - eles têm abordagens diferentes para a disponibilidade de dados (DA), o que ajuda a recuperar dados de estado em situações de emergência. Isto significa:

• O shard principal utiliza Ethereum como o seu DA.
• Os fragmentos secundários têm a opção de usar Ethereum ou optar por não ter um DA distinto.

Esta disposição é estabelecida lançando dois tipos de fragmentos no início: aqueles com uma solução DA separada e externa e aqueles sem. Nas fases subsequentes, apenas os fragmentos da mesma categoria de DA podem ser fundidos. Isto significa que durante a sua criação, cada conta deve ser mapeada para uma categoria de DA específica.

Além disso, este framework pode ser expandido para incluir outros tipos de DA.

Acesso Transparente aos Dados do Ethereum

Um dos nossos objetivos principais é otimizar a composição de aplicativos e evitar a fragmentação da liquidez, logo, a abordagem de fragmentação zkSharding seria incompleta sem acesso sem confiança ao estado do Ethereum. Isso significa que =nil; oferece total composabilidade e integração transparente com o Ethereum através do módulo de Provedor de Dados.

O Fornecedor de Dados opera de forma independente do armazenamento de dados do fragmento, sincroniza as suas informações com uma base de dados externa e injeta a impressão digital do Ethereum do último estado monitorado da base de dados (representado pelo hash do bloco do Ethereum) no bloco do fragmento. O estado mais recente desta base de dados recebe validação do módulo de confirmação, que utiliza um zkBridge com a prova de consenso Casper FFG do Ethereum.

O que vem a seguir:

=nil; e zkSharding são o culminar de produtos que a Fundação =nil; desenvolveu ao longo dos últimos 4 anos. O seu objetivo é ser a primeira solução componível, escalável e universal de zkRollup de camada 2 do Ethereum. Estamos entusiasmados por partilhar mais detalhes de implementação nos próximos meses. Certifique-se de seguir o nosso Twitter para se manter atualizado com o nosso progresso!

Para os tecnicamente inclinados, desenvolvemos um guia separado e abrangenteque aprofunda os detalhes de =nil; e zkFragmentação. Este manual é a sua porta de entrada para entender as complexidades por trás deste método, equipado com todos os detalhes técnicos e preliminares de que necessita.

Mergulhe agora no nosso guia técnico e junte-se à conversa sobre DiscordeTelegram. Vamos explorar juntos as possibilidades ilimitadas do zkSharding!

Aviso legal：

1. Este artigo é reproduzido a partir de [nil.foundation]. Todos os direitos de autor pertencem ao autor original [nil.foundation]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.