Ayer no dormí toda la noche investigando el libro blanco del $DUSK y leí hasta la parte de la estructura de las notas de Phoenix. Había una frase que me hizo detenerme y mirarla durante mucho tiempo
El campo cifrado de note, enc, se cifra con la clave de visualización (view key) del destinatario. El libro blanco dice que la view key permite al usuario delegar a un tercero el permiso para buscar transacciones en la red escaneada, pero el tercero no obtiene la secret key completa, así que no puede gastar dinero
Al principio no presté mucha atención a este detalle. Luego lo entendí: en realidad, esto es el núcleo criptográfico de la divulgación selectiva. Con los mismos datos de una transacción, distintas claves controlan distintos niveles de acceso
La definición de la view key en el libro blanco es (a, B), y la secret key es (a, b). Si falta un componente de la clave privada b, se agrega una capa extra de seguridad. Los datos cifrados de note se pueden descifrar para verlos, pero no se puede generar el nullifier correspondiente para gastarlos. La esencia de este mecanismo es que la capacidad de control y el derecho de uso pueden separarse
Para el público, las transacciones están cifradas; las pruebas ZK solo verifican la corrección sin exponer datos. Para los reguladores, si el autorizador obtiene la view key, puede descifrar el contenido específico de la note, verificar el saldo, la contraparte y el cumplimiento normativo, pero no puede disponer de los fondos. En la web, @Dusk dice que esto se llama "controlled visibility for audit, supervision, and regulated disclosure"; cuanto más lo leo, más preciso me parece ese enunciado
Un conjunto de llaves criptográficas que resuelve, al mismo tiempo, estas dos necesidades aparentemente contradictorias: privacidad y cumplimiento. El público no lo ve, el regulador sí, y el usuario decide
#dusk
Pero, seamos honestos, todavía no termino de entender cómo alinear esta mecánica de view key en el entorno EVM de Hedger. La view key del libro blanco está diseñada para el modelo nativo UTXO de Phoenix; Hedger sigue un modelo híbrido UTXO/cuentas. Si los sistemas de claves de ambos pueden mapearse sin problemas, aún no he encontrado una respuesta clara
El campo cifrado de note, enc, se cifra con la clave de visualización (view key) del destinatario. El libro blanco dice que la view key permite al usuario delegar a un tercero el permiso para buscar transacciones en la red escaneada, pero el tercero no obtiene la secret key completa, así que no puede gastar dinero
Al principio no presté mucha atención a este detalle. Luego lo entendí: en realidad, esto es el núcleo criptográfico de la divulgación selectiva. Con los mismos datos de una transacción, distintas claves controlan distintos niveles de acceso
La definición de la view key en el libro blanco es (a, B), y la secret key es (a, b). Si falta un componente de la clave privada b, se agrega una capa extra de seguridad. Los datos cifrados de note se pueden descifrar para verlos, pero no se puede generar el nullifier correspondiente para gastarlos. La esencia de este mecanismo es que la capacidad de control y el derecho de uso pueden separarse
Para el público, las transacciones están cifradas; las pruebas ZK solo verifican la corrección sin exponer datos. Para los reguladores, si el autorizador obtiene la view key, puede descifrar el contenido específico de la note, verificar el saldo, la contraparte y el cumplimiento normativo, pero no puede disponer de los fondos. En la web, @Dusk dice que esto se llama "controlled visibility for audit, supervision, and regulated disclosure"; cuanto más lo leo, más preciso me parece ese enunciado
Un conjunto de llaves criptográficas que resuelve, al mismo tiempo, estas dos necesidades aparentemente contradictorias: privacidad y cumplimiento. El público no lo ve, el regulador sí, y el usuario decide
#dusk
Pero, seamos honestos, todavía no termino de entender cómo alinear esta mecánica de view key en el entorno EVM de Hedger. La view key del libro blanco está diseñada para el modelo nativo UTXO de Phoenix; Hedger sigue un modelo híbrido UTXO/cuentas. Si los sistemas de claves de ambos pueden mapearse sin problemas, aún no he encontrado una respuesta clara