Hi @xingtianchunyan ,
非常感谢委员会的理解。很高兴能收到委员会提出的问题！
Pinata 上传流程
在目前 UGMP 的架构里，前端不直接请求 Pinata，由服务器通过其提供的PINATA_JWT 发出请求。
- 前端向 UGMP 服务器的
multipart/form-data接口提交图片。 - 服务器校验后调用 Pinata API：
https://api.pinata.cloud/pinning/pinFileToIPFS - Pinata 返回
IpfsHash。 - 服务端把结果整理为统一的
UploadResult返回给前端。
对应代码位置：
- API route：
app/api/uploads/pinata/route.ts - Pinata wrapper：
lib/pinata.ts
dob_metadata 结构
当前链上 metadata 使用最小字段：
{
"v": 0,
"n": "image.jpg",
"r": "ipfs://QmXQG5m7zH43PU4zRtnzjxYPkPY1kMiDhicKJMpK1A9Dqx",
"m": "image/jpeg"
}
字段含义：
v：metadata schema version，目前为0。n：展示名称，通常使用上传文件名。r：resource URI，也就是ipfs://{cid}。m：资源 MIME type，例如image/png、image/jpeg。
存储选项取舍
CKB-UGMP 目前将 IPFS 作为默认方案，但设计上保留了其他存储方式的空间。
IPFS / Pinata
优点：
- 链上只保存短 URI，对于较大的资源，成本低。
- 不依赖中心化平台。
- Pinata 提供 pin 服务，能提高资源可用性。
- 其他网关、索引器或渲染器也能解析资源。
缺点：
- 浏览器通常不能直接打开
ipfs://，需要网关或支持 IPFS 的客户端。 - 如果没有 pin，资源可能随时间变得不可用。
- 网关可能很慢。
纯文本上链
适用场景：
- metadata 极小。
- 资源本身就是文本、JSON等。
- 需要最大程度保证内容随链永久可读。
优点：
- 内容直接在 CKB 上，不依赖外部存储服务。
- 可验证性和长期可用性最强。
- 对索引器和链上解析最直接。
缺点：
- 单位成本极其昂贵。
适合极小文本、小 JSON，不适合作为图片类 DOB 的默认方案。
中心化平台 URL
适用场景：
- 快速原型。
- 项目方已有稳定 CDN 或对象存储。
- 对长期去中心化可用性要求不高。
优点：
- 实现简单。
- 浏览器兼容性好。
- 加载速度和缓存可控。
缺点：
- URL 指向的内容可以被替换、删除或失效。
- 长期可用性依赖平台或项目方。
关于部分 DOB 图片可视性的问题
目前我推测有两种可能
- Pinata 网关 fetch 速度比较慢，对于较大的图片，很可能加载缓慢或直接超时。
- 对于宽高比例失调的图片，渲染器可能没有比较好的渲染效果，导致有一种看不到图片的感觉。
请问方便提供出现问题的 DOB 的相关信息吗，以及上传图片的比例、大小信息吗？我也会在未来几天不断测试。
祝好，
HNO3Miracle