Segurança e desempenho SNARK

Um SNARK (Sucinct Non-Interactive Argument of Knowledge) é uma ferramenta criptográfica que abre novas e excitantes possibilidades no design do sistema, especialmente em configurações descentralizadas. SNARKs permitem que os dados sejam processados ​​por entidades não confiáveis, que podem então provar que os dados são válidos e foram processados ​​corretamente. Uma maneira ingênua de provar isso seria publicar os dados, permitindo que qualquer pessoa que queira verificar sua validade e processá-los diretamente. 

Um SNARK alcança o mesmo efeito, mas com melhor custos para os validadores. Por exemplo, em um rollup verificável de camada dois (L2), um serviço de rollup processa transações de blockchain. O serviço publica periodicamente os saldos das contas de seus usuários no blockchain da camada um. Toda vez que ele publica uma atualização nos saldos, ele anexa uma prova SNARK de que conhece uma sequência de transações válidas que alteraram os saldos da conta antiga para os atualizados. Dessa forma, os validadores de blockchain não precisam fazer o trabalho árduo de verificar a validade da transação (por exemplo, verificar uma assinatura digital para cada transação) nem processar explicitamente as transações para calcular os saldos atualizados.  

My num post anterior focado no desempenho dos provadores SNARK – o principal determinante da aplicabilidade do SNARK. Embora a execução de um provador SNARK possa ser computacionalmente intensiva, na medida em que pode ser inviável gerar uma prova para cálculos em larga escala, a verificação SNARK é geralmente muito mais barata do que verificar e processar dados diretamente. No entanto, os custos de verificação SNARK variam consideravelmente. Este post descompacta esses custos e compara as propriedades de segurança de diferentes SNARKs. 

Em particular, explico que em SNARKs práticos com segurança pós-quântica plausível (PQ-SNARKs), há uma tensão significativa entre custos de segurança e verificação. Além disso, em alguns casos, essa tensão está sendo resolvida em favor dos custos de verificação em detrimento da segurança.

Para que os SNARKs realizem seu potencial, os sistemas implantados devem ser seguros e os usuários devem estar confiantes em sua segurança. Concluo o post propondo ações simples que a comunidade web3 pode tomar para ajudar a garantir que essas propriedades se mantenham a longo prazo. 

Medidas de segurança quantitativa 

Um SNARK é seguro se for computacionalmente inviável produzir uma prova convincente de uma declaração falsa. Por exemplo, no contexto de rollups de L2, um invasor que deseja roubar meus fundos gostaria de provar uma declaração falsa no formato: “Conheço uma transação assinada digitalmente que transfere todos os ativos de Justin para minha própria conta”. 

O nível de segurança de um SNARK é medido pela quantidade de trabalho que deve ser feito para encontrar uma prova convincente de uma declaração falsa. Semelhante a outras primitivas criptográficas, como assinaturas digitais, o logaritmo dessa quantidade de trabalho é chamado de “bits de segurança”. Por exemplo, 30 bits de segurança implicam que 2³⁰ ≈ 1 bilhão de “passos de trabalho” são necessários para atacar o SNARK. Isso é inerentemente uma medida aproximada de segurança do mundo real porque a noção de uma etapa do trabalho pode variar e considerações práticas como requisitos de memória ou oportunidades para paralelismo não são consideradas.

E os qualitativos

Bits de segurança é um quantitativo medida da segurança de um SNARK. SNARKs também diferem em suas qualitativo propriedades de segurança. 

Por exemplo, alguns SNARKs exigem uma cerimônia de configuração confiável para gerar uma chave de comprovação estruturada. SNARKs que não requerem uma configuração confiável são chamados transparente. 

Para que um SNARK não transparente seja seguro, normalmente pelo menos um participante da cerimônia deve ter se comportado honestamente, o que significa que eles produziram e descartaram um “alçapão” que, se combinado com os alçapões de todos os outros participantes, facilitaria para encontrar “provas” convincentes do SNARK de qualquer declaração falsa. As configurações confiáveis ​​são ser corrida com centenas ou milhares de participantes para tornar essa suposição o mais branda possível. 

