Kiko奇科

DuskVM vs DuskEVM: Dos caminos para desarrolladores

¿Una blockchain necesita obligar a cada desarrollador al mismo entorno de ejecución?

Dusk adopta un enfoque diferente al ofrecer dos rutas de contratos inteligentes, cada una diseñada en torno a un modelo de desarrollo distinto.

DuskVM es la ruta nativa. Los desarrolladores escriben contratos en Rust, los compilan a WASM y los ejecutan directamente en Dusk L1. Esto permite que los contratos tengan acceso directo al modelo de ejecución de Dusk L1, a los modelos de transacción, a los contratos de protocolo y a las capacidades que deben estar cerca de la capa base, incluidas la privacidad y la funcionalidad de conocimiento cero.

DuskEVM toma una ruta centrada en la compatibilidad. Los desarrolladores pueden usar Solidity o Vyper junto con carteras, bibliotecas y herramientas EVM familiares. El asentamiento y la disponibilidad de datos se proporcionan a través de DuskDS mientras que DUSK sirve como el token de gas nativo.

La distinción, por lo tanto, tiene menos que ver con elegir qué entorno es mejor y más con adaptar la arquitectura a los requisitos de la aplicación. DuskVM favorece la ejecución directa en L1 y las capacidades nativas de Dusk. DuskEVM reduce la barrera para los desarrolladores que ya trabajan dentro del ecosistema de Ethereum.

Para Dusk, proporcionar ambas rutas crea un equilibrio interesante entre la funcionalidad nativa y la familiaridad para los desarrolladores.

¿Podría apoyar tanto la ejecución nativa como la compatibilidad con EVM ser una estrategia de desarrollo más fuerte que forzar un único entorno universal?

$DUSK

#dusk @Dusk

Staking en Dusk: Cómo DUSK asegura la red.

¿Qué aporta realmente el staking a una blockchain más allá de obtener recompensas?

En el staking de Dusk, este está directamente conectado al consenso. Los provisioners (proveedores) hacen staking de DUSK y participan en el proceso de proponer y validar bloques. Los provisioners activos pueden ganar recompensas provenientes de las emisiones de tokens y de las comisiones de transacciones, haciendo que el staking forme parte del mecanismo de seguridad de la red y no un producto de rendimiento separado.

El proceso de selección también es importante. La sortición determinista de Dusk selecciona generadores de bloques y miembros del comité de votación mediante un proceso ponderado por el stake. El mecanismo está diseñado para que la frecuencia de la selección sea proporcional al stake de un provisioner, manteniéndose reproducible e impredecible con antelación.

Luego, el consenso avanza a través de la validación de propuestas y la ratificación. Un provisioner seleccionado propone un bloque candidato, un comité lo evalúa y otro comité confirma el resultado de la validación. Una supermayoría de votos válidos puede producir un resultado exitoso.

Pero la participación conlleva responsabilidad. La documentación actual de Dusk distingue entre sanciones blandas por participación fallida y sanciones duras por conductas de consenso demostrablemente inválidas, incluyendo firmas en conflicto.

Esto crea una relación importante entre el stake económico y la responsabilidad de la red. DUSK no solo se bloquea: ofrece a los participantes una razón económica para operar correctamente la infraestructura de consenso.

Para @Dusk , el staking es, por lo tanto, parte de la arquitectura de seguridad en sí.

$DUSK #dusk

¿Atar el stake económico directamente a la responsabilidad del consenso crea un incentivo más fuerte para una participación confiable en la red?

comenta tu idea

ATARDECER: Más que un simple token.

¿Qué otorga a un token nativo de una blockchain una utilidad real más allá de ser simplemente negociado?

Para Dusk, DUSK se integra directamente en el funcionamiento de la red. La documentación oficial lo define como el token nativo que se utiliza para las comisiones de transacción y el staking, conectando el activo tanto con la actividad de la red como con la participación en el consenso.

Cada transacción requiere recursos de la red y DUSK funciona como el activo de gas utilizado para pagar esas operaciones. Esto incluye la actividad en los entornos de ejecución de Dusk, con DuskEVM usando explícitamente DUSK como su token de gas nativo.

El segundo rol es incluso más fundamental: el staking.

Dusk utiliza provisioners para participar en el consenso, seleccionándose provisioners activos para proponer y validar bloques. Según la documentación actual, el staking directo requiere operar un nodo provisioner y las recompensas se basan en la participación en el consenso y en el stake activo.

DUSK también conecta distintas partes del ecosistema. La documentación describe el movimiento entre Dusk L1 y DuskEVM, mientras que los desarrolladores pueden construir a través de DuskVM o DuskEVM según sus requisitos de ejecución y de herramientas.

Así que el punto interesante no es solo que DUSK sea el activo nativo de la red. Su utilidad está integrada en los mecanismos que hacen que la red funcione.

