Algo pequeño me ha estado molestando desde que empecé a leer cómo Dusk genera pruebas.
La prueba de conocimiento cero es costosa. Tu teléfono no quiere hacerlo. Así que Dusk te da una salida: wallet-core admite delegar la generación de pruebas a un Prover externo, y Prover es un tipo de nodo documentado que puedes ejecutar de verdad, junto con Provisioner y Archive.
Esa es una respuesta de ingeniería sensata. La actualización de ingeniería que la introdujo menciona específicamente que la delegación está diseñada para evitar la maleabilidad, de modo que el prober no pueda alterar en secreto lo que le pediste.
Pero la delegación siempre responde a una pregunta y abre otra. La maleabilidad trata de si el prober puede cambiar tu transacción. No es la misma pregunta que la de lo que el prober puede ver mientras construye la prueba para ti.
Ahora pon Hedger al lado. El planteamiento de Hedger para el lado de EVM va en la dirección opuesta: circuitos ligeros, generación de pruebas del lado del cliente en menos de dos segundos, en el navegador. No hay una tercera máquina involucrada.
Así que @Dusk tiene ambas formas en la misma pila. Un camino de pruebas delegadas para circuitos nativos pesados, y un camino de pruebas local para la capa EVM confidencial.
No creo que ninguna de las dos sea incorrecta. Las pruebas locales son más limpias para la privacidad y peores para dispositivos débiles. Las pruebas delegadas hacen lo contrario. La mayoría de las cadenas simplemente eligen una y dejan de hablar de ello.
Lo que aún no puedo determinar a partir de la documentación es cómo se supone que un usuario normal sabrá cuál está usando en cada momento. Esa sería la parte que querría que se explicara antes de que un banco ponga un cliente en eso.
Si un servicio ofreciera generar tu prueba de privacidad por ti, más rápido y gratis — ¿lo usarías o eso te quitaría el sentido?
#dusk $DUSK @Dusk
La prueba de conocimiento cero es costosa. Tu teléfono no quiere hacerlo. Así que Dusk te da una salida: wallet-core admite delegar la generación de pruebas a un Prover externo, y Prover es un tipo de nodo documentado que puedes ejecutar de verdad, junto con Provisioner y Archive.
Esa es una respuesta de ingeniería sensata. La actualización de ingeniería que la introdujo menciona específicamente que la delegación está diseñada para evitar la maleabilidad, de modo que el prober no pueda alterar en secreto lo que le pediste.
Pero la delegación siempre responde a una pregunta y abre otra. La maleabilidad trata de si el prober puede cambiar tu transacción. No es la misma pregunta que la de lo que el prober puede ver mientras construye la prueba para ti.
Ahora pon Hedger al lado. El planteamiento de Hedger para el lado de EVM va en la dirección opuesta: circuitos ligeros, generación de pruebas del lado del cliente en menos de dos segundos, en el navegador. No hay una tercera máquina involucrada.
Así que @Dusk tiene ambas formas en la misma pila. Un camino de pruebas delegadas para circuitos nativos pesados, y un camino de pruebas local para la capa EVM confidencial.
No creo que ninguna de las dos sea incorrecta. Las pruebas locales son más limpias para la privacidad y peores para dispositivos débiles. Las pruebas delegadas hacen lo contrario. La mayoría de las cadenas simplemente eligen una y dejan de hablar de ello.
Lo que aún no puedo determinar a partir de la documentación es cómo se supone que un usuario normal sabrá cuál está usando en cada momento. Esa sería la parte que querría que se explicara antes de que un banco ponga un cliente en eso.
Si un servicio ofreciera generar tu prueba de privacidad por ti, más rápido y gratis — ¿lo usarías o eso te quitaría el sentido?
#dusk $DUSK @Dusk