SNARKs também diferem em sua suscetibilidade a ataques quânticos. Especificamente, muitos SNARKs (por exemplo, Groth16, PlonK, Marlin, Bulletproofs, nova) baseiam-se na suposição de que logaritmos discretos são difíceis de calcular (e, em alguns casos, suposições adicionais também). Computar logaritmos discretos é algo que os computadores quânticos seriam capazes de fazer com eficiência. Portanto, esses SNARKs não são seguros pós-quânticos (não-PQ). 

Enquanto esforços urgentes estão em andamento para mudar para pós-quântico esquemas de criptografia, isso é impulsionado principalmente pela necessidade de manter as mensagens criptografadas em segredo por muitas décadas no futuro. Um adversário que armazena uma mensagem interceptada hoje e aguarda a chegada de um computador quântico em, digamos, cinquenta anos, pode usar o computador para descriptografar a mensagem de cinquenta anos. A situação com SNARKs é bem diferente. O uso de SNARKs não-PQ hoje não deve comprometer a segurança das blockchains cinquenta anos no futuro, mesmo que os computadores quânticos cheguem nessa época. 

Compromissos polinomiais

Todos os SNARKs fazem uso de uma primitiva criptográfica conhecida como esquema de compromisso polinomial, e esse componente geralmente é um gargalo de desempenho. (Para detalhes, veja meu num post anterior.) Além disso, a transparência e a segurança pós-quântica plausível de um SNARK são determinadas apenas pelo esquema de compromisso polinomial que ele usa. 

Um exemplo proeminente é o chamado Compromissos polinomiais KZG, que são usados ​​por PlonK, Marlin, e muitos outros. Os compromissos da KZG não são transparentes nem seguros pós-quânticos. Outros esquemas de compromisso são transparentes, mas não pós-quânticos, incluindo Bulletproofs, hyrax e alfaquim. 

Ainda outros esquemas são transparentes e plausivelmente pós-quânticos. Esses incluem Sexta-feira , Ligero, Ligero++, Travar e Orion. Todos esses esquemas são baseados em códigos de correção de erros. Hashing é a única primitiva criptográfica que eles usam. Eles também compartilham a seguinte propriedade: os custos de verificação (medidos pelo número de avaliações de hash e operações de campo) crescem linearmente com o número de bits de segurança.

Grosso modo, uma única “iteração” desses compromissos polinomiais pós-quânticos atinge apenas um pequeno número (digamos 2-4) bits de segurança. Assim, o protocolo deve ser repetido muitas vezes para “amplificar” o nível de segurança, com os custos de verificação crescendo a cada repetição. Assim, para controlar os custos de verificação em PQ-SNARKs (e, portanto, os custos de gás em aplicativos blockchain), os designers de protocolo são incentivados a manter o nível de segurança baixo. 

Com raro exceções, essa tensão entre segurança concreta e custos de verificação não surge em SNARKs não PQ (transparentes e não transparentes). Os não-PQ-SNARKs usam grupos de curvas elípticas nos quais se presume que logaritmos discretos sejam difíceis de calcular e seus níveis de segurança são determinados pelo grupo usado. O tamanho do grupo de curvas elípticas apropriado e, portanto, o custo de cada operação de grupo, cresce com o nível de segurança desejado. No entanto, o número dos elementos do grupo em uma prova são independentes da escolha do grupo. 

Nos PQ-SNARKs, não apenas o tamanho das avaliações de hash cresce linearmente com o nível de segurança desejado, mas também o número de avaliações incluídas na prova e realizadas pelo verificador. 

Custos e segurança do verificador concreto em SNARKs implantados

Os custos concretos do verificador e os níveis de segurança dos SNARKs implantados variam consideravelmente. Seguem alguns exemplos ilustrativos:

Custos do verificador 

My num post anterior mencionou dois exemplos de custos de verificação concretos: PlonK custo de provas para 300,000 gás para verificar no Ethereum, enquanto as provas da StarkWare custam cerca de 5 milhões de gás. As provas do StarkWare são transparentes e plausivelmente pós-quânticas, enquanto as do PlonK não são. No entanto, conforme detalhado a seguir, as provas do StarkWare estão sendo executadas em um nível de segurança muito menor do que as provas do PlonK no Ethereum.