Para @Dusk , la utilidad del token está, por lo tanto, estrechamente vinculada con la infraestructura.

$DUSK #dusk

¿Un token nativo se vuelve más significativo cuando su utilidad es inseparable de las operaciones centrales de la red?

Citadel: Divulgación Selectiva para Identidad Digital

La identidad digital a menudo crea una difícil elección: revelar todo para demostrar quién eres o revelar demasiado poco para satisfacer la aplicación.

Dusk aborda este problema con Citadel, descrito en su documentación como la capa de identidad y acceso de la red para la divulgación selectiva.

La distinción es importante. La divulgación selectiva no se trata simplemente de mantener la información de identidad en privado. Se trata de diseñar el acceso en torno a la información que realmente necesita divulgarse para una interacción particular.

Esto encaja naturalmente con la arquitectura más amplia de Dusk. La red ya distingue entre cuentas públicas y cuentas protegidas (shielded), lo que permite que las transacciones funcionen con diferentes niveles de visibilidad. Citadel extiende esa forma de pensar hacia la identidad y el acceso, en lugar de centrarse solo en los datos de transacción.

La documentación de Dusk también enumera las Identidades Auto Soberanas (Self Sovereign Identities) de Citadel en la Red Dusk como un documento de investigación dedicado, junto con el trabajo técnico relacionado con sistemas de conocimiento cero y autenticación por desenfoque/ocultamiento de atributos (attribute blinding).

Lo que me interesa aquí es el principio arquitectónico de que la identidad no necesariamente necesita convertirse en un registro público permanente solo porque un usuario necesite demostrar algo.

Para @Dusk , la divulgación selectiva conecta la privacidad con un control de acceso práctico, lo cual es especialmente relevante cuando la infraestructura blockchain interactúa con aplicaciones donde la identidad y la autorización importan.

#dusk $DUSK

¿Podría la divulgación selectiva convertirse en la capa faltante entre la privacidad digital y los requisitos de identidad de los sistemas financieros regulados?

Privacidad sin perder la usabilidad práctica.

La privacidad en una blockchain se vuelve difícil cuando proteger la información también dificulta el uso del sistema para verificar o integrar.

Dusk aborda este problema haciendo que diferentes niveles de visibilidad de las transacciones formen parte de la arquitectura de la red.

Su modelo Moonlight ofrece transacciones públicas basadas en cuentas. Los saldos y la actividad de las transacciones pueden permanecer transparentes, lo cual es útil cuando se requiere visibilidad y verificación sencilla.

Phoenix toma el enfoque opuesto cuando la confidencialidad de las transacciones es importante. Usa transacciones basadas en UTXO protegidos, construidas alrededor de nulificadores de notas y pruebas de conocimiento cero. La red puede verificar que la transacción es válida sin exponer públicamente al remitente, al destinatario ni el monto transferido.

Pero la privacidad en Phoenix no se trata simplemente de ocultar información a todos. El protocolo incluye claves de visualización que permiten a los usuarios identificar las transacciones dirigidas a ellos, manteniendo protegida la autoridad para gastar. El whitepaper también describe cómo las claves de visualización pueden permitir el escaneo de transacciones delegado sin dar a la parte delegada la capacidad de gastar las notas.

Esa distinción es importante porque la confidencialidad de la infraestructura financiera práctica no necesariamente significa abandonar el acceso controlado a la información.

Para <c-1/> @Dusk , la privacidad se entiende mejor como una propiedad configurable de las transacciones y no como un obstáculo para la usabilidad.

$DUSK #dusk

¿La visibilidad selectiva podría convertirse en el modelo más práctico para las finanzas en blockchain que elegir entre transparencia total y anonimato total?

Luz de luna vs Fénix: dos modelos de transacción.

Una de las opciones más interesantes en Dusk es que la privacidad no se trata como una decisión de todo o nada.

En lugar de eso, Dusk ofrece dos modelos de transacción con diferentes propósitos: Moonlight y Phoenix.
Moonlight es el modelo de cuenta pública de Dusk. Cada cuenta se asocia con una clave pública y la red mantiene su saldo y el nonce de la transacción. Las transacciones se autorizan mediante firmas digitales mientras el estado de la cuenta permanece transparente para la red.
Phoenix adopta un enfoque fundamentalmente distinto. Es un modelo blindado basado en UTXO en el que los UTXO se representan como notas en un árbol de Merkle. Cuando se gasta una nota, un nulificador impide el doble gasto sin revelar cuál nota específica fue consumida. Las transacciones de Phoenix usan pruebas de conocimiento cero para que la red pueda verificar que la transacción sigue las reglas del protocolo sin exponer directamente los detalles subyacentes de la transacción.
Esa distinción importa porque distintas actividades financieras pueden requerir diferentes niveles de visibilidad.
Una cuenta pública puede proporcionar una transparencia sencilla, mientras que Phoenix puede ofrecer una privacidad de transacción más sólida. La documentación de Dusk describe estos modelos como complementarios, en lugar de sistemas en competencia.
Para @Dusk la idea arquitectónica más profunda es la flexibilidad: los usuarios no tienen que elegir entre una blockchain completamente transparente y otra completamente privada.

