以前我看合约隐私时，目光总盯着存储区。加密字段就摆在那里，很容易让人安心。今天我在抠 RUES 的订阅条件时，两个限定词把我按住了。@Dusk 的合约可以把状态藏起来，但订阅不是摸黑进行的，它先认 contract_id，再认 event_name。可见性从这里就已经分了岔。
我把 D-03 和 D-37 摊成两栏。左边写存储加密，右边写事件层。订阅样例里的 JSON header 和 raw event bytes 我都圈出来了；$DUSK 合约事件会按条件送给订阅者。看到 raw event bytes 原样可读时，我像收到了一条报错提示：别把存储层的结论盖到日志层。订阅字段不是摆设，它决定谁能收集哪些行为碎片。
说白了，锁住文件柜，不等于门口的收件登记也上了锁。状态像柜里的材料，事件更像贴在门口的取件单。索引器未必能碰到加密字段，却可能把时间、调用和名称整理得很勤快。把两栏放在一起，我才慢慢回过味：隐私不是一个按钮，而是每层可见性分别算出来的结果。
这里有个很实际的边界。事件不必直接暴露资产数量，才会形成风险。把时间点、反复出现的调用关系和关联名称放到一起，旁观者已经能做出接近的推断。只查合约状态，会漏掉一条查询路径。把事件层单独划进检查表，不是吹毛求疵，而是避免后来才发现，行为轮廓早被日志拼出来了。
所以我现在不再只问存储有没有加密，还会追问事件怎么发、谁能订阅、字段是否脱敏。我宁可多花一分钟读字段，也不愿把默认可见当成默认私密。存储加密当然有用，但不等于日志就自动保密。隐私合约的检查清单里，事件层该独立占一行。索引器越勤快，这一行越不能省。#dusk
我把 D-03 和 D-37 摊成两栏。左边写存储加密，右边写事件层。订阅样例里的 JSON header 和 raw event bytes 我都圈出来了；$DUSK 合约事件会按条件送给订阅者。看到 raw event bytes 原样可读时，我像收到了一条报错提示：别把存储层的结论盖到日志层。订阅字段不是摆设，它决定谁能收集哪些行为碎片。
说白了，锁住文件柜，不等于门口的收件登记也上了锁。状态像柜里的材料，事件更像贴在门口的取件单。索引器未必能碰到加密字段，却可能把时间、调用和名称整理得很勤快。把两栏放在一起，我才慢慢回过味：隐私不是一个按钮，而是每层可见性分别算出来的结果。
这里有个很实际的边界。事件不必直接暴露资产数量，才会形成风险。把时间点、反复出现的调用关系和关联名称放到一起，旁观者已经能做出接近的推断。只查合约状态，会漏掉一条查询路径。把事件层单独划进检查表，不是吹毛求疵，而是避免后来才发现，行为轮廓早被日志拼出来了。
所以我现在不再只问存储有没有加密，还会追问事件怎么发、谁能订阅、字段是否脱敏。我宁可多花一分钟读字段，也不愿把默认可见当成默认私密。存储加密当然有用，但不等于日志就自动保密。隐私合约的检查清单里，事件层该独立占一行。索引器越勤快，这一行越不能省。#dusk