#dusk $DUSK @Dusk
Executando a geração de provas localmente para benchmarkar o desempenho do circuito, percebi algo que me fez voltar e ler os próprios materiais da equipe de criptografia, em vez das páginas de marketing.
Os números reais do PLONK é que sustentam o caso de conformidade, não apenas o ângulo de privacidade. O tempo de verificação fica em torno de 6 a 9 milissegundos, independentemente do tamanho do circuito — enquanto o tempo de prova escala com a complexidade do circuito (aproximadamente 5,46 segundos para um circuito de 2^16 portas em hardware modesto). Já o lado do verificador permanece rápido e constante. Essa assimetria importa mais para finanças reguladas do que as pessoas dão crédito: um auditor ou contraparte verificando uma prova não fica gastando computação relevante toda vez, mesmo conforme a lógica subjacente da transação fica mais complexa.
O que eu não esperava encontrar era que o próprio PLONK tinha uma vulnerabilidade real divulgada, não apenas um risco teórico. A equipe de pesquisa da Dusk encontrou uma falha crítica na forma como a transformação Fiat-Shamir foi implementada — a parte que transforma uma prova interativa em uma prova não interativa, fazendo hash dos desafios em vez de um verificador vivo enviá-los. A implementação original não fazia hash das entradas públicas cedo o bastante, o que enfraqueceu a garantia de solidez (soundness). A Trail of Bits coordenou a divulgação, a Dusk corrigiu antes do mainnet e publicou a correção em vez de deixá-la guardada.
É esse detalhe que não sai da minha cabeça — uma cadeia orientada à conformidade construída sobre um sistema de provas criptográficas que tinha um bug de solidez em código próximo de produção, detectado e corrigido antes de realmente importar. Não sei quantas outras implementações usando PLONK em outros lugares ainda estavam vulneráveis quando isso se tornou público, nem por quanto tempo a diferença entre a divulgação e a correção de forks próprios em outros projetos durou.
Executando a geração de provas localmente para benchmarkar o desempenho do circuito, percebi algo que me fez voltar e ler os próprios materiais da equipe de criptografia, em vez das páginas de marketing.
Os números reais do PLONK é que sustentam o caso de conformidade, não apenas o ângulo de privacidade. O tempo de verificação fica em torno de 6 a 9 milissegundos, independentemente do tamanho do circuito — enquanto o tempo de prova escala com a complexidade do circuito (aproximadamente 5,46 segundos para um circuito de 2^16 portas em hardware modesto). Já o lado do verificador permanece rápido e constante. Essa assimetria importa mais para finanças reguladas do que as pessoas dão crédito: um auditor ou contraparte verificando uma prova não fica gastando computação relevante toda vez, mesmo conforme a lógica subjacente da transação fica mais complexa.
O que eu não esperava encontrar era que o próprio PLONK tinha uma vulnerabilidade real divulgada, não apenas um risco teórico. A equipe de pesquisa da Dusk encontrou uma falha crítica na forma como a transformação Fiat-Shamir foi implementada — a parte que transforma uma prova interativa em uma prova não interativa, fazendo hash dos desafios em vez de um verificador vivo enviá-los. A implementação original não fazia hash das entradas públicas cedo o bastante, o que enfraqueceu a garantia de solidez (soundness). A Trail of Bits coordenou a divulgação, a Dusk corrigiu antes do mainnet e publicou a correção em vez de deixá-la guardada.
É esse detalhe que não sai da minha cabeça — uma cadeia orientada à conformidade construída sobre um sistema de provas criptográficas que tinha um bug de solidez em código próximo de produção, detectado e corrigido antes de realmente importar. Não sei quantas outras implementações usando PLONK em outros lugares ainda estavam vulneráveis quando isso se tornou público, nem por quanto tempo a diferença entre a divulgação e a correção de forks próprios em outros projetos durou.