TL;DR

• =nil; é um zkRollup fragmentado - um novo conceito L2 para escalonamento dinâmico e seguro do Ethereum através de uma execução de transação paralela em nível de protocolo através de fragmentos.
• 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 aplicativos plena composabilidade 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 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. Apresentamos um design de camada 2 (L2), =nil;, que eleva 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, protegido 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 nos permite reutilizar aplicações já implantadas. O acesso direto aos dados do L1 a partir do L2 garante um ambiente mais unificado e sem interrupções.

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

• Escalabilidade

  • Sem limitações de escalabilidade, pois a execução é paralela. A capacidade é estimada em cerca de 60k transferências ERC-20 por segundo, com aproximadamente 400 nós.
  • Geração de prova competitiva via o Mercado de Provas fornece a L1-finalidade mais rápida e os custos de geração de prova mais baratos.

• Ambiente de Execução Unificado

  • Ambiente de execução unificado garante que não haja fragmentação de segurança/liquidez, pois cada fragmento é parte do cluster como um todo.
  • Redução da necessidade de migrar liquidez do Ethereum, pois =nil; fornece acesso transparente aos seus dados para aplicativos, obrigando cada validador a manter um estado completo do Ethereum como parte da implantação, permitindo que aplicativos acessem dados diretamente do zkEVM do =nil;.

• Segurança

  • Transições de estado asseguradas pelo zkEVM compilado via zkLLVM. Ele fornece segurança auditável (por exemplo, segurança de restrições) pois 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 de prova descentralizada habilitada por =nil; Mercado de Provas.

• Funcionalidade

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

Escalonamento componível dinâmico

No nível mais baixo, 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. Ele usa o Ethereum tanto como sua Camada de Disponibilidade de Dados quanto como verificador para provas de transição de estado, semelhante às operações típicas de zkRollups.

Os shards secundários funcionam como “trabalhadores”, executando transações de usuário. Esses shards mantêm liquidez e dados unificados por meio de um protocolo de mensagens entre shards, eliminando qualquer fragmentação entre eles.

Cada fragmentação é supervisionada por um comitê de validadores. Há uma rotação periódica desses validadores entre as 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 iniciativa do usuário até a confirmação no Ethereum, considere as seguintes etapas:

• O usuário assina uma transação (tx) e a despacha para a rede.
• Validadores no fragmento S, onde a carteira do usuário está localizada, colocam tx na mempool.
• Esses validadores então criam um novo bloco B(1/S)
• O hash de B(1/S) é registrado 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 Ethereum para verificação e acoplada com os dados necessários para garantir a disponibilidade dos dados.
• Uma vez que esse processo estiver completo, tx alcança confirmação pelo Ethereum.

Este esboço pressupõe que a transação do usuário 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 usuário pode desencadear a criação de novas transações em outros 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 de aplicativos. 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 gerenciada por pontes externas separadas.

Para garantir a segurança de cada fragmentação secundária, seu comitê validador é obrigado a comprovar suas transições de estado para o primário para garantir que nenhuma fraude tenha ocorrido dentro de um grupo de validadores menor. Cada comitê de validadores de fragmentação tem tarefas adicionais além da manutenção da fragmentação. Os validadores são responsáveis por rastrear tipos específicos de eventos, ou seja, mensagens entre fragmentações, dentro de "fragmentações próximas". As fragmentações próximas são determinadas com base na distância de Hamming nos identificadores de fragmentação.

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

=nil;s zkEVM é um zkEVM Tipo-1 compilado com zkLLVM. Para entender as diferenças entre zkEVMs mais tradicionais e o zkEVM da =nil;, precisamos discutir as limitações associadas ao processo de definição de circuito que subjaz aos zkEVMs. O circuito zkEVM é uma parte crítica, responsável por uma prova de transição de estado a ser considerada correta, geralmente definida com algum zkDSL personalizado ou simplesmente uma biblioteca. Tal 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 do EVM.
• Auditabilidade: Limitadoauditabilidadeeinspectabilidadedevido à complexidade e à falta de explicitação dos zkDSLs utilizados.
• Atualização: Complexidade de manutenção e atualização devido a requisitos de definição de restrições manuais. No caso de qualquer mudança no EVM - a maioria dos circuitos zkEVM precisaria 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) muitas vezes resulta em limitações para aplicativos devido às diferenças no comportamento do zkEVM e do EVM real.

=nil; zkEVM está efetivamente lidando com todos esses desafios ao 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 para garantir que não haja diferenças de algoritmo presentes.
• Auditable: Um circuito deve ser representado em uma linguagem de programação de alto nível (como C++ ou Rust), que deve ser escrito de forma a ser facilmente legível por um desenvolvedor 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 que prove/defina exatamente o mesmo comportamento. Nenhuma necessidade de recompilação completa ou reauditoria deve surgir a partir de tal atualização.
• Compatível com bytecode (também conhecido como Tipo-1): A compilação de circuitos a partir de linguagens de alto nível traz compatibilidade total com bytecode e comportamento EVM, reduzindo drasticamente o tempo de entrada no 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 completa consistência com o EVM utilizado em 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 sua segurança não vem ao custo de incluir os últimos EIPs adicionados ao Ethereum.

zkRollup com Segurança e Disponibilidade de Dados do Ethereum

Como o shard primário e os shards secundários são diferentes em relação às suas tarefas dedicadas - os shards secundários focam no processamento de transações enquanto o shard primário foca 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. Isso significa:

• O shard principal emprega Ethereum como seu DA.
• Fragmentação secundária tem a opção de usar Ethereum ou optar por não ter um DA distinto.

Essa disposição é estabelecida ao lançar dois tipos de fragmentos no início: aqueles com uma solução DA separada e externa e aqueles sem. Nas fases subsequentes, apenas fragmentos da mesma categoria DA podem ser mesclados. Isso significa que durante sua criação, cada conta deve ser mapeada para uma categoria 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 de liquidez, portanto, naturalmente, a abordagem zkSharding seria incompleta sem acesso sem confiança ao estado do Ethereum. Isso significa =nil; oferece total composabilidade e integração transparente com o Ethereum por meio do módulo de Provedor de Dados.

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

Qual é o próximo:

=nil; e zkSharding são uma culminação de produtos que a Fundação =nil; desenvolveu ao longo dos últimos 4 anos. Seu objetivo é ser a primeira solução componível, escalável e universal de zkRollup L2 Ethereum. Estamos animados para compartilhar mais detalhes de implementação ao longo dos próximos meses. Certifique-se de seguir nosso Twitter para se manter atualizado com nosso progresso!

Para os tecnicamente inclinados, desenvolvemosum guia separado e abrangenteque se aprofunda nos detalhes de =nil; e zkSharding. Este guia é a sua porta de entrada para entender as complexidades por trás dessa abordagem, equipado com todos os detalhes técnicos e preliminares que você precisa.

Aprofunde-se em nosso guia técnico agora e participe da 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 autorais pertencem ao autor original [nil.foundation]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Responsabilidade Legal: 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 outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.