导语：Zen Protocol 可同时处理多份智能合约，再加上独特的代币发行机制，让它拥有了超越ETH的潜力。
1.恼人的可伸缩性
可伸缩性（Scalability ）是让任何区块链项目都十分头疼的问题。
理论上，比特币每秒最多可处理约7笔交易，但实际上只有3-4笔。目前以太坊每秒能处理约6笔交易，可理论上每秒最多可处理约12笔。比特币的区块通常满负荷运行，导致交易延迟。**以太坊在频繁使用时也面临着类似的问题 **——在2017年6月份的Status（英文缩写SNT，一个开源的聊天平台，以及是一个支持以太坊去中心化应用dApp的移动浏览器） ICO（inital coin offering）期间，以太坊的交易速度比平常慢了数小时。
以太坊代币（token）是运行在以太坊虚拟机（Ethereum Virtual Machine，以下简称EVM）上的，每一笔交易都会导致EVM状态改变，并且所有的交易只能按顺序依次处理。这就导致以太坊在交易吞吐量方面存在瓶颈——以太坊网络受到矿工运行智能合约速度的限制，智能合约一旦运行，就会导致EVM状态更新，最终导致以太坊处理交易速度降低。
2.拥堵的天敌——并行计算
计算领域中有一个重要概念是可并行性（parallelism） ，即同时执行多个任务的能力。以太坊网络不具有并行计算的能力，因为每一笔交易都会改变EVM的状态，并且后续也可能无法合并这些状态。没办法，以太坊网络只能一个接一个，依次处理每一笔交易。
Zen Protocol 没有像EVM这样的全网共享状态，这意味着我们可以并行处理智能合约。什么意思呢？
假设现在有两份智能合约——α和β 需要处理。运行智能合约α需要271毫秒，β则需要463毫秒。如果我们只能按顺序依次执行智能合约，那么必须运行先α，再运行β。即先花费271毫秒，再花费463毫秒，整个过程需要734毫秒才能处理完毕。
如果可以并行处理智能合约，那么我们就可以同时启动α和β。也就是说，经过271毫秒后，α已运行完毕，同时，β仍在运行；又过了192毫秒，β已经运行完毕。至此，两份智能合约处理完毕。整个过程耗时463毫秒——和处理单个最耗时的智能合约时长一样。
这就是并行计算的优势。那如果我们想运行α100次，该怎么办呢？假如必须按顺序依次处理智能合约，那么将耗时27100毫秒，即27.1秒。而如果我们可以并行处理智能合约，那么整个过程仍然只需要27毫秒—— 足足快了100倍！
很明显，如果可以并行处理智能合约，就可以提高交易吞吐量。在所有条件相同的情况下，可并行处理的智能合约数量才是制约交易量的最大因素。如你所知，现代计算机已经拥有并行计算的能力，服务器也可以成百上千地同时运行。
当然啦，并非所有的交易都可以并行处理。而如果同一个区块中，一笔交易的处理必须要依赖于另一笔交易的处理，那么就只能按顺序处理这些交易。话说回来，这种处理方式也有它的好处，即这些交易不会影响其他单独交易的时间。正如其运行在类似以太坊这样的单线程处理环境中一样。
假设我们有三份智能合约要处理：α，β和γ，其中γ取决于β，这些智能合约分别需要耗时7,4和3毫秒。如果单线程处理，那么我们必须先运行α，然后运行β，最后运行γ，总共耗时14毫秒。如果可以并行处理这三份智能合约，那么我们可以同时启动α和β——在4毫秒之后，β已处理完毕并且开始处理γ；在7毫秒之后，全部处理完毕！
以太坊在 ICO时经常遇到交易延迟的问题，因为无论是什么智能合约，一旦运行都必将导致EVM的状态更新，进而导致交易网络用拥堵不堪。恰好Zen Protocol 没有类似的全网共享状态，因此在Zen Protocol 上发起ICO，其他不相关的交易就不会影响交易处理时间。
这种优势是巨大的。以太坊网络上的各种代币（除了以太代币ETH）都是EVM的一部分，这意味着更改帐户余额必须通过智能合约更改EVM的状态。
Zen Protocol 设计了一流的代币发行机制，即其他代币的运行方式与Zen Protocol 的原生代币完全相同。它们是UTXO（Unspent Transaction Output，即消费的交易输出），并且在Zen Protocol 网络上交易不一定都会运用智能合约——你可以像消费比特币一样消费它们，十分简便。
因此，在Zen Protocol 上智能合约可以并行处理，简单交易甚至不涉及智能合约。
仅凭这一点，Zen Protocol 已比以太坊的性能意见有了显著提升。但是，我们可以做得更好。
3.编译代码的优势
以太坊使用“燃料系统”为矿工支付运行智能合约消耗的计算资源，智能合约由EVM生成。为了使用以太坊智能合约，用户支付“燃料费”作为交易费用。
在执行智能合约之前，以太坊矿工会查找执行该合约的“燃料费”。如果用户支付了足够的费用，则矿工从用户支付的燃气费中减去执行该指令的消耗的费用，然后在EVM上执行该命令，最后EVM会更新状态。这个过程一直持续到用户支付的费用消耗完毕，或者矿工执行完所有智能合同。
在Zen Protocol 中，智能合约中包含着执行智能合约需要消耗费用的信息。当旷工我们执行智能合约时，不需要跟踪记录燃料使用情况，因为执行智能合约之前我们就知道了执行的成本。因此，我们不需要浪费时间查看燃料价格，检查剩余燃料，还得从剩余燃料中减去执行命令的燃料费用。
正因为不关心燃料价格，所以我们不需要将智能合约设定为一整套指令 ——只需要保留其源代码即可。基于此，我们不用像以太坊那样逐一按顺序执行智能合约指令，即我们可以让矿工编译（compile）源代码，而不是像以太坊那样解释（interpret）指令。
这里稍微解释下两者的异同：
编译（compile）：即在整个程序源代码运行之前，将其翻译成为另外一种代码，然后等待被执行，产物则是另一份代码。
解释（interpret）：即在运行程序时一行一行读懂然后执行源代码，产物是运行结果。
编译代码比解释代码快了几个数量级，并且编译代码也更容易自动优化。例如，有时可以用2个机器指令执行计算，而不是5条。编译时我们可能会自动进行此优化，但在逐个解释说明时则可能无法实现。
4.总结
总而言之，Zen Protocol 有如下优势：
可以并行处理智能合约。即在所有其他条件相同时，我们可以在更短的时间内处理更多的智能合约；
智能合约处理速度更快。即使是相同的智能合约，在Zen Protocol 上运行得更快；
最后，Zen Protocol 拥有一流的代币发行机制，常用的转移代币功能也不需要使用智能合约。
原文：https://blog.zenprotocol.com/zen-protocol-and-scalability-e0f9bf8483b8，作者Asher Manning，翻译：谢行知
如果觉得文章不错，欢迎打赏哦~~ ZEN钱包：
zen1qsa2qkrgx0vp3e0tnngx6apae92fuchpctjt6n8gdjr375gclnqusqcam2g