区块链键值

1. 组成区块链基础运算功能的组织架构内容

随着互联网的都不发展，消费者对区块链技术和数字虚拟货币的认知程度也在不断的提高。今天，我们就一起来了解一下区块链技术的基础运算方法都有哪些结构构成的。下面java课程http://www.kmbdqn.cn/就一起来了解一下具体情况吧。

构成计算技术的基本元素是存储、处理和通信。大型主机、PC、移动设备和云服务都以各自的方式展现这些元素。各个元素之内还有专门的构件块来分配资源。

本文聚焦于区块链的大框架：介绍区块链中各个计算元素的模块以及各个模块的一些实现案例，偏向概论而非详解。

区块链的组成模块

以下是去中心化技术中各个计算元素的构件块：

存储：代币存储、数据库、文件系统/blob

处理：有状态的业务逻辑、无状态的业务逻辑、高性能计算

通信：数据、价值和状态的连接网络

存储

作为基本计算元素，存储部分包含了以下构件块。

代币存储。代币是价值的存储媒介(例如资产、证券等)，价值可以是比特币、航空里程或是数字作品的版权。代币存储系统的主要作用是发放和传输代币(有多种变体)，同时防止多重支付之类的事件发生。

比特币和Zcash是两大“纯净”的、只关注代币本身的系统。以太坊则开始将代币用于各种服务，以实现其充当全球计算中心的理想。这些例子中代币被用作运营整个网络架构的内部激励。

还有些代币不是网络用来推动自身运行的内部工具，而是用做更高级别网络的激励，但它们的代币实际上是存储在底层架构中的。一个例子是像Golem这样的ERC20代币，运行在以太坊网络层上。另一个例子是Envoke的IP授权代币，运行在IPDB网络层上。

数据库。数据库专门用来存储结构化的元数据，例如数据表(关系型数据库)、文档存储(例如JSON)、键值存储、时间序列或图数据库。数据库可以使用SQL这样的查询快速检索数据。

传统的分布式(但中心化)数据库如MongoDB和Cassandra通常会存储数百TB甚至PB级的数据，性能可达到每秒百万次写入。

SQL这样的查询语言是很强大的，因为它将实现与规范区分开来，这样就不会绑定在某个具体的应用上。SQL已经作为标准应用了数十年，所以同一个数据库系统可以用在很多不同的行业中。

换言之，要在比特币之外讨论一般性，不一定要拿图灵完备性说事。你只需要一个数据库就够了，这样既简洁又方便扩展。有些时候图灵完备也是很有用的，我们将在“去中心化处理”一节具体讨论。

BigchainDB是去中心化的数据库软件，是专门的文档存储系统。它基于MongoDB(或RethinkDB)，继承了后者的查询和扩展逻辑。但它也具备了区块链的特征，诸如去中心化控制、防篡改和代币支持。IPDB是BigchainDB的一个受监管的公开实例。

在区块链领域，也可以说IOTA是一个时间序列数据库。

文件系统/blob数据存储。这些系统以目录和文件的层级结构来存储大文件(电影、音乐、大数据集)。

IPFS和Tahoe-LAFS是去中心化的文件系统，包含去中心化或中心化的blob存储。FileCoin、Storj、Sia和Tieron是去中心化的blob存储系统，古老而出色的BitTorrent也是如此，虽然后者使用的是p2p体系而非代币。以太坊Swarm、Dat、Swarm-JS基本上都支持上述两种方式。

数据市场。这种系统将数据所有者(比如企业)与数据使用者(比如AI创业公司)连接在一起。它们位于数据库与文件系统的上层，但依旧是核心架构，因为数不清的需要数据的应用(例如AI)都依赖这类服务。Ocean就是协议和网络的一个例子，可以基于它创建数据市场。还有一些特定应用的数据市场：EnigmaCatalyst用于加密市场，Datum用于私人数据，DataBrokerDAO则用于物联网数据流。

处理

接下来讨论处理这个基本计算元素。

“智能合约”系统，通常指的是以去中心化形式处理数据的系统[3]。它其实有两个属性完全不同的子集：无状态(组合式)业务逻辑和有状态(顺序式)业务逻辑。无状态和有状态在复杂性、可验证性等方面差异巨大。三种去中心化的处理模块是高性能计算(HPC)。

无状态(组合式)业务逻辑。这是一种任意逻辑，不在内部保留状态。用电子工程术语来说，它可以理解为组合式数字逻辑电路。这一逻辑可以表现为真值表、逻辑示意图、或者带条件语句的代码(if/then、and、or、not等判断的组合)。因为它们没有状态，很容易验证大型无状态智能合约，从而创建大型可验证的安全系统。N个输入和一个输出需要O(2^N)个计算来验证。

跨账本协议(ILP)包含crypto-conditions(CC)协议，以便清楚地标出组合电路。CC很好理解，因为它通过IETF成为了互联网标准，而ILP则在各种中心和去中心化的支付网络(例如超过75家银行使用的瑞波)中广泛应用。CC有很多独立实现的版本，包括JavaScript、Python、Java等。BigchainDB、瑞波等系统也用CC，用以支持组合式业务逻辑/智能合约。

2. 区块链核心技术-P2P网络

点对点网络是区块链中核心的技术之一，主要关注的方面是为区块链提供一个稳定的网络结构，用于广播未被打包的交易（交易池中的交易）以及共识过的区块，部分共识算法也需要点对点的网络支撑（如PBFT），另外一个辅助功能，如以太坊的消息网络，也需要点对点网络的支持。

P2P网络分为结构化和非结构化网络两类。结构化网络采用类似DHT算法来构建网络结构；非结构化网络是一种扁平的网络，每个节点都有一些邻居节点的地址。

