...
是否有可能申明一种带所有权的 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 遇到的一些问题：
Move 最大只支持 u128，并且不支持小数
Move 不支持小数。我们为此实现了固定精度的计算，我们设定的固定小数位有 18位（因为当前的币最大的小数位是 18）。固定精度比浮动精度有更好的计算准确度。
在做 Defi 应用时，我们需要准确的计算。为了实现这一目的，我们使用了上述固定精度，当遇到乘法时极容易出现计算溢出错误。u128 能代表 3×10^38 表达空间，当我们使用两个固定小数位是 18 的数进行乘法计算时，极易溢出（n×10^18 × m*10^18）
2.调试的易用性.Debug 断点
合约调试暂时只能使用输出特定数字的方式进行问题定位。能否考虑支持 Debug 工具，可以断点调试，以提高调试的易用性
3.module 管理
4.全局常量
如何推广 Move
区块链圈子里的很多人认为 Solidity 和 Evm 已经占据了主导地位，类似于当年的 javascript，其他的竞争者已经没有机会了。我们需要一起努力想办法推广 Move，构建 Move 生态，改变这种看法。
...