Move 团队交流问题收集

Move 团队交流问题收集

请列举出自己关心的 Move 相关的问题。

基础类型的扩充以及 Math 的增强

能否支持 u256

能否支持判断计算是否溢出的办法

能否支持类似 rust 中的 saturating_sub 和 saturating_add

语法和类型系统

friend可见性的使用有没有可能简化或者增强？比如 address 可见或者跨 address 可见

Struct public field 以及反序列化支持，这样 struct 可作为交易参数

开发工具方面的增强

多版本 bytecode 编译的支持，比如用 v3 的编译器编译出 v2 版本的二进制

unit-test 的初始化

类似 GDB或者LLDB一类的调试工具

复杂项目的工程化，Solidity很难构建复杂系统，Move有没有这方面的考虑

Map 的支持

与泛型结合，存储已知的支持泛型的类型，不需要 signer。

全局排重

是否有可能申明一种带所有权的 Map，将 move_to/move_from/global_borrow 指令通过 Map 的操作表达出来。

在swap和bridge项目开发过程中，使用Move遇到一些问题：

大数计算

背景1：bridge打通以太坊等主流资产跨链到starcoin，以太坊生态里大量项目使用18位的decimal，类型为u256，而move里最大为u128，最大可以表示约39位长度的uint，为了兼容两条公链，需要在bridge里实现以太坊u256的兼容逻辑。

背景2：swap项目中，有对个地方涉及到u128 * u128的乘法，以及大数的除法，为了避免溢出或者丢失精度，额外封装了SafeMath来处理大数运算，但也只能保证部分场景有效。

诉求：不论是Move自有生态的发展诉求，还是从其他生态迁移过来，native u256都是一个很重要的特性，提供大数计算能力。

Mapping

背景：Move的理念是每一份resource都在owner的存储空间，且具备状态计费的能力，这一点比以太坊是很大的一个优势。而Mapping恰恰是违背这个理念的。在bridge项目中，需要在合约里对全局全量交易进行排重，不支持淘汰和过期，暂时的实现思路是链下维护全量交易，链上仅存储存在性proof证明，来实现全量全局排重需求。不过整个方案还是有些复杂，尤其是给到生态内的项目使用，有一定的门槛。

需求：是否有从语言层面，更优雅的对Mapping类场景的解决方案？

String

背景：Move中没有string类型，用vector<u8>来表示字符串。在开发bridge项目中，为了比对和验证两条公链签名和验签的一致性，写了大量测试代码来验证。一个痛点是，当想把Move中生成的签名在Solidity中测试是，只能拷贝bytes，非常不直观。相信在多个生态迁移时，这个问题会普遍遇到，虽然不影响功能，但确实是一个很麻烦的点。

需求：能否考虑对string的原生支持。

在借贷项目开发过程中，使用 Move 遇到的一些问题：

1. Move 最大只支持 u128，并且不支持小数

   1. Move 不支持小数。我们为此实现了固定精度的计算，我们设定的固定小数位有 18位（因为当前的币最大的小数位是 18）。固定精度比浮动精度有更好的计算准确度。

   2. 在做 Defi 应用时，我们需要准确的计算。为了实现这一目的，我们使用了上述固定精度，当遇到乘法时极容易出现计算溢出错误。u128 能代表 3×10^38 表达空间，当我们使用两个固定小数位是 18 的数进行乘法计算时，极易溢出（n×10^18 × m*10^18）

2.调试的易用性.Debug 断点

合约调试暂时只能使用输出特定数字的方式进行问题定位。能否考虑支持 Debug 工具，可以断点调试，以提高调试的易用性

3.module 管理

4.全局常量

如何推广 Move

区块链圈子里的很多人认为 Solidity 和 Evm 已经占据了主导地位，类似于当年的 javascript，其他的竞争者已经没有机会了。我们需要一起努力想办法推广 Move，构建 Move 生态，改变这种看法。