小饼的撸毛日记

朋友 corrió al verificador de Dusk y me preguntó si, por haber perdido la producción de bloques de forma consecutiva y haber sido sancionado, eso cuenta como mala fe. Al principio pensé que una sanción es una sanción; en el estilo de Cosmos, con firmas dobles te cierran el “cuartito” y no hay mucho que discutir.

Luego revisé el mecanismo de sanciones de Dusk y descubrí que hay dos tipos. Soft Slashing, sanción suave: se encarga de faltas no maliciosas, por ejemplo, que el nodo se desconecte cuando debía producir bloques, que no difunda dentro de la ventana correspondiente. No implica maldad, solo problemas de operación. La sanción consiste en que, por cada incumplimiento consecutivo, se descuenta N por un multiplicador de 10% de los intereses de la participación (staking). N es la cantidad de incumplimientos consecutivos. Además, se expulsa el nodo del consenso durante N epochs: un epoch es el periodo de consenso de Dusk, y al finalizar cada ronda, el conjunto de validadores rota una vez. El DUSK penalizado no se destruye; se transfiere desde el staking activo y el nodo puede recuperarlo.

Hard Slashing, sanción dura: se encarga de la conducta maliciosa. Generar bloques inválidos descuenta 10% del staking y destruye; hacer doble votación o doble producción de bloques descuenta 20% y destruye. La destrucción es real: desaparece, no es un bloqueo temporal para luego devolverlo.

No entendía por qué había dos categorías. Más tarde, al leer la parte de documentación sobre “rendición de cuentas”, lo entendí. Si el nodo solo se perdió un bloque por fluctuaciones de la red y tú lo vuelves a castigar fuerte, los validadores van a colocar el nodo en la nube más cara para evitar fallos, con lo cual el costo de operación sube y, paradójicamente, la descentralización empeora. La Soft Slashing sirve para sacar de manera gradual los nodos poco confiables del conjunto activo, dándoles oportunidad de recuperarse. Como cada penalización es pequeña, no arruina a quienes operan de forma honesta.

Lo que realmente cambió mi criterio fue el ajuste de N. Cuantos más incumplimientos consecutivos, mayor es el descuento y más largo el tiempo de expulsión. La primera vez que se cae: se descuenta 10% y se eliminan 1 epoch. La segunda vez: 20% y se eliminan 2 epochs. Eso genera presión de forma prácticamente exponencial: el nodo o vuelve a la estabilidad o se marcha automáticamente. La Hard Slashing queda para el daño claro: una sola destrucción, sin ventana de recuperación.

Tomemos Polkadot como ejemplo. En Polkadot el Slashing también es por niveles, pero los porcentajes de penalización son más finos: van de 0.1% a 100%, y el dinero de la multa se reparte con quien denuncia. El esquema de Dusk es más simple: o es negligencia o es malicia, el porcentaje es fijo y la destrucción no premia a los denunciantes. La ventaja es que los validadores pueden predecir el costo de cometer un error y no se atreven a no correr nodos por reglas complicadas.

Mi amigo, después de escucharlo, dijo que esta vez aceptó la Soft Slashing; se le cayó la red en casa durante media hora. También entiendo por qué Dusk separa tan claramente el mecanismo. Sin sanciones graduadas, los nodos honestos y los maliciosos se tratan igual#dusk $DUSK @Dusk

El día que miré la documentación de los nodos de Dusk, vi que la exigencia oficial mínima para los nodos Provisioner era de 2 núcleos de CPU, 4GB de memoria y 50GB de almacenamiento. ¿Parece que no es gran cosa, verdad? Cualquier servidor en la nube normal puede ejecutarlo.

Pero de paso consulté los nodos Archive: 4 núcleos de CPU, 8GB de memoria y 500GB de almacenamiento. El nodo Prover es todavía más exagerado: por cada Worker se necesita 1 núcleo y 1GB de memoria; como mínimo, 4 núcleos y 8GB.

Me quedé con la duda: ¿en la misma red, por qué el hardware de los nodos es tan diferente?

Al revisar el diseño de consenso de Dusk, descubrí que SBA divide a los participantes en dos tipos. Uno es el Block Generator, que mediante Proof-of-Blind-Bid selecciona por sorteo a los participantes y genera bloques de forma anónima. El otro es el Provisioner, que se encarga de validar las votaciones y de confirmar los bloques. Por cada bloque generado con éxito, 1 Generator y 192 Provisioner reciben recompensas. El comité de votación de Provisioner se vuelve a elegir en cada ronda mediante un sorteo determinista.

Provisioner debe verificar la legalidad de los bloques, comprobar las pruebas ZK y transmitir votos con firmas BLS; todo eso hay que hacerlo en cada ronda. El Generator es el que se selecciona para trabajar, mientras que el Provisioner debe estar listo en todo momento. Los nodos Archive no solo tienen que ejecutar el consenso, sino también almacenar todo el historial de la cadena. Los nodos Prover están dedicados a generar pruebas ZK, que son computación intensiva y se ejecutan en un solo hilo.

Yo antes pensaba que las redes PoS eran básicamente parecidas: si tenías suficiente DUSK en staking, podías ejecutar un nodo. Luego me di cuenta de que Dusk no funciona así. Los requisitos de hardware para cada tipo de nodo varían muchísimo. Generator con sorteo anónimo, votación del comité de Provisioner, Prover cargando el cómputo ZK y Archive guardando el historial completo: cada capa consume recursos de hardware distintos.

Pero lo que más me preocupa es esto: Dusk tiene ahora 206 Provisioner activos, y los primeros 20 controlaban más del 35% del staking. Después de segmentar por requisitos de hardware, los que pueden ejecutar Archive y Prover son, en realidad, un grupo minoritario; muy probablemente también sean quienes tienen más capital. No es un problema de distribución de tokens: el umbral de hardware en sí mismo es la primera criba. Los inversores minoristas comunes ni siquiera pueden tocar la puerta; solo pueden ir a los pools de Hyperstaking y entregar sus monedas a otros.

Ahora, cuando miro la descentralización de Dusk, primero reviso la documentación de nodos, luego la cantidad real de nodos en funcionamiento de los tres tipos, y por último la distribución del staking de los validadores. Los tres datos no coinciden: la descentralización es solo retórica. #dusk $DUSK @Dusk

