比特币如何实现高性能智能合约

说到智能合约，很多人的第一反应就是以太坊。 甚至在维基百科上搜索智能合约，也会给出如下定义：

智能合约：（英文：Smart Contract）是区块链中制作合约时使用的一种特殊协议，包含代码函数（Function），还可以与其他合约进行交互、决策、存储数据和发送以太坊等职能。

显然，仅将智能合约定义为以太坊功能的一部分有点过于笼统了。 相比之下，IBM给出的智能合约定义更准确，也更符合现代各种公链和合约：

IBM 定义的智能合约：只是存储在区块链上的程序，在满足预定条件时运行。 它们通常用于自动执行协议，以便所有参与者都可以立即确定结果，而无需任何中间人参与，也不会浪费时间。 他们还可以自动化工作流程，在满足条件时触发下一步操作。

总结是：

1. 存储在区块链上

2. 满足一定的条件就会运行特定的逻辑

3、运行逻辑不需要任何第三方参与

因此，满足这三点的都可以被认为是智能合约。 事实上，比特币、莱特币、狗狗币这些看似只是传递代币的东西，也符合智能合约的定义。 事实上，它们的传递函数本身也是一种智能合约。

但是，我们通常不认为只能转账的区块链是智能合约平台，主要是因为它们在秒下的场景太少（特定条件满足时会运行特定逻辑），而这个特定逻辑仅限于几个固定的场景，比如比特币只有P2PKH、P2PK、P2SH等标准的交易逻辑，可以使用的场景只有单签名、多签名等有限的场景，执行逻辑不能自由发挥根据开发者的需求定制，比如更丰富的前置条件、更复杂的逻辑控制、更灵活的合约交互等。因此，广义的智能合约应该增加第四点：

4. 图灵完备，可以执行任意逻辑

账户模型、UTXO模型和智能合约账户模型

众所周知的智能合约公链平台，如以太坊、EOS、Solana等，在执行方式上都可以称为账户模型。

帐户模型非常容易理解。 是一种思维方式，就像我们的支付宝账户、银行账户等，每个人都有一个或多个“账户”，每个账户都有一个“余额”。

A->B转账的过程是从A账户的余额中减去X，然后将X加到B账户的余额中（不考虑手续费）。 如果在转账过程中加入一些逻辑条件，只有满足一定的条件才能进行转账，那么就形成了智能合约。 以太坊内部有一个虚拟机，叫做EVM，用来监控特定的条件，在满足条件后自动执行转账。 因为这个虚拟机可以执行程序代码比特币合约群，所以只需要用高级计算机编程语言编写逻辑，部署在链上就可以轻松实现任意逻辑。

因为这个账户模型非常接近面向对象编程，只需要定义成员变量（各种余额数据）和方法（合约）就可以轻松实现任意逻辑。 正因为如此，市面上绝大部分的智能合约平台都运行在账户模型之上。

账户模型也有一个非常显着的劣势：如何在分布式节点的情况下保证虚拟机的一致性。 由于以太坊上的所有合约都是通过发送以太坊交易来驱动的，因此接收交易的顺序会影响交易的结果。 为了保证所有节点执行相同的逻辑，需要保证所有节点接收交易的顺序一致，否则会造成混乱。 显然，在分布式环境下，所有节点很难保持接收交易的一致性，尤其是在高频交易场景下。 如果 A 连续向 B 发送 10 笔钱，则必须等待所有节点按顺序收到所有交易。 交易完成后，即可完成结算。 如果某个节点先收到第十笔交易，则需要等待其他九笔交易到位后才能处理第十笔交易。 另外，每笔以太坊交易只能进行1对1的转账，这在高频场景尤其是复杂的多对多情况下难度很大。

为了突出以太坊的以下性能问题，我们假设如下场景，账户A要给100个人发红包。 如果用ETH发红包，必须发到1号、2号、3号…… 100个交易需要构造一个一个发送，节点也要一个一个处理为了。 因为每次发送都要等到最后的余额确定，所以1日和2日的红包领取顺序是确定的，第100个的顺序要等到前面的人都收到红包后才能领到红包。红包。

传统的使用账户模型的互联网应用必须配合数据库中的强一致性锁，或者强事务来实现账户修改安全。 这个问题在分布式区块链中尤为显着。

核心原因是对账户的修改必须按照严格的顺序执行，执行顺序可能相差很大（这就是为什么以太坊的swap一直没能解决矿工抢跑的问题，矿工可以自己受益）交易被插入到其他用户的前面来改变执行结果）。

UTXO模型

UTXO模型是主流区块链采用的另一种模型，如比特币、莱特币、DOGE等区块链。

UTXO 的意思是“未花费的交易输出”。 这个模型和我们日常使用的现金（纸币和硬币）非常相似，可以看作是现金的改进版（顺带一提，央行发行的数字货币就是UTXO模型）。

区块链不记录和维护某个地址的余额，而是记录每张钞票属于哪个地址。 在比特币场景下，无法直接查询到地址A的余额，需要统计A有多少张纸币。比如我们有一个钱包（真实钱包），里面有一张10元，一张100元，和一个1元硬币在里面，那么我们可以说我们的钱包余额是111元（我们知道余额是由一个100，一个10和一个1组成的），换句话说，如果你不计算每张纸币和面值，仅凭钱包本身不知道自己有多少余额，类似于以太坊支付宝等账户模型。

转账时如何转比特币也和我们平时用现金支付很接近（但不完全一样）。 还是刚才的真实钱包，如果A要付B 1元，那么A有3种方式付给B，给他1元，给他10元还9元，给他100元还99元. 换钱不等于现金，也可以说是一种进步。 A给B 10元取回9元，不是让B查出9元还给A，而是A烧掉10元（销毁UTXO），然后系统再打印1元给B，打印一张9 个区块到 A（重建 UTXO）。 交易后，A的钱包里有一张面值100元的钞票，一张面值9元的钞票，一张面值1元的钞票，余额为110元。

