在现有的可扩展性解决方案中,切分可能是支持水平可扩展性的最常用解决方案。
切分的基本思想是将一个全局系统状态划分为多个子状态,并相对独立地处理每个切分中的交易。
通过分片技术的适当设计,系统的容量能够随着切分和处理器(节点)数量的增加而增加,换句话说,即线性规模。
要应用分片,我们需要回答几个关键问题:
系统的全局状态是什么?如何更改系统状态?
例如,在分布式键值(KV)存储中(例如,BigTable、Cassandra),系统状态是从任意字节(键)到任意字节(值)的映射,而更改系统状态的操作是:创建、读取、更新和删除(CRUD)。
另一个例子是分布式只追加文件系统(例如,Google文件系统)。(GFS),Hadoop分布式文件系统(HDFS)),如果系统状态是一组目录和文件,并且操作是两组:在目录中创建、删除和列表操作,以及打开、追加、读取和关闭文件的操作。
如何将系统状态划分为碎片,以便所有操作都能得到正确有效的处理?
分区的方式对系统的性能是至关重要的,如果分区的设计不合适,那么系统的性能会很差。要设计分区,我们需要考虑以下几个关键方面:
· 状态到分区:系统状态的哪些部分应该分区?为了简化系统模型,我们应该只划分系统状态的部分:1)太大而不能在一个节点中;或者2)要求较高的每秒操作,而我们可能不会对系统状态中大小小到足以在单机上运行且操作不频繁的部分进行分区。例如,早期版本的GFS/HDFS只分区文件中的数据,而不分区目录,因为目录的数据大小相对较小(与文件中的数据相比),而且目录操作也很少。
· 确保操作(交易)语义:如何划分系统状态以满足操作语义?一个关键的语义是原子性,如果一个操作以原子性的方式改变多个碎片中的状态,这样的操作需要在碎片之间进行适当的协调(例如,通过分布式锁),这可能是昂贵的。因此,这种操作的性能很难从分片技术中获益。——有时表现甚至更糟。为了避免这样的问题,大多数现代的分片系统都支持在一个分片中进行原子批处理操作,并让上层应用程序处理复杂的多分片原子性问题。
· 平衡负载/大小:如何划分系统状态, a),所有碎片的负载在统计上均匀分布;b),分区系统状态的大小也统计均匀地分布在所有碎片上。实现这些是线性标度的关键前提。只要在添加更多的碎片后负载/大小均匀分布,我们就能够通过添加更多节点来处理新的碎片来线性地增加系统容量。请注意,这些发行版与用户操作模式高度相关,如果用户操作模式随时间变化很大,可能会导致负载不均匀(暂时或永久)。
· 重新切分:如何添加更多的碎片,以及新节点如何能够为新碎片服务。添加更多的碎片后,新碎片将由旧碎片中的一些状态组成,这些状态将迁移到新节点。在重新格式化期间的迁移可能需要时间并暂停现有的服务。此外,我们还需要确保所支持的操作在重塑之前和之后的语义相同。
在回答上述关于夸克链的问题之前,让我们先介绍现有区块链的系统模型和分片的难点。
现有区块链的系统状态和交易
我们考虑一个基于账户的区块链模型,类似于以太坊,其中系统状态基本上是一个从地址到账户数据的键值映射。地址有两种类型:
· 用户地址;及
· 智能合约地址;
账户数据包括
· 平衡;
· 临时措施;
· 代码;
· 储存;
其中用户地址的代码和存储为空。
CRUD操作的不同组合支持两种类型的交易:
1、两个用户地址之间的转账交易,主要是更新两个地址的余额和发送方的暂存;
2、只能合同交易,它可以
· 更新发件人的名称;
· 更新多个用户地址的余额;
· 通过调用和委托更新多个智能契约的余额和存储;
· 创建多个用户地址及其帐户数据;
· 创建多个智能契约。
区块链分片中的挑战
与现有的可扩展性解决方案相比,区块链切分带来的挑战是,区块链的系统状态与BigTable和Cassandra等分布式KV存储完全相同;然而,坏消息是,交易语义比简单的CRUD操作复杂得多–智能契约交易可能对系统状态的任何键值对执行任何CRUD操作。如果将状态划分为不同的子状态(碎片),则要确保跨多个碎片的原子性将非常困难(大多数情况下是不可能的)。如何分割区块链分类帐是区块链分片的根本问题。
此外,去中心化的世界面临更多挑战,因为我们需要建立适当的共识,以安全的方式处理所有碎片中的交易。新的切分共识打开了新的攻击可能性,因此如果没有对线程模型的全面分析,切分可能很容易被破坏,因此整个网络很容易被破坏。
除了分区和共识的挑战之外,切分的另一个常见问题是切分之间的互操作性,即跨切分交易。底层的逻辑是可用性——用户应该能够访问所有资源,包括智能合约和跨所有分片的其他用户帐户。如何开发高效、安全的跨切分交易是一个关键问题。
在接下来的文章中,我们将讨论夸克链在区块链切分方面的解决方案。此外,我们将比较夸克链与现有的集中式系统,如谷歌的BigTable,并说明其与集中式系统的异同。