第三节 区块链金融

算机集群系统中。

当业务逻辑处理器处理完输入后，一个输出分解器负责通知那些关心结果的人。这也是一个高度并行的任务。

最终，通过在业务逻辑处理器里使用单线程样品化处理器和Java虚拟机，LMAX可以在每秒内执行600万次交易。如果LMAX可以达到这个成绩，那么加密货币和智能合约平台并不需要在每秒连10个交易都不到的情况下去考虑集群网络方案。

5.高性能区块链

要建造一个高性能的区块链，我们需要使用与LMAX同样的技术。以下是几个必须实现的事项。

将所有东西都放在内存上，避免同步原语（锁定，原子操作），避免在业务逻辑处理器上进行不必要的计算。

由于内存的设计是高度并行的，因此越来越便宜。追踪互联网上每个人的账户余额和权限所需要的数据量是否可以放在小于1TB的RAM内存上，这用不到15000美元的价格就能买到了，而且可以装在商品化（高端）的服务器主板上。在这个系统被30亿人采用之前，这类硬件会在普通的桌面计算机里面看到。

真正的瓶颈不是内存容量的需求，而是带宽的需求。在每秒100万次交易和每笔交易占256字节的情况下，网络会需要256MB/s的数据量，即1Gbit/s的带宽。这样的带宽在普通的桌面计算机上并不是常见的。不过，这样的带宽只是二代互联网100Gbit/s带宽的一点而已。这个二代互联网被供应给超过210个美国教育机构、70家公司，以及45个非营利机构和政府机构。

换句话说，区块链技术可以轻松地将所有东西保存在内存里，而且如果设计合理的话可以扩展到支持每秒百万级别的转账。

6.分配ID并避免哈希计算

在单线程系统的系统里面，处理器周期是需要被保留的稀缺资源。传统的区块链设计使用加密算法基础上的哈希计算去生成一个全球独特的ID系统，以实现统计学上不会有碰撞的保证。进行这些哈希计算的问题是，它会耗用越来越多的内存和处理器周期。与一个直接的数组索引相比，这种方式会显著地占用更多处理器的时间去查找一个账户的记录。例如，64位的整数对比和操作起来都要比160位以上的ID更简单。更大的哈希ID机制意味着CPU缓存里面的空间更少了，而需要更多的内存。在现代的操作系统里不常访问的随机存储器是会被压缩的，不过哈希识别器是随机数，这是没法压缩的。

型号区块链给了我们一个在全球内分配独特ID的方法，这些ID互相之间不会起冲突，因此完全避免使用像比特币地址那样的哈希算法为基础的识别器去引用一个账号、余额或者许可。

7.从业务逻辑处理器中去除签名校验

所有在加密货币网络的交易依赖于用加密算法签名去校验权限。在大部分情况下，请求的权限可以由其他交易的结果改变。这意味着在业务逻辑处理器里面，权限需要被定义成与加密算法计算无关的情况。

要达到这个目的，所有的公钥需要分配一个独特的和不可代替的ID。当ID被分配后，输入分解器可以校验提供的签名与指定的ID是否匹配。当交易到达业务逻辑处理器后，只需要去检查ID就可以了。

这个同样的技术可以在拥有不可代替的静态ID的对象上实现去除前提条件检查。

8.为静态校验设计交易

对交易来说，有很多特性是可以进行静态检查的，而不需要引用当前的全局状态。这些检查包括参数的范围检查、输入的去冗余和数组排序等。通常来说，有很多检查是可以被进行的，如果交易包含它“假设”是全局状态的数据的话。在这些检查被执行后，业务逻辑处理器必须要做的事情就只有去确保这些假设还是正确的，这个过程总结下来就是检查一个涉及交易签名时间的对象引用的修改时间戳。

9.智能合约

很多区块链正在整合一种通用的脚本语言去定义所有的操作。这些设计最终将业务逻辑处理器定义为一个虚拟机，而所有的交易都被定义为由这个虚拟机运行的脚本。这个方案有一个在真实处理器上的单线程性能极限，并且由于将所有东西强制通过一个虚拟处理器去执行，让问题更严重了。一个虚拟处理器即使用上了实施编译技术（JIT）也总会比一个真正的处理器要慢，不过计算速度并不是这种“任何东西都是一个脚本”方案的唯一问题。

当交易被定义在这么低的层次上时，意味着静态检查和加密算法操作还是会被包含到业务逻辑处理的环节里，这也让会让整体的吞吐量降低。一个脚本引擎永远不应该要求执行一个加密算法签名检查的请求，即使这个请求是通过原生的机制实现的。

根据我们从LMAX上学到的课程，我们知道一个为区块链设计的虚拟机应该考虑到单线程表现。这意味着在一开始就要实施编译优化，而且最常用的智能合约应该通过区块链原生支持，而只有那些不常用的、定制的合约会运行在一个虚拟机上。这些定制的合约设计的时候要考虑性能，这意味着虚拟机应该将可以访问的内存范围限制到可以放在处理器缓存上的级别。

10.面向对象的数据模式

在内存中保存所有东西的其中一个好处是，软件可以设计成模仿现实世界中数据的关系。这意味着业务逻辑处理器可以迅速根据内存内的指针去找到数据