Uma pequena mudança em Rusk diz muito sobre como a Dusk trata a verificação criptográfica ao longo das atualizações do protocolo.
Um resultado em cache não fica mais vinculado apenas à prova e aos seus insumos. A Dusk também associa esse resultado às regras de verificação que estavam ativas quando a checagem foi feita.
Isso importa porque dados de prova idênticos nem sempre significam um contexto de verificação idêntico. Uma atualização de protocolo pode mudar o verificador ou a política de execução sem alterar os próprios bytes da prova.
Para a rede Dusk, isso se torna especialmente relevante à medida que ela constrói privacidade programável para mercados regulados, onde as provas criptográficas precisam continuar confiáveis ao longo das atualizações do protocolo.
O que eu ainda não sei é se a Dusk isolou essas regras específicas de versão com rigor suficiente para que um resultado em cache nunca ultrapasse a semântica que o tornou válido.
Os detalhes que valem acompanhar são o contexto da política de execução incluído nas chaves de cache, mudanças no verificador como a ativação do PLONK V3 e o que acontece quando atualizações futuras mudarem novamente o comportamento de verificação.
Bytes de prova correspondentes são uma evidência útil de que duas verificações parecem iguais. Eles são uma evidência mais fraca de que o mesmo resultado em cache é seguro para reutilização.
Eu me preocuparia mais em saber se o contexto ativo do verificador ainda corresponde do que em quanta verificação a Dusk consegue armazenar em cache.
O ponto mais profundo é que a verificação determinística depende de mais do que fixar a entrada. As regras usadas para interpretar essa entrada também precisam ser fixadas.
A questão é se a Dusk consegue continuar otimizando a verificação sem deixar que antigas semânticas de protocolo atravessem uma fronteira de atualização por meio do cache.
Estou observando como futuras mudanças no verificador se refletem nesse contexto da política de execução.
#dusk $DUSK @Dusk
Um resultado em cache não fica mais vinculado apenas à prova e aos seus insumos. A Dusk também associa esse resultado às regras de verificação que estavam ativas quando a checagem foi feita.
Isso importa porque dados de prova idênticos nem sempre significam um contexto de verificação idêntico. Uma atualização de protocolo pode mudar o verificador ou a política de execução sem alterar os próprios bytes da prova.
Para a rede Dusk, isso se torna especialmente relevante à medida que ela constrói privacidade programável para mercados regulados, onde as provas criptográficas precisam continuar confiáveis ao longo das atualizações do protocolo.
O que eu ainda não sei é se a Dusk isolou essas regras específicas de versão com rigor suficiente para que um resultado em cache nunca ultrapasse a semântica que o tornou válido.
Os detalhes que valem acompanhar são o contexto da política de execução incluído nas chaves de cache, mudanças no verificador como a ativação do PLONK V3 e o que acontece quando atualizações futuras mudarem novamente o comportamento de verificação.
Bytes de prova correspondentes são uma evidência útil de que duas verificações parecem iguais. Eles são uma evidência mais fraca de que o mesmo resultado em cache é seguro para reutilização.
Eu me preocuparia mais em saber se o contexto ativo do verificador ainda corresponde do que em quanta verificação a Dusk consegue armazenar em cache.
O ponto mais profundo é que a verificação determinística depende de mais do que fixar a entrada. As regras usadas para interpretar essa entrada também precisam ser fixadas.
A questão é se a Dusk consegue continuar otimizando a verificação sem deixar que antigas semânticas de protocolo atravessem uma fronteira de atualização por meio do cache.
Estou observando como futuras mudanças no verificador se refletem nesse contexto da política de execução.
#dusk $DUSK @Dusk
