CRS (Common Reference String)

O que é CRS (Common Reference String)?

CRS significa Common Reference String, um conjunto compartilhado de parâmetros criptográficos públicos usado por um sistema de provas de conhecimento zero.

No universo das criptomoedas, CRS é mencionado com mais frequência em relação a zk-SNARKs, protocolos de privacidade, provas de validade, zk-rollups, compromissos polinomiais e sistemas de escalabilidade de blockchain.

Um CRS oferece uma base comum ao provador e ao verificador, permitindo criar e verificar uma prova sem que o provador revele informações privadas.

O provador usa o CRS para gerar uma prova, e o verificador usa o mesmo CRS para conferir se ela é válida.

O guia da ethereum.org sobre provas de conhecimento zero explica que os parâmetros públicos usados em alguns sistemas de conhecimento zero são conhecidos coletivamente como Common Reference String.

Um CRS não é uma senha, chave privada, frase de recuperação de carteira ou segredo do usuário.

Em geral, ele é uma informação pública, mas o processo de geração pode ser extremamente sensível.

Se o CRS for criado de forma honesta e o material secreto da configuração for destruído, o sistema de provas poderá funcionar como previsto.

Se o CRS for criado de forma desonesta ou o material secreto da configuração for mantido, alguns sistemas de provas poderão permitir a criação de provas falsas.

Por isso, a segurança do CRS é uma das premissas de confiança mais importantes em muitos sistemas de conhecimento zero usados em cripto.

Por que o CRS é importante em cripto

O CRS é importante porque as provas de conhecimento zero são hoje uma tecnologia central para privacidade, escalabilidade, identidade e computação verificável em blockchain.

Uma prova de conhecimento zero permite demonstrar que uma afirmação é verdadeira sem revelar os dados ocultos que a fundamentam.

Em cripto, isso pode significar provar que uma transação privada é válida, que um lote de transações off-chain foi calculado corretamente ou que um usuário atende a uma regra sem revelar todos os seus dados pessoais.

Muitos sistemas zk-SNARK eficientes precisam de parâmetros públicos antes que as provas possam ser geradas e verificadas.

Esses parâmetros públicos são o CRS ou uma estrutura relacionada, como uma Structured Reference String.

A discussão da ZKProof sobre cerimônias de configuração explica que os zk-SNARKs dependem de um CRS como parâmetro público para gerar e verificar provas.

Isso torna a qualidade do CRS importante tanto para desenvolvedores quanto para usuários.

Os desenvolvedores precisam saber se o CRS corresponde ao circuito, ao sistema de provas e ao modelo de segurança.

Os usuários precisam saber se um protocolo depende de uma configuração confiável, de uma configuração universal, de uma cerimônia atualizável ou de um sistema de provas transparente que dispensa uma configuração confiável.

Para investidores e traders de cripto, o CRS pode parecer um tema técnico, mas pode afetar a credibilidade de privacy coins, zk-rollups, bridges, sistemas de provas e aplicativos tokenizados.

Como funciona um CRS

Um CRS funciona fornecendo a todos os participantes de um sistema de provas os mesmos dados públicos de referência.

O provador usa esses dados de referência para transformar um testemunho privado e uma afirmação pública em uma prova compacta.

O verificador usa os mesmos dados para conferir se a prova foi gerada de acordo com as regras do sistema.

A afirmação pública é a alegação que será verificada.

O testemunho privado é a informação oculta que torna a afirmação verdadeira.

Por exemplo, um usuário pode provar que uma transação segue as regras do protocolo sem revelar todos os detalhes da transação privada.

O CRS ajuda o sistema de provas a relacionar a afirmação matemática, o testemunho privado e o algoritmo de verificação.

Em muitos sistemas zk-SNARK, o CRS é criado antes que os usuários comuns gerem provas.

Essa etapa de configuração pode ser específica para um circuito ou suficientemente ampla para oferecer suporte a vários circuitos.

Os detalhes dependem do sistema de provas, das premissas criptográficas e do design da implementação.

O CRS deve ser gerado, armazenado, publicado e verificado de forma a reduzir a possibilidade de manipulação oculta.

CRS, SRS e parâmetros públicos

CRS é frequentemente usado como termo abrangente para dados públicos de referência empregados em um sistema de provas.

SRS significa Structured Reference String e geralmente se refere a uma string de referência com uma estrutura algébrica específica.

Parâmetros públicos é uma expressão mais geral que pode incluir CRS, SRS, chaves de prova, chaves de verificação e outros resultados da configuração.

Em conversas informais sobre cripto, às vezes CRS e SRS são usados como se significassem a mesma coisa.

Em textos mais técnicos, SRS costuma ser um tipo específico de CRS usado por determinados SNARKs ou esquemas de compromisso polinomial.

O guia da ZKDocs sobre compromissos polinomiais KZG descreve parâmetros públicos pré-gerados para compromissos KZG e observa que eles às vezes são chamados de Structured Reference String.

Essa diferença é importante porque nem todos os sistemas de provas usam o mesmo tipo de material de configuração.

Alguns sistemas precisam de um CRS específico para cada circuito.

Outros usam um SRS universal, capaz de oferecer suporte a vários circuitos até um tamanho definido.

Há ainda sistemas transparentes que não precisam de uma cerimônia de configuração confiável.

Um desenvolvedor cuidadoso deve sempre verificar o que o projeto entende por CRS, SRS, parâmetros de configuração, chave de prova e chave de verificação.

Configuração confiável e CRS

Uma configuração confiável é um processo usado para gerar o CRS em alguns sistemas de provas de conhecimento zero.

O termo “confiável” é usado porque os participantes precisam confiar que a configuração foi realizada corretamente e que toda aleatoriedade secreta foi destruída.

Esse material secreto de configuração costuma ser chamado de toxic waste.

Se o toxic waste permanecer com um invasor, ele poderá conseguir criar provas falsas em alguns sistemas.

Isso não significa que todo CRS seja inseguro.

Significa que a segurança de alguns sistemas baseados em CRS depende da integridade do processo de configuração.

Uma única parte pode realizar uma configuração confiável, mas isso cria um forte problema de confiança.

Os sistemas modernos costumam preferir cerimônias com vários participantes, pois elas reduzem a dependência de um único agente.

Em muitas cerimônias de configuração com vários participantes, a segurança pode ser mantida se pelo menos um participante honesto contribuir com aleatoriedade e destruir sua contribuição secreta.

Por isso, as cerimônias públicas geralmente buscam maximizar a participação, a transparência, a reprodutibilidade e a verificação independente.

Para os usuários de cripto, a questão principal não é apenas saber se existe um CRS, mas também como ele foi criado.

Cerimônia de computação multipartidária

Uma cerimônia de computação multipartidária é um processo de configuração em que vários participantes independentes contribuem com aleatoriedade para criar o CRS.

O objetivo é evitar que uma única pessoa, empresa, grupo de validadores ou equipe de desenvolvimento detenha todo o segredo da configuração.

Cada participante adiciona entropia à cerimônia e depois destrói sua contribuição privada.

Em muitos modelos de cerimônia, o CRS final pode permanecer seguro se pelo menos um participante agir honestamente.

Esse modelo é usado com frequência quando um sistema de provas precisa de uma configuração confiável, mas a comunidade quer reduzir a confiança em uma única parte.

A cerimônia KZG do Ethereum é um exemplo conhecido em cripto de um processo público usado para gerar material de configuração para compromissos KZG.

O resumo da cerimônia KZG da Ethereum Foundation descreve a cerimônia como um processo público que apoiou a base criptográfica da EIP-4844.

Uma cerimônia deve publicar informações suficientes para que outras pessoas possam auditar o processo.

Um bom design de cerimônia também inclui proteções contra contribuições maliciosas, aleatoriedade fraca, comprometimento de software e riscos de coordenação centralizada.

Uma cerimônia robusta não torna um sistema livre de riscos, mas pode reduzir o nível de confiança exigido do CRS.

CRS e zk-SNARKs

zk-SNARK significa Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (argumento de conhecimento sucinto, não interativo e de conhecimento zero).

