Runes 发币协议 或可 超越 Erc20 发币协议, 成为币圈 项目发币的新天地。

guanghua
发布于 阅读 111

引介: 如下所有内容来自于 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到哪一个输出
}
标签: 每日闲话
评论