Opside: Provedores Descentralizados Pioneiros para ZK-Rollups de Próxima Geração

Por que precisamos de provadores descentralizados?

Atualmente, existem vários ZK-Rollups em execução na rede principal Ethereum. No entanto, o design de ZK-Rollups descentralizados ainda está em seus estágios iniciais. Atualmente, estamos focados na questão dos sequenciadores descentralizados, mas a maioria das pessoas ignora o fato de que atualmente a maioria dos projetos ZK-Rollup não implementou provadores descentralizados.

Para ZK-Rollups, um provador centralizado ainda é seguro e não traz os mesmos problemas de censura que um sequenciador centralizado. No entanto, um provador centralizado também pode causar muitos problemas. Primeiro, se houver apenas um provador, a falha de um único nó pode fazer com que todo o ZK-Rollup não apresente sua prova de validade, afetando assim a finalidade das transações.

Em segundo lugar, o custo de um provador centralizado é alto e é incapaz de atender à demanda computacional de enormes ZK-Rollups no futuro.

Finalmente, do ponto de vista econômico, apenas um provador centralizado desfruta de uma parte dos lucros, o que, do ponto de vista da economia simbólica, é realmente injusto.

Desafios dos provadores descentralizados

Provadores descentralizados podem efetivamente resolver os problemas acima, mas também trazem alguns desafios. Esta é uma das razões pelas quais vários esquemas zkEVM lançados recentemente adotaram um esquema de provador centralizado. Por exemplo, a rede principal beta do Polygon zkEVM depende de um agregador confiável para enviar ZKPs, e a era zkSync é semelhante a esse respeito.

Do ponto de vista técnico, quando o contrato inteligente de um ZK-Rollup verifica o ZKP, ele precisa dos dados de prova originais. Isso pode desencadear vários comportamentos de ataque na cadeia. Por exemplo, quando um determinado provedor envia o ZKP calculado para o contrato em nível de cadeia, ele precisa enviar uma transação L1. Quando essa transação é transmitida para o pool de transações, os invasores podem ver os dados de prova originais e podem definir uma taxa de gás mais alta para enviar uma transação, sendo assim o primeiro a ser agrupado em um bloco e ganhar recompensas de PoW.

Além disso, como os provadores competem entre si com base no poder computacional, não há um mecanismo confiável de reconhecimento de identidade e também é difícil estabelecer um mecanismo de comunicação. Diferentes mineradores podem executar trabalho duplicado, resultando em desperdício de energia computacional.

Envio em duas etapas do ZKP

Etapa 1: enviar hash

• Depois que um provador calcula um ZKP para uma determinada sequência, ele primeiro calcula o hash de (prova/endereço) e envia o hash e o endereço para o contrato inteligente no nível da cadeia. Aqui, a prova é uma prova de conhecimento zero para uma determinada sequência, e o endereço é o endereço do provador.

  
  

• Supondo que o primeiro provador submeta o hash do ZKP no bloco T, ele é aceito até o bloco T+10 sem limite. A partir do bloco T+11, novos provadores não podem mais enviar o hash.

  
  

Passo 2: Enviar ZKP

• Após o bloco T+11, qualquer provador pode enviar um ZKP. Desde que um ZKP passe na verificação, ele pode ser usado para verificar todos os hashes enviados. Os provadores validados recebem recompensas PoW com base na proporção dos valores apostados pelos mineradores.

  
  

• Se nenhum ZKP passar na verificação antes do bloco T+20, todos os provadores que enviaram hashes serão cortados. A sequência é então reaberta e novos hashes podem ser enviados, retornando ao Passo 1.

  
  

Aqui está um exemplo: vamos supor que cada bloco tenha uma recompensa PoW de 128 IDE na rede Opside e que atualmente haja 64 slots de rollup disponíveis. Portanto, cada sequência de roll-up recebe uma recompensa PoW de 2 IDE. Se três mineradores, A, B e C, enviarem com sucesso o ZKP correto para uma sequência em sucessão, as apostas (IDE) dos três mineradores serão 200K, 500K e 300K, respectivamente. Então, A, B e C podem ganhar uma recompensa PoW de 0,4 IDE, 1 IDE e 0,6 IDE, respectivamente.

Aposta e punição do token do provador

Para evitar comportamento malicioso do provador, o provador precisa se registrar com um contrato de sistema especial e apostar uma certa quantidade de tokens. Se o valor da aposta atual for menor que o limite, o provador não poderá enviar o hash e o ZKP. A recompensa pelo envio do ZKP pelo provador será distribuída com base na proporção do valor da aposta, evitando que o provador envie vários ZKPs.

Se o provador cometer as seguintes ações, diferentes níveis de punição serão aplicados:

• O provador envia um hash incorreto.
• Para uma determinada sequência, se nenhum ZKP correspondente passar na verificação, todos os provadores que enviaram hashes serão punidos.
• O token perdido será queimado.

Para mais detalhes e considerações sobre o mecanismo de submissão em duas etapas do ZKP, os leitores são encorajados a consultar os documentos oficiais da Opside. Os números específicos da aposta e punição do provador podem ser alterados no futuro.

Várias considerações:

• Por que permitir que vários provadores enviem hashes? Se apenas o primeiro provador a enviar um hash for recompensado, outros provadores podem não ter incentivo para enviar provas depois que o primeiro provador enviar um hash. Se um invasor mal-intencionado atrasar o envio da prova por muito tempo após o envio de um hash, ele poderá retardar a verificação de toda a sequência. Portanto, é necessário permitir que vários provadores enviem hashes de forma independente e simultânea para evitar o monopólio da verificação do ZKP por um único invasor.

  
  

• Por que existe uma janela de tempo? Se alguém puder enviar a prova imediatamente após enviar um hash, a prova ainda poderá ser roubada. Os invasores podem enviar imediatamente um hash associado ao seu endereço e, em seguida, enviar a prova para ganhar recompensas. Ao definir uma janela de tempo, os provadores que enviaram hashes não têm incentivo para enviar provas dentro da janela, evitando assim a possibilidade de serem disputados.

  
  

• Por que a recompensa é alocada com base na aposta? Vários provadores podem enviar hashes para a mesma sequência em uma janela de tempo. Na verdade, os mineradores podem enviar vários hashes usando a prova gerada (só precisa de vários endereços). Isso pode fazer com que a maioria ou mesmo todas as recompensas do PoW sejam tomadas pelos mineradores. Para evitar esse ataque, a recompensa por uma sequência será alocada com base na proporção do valor da aposta do minerador.

  
  

Resumo e Planejamento

O algoritmo de envio de duas etapas para ZKPs proposto neste post realiza a descentralização do provador, evitando efetivamente ataques de corrida e incentivando mais mineradores a fornecer poder computacional ZKP estável e contínuo. A versão inicial do algoritmo será lançada na rede de teste pré-alfa Opside.

No futuro, a Opside também apresentará ideias mais inovadoras no campo da mineração ZKP, como:

• Ajuste dinâmico da taxa de alocação de recompensa entre PoS e PoW com base na demanda e no fornecimento de poder computacional ZKP em toda a rede.
• Mecanismo de precificação personalizado para lotes Rollup com base no tipo de ZK-Rollup, número de transações Rollup e uso de gás do Rollup.
• Subsídios para desenvolvedores de aplicativos gerarem ZKPs para seus Rollups associados para incentivar os mineradores a fornecer poder computacional.