撰文： Beosin
2 月 1 日，币安 Web3 钱包正式推出铭文市场，支持 BRC-20、EVM 等多种铭文协议。几天前，OKX 也宣布支持 ARC-20、Runes、Doginals 等铭文协议，引发整个市场对于铭文的关注。在此背景下，由于铭文协议的复杂性和新颖性，各种安全问题频出。这不仅威胁到用户的资产安全，也对整个铭文生态的健康发展产生了负面影响。
针对此，Beosin 安全团队对主流铭文协议进行了梳理，帮助用户了解铭文协议的用途、实现方式以及如何保护铭文资产。
铭文简介
区块链上所谓的铭文，就是通过区块链的某些特性，在区块链上记录一些特定的且具有意义的信息。该信息一旦记录到区块链之上，便将永久保存在区块链上，并且难以篡改。记录到区块链的信息可以是多种类型，例如简单的文本信息，复杂的代码、图像等都可以写入区块链，这样一来，我们便可以使用一套标准来实现数字资产的功能。
铭文现状
从最初 BRC-20 等比特币公链铭文的出现，到现在铭文生态中几乎每天都有层出不穷的铭文新协议以及新项目出现，铭文的发展可以说是突飞猛进。各个常见的公链也都加入了铭文生态圈，例如 ETH 公链上的 Ethscription 协议、BTC 公链上的 ARC-20 协议、BSC 公链上的 BSC-20 等协议、Polygon 公链上的 PRC-20 等协议......。这些协议都是为了在其公链上发布铭文所产生的，接下来的内容我们将介绍各种协议的实现方式以及用例。
铭文详解
我们来介绍一下目前市场关注度较高的协议，来比较一下各个公链的铭文协议到底有何共同点与不同点。
1. BRC-20
要讲清楚 BRC-20，首先要介绍一下 UTXO 与 Ordinals。
BTC 采用的是 UTXO 模型，交易是以 UTXO 为单位进行转账的。UTXO 是 Unspent Transaction Output 的缩写，意思是未花费的交易输出。UTXO 模型不同于以太坊等公链的账户模型，它记录交易事件，而不记录最终状态。计算某个用户有多少比特币，就需要对其地址的所有 UTXO 求和，得到结果就是该用户的持币数量。
Ordinals 是一个为比特币最小单位聪（sats）进行编号的一个系统协议，可以为每个 UTXO 里（包含了若干个聪）的每一个聪分配一个唯一的编号。Ordinals 还支持文字、图片、音频、视频等写入聪的功能，从而使得每个聪都具有独特性，就类似于大家熟悉的以太坊非同质化代币 NFT，而我们将其称之为比特币 NFT。
而 BRC-20 创始者基于 Ordinals 协议，想出了另外一套理念。既然 Ordinals 协议可以通过给每个聪赋予不同的 “属性” 来创造比特币 NFT，那么也可以通过给定一个统一的 “格式” 以及 “属性” 来创造比特币 FT，也就是同质化代币。
BRC-20 通过 Ordinals 协议，将统一的 JSON 格式的文本数据写入聪，该文本数据便是 BRC-20 代币的记账本，根据该文本数据可以解析出代币持有以及转移情况。主要包含以下内容：
{“p”:”brc-20”,“op”:”deploy”,“tick”:”ordi”,“max”:”21000000”,“lim”:”1000”}
{“p”:”brc-20”,“op”:”mint”,“tick”:”ordi”,“amt”:”1000”}
{“p”:”brc-20”,“op”:”transfer”,“tick”:”ordi”,“amt”:”1000”,}
以上是 BRC-20 的三种标准，其中，op 字段表示的是需要执行的操作，包括 deploy（部署）、mint（铸造）以及 transfer（转移），tick 表示的是需要执行操作的代币名称，max 表示代币发行总量，lim 表示每份代币最大铸币数量，amt 表示需要操作的代币数量，在 transfer 标准中，还存在 “to” 等字段，但这不是必须的，transfer 是通过将该铭文发送给目标地址来实现余额变化，如下图所示：
2. ARC-20
ARC-20 依然是比特币公链上的铭文协议，和 BRC-20 协议一样，都是在 UTXO 里面写入标准的数据来实现，但不同的是 ARC-20 协议不用在数据中指定 ARC-20 代币的数量，而是使用该 UTXO 中的 sats（聪，比特币最小单位）来表示 ARC-20 代币的数量，规则是 1 sat=1 ARC-20 token。
ARC-20 协议与 BRC-20 协议一样，也分为部署、铸造、转移三个步骤，其中部署阶段，需要向 UTXO 中填入标准的代币名称、代币总量、铸造限制、区块信息、图像信息等；铸造阶段，需要用户将代币的名称填入 UTXO，而该 UTXO 的 sats 数量便为 ARC-20 代币的铸造数量，并非和代币名称一起填入 UTXO；当用户铸造了 ARC-20 代币，便可以将代币发送给其他地址，在发送代币时，用户不需要再向 UTXO 里面填入任何数据，而是直接将持有该代币的 UTXO 转移给其他地址。
查询 ARC-20 代币时，只需要一个索引，线下索引服务器便可以读取代币注册信息以及铸造和转移交易，不需要服务器去计算资金转移关系，查询地址所拥有的 ARC-20 代币数量，直接读取持有该代币的 UTXO 的 sats 数量便可以得到。
了解了 BRC-20 和 ARC-20 之后，大家应该知道为什么有些会误将铭文资产转到其它地址或是 “燃烧” 掉了。
由于 BRC-20 和 ARC-20 这类 BTC 铭文协议是基于 UTXO 交易的，因此铭文交易实际上是附加在 BTC 交易中的，用户可能会在不完全理解铭文的情况下进行普通的 BTC 转账操作，将其现在的 UTXO 和其他 UTXO 进行融合拆分后发送给非预想的地址，从而导致铭文资产被误转或是被 “燃烧”，造成不可逆转的损失。
3. Ethscription
Ethscription 是以太坊上创建和共享数据的协议，某些铭文便是使用该协议从而替代智能合约实现代币发行的方案，使用铭文可以将用户的成本降至极低。
以太坊在发送交易时，提供了一个 calldata 的数据块，一般情况下普通 ETH 转账该数据块会留白，如果是调用智能合约，则该数据块将指定为调用函数的签名以及各个参数数据。Ethscription 协议便是利用了 calldata 这一数据块，在发送普通 ETH 转账的情况下，添加一些标准的数据，从而赋予相关的含义。
Ethscription 是如何规定这些标准数据的呢？
首先如果想要创建一个 Ethscription，其内容为图像数据，需要将图像（图像大小限制在 96KB）转换为 Base64 编码数据的 URI，格式为 (data:image/png;base64,...)；接下来将该 URI 转换为 16 进制字符串；通过以太坊向目标地址发送一笔普通转账交易，并且将上述的 16 进制字符串填入 calldata，如下图：
这样一来，0xf1bf 地址便拥有了该 Ethscription，并且在之后创建的相同 calldata 的 Ethscription 将被视为无效。
如果想要转移该 Ethscription，就需要 Ethscription 拥有者向接收地址发送一笔普通转账，并且在 calldata 中填入创建该 Ethscription 的交易哈希，则接收地址便拥有了该 Ethscription，如下图：
4. EVM 区块链的铭文
对于 BSC Chain、以太坊、polygon 等 EVM 区块链，有一套共有的铭文刻录方法，就是利用 calldata 数据块存储固定的格式数据，与上述保存图像数据不同，该方式是向 calldata 中写入标准格式的文本数据。
在 BSC Chain 上刻录铭文，其铭刻格式与 BRC20 铭刻格式类似，例如铭刻格式为：data:,{"p":"_","op":"_","tick":"_","amt":"_"}，则其中 p 字段所代表的是协议名称，如 bsc-20、bnbs-20、ltc-20、bep-20、drc-20、nrc-20、src-20 等等；op 字段所代表的是操作，一般为”mint”；tick 字段所代表的是代币名称；amt 字段所代表的是代币数量。
这里用以 bnbs 代币为例，我们可以看到，只要向目标地址发送一笔普通转账，在 calldata 中填入 data:,{"p":"bsc-20","op":"mint","tick":"bnbs","amt":"1000"} 便完成了 bnbs 代币铸造操作，如下图。此时，0x22ef 地址便拥有了 1000 枚 bnbs 代币。
接下来需要转移代币，和上述一样，需要向接收地址发送一笔普通转账，并将创建该 bnbs 代币的交易哈希填入 calldata，则接收地址便拥有了 bnbs 代币，如下图：
以太坊、polygon 等链上也基本相同，但需要注意一点，上述 BSC Chain 的内容并不是 evm 链上创建铭文的唯一情况，不同 evm 链或不同协议之间填入的文本数据字段可能存在区别，转移代币的方式也可能存在区别。但对于这类方式来说，都是利用了 EVM 链中的 calldata 属性来实现的，也就显得大同小异。
总结
本篇文章我们讨论了多条链上的铭文实现原理。总结来说，介绍的铭文都是利用一些公链系统特性，将线下信息按照规定的标准保存在区块链，并通过线下服务器进行识别展示的过程。介绍的这些铭文都未使用智能合约，用户在参与的时候可以减少大量的交易额外费用，但用户需充分理解铭文协议的实现方式，避免误转账或误燃烧铭文，造成资产损失。
