信息安全从业者Aus. Liu：漫谈比特币之上的智能合约

信息安全从业者 Aus. Liu

9月7日，Bitcoin Association（比特币协会）与OKEx、链得得联合在中国北京举办了一场BSV开发与商业生态大会，嘉楠耘智、wework作为协办方鼎力支持了此次活动。

这次活动是Bitcoin Association（下文简称BA）设置中国区域负责人以来的首次线下亮相，同时也是Bitcoin SV在中国地区的第一场官方活动。

作为一个信息安全从业者，Aus.Liu从黑客的思路出发对比特币之上的智能合约的进行了分析，他列举了以太坊智能合约的三大问题：一、货币模型限制了业务模型；二、问题是链上定义的VM限制了开发；第三个问题是复杂度的问题。

经过整理编辑，Aus.Liu的演讲全文如下：

我是Aus.Liu，其它地方也用Monkeylord作名字。我是一个信息安全从业者，也是BSV上的一个独立开发者。这可能使我和其它的开发者不太一样，因为我习惯采用一些黑客的思路。

黑客思路是什么样的呢？上学时，有辩论队的同学找到我和室友，原因是他们用的计时软件写死在倒数15秒时提醒，而他们想要倒数30秒。那怎么办？室友说他可以做个一模一样的，做成30秒。而我的思路是什么呢？我说的是我可以通过底层手段把程序内部写死的15改成30。

所以，我的室友成为了一个很好的开发者，他的工程能力很强，而我成为一个安全从业者，这就是不同的思路导致的。

    黑客思路的人，对于比特币会有什么样不同的关注？我会更关注底层细微的改变能够带来怎样的可能性，找各种别人想不到的使用场景。所以开发者一般会恨安全从业者，刚开发一个功能，还在吃着火锅唱着歌就被找到一种奇特的用法，然后对于开发来说便是漏洞，就得加班。作为安全出身的开发者，我就喜欢各种各样的可能性，很简单的边界条件变化会带来很大不同。

回归比特币，我们来用这种思路讨论比特币上的智能合约。BSV的扩容和解除限制这样看上去不明显的改变，会带来怎么样的可能性呢？

表面看上去只是容量大了，但是这个容量大了其实带来了巨大的质变。这个质变是什么，大家和我一起探索一下吧。

从一个演示开始

首先我想从一个演示开始，我们看到这个状态灯泡现在是灭的，我们按一下开关，灯泡的状态就变成了亮，再按一下开关，灯泡就会灭。在任何你能访问BSV的地方，你都可以得到灯泡当前的状态。

  这个演示在链上：https://bico.media/15stvxuJ9fzQrshxX8WNzuxeMsNcGQp1AY/Demo/lightbuble.html

实际上，每次按开关的动作都会在BSV链上发一个Tx，这个Tx包含了定义的按开关动作。当需要获取灯泡状态时，通过BitDB把所有按开关动作都取到，我就可以计算出当前灯泡的状态，那这个当前灯泡的状态它到底是什么样的状态呢？完全取决于你按开关的次数。这样实际上构成了一种链上的状态，或者说构成了一种链上状态机。

记住这个演示，我们来看链上存储。

确定性的记录

许多人对BSV的扩容的意义有疑问，虽说目前上限扩到了2G，可实际用处时什么呢？很多人觉得这不过意味着BSV能够作为网盘，而区块链网盘又贵又低效。

实际上这种扩容仅仅是网盘吗？要回答这个问题，就要回到一个更本质的问题，即——链上存储的数据，只是单纯的数据吗？链上存储和普通的云存储的本质区别在哪里？

如果你足够敏锐，你会发现，PoW赋信，和不可篡改。存储一旦上链，就具有和PoW一样高的确定性，并可以公开访问。对于确定性和不可篡改的信任，是云存储难以提供的。比特币上的数据存储，实际上就是提供了这样一种不可篡改并且能够公共访问的数据源。

