#dusk $DUSK
Pasé esta semana por la estructura de clave de Phoenix para entender qué es exactamente lo que le da una clave de vista a alguien — y en qué se diferencia de simplemente entregar el acceso.
Claves de vista de Phoenix: el whitepaper define la clave de vista como (a, B) — un secreto parcial que permite que un tercero escanee la red para identificar qué transacciones están dirigidas a ti. Pueden ver lo que entra. No pueden calcular la clave secreta de la nota, así que no pueden gastar nada. Escanear sin gastar.
La generación de pruebas ZK es delegable por separado. Una transacción requiere una prueba de conocimiento cero. Esa generación de pruebas es computacionalmente intensiva y puede externalizarse a una parte de confianza usando firmas, sin darles acceso a tu clave privada completa. La integridad de la transacción no se ve comprometida porque la firma la vincula a tu clave incluso si la prueba se generó en otro lugar.
Esa parte es sólida. Dos niveles de delegación, claramente separados: uno para acceso tipo auditoría, y otro para descargar la computación.
Lo que es más difícil de razonar es el costo de privacidad de cada uno. El delegado de la clave de vista sabe cuáles transacciones son tuyas. "No puede gastar" no significa "no sabe nada" — significa que puede construir un panorama de todo tu historial de recepción. Para un caso de uso de cumplimiento, tal vez sea exactamente lo que se necesita. Para un usuario individual, entregar una clave de vista a un servicio es una divulgación significativa incluso si no se mueven fondos.
En realidad, creo que la delegación de la prueba es más limpia desde el punto de vista de la privacidad — el generador de pruebas no aprende nada sobre el contenido de la transacción si el protocolo está correctamente estructurado. La clave de vista es la que transporta la información real.
Lo que no he resuelto es si los casos de uso de auditoría para Phoenix realmente usan la clave de vista directamente, o si existen mecanismos de divulgación selectiva para que solo se revelen transacciones específicas en lugar del historial completo de recepción. @Dusk
$DUSK #dusk
Pasé esta semana por la estructura de clave de Phoenix para entender qué es exactamente lo que le da una clave de vista a alguien — y en qué se diferencia de simplemente entregar el acceso.
Claves de vista de Phoenix: el whitepaper define la clave de vista como (a, B) — un secreto parcial que permite que un tercero escanee la red para identificar qué transacciones están dirigidas a ti. Pueden ver lo que entra. No pueden calcular la clave secreta de la nota, así que no pueden gastar nada. Escanear sin gastar.
La generación de pruebas ZK es delegable por separado. Una transacción requiere una prueba de conocimiento cero. Esa generación de pruebas es computacionalmente intensiva y puede externalizarse a una parte de confianza usando firmas, sin darles acceso a tu clave privada completa. La integridad de la transacción no se ve comprometida porque la firma la vincula a tu clave incluso si la prueba se generó en otro lugar.
Esa parte es sólida. Dos niveles de delegación, claramente separados: uno para acceso tipo auditoría, y otro para descargar la computación.
Lo que es más difícil de razonar es el costo de privacidad de cada uno. El delegado de la clave de vista sabe cuáles transacciones son tuyas. "No puede gastar" no significa "no sabe nada" — significa que puede construir un panorama de todo tu historial de recepción. Para un caso de uso de cumplimiento, tal vez sea exactamente lo que se necesita. Para un usuario individual, entregar una clave de vista a un servicio es una divulgación significativa incluso si no se mueven fondos.
En realidad, creo que la delegación de la prueba es más limpia desde el punto de vista de la privacidad — el generador de pruebas no aprende nada sobre el contenido de la transacción si el protocolo está correctamente estructurado. La clave de vista es la que transporta la información real.
Lo que no he resuelto es si los casos de uso de auditoría para Phoenix realmente usan la clave de vista directamente, o si existen mecanismos de divulgación selectiva para que solo se revelen transacciones específicas en lugar del historial completo de recepción. @Dusk
$DUSK #dusk
