Opside ZK-PoW V2.0: uma rede de provedores descentralizada multi-chain e multi-rollup

Oside ZK-PoW Introdução

Opside é uma plataforma ZK-RaaS (ZK-Rollup as a Service) descentralizada e uma rede líder para mineração ZKP (Zero-Knowledge Proof). O ZK-RaaS fornece um serviço de um clique para gerar ZK-Rollups para qualquer pessoa. Opside oferece uma base de lançamento ZK-Rollup universal, permitindo que os desenvolvedores implementem facilmente diferentes tipos de ZK-Rollups em várias cadeias de base.

• Cadeias de base: Ethereum/Opside chain/BNB chain/Polygon PoS e outras cadeias públicas.
• Tipos de ZK-Rollup: zkSync, Polygon zkEVM, Scroll, StarkNet e outras variantes de ZK-Rollups.

No design da Opside, os desenvolvedores podem implantar ZK-Rollups nessas diferentes cadeias de base. À medida que a tecnologia ZK-Rollup amadurece, pode haver centenas ou até milhares de ZK-Rollups no futuro, o que criará uma demanda significativa por poder de computação do ZKP. Opside utiliza o mecanismo ZK-PoW para incentivar os mineradores a fornecer poder de computação ZKP, fornecendo assim uma infraestrutura de hardware completa para ZK-Rollups.

Arquitetura ZK-PoW V2.0

A arquitetura geral do ZK-PoW V2.0 consiste em vários componentes principais:

1. ZK-PoW Cloud: Esta é a infraestrutura de nuvem fornecida pela Opside para computação ZKP. Ele é implantado em várias cadeias, incluindo Ethereum, BNB Chain, Polygon PoS e Opside Chain. A Nuvem ZK-PoW é responsável por coordenar e gerenciar as tarefas de computação do ZKP.

   
   

2. Nós do minerador: são os nós operados pelos mineradores que contribuem com seu poder computacional para realizar cálculos ZKP. Os mineradores podem participar da rede ZK-PoW executando software especializado em seu hardware de mineração.

   
   

3. Distribuição de Tarefas ZKP: A Nuvem ZK-PoW distribui tarefas de computação ZKP para os nós mineradores. A distribuição é feita de forma descentralizada para garantir justiça e eficiência. As tarefas do ZKP incluem gerar e verificar provas de conhecimento zero para vários ZK-Rollups.

   
   

4. Computação ZKP: Os nós mineradores recebem tarefas de computação ZKP e realizam os cálculos necessários para gerar as provas necessárias. Isso envolve a execução de algoritmos criptográficos e cálculos complexos.

   
   

5. Envio e verificação de prova: Uma vez que os cálculos do ZKP são concluídos, os nós mineradores enviam as provas geradas para o ZK-PoW Cloud para verificação. A infraestrutura de nuvem verifica a exatidão das provas para garantir sua validade e integridade.

   
   

6. Mecanismo de incentivo: os mineradores são incentivados a participar da rede ZK-PoW ganhando recompensas por suas contribuições computacionais. O sistema de recompensa é projetado para motivar os mineradores e manter a segurança e a estabilidade da rede.

No geral, o ZK-PoW V2.0 combina o poder dos recursos computacionais dos mineradores com infraestrutura de nuvem para fornecer computação ZKP eficiente e escalável para uma ampla gama de ZK-Rollups.

O agregador é um componente importante do Prover no sistema ZK-PoW V2.0. Ele é responsável por distribuir tarefas de prova ZKP, receber resultados de tarefas (provas ZKP), gerenciar as provas e enviá-las à Base Chain para ganhar recompensas. Com base em suas funções, a nova versão do Agregador é dividida em três submódulos: Proof Generator, Proof Manager e Proof Sender.

• O módulo Proof Generator é responsável por atribuir tarefas de prova ao Prover (poW miner), receber os resultados da tarefa (provas ZKP) e armazenar as provas ZKP no banco de dados do banco de dados.

