Move: 一门面向资产的编程语言

最近被 Libra 刷了屏。好多人都在谈论 Libra 对未来的影响，有从正面讨论的，认为会影响未来的数字经济，也有负面的，说我们还是逃不过被各大财阀控制的悲剧；有说 Facebook 在推动世界进步的，也有说小扎阴谋论的。这篇文章里，我们就不谈这些了，作为一名Developer，我们聊聊 Libra 附带推出的 Move 这门语言好了。

过去好像“无所不能”

作为一名区块链“从业者”，自从业以来，总有一种感觉————区块链这个新兴的技术，在写代码的时候能做的事情太多了。这并不是一种夸赞。我一直觉得总有一天区块链的世界里应该也会出现“编程范式”一样的东西来限制大家能做什么，不能做什么。

先来看几个例子：

基于以太坊的智能合约

Solidity 让你可以做很多事情，比如去年我尝试写一个颁发 Token 的智能合约。简单的实现了我自己期待的 Issue，Transfer，Destroy 方法，就可以了。

当然，假如你知道 OpenZeppelin 的话，把它引到代码库中，然后实现它里面的 ERC-20 就更完美了。

可是问题在于，它赋予了你选择的权利，你可以用也可以不用，那么你完全可以随意写一个 Token 然后部署到 Production 上，然后就会遇到各种奇奇怪怪的问题。比如：

1. 双花问题： 客户的 Token 可以被花两次。
2. 重入攻击： 以太坊 “DAO” 项目遇到的问题，黑客可以利用这个 Bug 无限的向自己的账户中转账，直到合约的余额为 0。

问题在于，以太坊让我可以很自由的去做很多事情，定义很多事情。

基于 Corda 的智能合约

从去年就开始在一个用 Corda 的项目上，从开始接触 Corda 到后来使用 Kotlin 写 Corda 的智能合约，就一直有一个苦恼，要写的 Corda 的逻辑几乎超过了业务逻辑。

我们消耗了大量的时间去处理，交易发起方应该找谁索要签名；作为交易接收方要如何处理，等一系列诸如此类的问题。

我们暂且抛开 Corda 的自身原因不谈，但是我一直纳闷，为什么想要专心写业务逻辑这么麻烦，为什么要把业务逻辑和这些区块链的业务混在一起呢？

问题在于，Corda 给我的灵活度更高，可是随之而来的风险也就越多。

从上面来看，我们会发现，区块链作为一个新兴的技术赋予了 Developer 太多的能力，而这些能力是没有过多的限制的，以太坊不会限制我的资产要怎么交易，因为我的资产在以太坊上只是智能合约里面的数据而已；Corda 不会限制我找谁签名或者做什么验证，因为 Corda 是把这些权利放给了 Developer 的。

可是，有时候没有限制，并不是一件好事。就像“编程范式”一样，我一直在想，是不是有一天，区块链也会出现自己的“编程范式”，规定 Developer 能做什么，不能做什么。比如规定作为一个资产，它是不能被复制，不能被随意销毁的。

过去，区