核心功能
- 聚合链共识
- 开放智能合约协议
- 链上pki
- 分片存储
常规区块链使用单链模式，同一时间所有的交易都只能在单个生产区块的节点上面计算，换句话说也就是区块链处理速度的上限就是单台节点的处理速度上限。
如果要提升处理能力，必然需要考虑如何分割任务，将互不影响的任务分发给不同的节点处理，最终汇总，以充分发挥并行处理能力。
以太坊提出了分片的概念，并且已在2.0版本中进行了较长时间的测试验证。
以太坊的分片机制会将单个块中的交易拆散，按实现规定的分片数，将交易分发到不同的节点上进行处理，最后再由信标链（等同于主链）合并校验所有的分片，打包生产新的区块。
以太坊的分片方案让交易可以在分片中并行处理，但依赖信标链做最终合并。
理论上将交易拆分到不同的节点上进行处理可以有效提升并行处理能力，并且可以根据需求进行横向扩展。但不代表这样就已经解决了问题，实际上分片在实际应用中会带来其它问题。
最核心的问题有2点：
- 合并时如何校验数据的正确性。
- 网络如果不分区，所有数据在网络中传播带来的阻塞问题。
区块链不同于传统应用，区块链上的数据都必须经过校验核算，因此分片处理完的数据，在合并时也必须要进行验证，否则发生了数据问题就破坏了链本身的安全性。以上的分片方案在合并时也必须要要进行核算，此时可以有两种方案进行处理，
一是由合并节点进行数据校验，这种方式要求合并节点具备足够强的运算能力与带宽，也就是比普通节点的能力要强的多，才能在足够短的时间内进行有效的核算合并，但物理上单节点的运算能力始终有限，成本高，并且会让整个区块链网络变得更集中化，具备足够计算能力的节点少之又少。
无论怎么增加分片，在合并的时候依然要将运算结果重新计算一遍，在处理复杂智能合约会让网络负担更加不堪重负。
由此我们可以得知，在无法解决如何快速校验分片数据的情况下，单纯地将数据拆分到多个分片上无法在真正意义上节省运算时间，在极限条件每个节点地性能都榨干的情况下，分片与不分片最终的计算累计时间没有本质上的区别。
从一的缺陷中我们可以来讨论第二种方案，即不完全校验分片数据。
假设在一个具备最终一致性的链环境中，例如联盟链环境，链的共识算法采用了BFT系的带最终确定性的特性。
那么我们可以认为这条链上的区块包含的数据具备可信任性，因为每一个区块都满足了分布式一致性算法的计算要求，同理，如果我们将交易产生的数据变更结果，独立成报告数据区块，再经过分布式一致性算法共识，它会被这条链上的所有节点进行计算验证，确保其有效性，也可被认为是有效合法的区块。
在这种前提下，我们就拥有了技术手段，可以节省合并时的数据校验正确性。
核心方案是：
- 需要采用带有最终一致性特性的共识算法。
- 当一条链需要进行横线扩展，需要使用特定的标志，将可以解耦的数据标志在新的分支链进行处理，后续的交易通过标志判断需要在哪条链需要处理，非相关的节点可以选择性略过。
- 通过互不影响的并行链，区块链可以有效进行横向扩展提升并行处理速度。
- 当要开始合并链，需要在分支链上标记结束延续，后续不再延伸分支链。
- 在分支链的末尾生成一个最终数据变更的记录区块，这个区块涵盖了从分支开始到分支结束中所有的交易完成后产生的数据变更汇总（即数据的合并最终状态），并经过一致性确认。
- 原来的主链，通过分支链的最终数据变更记录区块，直接合并数据变化，不再重新计算分支链的所有交易，完全信任分布式一致性算法的确认结果。
由此我们得到了一种类似git分支链路的DAG形式的区块链结构。这种结构：
- 整体上保持了单链模型，不管中间如何分支，最终都会通过合并的形式聚合成单链延伸，而非发散结构，更容易处理最终一致性。
- 所有的中间分支与主链都有对应的开始锚点和结束锚点，具备了可检验的关系。
- 横向扩展能力随分随用，可以按需扩展，不需要一直保持多分支形态。
- 并行处理速度取决于能拆分多少互不影响的交易群，而不是单机处理能力。
智能合约是在区块链上运行的可定制的程序逻辑，具备了智能合约的区块链，才具备了可信计算的平台基础。通过智能合约可以在区块链系统中安全地进行计算，无需顾虑计算结果的安全性，区块链的机制保证了所有节点都会基于一样的源代码执行一样的逻辑，从同样的输入处理产生一样的输出，杜绝了作恶可能性。因此智能合约对于区块链的应用尤为重要。
目前区块链上的智能合约实现方式有两种，一种是以太坊形式的，自建虚拟机，由区块链程序运行虚拟机程序，处理智能合约逻辑，仅支持特定智能合约编程语言。一种是超级账本Fabric形式的，通过容器技术运行智能合约程序，支持部分通用编程语言，通过接口方式处理智能合约逻辑。
前者的实现方式较为可控，虚拟机以及编程语言都为专用设计，因此容易实现，也特别契合区块链的运行逻辑。但学习成本及扩展成本都较为高昂，无法使用累积多年的编程领域宝贵资产。于是产生了后者的模式，后者通过容器技术避免了扩展问题以及部署问题，虽然可以使用常规的通用编程语言，但仍然需要依赖项目提供的智能合约框架，因此同样限制了可移植性和学习难度。
基于智能合约的运作模式属于应答模式（即由区块链软件携带输入数据状态提交给智能合约程序，智能合约程序响应相应的结果，区块链软件再记录处理后的状态），我们可以将智能合约的运行模式剥离成通用的智能合约协议。
这个协议只需要规定：
- 由实现程序负责数据存储，并且支持从参数中还原数据环境。
- 实现程序需要提供规定的访问接口。
- 相同的数据环境，相同的输入参数，实现程序必须要输出相同的结果。
于此，只需要在区块链上建立合适的智能合约版本控制机制，例如引入git，通过哈希版本确定智能合约版本，搭配容器技术进行部署，就可以实现具备更好开放性、更强扩展性、更低学习成本的智能合约模式。
这种协议规定的智能合约模式可以提供：
- 完全开放的智能合约实现模式，可以使用任何编程语言编写逻辑，只需要最终能部署成应用程序，满足协议的规定，就可以提供功能。这样降低了合约编程及部署门槛，并且可以完美使用编程领域的宝贵资产。
- 通过区块链版本控制机制，同样可以保证源程序的一致性和有效性。
- 真正将智能合约应用化，可以更容易进行独立部署、升级、回滚、横向扩展等。提升了区块链系统运行效率。