Segurança concreta

A única curva elíptica com pré-compilação do Ethereum é chamada de altbn128, então esta é a curva que todos os SNARKs não-PQ implantados no uso do Ethereum, incluindo asteca'areia zkSyncName's. Essa curva – e, portanto, também os SNARKs implantados que a usam – originalmente se acreditava oferecer aproximadamente 128 bits de segurança. Mas devido a ataques melhorados (cujo tempo de execução preciso é difícil determinar), a curva agora é amplamente considerada como oferecendo 100 a 110 bits de segurança. 

Existem EIPs para consideração introduzir pré-compilações para diferentes curvas que ainda oferecem cerca de 128 bits de segurança. Tais curvas são já usado nos SNARKs de projetos não-Ethereum, incluindo ZCash, Algorand, Dfinity, Filecoin e Aleo. 

Em contraste, de acordo com dados on-chain, os PQ-SNARKs da StarkWare (em seu chamado sistema SHARP, abreviação de SHARed Prover) foram configurados para atingir 80 bits de segurança. Esse nível de segurança é válido sob certas conjecturas sobre a solidez estatística do FRI (que abordarei mais adiante neste post). 

O termo “80 bits de segurança” é vago neste contexto, então deixe-me descompactá-lo. Grosso modo, isso significa que um invasor pode produzir uma prova convincente de uma declaração falsa avaliando uma função hash 2⁸⁰ vezes (ou seja, KECCAK-256, a função de hash usada pelo Ethereum). Para ser mais preciso, um invasor que está disposto a realizar 2^k avaliações de hash podem produzir uma prova convincente com uma probabilidade de aproximadamente 2^k-80. Por exemplo, com 2⁷⁰ avaliações de hash, pode-se encontrar uma “prova” SNARK de uma afirmação falsa com uma probabilidade de cerca de 2^-10 = 1 / 1024. 

Essa noção é mais fraca do que o termo “80 bits de segurança” significa em outros contextos. Por exemplo, uma função de hash resistente a colisões (CRHFs) configurada para 80 bits de segurança produziria saídas de 160 bits. Se a função hash for bem projetada, o procedimento mais rápido para encontrar colisões será o Ataque de aniversário, um procedimento de força bruta que pode encontrar uma colisão com cerca de 2^160/2 = 2⁸⁰ avaliações de hash. No entanto, com 2^k avaliações de hash, o ataque de aniversário encontrará uma colisão com uma probabilidade de apenas 2^2-160. 

Por exemplo, 2⁷⁰ avaliações de hash produzirão uma colisão com uma probabilidade de 2^-20  ≈ 1/1,000,000. Isso é muito menor do que a probabilidade de 1/1,000 de um invasor forjar uma prova PQ-SNARK configurada para 80 bits de segurança. 

Essa diferença pode alterar drasticamente a atratividade de realizar um ataque. Para ilustrar, imagine que um invasor tenha um orçamento de US$ 100 mil, que pode comprar 2⁷⁰ avaliações de hash. E suponha que, se o invasor for bem-sucedido, a recompensa seja de US$ 200 milhões. O valor esperado do ataque contra um PQ-SNARK configurado para 80 bits de segurança é (1/1,000) * US$ 200 milhões, ou US$ 200 mil – o dobro do custo. Se a probabilidade de sucesso fosse de apenas 1/1,000,000, como com um CRHF, o valor esperado do ataque seria de apenas US$ 200. 

As duas noções de “80 bits de segurança” também diferem drasticamente em sua robustez a ataques independentes. Por exemplo, suponha que 1,000 partes independentes ataquem o PQ-SNARK realizando 2⁷⁰ avaliações de hash. Como cada um é bem-sucedido com uma probabilidade de cerca de 1/1,000, pelo menos um deles é bem-sucedido. Este não seria o caso se cada um tivesse sucesso com uma probabilidade de apenas 1/1,000,000.

