ZKBase é um ZK-Rollup de alto desempenho baseado em ZK Stack e provador multi-gpu. Esta solução aprimora a capacidade de processamento de transações e fornece uma experiência de rede econômica. Sua principal vantagem reside na adoção da tecnologia de prova de conhecimento zero (ZKP), permitindo que as transações fora da cadeia sejam rapidamente verificadas e confirmadas, mantendo a privacidade das transações e a integridade dos dados. Como todas as provas de validade são verificadas no Ethereum, os usuários podem desfrutar das mesmas garantias de segurança do L1. ZKBase opera de forma semelhante ao Ethereum, mas com maior rendimento e taxas mais baixas. Os contratos inteligentes são escritos em Solidity/Vyper e podem ser invocados usando os mesmos clientes que outras cadeias compatíveis com EVM. Este artigo apresentará a engenharia básica e a implementação técnica do ZKBase. 1. Componentes principais do ZKBase : Esses componentes usam RocksDB para manter cópias locais da árvore de armazenamento L2. O banco de dados permanece sincronizado com o hash raiz de estado mais recente, refletindo continuamente o estado atual do sistema. Tree e TreeBackup : Executa transações e armazena com segurança os blocos incluídos no banco de dados RocksDB local, garantindo a integridade dos dados e atualizações contínuas de estado. StateKeeper/VM : Implantados na rede principal Ethereum, esses contratos inteligentes verificam as provas de conhecimento zero (ZKPs) enviadas fora da cadeia. Após a verificação bem-sucedida, esses contratos atualizam os estados das contas na rede Ethereum. Contrato Inteligente : uma tecnologia ZK-Rollup que garante verificação de transações segura e eficiente por meio de provas de conhecimento zero. Quando um lote de transações ocorre fora da rede principal Ethereum, o sistema de agregação ZK compacta múltiplas transações em uma única “prova de validade” calculada pelo Provador, demonstrando a exatidão do lote. Esta prova é então submetida à rede Ethereum, permitindo a confirmação rápida e segura de um grande volume de transações que ocorrem fora da cadeia. GPU Prover : ZKBase fornece um mecanismo de ponte para transferência segura de ativos entre ZKBase e a rede principal Ethereum, garantindo interoperabilidade e liquidez de ativos entre as duas plataformas Bridge 2. Fluxo de trabalho ZKBase Os usuários podem iniciar solicitações L2 por meio de uma interface de programação de aplicativos (API) ou por meio de contratos implantados em L1. Uma vez enviadas, essas solicitações entram em um mempool, aguardando execução. Notavelmente, as transações originadas de L1 (como depósitos) são armazenadas em uma fila de prioridade L1 dedicada para garantir que sejam processadas prontamente. A estrutura de armazenamento do mempool é um btreeset (um conjunto implementado por um btree). A estrutura de indexação é a seguinte: Aqui, fee_data não está envolvido no cálculo real da pontuação, mas ajuda a filtrar as transações que não atendem aos requisitos de taxas. A pontuação é classificada por carimbo de data e hora e, se os carimbos de data e hora forem idênticos, por endereço. As transações no mempool são gerenciadas pelo componente buscador de mempool dentro do State Keeper. Exceto para transações expiradas, as transações padrão são buscadas no mempool na ordem definida pela passagem btree e registradas no banco de dados. Eles são então processados pelo State Keeper/VM, executados e usados para atualizar a árvore de estado. O diagrama de layout de blocos mostra a organização das transações dentro de um bloco e a disposição dos blocos L2 dentro de um lote L1. Para iniciar cada lote L1, o operador precisa inserir detalhes importantes: o carimbo de data/hora do lote, sua posição na sequência e o valor hash do lote anterior. O hash raiz da árvore Merkle serve como hash raiz fundamental neste processo para garantir a validade do lote e a autenticidade das transações. Simultaneamente, o State Keeper tem autoridade para decidir quando finalizar um bloco L2 ou lote L1 específico, determinando assim o seu estado. Esta decisão é regida por um conjunto de critérios predefinidos gerenciados pelo módulo condicional_sealer. Esses critérios incluem parâmetros como contagem de transações, limites de tamanho e limites de uso de gás. Depois de processar uma transação, o State Keeper verifica quais condições de vedação foram atendidas. O condicional_sealer mantém um registro SealCriteria que inclui: Limites de contagem de transações, Limites de gás L2, Limites superiores à quantidade de dados publicados, entre outras regulamentações. Existem quatro cenários de decisão: NoSeal, IncludeAndSeal, ExcludeAndSeal e Unexecutable. Nos dois primeiros casos, o processo é o mesmo, sendo o estado pós-execução atualizado no State Keeper. ExcludeAndSeal lida com transações que excedem os limites de lote predefinidos, revertendo a execução da transação e colocando-a de volta na fila para ser incluída no próximo bloco L2. Se ocorrer uma situação Inexecutável, a transação não poderá ser executada e será rejeitada. Ao final de cada lote, o bootloader gera um bloco L2 de espaço reservado para concluir as transações e se preparar para o próximo ciclo. Embora quase sempre vazio, este bloco é crucial para operações internas e inclui um log de eventos de transferência para registrar movimentos de taxas entre o bootloader e a operadora. Para garantir a precisão do tempo, os carimbos de data/hora do lote e do último subbloco são cruzados com o período L1 esperado para aumentar a resiliência do sistema a problemas relacionados ao tempo. Assim que o lote é finalizado, o provador gera uma prova criptográfica para verificar a execução do bloco. No ZKBase, a responsabilidade do provador é provar a execução precisa da Máquina Virtual ZKBase Ethereum (EVM). Esta prova é então verificada por um contrato inteligente na rede Ethereum. Assim que a prova é gerada, o provador a empacota em uma transação L1 e a envia para o ETH_Sender. O ETH_Sender encaminha a transação para o contrato ZKBase implantado na rede principal Ethereum para processamento posterior. A rede principal Ethereum verifica a exatidão da prova e, após a verificação bem-sucedida, atualiza o estado de acordo. Ao longo do processo, o EthWatcher monitora continuamente eventos L1 específicos, como depósitos e atualizações do sistema, para garantir a sincronização com a rede principal Ethereum. 3. Arquitetura de vários provadores de GPU A arquitetura aproveita um banco de dados Postgres para compartilhar dados, permitindo a computação paralela em vários GPU Provers para aumentar a eficiência da geração de provas. Os principais componentes incluem: : O servidor que fornece serviços da Camada 2. Operador : Um módulo de comunicação que conecta o operador ao subsistema de prova. Prover Gateway : Gera tarefas de cálculo de prova e armazena artefatos intermediários. Witness Generator : agrega todas as tarefas de computação em um formato vetorial adequado para computação em GPU e as envia aos provadores. Gerador de vetor Executa o cálculo real e a verificação das provas. Provador: compacta a prova final no formato SNARK. Compressor: Fluxo de trabalho de geração de provas : O Operador coleta as transações e gera um novo lote. Geração de lote : O Prover Gateway recupera o novo lote do Operador e começa a se preparar para gerar a prova de conhecimento zero. Recepção de lote : O Prover Gateway insere as informações do lote no banco de dados Postgres. O processamento de dados subsequente interage diretamente com o banco de dados, recuperando dados das tabelas de entrada correspondentes e colocando os dados processados nas tabelas de saída relevantes. Inserção de banco de dados : Este estágio inicial ocorre quando um usuário inicia uma transação, gerando uma testemunha. A testemunha prova a validade da transação com base nas regras de consenso da rede, sem revelar quaisquer detalhes da transação. Novas testemunhas de transação são coletadas e processadas em lotes. Cada lote passa pelos seguintes processos: Geração de Testemunha Circuitos BásicosWitnessGenerator LeafAggregationWitnessGenerator Agregação de nós Agendador : O Gerador de Vetores consolida circuitos para produzir vetores testemunhas, otimizando o uso do poder computacional da GPU. Geração de Vetores : Os Provadores utilizam GPUs para calcular as provas de conhecimento zero, verificando a exatidão dos cálculos de prova. Computação de Prova : O módulo Compressor comprime a prova para reduzir o tamanho dos dados, transformando-os no formato SNARK. Compressão 4. Conclusão ZKBase, construído em ZK Stack e Multi-GPU Prover, alcança escalabilidade de camada 2 de alto desempenho. No entanto, a solução de escalonamento Ethereum ZK-Rollup ainda enfrenta inúmeros desafios técnicos. No futuro, a ZKBase continuará a pesquisar e explorar a implementação de sequenciamento descentralizado e uma rede descentralizada de poder computacional ZK.
