Después de empezar temprano y seguir hasta el final, probé la red de pruebas durante una semana, @Dusk . Me pareció más sólida de lo que imaginaba, pero la documentación es bastante floja.
Esta vez, la tarea para creadores de Binance me hizo revisar de principio a fin a Dusk, desde el libro blanco hasta la red de pruebas. Primero, la conclusión: a nivel técnico hay cosas reales; la privacidad y la conformidad no se remiendan, vienen de fábrica.
En el libro blanco, el punto más esencial es que no usa mezcladores, sino que combina el modelo UTXO y el de cuentas mediante el modelo de transacciones Phoenix, y luego lo complementa con pruebas de conocimiento cero PLONK. Como resultado, se puede ocultar el monto, las direcciones y el tipo de activo; aun así, los nodos verificadores pueden comprobar la validez de la transacción. En la red de pruebas envié algunas transferencias: revisé mis transacciones en el explorador de bloques y, efectivamente, solo veo el commitment y el nullifier; el campo del monto está directamente vacío. La generación de la prueba PLONK tarda aproximadamente entre uno y dos segundos en mi máquina local, y el lado verificador lo hace muy rápido. Esto coincide con lo que el libro blanco describe como “pruebas de tamaño constante”.
La parte del consenso también vale la pena. Dusk usa SBA (Segregated Byzantine Agreement), que no es un PoS común. El productor de bloques se selecciona mediante sorteos cifrados con VRF; antes de producir el bloque, la identidad no se publica, por lo que la superficie de ataque dirigido se reduce mucho. Cuando levanté nodos, me encontré algunas ocasiones en que el intervalo entre bloques fue algo mayor, pero en general no se atascó ni hubo bifurcaciones largas. Que la calidad de los nodos en la red de pruebas sea desigual es entendible.
En cuanto a Rusk VM, intenté escribir un contrato sencillo en Rust, compilarlo a WASM y luego ejecutarlo en el entorno ZK. La lógica del contrato en sí no es difícil; el problema principal fue que las versiones de la documentación no encajaban, y perdí bastante tiempo. Las herramientas del ecosistema tampoco están completas todavía, y para usuarios comunes no es lo suficientemente amigable.
El diseño de cumplimiento, en cambio, me cambió la percepción. Dusk sigue una ruta de divulgación opcional: el emisor puede dar claves de visualización a reguladores o auditores, mientras que entre usuarios normales la privacidad se mantiene. Esto es bastante realista para escenarios como RWA y tokens de valores; si no, las instituciones simplemente no se atreverían a ponerlo en la cadena.
En general, Dusk es adecuado para equipos que quieren hacer en serio finanzas privadas, no para quienes solo persiguen el relato. La base técnica es más sólida que la mayoría de las cadenas de privacidad, pero aún falta reforzar la documentación y las herramientas.
#dusk $DUSK
Esta vez, la tarea para creadores de Binance me hizo revisar de principio a fin a Dusk, desde el libro blanco hasta la red de pruebas. Primero, la conclusión: a nivel técnico hay cosas reales; la privacidad y la conformidad no se remiendan, vienen de fábrica.
En el libro blanco, el punto más esencial es que no usa mezcladores, sino que combina el modelo UTXO y el de cuentas mediante el modelo de transacciones Phoenix, y luego lo complementa con pruebas de conocimiento cero PLONK. Como resultado, se puede ocultar el monto, las direcciones y el tipo de activo; aun así, los nodos verificadores pueden comprobar la validez de la transacción. En la red de pruebas envié algunas transferencias: revisé mis transacciones en el explorador de bloques y, efectivamente, solo veo el commitment y el nullifier; el campo del monto está directamente vacío. La generación de la prueba PLONK tarda aproximadamente entre uno y dos segundos en mi máquina local, y el lado verificador lo hace muy rápido. Esto coincide con lo que el libro blanco describe como “pruebas de tamaño constante”.
La parte del consenso también vale la pena. Dusk usa SBA (Segregated Byzantine Agreement), que no es un PoS común. El productor de bloques se selecciona mediante sorteos cifrados con VRF; antes de producir el bloque, la identidad no se publica, por lo que la superficie de ataque dirigido se reduce mucho. Cuando levanté nodos, me encontré algunas ocasiones en que el intervalo entre bloques fue algo mayor, pero en general no se atascó ni hubo bifurcaciones largas. Que la calidad de los nodos en la red de pruebas sea desigual es entendible.
En cuanto a Rusk VM, intenté escribir un contrato sencillo en Rust, compilarlo a WASM y luego ejecutarlo en el entorno ZK. La lógica del contrato en sí no es difícil; el problema principal fue que las versiones de la documentación no encajaban, y perdí bastante tiempo. Las herramientas del ecosistema tampoco están completas todavía, y para usuarios comunes no es lo suficientemente amigable.
El diseño de cumplimiento, en cambio, me cambió la percepción. Dusk sigue una ruta de divulgación opcional: el emisor puede dar claves de visualización a reguladores o auditores, mientras que entre usuarios normales la privacidad se mantiene. Esto es bastante realista para escenarios como RWA y tokens de valores; si no, las instituciones simplemente no se atreverían a ponerlo en la cadena.
En general, Dusk es adecuado para equipos que quieren hacer en serio finanzas privadas, no para quienes solo persiguen el relato. La base técnica es más sólida que la mayoría de las cadenas de privacidad, pero aún falta reforzar la documentación y las herramientas.
#dusk $DUSK