第一次研究Dusk的时候，我对“隐私金融”有点怀疑。过去很多项目讲隐私就是藏，但面对机构和受监管市场，问题没那么简单。金融系统需要的不是看不见，而是需要验证的时候能证明某些事成立。

后来重新翻Dusk Citadel资料，才发现自己之前理解偏了。Citadel把身份验证拆成两步。第一步用户发一笔链上交易，附带一个只有自己能控制的隐身地址。许可证颁发方一直在扫链，看到发给自己的请求后验证通过，把许可证铸造到那个地址，用户再扫链接收。第二步用户拿着许可证申请服务，发一笔链上交易附带零知识证明，证明自己持有有效许可证，同时计算一个会话cookie——这是一个能用链上数据验证的值，只有用户和服务方知道它的含义。cookie通过加密信道发给服务方，服务方去链上核对会话ID，对上了才放行。全程链上完成，但除了用户和服务方没人知道谁在申请什么。

这个零知识证明电路的约束数大概是3.5万，生成证明十几秒，链上验证只要0.007秒。对用户来说多等十几秒申请一次，后面每次验证都是毫秒级。好在许可证可以提前作废，不用等过期，所以那个十几秒的生成时间对协议整体性能影响不大。

Citadel要保证五件事：证明你确实有证但不暴露额外信息、服务方能撤销但证没被撤之前一直有效、你的活动不能被追踪、证不能被重复用、只泄露必要信息。这五个属性加上已封装成SDK的Moat开发者工具，构成了Dusk身份层的核心——它和DuskDS、DuskVM平级，不是独立做隐私，而是决定谁有资格做Moonlight的公开交易和Phoenix的隐私交易。

看到这里我停下来想了一个事。真正成熟的隐私系统不是所有东西都看不见，而是让不同角色只看到自己该看到的。未来资产上链，竞争点不是谁藏得多#dusk $DUSK @Dusk

研究Dusk的时候，我第一眼盯的是DuskEVM。Antes miraba los proyectos y me acostumbré a mirar primero el entorno de ejecución: si los desarrolladores entran o no, eso decide si una cadena tiene futuro。

翻完资料我又回头看了一遍，这次真正让我停下来的，是DuskDS。

我以前一直觉得金融上链最大的坎是速度和成本。但把Dusk的设计拆开之后，我发现真正麻烦的是另一件事：一笔交易执行完，谁来确认它已经是最终状态？

Dusk把执行和结算拆成了两层。DuskEVM ejecuta la aplicación, construido sobre OP Stack; los desarrolladores de Solidity pueden desplegarlo directamente con las herramientas de siempre, como Hardhat y MetaMask. Sequencer gestiona las transacciones, y el batcher empaqueta los datos en un blob EIP-4844 y los sube a DuskDS. DuskDS no le importa qué aplicaciones se ejecuten arriba; solo se encarga del consenso, la disponibilidad de datos y la confirmación del estado final。

我盯着DuskDS那部分看了很久，才搞明白它到底在干什么。它跑的是 Succinct Attestation, un protocolo PoS basado en un comité. En cada ronda, un Provisioner propone el bloque, un comité valida y otro comité finaliza. Una vez que se finaliza, se obtiene una finalidad determinista; a diferencia de Bitcoin, que solo tiene finalidad probabilística, en condiciones normales no existe la posibilidad de reorganizaciones que los usuarios puedan percibir. Para ser Provisioner se requiere una apuesta mínima de 1000 DUSK; los nodos deben estar en línea 7×24 horas. Si el nodo está desconectado durante demasiado tiempo o actúa maliciosamente, se le impondrán penalizaciones。

研究到这里我才反应过来——以前觉得区块链最大的价值是让交易变快，但金融市场真正怕的不是慢，是不确定。一笔证券交易，资产转移完了但支付没同步，或者不同参与方看到的状态不一致，效率再高也没人敢用。

La liquidación determinista de Dusk, en esencia, está resolviendo este problema. La finalidad se reduce a dos o tres segundos, y además se integra con los flujos nativos de entrega a pago: esta combinación aporta un valor verdaderamente práctico en escenarios de liquidación financiera。

当然，这套设计最终还需要生态验证。基础设施做好只是第一步，真正的价值还要看资产和应用愿不愿意进来。

하지만, después de investigar Dusk, el mayor cambio es que ya no me fijo solo en cuántas transacciones puede procesar una cadena, sino en si puede dar tranquilidad a los participantes del sector financiero
#dusk $DUSK @Dusk

Después de que Dusk anunció el funcionamiento de la red principal, no lo reenvié de inmediato. En estos años he visto muchos proyectos: cuando se lanzan hay mucho movimiento, pero a los pocos meses la altura de los bloques casi no crece y los nodos no cambian. Así que esta vez no tuve prisa por escribir; estuve varios días seguidos mirando los datos on-chain.

Primero observé si la altura de los bloques variaba de forma continua, si el ritmo de producción era estable, y si la participación realmente avanzaba o se estaba quedando atrás. Antes, cuando evaluaba el valor de una cadena, estaba acostumbrado a mirar la promoción y el volumen de transacciones. Pero tras observar estos días, lo que de verdad no miente es si la red ha logrado mantener un estado de funcionamiento continuo. Ese juicio es frío, pero cuanto más lo miro, más lo entiendo y más lo comparto.

Lo que de verdad me detuvo fue la Succinct Attestation de Dusk. Se trata del nivel base de DuskDS, un protocolo de consenso PoS basado en comités: mediante un Provisioner seleccionado aleatoriamente que propone, valida y confirma bloques. Cada ronda de consenso consta de tres pasos: en la fase de Proposal, un Provisioner elegido crea y transmite el bloque candidato; en la fase de Validation, un comité revisa la validez del bloque y requiere que se apruebe por mayoría absoluta de dos tercios; en la fase de Ratification, otro comité confirma y, finalmente, “sella” el bloque. Una vez que se supera Ratification, el bloque entra en un estado final determinista y no puede retroceder (no se hace rollback).

Me fijé en este detalle dos veces, porque no habla de “seguridad de alta probabilidad”, sino de “una vez confirmada, es de verdad el final”.

Esto es crucial para escenarios financieros. Muchas cadenas siguen una lógica donde, si esperas un poco más, en la mayoría de los casos no hay rollback. Pero los valores, la compensación y liquidación, y los activos sujetos a cumplimiento no aceptan un “casi seguro”. Ellos necesitan un resultado claro: si se confirma ayer, no debería deshacerse hoy. Antes pensaba que la finalidad era un indicador técnico; ahora me doy cuenta de que es el umbral que determina si las instituciones se atreven o no a colocar activos reales en la cadena.

