Binance Square
小饼的撸毛日记
1.3k Publicaciones

小饼的撸毛日记

19年入圈。穿越两轮牛熊。全职Crypto,Trader,BTC/BNB 长期持有者。Alpha撸毛策略探索者,深度分享:alpha交流 LH688E
Abrir operación
Titular de BNB
Titular de BNB
Trader de alta frecuencia
5.8 años
86 Siguiendo
2.5K+ Seguidores
6.2K+ Me gusta
Publicaciones
Cartera
·
--
朋友 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_Foundation
朋友 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
Ver traducción
我那天翻Dusk的节点文档,Provisioner节点的官方最低要求写着2核CPU、4GB内存、50GB存储。看着不高对吧?普通云服务器就能跑。 但我顺手查了Archive节点,4核CPU、8GB内存、500GB存储。Prover节点更夸张,单Worker就要1核加1GB内存,最小配置4核8GB。 我纳闷了,同一个网络,节点之间的硬件怎么差这么多? 翻Dusk的共识设计才发现,SBA把参与者分两种。一种是Block Generator,通过Proof-of-Blind-Bid抽签选出,匿名出块。另一种是Provisioner,负责投票验证和敲定区块。每成功出一个块,1个Generator和192个Provisioner拿奖励。Provisioner的投票委员会每轮通过确定性抽签重新选。 Provisioner要验证区块合法性、检查ZK证明、广播BLS签名投票,每一轮都得跑。Generator被选中才干活,Provisioner得随时待命。Archive节点不光要跑共识,还得存整个链的历史。Prover节点专门生成ZK证明,那东西是单线程计算密集型。 我原来觉得PoS网络都差不多,质押够多DUSK就能跑节点。后来发现Dusk根本不是这么回事,每个节点的硬件要求天差地别,Generator匿名抽签、Provisioner委员会投票、Prover扛ZK计算、Archive存全量历史,每一层吃的硬件资源都不一样。 但更让我在意的是,Dusk现在206个活跃Provisioner,前20个控制了35%以上的质押。硬件要求分层之后,能跑Archive和Prover的本来就是少数人,这些人大概率也是筹码最多的人。不是代币分布的问题,硬件门槛本身就是第一道筛子。普通散户连门都摸不到,只能去Hyperstaking池子里把币交给别人。 现在我看Dusk的去中心化,先翻节点文档,再看三种节点的实际运行数量,最后看验证者质押分布。三个数据对不上,去中心化就是个修辞。#dusk $DUSK @Dusk_Foundation
我那天翻Dusk的节点文档,Provisioner节点的官方最低要求写着2核CPU、4GB内存、50GB存储。看着不高对吧?普通云服务器就能跑。

但我顺手查了Archive节点,4核CPU、8GB内存、500GB存储。Prover节点更夸张,单Worker就要1核加1GB内存,最小配置4核8GB。

我纳闷了,同一个网络,节点之间的硬件怎么差这么多?

翻Dusk的共识设计才发现,SBA把参与者分两种。一种是Block Generator,通过Proof-of-Blind-Bid抽签选出,匿名出块。另一种是Provisioner,负责投票验证和敲定区块。每成功出一个块,1个Generator和192个Provisioner拿奖励。Provisioner的投票委员会每轮通过确定性抽签重新选。

Provisioner要验证区块合法性、检查ZK证明、广播BLS签名投票,每一轮都得跑。Generator被选中才干活,Provisioner得随时待命。Archive节点不光要跑共识,还得存整个链的历史。Prover节点专门生成ZK证明,那东西是单线程计算密集型。

我原来觉得PoS网络都差不多,质押够多DUSK就能跑节点。后来发现Dusk根本不是这么回事,每个节点的硬件要求天差地别,Generator匿名抽签、Provisioner委员会投票、Prover扛ZK计算、Archive存全量历史,每一层吃的硬件资源都不一样。

但更让我在意的是,Dusk现在206个活跃Provisioner,前20个控制了35%以上的质押。硬件要求分层之后,能跑Archive和Prover的本来就是少数人,这些人大概率也是筹码最多的人。不是代币分布的问题,硬件门槛本身就是第一道筛子。普通散户连门都摸不到,只能去Hyperstaking池子里把币交给别人。

现在我看Dusk的去中心化,先翻节点文档,再看三种节点的实际运行数量,最后看验证者质押分布。三个数据对不上,去中心化就是个修辞。#dusk $DUSK @Dusk
Ver traducción
第一次研究Dusk的时候,我对“隐私金融”有点怀疑。过去很多项目讲隐私就是藏,但面对机构和受监管市场,问题没那么简单。金融系统需要的不是看不见,而是需要验证的时候能证明某些事成立。 后来重新翻Dusk Citadel资料,才发现自己之前理解偏了。Citadel把身份验证拆成两步。第一步用户发一笔链上交易,附带一个只有自己能控制的隐身地址。许可证颁发方一直在扫链,看到发给自己的请求后验证通过,把许可证铸造到那个地址,用户再扫链接收。第二步用户拿着许可证申请服务,发一笔链上交易附带零知识证明,证明自己持有有效许可证,同时计算一个会话cookie——这是一个能用链上数据验证的值,只有用户和服务方知道它的含义。cookie通过加密信道发给服务方,服务方去链上核对会话ID,对上了才放行。全程链上完成,但除了用户和服务方没人知道谁在申请什么。 这个零知识证明电路的约束数大概是3.5万,生成证明十几秒,链上验证只要0.007秒。对用户来说多等十几秒申请一次,后面每次验证都是毫秒级。好在许可证可以提前作废,不用等过期,所以那个十几秒的生成时间对协议整体性能影响不大。 Citadel要保证五件事:证明你确实有证但不暴露额外信息、服务方能撤销但证没被撤之前一直有效、你的活动不能被追踪、证不能被重复用、只泄露必要信息。这五个属性加上已封装成SDK的Moat开发者工具,构成了Dusk身份层的核心——它和DuskDS、DuskVM平级,不是独立做隐私,而是决定谁有资格做Moonlight的公开交易和Phoenix的隐私交易。 看到这里我停下来想了一个事。真正成熟的隐私系统不是所有东西都看不见,而是让不同角色只看到自己该看到的。未来资产上链,竞争点不是谁藏得多#dusk $DUSK @Dusk_Foundation
第一次研究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 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
研究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_Foundation
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_Foundation
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
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
Ver traducción
我之前看隐私公链时,一直认为零知识证明已经足够处理大部分加密需求,只要把交易参数写进证明,执行交给ZK虚拟机即可。但研究Dusk的Phoenix交易模型后,我改变了这个看法。真正困难的不是生成一笔匿名交易,而是在复杂环境下持续维护那些不断变化的隐私权限规则。 我觉得Phoenix交易模型更像写字楼的分层门禁系统。普通隐私合约像一把固定钥匙,只要生成合法证明就能解锁,而Phoenix系统像动态权限管理员,不只看你有没有有效证明,还会判断交易场景、披露权限、审计需求和合规等级是否符合要求。对于链上隐私应用来说,这种动态权限判断比单纯生成匿名证明更重要。 Dusk选择把隐私层和透明EVM层做分离设计,本质是在解决一个长期问题。过去很多隐私链把所有隐私规则直接写进底层合约,修改成本高,升级风险也大。当应用场景越来越复杂,用户的隐私需求越来越多元,单一匿名模式很难承载频繁变化的业务需求。双模式账户分离后,开发者可以更灵活地调整隐私等级,让交易隐私不再是一份全匿名的永久许可。 但这种设计也带来了新的工程挑战。跨层交易数量增加后,状态同步成本会上升,版本兼容会变复杂,开发者需要投入更多时间理解双模式交互逻辑。另外,ZK证明生成速度、Rusk SDK接入体验,以及机构用户是否愿意迁移,都会影响实际落地效果。 在我看来,Dusk真正需要验证的不是ZK隐私概念是否成立,而是这套双模式隐私系统能不能被大量开发者长期使用。未来我会持续观察测试网上的跨层交易数据,开发者接入情况,以及真实应用中的隐私权限更新频率。一个问题值得思考,如果未来链上隐私场景越来越多,我们需要的究竟是更强的加密能力,还是更好的隐私权限管理方式。 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
我之前看隐私公链时,一直认为零知识证明已经足够处理大部分加密需求,只要把交易参数写进证明,执行交给ZK虚拟机即可。但研究Dusk的Phoenix交易模型后,我改变了这个看法。真正困难的不是生成一笔匿名交易,而是在复杂环境下持续维护那些不断变化的隐私权限规则。

