@milkey #0 这个方案真正解决的是传统短链服务里“自有映射数据库”这一单点：长网址和短码的对应关系直接落在交易数据里，不再依赖某家 MySQL、KV 或后台接口，思路是成立的。结合前面有人提到的 web3 网盘打不开，我觉得要区分“数据还在链上”和“入口永远可达”：链上数据不可变，不代表 RPC 永久在线，静态前端、域名、网关都可能失效；另外还要考虑不同链的确认规则、链重组以及最终性。建议短码本身明确编码 chainId、交易哈希（或区块号+交易索引）和必要的版本字段，制定确定性的编解码规范，避免不同实现解析不一致。前端最好支持多个 RPC、多个静态镜像，并附带一个可下载的本地离线解码页，这样域名或单个 RPC 挂了仍能恢复。安全上建议只接受 http/https，IDN 域名做规范化并在跳转前展示完整目标，必要时对跳转链做预览；黑名单服务超时或失败时也要有明确策略，不能让“检测失败”被误认为“安全”。最后，链上写入意味着目标 URL 永久公开且基本不可撤回，可能泄露隐私，也可能被用于钓鱼、恶意下载和滥用内容，创建时最好明确提示，甚至提供本地策略或黑名单扩展接口。
@ptt男孩 #6 我记得dns记录数是有上限的
@ptt男孩 #6 cf现在新域名只有200条解析了吧，之前还有1000来着
@xlogcc #10
也改不了，只能重新生成，链接里面的短码对应的区块高度+序号
@milkey #0 这思路挺好
@006lp #12
不知道有上限，因为我目前几千条都没啥问题。
域名在CF注册的
存储短链识别码，解析系统+域名拼接=实际短链，与活码系统有啥不同
短链活的比原链接还久？
和区块链发消息是不是一个道理，自己插东西进去
ipfs 我突然想起来ipfs 图床
@milkey #0 这个方案真正解决的是传统短链服务里“自有映射数据库”这一单点：长网址和短码的对应关系直接落在交易数据里，不再依赖某家 MySQL、KV 或后台接口，思路是成立的。结合前面有人提到的 web3 网盘打不开，我觉得要区分“数据还在链上”和“入口永远可达”：链上数据不可变，不代表 RPC 永久在线，静态前端、域名、网关都可能失效；另外还要考虑不同链的确认规则、链重组以及最终性。建议短码本身明确编码 chainId、交易哈希（或区块号+交易索引）和必要的版本字段，制定确定性的编解码规范，避免不同实现解析不一致。前端最好支持多个 RPC、多个静态镜像，并附带一个可下载的本地离线解码页，这样域名或单个 RPC 挂了仍能恢复。安全上建议只接受 http/https，IDN 域名做规范化并在跳转前展示完整目标，必要时对跳转链做预览；黑名单服务超时或失败时也要有明确策略，不能让“检测失败”被误认为“安全”。最后，链上写入意味着目标 URL 永久公开且基本不可撤回，可能泄露隐私，也可能被用于钓鱼、恶意下载和滥用内容，创建时最好明确提示，甚至提供本地策略或黑名单扩展接口。