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

小饼的撸毛日记

19年入圈。穿越两轮牛熊。全职Crypto,Trader,BTC/BNB 长期持有者。Alpha撸毛策略探索者,深度分享:alpha交流 LH688E
Ouvert au trading
Détenteur pour BNB
Détenteur pour BNB
Trade fréquemment
5.8 an(s)
86 Suivis
2.5K+ Abonnés
6.2K+ J’aime
Publications
Portefeuille
·
--
Des amis courent après Dusk et me demandent : il a des sorties de bloc manquées en série par son nœud, il a été pénalisé—est-ce que ça compte comme de la malveillance ? Au début, je pensais que la pénalité est la pénalité : dans l’approche de Cosmos, le double-sig prive directement de droits et ferme la porte aux “petits noirs”, il n’y a pas grand-chose à discuter. Puis j’ai regardé le mécanisme de pénalités de Dusk : il y en a deux. Soft Slashing, la pénalité “douce”, gère les erreurs non malveillantes, par exemple lorsque le nœud est hors ligne au moment où il devait proposer un bloc, ou ne diffuse pas dans la fenêtre prévue—rien de malicieux, juste un problème d’exploitation. La pénalité est, à chaque série d’infractions consécutives, de N fois 10 % de l’actif mis en garantie (N correspondant au nombre de violations consécutives), et elle expulse le nœud du consensus pour N epochs. Un epoch est la période de consensus de Dusk ; à la fin de chaque round, l’ensemble des validateurs est renouvelé. Les DUSK retirés ne sont pas détruits : ils sont transférés hors des garanties actives, et le nœud peut les récupérer. Hard Slashing, la pénalité “dure”, concerne les comportements malveillants. Les blocs invalides coûtent 10 % du collatéral et sont détruits ; les doubles votes ou les doubles propositions coûtent 20 % et sont détruits. “Détruit” veut dire que c’est vraiment perdu : ce n’est pas juste mis de côté puis restitué. Je n’avais pas compris pourquoi on distingue deux cas. En relisant la documentation, j’ai compris la partie sur l’imputabilité. Si un nœud rate un bloc à cause d’une fluctuation réseau, tu appliques quand même une pénalité lourde ; les validateurs vont placer ces nœuds les plus “chers” sur le cloud, et les coûts d’exploitation augmentent—au final, la décentralisation s’en trouve même dégradée. Le Soft Slashing sert à pousser les nœuds peu fiables hors de l’ensemble actif tout en leur laissant une chance de revenir : à chaque fois on retire une petite part, sans réduire à la faillite ceux qui exploitent honnêtement. Ce qui a vraiment changé mon avis, c’est le paramètre N. Plus les violations consécutives sont nombreuses, plus la pénalité est grande et plus la durée d’expulsion est longue. Première coupure : 10 % retirés et 1 epoch en moins. Deuxième fois : 20 % retirés et 2 epochs en moins. Pression exponentielle : soit le nœud revient stable, soit il quitte automatiquement. Le Hard Slashing reste réservé aux actes clairement malveillants : une seule fois, destruction, pas de fenêtre de récupération. Prenons Polkadot en exemple. Son Slashing est aussi gradué, mais les proportions sont plus fines : de 0,1 % à 100 %, et l’amende est partagée avec le dénonciateur. La logique de Dusk est plus simple : soit erreur, soit malveillance ; le ratio est fixe ; la destruction ne récompense pas le dénonciateur. L’avantage, c’est que les validateurs peuvent prédire le coût d’une erreur et n’hésitent pas à faire tourner un nœud. Mon ami, après ça, a dit qu’il accepte la fois Soft Slashing : chez lui, le réseau était tombé pendant une demi-heure. Et là aussi, je comprends pourquoi Dusk sépare autant les mécanismes : sans pénalités graduées, les nœuds honnêtes et les nœuds malveillants seraient traités pareil #dusk $DUSK @Dusk_Foundation
Des amis courent après Dusk et me demandent : il a des sorties de bloc manquées en série par son nœud, il a été pénalisé—est-ce que ça compte comme de la malveillance ? Au début, je pensais que la pénalité est la pénalité : dans l’approche de Cosmos, le double-sig prive directement de droits et ferme la porte aux “petits noirs”, il n’y a pas grand-chose à discuter.

Puis j’ai regardé le mécanisme de pénalités de Dusk : il y en a deux. Soft Slashing, la pénalité “douce”, gère les erreurs non malveillantes, par exemple lorsque le nœud est hors ligne au moment où il devait proposer un bloc, ou ne diffuse pas dans la fenêtre prévue—rien de malicieux, juste un problème d’exploitation. La pénalité est, à chaque série d’infractions consécutives, de N fois 10 % de l’actif mis en garantie (N correspondant au nombre de violations consécutives), et elle expulse le nœud du consensus pour N epochs. Un epoch est la période de consensus de Dusk ; à la fin de chaque round, l’ensemble des validateurs est renouvelé. Les DUSK retirés ne sont pas détruits : ils sont transférés hors des garanties actives, et le nœud peut les récupérer.

Hard Slashing, la pénalité “dure”, concerne les comportements malveillants. Les blocs invalides coûtent 10 % du collatéral et sont détruits ; les doubles votes ou les doubles propositions coûtent 20 % et sont détruits. “Détruit” veut dire que c’est vraiment perdu : ce n’est pas juste mis de côté puis restitué.

Je n’avais pas compris pourquoi on distingue deux cas. En relisant la documentation, j’ai compris la partie sur l’imputabilité. Si un nœud rate un bloc à cause d’une fluctuation réseau, tu appliques quand même une pénalité lourde ; les validateurs vont placer ces nœuds les plus “chers” sur le cloud, et les coûts d’exploitation augmentent—au final, la décentralisation s’en trouve même dégradée. Le Soft Slashing sert à pousser les nœuds peu fiables hors de l’ensemble actif tout en leur laissant une chance de revenir : à chaque fois on retire une petite part, sans réduire à la faillite ceux qui exploitent honnêtement.

Ce qui a vraiment changé mon avis, c’est le paramètre N. Plus les violations consécutives sont nombreuses, plus la pénalité est grande et plus la durée d’expulsion est longue. Première coupure : 10 % retirés et 1 epoch en moins. Deuxième fois : 20 % retirés et 2 epochs en moins. Pression exponentielle : soit le nœud revient stable, soit il quitte automatiquement. Le Hard Slashing reste réservé aux actes clairement malveillants : une seule fois, destruction, pas de fenêtre de récupération.

