El crepúsculo está desplegando una capa compatible con EVM
junto a su cadena nativa, y la lógica declarada es
sencilla:
reducir la barrera para los desarrolladores, permitir que el Solidity
existente se conecte en lugar de pedirle a cada creador que
aprenda una pila nueva desde cero.
A simple vista, este es el movimiento obvio: EVM
la familiaridad es la mayor base de desarrolladores en cripto,
y negarse a encontrarla a mitad de camino es como las prometedoras L1 se mantienen permanentemente en un nicho.
Lo que me queda rondando, sin embargo, es una pregunta más acotada:
en una capa compatible con EVM, ¿hereda las garantías reales de privacidad de Dusk,
o hereda la transparencia predeterminada de EVM y simplemente se coloca al lado de la capa de privacidad de Dusk sin tocarla?
No es lo mismo, y la distinción
importa aquí más que en la mayoría de L1s
al añadir compatibilidad con EVM, porque la privacidad y la divulgación consciente de la normativa son la razón completa por la que existe Dusk.
Si un contrato desplegado en la capa de EVM se comporta
como cualquier otro contrato de EVM—estado público, público
calldata, el modelo estándar de transparencia—entonces “Dusk admite EVM” y “El modelo de privacidad de Dusk se extiende a EVM” son dos afirmaciones distintas, y solo el marketing tiende a sostenerlas ambas a la vez.
La versión honesta de ese equilibrio es que la compatibilidad con EVM y la computación confidencial nativa están, en cierta medida, enfrentadas a nivel estructural.
El modelo de ejecución de EVM no se diseñó pensando en la divulgación selectiva;
la propuesta de valor central de Dusk se construyó específicamente alrededor de eso.
Unir ambas bien —permitiendo
herramientas conocidas mientras se sigue obteniendo
transacciones confidenciales y contratos inteligentes conscientes de la normativa— es un problema de integración genuinamente difícil, no una casilla.
Es posible que Dusk lo haya resuelto de forma elegante.
También es posible que “compatible con EVM” signifique tranquilamente “compatible con EVM para la mitad transparente de la cadena”,
mientras que los contratos reales que preservan la privacidad sigan necesitando la pila nativa, XSC, y la curva de aprendizaje que se suponía que la compatibilidad con EVM eliminaría.
@Dusk #dusk $DUSK
junto a su cadena nativa, y la lógica declarada es
sencilla:
reducir la barrera para los desarrolladores, permitir que el Solidity
existente se conecte en lugar de pedirle a cada creador que
aprenda una pila nueva desde cero.
A simple vista, este es el movimiento obvio: EVM
la familiaridad es la mayor base de desarrolladores en cripto,
y negarse a encontrarla a mitad de camino es como las prometedoras L1 se mantienen permanentemente en un nicho.
Lo que me queda rondando, sin embargo, es una pregunta más acotada:
en una capa compatible con EVM, ¿hereda las garantías reales de privacidad de Dusk,
o hereda la transparencia predeterminada de EVM y simplemente se coloca al lado de la capa de privacidad de Dusk sin tocarla?
No es lo mismo, y la distinción
importa aquí más que en la mayoría de L1s
al añadir compatibilidad con EVM, porque la privacidad y la divulgación consciente de la normativa son la razón completa por la que existe Dusk.
Si un contrato desplegado en la capa de EVM se comporta
como cualquier otro contrato de EVM—estado público, público
calldata, el modelo estándar de transparencia—entonces “Dusk admite EVM” y “El modelo de privacidad de Dusk se extiende a EVM” son dos afirmaciones distintas, y solo el marketing tiende a sostenerlas ambas a la vez.
La versión honesta de ese equilibrio es que la compatibilidad con EVM y la computación confidencial nativa están, en cierta medida, enfrentadas a nivel estructural.
El modelo de ejecución de EVM no se diseñó pensando en la divulgación selectiva;
la propuesta de valor central de Dusk se construyó específicamente alrededor de eso.
Unir ambas bien —permitiendo
herramientas conocidas mientras se sigue obteniendo
transacciones confidenciales y contratos inteligentes conscientes de la normativa— es un problema de integración genuinamente difícil, no una casilla.
Es posible que Dusk lo haya resuelto de forma elegante.
También es posible que “compatible con EVM” signifique tranquilamente “compatible con EVM para la mitad transparente de la cadena”,
mientras que los contratos reales que preservan la privacidad sigan necesitando la pila nativa, XSC, y la curva de aprendizaje que se suponía que la compatibilidad con EVM eliminaría.
@Dusk #dusk $DUSK