Espera-se que grupos de curvas elípticas bem projetadas se comportem de maneira semelhante aos CRHFs, com ataques semelhantes a aniversários, como algoritmo rho de Pollard sendo o mais conhecido. Isso significa que em um grupo que oferece 128 bits de segurança, 2^k operações de grupo devem produzir uma solução para uma instância do problema do logaritmo discreto com uma probabilidade de apenas 2^2-256. Por exemplo, 2⁷⁰ operações de grupo encontrariam um logaritmo discreto com apenas uma probabilidade astronomicamente pequena de 2^-116. Além disso, cada operação em grupo é mais lenta do que uma avaliação CRHF. 

Quantas avaliações de hash são viáveis ​​hoje?

Em janeiro de 2020, o custo de computação pouco menos de 2⁶⁴ As avaliações de SHA-1 usando GPUs foram $45,000. Isso coloca o custo de 2⁷⁰ Avaliações SHA-1 em GPUs em alguns milhões de dólares (talvez menor após a fusão do Ethereum, já que a transição da mineração de prova de trabalho dominada por GPU provavelmente diminuirá a demanda por computação de GPU, diminuindo seu custo). 

Com os rollups de validade já armazenando centenas de milhões de dólares em fundos de usuários, encontrar uma prova convincente de uma declaração falsa pode render muitos milhões de dólares em lucro. Configurar um PQ-SNARK em 80 bits de segurança sob conjecturas agressivas deixa menos de 10 bits de espaço de manobra entre ataques lucrativos e a segurança conjecturada do PQ-SNARK.

Como outro ponto de dados, a taxa de hash da rede do Bitcoin é atualmente de cerca de 2⁶⁴  avaliações de hash por segundo, o que significa que os mineradores de bitcoin como um todo realizam 2⁸⁰ Avaliações SHA-256 a cada 18 horas. Obviamente, esse número surpreendente se deve ao grande investimento em ASICs para mineração de bitcoin. 

Assumindo seis blocos de bitcoin criado por hora, e dada a recompensa de bloco atual de 6.25 Bitcoin por bloco, esses 2⁸⁰ As avaliações do SHA-256 provavelmente custam menos de US$ 22,000 * 18 * 6 * 6.25 ≈ US$ 15 milhões. Caso contrário, a mineração de bitcoin não seria lucrativa nos preços atuais. 

Ações propostas para um ecossistema saudável

O objetivo principal de usar SNARKs em rollups é alcançar a escalabilidade do blockchain sem que os usuários precisem confiar cegamente no serviço de rollup. Como o serviço de rollup escreveu o contrato inteligente que funciona como o verificador SNARK, o público deve ser capaz de inspecionar o contrato e confirmar que está de fato verificando as provas SNARK das declarações apropriadas. O escrutínio público do contrato inteligente também pode ser necessário para garantir que o serviço de rollup não seja capaz de censurar seus próprios usuários. Os métodos propostos para resistência à censura exigem que o contrato inteligente do rollup permita que os usuários forcem a retirada de seus fundos se o serviço de rollup não processar suas transações. 

Dada a natureza sofisticada desses protocolos, esse paradigma de escrutínio público sobrecarrega os especialistas para discutir aberta e abertamente a segurança dos contratos implantados. 

Mas com PQ-SNARKs, pode ser difícil até mesmo para especialistas determinar o nível de segurança do protocolo implantado pela mesma razão que a segurança e o desempenho do verificador estão em tensão para esses SNARKs: o nível de segurança (e os custos do verificador) dependem dos parâmetros internos do SNARK. E pelo menos para StarkWare smart contracts, esses parâmetros, called logBlowupFactor, ​​proofOfWorkBits e n_Queries, não são especificados diretamente no código do contrato inteligente, mas sim passados ​​para o contrato inteligente como dados públicos. Até onde eu sei, a maneira mais fácil de identificar esses parâmetros a partir de informações on-chain é por meio de um processo de quatro etapas: 

1. veja o contrato inteligente apropriado em um explorador de blocos como Etherscan, 
2. clique em um transação “verify proof” apropriada, 
3. decodificar os dados de entrada da transação e
4. descobrir como interpretar os dados de entrada decodificados para aprender os principais parâmetros SNARK que juntos determinam o nível de segurança. 

