小饼的撸毛日记

朋友跑 Dusk 验证者，问我他节点连续错过出块被罚了，这算不算恶意。我一开始觉得罚没就是罚没，Cosmos 那套双签直接关小黑屋，没什么好辩的。

后来翻 Dusk 的罚没机制，发现它分两种。Soft Slashing，软惩罚，专门管非恶意过失，比如节点该出块时掉线、没在窗口期内广播，不涉及作恶，就是运维出问题。惩罚是每次连续违规扣 N 乘 10% 的质押权益，N 是连续违规次数，同时把节点从共识里踢出去 N 个 epoch，epoch 是 Dusk 的共识周期，每轮结束验证者集合轮换一次。罚掉的 DUSK 不销毁，从活跃质押里划走，节点能自己取回。

Hard Slashing，硬惩罚，管恶意行为。生成无效区块扣 10% 质押并销毁，双重投票或双重出块扣 20% 并销毁。销毁是真的没了，不是锁一阵再还。

我没想通为什么要分两种。后来看文档里关于可追责性的部分才明白。节点只是网络波动错过出块，你就重罚，验证者会把节点放最贵的云上，运维成本高，去中心化反而变差。Soft Slashing 的作用是把不靠谱的节点从活跃集合里挤出去，给机会恢复，每次罚一点，不会让诚实运维的人破产

真正让我改变判断的是 N 的设定。连续违规越多，扣的越多，踢出去时间越长。第一次掉线扣 10% 移除 1 个 epoch，第二次 20% 移除 2 个 epoch，指数级压力，节点要么恢复稳定，要么自动离场。Hard Slashing 留给明确作恶，一次销毁，没有恢复窗口

拿 Polkadot 比。Polkadot 的 Slashing 也分级，但惩罚比例更细，从 0.1% 到 100% 都有，罚款分给举报者。Dusk 这套更简单，要么过失要么恶意，比例固定，销毁不奖励举报。好处是验证者能预测犯错代价，不会因复杂规则不敢跑节点

朋友听完说这次 Soft Slashing 认了，家里网络掉了半小时。我也明白 Dusk 为什么把机制分这么清。没有分级惩罚，诚实节点和作恶节点一视同仁#dusk $DUSK @Dusk

我那天翻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

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

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

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

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

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

研究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

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

Vừa bắt đầu nghiên cứu cơ chế đồng thuận Dusk, tôi nhìn mãi bản whitepaper mà không hiểu “tính cuối cùng tất định” là cái gì. Không còn cách nào khác, tôi đành cặm cụi vẽ lên giấy một bảng so sánh ba mốc thời gian.

Ethereum sử dụng tính cuối cùng theo xác suất với Gasper: để được coi là gần như an toàn, khối cần xếp chồng thêm vài epoch. Tower BFT của Solana cũng phải mất vài chục giây mới xác nhận được. Còn Succinct Attestation của Dusk thì sao? Chỉ cần một khối đã được chấp thuận, đó là loại cuối cùng “cứng”, “tất định” và sẽ không quay đầu lại.

Lúc đó tôi nhìn ba đường trên giấy rất lâu. Chênh lệch vài giây trong giao dịch mật mã có thể gần như chẳng cảm nhận được—nhưng chờ thêm một chút thì cũng được. Tuy nhiên trong kịch bản thanh toán chứng khoán, vài giây ấy chính là “chốt an toàn cuối cùng” cho tài sản cỡ hàng trăm triệu, thậm chí hàng tỷ. Bạn bán một cổ phiếu trên sàn, đến T+2 mới được thanh toán. Trong khoảng thời gian hai ngày đó, rốt cuộc tài sản thuộc về ai? Nếu tại thời điểm thanh toán mà chuỗi vẫn có thể bị rollback, thì ai dám đưa “tài sản thật” lên đó? Với giao dịch lẻ thì nói “không thể rollback” là đủ, nhưng với thanh toán của tổ chức thì không được; không thể chấp nhận cụm “không quá có khả năng” ở cấp độ pháp lý và tuân thủ.

Sau đó tôi lật tài liệu chính thức mới hiểu Succinct Attestation vận hành như thế nào. Xem xong đoạn đó, tôi mới thở phào—những bối rối trước đây cuối cùng cũng có câu trả lời. Đây là một giao thức đồng thuận PoS dựa trên ủy ban, không cần cấp phép. Hệ thống chọn ngẫu nhiên một nhóm node gọi là Provisioner để đề xuất khối, một nhóm node khác chịu trách nhiệm xác minh, và cuối cùng một ủy ban xác nhận kết quả xác minh rồi chính thức phê duyệt khối. Khi khối đã đi qua bước ratification, nó sẽ đạt tính cuối cùng tất định; trong điều kiện vận hành bình thường sẽ không xảy ra tình trạng tái tổ hợp hướng tới người dùng.

Mainnet của Dusk chính thức khởi động ngày 7/1/2026, mỗi giây có thể xử lý hơn 20000 giao dịch. Chu kỳ phát triển sáu năm cuối cùng cũng đưa dự án từ testnet sang giai đoạn có thể chạy tài sản thật. Trước đây, hiểu biết của tôi về cơ chế đồng thuận chỉ là: ai tạo khối thì người đó nhận phần thưởng, và tôi nghĩ thứ này chẳng liên quan gì đến người dùng phổ thông. Nhưng Dusk buộc tôi nhìn theo một góc khác: việc lựa chọn cơ chế đồng thuận về bản chất là đang trả lời một câu hỏi căn bản nhất—số tiền bạn cho vào đó, liệu có thật sự “đếm được” không? Succinct Attestation trả lời là có, và không cần thêm cụm ba chữ “xác suất”. #dusk $DUSK @Dusk

Tuần trước, tôi đã hoàn tất một khoản vay thế chấp ETH trên mạng test TermMax. Tôi mở ví và liếc qua số dư thì thấy có thêm một thứ: một NFT. Tôi chẳng hề nhớ mình đã nhận món này. Lúc đó đầu óc rối bời, phản ứng đầu tiên là sợ ví bị nhiễm virus hoặc mạng test đã “airdrop” cho tôi thứ rác rưởi gì đó. Tôi refresh ba lần mà nó vẫn còn. Nói thật là tôi bắt đầu thấy hoảng: đừng để ETH thế chấp của tôi bị mất là được.

