#dusk $DUSK @Dusk
Cuatro números fue todo lo que hizo falta. El camino de Phoenix protegido de Dusk —la parte que lleva su argumento completo de privacidad— verificó pruebas a través de una sola llamada, y esa llamada nunca comprobó cuatro valores selectores contra las confirmaciones que estaban justo ahí en la clave del verificador. $DUSK #dusk @Dusk ya había pasado tres auditorías separadas antes de que esto se encontrara en febrero.
Lo que me sorprendió fue la forma del desvío. En PLONK estándar, los selectores se supone que son datos públicos, fijos, del lado del verificador. Los widgets personalizados de dusk-plonk los obligaron a convertirse en números proporcionados por el probador, y nadie actualizó el modelo mental que decide qué necesita un enlace criptográfico. La lógica del circuito en sí estaba bien de punta a punta —la brecha estaba una capa por debajo, en el cableado de verificación.
Lo que cambió para mí fue darme cuenta de que "auditado tres veces" no es lo mismo que "auditado contra el modelo de amenaza correcto". Un revisor que revisa la lógica de restricciones puede pasar por alto sin darse cuenta una suposición estructural que dejó de cumplirse silenciosamente. Es más difícil de detectar que un error normal de código, y no es exclusivo de Dusk — el mismo patrón apareció de forma independiente en Jellyfish de Espresso.
Lo siguiente que revisaría: si el impulso de Dusk por una especificación estandarizada de verificación en PLONK realmente se entrega, o si se queda como un hilo de discusión.
Cuatro números fue todo lo que hizo falta. El camino de Phoenix protegido de Dusk —la parte que lleva su argumento completo de privacidad— verificó pruebas a través de una sola llamada, y esa llamada nunca comprobó cuatro valores selectores contra las confirmaciones que estaban justo ahí en la clave del verificador. $DUSK #dusk @Dusk ya había pasado tres auditorías separadas antes de que esto se encontrara en febrero.
Lo que me sorprendió fue la forma del desvío. En PLONK estándar, los selectores se supone que son datos públicos, fijos, del lado del verificador. Los widgets personalizados de dusk-plonk los obligaron a convertirse en números proporcionados por el probador, y nadie actualizó el modelo mental que decide qué necesita un enlace criptográfico. La lógica del circuito en sí estaba bien de punta a punta —la brecha estaba una capa por debajo, en el cableado de verificación.
Lo que cambió para mí fue darme cuenta de que "auditado tres veces" no es lo mismo que "auditado contra el modelo de amenaza correcto". Un revisor que revisa la lógica de restricciones puede pasar por alto sin darse cuenta una suposición estructural que dejó de cumplirse silenciosamente. Es más difícil de detectar que un error normal de código, y no es exclusivo de Dusk — el mismo patrón apareció de forma independiente en Jellyfish de Espresso.
Lo siguiente que revisaría: si el impulso de Dusk por una especificación estandarizada de verificación en PLONK realmente se entrega, o si se queda como un hilo de discusión.