Patract CTO Aten | 未来合约平台的展望，如何突破现有瓶颈？

Original 闫钰承 BeWater Community 2022-01-01

2021年11月4日，在第四期 BeWater Live 上，Patract CTO Aten，在腾讯会议直播间，为大家带来了《未来合约平台的展望》的分享。

这场深度且系统的分享，核心内容：

1、合约到底该不该叫合约

2、合约平台与合约

3、当前合约平台的瓶颈：

- Evm ~ solidity

- pallet-contracts (substrate体系下的wasm合约平台) ~ ink!

- Solana ~ anchor

- Near ~ near SDK

4、合约（程序）的表现力：

- 逻辑建模能力

- 数据建模能力

5、瓶颈突破角度：

- 逻辑建模突破点：语言的表现力、模块的分离程度、执行并行化

- 数据建模能力突破点：跳出K/V模型的约束

BeWater

hello大家好，我是Aten，patract的cto。简单介绍一下 patract (https://patract.io/) 是波卡生态里专注于 Watson 合约相关技术的公司，我们有点类似于像以太坊中的 Consensys 的定位，所以我们主要做一系列的工具及组件来服务于Polkadot 下的 Wasm 的生态里的合约开发者。

今天，我给大家带来的分享主题，是未来合约平台的展望。感谢主持人，感谢bewater社区，我们现在就开始。

一、合约到底该不该叫合约

我第一个主题，其实抛出了一个很奇怪的问题，就是我们为什么要把现在搞的叫做合约？我们正常写个后台应用，或者叫后台代码，但是为什么在以太坊的这个时代里，就被叫成合约了？为什么像 solana，Near 和 dfinity 以后，他们不太喜欢把自己的这套模型再叫合约了？我们从比特币看起。

1、比特币的逻辑

比特币产生了一个点对点现金转移的货币。比特币完成一笔转账，并不是说 A 到 B 有一条记录，然后验签然后就结束；其实是 A 抛出了一个问题，就是我们所说的 UTXO，然后，会有一个 B 来回答这个问题，这就是所谓的input。那当 output ，就是 unspend output 跟 input 能够相互匹配的时候，才叫这笔交易转账成功。这个过程，就叫做比特币脚本的运行条件。这和其他的平台差距是很大的。我们比方说举个例子，我们都知道微信支付宝，它也是服务于这个金融转账的。但是它主要是说我转账就是转账了，没有说我可以让转账的人设立一个可编程的规则。

比特币除了正统的引入了用分布式的思想去解决这个去中心化的问题，还带出另外一个重要的点，即它使货币变成了一种可编程的概念。只不过比特币的可编程概念比较简陋，比特币的脚本跟真正的能够达成复杂逻辑这件事情相比还是有一定差距的。因为比特币脚本设计的核心，是为了完成转账而去达成一个条件。这个过程中是不持有状态的概念的，所以比特币脚本用的最多的情况其实是多签。

2、Contract 到 Dapp

好，那么以太坊延续比特币的这个概念的时候，V 神就要创立一套体系，去执行一个能够让图灵完备的程序，能够运行的体系。

也就是说，以太坊是在货币编程领域上更加扩展了一步，认为说现在所有的经济往来都可以抽象为叫合同的概念。只是说我们以前的合同，需要有实施的履行人去实施的，如果没有他不执行合同，就会有法律来强制执行。而作为去中心化平台的这个计算机，他就可以说我的所有的约定。其实都是可以编写为合同，并且这个约定，可以是一个在无监督第三方自动化的去执行整个过程。所以说，认为合约这个词来形容是最准确的。

另一方面，在引入图灵完备运行的概念后，以太坊还引入状态机的概念。而状态和逻辑加在一起，就很像一个程序的概念，而不是像比特币那样脚本的概念

但是大家要知道。虽然以太坊一开始把自己的这套模型称为“合约”，但是在后期这个词反而被淡化了，大家应该记得在 17 年的时候，开发人员才喜欢提 smart contract，对外宣讲的人更喜欢把自己的整套体系叫做 DAPP。

一方面是以太坊的合约过于简陋，在程序员的直观感受上很难把其当做通用程序去对待，另一方面由于以太坊运行能力过差，基本上开发人员只会把最重要的内容放到合约里，而很多额外的计算都是在链外计算的。

而我们现在把其他链类似的功能也叫合约，实际上是延续了以太坊合约的概念而来。随着新兴的各种公链的各种发起，以及 contract 这个逻辑变得越来越延伸以后，即便是以太坊本身，大家在写的时候一定程度上偏离了一开始被命名为 contract 的这样概念。

3、新的“合约”

比如说我们往下看 solana。solana 大家最近应该了解的很多。在 solana 的术语里面，它是不称之自己的合约，叫做contract的，它会称自己的这个平台上运行的叫做 program。他会认为说我的平台上运行的是程序，而不是说你们平时理解的合约。

Near 还比较老实，他会认为说，我就是合约，只不过我这个合约是以 wasm 的形式写的，但 wasm 已经可以引入内存（堆）的概念了。

但 dfinity，就在前面两者的基础上，还更近了一步，他会把这个叫做容器。这个容器，会是一批的Wasm的代码逻辑和内存页一起构成，请注意，这里引入了一个比较大的设计，叫做内存页。

写过solidity 合约的人应该都知道，其实solidity合约其实是没有内存的概念的，但是，其实往后新发展的各种合约里面，大家也要发现它被称为合约真的是不恰当的。因为合约再怎么说听起来也很像一种特化场景的业务逻辑，但是，和我们正统的程序相比，其实是有很大的差距的。所以说，从这些命名上，我们就可以窥见，其实对于现在新兴的一些合约平台而言，他们其实是在尽力的去摆脱自己叫做合约的这种概念的，要尽可能的把自己发展成一种想象空间更大。或者能执行更多。逻辑和程序，或者说具备更多特性的这样一个平台。

二、当前合约模型对比

好，然后，我们就来简单说一下我们当前合约模型的对比。我们从最左边这块开始。

其实 gavin 在思考以太坊的时候，已经把整个区块链抽象成了一种状态机转换的一种模型。那么延续这个概念继续往下探讨，其实就出现了当前substrate 的设计体系框架。如果写过 substrate 体系的人，应该会很明确的知道说 substrate 的体系，其实把它的整个区块链框架拆成了上层的runtime层和底层的区块链基础层。

如果从狭义上来说，就是任何认为应该进入共识状态的部分，都应该被叫做Runtime层，然后和共识无关的部分，被叫做区块链的底层。

广义上来说，我们所谓的 runtime 层就是这条链的业务逻辑。

比方说以太坊的业务逻辑就是运行 EVM 的平台。比如我用 substrate 直接开发了一个 uniswap 的逻辑功能，那么我这条区块链所干的事情就是能够运行 uniswap 功能的这么一条区块链。我们把比特币的逻辑套过来，那比特币就是能够运行转账业务逻辑的区块链平台。好，那如果有这么一种概念了以后，我们可以继续往下再进一步细化。

我们为什么要用区块链的这种底层去运行上层的业务逻辑？比方说我买了一台阿里云在阿里云上开了一台 ecs，然后我把后端代码部署到阿里云上。区块链我照样可以用相同的方式去理解，我们可以认为开发人员是在 runtime 层中编写了业务逻辑运行在区块链这种平台上。

所以说，从这种模型的角度上来说，我们在区块链上去构建一种业务逻辑，跟你把这段程序放在阿里云或者腾讯云的ECS上运行，其实是没有特别本质上的区别的。

那大家为什么要用区块链去执行？那很显然就是区块链，它提供了像阿里云之类的平台提供不了的东西。这个东西叫做可信平台，或者叫可信环境。请注意，区块链为了满足或者叫达成这种可信环境，他的方法是去假设有成百上千个阿里云，同时在执行相同的内容，并且通过某种协议保持了大家执行的结果是一致的，那么这个就是区块链，也就是说，区块链的可信环境其实是来源于多副本共同执行，并且达成一致的。那么我们先不管去外面的这层上层的 runtime 层，就是在我们这层可信环境上去构建的一种业务层。

而 EVM 是一种特殊的业务逻辑，目的就是为了运行第三方的代码。因此整个生态里面参与的角色，就由原本的链与用户的二元关系，变成了链，用户与第三方的开发者（项目方）的三元关系。这样子，就可以造成说我们当前的合约模型是在原本的区块链的模型上继续抽象出了一层能够运行第三方代码业务的这么一种业务逻辑平台，那么他就从原本的区块链平台，以及参与区块链的人。两方角色演变出了区块链的平台，参与区块链的人，以及能够创造一段新的代码运行到这条链上的第三方开发者。

这件事情，其实说起来好像挺特别的，如果回到我们传统的互联网领域其实这件事情是相当常见的，大家可以把微信自身的功能和区块链转账做类比，小程序和合约做类比。其实微信在自己的产品发展过程中有个最大的一个转折点。也就是微信他创建了一个小程序平台。

小程序这个平台给微信带来的是创建了一个新的生态逻辑。由原本的微信，它只能用来聊天、发朋友圈或者是一些付钱的功能，引入了一个可以运行其他第三方代码的这么一个平台，而在这个平台上，又一定程度上可以调用微信的一些逻辑功能，比方说大家可以在小程序里面去调用微信的支付。而这些小程序的开发商又不是微信。而是所有的小程序的开发者参与到了这个系统中去运行。小程序的开发者并不关心自己的小程序怎么运行的，只是把逻辑的运行过程委托给了微信去运行，那么把这件事情对应到合约平台上，其实也是一样的。

当前小程序的这个平台，大家都已经比较熟悉了，然后，我们继续往下再扩展一层。比方说，现在各大的云厂商都认为 serverless 才是将来的发展方向。这个 serverless 的云平台，其实可以运行任意的逻辑代码，你只要把你的代码部署到我的云平台上，那么我这个平台就可以长期运行了。那这个就是 serverless 对外推广的逻辑。如果我们把 serverless 的这套逻辑，重新套在区块链的这个维度上，大家可以看到，其实区块链的这种合约逻辑，其实是特别像 serverless 。

因为合约这件事情，大家部署到链上之后就永远不用关心我的合约到底是在面上怎么运行的。就如大家写了一段后端程序放到 serverless 平台上了以后，也不用去关心我的 serverless 到底是怎么运行的。

合约，它是运行到一个可信环境里面的。当然，这只是模型上来说。其实我剖析到这里，大家可以简单的理解为，其实我们的合约的这种平台，跟我们的云平台在模型上，是没有差别的。

在模型上是没有差别，但是实际上合约能干的事情远达不到 serveless 的程度，那么这差距就是合约平台能够提升的程度。

因此第一个重点，是其实当前我们所有的合约运行的平台逻辑，和当前的 serverless 化的这么一种平台逻辑，在模型上，是没有区别的。那么第二点，就是既然模型上是没有特别大的区别的，合约能干的事情，大家都有目共睹，那么很显然，就是我只要不断的去提升我合约能够干的事情，那么他就可以无限地向 serverless 平台能够提供的建模能力靠拢。

三、合约平台与合约

好，那么我们就讲下一个课题。

我们在讲合约的时候。其实模糊了其中的很多概念，其中一个最大的概念，就是我们在讲合约的时候，一定要强调好合约，是由合约平台与合约语言一起组成的。而这两部分面对不同的人的。

很显然，合约平台，它是作为一个链的运行环境，它提供的是我能运行我的合约语言编译的程序上的一种平台环境。对于合约语言而言，它其实面向的人是这门语言对应的开发者。

合约平台

合约平台的目标，是为了给这门合约语言提供一个整体的运行环境，所以说，对于合约而言，它的目标，是为了决定合约语言，能够发挥多大的功能。举个例子，就比方说像 EVM 能干的事情和 dfinity 能干的事情，其实是完全不一致的，这就是因为 dfinity 他的合约平台，是超过 EVM 这样的平台能够干的事情的。所以合约平台更多的着重点，是运行合约的运行能力，运行合约的指令的复杂度，优化程度，以及提供合约的模型能力等的这么一种综合环境的决定因素。

合约语言

而对于合约语言来说，他其实是说面向开发者的。比方说大家用 solidity 的人都知道，写起来很困难，而且还有很多抽象能力是受限的。那么如果我能换一门语言来写对应的合约代码，那就顺畅了很多。合约语言，又跟他的生态的复用程度，是成极度相关的关系，就比方说，如果solidity一直没有引入import 的模型，不能从 github上直接引入一个库，那solidity的生态也很难发展起来。例如在17年的时候，很多发 ico 的那些合约，如果没有用标准的 SafeMath 库，基本上都写出了这个一出问题，全部都被攻击了，然后，用 SafeMath 库的人就全部都活得好好的。那很显然，生态的复用程度，可以直接决定与你这么和谐语言到底有多成熟以及运行顺畅度的维度。

所以说，合约平台提供了我整个合约生态里面的根。这是因为合约平台才是真正决定你整个合约语言在整体运行环境当中的一些基础性的能力。合约语言，它的设计的巧妙程度，完善程度和生态的稳定程度，实际上是决定了你这么合约生态中的有多少人能够很顺利的用起你这门语言的这么一种方式。

因此大家在探讨概念的时候，需要先定位好自己的目标，你探讨的是合约生态里面的合约，还是探讨的是合约生态里面的合约平台？作为一个合约开发者，如果能尽量不需要理解到你这个合约平台模型和细节，也可以写出好的东西，那这个平台就是好的。那么最对于这个合约平台的设计者来说，他就说我要尽可能的给合约平台方案去提供更好的模型框架，让他能够在我这个平台上更好的去运行。这样子才是两者互相对比需要的这么一个需求点。

因此对于整体的合约生态的开发过程而言，合约语言是皮，而合约平台是根，也就是生态能不能发展是皮决定的，而生态能发展到什么程度，是由根决定的。

四、当前合约平台的瓶颈

我们就来讲下一个这么一个课题，也就是说当前的合约，其实刚才比较了这么多，我们就要来真正的上手来比较，说我们这几个合约，他们各自的瓶颈到底是个什么情况。

1、EVM

好第一个，是我们来说的是EVM。EVM是用的人最多的，所以大家基本上对EVM都十分了解，特别现在各种新链起来了以后，都争相去兼容EVM。但是，写过EVM的人，其实都感觉说，如果这个世界上不存在EVM，那就更好了。

我们来简单剖析一下说，从合约的第一个老祖宗EVM开始。VM的这种逻辑概念，其实很广泛的，我只要提供一个沙盒环境，能够对指令进行解析，它就可以称为一个VM。而对于以太坊的EVM来说，它其实最大的特点，就是超越了比特币的脚本，提供了一个基于状态环境的图灵完备的环境。

这里有两个最大的重点，第一个是基于状态环境。第二个是图灵完备。也其实也正是从EVM开始，才真正的引入了区块链的状态的概念。比特币是没有状态的概念的，比特币的状态是被推导出来的，而不是被计算出来的。而对于EVM来说，以状态机模型来描述的时候，我的所有的状态，就是被存储下来的。

然后，大家都知道，EVM的指令很简单，只有256位的指令，没有什么u8 u16 u32之类的指令，也不可能有浮点数的指令。当然浮点数指令合不合适我们另谈，只不过说从语言的逻辑功能来说，EVM我们的指令相对于现有的所有的虚拟指令来说，是一种相当简单的指令，它只不过在基础的加减乘除上的多了 jump 等来保证指令的完备，然后当我要运行复杂的逻辑的时候，它倾向于不用自己的简单指令去实现的，而是提供扩展指令去支持复杂的功能。

把举个最简单的例子，比方说大家都知道在EVM中可以验签。那么验签其实就是由各种加减乘除组成的。但是，验签的这段逻辑为什么不是由EVM的指令编写的，而是直接提供了一条扩展指令，叫做verify signature去保证以太坊的验签。那显然就是EVM，他的指令其实太简陋了，完成不了这么复杂的功能。

所以说，在EVM里面，大家如果更深入的了解，会知道EVM有个叫做预编译合约的概念。这个预编译合约本质上就是提供EVM的扩展指令用的。

然后另外一块，大家要知道EVM作为状态区块链模型开辟的老祖宗。他对于状态的操作是KV读写。这个叫做我这里叫做纯的KV读写的接口。正是因为以太坊对上层提供的是纯KV的接口，所以以太坊写起来才特别的恶心，特别是在说mapping的时候。大家都知道写solidity代码的时候。比方说我一个contract，以太坊它是没有 map 的概念的，他只有 mapping。那很显然，map 和 mapping 的区别，第一个，是他们都是KV表示的关系，第二个是 map，大家一般会默认为他是可遍历的。

Mapping 是不能遍历的。这就是很多业务逻辑在写 solidity 代码的时候，会很恶心.举个最简单的例子，比方说我用这个合约写了一个游戏排名。然后这个map记录的是用户地址和他的分数。当我想在合约内知道分数排名的话，这件事情在以太坊合约逻辑里实现起来的代价特别高。如果这段程序是一段普通的程序，完全不会出现说我想遍历这个 map，挑出其中的 max 的值是做不到的，这件事情在普通的程序里面不会觉得这是个问题。这就是因为以太坊它对上层提供了纯的KV接口没有提供更进一步的功能。

不过，以太坊最大的革新点，是在于说他其实提供了合约相关的许多特性。我们来回顾一下在以太坊的合约里面，什么叫做合约特性。举个例子。比方说我在以太坊的合约里面，我写 a+1，b+2之类的这种都是很通用的逻辑。如果以太坊的EVM不是放在以太坊的平台上，而是放到本地运行环境，或者说一个 VM 的沙盒功能。那么在solidity中 a+1，b+2之类的功能是完全做得到的。

那么，什么叫以太坊的合约特性？比方说以太坊，它有一个全局的上下文变量。最著名的，就是msg。大家都知道我们要从msg里面去取sender。去知道说我调用这个函数，它的调用者是谁。msg就作为一个全局上下文环境直接存在的。

而对于以太坊上，还有transfer。大家可以想一下，如果我直接移动EVM到另外一个非区块链的平台环境，那么我这个非区块链的平台环境，还会出现transfer的这种逻辑概念吗？那显然是不可能的，因为其他平台它就没有转账的这种概念，那么我这个合约里面怎么会有转账的这种逻辑概念存在。

以太坊的缺陷很显然，它指令简单，代表着是他的业务建模不能做到很复杂的事情；提供的纯KV接口实际上是代表的是他在数据建模上也不能做到很复杂的事情。

但是以太坊给大家提出了一些很新颖的一些概念。其中的一个概念，就是我们可以把以太坊的这种运行平台拆成逻辑运行和合约功能。

以太坊的平台给我们带来这样的功能之后，我们看一下solidity的设计。solidity 的好处，是在于说它其实是一门新的语言。对于新的语言的话，它可以尽可能的设计一些原本语言难以做到的一些事情，所以说，在新的语言里面event才能变成关键字。然后，它有一些跟合约强绑定，特别是跟合约功能相关的特性，我在新语言里面，就可以直接设计出来。

但是，作为一门新语言，它显然也是有相应的代价的，也就是说。新语言它的生态，是很难积累的。solidity 好在他是合约里面的第一门语言。一开始大家虽然没有生态，但是也不得不接受这样的环境，但是后面新出来的一些语言，就困难就很多了。比方说大家知道能够运行在EVM上的，除了solidity以外，还有个叫做 Vyper 的语言，它是种类python的这么一种语言，但是这门语言它的生态就相当匮乏，完全比不上 solidity ，所以像 uniswap 第一版，他用了 Vyper 去写。但是他第二第三版的话，照样也要重新写回solidity来了，因为他会发现 Vyper 的很多东西没法继续玩下去了。所以solidity给大家的启发就是如果我设计的是新语言。那么他在符合合约特性的这些功能逻辑的设计上，可以做出自己很好的考量。但是相对应的也会引来一个代价，就是你的生态是很难凝聚起来的。

2、Substrate

好，然后，我们来讲第二个。Substrate 的 wasm 合约模型是叫 pallet-contracts 模块。这个模块基本和以太坊的 EVM 模型一致。因此 EVM 存在的问题他也存在，只不过 EVM 是运行自己的指令集，而 pallet-contracts 运行的是 Wasm 指令集。而对于存储的处理，和 EVM 一致，也是只提供了 k/v 的读写接口。

Substrate对应的语言Ink!在集合和标准库(STD)部分提供了许多默认的实现，这些实现都是基于 K/V 封装出来的，虽然最后做到了，但是需要付出相应的代价，无论是运行效率还是代码大小。

solidity提供了合约，event，storage 调用接口这些概念， ink! 同样也提供了这些概念。这门语言，是基于 rust 去模拟 solidity 的这么一种模式。我们可以简单看一下。比方说，我们可以看到在 ink! 的这个体系下，它提供的叫做#[ink::contract]的这么一个设计，还提供了storage，event，然后对于函数调用，多出了constructor和message的概念。这些概念，是 rust 这门语言本身不可能具备的一些概念。而对于像storage，event，constructor，message这些概念，其实全部都是仿照solidity出来的。

当我们拿一门现有的语言去包装出了合约的功能逻辑时，他的利弊也是很明显的。

他的利处，是在于我可以直接使用这门语言已有的生态环境。比如在Rust里面，虽然最大支持到了u128。但是，我如果我要用超过u128的大数。就叫big number，比如u256。那么rust其实已经有成熟的库去帮你处理好整个事情了，所以说，如果我真的是想要一些计算库的话，那么可以直接在rust这门语言上去使用对应的这么一个生态库。

但是，它也有很明显的缺陷，就在于说。我的合约其实是要有合约相关的逻辑功能的。我在一门语言上强行去封装出这门逻辑功能，你不管再怎么封装，一定都不如我设计一门新语言那么顺滑。

假设我封装一个功能点，它带来的影响是1。那么我如果封装的另外一个功能点，它带来的影响也是1，那么最后对于整个体系复杂度的影响而言，它不是1+1的线性关系，而是1*1的乘积关系。所以ink! 截止目前为止，开发了一年半了仍然会有很多的bug。这个就是我在一门基础的语言上去模拟出合约的功能来的时候会带来的代价，而且另外一块最麻烦的代价是 Rust 没有继承的。那如果没有继承就想模拟solidity，这件事情是不可能做得到的。

或者说你一定要做到也行，只不过你基本上跟创造你的新语言也没有差别了，而且你创造了这么新语言，还会遇到各种各样的问题。所以rust的封装出来的ink! 在功能的复用上，其实是很不好做的。因为 rust 只能用组合，当然在合约里面，组合就是要另外一种模式去设计。

3、Near

然后，我们往下看一个Near。Near最大的特点是它带来了分片的功能，因此Near称呼自己的合约是异步合约。然后 Near 其实跟以太坊在底层的数据建模上没有区别，它是提供是纯KV接口。我们简单介绍一下它的这个异步合约。

我们这里一个简单的Near的标准。同质化代币作为标准来给大家简单看一下。大家可以看到，Near它的封装，跟ink! 有一点类似，不过他又没有说我强行要模拟solidity的概念。

所以可以看到Near的这套体系里面。第一个，是他同样跟这个ink! 类似，他要包装出了合约的存取。但是 near-sdk 和 ink! 相比一个最大的特点是它引入各种库的时候，是直接引入的。但是在 wasm 的生态引入中有比较大的差距。

大家可以看到ink，由于他对 wasm 这段要求更加严格。所以说，他所有引入和索引入库的相关的事情的时候一定要明确表明这件事情，一定是 no_std 的。所以可以看到它引入了所有的库。都需要标志 default-features=false 来让这个库原本的 std 变为false。

这样子的话，在引入各种库的时候，就会发现，如果我有一个库，它其实就是 std 的库。他虽然能编成wasm，但是，他没有提供纯正的基础wasm上功能的这种东西，那么我就没法复用这个 rust 生态的库。这件事情，在 Near 是做得到的，例如在near 合约里可以调用 serde 库。它用起来，其实是可以直接近似于去编写一个正常的rust的程序。所以说，Near-SDK，他是对rust 的简单生态的包装，而ink! 包装的太复杂了。Near包装的很简单，因此它的生态，是可以基本复用原本的rust的生态的。

但是，我们这里要说一下Near的异步的这个特性。熟悉 Near 的人，应该知道Near，为了应对他的分片功能把它的所有的操作，都拆成异步的过程。比方说 a 转账给 b ，因为你并不知道 b 在哪个分片，所以说他连转账其实也是一个异步的过程，但是，Near的异步，是要被拆到多个块里面去执行的。

比方说合约里 a 转账给 b 在一个块里面是执行不了的，我必须要把转账到 a 之前完成的逻辑放在第一个块，然后，转账给 b 之后完成逻辑放到第二个块。这个样子会带来很多问题，其中最显然的问题就是错误处理。就比方说我 a 转账给 b 的这个过程如果转账给 b 了，b 后面出现了问题，那么 a 前面的内容回不回滚？这件事情在 Near 里所有写合约的人都必然碰到。

这样子的话，写合约代码的人就比较痛苦了，因为异步是会给人带来极大的思维负担性的。那么前半段他还写得很顺畅，但是，后半段逻辑本来是要接着前半段写的，但是，他却不得不把后半段逻辑拆到其他的函数里面，还要用个很奇怪的操作去把他们关联起来。

虽然near-sdk是对rust的简单封装，也可以对生态进行充分的复用，但是，他的异步特性的封装的太过于简陋。

我们来举一个对应的例子。但是现在的很多新的合约，已经在探讨一些新的异步合约的概念了，比方说我们这里一个叫作gear的一个项目。

好，我们看一下gear的这里的example。可以看到。在gear的这个项目下他其实已经完整的用起了 rust 的 async await 的特性。

可以看到这里，他把整个函数包装成了 async 。然后，他调他的这个异步的过程，叫做 msg，然后，对这个 msg，出现了 await。那这个样子写起来就显然比 Near 的写法上有很明显的差距。

4、Solana

然后，我们接下来说下一个solana。他的整个模型是叫账户模型，写过solana的人应该都知道这个账户模型一开始就比较难用。solana的这个账户模型的目标，是为了做并行的，因为以账户的维度就可以对交易进行标记。进行标记了以后，他就可以对这个账户进行Dag的排序，来保证我个执行的不冲突。有项目方在solana比较裸露的合约框架上设计了一个叫Anchor的框架来简化合约的编写。

而solana要跟他的账户模型相绑定，这件事情就不是“皮”能解决的事情了，而是它的“根”的问题。solana的账户模型，跟他整个体系绑定的是相当深的，比如说一个账户模型的4M大小，这个账户模型的内存到底要怎么分配等等。特别是比如说像这里还会出现像 space=8+8 之类的这种东西，如果你完全不理解这个solana的账户的概念，你完全不知道这个地方为什么要这样写。大家在写solidity的时候难道还会让你去理解一下，说我这个账户到底应该怎么组成吗？那很显然说像solidity新创建的语言，在写法上的这种顺畅度会比solana要好一些。

这章，我们给大家强调的是，我们在说合约的概念的时候，一定要拆出合约平台跟合约语言的这两块功能逻辑。因为他们两边所注重的重心是完全不一致的。

以上，我给大家简略的比较了一下各个平台上的一种差距。

五、合约的表现力

这一章，我们就要开始引出我们本身最重要的核心了，也就是说刚才我们已经提到说合约这种东西，其实跟这种运行任意代码的平台，在模型上是没有区别的。那么他所谓的合约，其实就是我们正常的程序。

那么如何把一个合约的功能逻辑不断的提升向 serverless 靠拢呢？很显然，程序具备什么，合约也应该具备什么。我们都知道，所有的程序，都是由 code 和 data 组成的，也就是说是由数据和代码一起组成的。那么他实际上对应的合约的能力，也就是说我们这里换个词，叫做表现力。他最终是要体现在合约的逻辑建模能力以及数据建模能力共同组成的。我们这里举个例子。

逻辑建模能力

像 solidity 的逻辑建模能力。很显然，就是弱于 rust 的。因为 solidity 是基于简单的指令集，封装出了类 Java 的一种语言，而且他的很多语言设计上，当时设计的很粗糙，并比不上现在像 rust 之类有一定学术知识的语言，能够设计出来的能力。

所以 solidity 做简单项目，好像和其他语言没有特别大的区别，但是当 solidity 一旦进入到一个复杂的工程性项目而言，它的工程建模能力。很显然，是比其他语言要弱的。

然后，另外一块逻辑建模能力，就是受限于你这个合约平台，请注意我这里词用的词是合约平台，合约平台所提供的功能，所以你合约平台的提供的功能，是弱的，那么你这里的逻辑建模能力，自然也会弱，比方说以 wasm 和 EVM 为例，EVM他只能提供正常的256对齐的一些计算。对于 wasm 来说，他从 u8 到 u64 的各类的类型都有，甚至他也提供浮点数的能力。那么对于 wasm 的这种上层语言，rust 或者 C 做出来逻辑建模能力，就会超过 solidity 的。

数据建模能力

然后，另外一块是数据建模能力。很显然，数据建模能力基本上没有多少区块链（公链）想去改善它。可以看到刚才的这个 substrate 的 pallet-contract ，还有near，他们基本上还是继续沿用了正常的 KV模型。KV 模型很实在也很好用，但是如果你要真正的把KV模型用起来。你只能往 KV 上去封装更多的功能，因此。大家可以参考 ink!。可以看到，Ink! 就是为了给开发提供足够的轮子，才在简单的KV 上去把标准库全部实现了一遍。这样子的话，写合约人才比较顺畅，Near 好像也有，但是Near的包装没有没有ink! 这么丰富。而对于 solana 而言，直接就没有包装。

六、瓶颈突破角度

最后我们就来提一下说，他们的各自的突破点可能有哪些？

逻辑建模的突破点

第一个是逻辑建模的突破点。那很显然，逻辑突破点的现在已经算有足够成熟的方案了，比如说像这个 EVM 当前是很弱的，所以说大家都往新的 Wasm 去靠，甚至直接往 RISC-V （例如 Nervous）去靠。总之，不要再用 EVM 这么简单破旧的东西。那么它对应的，第一个是语言的表现力，语言的表现力，它直观地反映的结果，就是工程能力，就像我刚才举的 solidity 的工程化跟 rust 的工程化的比较能力而言，第二个是模块分离程度的复用性。这个和我刚才举例 solidity 的继承与调用别的库。

比如接口设计，和这门语言有没有提供可以让人白嫖的库，或者已有生态的复杂性的功能逻辑，一起构成的东西。

另一块逻辑建模的突破点，就是执行并行化和异步化。并行化，就类似于像 solana 想走的那条路。异步化，就有点像 near 跟 dfinity 想走的路。总之来说，就是在逻辑建模上，他们要提供更多的东西，去支持整个东西的运行，来让写程序的人有更多的逻辑功能去做。

数据建模的突破点

第二块是数据建模的突破点。数据突破的建模点很显然就是直接跳出KV建模的约束。我刚才提到说很多区块链的没有跳出KV建模的约束，在我的角度上，我认为是，他们是要对整个的数据最后的证明，去进行取舍的。

我们这里举个例子，以 dfinity 为例，如果写过的人会知道 dfinity 直接就没有存取的概念，而是它所有的东西，都永久的运行，直接放在内存里面，所以 dfinity 整个的过程中，是没有出现像其他语言那样，我需要对这个东西，去进行 get set 的过程，而是说我直接对一个全局变量进行操作就可以了。

第二是说如果对数据建模的封装的能力，已经提供了 SQL 或者 newSQL 的建模能力，那么对于刚才的功能逻辑来说，就是一个简单的select，然后 score 大于多少。直接就可以获取到对应的值了，这样子，对程序员的要求就很低。因为 SQL 本质上就是当前在互联网运用中沉淀下来的，大家公认的对数据建模的一层抽象。

然后第三个，是对轻节点的工程性需求，这个是跟平台对证明的取舍相关的，也就是说当前的所有的这个说我的KV必须要有一定的证明，最后的目标都是服务于轻节点，但是，轻节点对用户端工程性需求，几乎为零，而轻节点最大的作用，实际上是服务于跨链证明。

因此如果对于跨链需求比较弱的话，是不需要对存储有强证明的部分的。如果不需要强证明，在数据存储上就可以发挥更多的空间，而不是被 kv 限制住。

以上，谢谢大家。

…

BeWater Community

直播 LIVE 第 5 期预告

分享嘉宾：

郭光华，ComingChat & ChainX CEO，前ARRIS/Google 开发工程师，中国人工智能小镇区块链入驻者， ComingChat 是一个可信任的去中心化元宇宙，有近1000万用户，遍及全球192个国家。

分享主题：

taproot升级后，比特币网络的Layer2会迎来大爆发

主题背景：

Bitcoin 面世 13 年来，有三次大的技术革新。

第一次是：Bitcoin网络的正式落地。

第二次是：隔离见证。

第三次是：taproot升级。

但隔离见证带给 BTC 技术的影响力远不及 taproot。以太坊的 Layer2 以及生态如火如荼，但 BTC 的生态几乎无声音，根本原因就是 BTC 网络无法扩展，taproot 恰好是可以解决 BTC 无法扩展的关键技术，所以说，taproot 是 Bitcoin 网络上线以来，最大的技术迭代和突破。简单就是美（这是 Bitcoin 技术的设计原则）。这个分享，会带大家去发现 Taproot 的简洁之美。

分享时间及地点：

11 月 11 日，晚 20 点，@腾讯会议直播间

扫描上方图片二维码，报名哦

分享内容：

1. taproot技术是什么？

- MAST合约和 Schnorr 签名

- Schnorr签名的细节和影响

- MAST合约是什么

2. taproot对BTC技术的影响。

- 如何提高BTC的隐私

- 如何提高BTC的性能

- 如何提高BTC的扩展性