CPU 从 CISC[4] 设计转移到 RISC[5] 设计，利用基于软件的编译器来填补 RISC 中缺失的部门。
基于 UTXO 的区块链在区块链（硬件）部门中插手了更少的逻辑，并操作软件来增补更多的特性。
UTXO 模子和账户模子本质上是一样的，UTXO 模子只是一个软件界说版本的账户模子。
在 Generator 中复制逻辑不是一个坏主意对这条蹊径的不绝品评，也是我之前所担忧的，是我们在链外 generator 部门和链上智能合约中都复制了逻辑。但最近，我一直在质疑这一点：这真的是一个问题吗？在区块链的世界里，一个被遍及遵循的原则是「不要相信它，去验证它」（don't trust, verify）。一项生意业务中包括的智能合约不只会在单个节点上运行，还将在每个区块链节点上运行。我们已经执行了 N 次沟通的智能合约，假如 generator 再执行一次，并使其成为 N + 1，这真的很重要吗？我们都知道 N + 1 和 N 没有区别。我小我私家认为 generator 部门只是别的一个轻量级客户端节点，可以再次验证智能合约。这不会给我们现有的区块链设计带来任何问题。
关于这两种模子的争论已经有一段时间了。一个明明的思量是，账户模子的生意业务体积更小，但作为互换，必需在基于账户的区块链中计较状态，更糟糕的是，同一账户的生意业务需要顺序执行。另一方面，基于 UTXO 的区块链只需要举办验证事情，以确保提交的数据名目正确，会见同一账户差异部门的生意业务也可以并行验证，以得到更好的机能。可是，我们要支付生意业务体积较量大的价钱，因为生意业务需要包括实际的数据。
[2] 劈头实验 :
虽然，需要构建这个新的 generator，使基于 UTXO 的区块链的行为雷同于基于帐户的区块链。我在这里的概念是，这是一条完全可行的蹊径，这意味着基于 UTXO 的设计，永远不会故障基于帐户模子构建的 DApp。
而在基于 UTXO 的区块链中，状态都包括在生意业务中。你直接在生意业务中放入你想要的数据。凡是，多个 UTXO 可以一起事情来提供整个状态的一部门。当你但愿变动一部门数据时，你可以将该部门的 UTXO 作为生意业务中的输入包罗进来，并提供一个包括更新数据的新 UTXO。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