那么，数据又是什么呢？数据不仅仅是静态的文件，不仅仅是文本和视频，其实一切东西都是数据，用户的业务请求，服务器种运行的代码，同样也是数据。或者说数据本身是一种状态，而状态的表示也是数据。世界上各种各样的复杂状态都可以被规范化地表示为数据，作为历史被区块链记录，就像WeatherSV做的事情，成为确定性的记录。

比特币包含的记录的确定性是由熵保证的，这是PoS或者BFT所难以达到的。那么这种确定性的记录能在智能合约方面带来什么改变呢？我们得先来看智能合约的本质，状态机。

确定性有限状态自动机

其实我们谈论智能合约的时候，智能合约究竟是什么东西？

程序员大概都了解一个东西，叫有限状态自动机，或者叫确定性有限状态自动机，即DFA，这个东西其实是各种各样程序的基础。

包括像以太坊或者各种各样的智能合约的公链，实际上在构建一种状态机，这种状态机接受输入，产生状态转移。输入可能是交易或操作码，链上状态机接受输入，改变链上的状态比如账户金额，或者链上的其他状态。

各种程序其实都是状态机，比如之前的灯泡演示，灯泡有亮灭两种状态，按按钮是输入，产生两种状态间的状态转移。

我们从更准确一点的定义来看DFA是什么的话，它其实是一个五元组：一个非空的有限状态集合、输入字母表、状态转移函数、开始的状态、接受状态的集合。

我们用这种定义反思一下链上的VM，当我们谈论链上的智能合约的时候，我们需要的是一个什么东西？我们要的其实是一个公开的可验证的确定性的状态，以及确定性的状态转移函数。比如说，我们想要某种代币或合约时，我们真正关心的其实不是程序如何运行，而是要的功能（比如转账）能够确定性地实现，并且可验证，任何人无法篡改。

在这个过程中，合约或链规定了初始状态、接受状态以及状态集合，用户提供了输入并且被记录，状态转移函数则设置在共识里。从而产生确定性的状态。从以太坊发源的一系列智能合约的区块链，都是这么干的。

然而，把状态转移函数定义在共识里，存在几个严重的问题。

以太坊方式智能合约的问题

第一个问题是货币模型限制了业务模型。尽管图灵完备意味着可以做任何程序，但是，要将业务场景匹配到货币模型上，始终是一件很困难的事情。

许多业务模型不但不是货币模型，甚至难以用货币模型表达，这导致了传统业务很难在智能合约上开发，因为将其他业务模型翻译为货币模型是难度非常高的工作。以至于相对成功的智能合约往往局限于代币或数字资产这种天然适合货币模型的场景。而大众乃至开发者们对智能合约的理解也往往局限在代币和数字资产上。

第二个问题是链上定义的VM限制了开发，若为了区块链能够运行和扩容，共识中的状态转移函数就必须越简单越好，然而这样的话，开发就变得复杂了。虽然技术方面会有很多牛人写编译器，但是依然，很难复用各种语言生态中的组件。

这极大地提高了智能合约的技术门槛，再加上模型的翻译，门槛就更高了，这使得开发难以大规模进行（当然从制造门槛提高职业收入上，这倒不错）。作为一个喜欢用JS的伪全栈工程师，用JS写前端，用JS写后端，用JS访问数据库，为何就不能用用Chrome V8引擎跑链上VM呢。做不到，因为VM已经被定义好了，无法自己选择。

第三个问题是复杂度的问题。状态转移的计算在共识层中，这带来了严重的性能问题，网络拥有大量算力，然而整个链的处理能力却比不过一台古老的家用计算机。能否完整地承载一个通常的程序都困难。

许多商业服务里单个高性能服务器都不能满足业务需要了，更别说链上合约了，高吞吐量？基本不可能。这些问题根本的原因是，状态转移函数定义在共识中，所有的节点都必须计算状态转移来进行验证，要不然无法保证状态的确定性。