Muitos sistemas zk-SNARK são rápidos de verificar e produzem provas pequenas, o que os torna úteis para blockchains.

Provas pequenas são importantes porque o armazenamento e a verificação em blockchain podem ter custos elevados.

Provas não interativas são importantes porque o provador pode criar uma prova uma única vez e publicá-la para que qualquer pessoa a verifique depois.

Em muitas construções SNARK, o CRS ajuda a viabilizar esse modelo não interativo.

Sem os parâmetros corretos de configuração, o provador e o verificador talvez não compartilhem a referência matemática necessária para criar e validar a prova.

Diferentes famílias de SNARK tratam os requisitos de CRS de maneiras distintas.

Alguns sistemas mais antigos exigem uma configuração confiável separada para cada circuito.

Alguns sistemas mais recentes usam modelos de configuração universais ou atualizáveis.

Alguns sistemas de provas reduzem ou eliminam a necessidade de uma configuração confiável por meio de designs criptográficos diferentes.

Por isso, um projeto cripto não deve simplesmente dizer que usa zk-SNARKs e encerrar a explicação.

Ele deve explicar o modelo de configuração, o tipo de CRS, o processo de auditoria e o caminho de atualização.

CRS e zk-rollups

Um zk-rollup é um sistema de escalabilidade de blockchain que usa provas de validade para demonstrar que lotes de transações off-chain foram processados corretamente.

A documentação da ethereum.org sobre zk-rollups explica que um CRS pode ser necessário para um protocolo ZK-SNARK, pois fornece parâmetros públicos para gerar e verificar provas de validade.

Em um zk-rollup, um provador cria uma prova para várias transações de uma só vez.

A blockchain base verifica a prova em vez de executar novamente cada transação do lote.

Isso pode reduzir a quantidade de dados e de processamento necessária na camada base.

Se o rollup usar um sistema de provas baseado em CRS, o CRS fará parte das premissas de confiança e segurança do rollup.

Os usuários devem verificar se o rollup usa uma configuração confiável, se ela foi específica para um circuito e se futuras atualizações exigirão novas cerimônias.

Um CRS inadequado ou comprometido pode enfraquecer o sistema de provas de validade.

Um processo de configuração robusto pode reforçar a confiança de que será difícil falsificar as provas do rollup.

Por isso, o design do CRS não é apenas um tema acadêmico: ele pode afetar os fundos reais dos usuários em sistemas de escalabilidade.

CRS e compromissos KZG

Os compromissos KZG são um tipo de esquema de compromisso polinomial usado em pesquisas e implementações modernas de escalabilidade de blockchain.

Um compromisso polinomial permite que uma parte se comprometa com um polinômio e, posteriormente, prove afirmações sobre seus valores sem revelar o polinômio inteiro.

Isso é útil em disponibilidade de dados, escalabilidade de rollups e sistemas de provas, pois permite verificar estruturas de dados grandes de forma compacta.

A EIP-4844 introduziu transações que transportam blobs e usam compromissos e provas KZG como parte do roteiro de escalabilidade do Ethereum.

A especificação da EIP-4844 descreve as transações com blobs e a verificação de provas KZG no design do protocolo.

Os compromissos KZG dependem de material estruturado de configuração.

Esse material costuma ser chamado de SRS, que pode ser entendido como uma forma especializada de CRS.

A segurança de sistemas baseados em KZG depende da destruição de determinada aleatoriedade secreta da configuração durante o processo.

Por isso, as cerimônias KZG recebem tanta atenção na engenharia de cripto.

Um SRS KZG não é apenas um arquivo técnico: ele pode ser uma dependência criptográfica de longo prazo para os aplicativos que o utilizam.

CRS universal e CRS específico para circuitos

Um CRS específico para um circuito é gerado para um circuito ou cálculo específico.

Se o circuito mudar, o projeto talvez precise de uma nova configuração.

Isso pode ser inconveniente, pois aplicativos blockchain costumam ser atualizados ao longo do tempo.

Um CRS ou SRS universal pode oferecer suporte a vários circuitos até determinado limite de tamanho ou complexidade.

Isso pode facilitar o desenvolvimento, pois muitos aplicativos podem reutilizar o mesmo material de configuração.