$DUSK #dusk

¿Podría dar a los usuarios ambos modelos de transacciones, transparentes y blindados, convertirse en un requisito importante para una infraestructura financiera seria en cadena?

Afirmación concisa: cómo Dusk alcanza la finalidad.

¿Qué necesita realmente una blockchain para que una transacción sea final?

Para Dusk, la respuesta comienza con Succinct Attestation, su protocolo de consenso de prueba de participación. El mecanismo se estructura en torno a comités seleccionados aleatoriamente por provisioners y una secuencia de pasos de validación de propuestas y ratificación.
Un provisioner bloquea DUSK como garantía y, a partir de ahí, puede volverse elegible para participar en el consenso. La sortición determinista de Dusk selecciona generadores de bloques y miembros del comité de votación mediante un proceso ponderado por la garantía, haciendo que la selección sea reproducible mientras conserva un grado de imprevisibilidad a través de la semilla del protocolo.
La parte interesante es lo que ocurre después de que se propone un bloque. Un comité lo valida mientras otro ratifica el resultado de la validación. Una supermayoría de votos válidos produce un resultado exitoso con firmas BLS que permiten agregar los votos en atestaciones compactas.
Luego, Dusk utiliza finalidad progresiva en lugar de tratar cada bloque aceptado como inmediatamente irreversible. Los bloques avanzan por estados que incluyen aceptado, atestado, confirmado y finalmente final. Un bloque final no puede reemplazarse bajo las reglas de finalidad del protocolo.
Esta arquitectura demuestra que la finalidad no se trata simplemente de velocidad. Se trata de coordinar a los participantes de la red, demostrando el acuerdo y aumentando progresivamente la confianza en la cadena.
@Dusk , por lo tanto, está convirtiendo el consenso en un componente arquitectónico de su infraestructura financiera, no solo en un mecanismo de seguridad.

$DUSK #dusk

¿Es más importante para las blockchains financieras la finalidad predecible y verificable que simplemente maximizar el rendimiento de las transacciones?

¿Qué ocurre antes de que una blockchain pueda llegar a un consenso?

La red primero necesita una forma fiable de transferir información entre nodos.
Aquí es donde Kadcast se convierte en una parte importante de la arquitectura de Dusk.
Según el whitepaper de Dusk, Kadcast es la capa de comunicación de igual a igual (peer-to-peer) responsable de difundir bloques, transacciones y votos de consenso. Está construida sobre la tabla hash distribuida (distributed hash table) de Kademlia, usando la distancia XOR para organizar cómo se comunican los nodos.
Lo interesante está en su diseño de difusión. En lugar de hacer que cada nodo reenvíe mensajes a todos sus vecinos, Kadcast utiliza pares (peers) seleccionados a distancias crecientes y organiza la propagación mediante árboles de multicast. El objetivo es ampliar la cobertura de la red con menos transmisiones redundantes.
Eso importa porque la eficiencia de la comunicación afecta directamente a la rapidez con la que la información puede circular a través de una red descentralizada. Dusk diseñó específicamente Kadcast para entornos donde importan los recursos de red y la comunicación de baja latencia. El whitepaper también señala que su estructura puede ocultar de forma natural los puntos de origen de los mensajes al evitar conexiones directas de igual a igual.
Así que Kadcast es más que un detalle de red. Es parte de la base que conecta la capa de transacciones de Dusk con su mecanismo de consenso.
Para @Dusk , la comunicación eficiente se trata, en última instancia, de crear las condiciones para una coordinación fiable en toda la red.

$DUSK
#dusk

A medida que las redes blockchain escalan, ¿la arquitectura de comunicación se volverá tan importante como el consenso en sí?