Convertirse en Provisioner tampoco es complicado: se requiere apostar al menos 1000 DUSK y ejecutar un nodo. El nodo debe estar en línea 24/7, con un mínimo de 2 núcleos de CPU, 4GB de memoria y 50GB de almacenamiento. Tras apostar, la participación madura en unas 12 horas; luego ya se puede participar en el consenso. El comité selecciona aleatoriamente por sorteo según el peso de la apuesta, y cada ronda es diferente.

Estos días, el mayor cambio no es que confíe más en Dusk, sino que tengo más claro qué debo mirar. Para una infraestructura orientada a la privacidad y las finanzas reguladas, el lanzamiento de la red principal es solo el punto de partida; lo verdaderamente importante es si la red puede generar de forma estable estados confiables#dusk $DUSK @Dusk

Cuando empecé a estudiar el mecanismo de consenso de Dusk, estuve mirando el libro blanco durante un buen rato y no llegaba a entender qué significaba la “finalidad determinista”. No tuve más remedio que hacer una tabla comparativa con tres cronogramas en el papel y leerla a fondo.

En Ethereum, Gasper utiliza finalidad probabilística: el bloque tiene que acumularse durante varios epochs para considerarse básicamente seguro. En Solana, Tower BFT también tarda decenas de segundos en confirmarse. ¿Y la Succinct Attestation de Dusk? Una vez que un bloque es aprobado, esa finalidad es “dura”, determinista y no da marcha atrás.

En ese momento miré esas tres líneas del papel durante mucho tiempo. La diferencia de unos pocos segundos quizá no se sienta en las transacciones criptográficas; basta esperar un poco más. Pero en un escenario de compensación bursátil, esos segundos son el candado final de seguridad de activos a nivel de cientos de miles de millones. Vendes una acción en un exchange y la liquidación es T+2. En esas dos jornadas, ¿de quién es el activo realmente? Si en el momento de la compensación la cadena aún pudiera revertirse, ¿quién se atrevería a poner activos reales? Para los usuarios minoristas quizá baste con decir “no es probable que se revierta”, pero para la compensación institucional no. “No es probable que” en el plano legal y de cumplimiento equivale a que no hay ninguna garantía.

Más tarde revisé la documentación oficial y por fin entendí cómo funciona exactamente la Succinct Attestation. Al terminar de leer ese fragmento, respiré aliviado: las dudas anteriores por fin encontraron respuesta. Se trata de un protocolo de consenso PoS sin permiso y basado en un comité. El sistema selecciona aleatoriamente un grupo de nodos llamado Provisioner para proponer bloques; otro grupo se encarga de verificarlos; y, finalmente, un tercer comité confirma el resultado de la verificación y aprueba formalmente el bloque. Una vez que el bloque completa el paso de ratification, ya hay finalidad determinista, y en condiciones normales no ocurre una reorganización orientada al usuario.

La red principal de Dusk se lanzó oficialmente el 7 de enero de 2026. Puede procesar más de 20000 transacciones por segundo. Tras seis años de desarrollo, por fin pasó de la red de pruebas a una fase capaz de operar con activos reales. Antes, mi comprensión del mecanismo de consenso era que quien produce el bloque obtiene la recompensa, y pensaba que no tenía mucho que ver con los usuarios comunes. Pero Dusk me hizo mirar el asunto desde otro ángulo: la elección del mecanismo de consenso, en esencia, responde una pregunta básica: cuando guardas tu dinero ahí, ¿de verdad puede contarse como válido? La Succinct Attestation responde que sí, y sin necesidad de aumentar la probabilidad. #dusk $DUSK @Dusk

La semana pasada, después de completar en la red de pruebas de TermMax un préstamo con garantía de ETH, abrí la cartera y miré el saldo. Había algo nuevo: un NFT. Ni siquiera recordaba haber reclamado esa cosa. En ese momento tenía la cabeza hecha un lío; mi primera reacción fue pensar si la cartera tenía un virus o si la red de pruebas me había enviado algún “basurero” por airdrop. Lo refresqué tres veces y seguía ahí. La verdad, empecé a asustarme: no vaya a ser que me hayan quitado el ETH que puse como garantía.

Luego fui a buscar en la documentación oficial. Estuve como media hora revisando, incluso leí foros y discusiones tempranas de la comunidad, hasta que entendí que era el GT que antes no había prestado mucha atención. ¿Sabes cuál es la lógica más central de esta cosa? Pides un préstamo y el protocolo directamente te “minta” un NFT. Dentro queda registrado cuánta garantía aportaste, cuánto FT pediste prestado y los parámetros MLTV correspondientes a ese plazo. Cada préstamo es un NFT independiente.

Antes ya había caído en una situación parecida en otros protocolos de tipo tasa fija: claramente ya había devuelto una parte, pero el sistema seguía mostrando la tasa de garantía original. Me dio el susto de que, en realidad, me habían vuelto a hacer pagar otra vez. Después de buscar con soporte al menos media tarde, descubrí que era un retraso de sincronización del estado en el frontend. Pero esa ansiedad de “¿realmente ya lo pagué o no?” no quiero volver a vivirla.

Más tarde lo analicé: lo realmente interesante del GT va más allá. Puedes entender el GT como tu posición apalancada empaquetada en un objeto que se puede negociar. Si no quieres esperar hasta el vencimiento, simplemente lo vendes. Si alguien toma el relevo, la deuda y la garantía dentro de la posición se transfieren juntas. Esto no tiene nada que ver con el préstamo tradicional. En el préstamo tradicional, tu posición es una cadena de estados dentro del contrato: transferirla a otra persona no se puede; solo puedes cerrar tu posición, retirar la garantía y que la otra parte vuelva a abrir su posición de nuevo. Es un lío. En cambio, el GT empaqueta toda la posición en un NFT: lo puedes transferir o vender directamente. Un NFT por posición, claro y sin interferencias entre sí.

Yo siempre pensé que el GT era solo un comprobante de derechos normal, pero recién ahora entiendo su valor real: entrega a los usuarios la propiedad completa y exacta de todo tu préstamo. Cuando se lance en la red principal, planeo abrir varias posiciones con diferentes plazos y revisar, una por una, el desempeño del GT en todo el proceso de liquidación al vencimiento. #termmax @TermMax