Um CRS atualizável permite que novos participantes adicionem aleatoriedade após a configuração original.

Isso pode aumentar a confiança, pois a configuração pode receber novas contribuições ao longo do tempo.

Os modelos universais e atualizáveis ganharam importância porque reduzem o trabalho operacional de realizar repetidas cerimônias de configuração confiável.

No entanto, “universal” não significa ilimitado.

Um CRS universal normalmente tem limites, premissas, curvas compatíveis, tamanhos máximos de circuito e regras de implementação.

Os desenvolvedores ainda precisam verificar se o CRS é adequado ao aplicativo que estão criando.

Sistemas de provas transparentes e CRS

Um sistema de provas transparente não exige uma cerimônia de configuração confiável.

Em vez disso, pode usar aleatoriedade pública, funções hash ou outras construções que evitam material secreto de configuração.

Os zk-STARKs são frequentemente descritos como transparentes porque não exigem uma configuração confiável de CRS da mesma forma que muitos zk-SNARKs.

Esse é um dos motivos pelos quais sistemas baseados em STARK são atraentes para alguns aplicativos blockchain.

A contrapartida é que sistemas transparentes podem ter tamanhos de prova, custos de verificação, custos para o provador ou requisitos de implementação diferentes.

Um sistema sem configuração confiável não é automaticamente melhor para todos os casos de uso.

Um SNARK baseado em CRS pode oferecer provas menores e verificação eficiente.

Um sistema de provas transparente pode reduzir a confiança na configuração, mas apresentar outras contrapartidas de desempenho.

Um bom design de protocolo compara as premissas de segurança, o custo, o desempenho, as ferramentas para desenvolvedores, a qualidade das auditorias e a facilidade de manutenção a longo prazo.

Para os usuários, a ideia principal é simples: alguns sistemas ZK precisam de um CRS, enquanto outros foram projetados para evitar um CRS confiável.

Riscos de segurança do CRS

O maior risco relacionado ao CRS é uma configuração comprometida.

Se o material secreto da configuração não for destruído, um invasor poderá conseguir falsificar provas em alguns sistemas.

O risco de falsificação pode ser grave porque uma blockchain pode aceitar como válida uma prova falsa.

Em um sistema de pagamentos, isso pode ameaçar as regras de saldo privado ou a validade de transações protegidas.

Em um rollup, pode comprometer a correção das transições de estado off-chain.

Em uma bridge, pode comprometer as declarações sobre depósitos, saques ou o estado entre blockchains.

Outro risco é usar o CRS errado para o circuito ou sistema de provas errado.

Uma incompatibilidade entre CRS, circuito, chave de prova, chave de verificação e implementação pode comprometer a segurança ou impedir que as provas sejam verificadas.

Um terceiro risco é a falta de transparência da cerimônia.

Se os usuários não puderem verificar como o CRS foi gerado, terão de confiar nas afirmações da equipe do projeto.

Um quarto risco é a falta de rigor no software durante a configuração.

Malware, aleatoriedade defeituosa, backdoors ocultos ou processos de compilação inseguros podem comprometer a cerimônia.

Por isso, a segurança do CRS é tanto um problema criptográfico quanto um problema de segurança operacional.

Como os desenvolvedores usam um CRS

Os desenvolvedores usam um CRS ao criar aplicativos que dependem da geração e verificação de provas.

O CRS pode ser baixado de uma versão confiável, gerado por meio de uma cerimônia, incorporado ao software ou referenciado em uma especificação de protocolo.

O software do provador usa o material de configuração para gerar provas válidas para um circuito.

O software do verificador usa material de verificação relacionado para conferir as provas com eficiência.

Em sistemas de contratos inteligentes, a chave de verificação pode ser incluída em um contrato verificador on-chain.

Isso permite que a blockchain verifique a validade da prova sem ver o testemunho privado.

Os desenvolvedores precisam garantir que o CRS venha da cerimônia correta e corresponda exatamente à versão do sistema de provas utilizada.

Também devem conferir hashes, assinaturas, compilações reproduzíveis, documentação oficial e relatórios de auditoria.

