Moveinscription 源码系列(三)

  • sycute
  • 更新于 2024-03-26 09:06
  • 阅读 764

Moveinscription 源码系列(三)

继续学习 Movescriptions 合约源码。

1. epoch_bus_factory 模块

这个模块主要是用来部署“MOVE”铭文,提供 mint 功能 以前版本的MOVE铭文是在movescription::init函数中部署的,现在改了,需要主动调用 此外,还为TICK_NAME铭文提供接口

1.1 结构体

struct EpochRecord has store {
  epoch: u64,
  start_time_ms: u64,
  players: vector<address>,
  locked_sui: Table<address, Balance<SUI>>,
}

struct EpochBusFactory has store {
  init_locked_sui: u64,
  start_time_ms: u64,
  epoch_count: u64,
  epoch_amount: u64,
  current_epoch: u64,
  epoch_records: Table<u64, EpochRecord>,
}

很明显这两个结构体是用来记录 epoch 的。 以前版本,这个功能是 TickRecord.epoch_records 字段来记录。现在拆分到了单独的结构体中 接下来讲解函数的时候我们会看到怎么使用这个结构体

1.2 MOVE铭文起源

原始版本在movedescription::init函数中部署 MOVE,这个版本有所不同,改成了在 deploy_move_tick 函数中部署 此版本不影响主网上的原始版本。 这个函数将在 init.move 合约的 init_protocol 函数中统一调用

public fun deploy_move_tick(deploy_record: &mut DeployRecord, ctx: &mut TxContext)

函数内部还是调用了 movescription 合约中的部署函数来完成功能 let tick_record = movescription::internal_deploy_with_witness(...)

新版本中 MOVE 铭文用来铸造别的内置铭文

1.3 部署自定义铭文

这个版本发生了改变,在本合约中部署其他类型铭文,不再需要 MOVE 铭文,而是需要 TICK 铭文 TICK 铭文的来源是 tick_factory 模块,后面会详细讲到。

部署铭文的函数调用关系如下: public entry fun deploy --> public fun do_deploy --> tick_factory::do_deploy

do_deploy 函数会校验 tick_name 是否为TICK,限制了只能使用TICK铭文铸造新铭文。 部署新铭文的玩法除了变成消耗 TICK 铭文外,和之前版本相同。铭文消耗之后会将里面锁定的 SUI 返回给玩家

另外,这个版本的部署逻辑有一个明显的改变。之前版本中记录 epoch 的字段在 new TickRecord 的时候就会创建,现在新建的 TickRecordV2 中没有该字段,要通过 after_deploy 函数添加

fun after_deploy(
  tick_record: TickRecordV2,
  total_supply: u64,
  init_locked_sui: u64,
  start_time_ms: u64,
  epoch_count: u64, ctx: &mut TxContext)

这个函数将在每个 deploy 操作后调用,在新建的 TickRecordV2 结构体上添加动态字段,字段值为 EpochBusFactory 对象,字段名调用以下函数获取:

public fun type_to_name<T>() : String {type_name::into_string(type_name::get_with_original_ids<T>())}

其中 T 就是 EpochBusFactory 对象的类型

1.4 mint 函数

和之前版本相比,mint 的逻辑和功能都没有改变,只是最后分发铭文的代码放到了movescription::do_mint_with_witness函数中,对于玩家来说,打铭文的玩法和之前没有任何变化,彩蛋也相同。

此外,本合约同样提供了升级版本的函数,如migrate_tick_record_to_v2,升级逻辑和 Movescriptions模块中的基本类似,这里不再赘述。

2. tick_factory 模块

这个合约主要用来创建 TICK 铭文,并消耗 TICK 铭文用来部署新的铭文。

2.1 部署TICK铭文。

public fun deploy_tick_tick(deploy_record: &mut DeployRecord, ctx: &mut TxContext) 和部署 MOVE 铭文基本相同,这个函数将在 init 模块的 init_protocol 函数中统一调用。

  1. 铸造 TICK 铭文

    public fun do_mint(
     tick_tick_record: &mut TickRecordV2,
     locked_move: Movescription,
     tick_name: vector<u8>,
     clock: &Clock,
     ctx: &mut TxContext) : Movescription

    这个函数是消耗 MOVE 来铸造 TICK 铭文的函数,locked_move 必须是 MOVE 铭文。 函数将铸造一个 amount=1SUI=0TICK 铭文,并把 locked_move 铭文锁进去 这个"锁进去"指的是使用上一篇文章中提到的铭文嵌套的方式,将 MOVE 铭文嵌套进 TICK 当然,当 TICK 铭文被 burn 销毁后,MOVE 会被返回给钱包。

    新版本的合约在部署新铭文的时候,多了一个流程,即 MOVE --> TICK --> 新铭文

  2. 部署新的铭文 前面讲 epoch_bus_factory 合约部署新铭文的时候,要调用 tick_factory::do_deploy

    public fun do_deploy<W: drop>(
     deploy_record: &mut DeployRecord,
     tick_tick_record: &mut TickRecordV2,
     tick_name_movescription: Movescription,
     total_supply: u64,
     burnable: bool,
     _witness: W,
     clk: &Clock,
     ctx: &mut TxContext
    ) : TickRecordV2

    部署新铭文要消耗 TICK 铭文,这个函数将 burntick_name_movescription 铭文,然后部署新的铭文。 要注意,这个新铭文的名称使用的是 tick_name_movescription 中的 metadata.content,而不是其中的 tick 字段。 所以新版本的合约,不再直接消耗 MOVE 铭文部署新铭文,而改成了消耗 TICK

  3. 销毁铭文

通用的销毁逻辑。

3. name_factory 模块

这个模块和上面的 tick_factor模块 逻辑非常相似,主要功能是:

1.部署 NAME 铭文

2.铸造 NAME 铭文

3.销毁 NAME 铭文

区别在于,TICK 铭文用来部署别的铭文,而 NAME 铭文用来表达个人或者组织的 Name 个人或组织的名称记录在 NAME 铭文的 matadata中。

TICK 铭文 业务流程为: MOVE --> TICK:{tick:"TICK",metadata:要部署的铭文名称} --> 部署铭文

NAME 业务流程为: MOVE -->NAME:{tick:"NAME",metadata:个人或者组织的名称}

项目方关于 NAME 铭文的解释

总结

智能铭文 Movescriptions 项目的主要模块分析完毕了 新版本的合约中,一共有 4 种内置铭文,分别是"MOVE","TICK","NAME","TEST"。 其中 TEST 是用来测试的,我们并不关注 TICK 用来部署铭文,NAME用户 id,各有用途 整个合约比之前复杂很多,考虑了更多的安全性和扩展性。

点赞 1
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
sycute
sycute
0x80d6...FdC9
电报联系 @luosanzhang