StarcoinFramework 2.0 资产映射工作清单

By Bob
1 min

目的

本文目的主要是为了整理和讨论资产Framework2.0资产映射相关的一些工作和备忘，以及上线时的一些操作等。

该工作主要包含了以下清单：

  1. STC 资产，Starcoin Native Token

  2. Starswap 资产

  3. Bridge 资产

  4. NFT 资产

  5. 不具备Owner权限的资产（FAI、DAI、XUSDT）

  6. Starmask 针对 2.0 的升级

 

STC 资产

1.主网STC用户资产 和 state proof证明导出

  1. 2.0 genesis 隐射资产和证明流程

Starswap资产 @Bob

Starswap相关合约工作
所有链上模块适配2.0的改造
单元测试
集成测试
工具类基础模块
YieldFarming 基础
Swap流动池
单币池（Syrup）
双币池（Farming）
Boost
回购
链下相关接口检查与变更
starswap-info 前端
starswap-info 后端
starmask 前端
池子的资产映射工作
链上操作池基于映射数值的初始逻辑
双币池（Farming）
单币池（Syrup）
Swap 流动池（Swap Liquidity Pool）
回购（Buy back）
Boost
用户持仓映射，即用户Resource中Stake那部分的数据
链上处理：Starswap 大版本升级前&升级后的映射处理逻辑
链下处理：映射执行驱动 – 1.0数据读取后逐一调用升级合约执行映射的逻辑 @YSG

Bridge 资产 @hui jiao

  1. 支持signature native functions，比如ed25519_validate_pubkey, ed25519_verify, native_ecrecover

  2. 支持Signature/EVMAddress move script

  3. 处理Account/Token/STC相关流程：

    1. treasury deposit/mint

    2. TokenCode

    3. STC store

  4. Event相关问题：friend issue，deprecated functions

  5. Number precision：u128->u64, u256->u128

  6.  

 

NFT资产

NFTGallary 资源

 

不具备Owner权限的资产

总的来说分为两步，一 Genesis 负责查找并处理映射，二、项目方确定是否处理，若处理则可以通过第一步创建出来的user_address::legecy_coin 来管理旧代币

需要链下Rust实现以下逻辑

  1. 读取资产名称，找到对应的资产创建者地址

  2. 为该地址使用Genesis权限部署一个Legecy合约地址，作为替代的映射资产，并提供相应的提取与销毁操作，参考以下合约

// 提供见证参数类型 module starcoin_framework::asset_mapping { struct LegecyCoinWitness<phantom T> { root_hash: string::String, height: u64, amount: u64 } } // 资产映射临时存放模块， module user_address::legecy_coin { struct FAI {} struct ABC {} struct CoinStore<phantom T> { coin: Coin<T> witness: asset_mapping::LegecyCoinWitness<T> // 该参数存在的意义就是为了证明该合约的resource由资产映射而来 } // 初始函数，genesis调用 public entry fun initialize<T>( genesis: &signer, mapping_amount: u128, ) { managed_coin::initialize(...); let legecy_coins = managed_coin::mint(..., mapping_amount); witness :LegecyTokenWitness<T> // 见证参数，只有genesis可以构造 } public fun withdraw<T>(): coin::Coin<T> { ... } public fun burn<T>(coin: coin::Coin<T>) { ... } // 映射函数，gensis函数调用 public fun mapping_assign<T>(genesis: &signer, amount: u128, ... proof_params ...) { ... } }

  1. 使用链下逻辑找到持仓用户，调用mapping_assign为其分配对应额度的legecy_coin

  2. 若项目方自行处理，则自己部署对应合约后，通过legecy_coin::burn操作将旧token销毁即可

  3. 其他人可以查看legecy_coin::CoinStore/witness 来确认其映射的root hash、高度，以及映射发行的额度

问题

如何处理代币在其它不具备Owner权限的合约中的映射？

目前可以确定单个token的发行总量，但在映射后，我们需要考虑在user_address::legecy_coin模块中映射的数量。此时，是否需要计算其分布，并将其在其他合约中的额度铸造并暂时存储？

对上面的问题的进一步解释：即在映射的过程中，通过对比查找所有账户的资源的关键字，计算该Token在不同合约中的分布比例，可以得到该Token的分布场景：

  1. 用户持有的，即0x1::Account::Balance<FAI>

  2. 存在于Starswap中

  3. 存在于不具备Owner权限的合约路径中

针对上述三个场景，前两个场景的处理相对简单，但对于第三个场景，我们该如何应对？

  1. 对于场景1，我们可以直接将其映射到用户的coin::Store<T>中；

  2. 对于场景2，我们可以将其映射到Starswap中。

  3. 对于场景3：

    1. 如果该路径属于用户的代币经济治理路径，我们可以直接将其存入legecy_coin::CoinStore，表示已完成映射。

    2. 此处经讨论，如果是质押在其他swap的情况，则直接将其释放到质押给当前swap 的 owner的路径下

Starmask 针对 2.0 的升级

  1. Balacne 相关资源路径的变动

  2. NFTGallary 相关资源路径变动

 

Related content