Veo un detalle digno de mención al pensar en el papel de Zilch en @Dusk : se parece a una especie de “traducción” entre dos lenguajes distintos — el lenguaje de los valores protegidos de forma anónima tipo UTXO, y el lenguaje del estado del contrato tipo account-based que la mayoría de la lógica de los smart contracts necesita para funcionar.
Phoenix opera de manera muy similar a un modelo UTXO privado — el valor existe como notas independientes, y cada nota se valida por sí misma sin necesidad de conocer el estado global. Pero gran parte de la lógica del contrato, incluso sobre la Rusk VM, suele requerir un modelo de estado más continuo — donde una variable puede leerse, modificarse y registrarse en un orden rastreable. Esta es la brecha arquitectónica entre dos modelos de datos diferentes, y no es solo un tema de privacidad.
Si esto es así, el papel de Zilch no se limita a “ocultar información a extraños”, sino que también sirve como un puente para traducir un valor en forma de nota discreta en una entrada que el modelo de estado del contrato pueda consumir — un problema de compatibilidad de datos, no solo de seguridad. Luego, PLONK demuestra que ese proceso de traducción se realiza correctamente según las reglas, sin revelar el contenido de las notas originales.
Auto-refutación: esta es una inferencia basada en el entendimiento general de las diferencias entre UTXO y el modelo account-based; no necesariamente refleja con precisión los detalles técnicos de la implementación real de Dusk — se necesitaría documentación más profunda para confirmarlo.
Estoy esperando ver si $DUSK publica documentación técnica más detallada sobre cómo Zilch realiza la conversión entre estos dos modelos de datos, para confirmar si esto realmente es el problema de compatibilidad UTXO-account que yo imagino.
#dusk $BTC $ETH
Phoenix opera de manera muy similar a un modelo UTXO privado — el valor existe como notas independientes, y cada nota se valida por sí misma sin necesidad de conocer el estado global. Pero gran parte de la lógica del contrato, incluso sobre la Rusk VM, suele requerir un modelo de estado más continuo — donde una variable puede leerse, modificarse y registrarse en un orden rastreable. Esta es la brecha arquitectónica entre dos modelos de datos diferentes, y no es solo un tema de privacidad.
Si esto es así, el papel de Zilch no se limita a “ocultar información a extraños”, sino que también sirve como un puente para traducir un valor en forma de nota discreta en una entrada que el modelo de estado del contrato pueda consumir — un problema de compatibilidad de datos, no solo de seguridad. Luego, PLONK demuestra que ese proceso de traducción se realiza correctamente según las reglas, sin revelar el contenido de las notas originales.
Auto-refutación: esta es una inferencia basada en el entendimiento general de las diferencias entre UTXO y el modelo account-based; no necesariamente refleja con precisión los detalles técnicos de la implementación real de Dusk — se necesitaría documentación más profunda para confirmarlo.
Estoy esperando ver si $DUSK publica documentación técnica más detallada sobre cómo Zilch realiza la conversión entre estos dos modelos de datos, para confirmar si esto realmente es el problema de compatibilidad UTXO-account que yo imagino.
#dusk $BTC $ETH