Cuando antes miraba las blockchains de privacidad, siempre creía que las pruebas de conocimiento cero ya eran suficientes para cubrir la mayoría de necesidades criptográficas: basta con codificar los parámetros de la transacción en la prueba y ejecutar la operación mediante la ZK Virtual Machine. Pero tras estudiar el modelo de transacciones Phoenix de Dusk, cambié de opinión. Lo verdaderamente difícil no es generar una transacción anónima, sino mantener de forma continua—en entornos complejos—esas reglas de permisos de privacidad que no dejan de cambiar.

Creo que el modelo de transacciones Phoenix se parece más a un sistema de control de acceso por niveles de una oficina. Los contratos de privacidad “normales” son como una llave fija: mientras generes una prueba válida, puedes desbloquear. En cambio, el sistema Phoenix es como un administrador de permisos dinámico: no solo revisa si tienes una prueba válida, sino que también evalúa si el escenario de la transacción, los permisos de divulgación, los requisitos de auditoría y el nivel de cumplimiento encajan con lo exigido. Para las aplicaciones de privacidad on-chain, este tipo de evaluación dinámica de permisos es más importante que simplemente generar una prueba anónima.

Dusk opta por separar la capa de privacidad de la capa transparente de EVM; en esencia, está resolviendo un problema de largo plazo. En el pasado, muchas cadenas de privacidad escribían todas las reglas de privacidad directamente en el contrato base: el costo de modificar era alto y el riesgo de actualización también. A medida que los casos de uso se vuelven más complejos y las necesidades de privacidad de los usuarios se vuelven más diversas, un único modo anónimo difícilmente puede soportar cambios frecuentes en los requisitos del negocio. Después de separar las cuentas en dos modos, los desarrolladores pueden ajustar con mayor flexibilidad el nivel de privacidad, y la privacidad de la transacción deja de ser un permiso permanente de anonimato total.

Sin embargo, este diseño también introduce nuevos desafíos de ingeniería. Al aumentar el número de transacciones entre capas, sube el costo de sincronización del estado; la compatibilidad entre versiones se vuelve más complicada, y los desarrolladores necesitan invertir más tiempo para comprender la lógica de interacción de los dos modos. Además, la velocidad de generación de las pruebas ZK, la experiencia de integración del Rusk SDK y si los usuarios institucionales están dispuestos a migrar, afectarán el resultado real de su despliegue.

En mi opinión, lo que Dusk realmente necesita demostrar no es solo si la idea de privacidad con ZK es válida, sino si este sistema de privacidad con doble modo puede ser usado de forma sostenida por una gran cantidad de desarrolladores. En el futuro seguiré observando y probando en la red de pruebas los datos de transacciones entre capas, el nivel de incorporación de desarrolladores y la frecuencia con la que, en aplicaciones reales, se actualizan los permisos de privacidad. Hay una cuestión que vale la pena pensar: si en el futuro hay cada vez más escenarios de privacidad on-chain, ¿lo que necesitaremos será una capacidad criptográfica más potente o una mejor forma de gestionar los permisos de privacidad?
#dusk $DUSK @Dusk

@TermMaxFi Antes, en Aave, gané durante 30 días con un tipo de interés fijo; me topé con un parámetro hardcoded que no se podía modificar y perdí unos cientos de ganancias. Por eso soy especialmente sensible a las suposiciones subyacentes de los productos de interés fijo. Al leer el libro blanco de TermMax, vi una frase que el equipo usa constantemente como narrativa central; cuanto más la miro, más parece una “talón de Aquiles” escondido: “El AMM con vencimiento por tramos es la ruta más óptima para implementar tasas de interés fijas en la cadena”. El punto de partida del razonamiento es bastante directo: las tasas variables no permiten una fijación de precios a largo plazo, así que se bloquea el rendimiento hasta el vencimiento usando pools de fondos por tramos.

Pero hay un silencio mortal: el equipo de TermMax nunca ha discutido qué pasa si, según mi análisis personal, en el futuro los principales protocolos de préstamos admiten de forma nativa el fraccionamiento de tasas fijas. Con esta fragmentación nativa, el pool de tasas variables puede separar automáticamente sub-pools independientes de tasas fijas, sin necesidad de desplegar además un pool de fondos independiente hasta el vencimiento. Esto es el “santo grial” de la fijación de precios a largo plazo para quienes hacen préstamos en DeFi. En cuanto un protocolo de préstamos dominante complete la actualización, las soluciones que hoy no pueden evitar un protocolo independiente de interés fijo reviven al instante, “a plena salud”. Un producto que pueda abrir posiciones de interés fijo directamente dentro del pool de préstamos existente, sin migrar liquidez entre protocolos; y otro que requiere hacer market making por separado, donde cada operación debe emparejarse con una contraparte independiente que aporta fondos hasta el vencimiento. ¿Cuál elegirías?

Es como cuando los teléfonos de teclas llevaban la interacción con botones al límite: en cuanto llegó la pantalla táctil, fue una ofensiva desde una dimensión superior. El AMM con vencimiento por tramos es ahora el teléfono de teclas: la forma más elegante de llegar a una compensación cuando la capacidad nativa de la cadena para tasas de interés está limitada. Si cae esa “paja” de la fragmentación nativa de tasas fijas, la narrativa actual podría invertirse en una noche.
$TMX ¿y qué? TermMax dice que su captura de valor depende del uso continuo de transacciones de interés fijo: hacer market making implica mantener posiciones mediante el colateral de TMX, la distribución de comisiones depende del staking de TMX y los ingresos del protocolo se destruyen continuamente en TMX. Pero si la fragmentación nativa genera realmente la capacidad nativa de tasas de interés fijas, ¿quién querría evitar el desvío hacia un pool independiente de fondos con vencimiento por tramos? El modelo económico de TMX está construido sobre el supuesto de que los protocolos de préstamos generales no pueden hacer tasas de interés fijas; si ese supuesto se derrumba, la narrativa deflacionaria.

Mi postura: el AMM con vencimiento por tramos es una solución óptima parcial bajo las limitaciones actuales; no lo tomes como una verdad eterna. Los protocolos subyacentes de préstamos están evolucionando: hoy el obstáculo es fijar tasas fijas a largo plazo; mañana, con una sola iteración de versión, se supera. ¿Puede TermMax pasar de “producto de tasas fijas” a “capa de infraestructura nativa de tasas de interés” #termmax @TermMax

