铭文的热度真得高呀，今天继续写一下我对铭文的一些浅陋认知。 这两天参与Particle协议发起的People’s Alliance 铭文活动，让我对EVM铭文和比特币铭文之间的异同颇感兴趣。 于是，有着好奇宝宝体质的我，在数据平台Dune上查了一下他们的数据结构。 铭文现在总体上可以划分为比特币铭文和EVM铭文两大类，而比特币铭文又可以划分为以下两类：

• 将铭文信息保存在SegWit（隔离见证，专用于保存签名和脚本信息的比特币主网区块空间）Witness（见证）中的Ordinals和BRC20等协议。

其中，BRC20的铭文信息是一串标准化的Json文件： {"p":"brc20","op":"mint","tick":"***","amt":"100000000"} p的键值是协议名brc20； op的键值是操作类型（brc20定义的操作类型只有deploy部署、mint铸造和transfer转账）； tick的键值是铭文的Symbol，限制为4个字符； amt的键值是操作的数量。 Ordinals目前是最古典和最具正统性的铭文协议，BRC20是基于Ordinals协议的，它的作用是将Ordinals定义的非同质铭文同质化，成为可以像Erc20 Token那样可以交易的同质化资产。 此类铭文的具体保存位置见下图：

• 将铭文信息保存在UTXO包含字段的Atomicals（含ARC20）、Runes、Pipe、Stamps等等协议。

BRC20的Mint和Transfer过程中，会生产大量的略微高于546聪的UTXO，这些UTXO在很长时间内无法归集，从而引发比特币主网的UTXO集膨胀问题，演变成对比特币主网的粉尘攻击（Spam Attack）。 这是为什么BitcoinCore的领袖Luke和Ordinals协议发起者Casey不约而同批评BRC20的最重要原因。 所以，原生的同质化铭文协议Atomicals的ARC20、Casey发起的Runes、根据Casey Runes文档部署的Pipe和Stamps协议等等，他们选择将铭文信息保存在UTXO中，通过与比特币的数据结构保持一致性和原子性，最大可能地降低对比特币共识负载的影响。 以ARC20的龙头铭文ATOM为例，它的铭文归属地址信息保存在1笔UTXO的Output字段、打铭文的信息保存在hex字段，铭文开打的信息保存在input字段。 此类铭文的具体保存位置见下图： 以上是比特币铭文数据结构的简单介绍，而EVM铭文则大多参考了BRC20协议的设计规范。 EVM铭文的信息，以跟BRC20相同结构的标准化Json文件，保存在一笔Transaction（事务）的data字段中。 此类铭文的具体保存位置见下图： 写到这里，我们其实可以给铭文协议下一个非权威、个人化的定义 铭文协议，指的是一种由链下索引器验证、排序状态数据，并将其提交和保存在区块链主网的某个位置（比特币主网Segwit的Witness，UTXO的hex、input、output等字段，EVM区块链Transaction的data字段）的区块链扩展方案。 等一下，铭文协议这个的定义怎么听起来那么像L2呢？ 没错，在我看来，铭文协议与L2的抽象架构是相同的，只是在一些重要细节上有所不同：

• 与铭文协议相比，L2的状态数据变更，需要经过L2项目部署在主网的智能合约（如Optimism gateway）的验证；
• 铭文协议目前尚未支持VM（虚拟机），无法执行协议定义的deploy、mint、transfer之外的函数和方法；
• 铭文协议引入信任假设大于L2。ZK-Rollup L2有ZKP证明机制、OP-Rollup L2 有欺诈证明机制来确保去信任，而铭文协议目前主要依靠索引器代码开源和多实体运行索引器。

最后，抛开这些技术细节不谈，L2的设计规范反映的是加密精神的核心内涵（阳面）--自由和去信任化，而铭文协议的设计规范折射的是加密精神的对立面（阴面）-公平、公平和公平。 这就是为什么铭文社区对铭文协议的过度中心化和引入过多信任假设持包容和理解态度，而L2社区对L2序列器的中心化和欺诈证明未实际部署耿耿于怀。 就像在美国政治生态中，不能只有主张自由的共和党而没有主张公平的民主党一样，在加密世界的可扩展性方案中，也不能只有主张自由的L2而没有主张公平的铭文协议。 阴阳既济，利贞。