finish intro/bvm

i18n/zh-CN/docusaurus-plugin-content-docs/current/introduction/introduction/mvc-bvm-utxo.md

@@ -2,3 +2,54 @@
 sidebar_position: 3
 ---
 # BVM和UTXO智能合约
+
+根据我们前面介绍，[UTXO模型是MVC进行无限扩容的基础](mvc-performance)。使用UTXO模型进行标准的转账交易是非常简单的，但是要实现智能合约却受到很多限制，也存在很多技术难度：
+
+* UTXO模型因为不存在全局状态，进行类似以太坊智能合约的全局状态管理非常困难。
+* UTXO模型是纯函数式编程，需要一定的理论基础才可以掌握正确的编程模式。
+* BTC等公链限制了可以执行的脚本数量和类型，只允许几大标准类型的交易输出，导致智能合约的功能受到限制。
+* UTXO生态中缺乏完善的智能合约开发工具，开发者需要自己编写脚本并且手动构造交易，非常不友好。
+* UTXO合约由于其技术特点，存在很多编译期常量，在处理循环，递归等复杂逻辑时会遇到很多困难。
+
+MVC充分考虑了UTXO模型的优势和缺点，在吸取以太坊和其他UTXO公链的经验的基础上，引入了BVM（Blockchain Virtual Machine）的概念和MetaTxid等技术来实现真正的纯一层UTXO智能合约。并且同[sCrypt](https://scrypt.io/)团队深度合作，提供了更加友好的智能合约开发工具，大大降低了编写和部署BVM智能合约的门槛。
+
+## BVM（Bitcoin Virtual Machine）
+
+BVM是基于比特币的[脚本系统](https://en.bitcoin.it/wiki/Script)进行了操作码恢复和功能扩展的虚拟机，它是MVC智能合约的执行引擎。比特币的脚本系统是一个双栈结构的执行器，包括输入栈和输出栈，使用类forth语言对栈进行任意操作，实现更高层次的逻辑。实际上，很多现代编程语言的执行结构很大程度上都要依赖执行栈，从原理上来说，你甚至可以通过栈式结构来实现任意复杂的程序逻辑（只要内存资源足够多）。可以说，栈式结构是构成现代编程语言的基础，拥有无限的潜力。
+
+但由于BTC的限制，脚本系统只能进行简单的逻辑判断，可以使用的操作码也非常有限，无法实现复杂的智能合约逻辑。BVM在脚本系统的基础上进行了功能扩展，[引入了更多的操作码](/docs/blockchain/mvc-improvements/bvm-opcode-unlocking)，支持更多的数据类型，提供了更多的功能，使得MVC智能合约可以实现更多的复杂逻辑。
+
+我们可以对BVM及其合约进行如下的定义和特点归纳：
+
+1. BVM是基于比特币脚本系统的操作码进行了功能扩展的虚拟机。
+2. BVM由输入栈和输出栈组成。输出栈可以看作智能合约的函数定义以及数据，输入栈可以看作智能合约的函数调用以及参数。
+3. BVM合约是[纯函数式运算](https://www.turing.com/kb/introduction-to-functional-programming)，具备函数式编程的原子性，无状态，无副作用，可并行执行等特点。
+4. BVM的合约计算的结果只包含TRUE或者FALSE，通过UTXO是否能够被解锁来判断合约是否执行成功。
+5. BVM的合约具备原子性，要么全部成功，要么全部失败，不会出现部分执行的情况。校验失败的合约不会消耗GAS费，因为会被看作非法交易，不会记录上链。
+
+![BVM](/img/bitcoin-virtual-machine.png)
+
+
+更多关于BVM的操作码和合约编程的详细容请参考[后续章节](/docs/blockchain/mvc-improvements/bvm-opcode-unlocking)。
+
+## UTXO智能合约简介
+
+UTXO智能合约就是将合约的逻辑和数据存储在UTXO中，将合约的调用和参数作为input来尝试解锁合约，通过BVM执行合约的逻辑，最终通过能否解锁（函数返回true或false）来达到控制合约状态的目的。这样的模式可能对于以太坊智能合约开发者来说有些陌生，但实际上结合函数式编程思想，配合一些概念的转换，UTXO智能合约也可以实现非常复杂的逻辑。
+
+UTXO模型由于不存在全局状态，因此需要将合约的状态和逻辑存储在UTXO中，通过UTXO交易调用链的传递来进行状态的传递和转换，如下图所示：
+
+![UTXO state chain](/img/utxo-state-chain.png)
+（UTXO合约状态链，图片取自[sCrypt](https://docs.scrypt.io/how-to-write-a-contract/stateful-contract)）
+
+每一次的UTXO交易都会消耗之前的UTXO，生成新的UTXO，通过这种方式可以实现合约的链式状态转移。而能否解锁UTXO也就对应着合约的执行结果是否允许状态进行转移，如果合约判断不允许修改状态（比如不允许转账，不允许修改数据等），则会返回false，UTXO不会被解锁，合约执行失败。
+
+我们把合约看作对数据状态进行转移操作的状态机，那么这里可以看出UTXO合约和Account合约的区别：
+
+* account合约维护全局状态，一个交易可能导致EVM进行多次的状态转移，频繁地修改状态数据直到合约执行完成或者Gas消耗完。而UTXO合约的交易一个input合约调用只会触发一次状态转移，并且无论合约内部的逻辑多复杂，状态转移多少次，BVM只会将最终的状态转移结果记录在链上。
+* UTXO合约没有全局状态，只有一个个等待被执行的“函数”（UTXO）。需要转移状态，就要先找到这个状态所在的函数，通过函数调用来修改状态并且生成新的函数。这样的模式使得UTXO合约的状态转移更加清晰，更加容易理解。
+* 由于UTXO合约不依赖外部状态，因此一次合约调用，无论调用多少次，它的结果必然是确定的，这也就给合约的分析和调试以及单元测试带来了巨大的便利。反观EVM合约，由于依赖全局状态，合约的执行结果很可能会受到外部环境的影响，导致合约的执行结果不确定（余额够是一个结果，不够又是另一个结果），这也是EVM合约的安全性和可预测性的一个重要问题。
+
+当然，每次将状态传递下去也不是没有代价，在一些需要溯源的场景中，状态可能会随着传递链条的增大而增大，因为溯源需要校验的数据可能越来越多，状态本身会无限膨胀。这个问题MVC也通过称为[MetaTxid](meta_txid.md)的技术，通过哈希和数据抽取等密码学的手段将状态膨胀的一大类问题彻底解决，这也是MVC智能合约区别于其他UTXO链的一个重要特点。
+
+
+![UTXO smart contract](/img/bitcoin-smart-contract.png)

i18n/zh-CN/docusaurus-plugin-content-docs/current/introduction/introduction/mvc-performance.md

@@ -54,7 +54,7 @@ MVC吸取了这些前辈的教训，从最开始的设计就没有设置区块
 
 MVC在此基础上进行了改进，首先移除了可能导致未确认交易被替换的RBF机制，让内存池交易具备不可篡改性，其次由于MVC的区块大小没有限制，可以容纳更多的交易，因此对于**费率正常**的交易，可以预期在下一个区块内被打包，这样极大降低了双花的可能性。另外MVC还内置了交易安全机制，如果有交易被双花，可以立刻被网络发现并且标记，这样可以让商家在接受交易的时候更加放心。
 
-通过网络节点之间更强更紧密的链接，让交易以最快的速度触达全网，让双花的代价无限放大，这也是所谓的“小世界网络”希望实现的目标：
+通过网络节点之间更强更紧密的链接，让交易以指数级扩散并触达全网，让双花的代价无限放大，这也是所谓的“小世界网络”希望实现的目标：
 
 ![/img/zero-confirmation.png](/img/zero-confirmation.png)