Sau đó tôi đi lật tài liệu chính thức, lục gần nửa tiếng, thậm chí đọc hết cả những bài thảo luận từ cộng đồng lúc ban đầu, cuối cùng mới hiểu ra đó chính là GT mà trước đây tôi không mấy để ý. Bạn biết thứ logic cốt lõi của món này là gì không? Bạn vay một khoản tiền, giao thức sẽ trực tiếp mint cho bạn một NFT; bên trong ghi lại bạn đã thế chấp bao nhiêu tài sản, đã mượn bao nhiêu FT và các tham số MLTV tương ứng với thời hạn nào. Mỗi lần vay lại là một NFT độc lập.

Trước đây tôi từng dính kiểu “thiệt hại tương tự” trên một số giao thức lãi suất cố định khác. Rõ ràng tôi đã trả được một phần rồi, nhưng hệ thống vẫn hiển thị tỷ lệ thế chấp ban đầu, làm tôi tưởng rằng mình lại nợ thêm một lần nữa. Sau đó tôi phải đi hỏi chăm sóc khách hàng rất lâu mới phát hiện là do độ trễ đồng bộ trạng thái ở giao diện. Nhưng cái cảm giác lo “mình rốt cuộc đã trả hết chưa” đó, tôi thật sự không muốn trải qua lần thứ hai.

Sau này tôi suy nghĩ thêm thì thấy GT thú vị thật sự, không chỉ dừng ở đó. Bạn có thể hiểu GT như việc vị thế đòn bẩy của bạn được “đóng gói” thành một món đồ có thể giao dịch. Không muốn chờ đến kỳ hạn thì bán luôn là xong; nếu có người mua lại thì nợ trong vị thế và tài sản thế chấp sẽ được chuyển sang cùng một lúc. Cái này hoàn toàn không giống vay mượn truyền thống. Trong vay mượn truyền thống, vị thế của bạn là một chuỗi trạng thái trong hợp đồng—muốn chuyển cho người khác thì không được; chỉ có thể tự đóng vị thế, rút tài sản thế chấp, rồi bên kia mới mở vị thế lại, làm đủ thứ mất công. Còn GT thì đóng gói toàn bộ vị thế thành một NFT: muốn chuyển thì chuyển, muốn bán thì bán. Một vị thế là một NFT, rõ ràng rành mạch, không can thiệp lẫn nhau.

Tôi vẫn luôn nghĩ GT chỉ là một chứng nhận quyền lợi thông thường, cho đến khi mới hiểu được giá trị thực sự của nó: toàn bộ quyền sở hữu đối với khoản vay của bạn được trao trọn vẹn cho chính người dùng. Tôi định sau khi lên mainnet sẽ mở thêm vài khoản vị thế với các kỳ hạn khác nhau, rồi theo dõi từng khoản xem GT thể hiện toàn bộ quy trình ra sao khi đến lúc tất toán. #termmax @TermMax

我之前看隐私公链时，一直认为零知识证明已经足够处理大部分加密需求，只要把交易参数写进证明，执行交给ZK虚拟机即可。但研究Dusk的Phoenix交易模型后，我改变了这个看法。真正困难的不是生成一笔匿名交易，而是在复杂环境下持续维护那些不断变化的隐私权限规则。

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

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

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

在我看来，Dusk真正需要验证的不是ZK隐私概念是否成立，而是这套双模式隐私系统能不能被大量开发者长期使用。未来我会持续观察测试网上的跨层交易数据，开发者接入情况，以及真实应用中的隐私权限更新频率。一个问题值得思考，如果未来链上隐私场景越来越多，我们需要的究竟是更强的加密能力，还是更好的隐私权限管理方式。
#dusk $DUSK @Dusk

@TermMaxFi 之前在Aave存30天固定利率碰上参数硬编码改不动亏了小几百收益，所以我对固定利率产品的底层假设特别敏感，翻TermMax白皮书时看到有句话团队一直拿来当核心叙事，我越看越觉得是藏在暗处的阿喀琉斯之踵：“分档到期AMM，是当前链上实现固定利率的最优路径。”逻辑起点很直白——浮动利率做不了长期定价，所以用分档资金池锁死到期收益。

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

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

我的态度：分档AMM是当前约束下的局部最优解，别当永恒真理。底层借贷协议在进化，今天卡住长期固定利率的坎，明天一次版本迭代就跨过去。TermMax能不能从“固定利率产品商”转型成“链上利率基础设施层#termmax @TermMax

Gần đây tôi đã thử nghiệm song song nhiều tài khoản đối với các luồng giao dịch trên Dusk. Ban đầu tôi cứ nghĩ rằng chuỗi ẩn danh chủ yếu xử lý việc mã hoá và che giấu danh tính. Sau đó tôi chạy chung các giao dịch từ tài khoản EVM minh bạch và tài khoản ZK riêng tư, mới thấy rằng rắc rối thật sự không nằm ở cách mã hoá, mà ở chỗ: khi hai giao dịch “hợp lệ” đồng thời được đưa lên chuỗi, hệ thống phải làm thế nào để thực hiện kiểm tra mà không làm lộ nội dung bản rõ. Trước đây tôi từng nghĩ rằng mạng riêng tư chỉ cần chứng minh là đạt là được; nhưng giờ tôi ngày càng thấy rằng xử lý xung đột giữa các giao dịch song song mới là bài toán khó cốt lõi cho triển khai lâu dài.

Điều này giống như hai làn đường song song trong khu thương mại. Nhìn riêng từng làn thì quy tắc thông hành đều ổn. Nhưng nếu các quy tắc đổi làn giữa hai làn kề nhau không nhất quán, cả con đường sẽ bị ùn tắc, thậm chí gây tai nạn. Mạng giao dịch riêng tư cũng tương tự: việc một giao dịch ZK đơn lẻ có chứng minh hợp lệ không đồng nghĩa rằng khi nhiều giao dịch được nộp song song thì trạng thái trên chuỗi vẫn có thể giữ nhất quán.

Dusk kết hợp mô hình Phoenix UTXO ẩn danh, lớp EVM minh bạch Moonlight, mô-đun chứng minh tính phí Citadel và cơ chế tiết lộ có định hướng VEP. Về bản chất, đây là cách cho phép người dùng tự do lựa chọn mức độ riêng tư của giao dịch. Lợi ích rất rõ ràng: người dùng phổ thông có thể dùng tài khoản ẩn danh để bảo vệ dấu vết tài sản, còn người dùng tổ chức có thể dùng tài khoản minh bạch để thực hiện thanh toán tuân thủ, không bị giới hạn bởi một chế độ ẩn danh đơn nhất. Nhưng vấn đề cũng xuất hiện: khi một giao dịch riêng tư cần gọi một địa chỉ hợp đồng minh bạch, trong khi một giao dịch minh bạch khác lại cần đọc số dư từ tài khoản riêng tư, thì nút phải đồng bộ trạng thái như thế nào mà không làm lộ bản rõ? Trước đây nhiều chuỗi ẩn danh không gặp vấn đề này, vì hoặc là hoàn toàn ẩn danh, hoặc là hoàn toàn minh bạch—không có tình huống song song hai chế độ.

Những Trade-off mà tôi đang thấy hiện rất rõ ràng. Khi tăng tính linh hoạt về quyền riêng tư, độ phức tạp của kiểm tra trạng thái sẽ tăng; số lượng tài khoản hai chế độ càng nhiều thì chi phí tạo chứng minh ZK càng cao; khi giao dịch xuyên lớp diễn ra thường xuyên, ranh giới giữa định lượng Gas và truy vết kiểm toán cũng sẽ trở nên mờ nhạt. Độ trễ giao dịch xuyên lớp, tỷ lệ xác minh chứng minh thất bại, thời gian kiểm tra theo tiết lộ có định hướng—những chỉ số này có thể phản ánh mức độ trưởng thành để triển khai của các chuỗi riêng tư công cộng rõ hơn cả TPS.

Trong tương lai, tôi sẽ tiếp tục theo dõi dữ liệu giao dịch xuyên lớp trên testnet, các bản cập nhật chính thức về biên bản sửa xung đột, và cách mà các nút xử lý giao dịch song song hai chế độ. #dusk $DUSK @Dusk

Vừa kết thúc phần tương tác thử nghiệm TermMax 7 ngày Tái tạm (tạm dịch: 7 ngày), đa số mọi người khi bàn về lãi suất cố định trên chuỗi chỉ quan tâm là lợi suất có cao không; rất ít người dám nhắc đến: việc khớp lệnh sai, vấn đề thanh toán/cấp vốn khi đáo hạn gặp sự cố—ai sẽ là người đứng ra gánh trách nhiệm, người gây lỗi phải chịu cái giá gì. Vấn đề này trong thị trường thu nhập cố định truyền thống thường gặp, nhưng trên chuỗi thì lại rất hiếm khi có một giao thức trả lời thẳng thắn. Khi đối chiếu @TermMaxFi từ bản testnet/mainnet tới lớp này, tôi mới thấy đây mới là phần “đáng gọi là có công” thật sự, và nhân tiện cũng bổ sung/đính chính chỗ trước đó tôi diễn đạt chưa chính xác.

Với cùng một lệnh lãi suất cố định, phải nhờ cơ chế kiểm tra kép trên chuỗi—Fixed-Term TimeLock Module và một oracle độc lập—đảm bảo khớp lệnh hoàn tất mới ghi nhận chứng cứ lên blockchain. Nguyên văn phía dự án viết rằng cơ chế kiểm tra toàn bộ theo chuỗi này sẽ được xem là “đầy đủ” khi đi qua hoàn toàn giai đoạn public test (công khai). Ở giai đoạn hiện tại, hệ thống vẫn đang từng bước bao phủ tất cả các “pool” theo kỳ hạn; không phải ngày đầu上线主网 đã mở toàn lượng. Tiền ký quỹ của market maker được đặt trong pool “isolation guarantee” do giao thức cách ly quản lý. Tôi đã test: giai đoạn có thể phát sinh tranh chấp là 24 giờ. Nếu sau khi lệnh khớp mà kẻ xấu cố tình rút hủy lệnh (malicious cancel) hoặc cố ý báo lãi suất giả để gây nhiễu thị trường, và bị các node trọng tài trên chuỗi thách thức thành công, thì khoản ký quỹ này sẽ bị phạt tịch thu trực tiếp. Đây gọi là “phạt vi phạm tịch thu”—người làm điều sai phải trả giá bằng tiền thật, không thể lấy lại.

Lần trước tôi viết $TMX và cả hệ an ninh này còn quá khái quát, dễ khiến người ta tưởng rằng market maker ký quỹ chính là $TMX, nhưng thật ra không phải một chuyện. Trong tài liệu công bố token chính thức (tôi xem phần phân bổ token ở trang 17), vai trò của TMX ở hiện tại gồm bốn mảng: (1) phần thưởng đào mining cho người cung cấp thanh khoản, (2) phí giao thức khi tạo và treo lệnh, (3) TMX ký quỹ mà chính market maker dùng khi cung cấp dịch vụ, và (4) quyền biểu quyết quản trị đối với tham số lãi suất nhận được sau khi stake. Việc biến TMX thành “đơn vị phí gốc” và nền tảng staking của toàn mạng thì theo tài liệu chính thức phải chờ phiên bản V2 đưa các “cross-chain time pools” chạy chính thức mới xem như triển khai hoàn toàn—hiện tại vẫn chưa tới bước đó.

Nhìn hai mốc thời gian cùng lúc: vòng khép kín cho lãi suất cố định đầy đủ của dự án đang được lắp ráp theo từng giai đoạn. Hiện tại $TMX thiên về quản trị và ưu đãi giai đoạn sớm; còn “gánh nặng” bảo đảm an toàn thanh toán/cấp vốn của toàn mạng thì hiện đang đặt ở bên hợp đồng isolation time lock. #termmax @TermMax

Tôi ngồi “kẹt” cả một buổi chiều trước nhật ký của các node trên testnet Dusk. Những viên đá trong ly ice Americano trên bàn cũng tan hết. Nước ngưng tụ bám trên thành cốc chảy lan ra, thấm thành một vệt ướt trên miếng lót chuột. Tôi chỉ việc đặt chuột lên đế sạc không dây, rồi ngồi ngẩn năm phút, cho đến khi chợt nhận ra một câu hỏi mà trước giờ vẫn cứ mắc kẹt trong đầu: Hiện có khá nhiều dự án làm blockchain quyền riêng tư, vậy tại sao Dusk cuối cùng lại chọn Rusk native privacy virtual machine, thay vì “bọc” thêm một plugin quyền riêng tư dạng ZK trên EVM? Ban đầu tôi cứ nghĩ đơn giản là do họ chọn lộ trình kỹ thuật. Nhưng rồi tôi lật đi lật lại nhiều lần các tài liệu chính thức về mô hình giao dịch Phoenix và quyền riêng tư end-to-end, cuối cùng mới nhận ra mình đã nghĩ đơn giản quá đà.

Điểm khó khăn nhất của ứng dụng quyền riêng tư thực ra không nằm ở bản thân zero-knowledge proof, mà ở rủi ro rò rỉ trạng thái trên toàn chuỗi. Nếu chỉ thêm một “lớp vỏ” quyền riêng tư ở tầng giao dịch EVM, thì trong lưu trữ hợp đồng, ngăn xếp thực thi và cả nhật ký sự kiện vẫn để lại dấu vết bản rõ ở khắp nơi—chỉ cần rò rỉ ở bất kỳ khâu nào, thì phần bảo vệ quyền riêng tư ở phía trước cũng coi như làm vô ích. Dusk bắt đầu từ thiết kế quyền riêng tư ở tầng ảo hóa Rusk bên dưới, đồng thời dùng chứng minh đệ quy PLONK để “neo” trạng thái. Việc một node đơn lẻ hoàn tất xác thực một giao dịch quyền riêng tư chỉ mất 1,2 giây, nhanh hơn gần 4 lần so với phương án dùng ZK plugin bọc ngoài EVM. Nói thẳng ra là họ tỉnh táo cân bằng giữa độ sâu quyền riêng tư, hiệu suất phát triển và an toàn—không phải cứ chạy theo thứ hiệu quả ngắn hạn kiểu “tương thích EVM để dựng hệ sinh thái nhanh hơn”.

Điều thực sự khiến tôi đổi ý nằm ở một chi tiết khác. Tài liệu chính thức lặp đi lặp lại rằng: node không phải là nơi “giữ” dữ liệu bản rõ thay người dùng, mà chỉ phụ trách xác thực giao dịch. Việc thực thi giao dịch có thể chạy dựa trên không gian trạng thái mã hóa, nhưng quyền kiểm soát tài sản và khóa cho các “góc nhìn có định hướng” luôn nằm trong tay chính người dùng. Chính điều này giúp tôi hiểu rằng Dusk không chỉ thay đổi cách triển khai tính năng quyền riêng tư, mà là thay đổi mối quan hệ tin cậy cốt lõi nhất của blockchain công khai: thu hẹp phần buộc phải tin vào node ở mức nhỏ nhất, và mở rộng tối đa phần có thể được xác minh nhờ mật mã.

Quyền riêng tư end-to-end rốt cuộc chỉ là cách thể hiện của một tính năng sản phẩm. Mô hình niềm tin “node không cần biết (không cảm nhận) + người dùng tự nắm quyền” này mới là thứ mà @dusk_foundation thực sự đáng để suy ngẫm và cũng khó bị sao chép nhất #dusk $DUSK @Dusk

Dạo này mình lại bắt đầu đọc lại cơ chế AMM lãi suất cố định của @TermMaxFi, và mấy ngày nay mình bị kẹt bởi một câu hỏi khá ngớ ngẩn: DeFi muốn bước vào các bối cảnh tài chính phổ biến hơn thì rốt cuộc thứ còn thiếu là thêm nhiều loại sản phẩm cho vay, hay là một cách định giá không bắt người dùng phải gánh rủi ro biến động lãi suất? Mình đã đối chiếu vài lần phần 4 của whitepaper và dữ liệu giao dịch thực tế trên trang web, và mình nghiêng về việc TermMax không tập trung vào vấn đề “lãi suất cao hay thấp” bề nổi—mà cốt lõi là làm sao để chi phí vốn của các khoản vay mượn trên chuỗi trở nên có thể dự đoán được. #TermMax

Trước đây, trong DeFi, các khoản vay mượn chủ yếu đi theo mô hình lãi suất thả nổi: khi vay thì chỉ có thể nhìn APY hiện tại, hoàn toàn không biết sau ba ngày lãi suất có bị một lệnh vay lớn kéo lên “quá trời” hay không. Dù là Compound, Aave hay Morpho, hiệu quả sử dụng vốn đúng là được cải thiện; nhưng cái giá là mỗi người tham gia đều phải chịu sự không chắc chắn do biến động lãi suất. Công cụ vay mượn thì nhiều hơn, nhưng sự ổn định của chi phí vốn—yếu tố quan trọng nhất—lại trở thành một biến số có thể thay đổi bất cứ lúc nào. TermMax làm mình cảm thấy khác ở chỗ: nó chẳng hề “vá víu” gì trên mô hình lãi suất thả nổi cả. Theo cách họ nói, mỗi ngày đáo hạn tương ứng với một đường cong lãi suất cố định độc lập; nhờ các cơ chế như phân lớp đáo hạn AMM tạo lập thị trường và định giá theo phân tầng thanh khoản, họ sẽ “khóa cứng” chi phí vay mượn cho các kỳ hạn khác nhau ngay từ đầu. Cái logic định giá về cơ bản không đổi từ đầu đến cuối; thứ thay đổi là mức độ người dùng có thể dự đoán được chi phí vốn trong tương lai.

Mình nghĩ điều đáng “soi” thật sự nằm ở lớp định giá này. Người dùng không cần phải đoán xem liệu ở block tiếp theo có khoản vay lớn nào làm lãi suất bắn vọt hay không; cũng không cần phải đánh cược rằng giao thức có đột nhiên điều chỉnh tham số để đổi mô hình lãi suất hay không. TermMax dựa vào cơ chế tự động làm thị trường theo phân kỳ đáo hạn, rồi chồng thêm một lớp là quỹ dự trữ từ tích lũy phí phạt thanh lý—từ đó biến lãi suất của các kỳ hạn khác nhau thành “chi phí cố định” mà người dùng có thể khóa ngay. Về các tham số như $TMX độ sâu thanh khoản, tỷ lệ sai lệch lãi suất, quỹ dự phòng rủi ro—nói thật là vẫn phải có thời gian để kiểm chứng, chưa thể kết luận ngay bây giờ. Nhưng TermMax ít nhất đã nhắc mình một điều: sau này DeFi vay mượn muốn kết nối với dòng vốn chủ đạo, có lẽ không nhất thiết phải bê nguyên cách làm lãi suất thả nổi; cũng có thể, trong khi vẫn giữ mô hình an toàn phi tập trung trên chuỗi, giúp người dùng nhận được chi phí vốn xác định trước. #termmax @TermMax

Trước đây tôi chọn các giao thức DeFi, tiêu chuẩn của tôi rất đơn giản và thẳng thừng: TVL càng lớn càng an toàn.

Logic đó đã giúp tôi trong suốt vài năm. Aave, Morpho và những giao thức đầu ngành khác, TVL có khi lên tới hàng chục, hàng trăm tỷ—tiền đều nằm trong đó, có chuyện gì được chứ? Vì vậy khi TermMax TVL “chỉ có” 90 triệu, tôi thật sự không thèm để ý.

Thay đổi suy nghĩ của tôi đến từ một lần trò chuyện.

Bạn tôi hỏi: “Khoản USDC của cậu định để bao lâu?” Tôi nói là chờ cơ hội, không chắc. “Thế trong khoảng thời gian này, chi phí vốn của cậu là bao nhiêu?” Tôi sững lại—gửi trong Aave để ăn lãi suất thả nổi, hôm nay 4% ngày mai có thể là 3%, tôi căn bản không trả lời được câu “chi phí là bao nhiêu”. Tôi đặt điện thoại lên bàn, không kịp nói gì thêm; phần sau của bữa ăn hôm đó tôi hơi mất tập trung.

Về nhà, tôi nghiên cứu nghiêm túc TermMax và mới nhận ra: vấn đề mà nó giải quyết hoàn toàn khác với Aave.

Cốt lõi của TermMax là token hóa lãi suất cố định. Nợ được chia thành FT và XT: FT là trái phiếu nợ không lãi, trước khi đến hạn có thể bán với giá chiết khấu; XT là token quyền hưởng lợi, theo thời gian đến hạn thì giá trị tiến dần về 0. Mọi lúc luôn có hệ thức: 1 FT + 1 XT = 1 token nợ—đẳng thức bất biến này đảm bảo việc định giá của thị trường lãi suất cố định là minh bạch. GT là token đòn bẩy theo chuẩn ERC-721, đại diện cho một vị thế cho vay độc lập. Bên vay khóa tài sản thế chấp vào GT, rồi dựa trên tỷ lệ giá trị khoản vay tối đa theo thiết lập thị trường (MLTV) để đúc ra một lượng FT tương ứng. Nếu giá trị tài sản thế chấp giảm khiến tỷ lệ LTV vượt quá MLTV, vị thế sẽ bị thanh lý.

Quan hệ giữa FT và XT, lần đầu lật qua tôi không thấy gì đặc biệt; lần thứ hai mới nhận ra câu đó—sau khi làm rõ, cả logic liền thông suốt.

Cơ chế này giải quyết một vấn đề mà Aave luôn không giải quyết được—tính chắc chắn của chi phí vốn.

Aave giống như một ngân hàng trên chuỗi, tập trung vào hiệu quả luân chuyển dòng tiền. TermMax cho phép hai bên giao dịch ngay từ đầu thỏa thuận một mức lãi suất cố định và thời hạn cố định. Tôi bắt đầu tính toán: nếu nửa năm trước tôi đã khóa khoản tiền nhàn rỗi đó bằng TermMax với lãi suất cố định, tôi không chỉ biết trước đến hạn sẽ nhận được bao nhiêu, mà trong lúc chờ lệnh theo mức giá giới hạn, tiền cũng không bị “đắp chiếu”—nó sẽ tự động vào kho quỹ Morpho để kiếm lãi thả nổi, và khi khớp lệnh thành công thì chuyển đổi liền mạch sang lãi suất cố định.

TVL là chỉ số quy mô, còn lãi suất cố định là chỉ số tính chắc chắn. #termmax @TermMax

Tôi công bố thông báo ra mắt lên mainnet của Dusk cho khối đồng bộ theo chuẩn Citadel quy mô, lần này vốn định tìm chi tiết về việc kiểm toán an toàn cho mạch zero-knowledge proof, nào ngờ khi thấy danh sách chính thức gọi tên các đối tác hợp tác triển khai đầu tiên, tôi đứng hình một chút—không phải công ty an ninh chuyên kiểm toán mật mã, mà là sàn giao dịch chứng khoán số được cấp phép tại Hà Lan NPEX và tổ chức tư vấn tuân thủ MiCA của EU DAC8
Phản ứng đầu tiên của tôi là thấy kỳ lạ: @Dusk làm một public chain quyền riêng tư end-to-end, vậy sao đội hình “ra mắt khối tuân thủ” lại là hai tổ chức dịch vụ tài chính được cấp phép, không phải đội ngũ an ninh chuyên tấn công/phòng thủ mật mã?
Tôi lật vài bài blog kỹ thuật chính thức mới hiểu dụng ý của việc sắp xếp này. Khối zkUT theo chuẩn hợp quy của Dusk về bản chất là một bộ thực thi giao dịch quyền riêng tư. Dù mạch ZK có chặt chẽ đến đâu, giao dịch có thể “hạ cánh” hợp pháp hay không cuối cùng vẫn phụ thuộc vào việc bằng chứng đầu ra có đáp ứng được yêu cầu tuân thủ của cơ quan quản lý hay không. Ví dụ, một giao dịch cổ phiếu được token hóa: dù tính ẩn danh có hoàn hảo đến mức nào, nếu không đáp ứng yêu cầu khả kiểm toán theo định hướng của MiCA thì tuyệt đối không nhận được giấy phép phát hành, nguồn vốn của các tổ chức cũng không dám vào cuộc. Tương tự, một khoản chuyển tiền của tổ chức đáp ứng whitelist: dù tính ẩn danh có tốt đến đâu, nếu không có “giấy thông hành” từ danh sách trắng với tư cách pháp nhân của tổ chức do bên được cấp phép chứng thực, thì cũng không thể luân chuyển trong hệ thống môi giới chứng khoán tuân thủ.
Mainnet lần này chọn hai bên đó làm đối tác hợp tác ra mắt, về cơ bản tức là phía chính thức thừa nhận một điều: ngày đầu ra mắt khối tuân thủ này có đáng tin hay không—một nửa công lao nằm ở chính mạch ZK và logic ẩn danh khi staking của Dusk, còn nửa còn lại lại “đè” trực tiếp lên hai đối tác hợp tác tuân thủ kia. Phát hiện này khiến tôi nhìn lại cách nó quảng bá về quyền riêng tư end-to-end. PLONK với bằng chứng đệ quy và mô hình giao dịch ẩn danh Phoenix bảo đảm rằng quá trình thực thi giao dịch không bị ai can thiệp, tức là phần “tính toán + quyền riêng tư” là đáng tin. Nhưng việc giao dịch có được cơ quan quản lý công nhận hay có thể tích hợp vào hệ thống tài chính truyền thống hay không lại là một “ngưỡng triển khai” hoàn toàn độc lập. Mã kỹ thuật của Dusk không kiểm soát được phần này; chỉ có thể dựa vào việc kết nối với các đối tác tuân thủ được cấp phép, ký bản ghi ủy quyền của từng giao dịch tuân thủ dưới dạng bằng chứng có thể xác minh theo định hướng kèm dấu thời gian, rồi gắn các bằng chứng đó lên chuỗi để phía cơ quan quản lý đối chiếu sau.
Ban đầu tôi nghĩ độ tin cậy của hệ thống quyền riêng tư này là một tổng thể. Nhưng bây giờ tôi mới nhận ra có hai lớp tin cậy chồng lên nhau: độ tin cậy về quyền riêng tư trong kỹ thuật không đồng nghĩa với độ tin cậy về việc được phép gia nhập trong tuân thủ; phải tách riêng để nhìn. Khi nghĩ thông suốt lớp đó, tôi có đánh giá mới về việc khối tuân thủ của nó ra mắt
#dusk $DUSK @Dusk

Trước đó mình bị kẹt cả buổi chiều khi đọc log của testnet. Đá trong ly ice Americano trên bàn đã tan chảy hết, lớp nước ngưng trên thành cốc chảy ra tạo một vệt ướt trên miếng lót chuột. Mình đặt con chuột lên đế sạc không dây, ngồi ngẩn ra năm phút mới chợt nhận ra một điểm bất thường: toàn bộ bản ghi việc đặt cọc (staking) của các validator trên chuỗi PoS đều được công khai trên blockchain. Kẻ tấn công chỉ cần lần theo địa chỉ staking là có thể tìm được IP của node. Còn với chuỗi ẩn danh, ngay cả số tiền trong giao dịch cũng được mã hóa—chẳng lẽ lại để danh tính của validator “trần trụi” ra ngoài sao? Trước đây mình mặc định rằng cơ chế staking của chuỗi ẩn danh cũng tương tự như PoS thông thường, cho đến khi lật sang module staking ẩn danh Citadel của Dusk, mình mới nhận ra rằng ngay cả lớp định danh khi tạo block nó cũng đã làm ẩn danh theo kiểu end-to-end.

Ban đầu mình còn tưởng chỉ là “đóng gói” địa chỉ staking bằng cách trộn coin, nhưng khi nhìn kỹ vào mạch ZK của hợp đồng staking, mình mới hiểu—không hề đơn giản là che địa chỉ. Thứ nó cần là: bạn không cần phơi lộ địa chỉ staking của mình hay số tiền cụ thể, mà vẫn có thể chứng minh với toàn mạng rằng bạn đáp ứng ngưỡng tối thiểu và có đủ tư cách tham gia vào quá trình đồng thuận.

Cơ chế Citadel dựa trên chứng minh đệ quy PLONK này, cốt lõi là xử lý “cái lỗ hổng không thể tránh” mà mọi chain PoS công khai đều mắc phải: khi người dùng staking DUSK, họ sẽ khóa token vào một pool staking ẩn danh thống nhất; số tiền staking, thời gian khóa và mối liên hệ địa chỉ đều được xử lý mù (blinded). Các node khác chỉ cần 8 giây là hoàn tất việc xác minh—vừa không thấy được liên hệ giữa địa chỉ staking, vừa không thể ghép chữ ký khi tạo block với địa chỉ cụ thể.

Nhưng phải nói thật: thiết kế này yêu cầu độ chính xác của mạch ZK cực cao. Chỉ cần bỏ sót một ràng buộc trong phần viết là có thể phát sinh rủi ro giả mạo bằng chứng. Việc chế tài thật chính xác các node có hành vi xấu bằng phạt tịch thu cũng khó về mặt kỹ thuật hơn so với trường hợp staking công khai. Phần này vẫn đang được tiếp tục test. Con đường này có chạy thông suốt được hay không còn phải dựa vào thử nghiệm theo thời gian, nhưng ít nhất nó cũng cho thấy Dusk “nghiêm túc” với quyền riêng tư—ngay từ tầng nền của cơ chế đồng thuận. Bạn nghĩ sao về việc danh tính validator của các chuỗi PoS ẩn danh có nên công khai hay không? Bình luận ở bên dưới nhé.
#dusk $DUSK @Dusk

Tối qua làm thêm giờ “cày cá” rồi lỡ lướt tới lúc website mới của Dusk vừa ra mắt. Mình vốn định vào với tâm thế “đổi giao diện cho dự án”, ai ngờ website cũ muốn tìm tài liệu kỹ thuật phải nhảy qua tận ba bốn đường link, thỉnh thoảng còn bị 404. Kết quả là mình ngồi trước sơ đồ phân lớp kỹ thuật của website mới, đọc và lần ra mạch liên kết suốt 20 phút, cuối cùng đã nối liền toàn bộ những mảnh hiểu biết rời rạc về dự án trước đó.

Website mới hầu như không nhồi nhét marketing, mà trải thẳng ngăn xếp công nghệ từ tầng thấp lên tầng cao. Tầng thấp nhất là DuskDS: gánh việc đồng thuận, thanh toán và tính sẵn có của dữ liệu. Tầng đồng thuận dùng SBA—một cơ chế PoS dựa trên ủy ban. Khối tạo ra được chọn ẩn danh dựa trên Proof-of-Blind-Bid, danh sách người xác thực mỗi vòng đều thay đổi. Thiết kế này nhằm tránh việc người xác thực bị “khóa cứng” từ trước hoặc bị tấn công, đồng thời ngăn tình trạng trong PoS truyền thống, các “ông lớn” độc quyền quyền tạo khối.

Tầng giao dịch dùng Phoenix, dựa trên mô hình ghi chú UTXO. Tiền tồn tại dưới dạng các “notes” đã mã hóa; kết hợp Pedersen cam kết để che giấu số tiền, bộ hủy (nullifier) chặn double-spend. Node chỉ cần kiểm tra xem bằng chứng không kiến thức (zero-knowledge proof) có hợp lệ hay không. Lúc mình test, mình cố nhét dữ liệu giao dịch ở dạng bản rõ thì bị từ chối ngay—mình mới biết đây là một quy tắc “đóng đinh” từ tận tầng đồng thuận.

Đi lên tiếp, tầng Dusk Trade ban đầu mình tưởng là một kiểu DEX quyền riêng tư bọc ngoài. Nhưng demo quy trình trên website mới cho thấy nó trực tiếp điều khiển kênh thanh toán tầng dưới. Sổ lệnh mặc định được mã hóa, dùng mã hóa đồng cấu ElGamal: giá và số lượng đặt lệnh trên chain đều là bản mã. Công cụ khớp lệnh có thể tính toán trực tiếp trên bản mã. Khi đã xác định được giá và số lượng khớp, việc giải mã được thực hiện để hoàn tất giao dịch—suốt quá trình chi tiết lệnh gần như không lộ ra.

Bên trên nữa là DuskEVM: lớp thực thi được cải tạo dựa trên OP Stack, thực hiện thanh toán ngay trên DuskDS. Nếu Sol tích hợp vào thì có thể kế thừa năng lực quyền riêng tư ở tầng nền, không cần xây lại từ đầu. Tầng cao nhất là workflow thị trường tuân thủ (compliance), biến Citadel thành một module gọi trực tiếp được. Người dùng không cần gửi ảnh hộ chiếu; chỉ dựa vào zero-knowledge proof để chứng minh với hệ thống rằng mình “đã hoàn tất xác minh tuân thủ”.

Trước đây mình vẫn thấy đường hướng kỹ thuật của Dusk chỗ này chỗ kia, rời rạc. Lần này website mới trải toàn bộ stack ra, mình mới nhận ra—ngay từ đầu Dusk không phải làm đồ chơi chuyển tiền ẩn danh. Nó đang xây một nền tảng tài chính quyền riêng tư tuân thủ đầy đủ. Xem xong mình lập tức bổ sung thêm chút DUSK, vì những dự án dám bày công khai kiến trúc kỹ thuật rõ ràng cho mọi người thấy như thế này thật sự không nhiều. #dusk $DUSK @Dusk

Nói thật, ban đầu mình cũng tưởng Dusk chỉ là một kiểu “ẩn danh kể chuyện” theo bài cũ. Cho đến tuần trước, mình theo Discord của cộng đồng để canh thử nghiệm mạng chính RC2; đúng 3 giờ sáng, ly Americano đá uống đã ấm luôn rồi. Gas để thấp thì bị kẹt mất 20 phút, mình còn phải lên than với admin. Thử nghiệm tới thử nghiệm lui mới phát hiện thứ này hoàn toàn không giống với các “chuỗi ẩn danh” mà mình từng chơi trước đó.

Phần lớn các chuỗi ẩn danh mã hóa nằm ở lớp smart contract. Tức là khóa cửa nhà bạn gắn ở phòng khách: nếu có trộm đột nhập qua cửa sổ, thì đồ trong nhà vẫn bị nhìn thấy hết. Năm ngoái mình test một chuỗi ẩn danh đang hot—là vì lỗ hổng quyền trong contract. Trên testnet, mọi khoản chuyển đều lộ bản rõ ngay trong trình duyệt block explorer. Mình đã để lại một địa chỉ test, kết quả là bị tin rác “airdrop” quấy rối cả hai tháng. Còn Dusk hàn chết mã hóa cam kết Pedersen trực tiếp vào lớp đồng thuận SBA: tài sản từ ngay khi vào mempool đã ở trạng thái mã hóa. Node dù có lấy được toàn bộ dữ liệu block, cũng chỉ đọc được bằng chứng zero-knowledge “giao dịch hợp lệ”; không thể chạm tới bất kỳ đồng bản rõ nào, cũng không xem được địa chỉ. Mình cố tình nhét dữ liệu giao dịch bản rõ vào interface node, kết quả bị lớp đồng thuận đá thẳng ra—thậm chí không đi được tới bước xác thực.

Trước đây mình khó chịu nhất với vấn đề KYC của các chuỗi ẩn danh. Năm ngoái mình dùng một chuỗi ẩn danh “tuân thủ” nào đó, phải upload ảnh hộ chiếu lên một plugin bên thứ ba, quay đầu là nhận tin nhắn rác về sản phẩm tài chính ở nước ngoài. ZkKYC của Dusk được nhúng thẳng trong Rusk VM: giấy tờ KYC của bạn nằm ở chính máy bạn; khi giao dịch chỉ tạo một loại chứng minh rằng “mình đáp ứng yêu cầu quản lý”. Ngay cả dự án cũng không lấy được thông tin danh tính của bạn. Nếu bên quản lý mở khung kiểm toán, cũng chỉ xem được các giao dịch được chỉ định. Hiện tại họ vừa gộp PR kết hợp chứng minh FRI+PLONK: xác thực một giao dịch chỉ còn 1.4 mili giây. Gas cho hợp đồng “cơ mật” thấp hơn 67% so với kiểu EVM bọc thêm lớp ZK. Mình deploy một hợp đồng trái phiếu test chỉ tầm dưới 20 dòng code, và Gas tốn có 0.28 $DUSK .

Trước đó mình từng bị “kẹt” và lỗ gần hai nghìn U trên một chuỗi ẩn danh cũ. Mình vẫn luôn nghĩ riêng tư và tuân thủ vốn là kẻ thù trời sinh: hoặc làm nơi trú ẩn cho “xám” và rửa tiền, hoặc làm “chuỗi tuân thủ” bóc trần quyền riêng tư người dùng. Chạy test Dusk xong mình mới hiểu: quyền riêng tư không nên là tấm khăn che cho hoạt động mờ ám. Dữ liệu tài sản và danh tính của người dùng vốn dĩ phải do chính họ nắm giữ. Tuân thủ cũng không nên đánh đổi quyền riêng tư. Dusk thật sự đã bẻ gãy nút thắt rối ren đó—suốt gần mười năm từ tầng đáy—và cắt nó ra@Dusk
#dusk $DUSK

币圈已经没流动性了，和A股一样#闪迪股价涨幅扩大至11%

Cuối tuần, ngồi quán cà phê dưới lầu cọ điều hòa rồi canh mạng test Dusk, lỡ tay nhập sai mật khẩu liên tiếp ba lần, giày vò nửa tiếng mới chạy xong giao dịch thứ 21. Nhìn chằm chằm vào log thực thi của máy ảo Rusk mà ngây ra rất lâu—trước đây tôi đã chơi vài chuỗi ẩn danh cũ, hoặc là bị kẹt nửa ngày không ra block, hoặc là làm ẩn danh tới mức tuân thủ theo kiểu “căn bản chẳng thể mở quyền kiểm toán”. Ban đầu tôi vốn chẳng còn kỳ vọng gì vào cái gọi là “chuỗi công khai riêng tư”, cho tới khi tự tay dính bẫy mới hiểu: thứ này thật sự không phải chỉ việc khoác một cái vỏ rồi đem đi thổi khái niệm.

Lúc đầu tôi làm quen vai trò đồng thuận SBA theo hướng “đổi da PoS”. Lật hết quy tắc nút, rồi tự chạy mô phỏng double-spend tới một vạn lần mới hiểu ra: SBA (Segregated Byzantine Agreement, thỏa thuận Byzantine phân tách) chia các nút thành hai tầng. Một tầng là ủy ban sản xuất block, chịu trách nhiệm đóng gói giao dịch; tầng còn lại là các trình xác minh bị rút thăm để kiểm tra ngẫu nhiên, đóng vai trò kiểm tra/kiểm chứng. Hạt giống cho rút thăm ngẫu nhiên do VDF (hàm trễ có thể xác minh) sinh ra, không ai có thể đoán trước tiếp theo sẽ kiểm tra ai. Trình duyệt mạng test hiển thị có 3 nút bị phạt mất tiền đảm bảo do nộp block không hợp lệ; trong đó hai nút là bị phạt mềm—bỏ sót vài block nên tạm thời bị đẩy ra khỏi hàng đợi đồng thuận, tổng số tiền stake hợp lệ bị cắt giảm một đoạn; nút còn lại là bị phạt cứng—bị bắt khi song ký, token stake bị trừ thẳng 20% và đem đi hủy. Cơ chế phạt kiểu này đẩy chi phí gây hại lên rất cao, khiến giá phải trả cho việc thử sai cực lớn.

Khi test giao dịch, tôi trượt tay gõ thừa một số 0: số tiền lập tức vượt phạm vi của Range Proof, giao dịch ngay lập tức bị ném trả lại, trên chuỗi thậm chí không để lại dấu vết giao dịch vô dụng. Phoenix protocol có Range Proof “khóa cứng” dải giá trị của số tiền giao dịch; kết hợp với cam kết Pedersen, khóa chặt tổng lượng tài sản của từng khoản—không thể xuất hiện việc phát hành vô cớ. Thêm nữa, mỗi giao dịch đều tự động đổi địa chỉ Stealth Address dùng một lần, nên tôi chuyển liên tiếp 5 lô test coin: trên chuỗi hoàn toàn không thể liên hệ các giao dịch này về cùng một tài khoản. Bằng chứng PLONK truy hồi gom nhóm được nén chỉ còn 287 byte, kiểm chứng từng giao dịch chỉ mất 1,8 mili giây; chạy rất mượt, ngay cả lúc mạng test cao điểm cũng không gặp tắc nghẽn.

Máy ảo Rusk được viết hoàn toàn từ đầu bằng Rust, hỗ trợ nguyên sinh chuẩn tài sản bí mật. Tôi triển khai test Token chỉ cần chưa tới 200 dòng code riêng tư, chẳng phải viết nhiều; chi phí Gas khi chạy hợp đồng còn thấp hơn 63% so với EVM khi chồng thêm lớp ZK, và còn để sẵn lối vào quyền kiểm toán cho bên tuân thủ—quyền riêng tư và tuân thủ không cần chọn một trong hai, có thể cân bằng đồng thời. Sau khi chạy xong mạng test vào đêm đó, tôi thấy yên tâm hơn bất kỳ dự án nào tôi từng cùng đầu tư trước đây.
#dusk $DUSK @Dusk