我觉得Phoenix交易模型更像写字楼的分层门禁系统。普通隐私合约像一把固定钥匙,只要生成合法证明就能解锁,而Phoenix系统像动态权限管理员,不只看你有没有有效证明,还会判断交易场景、披露权限、审计需求和合规等级是否符合要求。对于链上隐私应用来说,这种动态权限判断比单纯生成匿名证明更重要。

Dusk选择把隐私层和透明EVM层做分离设计,本质是在解决一个长期问题。过去很多隐私链把所有隐私规则直接写进底层合约,修改成本高,升级风险也大。当应用场景越来越复杂,用户的隐私需求越来越多元,单一匿名模式很难承载频繁变化的业务需求。双模式账户分离后,开发者可以更灵活地调整隐私等级,让交易隐私不再是一份全匿名的永久许可。

但这种设计也带来了新的工程挑战。跨层交易数量增加后,状态同步成本会上升,版本兼容会变复杂,开发者需要投入更多时间理解双模式交互逻辑。另外,ZK证明生成速度、Rusk SDK接入体验,以及机构用户是否愿意迁移,都会影响实际落地效果。

在我看来,Dusk真正需要验证的不是ZK隐私概念是否成立,而是这套双模式隐私系统能不能被大量开发者长期使用。未来我会持续观察测试网上的跨层交易数据,开发者接入情况,以及真实应用中的隐私权限更新频率。一个问题值得思考,如果未来链上隐私场景越来越多,我们需要的究竟是更强的加密能力,还是更好的隐私权限管理方式。
#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
@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_Foundation
我最近在对着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
刚跑完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_Foundation
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
Ver traducción
最近在重新啃 @TermMaxFi 的固定利率AMM机制,卡了我好几天的是一个挺笨的问题:DeFi借贷要走进更主流的金融场景,缺的到底是更多借贷品种,还是一种不需要用户承担利率波动风险的定价方式。把白皮书第四节和官网的真实交易数据对着看了几遍,我倾向于认为TermMax要解决的不是表面的利率高低问题,核心是怎么让链上借贷的资金成本变得可预测。#TermMax 以前DeFi玩借贷,走的路子基本都是浮动利率模型,借的时候只能看当前APY,根本不知道三天后利率会不会被大单拉到离谱。Compound也好,Aave也好,Morpho也好,资金效率确实提上去了,代价是每一个参与者都得承担利率波动的不确定性。借贷工具变多了,可原本最重要的资金成本稳定性,也成了随时会变的变量。TermMax让我觉得不太一样的地方,在于它压根没在浮动利率模型上修修补补。按官方的说法,每一个到期日的资金池对应的是一套独立的固定利率曲线,靠分档到期的AMM做市、流动性分层定价这类机制,提前把不同期限的借贷成本限定死。利率的定价逻辑从头到没变,变的是用户对未来资金成本的可预期程度。 我觉得真正该抠的其实是定价这一层。用户不用去猜下一个区块会不会有大额借贷把利率拉飞,也不用去赌协议会不会突然调整参数改利率模型。TermMax靠分档到期的自动做市,再叠一层清算罚金积累的协议储备金,把不同期限的利率,翻译成用户能直接锁定的固定成本。$TMX 流动性深度、利率偏差率、风险准备金这几个参数说实话还得靠时间去验证,没法现在就下结论。但TermMax至少给我提了个醒:DeFi借贷以后要对接主流资金,未必非得照搬浮动利率那套打法,也可以试着在守住链上去中心化安全模型的前提下,让用户先拿到确定的资金成本。#termmax @termmax
最近在重新啃 @TermMaxFi 的固定利率AMM机制,卡了我好几天的是一个挺笨的问题:DeFi借贷要走进更主流的金融场景,缺的到底是更多借贷品种,还是一种不需要用户承担利率波动风险的定价方式。把白皮书第四节和官网的真实交易数据对着看了几遍,我倾向于认为TermMax要解决的不是表面的利率高低问题,核心是怎么让链上借贷的资金成本变得可预测。#TermMax

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

我觉得真正该抠的其实是定价这一层。用户不用去猜下一个区块会不会有大额借贷把利率拉飞,也不用去赌协议会不会突然调整参数改利率模型。TermMax靠分档到期的自动做市,再叠一层清算罚金积累的协议储备金,把不同期限的利率,翻译成用户能直接锁定的固定成本。$TMX 流动性深度、利率偏差率、风险准备金这几个参数说实话还得靠时间去验证,没法现在就下结论。但TermMax至少给我提了个醒:DeFi借贷以后要对接主流资金,未必非得照搬浮动利率那套打法,也可以试着在守住链上去中心化安全模型的前提下,让用户先拿到确定的资金成本。#termmax @TermMax
Ver traducción
以前选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
以前选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 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
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
Ver traducción
之前对着测试网日志卡了快一下午,桌上冰美式的冰块全化透了,杯壁凝的水在鼠标垫上洇出一圈湿印,我把鼠标往无线充电座上一放,坐那愣了五分钟,才突然反应过来一个反常的点:PoS链的验证者质押记录全在链上公开,攻击者顺着质押地址找节点IP就行,隐私链连交易金额都加密了,总不能让验证者身份裸奔吧?我以前默认隐私链的质押逻辑跟普通PoS差不多,直到翻到Dusk的Citadel匿名质押模块,才发现连出块身份这层它也做了端到端隐私。 我一开始还以为就是给质押地址套个混币,后来对着质押合约的ZK电路细看才明白,根本不是藏地址那么简单——它要实现的是:你不用暴露自己的质押地址和具体质押金额,就能向全网证明你满足最低门槛,有资格参与共识。 这套基于PLONK递归证明的Citadel机制,核心就是解决公开质押记录这个所有PoS链都躲不开的死穴——用户质押DUSK时会把代币锁进统一匿名质押池,质押金额、锁定期、地址关联全部做盲化处理,其他节点仅需8秒就能完成验证,既看不到质押地址关联,也没法把出块签名和具体地址对应起来。 但我得说句实话,这种设计对ZK电路精度要求极高,一旦约束写漏了就可能出现伪造证明的风险,精准罚没作恶节点的工程难度也比公开质押大得多,这块还在持续测试。这条路能不能跑通还得靠时间检验,但至少说明Dusk对隐私的较真是从共识底层开始的。你觉得PoS隐私链的验证者身份,到底该不该公开?评论区聊聊。 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
之前对着测试网日志卡了快一下午,桌上冰美式的冰块全化透了,杯壁凝的水在鼠标垫上洇出一圈湿印,我把鼠标往无线充电座上一放,坐那愣了五分钟,才突然反应过来一个反常的点:PoS链的验证者质押记录全在链上公开,攻击者顺着质押地址找节点IP就行,隐私链连交易金额都加密了,总不能让验证者身份裸奔吧?我以前默认隐私链的质押逻辑跟普通PoS差不多,直到翻到Dusk的Citadel匿名质押模块,才发现连出块身份这层它也做了端到端隐私。

我一开始还以为就是给质押地址套个混币,后来对着质押合约的ZK电路细看才明白,根本不是藏地址那么简单——它要实现的是:你不用暴露自己的质押地址和具体质押金额,就能向全网证明你满足最低门槛,有资格参与共识。

这套基于PLONK递归证明的Citadel机制,核心就是解决公开质押记录这个所有PoS链都躲不开的死穴——用户质押DUSK时会把代币锁进统一匿名质押池,质押金额、锁定期、地址关联全部做盲化处理,其他节点仅需8秒就能完成验证,既看不到质押地址关联,也没法把出块签名和具体地址对应起来。

但我得说句实话,这种设计对ZK电路精度要求极高,一旦约束写漏了就可能出现伪造证明的风险,精准罚没作恶节点的工程难度也比公开质押大得多,这块还在持续测试。这条路能不能跑通还得靠时间检验,但至少说明Dusk对隐私的较真是从共识底层开始的。你觉得PoS隐私链的验证者身份,到底该不该公开?评论区聊聊。
#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_Foundation
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
Ver traducción
说真的最开始我也以为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_Foundation {spot}(DUSKUSDT) #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
Ver traducción
周末楼下咖啡店蹭空调蹲Dusk测试网,连续输错三次密码,折腾半小时才跑完第21笔交易。盯着Rusk虚拟机的执行日志愣了好久——之前玩过几个老隐私链,要么卡半天不出块,要么匿名做满了合规方根本没法开审计权限。本来我对所谓“隐私公链”已经不抱什么期待了,直到亲手踩坑才明白,这玩意儿真不是套个壳炒概念。 最开始我当SBA共识是换皮PoS,翻完节点规则、自己跑了一万次双花模拟才懂:SBA(Segregated Byzantine Agreement,隔离拜占庭协议)把节点分成两层,一层是出块委员会负责打包交易,一层是抽查验证者负责随机审计。随机抽查的种子靠VDF(可验证延迟函数)生成,没人能提前预测接下来查谁。测试网浏览器显示有3个节点因为提交无效块被罚没保证金,其中两个是软罚没——漏了几个块,暂时移出共识队列,有效质押额被砍了一截;另一个是硬罚没,双签被逮到,质押代币直接扣了20%销毁掉。这类惩罚机制把作恶成本抬得很高,试错代价极大。 交易测试时手滑多打了个0,金额直接超了Range Proof的范围,交易瞬间被丢回来,链上连废交易痕迹都没留。Phoenix协议的Range Proof硬卡交易金额范围,配合Pedersen承诺锁死每一笔的资产总量,不会出现凭空增发。加上一次性Stealth Address每笔交易自动换新地址,我连续转5笔测试币,链上根本没法把这几笔关联到同一个账户。递归聚合的PLONK证明压缩到287字节,单笔验证才1.8毫秒,跑起来很顺,测试网高峰期也没遇到拥堵。 Rusk虚拟机是全Rust从零写的,原生支持机密资产标准,我部署测试Token连200行隐私代码都不用写,跑合约Gas比EVM套ZK层低63%,还给合规方预留了审计权限入口——隐私和合规不用二选一,可以同时兼顾。测试网跑完那晚,比之前跟投任何项目都踏实。 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
周末楼下咖啡店蹭空调蹲Dusk测试网,连续输错三次密码,折腾半小时才跑完第21笔交易。盯着Rusk虚拟机的执行日志愣了好久——之前玩过几个老隐私链,要么卡半天不出块,要么匿名做满了合规方根本没法开审计权限。本来我对所谓“隐私公链”已经不抱什么期待了,直到亲手踩坑才明白,这玩意儿真不是套个壳炒概念。

最开始我当SBA共识是换皮PoS,翻完节点规则、自己跑了一万次双花模拟才懂:SBA(Segregated Byzantine Agreement,隔离拜占庭协议)把节点分成两层,一层是出块委员会负责打包交易,一层是抽查验证者负责随机审计。随机抽查的种子靠VDF(可验证延迟函数)生成,没人能提前预测接下来查谁。测试网浏览器显示有3个节点因为提交无效块被罚没保证金,其中两个是软罚没——漏了几个块,暂时移出共识队列,有效质押额被砍了一截;另一个是硬罚没,双签被逮到,质押代币直接扣了20%销毁掉。这类惩罚机制把作恶成本抬得很高,试错代价极大。

交易测试时手滑多打了个0,金额直接超了Range Proof的范围,交易瞬间被丢回来,链上连废交易痕迹都没留。Phoenix协议的Range Proof硬卡交易金额范围,配合Pedersen承诺锁死每一笔的资产总量,不会出现凭空增发。加上一次性Stealth Address每笔交易自动换新地址,我连续转5笔测试币,链上根本没法把这几笔关联到同一个账户。递归聚合的PLONK证明压缩到287字节,单笔验证才1.8毫秒,跑起来很顺,测试网高峰期也没遇到拥堵。

Rusk虚拟机是全Rust从零写的,原生支持机密资产标准,我部署测试Token连200行隐私代码都不用写,跑合约Gas比EVM套ZK层低63%,还给合规方预留了审计权限入口——隐私和合规不用二选一,可以同时兼顾。测试网跑完那晚,比之前跟投任何项目都踏实。
#dusk $DUSK @Dusk
Inicia sesión para explorar más contenidos
Únete a usuarios de criptomonedas de todo el mundo en Binance Square
⚡️ Obtén la información más reciente y útil sobre criptomonedas.
💬 Confía en el mayor exchange de criptomonedas del mundo.
👍 Descubre opiniones reales de creadores verificados.
Correo electrónico/número de teléfono
Mapa del sitio
Preferencias de cookies
Términos y condiciones de la plataforma