Esta etapa final requer encontrar o código Solidity apropriado para implementar a transação, o que pode ser uma tarefa confusa. (Quando eu estava preparando vistoria negociações em rollups neste verão, o Etherscan conseguiu decodificar os dados de entrada relevantes para as transações do verificador SHARP conforme a Etapa 2 acima. Mas isso não parece mais estar funcionando.)

Proposta 1: Escrutínio 

Com isso em mente, minha primeira sugestão para a comunidade web3 é tornar muito mais fácil examinar o nível de segurança dos SNARKs pós-quânticos implantados. Isso provavelmente envolve melhores ferramentas para entender os dados da cadeia e maior transparência pelos próprios projetos em tornar esses parâmetros conhecidos. 

Proposta 2: Normas mais fortes

80 bits de segurança é muito baixo, especialmente a versão fraca em que 2⁷⁰ as avaliações de hash são suficientes para atacar com sucesso com uma probabilidade de cerca de 1/1000 - ainda mais devido ao longo histórico de ataques surpreendentes a primitivos criptográficos. Um, mencionado acima, são os melhores ataques em curvas elípticas compatíveis com o emparelhamento, como altbn128. Um exemplo mais famoso é o SHA-1, que foi padronizado em 80 bits de segurança, mas acabou sendo mostrado para atingir apenas cerca de 60 bits. Com esse histórico em mente, os projetistas do PQ-SNARK devem deixar mais de 10 bits de espaço de manobra ao configurar o nível de segurança, especialmente se a análise de segurança envolver conjecturas fortes sobre a segurança estatística de protocolos relativamente novos, como o FRI.

Mesmo para PQ-SNARKs, níveis de segurança apropriados sempre podem ser alcançados, simplesmente aumentando os custos de verificação. Por exemplo, aumentar a segurança do verificador do SHARP de 80 para 128 bits (sob conjecturas sobre a solidez estatística do FRI) aumentaria os custos do gás em aproximadamente um fator de dois, de pouco mais de 5 milhões para pouco mais de 10 milhões. Sem conjecturas sobre o FRI, os custos do gás aumentariam por mais um fator de dois, para mais de 20 milhões. 

Minha próxima sugestão, então, é que a comunidade web3 deve desenvolver normas mais fortes em torno dos níveis de segurança apropriados para SNARKs implantados. Minha recomendação pessoal seria de pelo menos 100 bits e pelo menos 128 se a segurança do SNARK for baseada em suposições não padronizadas. eu não sou o primeiro a faça tal proposta.

Aqui, estou disposto a categorizar como uma “suposição padrão” a segurança incondicional no modelo de oráculo aleatório, se o oráculo aleatório no SNARK implantado for instanciado com uma função de hash padrão, como KECCAK-256. O modelo de oráculo aleatório é uma configuração idealizada destinada a capturar o comportamento de funções de hash criptográficas bem projetadas. É frequentemente usado para analisar a segurança de PQ-SNARKs. 

Um exemplo de suposições não padronizadas são as conjecturas (descritas abaixo) sobre a solidez quantitativa de um protocolo como o FRI, seja em um ambiente interativo ou como um protocolo não interativo no modelo de oráculo aleatório.

Os designers do SNARK estão inovando de muitas maneiras interessantes, algumas das quais podem ir além em termos de segurança – por exemplo, usando funções de hash compatíveis com SNARK que não foram submetidas a tanta criptoanálise quanto mais funções de hash padrão. Não estou pedindo o fim de tais esforços – longe disso. Mas essas primitivas devem ser instanciadas em níveis de segurança que excedem os ataques conhecidos e viáveis ​​em mais de 10 bits. 

Rollups usando SNARKs são comumente descritos como herdando a segurança de sua L1. Mas este é um caso difícil de fazer se eles estiverem configurados em níveis de segurança muito mais baixos do que quaisquer primitivas criptográficas usadas pelo L1. À medida que os SNARKs veem uma adoção crescente, devemos nos certificar de implantá-los de maneira consistente com a forma como falamos sobre eles. Desde que os SNARKs sejam analisados ​​com cuidado, configurados adequadamente e implementados corretamente, eles são tão seguros quanto qualquer primitivo criptográfico em uso hoje. 

Um aparte: Mergulhando ainda mais na segurança do PQ-SNARK

