$DUSK $aDUSK #dusk — la capa construida para la adopción por parte de desarrolladores establece por defecto ser transparente, no privada.
La mayoría de "cadenas" privadas tratan el cumplimiento como un pensamiento posterior, añadido a un libro mayor público: mezcladores, blindaje opcional, una puerta de KYC situada fuera del protocolo. El planteamiento de Dusk fue distinto: la privacidad integrada en la liquidación misma. Según la documentación de Dusk, nativo DuskDS te ofrece dos modelos de transacción — Moonlight (transparente, saldos visibles) o Phoenix (notas protegidas, cero-conocimiento por defecto). @DuskFoundation construyó su narrativa de cumplimiento a partir de ese valor predeterminado, no como un complemento.
Luego miré DuskEVM, la capa compatible con Solidity que en realidad está pensada para atraer desarrolladores. La documentación describe Hedger, el módulo de privacidad con cifrado homomórfico/ZK, como una herramienta a la que recurres "cuando corresponde". Los contratos simples en DuskEVM se comportan como contratos EVM simples en cualquier parte — transparentes a menos que alguien conecte explícitamente Hedger. El patrón de "anexar" que Dusk critica en otras cadenas aparece en su propia superficie de crecimiento.
Lo que cambió para mí: "privacidad por diseño" no es una sola propiedad aquí, sino dos valores predeterminados cosidos entre sí — y la capa que la mayoría de los creadores realmente tocará hereda la opción más débil. No mata la tesis, solo acota dónde se sostiene. Vale la pena verificar: ¿las primeras implementaciones de DuskEVM están integrando realmente Hedger, o publican transparente como cualquier otra cadena EVM?
#dusk $DUSK @Dusk
La mayoría de "cadenas" privadas tratan el cumplimiento como un pensamiento posterior, añadido a un libro mayor público: mezcladores, blindaje opcional, una puerta de KYC situada fuera del protocolo. El planteamiento de Dusk fue distinto: la privacidad integrada en la liquidación misma. Según la documentación de Dusk, nativo DuskDS te ofrece dos modelos de transacción — Moonlight (transparente, saldos visibles) o Phoenix (notas protegidas, cero-conocimiento por defecto). @DuskFoundation construyó su narrativa de cumplimiento a partir de ese valor predeterminado, no como un complemento.
Luego miré DuskEVM, la capa compatible con Solidity que en realidad está pensada para atraer desarrolladores. La documentación describe Hedger, el módulo de privacidad con cifrado homomórfico/ZK, como una herramienta a la que recurres "cuando corresponde". Los contratos simples en DuskEVM se comportan como contratos EVM simples en cualquier parte — transparentes a menos que alguien conecte explícitamente Hedger. El patrón de "anexar" que Dusk critica en otras cadenas aparece en su propia superficie de crecimiento.
Lo que cambió para mí: "privacidad por diseño" no es una sola propiedad aquí, sino dos valores predeterminados cosidos entre sí — y la capa que la mayoría de los creadores realmente tocará hereda la opción más débil. No mata la tesis, solo acota dónde se sostiene. Vale la pena verificar: ¿las primeras implementaciones de DuskEVM están integrando realmente Hedger, o publican transparente como cualquier otra cadena EVM?
#dusk $DUSK @Dusk