链上没有可直接存放的“秘密原文”
ethereum.org在Blockchain Data Storage Strategies中开篇列出多种把信息“直接写上链”或“由链担保”的方式：EIP-4844 blobs、calldata、带L1机制的链下存放、合约代码、事件与EVM存储。选择依据包括信息来源与去向、可接受的处理负担、是否需要全网节点轻易读取，以及安全要求。
同一页把信息安全拆成机密性、完整性与可用性。它明确写道：链上没有秘密——区块链依赖任何人都能验证状态转换，因此不能直接用来存放机密；若要在链上处理机密信息，都要依赖某种链下组件至少保存密钥。对个人信息而言，这意味着“把原文塞进交易字段”并不能自动获得保密效果。
完整性靠哈希，可用性与留存窗口仍要单独设计
该ethereum.org页继续说明：文中方案通常都有良好的完整性，因为哈希会发布到L1；但可用性保证并不相同。blobs被描述为有限寿命的廉价临时数据通道（文中提及最初约18天量级），主要服务rollup发布交易等场景。事件则“完全无法在链上再被读取”。写作时应分开记录：链上承诺证明的是哪份摘要、原文存放在何处、以及挑战/读取窗口是否仍覆盖业务需要。
因此，个人信息更常见的工程分工是：链下保存可删除或可过期的原文，链上仅保留必要时的承诺或索引；不能把“已经上链”误写成“已经完成长期可审计的原文存档”，也不能把短寿命数据通道当成永久个人档案库。
内容寻址与加密：哈希公开不等于身份隐藏
IPFS Docs的Privacy and encryption页写明：IPFS是公共网络，节点为全局一致的内容地址（CID）存储并通告数据，相关元数据会进入可公开查看的分布式哈希表。节点之间的流量可加密，但发布到DHT的元数据是公开的，包括PeerID以及它们提供的CID；因而“谁在检索/再提供哪些CID”等信息可被观察。
该页还说明协议核心未内建单一隐私层，并建议在担心泄露时采取额外措施，例如停用再提供、加密敏感内容，或在合适时运行私有网络。结合ethereum.org对“链上无秘密、机密依赖链下密钥”的表述，可以固定一条写作边界：对原文做哈希或生成CID，解决的是完整性与定位，并不自动等于匿名化或个人信息脱敏；是否暴露关联元数据，要按公开DHT与密钥管理单独评估。