AbdullRauf

ALERTA DE SORTEO 🧧
¡Estamos regalando 2000 regalos a nuestra Familia Square como un enorme agradecimiento por su apoyo!
Para participar:
✅ Sigue
✅ Comparte esta publicación
✅ Comenta "666 !"
Se seleccionarán ganadores al azar. ¡Mucha suerte a todos! 🚀

Al principio asumí que los dos modelos de transacción en Dusk eran solo un ajuste de privacidad. Público o privado. Un interruptor. Una elección sencilla.

La diferencia real va más allá.

Moonlight funciona como Ethereum. Tu cuenta tiene un nonce. Cada transacción lo incrementa públicamente. Cualquiera puede ver tu saldo, tu historial y tu secuencia. El nonce es un contador. También es un rastro.

Phoenix funciona de manera diferente. No hay cuenta. No hay saldo visible. No hay contador secuencial. En su lugar, cuando gastas una nota, generas un nullifier. La red registra ese nullifier y sabe que la nota ya no está. Pero no puede vincular el nullifier con la nota de la que provino. El gasto es demostrable. La identidad de lo que se gastó no lo es.

Esa distinción importa más de lo que suena. En Moonlight, tu historial de transacciones es una historia legible. En Phoenix, la red sabe que se están escribiendo capítulos sin saber qué dicen.

Lo que no dejo de pensar es qué instituciones quieren realmente cada modelo. Un banco que procese una liquidación podría necesitar Moonlight para rastros de auditoría. Un fondo que ejecute una estrategia podría necesitar Phoenix para evitar el front-running. Ambos pueden vivir en la misma cadena. Ninguno obliga al otro a comprometerse.

Lo que no puedo encontrar en la documentación es cómo tratan los reguladores los nullifiers como evidencia. Un nonce prueba el orden. Un nullifier prueba el gasto sin revelar la nota. ¿Son legalmente equivalentes en un contexto de cumplimiento?

¿Qué piensas — cuando un regulador pide una prueba de transacción, un nullifier cumple el requisito o solo plantea una pregunta más difícil?

#dusk $DUSK @Dusk

Aria

suadagar

Sr. Raj

ostra

prof

cripto

yiiz

DT Singh

Shaheen

sara

najaf

ir

bilverse

príncipe

La privacidad atornillada a EVM no es lo mismo que la privacidad integrada desde el primer día.#dusk

Solía mirar un nuevo diseño de consenso y hacer primero una sola pregunta: ¿Cómo rompe esto un atacante?

Estudiar Dusk cambió ese hábito. Con la Atestación Concisa, aparece un escenario diferente. Imagina que ya estás seleccionado para generar un bloque en una iteración posterior. También estás votando sobre el actual. ¿Ayudas a que el bloque actual tenga éxito y te llevas la recompensa del votante, o te quedas en silencio para que la iteración falle y tu futura posición como generador mejore?

Ese es el Problema de Incentivo al Generador Futuro. No viene de afuera. Viene de los incentivos disponibles para un participante legítimo.

La respuesta de Dusk fue reconfigurar esos incentivos. Separar las recompensas del generador y del votante. Excluir al generador de la siguiente iteración de la votación actual. Limitar cuántas iteraciones pueden ejecutarse.

Hay un compromiso. Cada regla de incentivo adicional agrega otra suposición que aún debe sostenerse bajo presión.

El juego real debajo de la criptografía es si la jugada más racional se mantiene como la honesta.

#dusk $DUSK @Dusk

$DUSK está caído 93%… Sin embargo, mantiene asociaciones y una cartera de emisión de +200M €; la mayoría de los protocolos a este precio no tienen

Al principio asumí que agregar privacidad a un entorno EVM era lo mismo que construir privacidad desde el inicio. Desde fuera, ambos se ven similares. Por dentro no.

El modelo de cuentas de EVM lleva una suposición estructural. Las direcciones persisten. La actividad se acumula. Incluso cuando las transacciones individuales están cifradas, la cuenta en sí se convierte en un patrón con el tiempo. Hedger agrega confidencialidad sobre ese modelo. Los datos de la transacción pueden volverse opacos. La estructura de la cuenta sigue siendo visible.

Así que la pregunta real es más limitada. Cuando Hedger cifra una transacción, ¿qué exactamente se oculta y qué no? Los montos y la lógica interna pueden mantenerse privados. El hecho de que esta cuenta interactuó con este contrato en ese momento a menudo sigue siendo visible. En las finanzas reguladas, quién operó con quién y cuándo puede importar tanto como qué negociaron.

Esto no es un defecto del diseño. EVM basado en cuentas es práctico para los desarrolladores. Hedger es una capa real de privacidad. El riesgo es malinterpretar. Una capa de privacidad que la gente sobreestima puede ser más peligrosa que ninguna capa de privacidad en absoluto.

¿La confidencialidad a nivel de transacción le brinda a las instituciones suficiente protección, o el modelo de cuenta subyacente limita silenciosamente toda la promesa?

#dusk $DUSK @Dusk