Os 80 bits de segurança nos PQ-SNARKs da StarkWare são contabilizados da seguinte forma. Esses PQ-SNARKs fazem uso de um esquema de comprometimento polinomial chamado Sexta-feira , e o verificador SHARP da StarkWare executa o FRI em 48 bits de segurança sob uma conjectura. Grosso modo, a conjectura é que um simples ataque à solidez do FRI é o ideal. Neste ataque, um provador de trapaça, com um pequeno esforço, gera uma “prova de FRI” que passa nas verificações escolhidas aleatoriamente pelo verificador com probabilidade 2^-48. 

StarkWare combina FRI com uma técnica chamada “moagem”. Isso exige que o provador honesto produza uma prova de trabalho de 32 bits antes de produzir uma prova de FRI. O benefício da moagem é que aumenta drasticamente o trabalho necessário para um provador de trapaça realizar o simples ataque ao FRI mencionado acima, para cerca de 2³² avaliações de hash. 

Uma vez que (na expectativa) 2⁴⁸ tentativas do ataque simples são necessárias antes que uma delas seja bem sucedida, a quantidade total de trabalho que o provador de trapaça tem que fazer para forjar uma prova de FRI é aproximadamente 2⁴⁸ * 2³² = 2⁸⁰ avaliações de hash.

Finalmente, vamos descompactar como surgem os 48 bits de segurança para FRI. O verificador FRI faz “consultas” ao polinômio comprometido. Os custos de verificação de FRI crescem linearmente com o número de consultas. Por exemplo, 36 consultas do verificador FRI são aproximadamente 4 vezes mais caras que 9 consultas. Mas mais consultas significam mais segurança. O número de “bits de segurança por consulta” depende de outro parâmetro de FRI, chamado de taxa de código. 

Especificamente, FRI usa algo chamado código de taxa Reed-Solomon r, Onde r é sempre um número estritamente entre 0 e 1. Os custos do provador FRI são inversamente proporcionais r, portanto, uma taxa de 1/16 leva a um provador que é cerca de quatro vezes mais lento e ocupa mais espaço do que uma taxa de ¼. 

O verificador SHARP tem executado FRI com uma taxa de código de 1/16 e com 12 consultas de verificador.

StarkWare conjectura que cada consulta do verificador FRI adiciona log₂(1 /r) pedaços de segurança. Sob essa conjectura, 12 consultas do verificador produzem 12 * log₂(16) = 48 bits de segurança.

No entanto, as análises atuais apenas estabelecem que cada consulta do verificador adiciona um pouco menos do que log₂(1/r^1/2) bits de segurança. Portanto, 12 consultas do verificador FRI geram apenas menos de 12 * log₂(4) = 24 bits de segurança “comprovável”. 

Uma proposta para mitigar a tensão entre segurança e desempenho

PQ-SNARKs práticos têm custos de verificação que crescem linearmente com o número desejado de bits de segurança. Uma técnica promissora para mitigar essa tensão é a composição SNARK - que descrevi no meu post anterior como um meio de resolver a tensão entre os custos do provador e do verificador, mas também pode abordar a segurança. 

Dois exemplos 

Polígono Hermez é compondo PQ-SNARKs com PlonK. A ideia é que o provador primeiro gere uma prova PQ-SNARK π. Se o PQ-SNARK estiver configurado para ter um provador rápido e um nível de segurança adequado, então π será grande. Portanto, o provador não envia π para o verificador. Em vez disso, ele usa o PlonK para provar que conhece π. 

Isso significa aplicar o PlonK a um circuito que recebe π como entrada e verifica se o verificador PQ-SNARK aceitaria π. Como o PQ-SNARK tem custo de verificação polilogarítmica, o PlonK é aplicado a um circuito pequeno e, portanto, o provador PlonK é rápido. Como as provas PlonK são pequenas e baratas de verificar, os custos de verificação são baixos. 

Infelizmente, o uso do PlonK destrói a transparência e a segurança pós-quântica. Em vez disso, pode-se considerar usar o próprio PQ-SNARK no lugar do PlonK para provar o conhecimento de π (na verdade, o PQ-SNARK usado pelo Polygon é auto-composto dessa maneira). 