Uma pequena incompatibilidade na configuração pode causar falhas de verificação, desperdício de gas, aplicativos inoperantes ou segurança mais fraca.

Por isso, sistemas ZK em produção tratam arquivos de configuração como infraestrutura crítica.

CRS e privacy coins

Historicamente, o CRS foi importante para sistemas de criptomoedas voltados à privacidade que usavam zk-SNARKs.

Protocolos de privacidade podem usar provas de conhecimento zero para demonstrar a validade de transações protegidas sem expor detalhes confidenciais.

Os primeiros designs eficientes de zk-SNARK frequentemente dependiam de cerimônias de configuração confiável.

A Zcash é um dos exemplos mais conhecidos de projeto de criptomoeda que tornou a configuração confiável e sua posterior remoção temas importantes de pesquisa.

A explicação da Zcash sobre zk-SNARKs observa que a Zcash introduziu o protocolo de pagamentos protegidos Orchard com Halo 2 e descreve Halo como uma solução que elimina a configuração confiável e oferece suporte a pagamentos digitais privados.

Essa evolução mostra por que o design do CRS muda com o tempo.

Sistemas iniciais podem aceitar uma configuração confiável para obter provas pequenas e desempenho prático.

Sistemas posteriores podem adotar designs de prova que reduzem a confiança na configuração ou a eliminam de partes importantes do protocolo.

Para os usuários, a lição importante é avaliar as afirmações de privacidade em conjunto com as premissas de configuração.

Um protocolo de privacidade robusto deve explicar tanto o que oculta quanto as premissas de confiança de que depende.

CRS e atualizações de blockchain

Atualizações de blockchain podem criar desafios relacionados ao CRS, pois novos circuitos ou sistemas de provas talvez exijam novo material de configuração.

Se um protocolo alterar as regras de transação, o design de escalabilidade ou o sistema de provas, o CRS antigo poderá não ser mais suficiente.

Uma configuração específica para um circuito pode exigir uma nova cerimônia para uma atualização importante.

Uma configuração universal pode oferecer mais flexibilidade, mas ainda tem limites.

As equipes de protocolo precisam planejar como as mudanças de configuração serão propostas, auditadas, executadas, publicadas e ativadas.

A governança também é importante, pois os usuários precisam ter confiança de que uma atualização não introduzirá silenciosamente premissas de prova mais fracas.

Um bom processo de atualização deve documentar a configuração antiga, a nova configuração, os riscos de migração e as mudanças na verificação.

Em sistemas descentralizados, a análise da comunidade é importante porque mudanças no CRS podem afetar todos os usuários que dependem da validade das provas.

Isso é especialmente relevante para sistemas que protegem depósitos, saques, saldos privados ou raízes de estado de rollups.

Por isso, a governança do CRS faz parte da segurança de longo prazo em cripto.

Como avaliar um projeto cripto baseado em CRS

A primeira pergunta é se o projeto usa um sistema de provas baseado em CRS.

A segunda é se o CRS foi gerado por uma única parte ou por meio de uma cerimônia pública com vários participantes.

A terceira é se a configuração é específica para um circuito, universal ou atualizável.

A quarta é se a transcrição da cerimônia, o software, os parâmetros e as instruções de verificação são públicos.

A quinta é se pesquisadores independentes ou auditores analisaram a configuração e o sistema de provas.

A sexta é se futuras atualizações exigirão uma nova configuração.

A sétima é se os usuários podem comparar os hashes dos parâmetros com as versões oficiais.

A oitava é se o projeto explica as consequências de uma configuração comprometida.

A nona é se o sistema tem um plano de resposta emergencial para vulnerabilidades no sistema de provas.

A décima é se o sistema de provas é adequado ao valor protegido pelo protocolo.

Essas perguntas ajudam os usuários a ir além das afirmações de marketing e avaliar as premissas criptográficas reais.

Equívocos comuns sobre CRS

Um equívoco é achar que um CRS precisa permanecer secreto.

Na maioria dos sistemas de provas, o CRS é público; o risco vem da aleatoriedade secreta usada na configuração, que deve ser destruída.