我最近在对着Dusk的多账户并行测试几组交易流，原本以为隐私链主要处理加密和匿名。后来把透明EVM账户和隐私ZK账户的交易放在一起跑，才发现真正麻烦的不是怎么加密，而是两条都“合法”的交易同时上链时，系统该怎么在不泄露明文的前提下完成校验。我以前觉得隐私网络只要证明通过就行，现在越来越觉得，并行交易的冲突处理才是长期落地的核心难题。

这有点像商圈里的两条并行车道。每条车道单独看通行规则都没问题，但如果相邻车道的车辆变道规则不协调，整条路就会堵死甚至撞车。隐私交易网络也是一样，单条ZK交易的证明合法，并不代表多笔交易并行提交后，链上状态依然能保持一致。

Dusk把Phoenix隐私UTXO模型、Moonlight透明EVM层、Citadel计费证明模块和VEP定向披露机制组合起来，本质是在允许用户自主选择交易隐私等级。这样做的好处很明显，普通用户可以用隐私账户保护资产轨迹，机构用户可以用透明账户完成合规结算，不用被单一隐私模式限制。问题也随之出现：当一笔隐私交易要调用透明合约地址，另一笔透明交易要读取隐私账户的余额，节点如何在不泄露明文的前提下完成状态同步？过去很多隐私链没有这个问题，因为要么全匿名要么全透明，根本不存在双模式并行。

我现在看到的Trade-off很明确。隐私灵活性提高后，状态校验复杂度会上升；双模式账户越多，ZK证明生成成本越高；跨层交易频繁后，Gas计量和审计追溯的边界也会变得模糊。跨层交易延迟、证明验证失败率、定向披露的校验耗时，这些指标可能比TPS更能反映隐私公链的落地成熟度。
未来我会持续观察测试网上的跨层交易数据、官方更新的冲突修复记录，以及节点对双模式并行交易的处理方式。#dusk $DUSK @Dusk

刚跑完TermMax 7天池的测试交互，大部分人聊链上固定利率，只关心收益率高不高，很少有人敢提：订单撮合错了、资金兑付出问题，谁来兜底，出错的人付什么代价。这个问题传统固定收益市场里见得多，链上反而很少有协议正面回答。查 @TermMaxFi 主网测试网到这一层，我才觉得这才是真见功夫的地方，也顺手把之前一处说得不够精确的地方补了。

同一笔固定利率订单要靠链上Fixed-Term TimeLock Module和独立预言机双重校验，匹配完成才上链存证，官方原文写的是这套全链路校验机制要等完全走出公测阶段才算满配，现在这个阶段还在逐步覆盖全期限池，不是从主网上线第一天就全量开放。做市商的保证金押在协议的隔离保证金池里，我测试过，争议窗口期是24小时，订单成交后恶意撤单、或者故意报虚假利率扰乱市场被链上仲裁节点挑战成功，这笔保证金会被直接罚没，这叫违约罚没，作恶代价是真金白银拿不回来。

我上次把$TMX 和这套安全体系写得太笼统，容易让人以为做市商押的就是TMX，其实不是同一件事。翻官方代币披露材料（看的是第17页代币分配章节），TMX现阶段的作用是四块：给流动性提供者的挖矿奖励、创建和挂单时的协议手续费、做市商提供服务时自己抵押的TMX保证金、以及质押后拿到的利率参数治理投票权。真正让TMX变成整个网络原生的手续费和质押本位，官方写的是要等V2版本的跨链期限池正式跑起来才算完全落地，现在还没到那一步。

两条时间线放一起看，这个项目的完整固定利率闭环还在分阶段拼装，$TMX 目前更偏治理和早期激励，真正扛住全网资金兑付安全的重担现在压在隔离时间锁合约这头。#termmax @TermMax

Pasé casi toda la tarde enganchado a los logs del nodo de la red de pruebas de Dusk. Los cubitos de hielo del iced americano sobre el escritorio se terminaron de derretir por completo; el agua que se condensaba en las paredes del vaso se filtró formando un anillo húmedo en la alfombrilla del mouse. Dejé el mouse encima del cargador inalámbrico y me quedé sentado inmóvil durante cinco minutos, hasta que de pronto caí en cuenta de una pregunta que me venía atorando desde hace tiempo: hay bastantes proyectos de cadenas públicas de privacidad; ¿por qué Dusk eligió al final una máquina virtual nativa de Rusk, en lugar de ponerle encima un plugin de privacidad ZK a EVM? Al principio pensé que era simplemente una decisión de ruta tecnológica. Pero luego me puse a revisar una y otra vez los materiales oficiales sobre el modelo de transacciones Phoenix y la privacidad de extremo a extremo, y entonces entendí que lo estaba simplificando demasiado.

En realidad, lo más urgente en una aplicación de privacidad no es el propio mecanismo de las pruebas de conocimiento cero, sino el riesgo de filtración de estado a lo largo de toda la cadena. Si solo añades una “capa” de privacidad en el nivel de transacciones de EVM, el contrato almacena, el stack de ejecución y los eventos dejan rastros en texto plano por todas partes. Si se filtra cualquiera de esas piezas, toda la protección previa de privacidad queda en blanco. Dusk empieza desde la máquina virtual Rusk a nivel de base, con un diseño nativo de privacidad; al mismo tiempo usa pruebas recursivas de PLONK para anclar el estado. Verificar una transacción de privacidad en un nodo tarda solo 1.2 segundos, casi 4 veces más rápido que el esquema de usar un plugin ZK sobre EVM. En pocas palabras: están haciendo una elección lúcida entre profundidad de privacidad, eficiencia de desarrollo y seguridad, no persiguen a ciegas “lanzarse más rápido a la compatibilidad con el ecosistema EVM” y ya.

Lo que de verdad me hizo cambiar de opinión fue otro detalle. Una y otra vez, el material oficial recalca que los nodos se encargan de la validación de transacciones, no de custodiar datos en texto plano en nombre de los usuarios. La ejecución de transacciones puede apoyarse en el espacio de estados cifrado, pero el control de los activos y las claves de vistas direccionadas siguen siempre en manos del propio usuario. Eso es lo que me hizo entender que Dusk no solo ajusta la forma de implementar la función de privacidad, sino la relación de confianza más central de la cadena pública: reducir al mínimo la parte que requiere confiar en el nodo, y ampliar al máximo la parte que se puede verificar mediante criptografía.

Al final, la privacidad de extremo a extremo es solo la presentación de una característica del producto. El modelo de confianza de “nodos sin conciencia + el usuario controla por sí mismo” es lo que @dusk_foundation realmente vale la pena estudiar, y también lo más difícil de copiar. #dusk $DUSK @Dusk

最近在重新啃 @TermMaxFi 的固定利率AMM机制，卡了我好几天的是一个挺笨的问题：DeFi借贷要走进更主流的金融场景，缺的到底是更多借贷品种，还是一种不需要用户承担利率波动风险的定价方式。把白皮书第四节和官网的真实交易数据对着看了几遍，我倾向于认为TermMax要解决的不是表面的利率高低问题，核心是怎么让链上借贷的资金成本变得可预测。#TermMax

以前DeFi玩借贷，走的路子基本都是浮动利率模型，借的时候只能看当前APY，根本不知道三天后利率会不会被大单拉到离谱。Compound也好，Aave也好，Morpho也好，资金效率确实提上去了，代价是每一个参与者都得承担利率波动的不确定性。借贷工具变多了，可原本最重要的资金成本稳定性，也成了随时会变的变量。TermMax让我觉得不太一样的地方，在于它压根没在浮动利率模型上修修补补。按官方的说法，每一个到期日的资金池对应的是一套独立的固定利率曲线，靠分档到期的AMM做市、流动性分层定价这类机制，提前把不同期限的借贷成本限定死。利率的定价逻辑从头到没变，变的是用户对未来资金成本的可预期程度。

我觉得真正该抠的其实是定价这一层。用户不用去猜下一个区块会不会有大额借贷把利率拉飞，也不用去赌协议会不会突然调整参数改利率模型。TermMax靠分档到期的自动做市，再叠一层清算罚金积累的协议储备金，把不同期限的利率，翻译成用户能直接锁定的固定成本。$TMX 流动性深度、利率偏差率、风险准备金这几个参数说实话还得靠时间去验证，没法现在就下结论。但TermMax至少给我提了个醒：DeFi借贷以后要对接主流资金，未必非得照搬浮动利率那套打法，也可以试着在守住链上去中心化安全模型的前提下，让用户先拿到确定的资金成本。#termmax @TermMax

之前选DeFi协议，我的标准简单粗暴：TVL越大越安全。

这个逻辑支撑了我好几年。Aave、Morpho这些头部协议的TVL动辄几十上百亿，钱都在里面，能有什么事？所以TermMax TVL“只有”9000万的时候，我确实没正眼瞧过。

改变我想法的，是一次闲聊。

朋友问我：“你那笔USDC准备放多久？”我说等机会，不确定。“那你这段时间的资金成本是多少？”我愣了一下——在Aave存着吃浮动利息，今天4%明天可能3%，我根本没法回答“成本是多少”这个问题。我把手机放桌上，没接话，那顿饭后半程有点心不在焉。

回去认真研究了一下TermMax，才发现它解决的问题跟Aave完全是两回事。

TermMax的核心逻辑是固定利率代币化。债务代币拆成FT和XT，FT是零息债券，到期前以折扣价出售；XT是收益权代币，随到期逼近价值归零。任何时候1 FT + 1 XT = 1债务代币——这个恒等式确保了固定利率市场的定价透明。GT是ERC-721标准的杠杆代币，代表一个独立的贷款头寸。借款方把抵押资产锁进GT，根据市场设定的最大贷款价值比（MLTV）铸造对应数量的FT。如果抵押品价值下跌导致贷款价值比（LTV）超过MLTV，头寸会被清算。

FT和XT的关系，第一遍翻过去没觉得有什么，第二遍才看到那句话——理顺之后整个逻辑就通了。

这套机制解决了一个Aave始终解决不了的问题——资金成本的确定性。

Aave更像链上银行，关注资金流动效率。TermMax让借贷双方在交易开始时就能约定一个固定利率和固定期限。我开始算账：如果大半年前就把那笔闲置资金通过TermMax锁定固定利率，我不仅能提前知道到期能拿多少，限价单等待期间资金也不会闲着——它会自动进入Morpho金库赚浮动收益，匹配成功后再无缝切换成固定利率。

TVL是规模指标，固定利率是确定性指标。#termmax @TermMax

Anuncio de lanzamiento del bloque de cumplimiento del testnet/mainnet de Citadel de Dusk; esta vez quería encontrar detalles sobre la auditoría de seguridad de circuitos de pruebas de conocimiento cero, pero al ver que la propia oficina nombra a los primeros socios de implementación, me quedé atónito—no es una empresa de seguridad que haga auditorías criptográficas, sino el exchange digital regulado NPEX de los Países Bajos y la firma de consultoría de cumplimiento DAC8, especializada en MiCA de la UE
Mi primera reacción fue que era raro: Dusk construye una cadena pública de privacidad de extremo a extremo, ¿cómo aparece ese bloque de cumplimiento con un equipo de dos instituciones financieras reguladas, en lugar de un equipo de seguridad dedicado a ataques y defensas criptográficas?
Revisé varios blogs técnicos oficiales hasta que entendí el propósito de este arreglo. El bloque de cumplimiento zkUT de Dusk, en esencia, es un ejecutor de transacciones de privacidad. Por muy riguroso que sea el circuito ZK, si la transacción puede o no aterrizar legalmente depende de si la prueba que produce puede cumplir los requisitos de cumplimiento regulatorios. Por ejemplo, una transacción de acciones tokenizadas: por perfecta que sea la anonimización, si no cumple con el requisito de trazabilidad/“auditoría dirigida” de MiCA, simplemente no se obtiene la licencia de emisión; sin licencias, los fondos institucionales ni se atreven a entrar. Del mismo modo, una transferencia institucional que cumpla la lista blanca: aunque la anonimidad sea excelente, sin el respaldo de una institución regulada (identidad acreditada en la lista blanca), no se puede circular dentro del ecosistema de brókers/comisionistas regulados.
Cuando el mainnet fijó a estas dos empresas como socios de lanzamiento, equivale a que la propia autoridad oficial reconoce una cosa: si el bloque de cumplimiento es confiable el primer día de su despliegue, la mitad del mérito recae en el propio circuito ZK y la lógica de “staking” anónimo de Dusk, y la otra mitad se apoya directamente en estos dos socios de cumplimiento. Este descubrimiento me hizo replantearme la privacidad de extremo a extremo que presume.
Las pruebas recursivas de PLONK más el modelo de transacciones privadas de Phoenix garantizan que el proceso de ejecución de la transacción no sea manipulado “con mala intención”, y que la parte de cálculo y privacidad sea confiable. Pero si la transacción puede ser reconocida por el regulador, y si puede integrarse en el sistema financiero tradicional, es otro umbral de implementación totalmente independiente. El código técnico de Dusk no puede controlarlo: solo puede apoyarse en socios de cumplimiento regulados para que cada registro de autorización de una transacción conforme se firme como una prueba verificable dirigida con marca de tiempo y se publique en la cadena, a fin de que los reguladores lo verifiquen posteriormente.
Yo pensaba que la confiabilidad de este sistema de privacidad era un todo; ahora veo que son dos capas de confianza superpuestas. La privacidad confiable a nivel técnico no equivale a la confiabilidad de la admisión regulatoria; hay que mirarlo por separado. Después de tener clara esta capa, mi valoración sobre el lanzamiento del bloque de cumplimiento es
#dusk $DUSK @Dusk

对着测试网日志卡了快一下午。桌上冰美式的冰块全化透了，杯壁凝的水在鼠标垫上洇出一圈湿印。我把鼠标往无线充电座上一放，坐那愣了五分钟，才突然反应过来一个反常的点：en la cadena PoS, los validadores tienen sus registros de staking publicados en la cadena. El atacante solo necesita seguir la dirección de staking para encontrar la IP del nodo. En una cadena de privacidad, incluso los montos de las transacciones van cifrados; ¿cómo no habría de estar la identidad del validador al descubierto?

Antes yo asumía que la lógica de staking en la cadena de privacidad era parecida a la de un PoS normal, hasta que encontré el módulo anónimo de staking de Citadel de Dusk y descubrí que incluso la capa de identidad al momento de producir bloques también lo hace con privacidad de extremo a extremo.

Al principio pensé que solo era “encapsular” la dirección de staking con algún servicio de mezcla. Pero al mirar con detalle el circuito ZK del contrato de staking, me di cuenta de que no se trata de esconder la dirección de forma tan simple. Lo que busca es: sin exponer tu dirección de staking ni el monto exacto, puedes demostrar a toda la red que cumples el umbral mínimo y tienes derecho a participar en el consenso.

El mecanismo Citadel basado en pruebas recursivas PLONK tiene como núcleo resolver el gran “talón de Aquiles” que todas las cadenas PoS enfrentan: cuando un usuario hace staking de DUSK, bloquea los tokens en un pool de staking anónimo unificado. El monto del staking, el período de bloqueo y las asociaciones de direcciones se tratan con ofuscación; los demás nodos solo necesitan 8 segundos para completar la verificación. Así, no se puede ver la asociación entre la dirección de staking, y tampoco se puede vincular una firma de producción de bloque con una dirección específica.

Pero tengo que decirlo con honestidad: este diseño exige una precisión altísima en los circuitos ZK. Si alguna restricción queda escrita por fuera, puede existir el riesgo de pruebas falsificadas. Además, el reto de implementar correctamente el castigo y el slashing de nodos maliciosos con precisión es mucho mayor que en un sistema de staking público. Esta parte aún sigue en pruebas. Si el camino podrá o no correr perfectamente, habrá que comprobarlo con el tiempo, pero al menos deja claro que Dusk se toma la privacidad muy en serio, desde la base misma del consenso. ¿Crees que la identidad de los validadores en una cadena PoS de privacidad debería o no hacerse pública? ¡Hablemos en la sección de comentarios!
#dusk $DUSK @Dusk

Anoche me quedé trabajando y aproveché para “hacer tiempo” leyendo hasta que se lanzó el nuevo sitio de Dusk. Entré con la mentalidad de “un rediseño del proyecto, cambio de piel”, pero el sitio anterior para encontrar documentación técnica te obligaba a saltar entre tres o cuatro enlaces y a veces ni cargaba (404). Al final, frente al nuevo sitio, vi el diagrama de capas apiladas de la tecnología y estuve 20 minutos entendiéndolo: me conectó toda la comprensión fragmentada que tenía de mis proyectos anteriores.

El nuevo sitio no amontona tanto discurso de marketing; simplemente despliega el stack técnico de la capa más baja a la más alta. En la parte más inferior está DuskDS: se encarga del consenso, la liquidación y la disponibilidad de datos. La capa de consenso usa SBA, un mecanismo PoS basado en comités: selecciona al generador de bloques de forma anónima con Proof-of-Blind-Bid. La lista de validadores cambia en cada ronda; así está diseñado para evitar que los validadores queden fijados de antemano o sean atacados, y para impedir el acaparamiento de poder de producción de bloques típico de los “grandes” en PoS tradicional.

La capa de transacciones usa Phoenix: se basa en el modelo de notas UTXO, donde el dinero existe en forma de “notes” cifradas; junto con las compromisos de Pedersen para ocultar el importe y con los anuladores (nullifiers) para bloquear el doble gasto. Los nodos solo se ocupan de verificar si las pruebas de conocimiento cero son válidas. Cuando probé antes e intenté meter texto en claro directamente en las transacciones, me lo rechazaron: ahí supe que estas reglas están “soldadas” desde la capa de consenso.

Luego, mirando hacia arriba, la capa Dusk Trade. Yo pensaba que era un DEX de privacidad “con envoltorio” típico, pero en la demo del sitio descubrí que en realidad llama directamente al canal de liquidación de la capa inferior. El order book está cifrado por defecto y usa cifrado homomórfico por ElGamal: los precios y cantidades de las órdenes en la cadena son texto cifrado. El motor de matching calcula con los cifrados y, cuando ya se determina el precio y la cantidad de la operación, recién entonces se descifran para completar la transacción. En todo el proceso, los detalles de las órdenes no se exponen.

Aún arriba hay otra capa: DuskEVM, una capa de ejecución modificada a partir de OP Stack. Hace la liquidación directamente sobre DuskDS; si conectas Solidity, hereda las capacidades de privacidad de la capa base, sin necesidad de inventar otra arquitectura.

La capa superior es el flujo de trabajo del mercado de cumplimiento normativo: convierte a Citadel en un módulo nativo invocable. Los usuarios no tienen que enviar fotos de pasaporte; mediante pruebas de conocimiento cero pueden demostrarle al sistema que “ya completaron la verificación de cumplimiento”.

Antes siempre sentía que la ruta técnica de Dusk estaba hecha de piezas sueltas. Pero con el nuevo sitio (que desvela el stack completo) me di cuenta de que desde el principio no se trata de hacer un juguete de transferencias anónimas: están montando un conjunto completo de infraestructura financiera con privacidad y cumplimiento. Al terminar de leer, añadí un poco de DUSK; porque proyectos que exponen de forma clara y abierta su arquitectura técnica para que cualquiera la vea, sinceramente, ahora mismo no hay muchos. #dusk $DUSK @Dusk

说真的最开始我也以为Dusk就是炒匿名叙事的老套路，直到上周跟着Discord社区蹲主网RC2测试，凌晨三点冰美式都喝温了，Gas设低了卡了20分钟还找管理员吐槽，测着测着才发现这玩意儿跟之前玩过的隐私链根本不是一个东西。

大部分隐私链的加密是写在智能合约层的，相当于你家门锁装在客厅，真有贼撬了窗户翻进来，家里东西全看得见——去年我测某条热门隐私链，就是因为合约权限漏洞，测试网所有转账明文直接漏在区块浏览器里，我当时留的测试地址被垃圾空投骚扰了俩月。Dusk直接把Pedersen承诺加密焊死在SBA共识层，资产从进mempool开始就是加密状态，节点哪怕拿到全量区块数据，也只能读到“交易合法”的零知识证明，半毛钱明文金额、地址都摸不到。我故意往节点接口塞明文交易数据，直接被共识层丢了回来，连验证环节都进不去。

之前我最烦隐私链的KYC问题，去年用某合规隐私链，把护照照片传第三方插件，转头就收到了海外理财垃圾短信。Dusk的ZkKYC直接嵌在Rusk虚拟机里，你的KYC凭证存在自己本地，交易时只生成个证明“我符合监管要求”，连项目方都拿不到你的身份信息，给监管开审计视图也只能看指定交易。现在他们刚合并FRI+PLONK混合证明的PR，单笔验证压到1.4毫秒，跑机密合约Gas比EVM套ZK层低67%，我部署测试债券合约连20行代码都不到，Gas才花了0.28 $DUSK 。

之前在老隐私链套牢亏了小两千U，我一直觉得隐私和合规就是天生的死对头：要么做全匿名的灰产温床，要么做扒光用户隐私的“合规链”。跑完Dusk测试我才明白，隐私本就不该是灰产遮羞布，用户的资产和身份数据从来都该自己握着，合规也不该以牺牲隐私为代价，Dusk是真从底层把这个拧巴了快十年的死结剪开了@Dusk
#dusk $DUSK

En el mundo cripto ya no hay liquidez, igual que en la bolsa de China#闪迪股价涨幅扩大至11%

El fin de semana, en la cafetería de abajo me colé para aprovechar el aire acondicionado y me quedé allí probando la red de pruebas de Dusk. Intenté tres veces seguidas con contraseñas mal antes de terminar la transacción 21 después de pelearme con todo durante media hora. Me quedé mirando durante mucho tiempo los registros de ejecución de la máquina virtual Rusk—antes había jugado con varias cadenas antiguas de privacidad: o se quedaban colgadas durante media hora sin producir bloques, o hacían el anonimato “completo” de forma que, por motivos de cumplimiento, simplemente no era posible abrir permisos de auditoría. En un principio no tenía ya ninguna expectativa sobre eso de las “blockchains de privacidad”, pero al meter la mano y caer en la trampa entendí que esto no es simplemente una carcasa para vender una idea.

Al principio pensé que, como SBA consenso, era un PoS con piel nueva. Después de revisar las reglas de nodos y simular diez mil veces el doble gasto, me quedó claro: SBA (Segregated Byzantine Agreement, Acuerdo Bizantino Aislado) divide los nodos en dos capas. Una capa es el comité que produce bloques y se encarga de empaquetar transacciones; la otra es un conjunto de validadores que realizan verificaciones aleatorias para auditar al azar. La semilla de los sorteos se genera con VDF (función de retardo verificable), y nadie puede predecir a quién van a revisar después. El explorador de la red de pruebas mostró que 3 nodos fueron sancionados con confiscación de la fianza por enviar bloques inválidos: dos recibieron una sanción “suave”—se les escaparon algunos bloques y temporalmente quedaron fuera de la cola de consenso; la cantidad de garantía efectiva se recortó. El otro recibió una sanción “dura”: lo pillaron con doble firma, y el token de la participación se le descontó directamente en un 20% y se destruyó. Este tipo de mecanismos de penalización eleva mucho el costo de hacer mal, y el precio de probar es enorme.

Al probar transacciones, me resbaló el dedo y añadí un 0 de más: el monto se salió del rango permitido por el Range Proof. La transacción fue rechazada al instante y ni siquiera quedó rastro de una transacción inútil en la cadena. El Range Proof del protocolo Phoenix bloquea estrictamente el rango del monto de las transacciones; junto con los compromisos de Pedersen que fijan el total de activos de cada operación, no puede aparecer emisión “por la nada”. Además, con una Stealth Address de un solo uso que cambia automáticamente la dirección en cada transacción, envié 5 veces monedas de prueba seguidas: en la cadena, no hay forma de asociar estas operaciones a una misma cuenta. Las pruebas PLONK agregadas recursivamente se comprimen a 287 bytes; la verificación por transacción tarda solo 1.8 milisegundos. Corrió muy fluido, y ni siquiera en el pico de la red de pruebas se notó congestión.

La máquina virtual Rusk está escrita íntegramente en Rust desde cero. Soporta nativamente el estándar de activos confidenciales. Desplegué mi Token de pruebas y ni siquiera tuve que escribir más de 200 líneas de código de privacidad; el Gas de los contratos al ejecutarse es 63% más bajo que cuando metes una capa ZK sobre EVM. Además, deja un acceso para auditoría reservado para los equipos de cumplimiento—privacidad y cumplimiento no tienen que ser una elección excluyente; se pueden cubrir a la vez. La noche en que terminó la red de pruebas, me sentí mucho más tranquilo que con cualquier proyecto en el que antes hubiera invertido.
#dusk $DUSK @Dusk