La privacidad de Dusk solo es realmente confiable cuando la red está bajo estrés
Lo que me cambió la forma de ver a Phoenix fue darme cuenta de que no ver no equivale a no poder comprobar.
En las transacciones cifradas, los observadores públicos no ven el remitente, el destinatario ni el importe como en Moonlight, pero la red aún debe verificar la transacción antes de que el estado sea aceptado. Luego, DuskDS envía el bloque mediante una propuesta, validación y ratificación para lograr una finalidad determinista.
En condiciones normales, este modelo es bastante compacto. Donde quiero mirarlo con más detalle es cuando la red está congestionada.
Si las transacciones públicas y las confidenciales ejercen presión simultáneamente sobre el sistema, el comité cambia continuamente y algunos provisioners empiezan a ir más despacio: la privacidad deja de ser la única pregunta. La red también debe mantener la vivacidad y la finalidad sin rebajar los estándares de verificación.
Lo que me parece razonable es que Dusk no trata todos los errores como si fueran iguales. Los provisioners que se pierdan sus tareas pueden recibir una soft penalty, mientras que las conductas que se pueden demostrar incorrectas, como un voto no válido o una firma en conflicto, pueden conllevar una hard penalty.
En mi opinión, esta es la prueba que vale más la pena observar que una transacción privada que simplemente funcione sin problemas.
Un buen sistema de privacidad no solo tiene que ocultar datos cuando todo va bien. Debe conservar la verificabilidad cuando los nodos se desincronizan, el comité rota y la carga de la red aumenta de forma notable.
Si Dusk logra mantener ese límite, entonces la privacidad será de verdad una propiedad de la infraestructura, no solo una experiencia de la billetera.
@Dusk $DUSK #dusk
$RICE $BTW
Lo que me cambió la forma de ver a Phoenix fue darme cuenta de que no ver no equivale a no poder comprobar.
En las transacciones cifradas, los observadores públicos no ven el remitente, el destinatario ni el importe como en Moonlight, pero la red aún debe verificar la transacción antes de que el estado sea aceptado. Luego, DuskDS envía el bloque mediante una propuesta, validación y ratificación para lograr una finalidad determinista.
En condiciones normales, este modelo es bastante compacto. Donde quiero mirarlo con más detalle es cuando la red está congestionada.
Si las transacciones públicas y las confidenciales ejercen presión simultáneamente sobre el sistema, el comité cambia continuamente y algunos provisioners empiezan a ir más despacio: la privacidad deja de ser la única pregunta. La red también debe mantener la vivacidad y la finalidad sin rebajar los estándares de verificación.
Lo que me parece razonable es que Dusk no trata todos los errores como si fueran iguales. Los provisioners que se pierdan sus tareas pueden recibir una soft penalty, mientras que las conductas que se pueden demostrar incorrectas, como un voto no válido o una firma en conflicto, pueden conllevar una hard penalty.
En mi opinión, esta es la prueba que vale más la pena observar que una transacción privada que simplemente funcione sin problemas.
Un buen sistema de privacidad no solo tiene que ocultar datos cuando todo va bien. Debe conservar la verificabilidad cuando los nodos se desincronizan, el comité rota y la carga de la red aumenta de forma notable.
Si Dusk logra mantener ese límite, entonces la privacidad será de verdad una propiedad de la infraestructura, no solo una experiencia de la billetera.
@Dusk $DUSK #dusk
$RICE $BTW