状态的确定性并不需要计算

有以下计算式：(1087357389+87890345434)*28 + 897733^21388233 - 73004832%3

它的结果是什么？不计算不知道。但是我问你，它的结果是确定的吗？是不是不管谁来计算，结果唯一且不会发生变化？实际上，我们并不需要进行任何的计算就知道结果是确定的。因为我们知道这几个运算都是确定的，用来计算的数字也是已经确定的了。

足够聪明的话，你大概已经明白我要表达的意思了。对于一个DFA，只要它的定义是确定的，状态转移函数是确定的，输入流也是确定的，那么，你并不需要执行状态转移函数，就可以知道执行后的状态是确定的。

这种状态的确定性，是不需要计算的就可以获得的。必须要去计算的，只是想知道具体结果的人，即对当前状态感兴趣的人。所以，要达到智能合约的目的，只需要确定性地定义DFA，以及其状态转移函数，并且产生一个确定性的输入流。

一旦这些都确定了，链上计算，其实是不需要的，因为不论是链上计算还是链下计算，在哪里计算并不会影响结果的确定性。就像那个计算式，你在家里计算和在公园里计算并不会给结果带来任何差别。

BSV扩容产生的本质改变，也就正在于此处了，确定性，而且是PoW保证的确定性。

BSV带来的全新的智能合约可能

那么如何去做呢？原理实际上很简单，其实就是使用BSV存储的确定性，来确定性地定义DFA，你就得到了不可篡改、公开可验证的DFA。通过在BSV链上公开定义状态集合、状态转移函数、开始状态和结束状态，以及，得到确定性的TX输入流的排序方法，一个接受链上输入的链上智能合约就产生了。

在这个里面，能不能自己定义一些复杂的状态对象呢？完全可以。将TX定义为输入时，能不能采用自定义的数据结构呢？完全可以（不符合要求的TX是无效输入，也是一种输入，对应的状态转移是不转移）。定义状态转移函数时，能不能用自己习惯的语言呢？完全可以，只要代码和VM都是确定性的。

灯泡的演示就算是用JS编写的简单链上DFA，实际上这些定义大部分就是JS代码（当然，这里面其实还需要考虑组件的安全性，区块链历史查询不应相信第三方）。

讲解到这里，聪明的人已经懂得如何在BSV上实现这种智能合约了，实际上这就是Tokenized上智能合约的思路之一，也是unwriter为什么称Planaria为Infinite State Machine的原因。

以太坊的分片扩容方案思路，本质上也是放弃链上计算，只让感兴趣的人或分片进行计算。然而可惜的是，以太坊以及其模仿者，终究无法通过这种思路扩容。

为什么以太坊必须进行链上计算

简单来讲，是攻击成本问题。如果以太坊不进行链上计算来验证输入是否有效，那么它就无法阻止攻击者用大量无效输入堵塞状态机，无止境地消耗计算资源。攻击成本为零会让状态计算在计算成本上不可行。

目前的以太坊尽管以太坊有Gas机制来处理无效输入，但是Gas机制也依赖于状态计算，除非以太坊有不依赖EVM状态计算的外部Gas机制。而比特币（BSV）数据存储的手续费价格，正好从攻击成本上解决了这个问题。即便是无效输入，也需要付出数据上链成本，实际上就构成了不依赖合约状态的智能合约的Gas。

其实，构建在比特币二层，使用比特币作为Gas的EVM会是更理想的智能合约引擎。每想及此处，作为一个比特币原教旨主义者，都不免感慨，BTC本应成为智能合约的底层区块链，可惜被各种强加在共识上的限制捆住了手脚。如今这一切的应用开发，其实早在四五年前就应当繁荣发展了，而不是看着Github上一堆在四五年前停止维护的比特币应用项目感叹前人智慧。

幸好我们有了BSV。