• O Proof Manager é responsável por gerenciar as provas ZKP concluídas e empacotar as provas que estão prontas para envio na cadeia como tarefas para o módulo Proof Sender.

• O módulo Proof Sender lida com o envio on-chain de provas ZKP, submetendo-as ao contrato zkEVM implantado na Base Chain.

  
  

Abaixo estão as introduções destes três módulos:

gerador de prova

A Rollup Chain agrega um determinado número de transações em um lote e, em seguida, vários lotes (com base em fatores como frequência de transação) são combinados em uma sequência. A sequência é então submetida à Cadeia de Base, tornando-a a unidade de submissão de dados para cada operação na cadeia. Cada sequência consiste em um ou mais lotes, e a prova ZKP verifica a validade da sequência enviada. Portanto, o lote é a menor unidade de tarefa de prova. Dependendo do número de lotes incluídos em uma sequência, as tarefas de prova necessárias variam da seguinte forma:

• Se o número de lotes for 1, o processo de prova envolve BatchProofTask seguido de FinalProofTask e as tarefas são concluídas sequencialmente.

• Se a sequência contiver mais de 1 lote, o processo de prova envolverá vários BatchProofTasks, um AggregatorProofTask e um FinalProofTask, e as tarefas serão concluídas sequencialmente.

  
  

Para maximizar a eficiência da geração de provas e aumentar as recompensas de mineração para mineradores PoW, pretendemos gerar provas simultaneamente. Isso é alcançado em dois aspectos:

• A geração de provas para diferentes sequências pode ser feita simultaneamente, pois não há dependência contextual ou de estado.

• Dentro da mesma sequência, vários BatchProofTasks podem ser executados simultaneamente.

  
  

Essa abordagem utiliza os recursos computacionais dos Provers de forma mais eficiente, resultando em geração de prova mais eficiente.

Gerenciador de provas

Este módulo é o principal responsável por gerenciar as provas do ZKP e controlar sua verificação on-chain. É composto por três módulos principais:

• submitPendingProof : Este módulo é executado apenas uma vez quando o Agregador é iniciado. A sua finalidade é completar a submissão de provas ZKP inacabadas do serviço Aggregator anterior. Isso lida com a situação em que proofHash foi enviado, mas outros mineradores já enviaram suas provas. Para obter mais informações sobre proofHash, consulte o módulo Proof Sender.
• tryFetchProofToSend : Este módulo é executado como uma co-rotina e adiciona a última prova ZKP gerada, juntamente com sua sequência não verificada correspondente, ao cache do Proof Sender, aguardando o envio na cadeia.
• processResend : Este módulo é executado como uma co-rotina e tem como objetivo reenviar sequências que não foram verificadas com sucesso em uma determinada janela de tempo. Sua finalidade é garantir que as sequências que excedam o tempo de verificação sejam reenviadas para processamento on-chain.

Remetente da prova

Oside propôs um algoritmo de submissão ZKP de duas etapas para obter a descentralização do provador. Esse algoritmo evita ataques front-running ZKP e permite que mais mineradores recebam recompensas, incentivando assim mais mineradores a participar e fornecer poder de computação ZKP estável e contínuo.

• Etapa 1 : Ao produzir uma prova PoW para uma sequência específica (referida como prova), o provador primeiro calcula o hash de "prova/endereço" e o envia ao contrato. Se nenhum proofHash foi enviado para essa sequência antes, uma janela de tempo de envio proofHash, T1, é aberta. Os mineradores são elegíveis para enviar a sequência dentro dos blocos T1 e a prova só pode ser enviada após os blocos T1.

  
  

• Etapa 2 : Após os blocos T1, a janela de envio de provas é aberta para os blocos T2. Se nenhuma das provas enviadas passar na verificação dentro dos blocos T2, todos os mineradores que enviaram proofHash anteriormente serão penalizados. Se proofHash for enviado com sucesso dentro da janela de tempo T1, mas a prova não puder ser enviada com sucesso dentro da janela de tempo T2, e outros mineradores enviarem suas provas com sucesso dentro da janela T2, o provador ainda poderá continuar a enviar essa prova. Em outros cenários, o processo de envio em duas etapas é reiniciado.