Outro equívoco é achar que todos os sistemas de conhecimento zero precisam de uma configuração confiável.

Alguns sistemas de provas são transparentes e dispensam cerimônias de configuração confiável.

Um terceiro equívoco é achar que um único CRS serve para todos os aplicativos.

Um CRS pode estar vinculado a um sistema de provas, uma curva, um tamanho de circuito ou um design de aplicativo específico.

Um quarto equívoco é achar que uma configuração confiável é automaticamente insegura.

Uma cerimônia multipartidária bem projetada pode reduzir a necessidade de confiança se pelo menos uma contribuição honesta permanecer desconhecida dos invasores.

Um quinto equívoco é achar que os usuários não precisam se preocupar com o CRS porque ele é um tema exclusivo para desenvolvedores.

Na realidade, o CRS pode afetar a segurança de um protocolo de privacidade, rollup, bridge ou aplicativo baseado em provas.

Perguntas frequentes

O que significa CRS em cripto?

CRS significa Common Reference String, ou string de referência comum, um conjunto de dados públicos de referência usado por alguns sistemas de provas de conhecimento zero para gerar e verificar provas.

CRS é igual a SRS?

CRS é o termo mais amplo, enquanto SRS geralmente é uma forma estruturada de CRS usada por determinados SNARKs e esquemas de compromisso polinomial.

Por que os zk-SNARKs precisam de um CRS?

Muitos zk-SNARKs precisam de um CRS para que o provador e o verificador compartilhem parâmetros públicos que permitam gerar e verificar provas não interativas.

O CRS é privado?

Não. Em geral, o CRS é público, mas a aleatoriedade secreta usada para gerá-lo precisa ser destruída em sistemas com configuração confiável.

O que é toxic waste em uma configuração confiável?

Toxic waste é o material secreto da configuração que, se mantido por um invasor, pode permitir a criação de provas falsas em alguns sistemas.

O que é uma cerimônia CRS?

Uma cerimônia CRS é um processo de configuração em que um ou mais participantes geram a string pública de referência para um sistema de provas.

Por que são usadas cerimônias multipartidárias?

As cerimônias multipartidárias são usadas para reduzir a dependência de um único participante confiável durante a geração do CRS.

Os zk-STARKs precisam de um CRS confiável?

Em geral, os zk-STARKs são descritos como sistemas de provas transparentes porque não exigem um CRS de configuração confiável como muitos sistemas zk-SNARK.

Um CRS inadequado pode colocar fundos cripto em risco?

Sim. Um CRS comprometido pode ser perigoso se o protocolo aceitar provas forjadas que afetem saldos, saques, declarações de bridges ou o estado de um rollup.

Como os usuários podem verificar as premissas de confiança do CRS?

Os usuários podem consultar a documentação do projeto, as transcrições da cerimônia, os hashes dos parâmetros, as auditorias, os detalhes do sistema de provas e os procedimentos de atualização.

Conclusão

CRS (Common Reference String) é um conceito fundamental da criptografia de conhecimento zero e um tema importante de segurança para os sistemas cripto modernos.

Ele fornece parâmetros públicos compartilhados que permitem aos provadores criar provas e aos verificadores conferi-las.

Em muitos sistemas zk-SNARK, o CRS é criado por meio de uma configuração confiável, o que exige um processo de configuração robusto e transparente.

Se o material secreto da configuração for destruído e a cerimônia for bem projetada, um sistema baseado em CRS poderá oferecer verificação eficiente e compacta de provas.

Se o material secreto da configuração for comprometido, alguns sistemas poderão ficar vulneráveis à falsificação de provas.

Por isso, o design do CRS é importante para protocolos de privacidade, zk-rollups, compromissos KZG, bridges, sistemas de identidade e outros aplicativos cripto baseados em provas.

O principal é entender que o CRS geralmente é público, mas é preciso compreender a confiança depositada no processo de geração.

Quem avalia um projeto cripto de conhecimento zero deve perguntar como o CRS foi criado, se a configuração é confiável ou transparente, se é universal ou específica para um circuito e como futuras atualizações tratarão os parâmetros de prova.