在以太坊上给一枚 NFT 写铭文，大多数人想到的是合约：先部署一段 ERC-721 或 ERC-1155 代码，再在上面铸造、挂单、转让。Ethscriptions 走的是另一条路——它没有自己的代币合约，对象直接寄生在普通交易的输入数据里。官方文档对协议的概括是”用交易 calldata 在以太坊上创建和分享数字对象的新方式”：任何一笔成功的交易，只要输入数据按 UTF-8 解释后是一个合法的 Data URI，且交易有明确的接收方（即不是合约创建交易），索引器就会把这笔交易登记为一个 Ethscription。换句话说，发一个对象不需要写一行合约代码，只需要发一笔把 Data URI 放进 calldata 的转账。
按官方规范，索引规则有几条硬约束值得逐条读。第一，只统计成功交易：状态码为 0 的交易必须被忽略；早期区块（高度不高于 4370000）没有状态字段的历史交易按规则同样纳入。第二，身份与归属完全由交易决定：创建这笔交易的哈希就是这个对象的 id，交易的接收方是它的初始所有者，发送方是创建者。转让同样通过一笔交易完成，Data URI 里写明转让意图与对象标识，接收方即新 owner——整个”账本”就是对全链交易按区块顺序重放索引的结果。第三，唯一性靠内容哈希：同一 Data URI 的 UTF-8 文本的 sha256 如果在此前的交易里出现过，这笔创建就不被登记；直到 ESIP-6 生效，创建者才可以在 URI 里带上 rule=esip6 参数主动选择允许非唯一。
协议还留了一个演进通道：ESIP（Ethscription Improvement Proposal）。官方文档列出的已接受提案包括智能合约转让（ESIP-1）、Safe 信任less 托管（ESIP-2）、合约侧创建（ESIP-3）、批量转让（ESIP-5）、非唯一模式（ESIP-6）、calldata 的 gzip 压缩（ESIP-7）以及把大文件挂到 blob 上的 BlobScriptions（ESIP-8），每一项都标注了生效区块高度。这意味着同一个协议在不同时期的链上表现并不相同，核对历史对象时必须按当时的规则重放，而不是拿最新规则倒推。文档还描述了一条 AppChain 路线：把 L1 上的创建与转让意图确定性地翻译成 L2 存款交易，用 SSTORE2 的思路把内容切成合约字节码分片存储，以获得更接近合约 NFT 的交互体验。
把这套机制和合约型 NFT 摆在一起，差异就清楚了。合约 NFT 的状态存在合约存储里，市场与钱包读的是合约接口；Ethscription 的状态不存在任何合约里，完全靠链下索引器重放全链交易算出来。这带来两个直接后果：其一，市场上没有标准的 ownerOf、transferFrom 函数可查，能否被钱包显示、能否在某站挂单，取决于该平台是否接了配套索引器或 ESIP-1 的合约转让通道；其二，对象的”内容本体”就躺在当年那笔交易的 calldata 里，只要以太坊历史数据还在，内容就跟着在，不需要 IPFS 网关或后端服务器——这也是它最常被拿来和 Ordinals 对照的卖点。代价同样直白：calldata 按字节计费，稍大的图片会让创建费用迅速失控，这也是官方文档收录压缩类与 blob 类提案的原因。
上手核对时建议做四件事。第一，不要只看第三方浏览器的展示页，用交易哈希在以太坊节点或区块浏览器上查这笔交易的输入数据原文，确认它确实是一个可解析的 Data URI；第二，确认平台的转让走的是普通 calldata 转账还是 ESIP-1 的合约通道，两者对钱包签名弹窗的要求完全不同，看到看不懂的合约调用就先停下；第三，如果目标是”唯一”，检查 URI 是否带 rule=esip6——带了就意味着主动放弃了唯一性约束；第四，任何声称”免费铸 Ethscription”的前端都要先核对其生成的目标地址与数据内容，因为创建与转让本质就是你自己发的一笔转账，签名即执行。作为机制样本，它展示了 NFT 的另一条定义路径：确权不依赖合约地址，而依赖交易历史本身与所有索引者对同一套规则的共识。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。