根据上面的描述，我们可以知道，比特币的转账和收款比特币合约群，就是钱包中纸币不断淘汰和生成的过程。 要想知道比特币地址的余额，需要把这个钱包地址的所有纸币都拿出来，计算出所有的面额，然后相加。

同时，比特币支持多对多交易。 例如，一笔交易可以让 A 同时将 1 个区块转入 DEF：

1.取出100面额烧掉，印出99张还给A，1张给D。

2、取出10张面值烧毁，打印9张返还给A，1张给E。

3、取出1张面值烧毁，不找零给A，1张给F。

UTXO模型的神奇之处在于，以上三个步骤可以在三个不相关的（并行交易与顺序无关）交易中发送，也可以直接使用一个交易发送。

与以太坊相比，比特币如果要同时发送给100个人，只需要一笔交易就可以让100个人同时收到钱。 性能差距可想而知。 这样我们就可以理解为什么央行数字货币采用UTXO模型了。 不然深圳怎么可能给5万个钱包发1000万数字人民币？

UTXO脚本控制，一张UTXO（一张具有一定面值的纸币）是否可以销毁，控制的粒度是UTXO（单张纸币）的级别，交易没有顺序要求，所以多对多交易和可以进行并行交易验证。 它在现金转账场景中具有极高的性能。

UTXO 脚本智能

刚才提到的UTXO模型在并行化和扩展性能上有很大的优势，但是为什么我们很少在UTXO公链上看到智能合约呢？

主要有以下几个原因：

1.UTXO脚本编程比较复杂

2、BTC等公链限制脚本类型、脚本量等。

3.分布式状态管理更复杂

让我们一一解释。 首先，很多人不知道比特币是可以自由编程的。 我们从比特币维基上可以看到，比特币有大量的操作码，看起来极其不友好，看起来很像汇编语言。 研究过比特币脚本原理的应该知道，比特币能否花掉的判断是通过一个栈结构来存储和验证的。

解锁脚本和锁定脚本依次入栈，然后依次执行操作码。 如果最终栈的返回值为真，那么这个UTXO就可以花费，否则不能花费。

其实很多我们熟悉的编程语言在计算机底层执行逻辑的时候也是有栈结构的，比如Java、rust、go等。以Java为例，Java就有栈内存的概念和堆内存。 栈内存主要执行函数内部逻辑，堆内存主要存储对象等数据。 可以看出栈其实可以执行任意逻辑，Java编译后的字节码就是在操作这个栈来实现各种复杂的业务逻辑。

虽然比特币脚本使用的栈和虚拟机没有JVM那么复杂，但是几乎所有的图灵完备逻辑都可以通过一定的组合来实现。 这里很多人会说比特币脚本没有死循环，所以不是图灵完备的。 其实这是有意为之，为了保证计算一定要出结果。 其实以太坊等并没有真正的无限循环，gas烧完之后循环就会停止。 比特币脚本在做循环的时候，需要提前把循环重复写到脚本栈中。 如果要做无限循环，就必须写一个 Infinitely long 的脚本，这种事务显然是没有意义的。 在实际脚本编写中，比特币脚本会规定一个循环次数上限，以保证手续费在合理范围内（与以太坊gas燃尽原理相同）。

说了这么多脚本栈，我们来看看Bitcoin Script是如何实现一些智能合约的。 最典型的合约场景之一就是ERC 721，它是一种NFT合约。 在以太坊场景下创建一个NFT，首先要部署一个合约账户，然后所有的NFT所有权都由这个账户管理，这个NFT的所有转账都必须和这个NFT合约账户进行交互。

在UTXO模型下，我们设计这样一个UTXO，里面有一段数据和代码，标记这个UTXO代表什么NFT，谁可以解锁，怎么销毁，上限怎么保证，那么这个UTXO可以代表这个 NFT。 拥有这个UTXO的人，就拥有了这个NFT。 如果你要转出这个NFT，你必须用你的私钥签名，满足解锁条件，然后比特币矿工会执行你的脚本，判断你是否可以转出这个UTXO。 更重要的是，同一系列的NFT分散在不同的UTXO中，所以只要从分布式全局状态中找到满足一定条件的UTXO，就可以确定这些NFT属于谁。 这些 NFT 的转账可以并行进行，互不影响，提供了最高的性能。

因此，比特币合约的思想是使用单一的 UTXO 脚本栈来存储状态和逻辑。 整体状态由一批 UTXO 状态组成。 以太坊对应的合约状态只存在于一个账户中。 相比之下，比特币合约具有与 UTXO 同等级别的并发性，为大规模高性能使用奠定了基础。

抛开脚本大小、实用性和客户端限制，在比特币上实现上述逻辑理论上是可行的，但由于UTXO的独立性，在实际工程中会遇到两个问题。 一是 UTXO 相互影响。 另一个是合同溯源和防伪问题。 MVC链巧妙地解决了这两个问题，最终实现了实用的高性能UTXO模型智能合约。

MVC是一条完美实现比特币+高性能智能合约的Web3公链：

1、采用一层兼容UTXO并行处理能力的智能合约技术“MetaTXID方案”；

2、结合UTXO模型的优点，是区块链领域并发最高、执行成本最低的Layer-1链上智能合约解决方案；

3. 首次实现了UTXO模型公链的实用性图灵完备，可以满足所有Web3应用和元界应用的使用场景。

MVC是如何解决这两个问题的，后面会详细讲解。