Nesta segunda aplicação do PQ-SNARK, para provar o conhecimento de π, o sistema pode ser configurado para obter segurança adequada com provas de tamanho razoável, por exemplo, selecionando uma taxa de código muito pequena para uso em FRI. O ponto chave é que, embora essa pequena taxa de código seja ruim para o tempo do provador, a segunda aplicação do PQ-SNARK é aplicada apenas a um circuito pequeno, então o tempo total do provador ainda deve ser pequeno.

Nosso entendimento teórico da segurança de SNARKs compostos deixa muito a desejar. No entanto, não há ataques conhecidos a eles que sejam mais rápidos do que atacar um dos SNARKs constituintes individualmente. Por exemplo, se compor um PQ-SNARK com PlonK, não conhecemos um ataque melhor do que atacar o PQ-SNARK (ou seja, encontrar uma prova de PQ-SNARK π de uma declaração falsa), ou atacar o PlonK (ou seja, encontre uma prova PlonK da afirmação falsa “Eu conheço uma prova PQ-SNARK π que o verificador teria aceitado.”)

Compor SNARKs dessa maneira é uma maneira cada vez mais popular de melhorar o desempenho. Espero que os designers de protocolo também o usem para melhorar a segurança.

***

Justin Thaler é Professor Associado da Universidade de Georgetown. Antes de ingressar na Georgetown, ele passou dois anos como Cientista de Pesquisa no Yahoo Labs em Nova York, antes dos quais foi Pesquisador no Instituto Simons para a Teoria da Computação na UC BeRkeley. 

Editor: Tim Sullivan @tim_org

***

As opiniões expressas aqui são as do pessoal individual da AH Capital Management, LLC (“a16z”) citadas e não são as opiniões da a16z ou de suas afiliadas. Certas informações aqui contidas foram obtidas de fontes de terceiros, inclusive de empresas do portfólio de fundos administrados pela a16z. Embora retiradas de fontes consideradas confiáveis, a16z não verificou essas informações de forma independente e não faz representações sobre a precisão duradoura das informações ou sua adequação a uma determinada situação. Além disso, esse conteúdo pode incluir anúncios de terceiros; a16z não revisou tais anúncios e não endossa nenhum conteúdo de publicidade neles contido.

Este conteúdo é fornecido apenas para fins informativos e não deve ser considerado como aconselhamento jurídico, comercial, de investimento ou fiscal. Você deve consultar seus próprios conselheiros sobre esses assuntos. As referências a quaisquer valores mobiliários ou ativos digitais são apenas para fins ilustrativos e não constituem uma recomendação de investimento ou oferta para fornecer serviços de consultoria de investimento. Além disso, este conteúdo não é direcionado nem destinado ao uso por quaisquer investidores ou potenciais investidores, e não pode, em nenhuma circunstância, ser invocado ao tomar uma decisão de investir em qualquer fundo administrado pela a16z. (Uma oferta para investir em um fundo a16z será feita apenas pelo memorando de colocação privada, contrato de subscrição e outra documentação relevante de tal fundo e deve ser lida na íntegra.) Quaisquer investimentos ou empresas de portfólio mencionados, referidos ou descritos não são representativos de todos os investimentos em veículos administrados pela a16z, e não pode haver garantia de que os investimentos serão rentáveis ​​ou que outros investimentos realizados no futuro terão características ou resultados semelhantes. Uma lista de investimentos feitos por fundos administrados por Andreessen Horowitz (excluindo investimentos para os quais o emissor não deu permissão para a a16z divulgar publicamente, bem como investimentos não anunciados em ativos digitais negociados publicamente) está disponível em https://a16z.com/investments /.

Os gráficos e gráficos fornecidos são apenas para fins informativos e não devem ser considerados ao tomar qualquer decisão de investimento. O desempenho passado não é indicativo de resultados futuros. O conteúdo fala apenas a partir da data indicada. Quaisquer projeções, estimativas, previsões, metas, perspectivas e/ou opiniões expressas nestes materiais estão sujeitas a alterações sem aviso prévio e podem diferir ou ser contrárias às opiniões expressas por outros. Consulte https://a16z.com/disclosures para obter informações adicionais importantes.