1/ Cuidado com o hype: embora SNARKs e zkVMs mostrem imensa promessa, eles não estão prontos para implantações complexas e de alto risco. Os bugs estão por toda parte, a verificação formal é incipiente e as provas podem ser centenas de milhares de vezes mais lentas do que a execução nativa.

2/ Acabei de publicar um post descrevendo um roteiro estruturado para o desenvolvimento do zkVM. Ele separa "estágios de segurança" de "estágios de velocidade", dando-nos uma maneira transparente de acompanhar o progresso. Leia aqui:

3/ Quanto à segurança, identifico três etapas para a verificação formal: • Protocolos verificados • Verificadores verificados • Provadores verificados Até chegarmos ao Estágio 2, não podemos realmente chamar um zkVM de "seguro" – e chegar lá provavelmente ainda está a vários anos de distância.

4/ No desempenho, as despesas gerais versus a execução nativa ainda excedem 100.000× — um ponto fora da curva para a maioria dos casos de uso. Meu post propõe cinco "estágios de desempenho" para reduzir essa sobrecarga em ordens de magnitude e, eventualmente, habilitar provas no dispositivo.

5/ Crucialmente, devemos isolar a eficiência fundamental de um sistema de prova. No momento, muitos benchmarks agrupam tudo — sistema de prova, engenharia, melhorias de hardware e pré-compilações ajustadas à mão — em um único número de primeira linha, obscurecendo onde realmente estamos.

6/ Então, sim, zkVMs e SNARKs têm um enorme potencial, mas flertamos com o desastre se fingirmos que eles estão prontos para o horário nobre. Usarei esses estágios para acompanhar o progresso do zkVM nos próximos anos — e espero que outros também o façam. Confira meu post aqui: