先说句实在话，Dusk 这套 WASM 合约流程，我在 Chrome 里打开编辑器、连钱包、点编译，前后没装任何本地依赖——这一把体验确实顺滑。#[contract] 宏把导出和序列化给包圆了，Contract Drivers 那层桥接也省了不少查 ABI 的功夫。你要是只跑 Moonlight 的公开转账，从零到上线，可能比你泡杯手冲咖啡还快。
大饼又开始涨了，BTC还是很强
但真让我坐下来多想了半小时的，是我把一笔 Phoenix 的屏蔽转账塞进 Moonlight 的查询逻辑里调试的时候。
Dusk 的玩法是两条腿走路：Moonlight 是透明账本，余额直接怼在账户上；Phoenix 是 UTXO 套了层隐身地址，余额藏在 note 里。这俩之间的资金流转得靠 Transfer Contract 当翻译官——公开转屏蔽，先扣余额再铸 note；屏蔽转公开，先烧 note 再增余额。听着逻辑清晰对吧？可一旦你写查询接口，想一次性把两边的余额总和展示出来，就得同时处理账户状态和 note 密文两组完全不同格式的数据。我团队里的新人第一反应是把 note 的 value 当余额直接累加——那笔交易广播出去直接废了，因为 Phoenix 的 note 得先验证所有权证明才能解出数值，这跟 Moonlight 的余额读取压根不是一个时序。
Gas 这块更是个隐形坑。公开交易你照常规逻辑估算，基本八九不离十；但屏蔽交易得走 ZK 证明生成和验证，证明电路的复杂度跟你这笔交易里 note 的数量、约束条件直接挂钩。我试过一笔 2 个输入 note 加 3 个输出 note 的 Phoenix 转账，Gas 消耗比同数量级的公开交易高出接近两个数量级。文档里给的 Gas 常量只能当底价参考，真上线前你不在测试网用真实参数跑几轮模拟，那个 Gas 上限你根本不敢填——填少了交易被 revert，填多了又白白烧钱。
我没完全搞懂的是，Dusk 官方教程里对这类“混合查询 + 跨模型调用”的边缘场景，边界说明实在稀薄。 @Dusk $DUSK #dusk
大饼又开始涨了，BTC还是很强
但真让我坐下来多想了半小时的，是我把一笔 Phoenix 的屏蔽转账塞进 Moonlight 的查询逻辑里调试的时候。
Dusk 的玩法是两条腿走路：Moonlight 是透明账本，余额直接怼在账户上；Phoenix 是 UTXO 套了层隐身地址，余额藏在 note 里。这俩之间的资金流转得靠 Transfer Contract 当翻译官——公开转屏蔽，先扣余额再铸 note；屏蔽转公开，先烧 note 再增余额。听着逻辑清晰对吧？可一旦你写查询接口，想一次性把两边的余额总和展示出来，就得同时处理账户状态和 note 密文两组完全不同格式的数据。我团队里的新人第一反应是把 note 的 value 当余额直接累加——那笔交易广播出去直接废了，因为 Phoenix 的 note 得先验证所有权证明才能解出数值，这跟 Moonlight 的余额读取压根不是一个时序。
Gas 这块更是个隐形坑。公开交易你照常规逻辑估算，基本八九不离十；但屏蔽交易得走 ZK 证明生成和验证，证明电路的复杂度跟你这笔交易里 note 的数量、约束条件直接挂钩。我试过一笔 2 个输入 note 加 3 个输出 note 的 Phoenix 转账，Gas 消耗比同数量级的公开交易高出接近两个数量级。文档里给的 Gas 常量只能当底价参考，真上线前你不在测试网用真实参数跑几轮模拟，那个 Gas 上限你根本不敢填——填少了交易被 revert，填多了又白白烧钱。
我没完全搞懂的是，Dusk 官方教程里对这类“混合查询 + 跨模型调用”的边缘场景，边界说明实在稀薄。 @Dusk $DUSK #dusk