引介： 如下所有内容来自于 BEVM 开发团队。
币圈第一大 发币协议 erc20 ，他有如下的功绩。
- 成就了 以太坊，让以太坊 的EVM 智能合约平台 成为当下的最主流。
- 成就了 Defi， erc20 token 的出现， 让项目方可以使用去中心化的token 去服务于 去中心化金融业务。
- 成就了去中心化 融资和创业，因为 投资方和创业项目方 只需要 链上 token 对 ETH的 价值交换。 典型的用例是 ICO。
当下新公链的叙事，都是在复制 以太坊的成功之路， 想扶持自己的 erc20。怎样才能做出属于自己平台的ERC20 ？
- 新公链的市值要足够大，所以Solana 一直 在狂拉，一度超过了 ETH 市值的 20%， 想要夯实自己的地基。
- 发币协议要创新， 不能单纯的erc20 复制。
- 要得到 广大社群 的认可。
对比了上面的 ERC20 成就之路和新 发币协议的突围之路。 当下最有可能超越 erc20 发币的协议的发币协议是 Runes。理由：
- #Bitcoin 的市值占加密货币市值的50%， 地基最牢固， 地基甚至远超 以太坊地基。
- #BRC20 铭文 出来， 公平发射的逻辑 足够创新，得到了广大用户的认可。
- Runes 协议是在 #BRC20 公平发射的基础上，衍生迭代的新发币协议，兼容了 #BRC20 和 #ERC20 的优势，同时又是 #BTC 主网上的发币协议。
Runes 的基本特征
- 1， 利用UTXO所携带的op_return 来描述 代币的 deploy，mint， transfer 等基本操作以及所携带的代币信息。
- 2， 代币发行者，可以定制 类似 #BRC20 的完全公平发射， 也可以定制 #ERC20的 团队机构募资流程。 同时也支持 两者兼顾，一部分用于公平发射，另外一部分用于团队预留。
Runes VS BRC20
- 更灵活： BRC20 只能公平发射，不利于团队募资和融资。而 Runes 可以。
- 更方便：BRC20 transfer 时，必须先铭刻，发一笔交易，然后再 transfer，需要很重的外部检索器来溯源历史。 而基于 UTXO op_return的 Runes 每个 UTXO 中带着 操作码和信息，不需要额外铭刻交易， 只需要轻量级的 检索器。 给 BTC网络不会造成 大规模的 小额UTXO的粉尘攻击，也给用户节省了 交易手续费成本。
- 可以并发， 比如一笔交易里带一个 op_return 加 M（M为整数，比如可以设置为1000）个地址，一笔交易就能平均发送给 M个用户。 哈哈，这有点类似于微信红包基础送红包功能。
Runes VS ERC20
- erc20 的地基是 ETH， Runes 的地基是 BTC， Runes 的地基更牢固。
- erc20 从2016年以来，已经有很多闭环的商业和很大的生态， Runes 还没正式开始， erc20 有先发优势和规模效应。
- Runes 更新， 炒新不吵旧， Runes 更有时髦性和 发财的大机会。
- Runes 兼容铭文 brc20 的公平发射。
- erc20 有图灵完备的EVM 主网支撑其商业闭环， Runes可以利用BTC Layer2 来完成 以太坊的图灵完备带来的商业逻辑。
Runes 发币协议的一些细节
deploy：通过构造op_return中带有如下信息的交易来实现符文的部署
#[derive(Default, Serialize, Debug, PartialEq, Copy, Clone)]
pub struct Etching {
// 通过rune和spacers来决定需要部署的符文表示符号
// 如: rune: 39116, spacers:0 <===> BEVM
// 如: rune: 39116, spacers:1 <===> B•EVM
pub rune: Option<Rune>, // rune的内部数字id
pub spacers: u32, // rune换成字符串带有间隔符的显示方案？
// 利用mint来表示fair mint的规则
pub mint: Option<Mint>, // 用于定义mint的规则
// 利用divisibility和symbol来标识符文代币的余额
// 如balance: 1100 divisibility: 3 symbol: '$' <===> 1.1$
pub divisibility: u8, // 精度
pub symbol: Option<char>, // 符文的symbol
}
#[derive(Default, Serialize, Debug, PartialEq, Copy, Clone)]
pub struct Mint {
pub deadline: Option<u32>, // 利用deadline来表示fair mint截止时间戳
pub limit: Option<u128>, // 利用limit来表示fair mint每次可以mint的最大数量
pub term: Option<u32>, // 利用term来表示fair mint截止区块高度
}
在Deploy交易中，可以在op_return中同时带有如下信息来实现部署的同时项目方预留代币：
#[derive(Default, Serialize, Debug, PartialEq, Copy, Clone)]
pub struct Edict {
pub id: RuneId, // deploy时填0就好
pub amount: u128, // 指定数量
pub output: u128, // 指定符文mint到哪一个输出
}
部署的符文有3种启动方式：
- term设置为0，带有Edict，代表部署的符文全部在项目方手中
- term不为0，不带有Edict，代表项目方不预留符文，在满足deadline和term两个约束条件时可以fair mint
- term不为0，带有Edict，代表项目方预留符文，在满足deadline和term两个约束条件时可以fair mint
Mint： 满足约束条件下，只需要在op_return中带有如下信息，即可实现mint，mint的数量在部署的时候已经进行了限定
pub struct Runestone {
// 符文id，在部署的时候自动唯一确定
pub claim: Option<RuneId>,
}
Transfer： 输入利用带有符文的utxo，然后利用op_return带有Edict信息，指定转账到哪一个utxo
#[derive(Default, Serialize, Debug, PartialEq, Copy, Clone)]
pub struct Edict {
pub id: RuneId, // 符文id，在部署的时候自动唯一确定
pub amount: u128, // 指定数量
pub output: u128, // 指定符文transfer到哪一个输出
}
