Crypto knowledge P
164 Publicaciones
Crypto knowledge P
15 Siguiendo
1.4K+ Seguidores
518 Me gusta
Publicaciones
🎁🎁Reclamo de sobre rojo rápido 🎁🎁
Una conexión de cartera Dusk parece un simple clic. Pero cuando empecé a mirar lo que hay detrás, me di cuenta de que hay bastante en juego.
Primero recorrí el flujo de descubrimiento de la cartera. Un dApp no simplemente toma la cartera Dusk que está en la página. Las carteras se anuncian, el dApp las descubre y, si hay más de una instalada, hay que seleccionar un proveedor. Cada una también lleva su propia identidad. Es un detalle pequeño, pero importa porque el sitio necesita saber con qué cartera se está comunicando realmente.
Luego observé el lado de los permisos. Una solicitud de perfil, una dirección de recepción protegida, una transacción, una llamada de contrato o una firma no son todas lo mismo. Pasan por solicitudes de cartera diferentes, y la cartera también puede informar cambios de perfil, de cadena y del nodo seleccionado mientras la conexión está activa. Así que «conectado» en realidad no significa que el dApp tenga acceso ilimitado.
La parte de la firma fue la que me pareció más interesante. Dusk introduce el origen y el ID de cadena en el contexto del mensaje firmado. La firma de autenticación también incluye un nonce y marcas de tiempo. Así que la firma no es solo «esta cuenta firmó algo»: también hay contexto sobre la solicitud.
También revisé los cambios recientes de la cartera relacionados con esto. Los mensajes del proveedor se restringieron para que otro proveedor Dusk instalado no pueda recibir la misma solicitud del dApp. Se ajustaron el manejo de origen y permisos, y las conexiones RPC del dApp y con nodos personalizados se restringieron a endpoints HTTPS o de desarrollo local. Las notas de seguridad de Dusk también mencionan límites como que la memoria de JavaScript no se puede borrar de forma fiable.
Para mí, eso cambia cómo se ve el pequeño botón «Connect Wallet». No es realmente un solo permiso. Hay toda una capa entre el sitio web y la clave que decide qué cartera se está usando, qué puede pedir el dApp y qué firma realmente el usuario.
$DUSK @Dusk #dusk
Primero recorrí el flujo de descubrimiento de la cartera. Un dApp no simplemente toma la cartera Dusk que está en la página. Las carteras se anuncian, el dApp las descubre y, si hay más de una instalada, hay que seleccionar un proveedor. Cada una también lleva su propia identidad. Es un detalle pequeño, pero importa porque el sitio necesita saber con qué cartera se está comunicando realmente.
Luego observé el lado de los permisos. Una solicitud de perfil, una dirección de recepción protegida, una transacción, una llamada de contrato o una firma no son todas lo mismo. Pasan por solicitudes de cartera diferentes, y la cartera también puede informar cambios de perfil, de cadena y del nodo seleccionado mientras la conexión está activa. Así que «conectado» en realidad no significa que el dApp tenga acceso ilimitado.
La parte de la firma fue la que me pareció más interesante. Dusk introduce el origen y el ID de cadena en el contexto del mensaje firmado. La firma de autenticación también incluye un nonce y marcas de tiempo. Así que la firma no es solo «esta cuenta firmó algo»: también hay contexto sobre la solicitud.
También revisé los cambios recientes de la cartera relacionados con esto. Los mensajes del proveedor se restringieron para que otro proveedor Dusk instalado no pueda recibir la misma solicitud del dApp. Se ajustaron el manejo de origen y permisos, y las conexiones RPC del dApp y con nodos personalizados se restringieron a endpoints HTTPS o de desarrollo local. Las notas de seguridad de Dusk también mencionan límites como que la memoria de JavaScript no se puede borrar de forma fiable.
Para mí, eso cambia cómo se ve el pequeño botón «Connect Wallet». No es realmente un solo permiso. Hay toda una capa entre el sitio web y la clave que decide qué cartera se está usando, qué puede pedir el dApp y qué firma realmente el usuario.
$DUSK @Dusk #dusk
Con verificación
Creo que normalmente hacemos la pregunta equivocada cuando una transacción de “Dusk” “falla”.
Un 202 Accepted solo significa que el nodo aceptó la solicitud para el enrutamiento. No significa que la transacción ya esté en el mempool o en un bloque. Un ejemplo que me pareció interesante es un nonce futuro. Si llega una transacción de Moonlight con un nonce futuro mientras aún falta un nonce anterior, Dusk puede mantenerla fuera del mempool real y esperar a que se cierre la brecha de nonces en lugar de rechazarla de inmediato. Obtiene un estado diferido mientras ocurre eso.
Esa es solo una parte de la historia. Una vez que una transacción pasa la admisión, entra en el mempool local de ese nodo. Los otros nodos mantienen sus propios mempools y también ejecutan sus propias comprobaciones de admisión. Más tarde, una transacción puede seleccionarse para un bloque, ejecutarse y finalmente quedar finalizada. También puede salir del mempool local sin que eso signifique automáticamente que falló. La caducidad, el reemplazo, los límites de capacidad y los conflictos pueden llevar a su eliminación.
Aquí es donde creo que la diferencia importa para billeteras y exchanges. La guía de integración de Dusk indica que se debe conservar la transacción firmada exacta, tratar el 202 Accepted solo como un enrutamiento exitoso y retransmitir los mismos bytes firmados después de un tiempo de espera de transporte en lugar de crear una nueva transacción a ciegas. Un retiro solo debe marcarse como completado después de comprobar que la ejecución se realizó y que el bloque quedó finalizado.
Cuanto más lo miré, menos “transacción enviada” sonaba como un estado útil por sí solo. Una transacción puede estar esperando un nonce, estar en el mempool de un nodo, ejecutarse con un error o estar en un bloque que todavía no es final. Son situaciones muy distintas, aunque todas pueden parecer “sigue pendiente” desde fuera.
Para mí, esa es la conclusión útil del flujo de transacciones de Dusk: enviada es solo el comienzo. Lo que importa es el estado que realmente puedes demostrar que alcanzó la transacción.
$DUSK @Dusk #dusk
Un 202 Accepted solo significa que el nodo aceptó la solicitud para el enrutamiento. No significa que la transacción ya esté en el mempool o en un bloque. Un ejemplo que me pareció interesante es un nonce futuro. Si llega una transacción de Moonlight con un nonce futuro mientras aún falta un nonce anterior, Dusk puede mantenerla fuera del mempool real y esperar a que se cierre la brecha de nonces en lugar de rechazarla de inmediato. Obtiene un estado diferido mientras ocurre eso.
Esa es solo una parte de la historia. Una vez que una transacción pasa la admisión, entra en el mempool local de ese nodo. Los otros nodos mantienen sus propios mempools y también ejecutan sus propias comprobaciones de admisión. Más tarde, una transacción puede seleccionarse para un bloque, ejecutarse y finalmente quedar finalizada. También puede salir del mempool local sin que eso signifique automáticamente que falló. La caducidad, el reemplazo, los límites de capacidad y los conflictos pueden llevar a su eliminación.
Aquí es donde creo que la diferencia importa para billeteras y exchanges. La guía de integración de Dusk indica que se debe conservar la transacción firmada exacta, tratar el 202 Accepted solo como un enrutamiento exitoso y retransmitir los mismos bytes firmados después de un tiempo de espera de transporte en lugar de crear una nueva transacción a ciegas. Un retiro solo debe marcarse como completado después de comprobar que la ejecución se realizó y que el bloque quedó finalizado.
Cuanto más lo miré, menos “transacción enviada” sonaba como un estado útil por sí solo. Una transacción puede estar esperando un nonce, estar en el mempool de un nodo, ejecutarse con un error o estar en un bloque que todavía no es final. Son situaciones muy distintas, aunque todas pueden parecer “sigue pendiente” desde fuera.
Para mí, esa es la conclusión útil del flujo de transacciones de Dusk: enviada es solo el comienzo. Lo que importa es el estado que realmente puedes demostrar que alcanzó la transacción.
$DUSK @Dusk #dusk
Con verificación
Las 280 transferencias me llamaron la atención, pero al final presté más atención a todo lo que había alrededor.
Revisé el trabajo más reciente de validación y el cierre del Dusk Hyperlane, y hasta ahora los resultados de las pruebas se ven sólidos. La última reproducción limpia pasó las compilaciones del contrato, las pruebas de VM, las pruebas de transacciones y las comprobaciones del agente de Hyperlane. Luego se ejecutó una prueba de aguante de alto volumen durante 7 ciclos, con 20 transferencias de EVM a Dusk y 20 de Dusk a EVM en cada ciclo. Eso dio un total de 280 transferencias en 7,282 segundos antes de que terminara la ventana de prueba de 120 minutos.
Lo que encontré más importante fue la lista de verificación de producción que estaba junto a esos resultados. Aún se está decidiendo la custodia del firmante de producción. También hay una decisión abierta sobre la recuperación de fondos en escrow pendiente, cuánto tiempo debería ejecutarse la prueba de aguante y cómo debería funcionar la configuración de CI y reproducibilidad. Esas cosas son fáciles de pasar por alto cuando el titular es que la prueba salió exitosa, pero son las que yo querría entender antes de que entre en juego una liquidez real.
La pregunta sobre el firmante es especialmente difícil de ignorar después de lo que ocurrió con el puente antiguo de Dusk a EVM en enero. Un atacante obtuvo acceso a la billetera de firma del puente, robó DUSK desde ella y movió parte de los fondos robados a través del puente hacia BNB Smart Chain. Dusk dejó claro que el incidente fue una filtración/compromiso de la billetera del puente, no una explotación del consenso o del protocolo de Dusk. Más tarde, el puente se rediseñó con una separación más fuerte entre la firma, el manejo de eventos y la liberación de fondos, además de controles de saldo y recuperación más estrictos.
Así que no estoy viendo las 280 transferencias como una luz verde ni como una bandera roja. Muestran que el sistema se está probando en serio. Lo que importa para mí ahora es cómo se supone que debe comportarse el sistema cuando algo sale mal, quién controla las partes sensibles y cómo se gestiona la recuperación.
Eso es lo que yo querría que quedara resuelto antes de tratar Dusk Hyperlane como infraestructura para una liquidez significativa.
$DUSK @Dusk #dusk
Revisé el trabajo más reciente de validación y el cierre del Dusk Hyperlane, y hasta ahora los resultados de las pruebas se ven sólidos. La última reproducción limpia pasó las compilaciones del contrato, las pruebas de VM, las pruebas de transacciones y las comprobaciones del agente de Hyperlane. Luego se ejecutó una prueba de aguante de alto volumen durante 7 ciclos, con 20 transferencias de EVM a Dusk y 20 de Dusk a EVM en cada ciclo. Eso dio un total de 280 transferencias en 7,282 segundos antes de que terminara la ventana de prueba de 120 minutos.
Lo que encontré más importante fue la lista de verificación de producción que estaba junto a esos resultados. Aún se está decidiendo la custodia del firmante de producción. También hay una decisión abierta sobre la recuperación de fondos en escrow pendiente, cuánto tiempo debería ejecutarse la prueba de aguante y cómo debería funcionar la configuración de CI y reproducibilidad. Esas cosas son fáciles de pasar por alto cuando el titular es que la prueba salió exitosa, pero son las que yo querría entender antes de que entre en juego una liquidez real.
La pregunta sobre el firmante es especialmente difícil de ignorar después de lo que ocurrió con el puente antiguo de Dusk a EVM en enero. Un atacante obtuvo acceso a la billetera de firma del puente, robó DUSK desde ella y movió parte de los fondos robados a través del puente hacia BNB Smart Chain. Dusk dejó claro que el incidente fue una filtración/compromiso de la billetera del puente, no una explotación del consenso o del protocolo de Dusk. Más tarde, el puente se rediseñó con una separación más fuerte entre la firma, el manejo de eventos y la liberación de fondos, además de controles de saldo y recuperación más estrictos.
Así que no estoy viendo las 280 transferencias como una luz verde ni como una bandera roja. Muestran que el sistema se está probando en serio. Lo que importa para mí ahora es cómo se supone que debe comportarse el sistema cuando algo sale mal, quién controla las partes sensibles y cómo se gestiona la recuperación.
Eso es lo que yo querría que quedara resuelto antes de tratar Dusk Hyperlane como infraestructura para una liquidez significativa.
$DUSK @Dusk #dusk
Parcialmente cierto
Un pequeño detalle sobre las transacciones de Dusk que no dejaba de preocuparme.
Estaba leyendo el flujo de transacciones de Dusk y descubrí que una transacción actualmente lleva una sola operación. Para algo básico, en realidad tiene bastante sentido. Esto facilita validarlo y entenderlo. Pero luego pensé en un flujo DeFi más complejo, como preparar fondos, hacer un swap y luego hacer staking. Para el usuario, eso se siente como una sola acción. En Dusk, se convierte en varias transacciones separadas, cada una con su propio nonce, firma y probabilidad de que sea incluida.
Ahí es donde empecé a preguntarme qué pasa si solo se ejecuta una parte de la secuencia. No hay un mecanismo de rollback a nivel de protocolo entre esas transacciones, así que puedes terminar a la mitad de un flujo más grande. Para un trade normal, probablemente no sea un gran problema. Pero para DeFi, operaciones de liquidación o del tesoro, puedo ver que esto se convierta en un dolor de cabeza real.
Lo interesante que encontré es que Dusk ya tiene un issue abierto en GitHub, #4058, que habla sobre transacciones por lotes. Una idea es un contrato agregador que mete varias llamadas en una sola transacción, pero los contratos que usan caller() podrían ver al agregador en lugar del usuario original. La otra opción es un batch a nivel de protocolo donde varias operaciones permanezcan bajo la identidad del usuario, pero eso implicaría cambios en el formato de la transacción, soporte de consenso, activación de un hard fork y SDKs.
Así que no reemplazaría el modelo actual de una sola operación. Creo que tiene sentido como predeterminado simple. Preferiría ver un batch atómico opcional para flujos complejos, donde las operaciones se ejecuten en orden, todo el batch pueda revertirse si una falla y el usuario original siga siendo visible para cada llamada.
¿Sería ese el equilibrio adecuado para Dusk, o la complejidad extra del protocolo no vale la pena?
$DUSK @Dusk #dusk
Estaba leyendo el flujo de transacciones de Dusk y descubrí que una transacción actualmente lleva una sola operación. Para algo básico, en realidad tiene bastante sentido. Esto facilita validarlo y entenderlo. Pero luego pensé en un flujo DeFi más complejo, como preparar fondos, hacer un swap y luego hacer staking. Para el usuario, eso se siente como una sola acción. En Dusk, se convierte en varias transacciones separadas, cada una con su propio nonce, firma y probabilidad de que sea incluida.
Ahí es donde empecé a preguntarme qué pasa si solo se ejecuta una parte de la secuencia. No hay un mecanismo de rollback a nivel de protocolo entre esas transacciones, así que puedes terminar a la mitad de un flujo más grande. Para un trade normal, probablemente no sea un gran problema. Pero para DeFi, operaciones de liquidación o del tesoro, puedo ver que esto se convierta en un dolor de cabeza real.
Lo interesante que encontré es que Dusk ya tiene un issue abierto en GitHub, #4058, que habla sobre transacciones por lotes. Una idea es un contrato agregador que mete varias llamadas en una sola transacción, pero los contratos que usan caller() podrían ver al agregador en lugar del usuario original. La otra opción es un batch a nivel de protocolo donde varias operaciones permanezcan bajo la identidad del usuario, pero eso implicaría cambios en el formato de la transacción, soporte de consenso, activación de un hard fork y SDKs.
Así que no reemplazaría el modelo actual de una sola operación. Creo que tiene sentido como predeterminado simple. Preferiría ver un batch atómico opcional para flujos complejos, donde las operaciones se ejecuten en orden, todo el batch pueda revertirse si una falla y el usuario original siga siendo visible para cada llamada.
¿Sería ese el equilibrio adecuado para Dusk, o la complejidad extra del protocolo no vale la pena?
$DUSK @Dusk #dusk
#dusk $DUSK @Dusk
He estado mirando recientemente el lado de las PYME de Dusk y una cosa no paraba de volver a mí.
Tokenizar una PYME suena simple cuando lo dices en una sola línea.
Pon el activo en la cadena.
Permite que los inversores accedan.
Listo.
Pero en realidad no es tan simple.
Alguien todavía tiene que decidir quién puede invertir, cómo se gestiona la propiedad, cómo funcionan las transferencias, qué información debe divulgarse y cómo se liquida el dinero real.
Y creo que es aquí donde a veces la gente subestima el problema de los activos del mundo real (RWA).
El token en sí es solo una parte del proceso. El mercado alrededor de él todavía tiene que funcionar.
Ahí es donde el enfoque de Dusk se me hace interesante.
Su enfoque reciente en mercados privados y PYME no se trata realmente de poner otro activo en una blockchain solo por hacerlo.
Más bien, se trata de conectar las distintas partes del proceso.
Porque la parte difícil no es crear el token.
La parte difícil es hacer que el token sea utilizable.
Una PYME puede tener un valor tokenizado, pero si los inversores no pueden acceder a él correctamente, si las transferencias se vuelven complicadas o si no hay un mercado real a su alrededor, entonces no ha cambiado mucho.
Por eso también me da curiosidad ver cómo se desarrolla el lado de Dusk Trade.
Si puede hacer el proceso más sencillo tanto para las empresas como para los inversores, entonces esto se vuelve más interesante que solo otra narrativa de RWA.
Aun así, es pronto.
Para mí, la prueba real es simple:
¿Puede Dusk hacer que los mercados privados sean realmente más fáciles de usar, o solo estamos poniendo un proceso antiguo en la cadena y llamándolo nuevo?
Esa es la parte que seguiré de cerca mientras Dusk Trade empiece a tomar forma.
He estado mirando recientemente el lado de las PYME de Dusk y una cosa no paraba de volver a mí.
Tokenizar una PYME suena simple cuando lo dices en una sola línea.
Pon el activo en la cadena.
Permite que los inversores accedan.
Listo.
Pero en realidad no es tan simple.
Alguien todavía tiene que decidir quién puede invertir, cómo se gestiona la propiedad, cómo funcionan las transferencias, qué información debe divulgarse y cómo se liquida el dinero real.
Y creo que es aquí donde a veces la gente subestima el problema de los activos del mundo real (RWA).
El token en sí es solo una parte del proceso. El mercado alrededor de él todavía tiene que funcionar.
Ahí es donde el enfoque de Dusk se me hace interesante.
Su enfoque reciente en mercados privados y PYME no se trata realmente de poner otro activo en una blockchain solo por hacerlo.
Más bien, se trata de conectar las distintas partes del proceso.
Porque la parte difícil no es crear el token.
La parte difícil es hacer que el token sea utilizable.
Una PYME puede tener un valor tokenizado, pero si los inversores no pueden acceder a él correctamente, si las transferencias se vuelven complicadas o si no hay un mercado real a su alrededor, entonces no ha cambiado mucho.
Por eso también me da curiosidad ver cómo se desarrolla el lado de Dusk Trade.
Si puede hacer el proceso más sencillo tanto para las empresas como para los inversores, entonces esto se vuelve más interesante que solo otra narrativa de RWA.
Aun así, es pronto.
Para mí, la prueba real es simple:
¿Puede Dusk hacer que los mercados privados sean realmente más fáciles de usar, o solo estamos poniendo un proceso antiguo en la cadena y llamándolo nuevo?
Esa es la parte que seguiré de cerca mientras Dusk Trade empiece a tomar forma.
He estado profundizando en cómo Dusk gestiona las transacciones y noté algo que antes no me había planteado.
Moonlight y Phoenix no son solo dos versiones de lo mismo.
Moonlight es basado en cuentas. Tienes una cuenta, un saldo, un nonce y claves, y la red comprueba la transacción en función de ese estado.
Phoenix adopta un enfoque diferente.
Usa notas almacenadas en un árbol de Merkle. Cuando una nota se gasta, se crea un nullifier para que la misma nota no pueda volver a gastarse.
Lo que captó mi atención es que la red no necesita revelar qué nota específica se gastó.
Ahí es donde entran las pruebas ZK: la transacción puede verificarse sin exponer los detalles privados subyacentes. Las claves de notas de un solo uso también ayudan a reducir la vinculación entre transacciones.
También hay un mecanismo de delegación para tareas como el escaneo y la generación de pruebas, sin dar al delegado acceso para gastar los fondos.
Así que no lo describiría simplemente como “Moonlight es transparente y Phoenix es privado”.
Son modelos de transacción distintos, diseñados para satisfacer requisitos diferentes, mientras operan en la misma red de Dusk.
Y sinceramente, creo que esa elección de diseño es bastante interesante.
¿Con cuál preferirías quedarte en Dusk?
@Dusk $DUSK #dusk
Moonlight y Phoenix no son solo dos versiones de lo mismo.
Moonlight es basado en cuentas. Tienes una cuenta, un saldo, un nonce y claves, y la red comprueba la transacción en función de ese estado.
Phoenix adopta un enfoque diferente.
Usa notas almacenadas en un árbol de Merkle. Cuando una nota se gasta, se crea un nullifier para que la misma nota no pueda volver a gastarse.
Lo que captó mi atención es que la red no necesita revelar qué nota específica se gastó.
Ahí es donde entran las pruebas ZK: la transacción puede verificarse sin exponer los detalles privados subyacentes. Las claves de notas de un solo uso también ayudan a reducir la vinculación entre transacciones.
También hay un mecanismo de delegación para tareas como el escaneo y la generación de pruebas, sin dar al delegado acceso para gastar los fondos.
Así que no lo describiría simplemente como “Moonlight es transparente y Phoenix es privado”.
Son modelos de transacción distintos, diseñados para satisfacer requisitos diferentes, mientras operan en la misma red de Dusk.
Y sinceramente, creo que esa elección de diseño es bastante interesante.
¿Con cuál preferirías quedarte en Dusk?
@Dusk $DUSK #dusk
🔥 Phoenix
50%
🌙 Moonlight
10%
⚡ Both
20%
🤔 Depends on the use case
20%
10 Votos • Votación cerrada
Estar un token en la cadena es solo el comienzo.
La pregunta real es: ¿las reglas en torno a ese activo pueden moverse también a la cadena?
Piensa en un bono regulado.
Convertirlo en un token quizá sea la parte fácil. Pero un mercado financiero real necesita más:
• Solo los inversores elegibles deberían poder mantenerlo
• Las transferencias pueden requerir restricciones integradas
• Las posiciones sensibles no deberían ser públicas por defecto
• Las partes adecuadas necesitan acceso a la información correcta
• El efectivo y la entrega del activo deben liquidarse juntos
Ahí es donde la tokenización se convierte en algo más que un simple envoltorio digital.
Se convierte en infraestructura de mercado.
Por eso @Dusk destaca para mí. Su enfoque no es simplemente poner activos en la cadena, sino habilitar flujos de trabajo regulados a su alrededor: transferencias controladas, divulgación selectiva, privacidad, elegibilidad y liquidación como partes conectadas de un solo sistema.
La gran oportunidad no es solo la de los activos tokenizados.
Es la de los mercados programables:
Reglas que siguen al activo.
Privacidad que puede coexistir con la rendición de cuentas.
Liquidación que ocurre como parte de la transacción.
Cambios de titularidad que no rompen los requisitos de cumplimiento.
Si ese modelo funciona a escala, las finanzas en cadena podrían verse menos como los mercados tradicionales con una base de datos nueva, y más como un sistema financiero rediseñado.
¿Qué crees que es el obstáculo más difícil para que las finanzas del mundo real se trasladen a la cadena: la identidad, la privacidad, el trading, la liquidación o el servicio del activo?
$DUSK #dusk @Dusk
La pregunta real es: ¿las reglas en torno a ese activo pueden moverse también a la cadena?
Piensa en un bono regulado.
Convertirlo en un token quizá sea la parte fácil. Pero un mercado financiero real necesita más:
• Solo los inversores elegibles deberían poder mantenerlo
• Las transferencias pueden requerir restricciones integradas
• Las posiciones sensibles no deberían ser públicas por defecto
• Las partes adecuadas necesitan acceso a la información correcta
• El efectivo y la entrega del activo deben liquidarse juntos
Ahí es donde la tokenización se convierte en algo más que un simple envoltorio digital.
Se convierte en infraestructura de mercado.
Por eso @Dusk destaca para mí. Su enfoque no es simplemente poner activos en la cadena, sino habilitar flujos de trabajo regulados a su alrededor: transferencias controladas, divulgación selectiva, privacidad, elegibilidad y liquidación como partes conectadas de un solo sistema.
La gran oportunidad no es solo la de los activos tokenizados.
Es la de los mercados programables:
Reglas que siguen al activo.
Privacidad que puede coexistir con la rendición de cuentas.
Liquidación que ocurre como parte de la transacción.
Cambios de titularidad que no rompen los requisitos de cumplimiento.
Si ese modelo funciona a escala, las finanzas en cadena podrían verse menos como los mercados tradicionales con una base de datos nueva, y más como un sistema financiero rediseñado.
¿Qué crees que es el obstáculo más difícil para que las finanzas del mundo real se trasladen a la cadena: la identidad, la privacidad, el trading, la liquidación o el servicio del activo?
$DUSK #dusk @Dusk
Parcialmente cierto
Todo el mundo habla de la escalabilidad de blockchain.
Casi nadie habla del costo de recordar.
Una red puede procesar enormes cantidades de actividad, pero cada bloque, evento y transición de estado también crea datos históricos que eventualmente tienen que almacenarse y mantenerse.
Por eso encontré más interesante la reciente actualización de infraestructura de Dusk que otro titular sobre TPS.
Dusk redujo el almacenamiento de eventos del nodo de archivo de 310.7 MB a 27.7 MB — más de un 90% de reducción — mientras preserva los resultados históricos.
Lo interesante no es simplemente la cifra.
Es lo que esto dice sobre la infraestructura de blockchain.
Si las redes van a terminar soportando activos financieros y aplicaciones que pueden necesitar años de verificación histórica, la eficiencia de almacenamiento se convierte en parte de la arquitectura misma.
La escalabilidad no consiste solo en procesar más. También es llevar menos datos sin perder el historial que hace que la red sea verificable.
Estas mejoras probablemente no generen los titulares más sonoros.
Pero el trabajo de infraestructura, aunque aburrido, a menudo es lo que hace posible la adopción a gran escala.
Dusk no solo está trabajando en lo que ocurre en la cadena.
También está mejorando qué tan eficientemente puede la red recordar lo que pasó.
@Dusk $DUSK #dusk
Casi nadie habla del costo de recordar.
Una red puede procesar enormes cantidades de actividad, pero cada bloque, evento y transición de estado también crea datos históricos que eventualmente tienen que almacenarse y mantenerse.
Por eso encontré más interesante la reciente actualización de infraestructura de Dusk que otro titular sobre TPS.
Dusk redujo el almacenamiento de eventos del nodo de archivo de 310.7 MB a 27.7 MB — más de un 90% de reducción — mientras preserva los resultados históricos.
Lo interesante no es simplemente la cifra.
Es lo que esto dice sobre la infraestructura de blockchain.
Si las redes van a terminar soportando activos financieros y aplicaciones que pueden necesitar años de verificación histórica, la eficiencia de almacenamiento se convierte en parte de la arquitectura misma.
La escalabilidad no consiste solo en procesar más. También es llevar menos datos sin perder el historial que hace que la red sea verificable.
Estas mejoras probablemente no generen los titulares más sonoros.
Pero el trabajo de infraestructura, aunque aburrido, a menudo es lo que hace posible la adopción a gran escala.
Dusk no solo está trabajando en lo que ocurre en la cadena.
También está mejorando qué tan eficientemente puede la red recordar lo que pasó.
@Dusk $DUSK #dusk
Con verificación
Una actualización de One Dusk que creo merece más atención es el lanzamiento de la testnet de DuskEVM.
A primera vista, “otro entorno EVM” no suena especialmente interesante. Pero la arquitectura cuenta una historia diferente.
DuskEVM trae Solidity, Hardhat y las herramientas estándar de Ethereum a Dusk, mientras que la ejecución se resuelve a través de DuskDS. Esta separación es importante porque los desarrolladores pueden usar un entorno de aplicaciones familiar sin renunciar al sistema nativo de Dusk para la liquidación y la disponibilidad de datos.
Lo más interesante es lo que hay alrededor.
Dusk también está construyendo Dusk Trade como una capa de aplicación para activos financieros tokenizados, con flujos de trabajo en torno al alta de inversores, vinculación de billeteras, transferencias controladas, coordinación de pagos y una liquidación conforme.
Así que el desarrollo reciente no se trata solo de añadir compatibilidad con EVM.
Más bien, parece que Dusk se está encaminando hacia un stack completo en el que distintas piezas resuelven distintos problemas:
→ DuskDS: consenso, liquidación y disponibilidad de datos
→ DuskEVM: ejecución EVM familiar
→ DuskVM: ejecución nativa en Rust/WASM con acceso directo a las capacidades de privacidad de Dusk
→ Dusk Trade: infraestructura a nivel de aplicación para mercados tokenizados
Y aquí es donde la tesis de RWA se vuelve más interesante.
Tokenizar un activo es relativamente fácil de describir. Construir la infraestructura real para la emisión, la elegibilidad, las transferencias, la privacidad, la divulgación y la liquidación es el problema más difícil.
Con DuskEVM ya disponible para pruebas y Dusk Trade construyéndose alrededor de flujos de trabajo reales de mercado, lo siguiente que estaré observando no es otro anuncio.
Es lo que de verdad construyen los desarrolladores y las aplicaciones financieras sobre este stack.
@Dusk $DUSK #dusk
A primera vista, “otro entorno EVM” no suena especialmente interesante. Pero la arquitectura cuenta una historia diferente.
DuskEVM trae Solidity, Hardhat y las herramientas estándar de Ethereum a Dusk, mientras que la ejecución se resuelve a través de DuskDS. Esta separación es importante porque los desarrolladores pueden usar un entorno de aplicaciones familiar sin renunciar al sistema nativo de Dusk para la liquidación y la disponibilidad de datos.
Lo más interesante es lo que hay alrededor.
Dusk también está construyendo Dusk Trade como una capa de aplicación para activos financieros tokenizados, con flujos de trabajo en torno al alta de inversores, vinculación de billeteras, transferencias controladas, coordinación de pagos y una liquidación conforme.
Así que el desarrollo reciente no se trata solo de añadir compatibilidad con EVM.
Más bien, parece que Dusk se está encaminando hacia un stack completo en el que distintas piezas resuelven distintos problemas:
→ DuskDS: consenso, liquidación y disponibilidad de datos
→ DuskEVM: ejecución EVM familiar
→ DuskVM: ejecución nativa en Rust/WASM con acceso directo a las capacidades de privacidad de Dusk
→ Dusk Trade: infraestructura a nivel de aplicación para mercados tokenizados
Y aquí es donde la tesis de RWA se vuelve más interesante.
Tokenizar un activo es relativamente fácil de describir. Construir la infraestructura real para la emisión, la elegibilidad, las transferencias, la privacidad, la divulgación y la liquidación es el problema más difícil.
Con DuskEVM ya disponible para pruebas y Dusk Trade construyéndose alrededor de flujos de trabajo reales de mercado, lo siguiente que estaré observando no es otro anuncio.
Es lo que de verdad construyen los desarrolladores y las aplicaciones financieras sobre este stack.
@Dusk $DUSK #dusk
Cuanto más observo la tokenización, más pienso que estamos haciendo la pregunta equivocada.
Todos preguntan: “¿Se puede colocar este activo en la cadena?”
Pero imagina que el activo ya está ahí.
Ahora un inversor quiere comprarlo. Otro quiere venderlo. El emisor necesita hacer cumplir quién puede poseerlo. Un regulador puede necesitar pruebas más adelante. Y, en algún punto intermedio, la información sensible no debería convertirse en datos públicos.
Ahí está la parte interesante de @Dusk para mí. Su infraestructura de mercado se está diseñando en torno a todo el flujo de trabajo: elegibilidad, transferencias controladas, privacidad, divulgación y liquidación; en lugar de tratar un token como el producto final.
Quizá el verdadero avance en RWA no sea crear más tokens.
Quizá sea lograr que esos tokens realmente se comporten como activos financieros.
¿Qué parte de ese flujo de trabajo crees que es la más difícil de resolver?
$DUSK #dusk @Dusk
Todos preguntan: “¿Se puede colocar este activo en la cadena?”
Pero imagina que el activo ya está ahí.
Ahora un inversor quiere comprarlo. Otro quiere venderlo. El emisor necesita hacer cumplir quién puede poseerlo. Un regulador puede necesitar pruebas más adelante. Y, en algún punto intermedio, la información sensible no debería convertirse en datos públicos.
Ahí está la parte interesante de @Dusk para mí. Su infraestructura de mercado se está diseñando en torno a todo el flujo de trabajo: elegibilidad, transferencias controladas, privacidad, divulgación y liquidación; en lugar de tratar un token como el producto final.
Quizá el verdadero avance en RWA no sea crear más tokens.
Quizá sea lograr que esos tokens realmente se comporten como activos financieros.
¿Qué parte de ese flujo de trabajo crees que es la más difícil de resolver?
$DUSK #dusk @Dusk
Hace unos días pensaba en lo que realmente significa “tokenizar un activo”. Al principio suena simple: tomar una acción, un bono o un activo financiero y llevarlo a la cadena. Pero crear el token probablemente sea la parte más fácil.
Las preguntas difíciles empiezan después. ¿Quién puede realmente mantenerlo? ¿Qué pasa cuando alguien intenta transferirlo a la billetera equivocada? ¿Qué información necesita ser visible para el cumplimiento normativo y qué debería mantenerse en privado?
Ahí es donde $DUSK me resulta interesante. Los activos financieros reales necesitan más que solo transferencias rápidas: requieren que las reglas, la privacidad, la verificación y la liquidación funcionen juntas para que todo no termine convirtiéndose en una hoja de cálculo pública.
Quizá el verdadero reto de RWA no sea poner activos en la cadena. Tal vez sea construir un sistema en el que los mercados financieros puedan operar allí de verdad sin renunciar a la privacidad y los controles de los que ya dependen. ¿Qué piensas que es la pieza que falta más importante? 👀
@Dusk $DUSK #Dusk
Las preguntas difíciles empiezan después. ¿Quién puede realmente mantenerlo? ¿Qué pasa cuando alguien intenta transferirlo a la billetera equivocada? ¿Qué información necesita ser visible para el cumplimiento normativo y qué debería mantenerse en privado?
Ahí es donde $DUSK me resulta interesante. Los activos financieros reales necesitan más que solo transferencias rápidas: requieren que las reglas, la privacidad, la verificación y la liquidación funcionen juntas para que todo no termine convirtiéndose en una hoja de cálculo pública.
Quizá el verdadero reto de RWA no sea poner activos en la cadena. Tal vez sea construir un sistema en el que los mercados financieros puedan operar allí de verdad sin renunciar a la privacidad y los controles de los que ya dependen. ¿Qué piensas que es la pieza que falta más importante? 👀
@Dusk $DUSK #Dusk
#dusk $DUSK
La historia de seguridad de una blockchain no es “no encontramos ningún bug”.
Es lo que ocurre después de que una auditoría seria encuentra uno.
Por eso me fui por la madriguera de AEGIS con @Dusk .
La remediación AEGIS de Dusk para 2026 incluyó 39 correcciones de seguridad, incluyendo 7 hallazgos críticos.
¿Lo interesante? No eran solo problemas a nivel superficial.
La auditoría profundizó en la pila:
→ Ejecución en un sandbox de la VM
→ Deserialización del lado del host
→ Lógica de tarifas y reembolsos de Phoenix
→ Seguridad de firmas BLS
→ Componentes de consenso, de red y criptográficos
Un problema de tarifas de Phoenix podría afectar la integridad del suministro, la disponibilidad de la cadena y la seguridad de los reembolsos. El problema de BLS implicó la construcción criptográfica usada para la verificación de firmas.
AEGIS no se limitó a parchear una sola línea y seguir adelante. Dusk dice que reestructuró el modelo de propiedad afectado, reforzó los límites de confianza, añadió comprobaciones de consistencia de tarifas en múltiples capas, fortaleció la ruta BLS y agregó pruebas de regresión con forma de exploit.
Y según Dusk, no encontraron evidencia de que los hallazgos críticos hubieran sido explotados antes de AEGIS.
Para mí, ese es el verdadero aprendizaje.
En las finanzas reguladas, la privacidad es importante.
Pero la privacidad sin seguridad no sirve.
La infraestructura tiene que resistir el pensamiento adversarial antes de que las instituciones puedan confiar en ella.
Esa es la parte de @Dusk que me interesa seguir:
no solo lo que promete el protocolo,
sino cuán en serio responde cuando alguien intenta romperlo.
$DUSK #dusk @Dusk
La historia de seguridad de una blockchain no es “no encontramos ningún bug”.
Es lo que ocurre después de que una auditoría seria encuentra uno.
Por eso me fui por la madriguera de AEGIS con @Dusk .
La remediación AEGIS de Dusk para 2026 incluyó 39 correcciones de seguridad, incluyendo 7 hallazgos críticos.
¿Lo interesante? No eran solo problemas a nivel superficial.
La auditoría profundizó en la pila:
→ Ejecución en un sandbox de la VM
→ Deserialización del lado del host
→ Lógica de tarifas y reembolsos de Phoenix
→ Seguridad de firmas BLS
→ Componentes de consenso, de red y criptográficos
Un problema de tarifas de Phoenix podría afectar la integridad del suministro, la disponibilidad de la cadena y la seguridad de los reembolsos. El problema de BLS implicó la construcción criptográfica usada para la verificación de firmas.
AEGIS no se limitó a parchear una sola línea y seguir adelante. Dusk dice que reestructuró el modelo de propiedad afectado, reforzó los límites de confianza, añadió comprobaciones de consistencia de tarifas en múltiples capas, fortaleció la ruta BLS y agregó pruebas de regresión con forma de exploit.
Y según Dusk, no encontraron evidencia de que los hallazgos críticos hubieran sido explotados antes de AEGIS.
Para mí, ese es el verdadero aprendizaje.
En las finanzas reguladas, la privacidad es importante.
Pero la privacidad sin seguridad no sirve.
La infraestructura tiene que resistir el pensamiento adversarial antes de que las instituciones puedan confiar en ella.
Esa es la parte de @Dusk que me interesa seguir:
no solo lo que promete el protocolo,
sino cuán en serio responde cuando alguien intenta romperlo.
$DUSK #dusk @Dusk
Con verificación
#dusk $DUSK
La mayoría de las blockchains se diseñaron alrededor de una única idea:
Transparencia.
Pero los mercados financieros reales necesitan algo más matizado.
No puedes esperar que las instituciones publiquen cada saldo, posición y detalle de transacciones en un libro mayor público para que todo el mundo lo vea.
Ahí es donde @Dusk se pone interesante.
Dusk está construyendo infraestructura para finanzas onchain reguladas donde la privacidad, el cumplimiento y la liquidación determinista pueden funcionar juntas.
→ Moonlight para flujos públicos transparentes
→ Phoenix para transferencias protegidas y confidenciales
→ Divulgación selectiva cuando una parte autorizada necesita información específica
→ DuskVM para contratos inteligentes nativos en Rust/WASM + ZK
→ DuskEVM para una ruta de desarrollo compatible con EVM
Y la idea más grande va más allá de simplemente “tokenizar un activo”.
Para valores regulados, necesitas que la elegibilidad de los inversores, las transferencias controladas, la privacidad, la divulgación, el reporte y la liquidación funcionen en conjunto.
Esa es la parte que encuentro más interesante de Dusk.
La tokenización es fácil de describir.
Construir la infraestructura financiera alrededor de eso es lo difícil.
Dusk apuesta a que el futuro de las finanzas onchain necesita ambas cosas:
Privacidad cuando importa.
Transparencia cuando es útil.
Cumplimiento cuando es requerido.
Liquidación que pueda confiarse.
Esa es una tesis que vale la pena seguir. 👀
@Dusk $DUSK #dusk
La mayoría de las blockchains se diseñaron alrededor de una única idea:
Transparencia.
Pero los mercados financieros reales necesitan algo más matizado.
No puedes esperar que las instituciones publiquen cada saldo, posición y detalle de transacciones en un libro mayor público para que todo el mundo lo vea.
Ahí es donde @Dusk se pone interesante.
Dusk está construyendo infraestructura para finanzas onchain reguladas donde la privacidad, el cumplimiento y la liquidación determinista pueden funcionar juntas.
→ Moonlight para flujos públicos transparentes
→ Phoenix para transferencias protegidas y confidenciales
→ Divulgación selectiva cuando una parte autorizada necesita información específica
→ DuskVM para contratos inteligentes nativos en Rust/WASM + ZK
→ DuskEVM para una ruta de desarrollo compatible con EVM
Y la idea más grande va más allá de simplemente “tokenizar un activo”.
Para valores regulados, necesitas que la elegibilidad de los inversores, las transferencias controladas, la privacidad, la divulgación, el reporte y la liquidación funcionen en conjunto.
Esa es la parte que encuentro más interesante de Dusk.
La tokenización es fácil de describir.
Construir la infraestructura financiera alrededor de eso es lo difícil.
Dusk apuesta a que el futuro de las finanzas onchain necesita ambas cosas:
Privacidad cuando importa.
Transparencia cuando es útil.
Cumplimiento cuando es requerido.
Liquidación que pueda confiarse.
Esa es una tesis que vale la pena seguir. 👀
@Dusk $DUSK #dusk
⚡ ENCUESTA DE TRADERS DE FUTUROS ⚡
RSI por encima de 78 = zona de sobrecompra 📊
Estos principales ganadores están aumentando... ¿cuál es tu movimiento en futuros? 👇
Alto riesgo, alta recompensa — ¡no te liquides!
💬 Comenta tu entrada & apalancamiento#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
RSI por encima de 78 = zona de sobrecompra 📊
Estos principales ganadores están aumentando... ¿cuál es tu movimiento en futuros? 👇
Alto riesgo, alta recompensa — ¡no te liquides!
💬 Comenta tu entrada & apalancamiento#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
Short KERNEL
57%
Short SKL
13%
Short MOVR
27%
Short ZBT
3%
104 Votos • Votación cerrada
¿Qué tipo de criptomoneda estás apostando para el próximo mercado alcista? 👇
💬 Comenta tu elección + por qué
#BTC #solana #MEME #CryptoPoll #Dogecoin $NOM $ON $KAT
💬 Comenta tu elección + por qué
#BTC #solana #MEME #CryptoPoll #Dogecoin $NOM $ON $KAT
Store of Value — Bitcoin (BTC)
22%
Oracle Power— Chainlink (LINK)
14%
High-Speed Chains— Solana(SOL)
33%
Memecoins — Dogecoin (DOGE)
31%
36 Votos • Votación cerrada
Encuesta de Gemas Ocultas en Tendencia (Binance) 💎
Todos miran BTC & ETH…
Pero las verdaderas ganancias vienen de gemas ocultas 👀
¿Cuál altcoin en tendencia tiene el mayor potencial de 10x?$FET $RNDR $TIA
📊 Vota ahora & comenta tu gema oculta
La mejor información siempre está en los comentarios 👇
#crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
Todos miran BTC & ETH…
Pero las verdaderas ganancias vienen de gemas ocultas 👀
¿Cuál altcoin en tendencia tiene el mayor potencial de 10x?$FET $RNDR $TIA
📊 Vota ahora & comenta tu gema oculta
La mejor información siempre está en los comentarios 👇
#crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
FET (AI narrative)
63%
RNDR (GPU / AI infrastructure)
10%
TIA (Modular blockchain)
24%
SEI (High-speed DeFi chain)
3%
71 Votos • Votación cerrada
¿Qué memecoin estás acumulando ahora mismo?
💬 Comenta la memecoin en la que tienes confianza
Veamos cuál comunidad es la más fuerte 👀
#MemecoinArmy #CryptoPoll #BinanceSquare #PEPE #memecoin🚀🚀🚀
$PEPE $DOGE $FLOKI
💬 Comenta la memecoin en la que tienes confianza
Veamos cuál comunidad es la más fuerte 👀
#MemecoinArmy #CryptoPoll #BinanceSquare #PEPE #memecoin🚀🚀🚀
$PEPE $DOGE $FLOKI
DOGE
43%
SHIB
7%
PEPE
39%
OTHER (COMMENT IT)
11%
87 Votos • Votación cerrada
🚨 Sé honesto... la mayoría de las personas se equivocará en esto.
¿Qué activo realmente lidera el PRÓXIMO ciclo alcista? 📈
#CryptoPoll #Binance #BTC #Web3 #Ethereum
$KITE $DENT $SENT
¿Qué activo realmente lidera el PRÓXIMO ciclo alcista? 📈
#CryptoPoll #Binance #BTC #Web3 #Ethereum
$KITE $DENT $SENT
₿ Bitcoin – The king
23%
Ξ Ethereum – Smart contracts
19%
🟡BNB – Exchange+ real utility
13%
🚀 Altcoins
45%
31 Votos • Votación cerrada
Inicia sesión para explorar más contenidos