Acabo de pasar un tiempo revisando una vez más el Fénix de Dusk y la parte que sigue resultándome ligeramente extraña es lo poca información que realmente necesita un validador.
En una transacción normal, estoy acostumbrado a que la red vea suficientes datos para averiguar quién gastó qué y adónde fue. Phoenix toma una ruta diferente. La transacción se construye a partir de UTXOs blindados y una prueba de conocimiento cero, de modo que la red puede verificar que el gasto es válido, que la entrada no se ha gastado ya y que el valor es suficiente, sin aprender quién es el remitente, el destinatario ni el importe.
Suena obvio después de leerlo dos veces. Lo interesante es lo que desaparece del trabajo del validador. No necesita reconstruir mi historial financiero solo para verificar una única transición de estado.
Aunque tiene un coste. La información privada no hace que la computación desaparezca por arte de magia. El cliente tiene que generar la prueba antes de que la transacción llegue a la red, y demostrar con ZK puede ser mucho más pesado que firmar una transacción normal.
Probablemente esa sea la parte que yo me preocuparía más en la práctica.
Un validador puede mantenerse relativamente ignorante mientras aun así comprueba las reglas, lo cual es útil. Pero si generar esas pruebas se vuelve doloroso en hardware cotidiano, la privacidad empieza a convertirse en un requisito del propio hardware.
Me gusta más la arquitectura una vez la miro así. La red puede verificar la regla sin convertir la cuenta del usuario en infraestructura pública. La pregunta para la que me gustaría tener un punto de referencia es sencilla: ¿cuánto es el tiempo real de generación de la prueba y cuál es la huella de memoria para una transacción de Phoenix en hardware de cliente común?
#dusk $DUSK @Dusk $HEMI $ACE #BNBChain #satoshiNakamato #SaudiArabia #the
En una transacción normal, estoy acostumbrado a que la red vea suficientes datos para averiguar quién gastó qué y adónde fue. Phoenix toma una ruta diferente. La transacción se construye a partir de UTXOs blindados y una prueba de conocimiento cero, de modo que la red puede verificar que el gasto es válido, que la entrada no se ha gastado ya y que el valor es suficiente, sin aprender quién es el remitente, el destinatario ni el importe.
Suena obvio después de leerlo dos veces. Lo interesante es lo que desaparece del trabajo del validador. No necesita reconstruir mi historial financiero solo para verificar una única transición de estado.
Aunque tiene un coste. La información privada no hace que la computación desaparezca por arte de magia. El cliente tiene que generar la prueba antes de que la transacción llegue a la red, y demostrar con ZK puede ser mucho más pesado que firmar una transacción normal.
Probablemente esa sea la parte que yo me preocuparía más en la práctica.
Un validador puede mantenerse relativamente ignorante mientras aun así comprueba las reglas, lo cual es útil. Pero si generar esas pruebas se vuelve doloroso en hardware cotidiano, la privacidad empieza a convertirse en un requisito del propio hardware.
Me gusta más la arquitectura una vez la miro así. La red puede verificar la regla sin convertir la cuenta del usuario en infraestructura pública. La pregunta para la que me gustaría tener un punto de referencia es sencilla: ¿cuánto es el tiempo real de generación de la prueba y cuál es la huella de memoria para una transacción de Phoenix en hardware de cliente común?
#dusk $DUSK @Dusk $HEMI $ACE #BNBChain #satoshiNakamato #SaudiArabia #the