Tengo algo que me di cuenta al intentar plantear preguntas: si la privacidad es solo “herramientería adicional cuando conviene” en la testnet de EVM de Dusk, ¿qué haría que un desarrollador realmente la elija en lugar de pasarla por alto?
Para la mayoría de los devs, por defecto siempre gana: no porque no les importe la funcionalidad avanzada, sino porque el modo por defecto es el camino con menos obstáculos cuando estás tratando de sacar el producto a tiempo. Una función que está en una documentación separada, que requiere aprender un SDK distinto, y que exige un modelo de pensamiento diferente al EVM tradicional, siempre terminará empujada hacia la lista de “pendientes” a menos que haya una razón realmente urgente para priorizarla de inmediato.
Esto es un problema más conductual que técnico. No importa qué tan potente sea el mecanismo Hedger o la codificación homomórfica de @Dusk , por muy sólido que sea el diseño: si la ruta predeterminada sigue siendo una cadena estándar de OP Stack sin cifrado, la mayor parte de las aplicaciones construidas sobre esta testnet en la etapa inicial probablemente no usarán esa capa de privacidad, simplemente porque nadie está obligado a hacerlo. Si esto continúa hasta mainnet, la consecuencia podría ser que gran parte del ecosistema de aplicaciones no aproveche el valor central que $DUSK fue diseñado para aportar.
Auto-refutación: quizá es una preocupación demasiado temprana. La testnet siempre prioriza lo más fácil primero, y la privacidad podría volverse predeterminada en la fase de mainnet cuando Dusk haya tenido tiempo suficiente para perfeccionar la experiencia de desarrollo para esa parte.
Estoy esperando ver si Dusk publica una hoja de ruta concreta para llevar la privacidad de “herramientería adicional” a algo más cercano a la configuración por defecto, antes de que el ecosistema de aplicaciones se consolide en la dirección contraria.
#dusk $AKE $BTC
Para la mayoría de los devs, por defecto siempre gana: no porque no les importe la funcionalidad avanzada, sino porque el modo por defecto es el camino con menos obstáculos cuando estás tratando de sacar el producto a tiempo. Una función que está en una documentación separada, que requiere aprender un SDK distinto, y que exige un modelo de pensamiento diferente al EVM tradicional, siempre terminará empujada hacia la lista de “pendientes” a menos que haya una razón realmente urgente para priorizarla de inmediato.
Esto es un problema más conductual que técnico. No importa qué tan potente sea el mecanismo Hedger o la codificación homomórfica de @Dusk , por muy sólido que sea el diseño: si la ruta predeterminada sigue siendo una cadena estándar de OP Stack sin cifrado, la mayor parte de las aplicaciones construidas sobre esta testnet en la etapa inicial probablemente no usarán esa capa de privacidad, simplemente porque nadie está obligado a hacerlo. Si esto continúa hasta mainnet, la consecuencia podría ser que gran parte del ecosistema de aplicaciones no aproveche el valor central que $DUSK fue diseñado para aportar.
Auto-refutación: quizá es una preocupación demasiado temprana. La testnet siempre prioriza lo más fácil primero, y la privacidad podría volverse predeterminada en la fase de mainnet cuando Dusk haya tenido tiempo suficiente para perfeccionar la experiencia de desarrollo para esa parte.
Estoy esperando ver si Dusk publica una hoja de ruta concreta para llevar la privacidad de “herramientería adicional” a algo más cercano a la configuración por defecto, antes de que el ecosistema de aplicaciones se consolide en la dirección contraria.
#dusk $AKE $BTC