点对点网络的主要职责有维护网络结构和发送信息这两个方面。网络结构要关注的是新节点的加入和网络更新这两个方面，而发送信息包括广播和单播两个方面

如何建立并维护点对点的整个网络？节点如何加入、退出？
网络结构的建立有两个核心的参数，一个是每个节点向外连接的节点数，第二个是最大转发数。

新节点对于整个网络一无所知，要么通过一个中心的服务获取网络中的一些节点去连接，要么去连接网络中的“种子”节点。

网络更新处理当有新节点加入或者节点退出，甚至原来一些节点网络不好，无法连接，过一段时间又活了，等等这些情况。一般通过节点已有的连接来广播这些路由表的变化。需要注意的是，因为点对点网络的特殊性，每个节点的路由表是不一样的（也叫partial view）

广播一般采用泛洪协议，即收到转发方式，使的消息在网络中扩散，一般要采用一些限制条件，比如一条消息要设置最大的转发数，避免网络的过渡负载。

单播需要结构化网络结构支持，一般是DHT，类似于DNS解析的方式，逐跳寻找目标节点地址，之后进行传输，并且更新本地路由表。

要想快速检索信息，有两种数据结构可以使用，一种是树类型，如AVL树、红黑树、B树等；另外一类是hash表。
哈希表的效率比树更高，但是需要占用更多的内存。
信息的表示采用键值对的方式，即一个键对应一个值，我们要查找的是key，值是附着的信息。
哈希表要解决的问题是如何均匀地为每一个key分配一个存储位置。
这里面有两个重点：1.是为key分配一个存储地点，这个分配算法是固定的，保证存储的时候和查找的时候使用同一个算法，不然存进去之后会找不到；2.是均匀地分配，不能有点地方存放数据多，有点放存放数据少。

一般语言里面的hashtable、map等结构使用这个技术来实现，哈希函数可以直接使用取模函数，key%n，这种方式，n代表有多少个地方，key是整数，如果key是其他类型，需要先进行一次哈希，将key转为整数。这种方式可以解决上面的两个需求，但是当n不够大的时候（小于要存储的数据），会产生冲突，一个地方一定会有两个key要存储，这时候，需要在这个地方放一个链表，将分配到同一地点、不同key，顺序摆放。当一个地点放的key太多后，链表的查找速度太慢，要转化为树类型结构（红黑树或者AVL树）。

上面说过，哈希表效率很高，但是占用内容，使用多台机器就可以解决这个限制。在分布式环境中，可以将上述的地点理解为计算机（后面成为节点），即如何将一个key映射到一个节点上，每个节点有一个节点ID，即key->node id的映射，这个映射算法也要固定。
这个算法还有一个非常重要的要求，即scalebility,当新节点加入和退出时候，需要迁移的key要尽量少。

这个映射算法有两种典型结构，一个是环形，一个是树形；环形的叫一致性哈希算法，树形的典型叫kademlia算法。

选点算法就是解决key->node id的映射算法，形象的来说就是为一个key选择它生命中的她（节点）。

假设我们使用32哈希，那么总共能容纳的key的数据量是2**32，称之为hash空间，把节点的ID映射成整数，key也映射成整数。把key哈希和节点哈希值接的差值的叫做距离（负数的话要取模，不用绝对值），比如一个key的哈希是100（整数表示），一个节点的哈希是105，则这两个的距离是105-100=5。当然使用其他距离表示也可以，比如反过来减，但是算法要固定。我们把key映射（放到）距离他最近的节点上。距离取模的话，看起来就是把节点和key放到一个环上，key归属到从顺时针角度离它最近的节点上。

kademlia算法的距离采用的是key哈希与节点哈希异或计算之后的数值来表示（整数），从左往右，拥有越多的“相同前缀”，则距离越近，越在左边位置不一样，距离越远。
树结构的体现是，将节点和key看成树的节点，这个算法支持的位数是160bit，即20个8字节，树的高度为160，每个边表示一位。
选点的算法和一致性哈希相同，从所有节点中，选择一个距离key距离最小的节点作为这个key的归宿。

由于是在分布式环境中，为了保证高可用，我们假设没有一个中心的路由表，没有这个可以看到全貌的路由表，带来了一些挑战，比如如何发现节点、查找节点？
在P2P网络中，常用的方法是每个节点维护一个部分路由表，即只包含部分节点的路由信息。在泛洪算法中，这些节点上随机的；在DHT算法中，这个路由表是有结构的，维护的节点也是有选择性的。那么如何合理的选择需要维护路由信息的节点呢？

一个朴素的做法是，每一个节点保存比他大的节点的信息，这样可以组成一个环，但是这样做的话，有一个大问题和一个小问题。大问题是，每个节点知道的信息太少(只有下一个节点的哈希和地址)，当给出一个key时，它不知道网络中还有没有比它距离这个key距离还短的节点，所以它首先判断key是否属于自己和下一个节点,如果是，那么这个key就属于下一个节点，如果不是就调用下一个节点同样的方法，这个复杂度是N(节点数)。一个优化的方法是，每个节点i维护的其他节点有：i+2 1, i+2 2,....i+2**31,通过观察这个数据，发现由近到远，节点越来越稀疏。这样可以把复杂度降低到lgN

每个节点保存的其他节点的信息，包括，从左到右，每一位上与本节点不同的节点，最多选择k个（算法的超参数）。比如在节点00110上（为演示起见，选择5位），在要保存的节点路由信息是：
1****: xxx,....,xxx(k个)
01 : xxx,....,xxx(k个)
000 : xxx,....,xxx(k个)
0010 : xxx,....,xxx(k个)
00111: xxx,....,xxx(k个)
以上为一行称为k-bucket。形象的来看，也是距离自己越近，节点越密集，越远，节点越稀疏。这个路由查找、节点查找的算法也是lgN复杂度。