O diagrama a seguir ilustra como o Proof Sender implementa o envio em duas etapas usando três caches thread-safe e classificados por prioridade. Esses caches são classificados com base na altura inicial das sequências, garantindo que cada vez que um elemento é recuperado desses caches, ele corresponda à menor altura da sequência. Além disso, os elementos nesses caches são desduplicados. Quanto menor a altura da sequência correspondente, maior a prioridade de processamento.

• finalProofMsgCache: Armazena as mensagens finalProof enviadas pelo Proof Manager, indicando a finalização das provas do ZKP.
• monitPHTxCache: Armazena as transações proofHash a serem monitoradas.
• ProofHashCache: Armazena as mensagens de prova para envio na cadeia.

Após o lançamento do módulo Proof Sender, três corrotinas são iniciadas para consumir dados dos três caches. O processo simplificado é o seguinte:

1. A Coroutine 1 consome as mensagens finalProof do finalProofMsgCache, calcula o proofHash e, se atender às condições para envio na cadeia (dentro da janela T1), envia o proofHash para a cadeia e adiciona a transação proofHash ao monitPHTxCache.

2. A corrotina 2 consome as mensagens de transação proofHash do monitPHTxCache. Se o proofHash atender às condições para envio na cadeia dentro da janela T2, ele constrói a mensagem de prova e a armazena no ProofHashCache.

3. A corrotina 3 consome as mensagens de prova do ProofHashCache e envia as provas para a cadeia.

   
   

Em comparação com o módulo anterior, essa estrutura é mais clara e economiza na sobrecarga de recursos.

Resumo

Comparação com a versão 1.0

• A versão 2.0 divide o serviço original em três submódulos, cada um responsável pela geração de prova, gerenciamento de prova e envio de prova, resultando em uma estrutura mais clara, menor acoplamento e maior robustez.
• O módulo de geração de prova, Proof Generator, adicionou o parâmetro startBatch em comparação com a versão antiga, tornando mais fácil para novos mineradores acompanhar o progresso da mineração.
• O módulo de gerenciamento de prova, Proof Manager, foi aprimorado em comparação com a versão antiga. Ele reenvia prontamente as provas em caso de reinicialização do serviço do minerador ou outros motivos para falha no envio da prova, garantindo os interesses do minerador. O mecanismo de reenvio não apenas aborda os casos de falha no envio de provas, mas também lida com todos os casos de falha ou não envio de provas, garantindo a segurança da Cadeia Rollup.
• O módulo de envio de prova, Proof Sender, implementa um envio de transação em duas etapas usando três caches prioritários thread-safe. Reduz o uso de travas globais em relação às versões anteriores, garantindo que as provas com alturas menores sejam enviadas prontamente e protegendo os interesses do minerador. Além disso, o fluxo geral do serviço é mais claro, com menor contagem de threads e menor consumo de recursos durante a execução do programa.

Resultados do teste de estresse:

• Na versão 2.0, utilizando 10 máquinas com 64 núcleos cada, foram concluídas 566 provas em lote em 7 horas, 38 minutos e 40 segundos, com tempo médio de 48,62 segundos por prova. Em um cenário de vários mineradores, em comparação com a versão 1.0, a eficiência da geração de provas zk na versão 2.0 melhorou em 50% no geral.

  
  

Em conclusão, o Opside ZK-PoW V2.0 otimizou o processo de vários mineradores participando de cálculos ZKP, melhorando a utilização do hardware, aprimorando a disponibilidade do serviço e sendo mais amigável ao minerador. É importante ressaltar que, em um cenário de vários mineradores, o tempo de computação do ZKP foi reduzido para menos de um minuto, acelerando significativamente o tempo de confirmação das transações ZK-Rollup.