¿Qué es lo que realmente hace diferente a una arquitectura blockchain?
Con Dusk la respuesta no es una sola característica aislada. Es la forma en que varias capas están diseñadas para funcionar juntas.
En la base está DuskDS, la capa de finalidad de consenso y disponibilidad de datos de la red. Sobre eso, Dusk admite dos rutas de ejecución distintas: DuskVM, donde los contratos Rust/WASM se ejecutan directamente en Dusk L1, y DuskEVM, que proporciona un entorno EVM mientras utiliza DuskDS para la liquidación y la disponibilidad de datos.
La capa de red también es importante. Dusk usa Kadcast para propagar bloques, transacciones y votos de consenso. Su enfoque estructurado está diseñado para reducir la redundancia de mensajes y mejorar la eficiencia de la comunicación de red.
Luego está la capa de transacciones. Moonlight ofrece transacciones públicas basadas en cuentas, mientras que Phoenix ofrece un modelo protegido basado en UTXO. Esto significa que la privacidad no se trata como una ocurrencia tardía; forma parte de la arquitectura de transacciones del protocolo.
Esa combinación es lo que hace que @Dusk
resulte interesante para analizar. En lugar de obligar a cada aplicación a encajar en un solo modelo de ejecución, Dusk separa la red, el consenso, la liquidación, la ejecución y la privacidad de las transacciones en componentes complementarios.
$DUSK se integra en esta arquitectura como el activo nativo para las comisiones de transacción y el staking.
La pregunta más profunda es si esta arquitectura modular le da a Dusk una ventaja significativa a medida que evoluciona la infraestructura blockchain.
#dusk

¿Por qué las finanzas tradicionales necesitan una blockchain diseñada de manera diferente desde el principio?

El desafío no es simplemente colocar activos financieros en la cadena. Los mercados financieros necesitan privacidad, auditabilidad, cumplimiento normativo, escalabilidad y finalidad confiable al mismo tiempo. El documento técnico de Dusk lo plantea como un problema central de infraestructura: la información financiera sensible no siempre puede exponerse públicamente, pero las instituciones aún necesitan mecanismos que respalden la supervisión y el cumplimiento.

Aquí es donde @Dusk
toma un enfoque arquitectónico diferente.

En lugar de tratar la privacidad como una capa externa, Dusk la integra en la red mediante sus modelos de transacción. Moonlight ofrece un modelo transparente y basado en cuentas, mientras que Phoenix utiliza un diseño basado en UTXO para transacciones protegidas. El documento técnico también describe la Attestation Concisa como un mecanismo de consenso diseñado para lograr finalidad en segundos, orientado a los requisitos de baja latencia de los mercados financieros.
Lo importante es que Dusk no está presentando la adopción de blockchain como un problema puramente técnico. Está intentando abordar los requisitos institucionales que determinan si la infraestructura financiera realmente puede operar en cadena.
Eso hace que $DUSK sea interesante de estudiar más allá de su papel como token: la pregunta real es si la privacidad, el cumplimiento y la ejecución nativa de blockchain pueden coexistir sin obligar a las instituciones a comprometerse con cualquiera de ellos.

#dusk

¿La infraestructura de blockchain puede realmente satisfacer tanto el cumplimiento institucional como la privacidad del usuario a escala?

#baby $BABY

Bitcoin como capital productivo: pedir prestado contra BTC a través de TBV
Durante años, Bitcoin se ha visto principalmente como una reserva de valor a largo plazo. Aunque esa estrategia ha funcionado para muchos titulares, a menudo crea una elección difícil: vender BTC para acceder a la liquidez o mantenerlo intacto y dejar sin utilizar su potencial económico. Las Trustless Bitcoin Vaults (TBV) introducen una forma diferente de pensar sobre Bitcoin: no como un activo que deba venderse, sino como capital productivo.
Con TBV, el BTC nativo se bloquea en un vault basado en Taproot en la red de Bitcoin, mientras que se crea un registro de vault correspondiente en Ethereum. Una vez que el vault se verifica y activa, puede suministrarse como garantía a aplicaciones DeFi compatibles, incluida la integración en la testnet pública con Aave v4. Los usuarios pueden pedir prestados activos compatibles mientras su Bitcoin permanece bloqueado en Bitcoin durante todo el proceso.
Lo que hace especialmente interesante a este modelo es que la utilidad proviene de la seguridad de Bitcoin, en lugar de transferir el activo a otro lugar. No hay wrapping ni un puente custodial involucrado. En su lugar, el protocolo coordina $BTC y $ETH mediante verificación criptográfica, lo que permite que el BTC respalde préstamos mientras se preserva la autogestión (self custody) y el modelo nativo de confianza de Bitcoin.
Para mí, esto representa un cambio importante en la forma en que Bitcoin puede participar en las finanzas descentralizadas. El objetivo no es transformar Bitcoin en algo distinto, sino desbloquear liquidez sin obligar a los titulares a renunciar a la propiedad ni a comprometer la seguridad. El capital productivo no tiene por qué venir al costo de los principios fundamentales de Bitcoin.
El trabajo de @BabylonLabs_io demuestra que Bitcoin puede permanecer seguro, nativo y con custodia propia, al tiempo que se convierte en un participante más activo en los mercados financieros descentralizados.

Pregunta: Si Bitcoin puede desbloquear liquidez sin venderse, tokenizarse con wrapping o utilizarse a través de puentes, ¿podría pedir prestado contra BTC nativo convertirse en uno de los casos de uso más importantes para Bitcoin en DeFi?