在卡达诺上验证”这段文字确实是这个地址的主人签的”，可以完全不碰智能合约——这是 CIP-8 数据签名标准最核心的一句话。这份卡达诺改进提案定义的是一套链下签名与验证格式：签名本体用工业标准的 COSE 结构封装，验证只需公钥、原文与签名三样东西。对 NFT 场景来说，它提供的是一条比”发一条推文自称作者”强得多、又比部署验证合约轻得多的归属声明路径。
先看它站在什么地基上。提案明确选择 COSE（CBOR Object Signing and Encryption，RFC 8152）作为容器，理由是卡达诺基础协议本来就依赖 CBOR 编解码，生态工具链无需引入新库，而且 COSE 编码紧凑——提案原话是”万一这些数据将来需要存到链上”，紧凑格式能省空间。也就是说，链上存放只是预留的可能性，规范本体规定的是签名与验证的构造方法。
签名容器分两种：单签名者用 COSE_Sign1，多签名者用 COSE_Sign（内含多个 COSE_Signature）。COSE_Sign1 的三段结构是头部、载荷（payload，可以为 nil）与签名字节。真正决定”这份签名只能用于这个场合”的，是签名前拼进哈希的 Sig_structure：规范给出的形式是把文本 “Signature1”、受保护头部（protected）、以及载荷三部分组成数组再序列化。受保护头部里被哈希锁定的字段改一个字符，验证就失败；载荷则可以走”分离式”（detached）路线——签名为 nil、原文另行传给验证方，这样给大文件签名时不必把整个文件塞进签名结构里。
地址与密钥的表达是这份规范的卡达诺特色。密钥信息放在头部里，提案用 CWT（CBOR Web Token）claims 组织，密钥标识 key_id 通常直接放地址派生用的公钥哈希。规范特别处理了两类地址的差异：简单的支付验证密钥地址可以直接从地址解出验签公钥；而带链码与属性的 v2 企业级地址，光看公钥无法反推地址，提案因此建议在受保护头部里附上完整地址，验证方结合公钥重建地址后核对是否一致——这一步防的是”用别的地址的公钥冒充”。提案同时警告头部里的公钥不应携带链码信息，否则会危及分层派生非硬化密钥的隐私与安全。
签名可以被拿去做什么、不能做什么，提案的”未决问题”一节写得罕见地直白：它举的例子正是重放攻击——有人在测试网上被诱导签了一条消息，另一个人把同一份签名搬到主网的同一应用去用。规范把这列为尚未彻底解决的问题，意味着防场景绑定的责任落在应用与工具上：严谨的签名工具应当把网络环境、应用标识这类上下文写进被签内容本身，而不是指望协议层兜底。使用者看到的后果很简单——凡是弹窗不回显原文、只让你签一坨编码串的工具，都可能把你暴露在这种跨场景重放里。
面向人的编码，提案另给了带前缀的文本格式（用户可见的签名串由数据部分与校验和组成，方便粘贴与传阅），以及加密扩展（encrypted COSE 结构，接收者头部用临时密钥对的公钥 epk 标注），但 NFT 日常用到的是最朴素的”签名加原文加地址”三件套。验证流程因此可自述：重建 Sig_structure、按头部声明的算法（典型为 EdDSA）验签、核对受保护头部里的地址与语境吻合。整个过程中合约不需要存在、链上不需要查询——这与以太坊的 EIP-1271 路线（合约必须自己实现验证逻辑）形成结构性对照：卡达诺把验证做成了纯离线动作，代价是链上程序默认不消费这些签名，验证发生在钱包与工具层。
落到 NFT 使用上，能做与不能做的界线清楚。能做：作者用自己活跃的地址对作品说明签名，收藏者拿原文、签名与地址三样东西在任何合规工具里复验，确认声明确出自该地址；多签托管的小组可以用 COSE_Sign 给同一份声明共同背书。不能做：签名不等于授权——一段被签的文本即使描述了”我同意转让”，链上也不会因此发生任何转让；签名也不自带时间戳——它只能证明”某时刻之后签的”，证不了”现在仍然有效”。判断声明与具体资产的绑定是否真实，靠的是把资产标识原文写进被签文本里，让重放资产声明同样撞上哈希不匹配。
工具核对也因此有抓手：一份合格的 CIP-8 签名容器，受保护头部至少要有算法字段与密钥标识字段，v2 地址场合还应有完整地址字段；缺一件的”签名”都值得退回重签。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。