Prenons Polkadot en exemple. Son Slashing est aussi gradué, mais les proportions sont plus fines : de 0,1 % à 100 %, et l’amende est partagée avec le dénonciateur. La logique de Dusk est plus simple : soit erreur, soit malveillance ; le ratio est fixe ; la destruction ne récompense pas le dénonciateur. L’avantage, c’est que les validateurs peuvent prédire le coût d’une erreur et n’hésitent pas à faire tourner un nœud.

Mon ami, après ça, a dit qu’il accepte la fois Soft Slashing : chez lui, le réseau était tombé pendant une demi-heure. Et là aussi, je comprends pourquoi Dusk sépare autant les mécanismes : sans pénalités graduées, les nœuds honnêtes et les nœuds malveillants seraient traités pareil #dusk $DUSK @Dusk
Voir la traduction
我那天翻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
Voir la traduction
第一次研究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
Voir la traduction
研究Dusk的时候,我第一眼盯的是DuskEVM。过去看项目习惯了,先看执行环境——开发者进不进来,决定一条链有没有未来。 翻完资料我又回头看了一遍,这次真正让我停下来的,是DuskDS。 我以前一直觉得金融上链最大的坎是速度和成本。但把Dusk的设计拆开之后,我发现真正麻烦的是另一件事:一笔交易执行完,谁来确认它已经是最终状态? Dusk把执行和结算拆成了两层。DuskEVM跑应用,基于OP Stack搭的,Solidity开发者用Hardhat、MetaMask那套工具就能直接部署。Sequencer处理交易,batcher把数据打包成EIP-4844 blob往DuskDS上传。DuskDS不关心上面跑什么应用,只管共识、数据可用性和最终状态确认。 我盯着DuskDS那部分看了很久,才搞明白它到底在干什么。它跑的是Succinct Attestation,一种基于委员会的PoS协议。每轮一个Provisioner提议区块,一个委员会验证,另一个委员会敲定。一旦敲定就是确定性终局性,不像比特币只有概率终局性,正常情况不存在用户能感知的重组。想成为Provisioner最低质押1000枚DUSK,节点7×24在线,离线太久或作恶会被罚没。 研究到这里我才反应过来——以前觉得区块链最大的价值是让交易变快,但金融市场真正怕的不是慢,是不确定。一笔证券交易,资产转移完了但支付没同步,或者不同参与方看到的状态不一致,效率再高也没人敢用。 Dusk的确定性结算,本质是在解决这个问题。最终性压到两到三秒,加上交付对支付的原生工作流——这套组合在金融结算场景里才有真正的实用价值。 当然,这套设计最终还需要生态验证。基础设施做好只是第一步,真正的价值还要看资产和应用愿不愿意进来。 但研究完Dusk之后,我最大的变化是:不再只关注一条链能处理多少交易,而是开始关注它能不能让金融参与者放心 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
研究Dusk的时候,我第一眼盯的是DuskEVM。过去看项目习惯了,先看执行环境——开发者进不进来,决定一条链有没有未来。

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

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

Dusk把执行和结算拆成了两层。DuskEVM跑应用,基于OP Stack搭的,Solidity开发者用Hardhat、MetaMask那套工具就能直接部署。Sequencer处理交易,batcher把数据打包成EIP-4844 blob往DuskDS上传。DuskDS不关心上面跑什么应用,只管共识、数据可用性和最终状态确认。

我盯着DuskDS那部分看了很久,才搞明白它到底在干什么。它跑的是Succinct Attestation,一种基于委员会的PoS协议。每轮一个Provisioner提议区块,一个委员会验证,另一个委员会敲定。一旦敲定就是确定性终局性,不像比特币只有概率终局性,正常情况不存在用户能感知的重组。想成为Provisioner最低质押1000枚DUSK,节点7×24在线,离线太久或作恶会被罚没。

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

Dusk的确定性结算,本质是在解决这个问题。最终性压到两到三秒,加上交付对支付的原生工作流——这套组合在金融结算场景里才有真正的实用价值。

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

但研究完Dusk之后,我最大的变化是:不再只关注一条链能处理多少交易,而是开始关注它能不能让金融参与者放心
#dusk $DUSK @Dusk
Voir la traduction
Dusk宣布主网运行后,我没有第一时间转发。这几年看过不少项目,上线时热闹,过几个月区块没怎么增长,节点也没变化。所以这次我没急着写,而是连续几天盯着链上数据。 我先看区块高度有没有持续变化,出块节奏稳不稳,验证参与跟没跟上。以前判断一条链的价值,习惯看宣传和交易量。但这几天观察下来,真正不会说谎的,是网络有没有形成持续运行的状态。这个判断很冷,可我越看越认同。 真正让我停住的,是Dusk的Succinct Attestation。它是DuskDS底层基于委员会的PoS共识协议,用随机选出的Provisioner来提议、验证和确认区块。每个共识轮次走三步:Proposal阶段,一名被选中的Provisioner创建并广播候选区块;Validation阶段,一个委员会检查区块有效性,需要三分之二绝对多数通过;Ratification阶段,另一个委员会确认并最终敲定区块。一旦经过Ratification,区块就进入确定性最终状态,不会回滚。 这个细节我看了两遍,因为它说的不是“大概率安全”,而是“一旦确认,就算真正结束”。 这点对金融场景很关键。很多链的逻辑是等久一点,大概率不会回滚。但证券、清结算、合规资产不接受“大概率”。它们要的是明确结果,昨天确认今天就不该被推翻。我以前总觉得最终性是技术指标,现在才意识到,它是机构敢不敢把真实资产放上来的门槛。 成为Provisioner也不复杂。质押至少1000DUSK,跑一个节点就行。节点需24/7在线,最低2核CPU、4GB内存、50GB存储。质押后约12小时成熟,之后就能参与共识。委员会通过质押权重抽签随机选出,每次都不一样。 这几天盯下来,我最大的变化不是更相信Dusk,而是更清楚自己该看什么。对一个面向隐私和合规金融的基础设施来说,主网上线只是起点,真正重要的是网络能不能稳定产生可信状态#dusk $DUSK @Dusk_Foundation
Dusk宣布主网运行后,我没有第一时间转发。这几年看过不少项目,上线时热闹,过几个月区块没怎么增长,节点也没变化。所以这次我没急着写,而是连续几天盯着链上数据。

我先看区块高度有没有持续变化,出块节奏稳不稳,验证参与跟没跟上。以前判断一条链的价值,习惯看宣传和交易量。但这几天观察下来,真正不会说谎的,是网络有没有形成持续运行的状态。这个判断很冷,可我越看越认同。

真正让我停住的,是Dusk的Succinct Attestation。它是DuskDS底层基于委员会的PoS共识协议,用随机选出的Provisioner来提议、验证和确认区块。每个共识轮次走三步:Proposal阶段,一名被选中的Provisioner创建并广播候选区块;Validation阶段,一个委员会检查区块有效性,需要三分之二绝对多数通过;Ratification阶段,另一个委员会确认并最终敲定区块。一旦经过Ratification,区块就进入确定性最终状态,不会回滚。

这个细节我看了两遍,因为它说的不是“大概率安全”,而是“一旦确认,就算真正结束”。

这点对金融场景很关键。很多链的逻辑是等久一点,大概率不会回滚。但证券、清结算、合规资产不接受“大概率”。它们要的是明确结果,昨天确认今天就不该被推翻。我以前总觉得最终性是技术指标,现在才意识到,它是机构敢不敢把真实资产放上来的门槛。

成为Provisioner也不复杂。质押至少1000DUSK,跑一个节点就行。节点需24/7在线,最低2核CPU、4GB内存、50GB存储。质押后约12小时成熟,之后就能参与共识。委员会通过质押权重抽签随机选出,每次都不一样。

这几天盯下来,我最大的变化不是更相信Dusk,而是更清楚自己该看什么。对一个面向隐私和合规金融的基础设施来说,主网上线只是起点,真正重要的是网络能不能稳定产生可信状态#dusk $DUSK @Dusk
刚开始研究Dusk共识机制的时候,我对着白皮书看了半天也没搞明白什么叫确定性最终性。没办法,我只好在纸上画了三列时间轴对比表硬啃。 以太坊的Gasper走的是概率最终性,区块得堆好几个epoch才能说基本安全了。Solana的Tower BFT也要几十秒才能确认。Dusk的Succinct Attestation呢?区块一旦被批准,就是硬的、确定的、不会回头的那种最终性。 当时我盯着纸上这三条线看了很久。几秒钟的差距在加密交易里你可能根本感觉不到,多等一会儿就是了。但在证券结算的场景下,这几秒是亿级资产的最终安全锁。你在交易所卖了一笔股票,T+2才交割,这中间两天时间资产到底算谁的?如果结算那一刻链还能回滚,谁敢把真实资产放上去?散户交易说不太可能回滚就够了,但机构结算不行,不太可能这三个字在法律和合规层面等于什么都没保证。 后来我翻官方文档才搞清楚Succinct Attestation到底怎么跑的,看完那段才算松了口气,之前的困惑总算有了答案。它是无需许可的、基于委员会的PoS共识协议。系统随机选出一批叫Provisioner的节点来提议区块,另一批节点负责验证,最后一批委员会确认验证结果、正式批准区块。区块一旦走完 ratification 这一步,就是确定性最终性,正常操作下不会发生面向用户的重组。 Dusk主网2026年1月7号正式启动,每秒能处理超过20000笔交易。六年开发周期,终于从测试网走到了能跑真实资产的阶段。以前我对共识机制的理解就是谁出块谁拿奖励,觉得这东西跟普通用户没什么关系。但Dusk让我换了个角度看,共识机制的选择本质上是在回答一个最基本的问题:你这笔钱一旦放进去,到底能不能真的算数?Succinct Attestation给的答案是能,而且不用加大概率三个字。#dusk $DUSK @Dusk_Foundation
刚开始研究Dusk共识机制的时候,我对着白皮书看了半天也没搞明白什么叫确定性最终性。没办法,我只好在纸上画了三列时间轴对比表硬啃。

以太坊的Gasper走的是概率最终性,区块得堆好几个epoch才能说基本安全了。Solana的Tower BFT也要几十秒才能确认。Dusk的Succinct Attestation呢?区块一旦被批准,就是硬的、确定的、不会回头的那种最终性。

当时我盯着纸上这三条线看了很久。几秒钟的差距在加密交易里你可能根本感觉不到,多等一会儿就是了。但在证券结算的场景下,这几秒是亿级资产的最终安全锁。你在交易所卖了一笔股票,T+2才交割,这中间两天时间资产到底算谁的?如果结算那一刻链还能回滚,谁敢把真实资产放上去?散户交易说不太可能回滚就够了,但机构结算不行,不太可能这三个字在法律和合规层面等于什么都没保证。

后来我翻官方文档才搞清楚Succinct Attestation到底怎么跑的,看完那段才算松了口气,之前的困惑总算有了答案。它是无需许可的、基于委员会的PoS共识协议。系统随机选出一批叫Provisioner的节点来提议区块,另一批节点负责验证,最后一批委员会确认验证结果、正式批准区块。区块一旦走完 ratification 这一步,就是确定性最终性,正常操作下不会发生面向用户的重组。

Dusk主网2026年1月7号正式启动,每秒能处理超过20000笔交易。六年开发周期,终于从测试网走到了能跑真实资产的阶段。以前我对共识机制的理解就是谁出块谁拿奖励,觉得这东西跟普通用户没什么关系。但Dusk让我换了个角度看,共识机制的选择本质上是在回答一个最基本的问题:你这笔钱一旦放进去,到底能不能真的算数?Succinct Attestation给的答案是能,而且不用加大概率三个字。#dusk $DUSK @Dusk
Voir la traduction
上周在TermMax测试网做完一笔ETH抵押借款,我打开钱包扫了一眼余额。多了个东西,一个NFT,我根本不记得领过这玩意儿。当时脑子里乱得很,第一反应是钱包中病毒了还是测试网给我空投了什么垃圾,刷新了三次它还在。说实话我开始有点慌了,抵押的ETH可别给我搞没了。 然后我就去翻官方文档,翻了快半小时,连社区早期的讨论帖都翻了个遍,才搞明白这就是之前没太在意的GT。你知道这玩意儿最核心的逻辑是什么吗?你借一笔钱,协议直接给你mint一个NFT,里面记着你抵押了多少资产、借出了多少FT、对应什么期限的MLTV参数,每一笔借款都是一个独立的NFT。 我以前在别的固定利率协议上吃过类似的亏,明明已经还了一部分,系统还显示着原始抵押率,吓得我以为自己又欠了一遍。后来找客服查了半天才发现是前端状态同步延迟,但那种“我到底还清了没有”的焦虑,真不想再经历第二次。 后来我琢磨了一下,GT真正有意思的地方其实还不止于此。你可以把GT理解成你的杠杆仓位被打包成了一个可以交易的物品,不想等到期了直接卖掉就行,有人接盘的话仓位里的债务和抵押品就一起转过去了。这跟传统借贷完全不是一回事,传统借贷里你的仓位是合约里的一串状态,想转给别人没门儿,只能自己平仓、提抵押品、对方再重新开仓,折腾半天。GT直接把整个仓位打包成一个NFT,想转就转,想卖就卖,一个仓位一个NFT清清楚楚,不会互相干扰。 我一直以为GT就是个普通的权益凭证,现在才看懂它真正的价值,就是把你借款的全部所有权完完整整交到了用户自己手里。我准备主网上线后多开几笔不同期限的仓位,逐笔盯着看GT在到期兑付时候的全流程表现。#termmax @termmax
上周在TermMax测试网做完一笔ETH抵押借款,我打开钱包扫了一眼余额。多了个东西,一个NFT,我根本不记得领过这玩意儿。当时脑子里乱得很,第一反应是钱包中病毒了还是测试网给我空投了什么垃圾,刷新了三次它还在。说实话我开始有点慌了,抵押的ETH可别给我搞没了。

然后我就去翻官方文档,翻了快半小时,连社区早期的讨论帖都翻了个遍,才搞明白这就是之前没太在意的GT。你知道这玩意儿最核心的逻辑是什么吗?你借一笔钱,协议直接给你mint一个NFT,里面记着你抵押了多少资产、借出了多少FT、对应什么期限的MLTV参数,每一笔借款都是一个独立的NFT。

我以前在别的固定利率协议上吃过类似的亏,明明已经还了一部分,系统还显示着原始抵押率,吓得我以为自己又欠了一遍。后来找客服查了半天才发现是前端状态同步延迟,但那种“我到底还清了没有”的焦虑,真不想再经历第二次。

后来我琢磨了一下,GT真正有意思的地方其实还不止于此。你可以把GT理解成你的杠杆仓位被打包成了一个可以交易的物品,不想等到期了直接卖掉就行,有人接盘的话仓位里的债务和抵押品就一起转过去了。这跟传统借贷完全不是一回事,传统借贷里你的仓位是合约里的一串状态,想转给别人没门儿,只能自己平仓、提抵押品、对方再重新开仓,折腾半天。GT直接把整个仓位打包成一个NFT,想转就转,想卖就卖,一个仓位一个NFT清清楚楚,不会互相干扰。

我一直以为GT就是个普通的权益凭证,现在才看懂它真正的价值,就是把你借款的全部所有权完完整整交到了用户自己手里。我准备主网上线后多开几笔不同期限的仓位,逐笔盯着看GT在到期兑付时候的全流程表现。#termmax @TermMax
Voir la traduction
我之前看隐私公链时,一直认为零知识证明已经足够处理大部分加密需求,只要把交易参数写进证明,执行交给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
Voir la traduction
@TermMaxFi 之前在Aave存30天固定利率碰上参数硬编码改不动亏了小几百收益,所以我对固定利率产品的底层假设特别敏感,翻TermMax白皮书时看到有句话团队一直拿来当核心叙事,我越看越觉得是藏在暗处的阿喀琉斯之踵:“分档到期AMM,是当前链上实现固定利率的最优路径。”逻辑起点很直白——浮动利率做不了长期定价,所以用分档资金池锁死到期收益。 但有个要命的沉默:TermMax团队从没讨论过,按我个人的推演万一未来主流借贷协议原生支持固定利率分片,这套分档AMM体系是什么下场。原生分片能让浮动利率池直接划出独立的固定利率子池,不用额外部署一套独立的到期资金池。这玩意儿是DeFi借贷派眼里的长期定价圣杯。一旦主流借贷协议完成升级,那些现在绕不开独立固定利率协议的方案立马满血复活。一个能在现有借贷池里直接开固定利率仓位、不用跨协议迁移流动性的产品,和一个得单独做市、每笔成交都要匹配到期对手方的独立资金池,你选哪个? 就像当年功能机把按键交互做到极致,全触屏一来直接降维打击。分档到期AMM现在就是功能机——链上原生利率能力受限时最优雅的妥协。原生固定利率分片这根稻草落下,现有叙事可能一夜翻转。 $TMX 呢?TermMax说它价值捕获靠固定利率交易持续使用——做市锁仓靠TMX抵押,手续费分润靠TMX质押,协议收入持续销毁TMX。可原生分片催生真正的原生固定利率能力之后,谁还绕道独立的分档资金池?TMX的经济模型建在“通用借贷协议做不了固定利率”这个前提上,前提被推翻,通缩叙事 我的态度:分档AMM是当前约束下的局部最优解,别当永恒真理。底层借贷协议在进化,今天卡住长期固定利率的坎,明天一次版本迭代就跨过去。TermMax能不能从“固定利率产品商”转型成“链上利率基础设施层#termmax @termmax
@TermMaxFi 之前在Aave存30天固定利率碰上参数硬编码改不动亏了小几百收益,所以我对固定利率产品的底层假设特别敏感,翻TermMax白皮书时看到有句话团队一直拿来当核心叙事,我越看越觉得是藏在暗处的阿喀琉斯之踵:“分档到期AMM,是当前链上实现固定利率的最优路径。”逻辑起点很直白——浮动利率做不了长期定价,所以用分档资金池锁死到期收益。

但有个要命的沉默:TermMax团队从没讨论过,按我个人的推演万一未来主流借贷协议原生支持固定利率分片,这套分档AMM体系是什么下场。原生分片能让浮动利率池直接划出独立的固定利率子池,不用额外部署一套独立的到期资金池。这玩意儿是DeFi借贷派眼里的长期定价圣杯。一旦主流借贷协议完成升级,那些现在绕不开独立固定利率协议的方案立马满血复活。一个能在现有借贷池里直接开固定利率仓位、不用跨协议迁移流动性的产品,和一个得单独做市、每笔成交都要匹配到期对手方的独立资金池,你选哪个?

就像当年功能机把按键交互做到极致,全触屏一来直接降维打击。分档到期AMM现在就是功能机——链上原生利率能力受限时最优雅的妥协。原生固定利率分片这根稻草落下,现有叙事可能一夜翻转。
$TMX 呢?TermMax说它价值捕获靠固定利率交易持续使用——做市锁仓靠TMX抵押,手续费分润靠TMX质押,协议收入持续销毁TMX。可原生分片催生真正的原生固定利率能力之后,谁还绕道独立的分档资金池?TMX的经济模型建在“通用借贷协议做不了固定利率”这个前提上,前提被推翻,通缩叙事

我的态度:分档AMM是当前约束下的局部最优解,别当永恒真理。底层借贷协议在进化,今天卡住长期固定利率的坎,明天一次版本迭代就跨过去。TermMax能不能从“固定利率产品商”转型成“链上利率基础设施层#termmax @TermMax
J’ai récemment mené des tests parallèles de plusieurs flux de transactions en comptant différents comptes sur Dusk. Je pensais au départ que les chaînes de confidentialité traitaient principalement le chiffrement et l’anonymat. Puis j’ai fait tourner ensemble des transactions provenant de comptes EVM transparents et de comptes ZK privés, et j’ai compris que le vrai problème n’est pas tant la manière de chiffrer, mais plutôt la façon d’assurer la validation sans divulguer le texte en clair lorsque deux transactions « légitimes » sont simultanément incluses dans la blockchain. J’avais l’impression auparavant qu’il suffisait que les preuves de confidentialité soient valides ; aujourd’hui, je pense de plus en plus que la gestion des conflits de transactions parallèles est le défi central pour une mise en œuvre durable. C’est un peu comme deux voies de circulation parallèles dans un centre commercial. Vu séparément, les règles de circulation de chaque voie ne posent pas de problème, mais si les règles de changement de voie des véhicules entre les voies adjacentes ne sont pas cohérentes, toute la route se bloque, voire provoque des collisions. Dans les réseaux de transactions confidentielles, c’est pareil : la preuve correcte d’une transaction ZK isolée ne signifie pas que, après soumission en parallèle de plusieurs transactions, l’état sur la chaîne reste cohérent. Dusk combine, de manière essentielle, le modèle d’UTXO de confidentialité Phoenix, la couche EVM transparente Moonlight, le module de preuves de tarification Citadel et le mécanisme de divulgation ciblée VEP. En substance, cela permet aux utilisateurs de choisir eux-mêmes le niveau de confidentialité de leurs transactions. L’avantage est évident : les utilisateurs ordinaires peuvent protéger la trajectoire de leurs actifs avec des comptes privés, tandis que les utilisateurs institutionnels peuvent effectuer des règlements conformes avec des comptes transparents, sans être limités par un seul mode de confidentialité. Mais un problème apparaît aussi : si une transaction de confidentialité doit appeler une adresse de contrat transparente, et qu’une autre transaction transparente doit lire le solde d’un compte de confidentialité, comment les nœuds peuvent-ils synchroniser l’état sans divulguer le texte en clair ? Dans le passé, beaucoup de chaînes de confidentialité n’avaient pas ce problème, car elles étaient soit entièrement anonymes, soit entièrement transparentes ; il n’existait donc pas de double mode en exécution parallèle. Ce que je vois maintenant comme compromis (trade-off) est très clair. En augmentant la flexibilité de la confidentialité, la complexité de la validation d’état augmente aussi ; plus il y a de comptes en double mode, plus le coût de génération des preuves ZK est élevé ; et lorsque les transactions inter-couches deviennent fréquentes, les frontières entre le comptage du Gas et l’audit/la traçabilité peuvent devenir floues. Le délai des transactions inter-couches, le taux d’échec de validation des preuves et le temps de vérification de la divulgation ciblée pourraient refléter plus fidèlement la maturité de la mise en œuvre d’une blockchain de confidentialité que le TPS. À l’avenir, je continuerai à observer les données de transactions inter-couches sur le testnet, les historiques officiels de correctifs liés aux conflits, ainsi que la manière dont les nœuds gèrent les transactions parallèles en double mode. #dusk $DUSK @Dusk_Foundation
J’ai récemment mené des tests parallèles de plusieurs flux de transactions en comptant différents comptes sur Dusk. Je pensais au départ que les chaînes de confidentialité traitaient principalement le chiffrement et l’anonymat. Puis j’ai fait tourner ensemble des transactions provenant de comptes EVM transparents et de comptes ZK privés, et j’ai compris que le vrai problème n’est pas tant la manière de chiffrer, mais plutôt la façon d’assurer la validation sans divulguer le texte en clair lorsque deux transactions « légitimes » sont simultanément incluses dans la blockchain. J’avais l’impression auparavant qu’il suffisait que les preuves de confidentialité soient valides ; aujourd’hui, je pense de plus en plus que la gestion des conflits de transactions parallèles est le défi central pour une mise en œuvre durable.

C’est un peu comme deux voies de circulation parallèles dans un centre commercial. Vu séparément, les règles de circulation de chaque voie ne posent pas de problème, mais si les règles de changement de voie des véhicules entre les voies adjacentes ne sont pas cohérentes, toute la route se bloque, voire provoque des collisions. Dans les réseaux de transactions confidentielles, c’est pareil : la preuve correcte d’une transaction ZK isolée ne signifie pas que, après soumission en parallèle de plusieurs transactions, l’état sur la chaîne reste cohérent.

Dusk combine, de manière essentielle, le modèle d’UTXO de confidentialité Phoenix, la couche EVM transparente Moonlight, le module de preuves de tarification Citadel et le mécanisme de divulgation ciblée VEP. En substance, cela permet aux utilisateurs de choisir eux-mêmes le niveau de confidentialité de leurs transactions. L’avantage est évident : les utilisateurs ordinaires peuvent protéger la trajectoire de leurs actifs avec des comptes privés, tandis que les utilisateurs institutionnels peuvent effectuer des règlements conformes avec des comptes transparents, sans être limités par un seul mode de confidentialité. Mais un problème apparaît aussi : si une transaction de confidentialité doit appeler une adresse de contrat transparente, et qu’une autre transaction transparente doit lire le solde d’un compte de confidentialité, comment les nœuds peuvent-ils synchroniser l’état sans divulguer le texte en clair ? Dans le passé, beaucoup de chaînes de confidentialité n’avaient pas ce problème, car elles étaient soit entièrement anonymes, soit entièrement transparentes ; il n’existait donc pas de double mode en exécution parallèle.

Ce que je vois maintenant comme compromis (trade-off) est très clair. En augmentant la flexibilité de la confidentialité, la complexité de la validation d’état augmente aussi ; plus il y a de comptes en double mode, plus le coût de génération des preuves ZK est élevé ; et lorsque les transactions inter-couches deviennent fréquentes, les frontières entre le comptage du Gas et l’audit/la traçabilité peuvent devenir floues. Le délai des transactions inter-couches, le taux d’échec de validation des preuves et le temps de vérification de la divulgation ciblée pourraient refléter plus fidèlement la maturité de la mise en œuvre d’une blockchain de confidentialité que le TPS.

À l’avenir, je continuerai à observer les données de transactions inter-couches sur le testnet, les historiques officiels de correctifs liés aux conflits, ainsi que la manière dont les nœuds gèrent les transactions parallèles en double mode. #dusk $DUSK @Dusk
Voir la traduction
刚跑完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
Voir la traduction
我对着Dusk测试网的节点日志卡了快一下午,桌上冰美式的冰块全化透了,杯壁凝的水在鼠标垫上洇出一圈湿印,我把鼠标往无线充电座上一放,坐那愣了五分钟,突然反应过来一个一直卡着我的问题:现在做隐私公链的项目不少,Dusk为什么最后选了Rusk原生隐私虚拟机,而不是在EVM上套一层ZK隐私插件?一开始我以为纯粹是技术路线选择,后来把官方那些关于Phoenix交易模型和端到端隐私的资料翻来覆去看了几遍,才发现想简单了。 隐私应用最吃紧的地方,其实不是零知识证明本身,而是全链路状态泄露的风险。如果只是在EVM交易层加个隐私壳,合约存储、执行栈、事件日志里到处都留着明文痕迹,随便哪一个环节泄露,前面的隐私保护就全白做了。Dusk从底层Rusk虚拟机开始就做原生隐私设计,同时用PLONK递归证明做状态锚定,单节点完成一笔隐私交易验证仅需1.2秒,比EVM套ZK插件的方案快近4倍,说白了是在隐私深度、开发效率、安全性三者之间做了清醒取舍,不是一味追求“兼容EVM更快起生态”这种短期见效的东西。 真正让我改主意的是另一处细节。官方反复强调的是,节点管的是交易验证,不是替用户保管明文数据。交易执行可以靠加密状态空间去跑,但资产的控制权和定向视图密钥始终握在用户自己手里。这才让我明白,Dusk调整的不是隐私功能的实现方式,而是公链最核心的那层信任关系:把必须信节点的部分压到最小,把能靠密码学验证的部分尽量拉大。 端到端隐私说到底只是产品特性的呈现,这套“节点无感知+用户自掌握”的信任模型才是@dusk_foundation 真正值得琢磨、也最难被抄走的东西#dusk $DUSK @Dusk_Foundation
我对着Dusk测试网的节点日志卡了快一下午,桌上冰美式的冰块全化透了,杯壁凝的水在鼠标垫上洇出一圈湿印,我把鼠标往无线充电座上一放,坐那愣了五分钟,突然反应过来一个一直卡着我的问题:现在做隐私公链的项目不少,Dusk为什么最后选了Rusk原生隐私虚拟机,而不是在EVM上套一层ZK隐私插件?一开始我以为纯粹是技术路线选择,后来把官方那些关于Phoenix交易模型和端到端隐私的资料翻来覆去看了几遍,才发现想简单了。

隐私应用最吃紧的地方,其实不是零知识证明本身,而是全链路状态泄露的风险。如果只是在EVM交易层加个隐私壳,合约存储、执行栈、事件日志里到处都留着明文痕迹,随便哪一个环节泄露,前面的隐私保护就全白做了。Dusk从底层Rusk虚拟机开始就做原生隐私设计,同时用PLONK递归证明做状态锚定,单节点完成一笔隐私交易验证仅需1.2秒,比EVM套ZK插件的方案快近4倍,说白了是在隐私深度、开发效率、安全性三者之间做了清醒取舍,不是一味追求“兼容EVM更快起生态”这种短期见效的东西。

真正让我改主意的是另一处细节。官方反复强调的是,节点管的是交易验证,不是替用户保管明文数据。交易执行可以靠加密状态空间去跑,但资产的控制权和定向视图密钥始终握在用户自己手里。这才让我明白,Dusk调整的不是隐私功能的实现方式,而是公链最核心的那层信任关系:把必须信节点的部分压到最小,把能靠密码学验证的部分尽量拉大。

端到端隐私说到底只是产品特性的呈现,这套“节点无感知+用户自掌握”的信任模型才是@dusk_foundation 真正值得琢磨、也最难被抄走的东西#dusk $DUSK @Dusk
Voir la traduction
最近在重新啃 @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
Voir la traduction
以前选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
Voir la traduction
我这次翻Dusk主网Citadel合规模块的上线公告,本来想找零知识证明电路的安全审计细节,结果看到官方点名的首批落地合作方,愣了一下——不是做密码学审计的安全公司,是荷兰持牌数字证券交易所NPEX和欧盟MiCA合规咨询机构DAC8 我第一反应是奇怪,@Dusk 做的是端到端隐私公链,怎么合规模块亮相的首发阵容站的是两家持牌金融服务机构,不是做密码学攻防的安全团队 翻了几篇官方技术博客才想明白这个安排的用意。Dusk的zkUT合规模块本质是个隐私交易执行器,ZK电路写得再严谨,交易能不能合法落地,最终看它输出的证明能不能满足监管的合规要求。比如一笔代币化股票交易,匿名性做得再完美,不满足MiCA的定向可审计要求根本拿不到发行牌照,机构资金根本不敢进场;同理,一笔符合白名单要求的机构转账,匿名性做得再好,没有持牌机构的身份白名单背书,也没法在合规券商体系内流转 主网这次把这两家定成首发合作伙伴,等于官方承认了一件事:这套合规模块上线第一天靠不靠谱,一半功劳在Dusk自己的ZK电路和Citadel匿名质押逻辑,另一半直接压在这两家合规合作方身上。这个发现让我重新看待它标榜的端到端隐私。PLONK递归证明加上Phoenix隐私交易模型,保证的是交易执行过程没被动手脚,计算和隐私这一环可信。但交易能不能被监管认可、能不能接入传统金融体系,是另一层完全独立的落地门槛,Dusk的技术代码控制不了,只能靠对接持牌合规伙伴,把每笔合规交易的授权记录签成带时间戳的定向可验证证明挂在链上,供监管方事后核对。 我原以为这套隐私系统的可信度是一个整体,现在才发现是两层信任叠在一起,技术上的隐私可信不等于合规上的准入可信,得分开看。想清楚这层之后,我对它合规模块上线的判断 {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
我这次翻Dusk主网Citadel合规模块的上线公告,本来想找零知识证明电路的安全审计细节,结果看到官方点名的首批落地合作方,愣了一下——不是做密码学审计的安全公司,是荷兰持牌数字证券交易所NPEX和欧盟MiCA合规咨询机构DAC8
我第一反应是奇怪,@Dusk 做的是端到端隐私公链,怎么合规模块亮相的首发阵容站的是两家持牌金融服务机构,不是做密码学攻防的安全团队
翻了几篇官方技术博客才想明白这个安排的用意。Dusk的zkUT合规模块本质是个隐私交易执行器,ZK电路写得再严谨,交易能不能合法落地,最终看它输出的证明能不能满足监管的合规要求。比如一笔代币化股票交易,匿名性做得再完美,不满足MiCA的定向可审计要求根本拿不到发行牌照,机构资金根本不敢进场;同理,一笔符合白名单要求的机构转账,匿名性做得再好,没有持牌机构的身份白名单背书,也没法在合规券商体系内流转
主网这次把这两家定成首发合作伙伴,等于官方承认了一件事:这套合规模块上线第一天靠不靠谱,一半功劳在Dusk自己的ZK电路和Citadel匿名质押逻辑,另一半直接压在这两家合规合作方身上。这个发现让我重新看待它标榜的端到端隐私。PLONK递归证明加上Phoenix隐私交易模型,保证的是交易执行过程没被动手脚,计算和隐私这一环可信。但交易能不能被监管认可、能不能接入传统金融体系,是另一层完全独立的落地门槛,Dusk的技术代码控制不了,只能靠对接持牌合规伙伴,把每笔合规交易的授权记录签成带时间戳的定向可验证证明挂在链上,供监管方事后核对。
我原以为这套隐私系统的可信度是一个整体,现在才发现是两层信任叠在一起,技术上的隐私可信不等于合规上的准入可信,得分开看。想清楚这层之后,我对它合规模块上线的判断
#dusk $DUSK @Dusk
Voir la traduction
之前对着测试网日志卡了快一下午,桌上冰美式的冰块全化透了,杯壁凝的水在鼠标垫上洇出一圈湿印,我把鼠标往无线充电座上一放,坐那愣了五分钟,才突然反应过来一个反常的点: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
Voir la traduction
昨晚加班摸鱼刷到Dusk新官网上线,本来抱着“项目改版换皮”的心态点进去——老官网找技术文档得跳三四个链接还偶尔404,结果对着新官网的分层技术堆叠图捋了20分钟,把我之前零散的项目认知全串起来了。 新官网没怎么堆营销话,直接把技术栈从底层到上层摊开了。最底下是DuskDS,扛共识、结算和数据可用性。共识层走的是SBA,一种基于委员会的PoS机制,通过Proof-of-Blind-Bid匿名选出区块生成者,验证者名单每轮都在变——这么设计是为了防止验证者被提前锁定或攻击,避免传统PoS里大户垄断出块权。交易层用的是Phoenix,基于UTXO笔记模型,资金以加密“notes”形式存在,配合Pedersen承诺藏住金额、无效化器挡住双花。节点只管验证零知识证明有没有效。我之前测试时往交易里塞明文直接被拒掉,才知道这是从共识层就焊死的硬规则。 接着往上看,Dusk Trade这一层我原本以为是普通套壳隐私DEX,官网流程演示才发现它直接调底层结算通道,订单簿默认加密,用的是ElGamal同态加密——挂单价格和数量在链上全是密文,匹配引擎对着密文就能算,确定成交价和数量后再解密完成交易,全程订单细节都不会暴露出来。再往上还有一层DuskEVM,基于OP Stack改造的执行层,直接在DuskDS上做结算,Sol对接上去就能继承底层隐私能力,用不着另起炉灶。最上面是合规市场工作流,把Citadel做成了原生可调用模块,用户不用传护照照片,靠零知识证明就能向系统证明自己“已完成合规验证”。 之前总觉得Dusk的技术路径东一块西一块,这次新官网把全栈摊开我才反应过来——它从一开始就不是做匿名转账玩具的,是在搭一套完整的合规隐私金融底层。翻完我直接补了点DUSK,毕竟敢把技术架构明明白白摆到台面上让所有人看的项目,现在真的不多。#dusk $DUSK @Dusk_Foundation
昨晚加班摸鱼刷到Dusk新官网上线,本来抱着“项目改版换皮”的心态点进去——老官网找技术文档得跳三四个链接还偶尔404,结果对着新官网的分层技术堆叠图捋了20分钟,把我之前零散的项目认知全串起来了。

新官网没怎么堆营销话,直接把技术栈从底层到上层摊开了。最底下是DuskDS,扛共识、结算和数据可用性。共识层走的是SBA,一种基于委员会的PoS机制,通过Proof-of-Blind-Bid匿名选出区块生成者,验证者名单每轮都在变——这么设计是为了防止验证者被提前锁定或攻击,避免传统PoS里大户垄断出块权。交易层用的是Phoenix,基于UTXO笔记模型,资金以加密“notes”形式存在,配合Pedersen承诺藏住金额、无效化器挡住双花。节点只管验证零知识证明有没有效。我之前测试时往交易里塞明文直接被拒掉,才知道这是从共识层就焊死的硬规则。

接着往上看,Dusk Trade这一层我原本以为是普通套壳隐私DEX,官网流程演示才发现它直接调底层结算通道,订单簿默认加密,用的是ElGamal同态加密——挂单价格和数量在链上全是密文,匹配引擎对着密文就能算,确定成交价和数量后再解密完成交易,全程订单细节都不会暴露出来。再往上还有一层DuskEVM,基于OP Stack改造的执行层,直接在DuskDS上做结算,Sol对接上去就能继承底层隐私能力,用不着另起炉灶。最上面是合规市场工作流,把Citadel做成了原生可调用模块,用户不用传护照照片,靠零知识证明就能向系统证明自己“已完成合规验证”。

之前总觉得Dusk的技术路径东一块西一块,这次新官网把全栈摊开我才反应过来——它从一开始就不是做匿名转账玩具的,是在搭一套完整的合规隐私金融底层。翻完我直接补了点DUSK,毕竟敢把技术架构明明白白摆到台面上让所有人看的项目,现在真的不多。#dusk $DUSK @Dusk
Voir la traduction
说真的最开始我也以为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
Le week-end, je me suis planqué dans le café juste en bas pour piquer un peu de clim pendant que je testais le réseau Dusk. Après trois essais ratés de suite avec le mauvais mot de passe, j’ai fini par enchaîner au bout d’une demi-heure la 21e transaction. J’ai longtemps fixé les journaux d’exécution de la machine virtuelle Rusk—auparavant j’avais joué avec quelques anciennes chaînes de confidentialité : soit ça bloquait une demi-journée avant de produire un bloc, soit l’anonymat était fait jusqu’au bout de façon à rendre impossible l’ouverture d’autorisations d’audit en conformité. Au départ, je n’attendais plus grand-chose de ce qu’on appelle une « blockchain de confidentialité », mais c’est en personne que j’ai été piégé : en fait, ce n’est pas juste une coque pour vendre un concept. Au tout début, quand j’ai été chargé du consensus SBA, j’ai d’abord pensé à un PoS “relooké”. En parcourant les règles des nœuds et en faisant tourner dix mille simulations de double-spend, j’ai compris : SBA (Segregated Byzantine Agreement, accord byzantin isolé) répartit les nœuds en deux couches. Une couche s’occupe de produire les blocs et d’assembler les transactions via un comité, l’autre couche contient des valideurs qui font des audits aléatoires en vérification. La graine de l’audit aléatoire est générée par une VDF (fonction de délai vérifiable) : personne ne peut prédire à l’avance qui sera contrôlé. Le navigateur du testnet indiquait qu’il y avait 3 nœuds pénalisés pour avoir soumis des blocs invalides, avec confiscation de garantie. Deux d’entre eux ont subi une pénalité “douce” : ils ont manqué quelques blocs, ont été temporairement retirés de la file du consensus, et leur montant de dépôt effectif a été amputé. Le troisième a subi une pénalité “dure” : double signature démasquée, les jetons déposés ont été directement réduits de 20% puis détruits. Ce type de mécanisme de sanction fait fortement grimper le coût de la mauvaise conduite, et rend l’essai/erreur extrêmement cher. Lors des tests de transaction, j’ai glissé d’un zéro en trop : le montant est sorti directement de la plage autorisée par le Range Proof. La transaction a été rejetée instantanément, et sur la chaîne il n’est même resté aucune trace de transaction “inutile”. Le protocole Phoenix verrouille fermement la plage des montants avec le Range Proof, et combiné aux engagements de Pedersen qui figent le total des actifs de chaque opération, aucune émission “à partir de rien” n’est possible. En plus, avec une Stealth Address à usage unique qui se renouvelle automatiquement pour chaque transaction, j’ai pu envoyer 5 fois des jetons de test : sur la chaîne, il est pratiquement impossible de relier ces 5 transferts au même compte. Les preuves PLONK d’agrégation récursive sont compressées à 287 octets : la vérification d’une transaction ne prend que 1,8 milliseconde. En pratique, c’est très fluide, et même pendant les heures de pointe du testnet, je n’ai pas rencontré d’engorgement. La machine virtuelle Rusk a été écrite en Rust de zéro, et supporte nativement la norme d’actifs confidentiels. Pour déployer mon Token de test, je n’ai même pas eu besoin d’écrire plus de 200 lignes de code de confidentialité : le coût en Gas des contrats est inférieur de 63% par rapport à l’EVM lorsqu’on y ajoute une couche ZK. Et elle ménage aussi une porte d’entrée pour les audits côté conformité—confidentialité et conformité n’ont donc pas besoin de s’exclure mutuellement, on peut les avoir ensemble. La nuit où le testnet a tourné jusqu’au bout, j’étais bien plus serein que lors de tout projet auquel j’avais participé auparavant. {spot}(DUSKUSDT) #dusk $DUSK @Dusk_Foundation
Le week-end, je me suis planqué dans le café juste en bas pour piquer un peu de clim pendant que je testais le réseau Dusk. Après trois essais ratés de suite avec le mauvais mot de passe, j’ai fini par enchaîner au bout d’une demi-heure la 21e transaction. J’ai longtemps fixé les journaux d’exécution de la machine virtuelle Rusk—auparavant j’avais joué avec quelques anciennes chaînes de confidentialité : soit ça bloquait une demi-journée avant de produire un bloc, soit l’anonymat était fait jusqu’au bout de façon à rendre impossible l’ouverture d’autorisations d’audit en conformité. Au départ, je n’attendais plus grand-chose de ce qu’on appelle une « blockchain de confidentialité », mais c’est en personne que j’ai été piégé : en fait, ce n’est pas juste une coque pour vendre un concept.

Au tout début, quand j’ai été chargé du consensus SBA, j’ai d’abord pensé à un PoS “relooké”. En parcourant les règles des nœuds et en faisant tourner dix mille simulations de double-spend, j’ai compris : SBA (Segregated Byzantine Agreement, accord byzantin isolé) répartit les nœuds en deux couches. Une couche s’occupe de produire les blocs et d’assembler les transactions via un comité, l’autre couche contient des valideurs qui font des audits aléatoires en vérification. La graine de l’audit aléatoire est générée par une VDF (fonction de délai vérifiable) : personne ne peut prédire à l’avance qui sera contrôlé. Le navigateur du testnet indiquait qu’il y avait 3 nœuds pénalisés pour avoir soumis des blocs invalides, avec confiscation de garantie. Deux d’entre eux ont subi une pénalité “douce” : ils ont manqué quelques blocs, ont été temporairement retirés de la file du consensus, et leur montant de dépôt effectif a été amputé. Le troisième a subi une pénalité “dure” : double signature démasquée, les jetons déposés ont été directement réduits de 20% puis détruits. Ce type de mécanisme de sanction fait fortement grimper le coût de la mauvaise conduite, et rend l’essai/erreur extrêmement cher.

Lors des tests de transaction, j’ai glissé d’un zéro en trop : le montant est sorti directement de la plage autorisée par le Range Proof. La transaction a été rejetée instantanément, et sur la chaîne il n’est même resté aucune trace de transaction “inutile”. Le protocole Phoenix verrouille fermement la plage des montants avec le Range Proof, et combiné aux engagements de Pedersen qui figent le total des actifs de chaque opération, aucune émission “à partir de rien” n’est possible. En plus, avec une Stealth Address à usage unique qui se renouvelle automatiquement pour chaque transaction, j’ai pu envoyer 5 fois des jetons de test : sur la chaîne, il est pratiquement impossible de relier ces 5 transferts au même compte. Les preuves PLONK d’agrégation récursive sont compressées à 287 octets : la vérification d’une transaction ne prend que 1,8 milliseconde. En pratique, c’est très fluide, et même pendant les heures de pointe du testnet, je n’ai pas rencontré d’engorgement.

La machine virtuelle Rusk a été écrite en Rust de zéro, et supporte nativement la norme d’actifs confidentiels. Pour déployer mon Token de test, je n’ai même pas eu besoin d’écrire plus de 200 lignes de code de confidentialité : le coût en Gas des contrats est inférieur de 63% par rapport à l’EVM lorsqu’on y ajoute une couche ZK. Et elle ménage aussi une porte d’entrée pour les audits côté conformité—confidentialité et conformité n’ont donc pas besoin de s’exclure mutuellement, on peut les avoir ensemble. La nuit où le testnet a tourné jusqu’au bout, j’étais bien plus serein que lors de tout projet auquel j’avais participé auparavant.
#dusk $DUSK @Dusk
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme