Prova Descentralizada Curvy – Criptografia

Exploramos uma arquitetura de prova descentralizada para Curvy, um protocolo de preservação de privacidade baseado em UTXOs de endereço furtivo e agregação ZK. Identificamos um problema decorrente de atualizações de estado simultâneas em uma raiz Sparse Merkle Tree (SMT) compartilhada e propomos um mecanismo de sequenciamento baseado em slot na cadeia para provadores. Analisamos os riscos de negação de serviço introduzidos por esta abordagem e propomos a participação apoiada por garantias e solicitamos a limitação como mitigações.

O protocolo Curvy permite transferências privadas usando transferências de endereços furtivas e provas ZK. Como cada transferência recebida termina em um endereço furtivo diferente, o Curvy permite a agregação de fundos usando um agregador ZK sem revelar a origem dos fundos ao público. No entanto, um único provador centralizado seria capaz de reunir informações sobre todas as seções do gráfico de transações, reconstruindo assim as origens de todos os fundos. Para evitar esse tipo de vazamento de privacidade, estamos investigando provadores descentralizados que podem criar individualmente suas próprias provas de agregação ou enviar provas em lote de vários usuários.

Os fundos de transferências furtivas são representados de forma UTXO como notas. Cada nota é armazenada em um SMT e a raiz SMT atual é mantida no contrato inteligente do agregador. Nota IDs (folhas de árvores) são emitidos através de eventos. Cada cliente pode ouvir eventos e reconstruir a árvore. A agregação é um processo no qual as notas existentes são destruídas e novas notas são criadas, tendo o saldo das notas de saída igual à soma de todos os saldos das notas de entrada. Cada agregação cria novas notas e atualiza a árvore de notas, apoiada pela prova ZK que atesta a correção da atualização.

O cálculo da prova de agregação requer o fornecimento da raiz SMT antiga e da nova, calculada depois que todas as novas notas forem inseridas corretamente. Devido à natureza sequencial das atualizações de raiz na cadeia, se vários provadores tentarem modificar o SMT com base na mesma raiz antiga, apenas o primeiro provador seria capaz de realizar a operação com sucesso, enquanto as transações de todos os outros provadores seriam revertidas. Mesmo que um provador seja de facto o primeiro a submeter a transacção, a ordenação não determinística da transacção pode fazer com que a transacção do provador não seja a primeira num bloco, e a transacção pode ser revertida. A transação revertida com apenas dois valores raiz (antigos e novos) e dados de prova Groth16 em calldata custa aproximadamente 33.000 gás. Mesmo que o custo não seja significativamente elevado, a repetição da transação não garante o sucesso, mesmo com as raízes atualizadas e as provas correspondentes.

Para mitigar as colisões que resultam em múltiplos provadores referindo-se ao mesmo estado antigo, propomos a introdução de uma fila de solicitações na cadeia, onde os provadores primeiro solicitariam um intervalo de tempo no qual poderiam enviar suas atualizações de estado. Um intervalo de tempo refere-se a um intervalo (fromBlockNumber, paraBlockNumber) associado a um determinado remetente de mensagem. Os provadores podem enviar suas provas somente quando o número do bloco atual estiver dentro do intervalo de tempo.

Dessa forma, a sequência natural de atualizações é mantida na cadeia e os provadores podem determinar seu espaço de prova. O tempo de espera também é conhecido antecipadamente, o que significa que os provadores podem economizar tempo em pesquisas constantes de estado e escuta de eventos. A operação de “cadastro” é uma operação de baixo custo em comparação à reversão de transações que carregam o comprovante ZK e dados públicos. Esta solução evita colisões, mas permite ataques DOS ao contrato inteligente, fazendo com que usuários mal-intencionados ocupem um grande número de slots usando fundos relativamente pequenos.

Os intervalos de tempo ignorados não são reutilizáveis. Se um provador errar o slot determinado, um novo slot deverá ser solicitado. O prazo de um slot precisa ser estimado adequadamente. O horário de início do slot precisa ser atrasado pelo menos o tempo necessário para gerar a prova Groth16, enquanto o horário de término precisa fornecer um buffer adequado, levando em consideração a latência da rede. Os valores exatos ainda não foram determinados. Sobreposições de slots não são permitidas.

Se um provador, por algum motivo, enviar uma prova inválida, a vaga permanece ativa até o prazo final da vaga, permitindo ao provador enviar a prova corrigida.

Provadores apoiados por garantias

A fonte da possibilidade de ataque DOS está no baixo custo das solicitações de slot. Adicionar um custo extra a todas as solicitações pode ser uma solução teórica, mas a experiência do usuário e os custos cumulativos de comprovação prejudicam os benefícios gerais da comprovação descentralizada. Consideramos exigir que cada provador forneça uma garantia única antes de solicitar um intervalo de tempo. A garantia não seria perdida, mas sim bloqueada até que os provadores decidissem parar de provar e retirar a sua garantia. Dessa forma, a barreira de entrada tem maiores custos de pontualidade, mas elimina uma parcela de provadores maliciosos que podem ultrapassar a barreira. Além disso, cada provador honesto receberia uma taxa de todos os fundos agregados nas provas apresentadas, tornando o comportamento honesto ainda mais incentivado.

Limitação de solicitações

A garantia atua como um token de adesão ao serviço de comprovação, mas uma vez ingressado, um provador ainda pode enviar spam para a fila de solicitações. Para mitigar esta situação, os pedidos são limitados para que os provadores possam submeter apenas um determinado número de pedidos num determinado período de tempo (ou seja, uma vez em 10 minutos). Para poder solicitar faixas horárias com mais frequência, a garantia exigida teria de ser mais elevada. Se um intervalo de tempo de solicitação por um determinado período custar X, k slots teriam um custo linearmente maior de kX. A limitação seria implementada em nível de contrato inteligente, rastreando o tempo de envio da última solicitação de cada provador com garantia depositada.

Visibilidade dos dados

No protocolo descrito, cada provador necessitará de conhecimento de insumos privados para a construção de provas ZK. Se um provador estiver prestando serviços de comprovação a outros usuários, ele poderá ver determinadas informações divulgadas. Em geral, ele estará ciente de um segmento do gráfico da transação. Sem o conhecimento de todas as transações na cadeia, desde os depósitos até aos levantamentos, a origem e o destino dos fundos permanecerão indetectáveis ​​para o provador.