区块链之网络架构详解

引言

到目前为止，我们所构建的原型已经具备了区块链所有的关键特性：匿名，安全，随机生成的地址；区块链数据存储；工作量证明系统；可靠地存储交易。尽管这些特性都不可或缺，但是仍有不足。能够使得这些特性真正发光发热，使得加密货币成为可能的，是网络（network）。如果实现的这样一个区块链仅仅运行在单一节点上，有什么用呢？如果只有一个用户，那么这些基于密码学的特性，又有什么用呢？正是由于网络，才使得整个机制能够运转。

你可以将这些区块链特性认为是规则（rule），类似于人类在一起生活，繁衍生息建立的规则，一种社会安排。区块链网络就是一个程序社区，里面的每个程序都遵循同样的规则，正是由于遵循着同一个规则，才使得网络能够长存。类似的，当人们都有着同样的想法，就能够将拳头攥在一起构建一个更好的生活。如果有人遵循着不同的规则，那么他们就将生活在一个分裂的社区中。同样的，如果有区块链节点遵循不同的规则，那么也会形成一个分裂的网络。

重点在于：如果没有网络，或者大部分节点都不遵守同样的规则，那么规则就会形同虚设，毫无用处！

声明：这是一个实验模式下 P2P 网络原型。本文会展示一个最常见的场景，这个场景涉及不同类型的节点。继续改进这个场景，将它实现为一个 P2P 网络，对你来说是一个很好的挑战和实践！除了本文的场景，无法保证在其他场景将会正常工作。

区块链网络

区块链网络是去中心化的，这意味着没有服务器，客户端也不需要依赖服务器来获取或处理数据。在区块链网络中，有的是节点，每个节点是网络的一个完全（full-fledged）成员。节点就是一切：它既是一个客户端，也是一个服务器。这一点需要牢记于心，因为这与传统的网页应用非常不同。

+

区块链网络是一个 P2P（Peer-to-Peer，端到端）的网络，即节点直接连接到其他节点。它的拓扑是扁平的，因为在节点的世界中没有层级之分。下面是它的示意图：

要实现这样一个网络节点更加困难，因为它们必须执行很多操作。每个节点必须与很多其他节点进行交互，它必须请求其他节点的状态，与自己的状态进行比较，当状态过时时进行更新。

节点角色

尽管节点具有完备成熟的属性，但是它们也可以在网络中扮演不同角色。比如：

矿工 这样的节点运行于强大或专用的硬件（比如 ASIC）之上，它们唯一的目标是，尽可能快地挖出新块。矿工是区块链中唯一可能会用到工作量证明的角色，因为挖矿实际上意味着解决 PoW 难题。在权益证明 PoS 的区块链中，没有挖矿。

全节点 这些节点验证矿工挖出来的块的有效性，并对交易进行确认。为此，他们必须拥有区块链的完整拷贝。同时，全节点执行路由操作，帮助其他节点发现彼此。对于网络来说，非常重要的一段就是要有足够多的全节点。因为正是这些节点执行了决策功能：他们决定了一个块或一笔交易的有效性。

+

SPV SPV 表示 Simplified Payment Verification，简单支付验证。这些节点并不存储整个区块链副本，但是仍然能够对交易进行验证（不过不是验证全部交易，而是一个交易子集，比如，发送到某个指定地址的交易）。一个 SPV 节点依赖一个全节点来获取数据，可能有多个 SPV 节点连接到一个全节点。SPV 使得钱包应用成为可能：一个人不需要下载整个区块链，但是仍能够验证他的交易。

网络简化

为了在目前的区块链原型中实现网络，我们不得不简化一些事情。因为我们没有那么多的计算机来模拟一个多节点的网络。当然，我们可以使用虚拟机或是 Docker 来解决这个问题，但是这会使一切都变得更复杂：你将不得不先解决可能出现的虚拟机或 Docker 问题，而我的目标是将全部精力都放在区块链实现上。所以，我们想要在一台机器上运行多个区块链节点，同时希望它们有不同的地址。为了实现这一点，我们将使用端口号作为节点标识符，而不是使用 IP 地址，比如将会有这样地址的节点：127.0.0.1:3000，127.0.0.1:3001，127.0.0.1:3002等等。我们叫它端口节点（port node） ID，并使用环境变量对它们进行设置。故而，你可以打开多个终端窗口，设置不同的运行不同的节点。

这个方法也需要有不同的区块链和钱包文件。它们现在必须依赖于节点 ID 进行命名，比如 blockchain_3000.db, blockchain_30001.db and wallet_3000.db, wallet_30001.db 等等。

实现

所以，当你下载 Bitcoin Core 并首次运行时，到底发生了什么呢？它必须连接到某个节点下载最新状态的区块链。考虑到你的电脑并没有意识到所有或是部分的比特币节点，那么连接到的“某个节点”到底是什么？

+

在 Bitcoin Core 中硬编码一个地址，已经被证实是一个错误：因为节点可能会被攻击或关机，这会导致新的节点无法加入到网络中。在 Bitcoin Core 中，硬编码了DNS seeds。虽然这些并不是节点，但是 DNS 服务器知道一些节点的地址。当你启动一个全新的 Bitcoin Core 时，它会连接到一个种子节点，获取全节点列表，随后从这些节点中下载区块链。

不过在我们目前的实现中，无法做到完全的去中心化，因为会出现中心化的特点。我们会有三个节点：

一个中心节点。所有其他节点都会连接到这个节点，这个节点会在其他节点之间发送数据。

一个矿工节点。这个节点会在内存池中存储新的交易，当有足够的交易时，它就会打包挖出一个新块。

一个钱包节点。这个节点会被用作在钱包之间发送币。但是与 SPV 节点不同，它存储了区块链的一个完整副本。

场景

本文的目标是实现如下场景：

中心节点创建一个区块链。

一个其他（钱包）节点连接到中心节点并下载区块链。

另一个（矿工）节点连接到中心节点并下载区块链。

钱包节点创建一笔交易。

矿工节点接收交易，并将交易保存到内存池中。

当内存池中有足够的交易时，矿工开始挖一个新块。

当挖出一个新块后，将其发送到中心节点。

钱包节点与中心节点进行同步。

钱包节点的用户检查他们的支付是否成功。

这就是比特币中的一般流程。尽管我们不会实现一个真实的 P2P 网络，但是我们会实现一个真实，也是比特币最常见最重要的用户场景。

版本

节点通过消息（message）进行交流。当一个新的节点开始运行时，它会从一个 DNS 种子获取几个节点，给它们发送消息，在我们的实现看起来就像是这样：

type version struct {

Version int

BestHeight int

AddrFrom string}

由于我们仅有一个区块链版本，所以字段实际并不会存储什么重要信息。存储区块链中节点的高度。存储发送者的地址。

接收到消息的节点应该做什么呢？它会响应自己的消息。这是一种握手：如果没有事先互相问候，就不可能有其他交流。不过，这并不是出于礼貌：用于找到一个更长的区块链。当一个节点接收到消息，它会检查本节点的区块链是否比的值更大。如果不是，节点就会请求并下载缺失的块。

为了接收消息，我们需要一个服务器：

var nodeAddress stringvar knownNodes = []string{"localhost:3000"}func StartServer(nodeID, minerAddress string) {

nodeAddress = fmt.Sprintf("localhost:%s", nodeID)

miningAddress = minerAddress

ln, err := net.Listen(protocol, nodeAddress)

defer ln.Close()

bc := NewBlockchain(nodeID)

if nodeAddress != knownNodes[0] {

sendVersion(knownNodes[0], bc)

}

for {

conn, err := ln.Accept()

go handleConnection(conn, bc)

}}

首先，我们对中心节点的地址进行硬编码：因为每个节点必须知道从何处开始初始化。参数指定了接收挖矿奖励的地址。代码片段：

if nodeAddress != knownNodes[0] {

sendVersion(knownNodes[0], bc)}

这意味着如果当前节点不是中心节点，它必须向中心节点发送消息来查询是否自己的区块链已过时。

func sendVersion(addr string, bc *Blockchain) {

bestHeight := bc.GetBestHeight()

payload := gobEncode(version)

request := append(commandToBytes("version"), payload...)

sendData(addr, request)}

我们的消息，在底层就是字节序列。前 12 个字节指定了命令名（比如这里的），后面的字节会包含gob编码的消息结构，看起来是这样：

func commandToBytes(command string) []byte {

var bytes [commandLength]byte

for i, c := range command {

bytes[i] = byte(c)

}

return bytes[:]}

它创建一个 12 字节的缓冲区，并用命令名进行填充，将剩下的字节置为空。下面一个相反的函数：

func bytesToCommand(bytes []byte) string {

var command []byte

for _, b := range bytes {

if b != 0x0 {

command = append(command, b)

}

}

return fmt.Sprintf("%s", command)}

当一个节点接收到一个命令，它会运行来提取命令名，并选择正确的处理器处理命令主体：

func handleConnection(conn net.Conn, bc *Blockchain) {

request, err := ioutil.ReadAll(conn)

command := bytesToCommand(request[:commandLength])

fmt.Printf("Received %s command\n", command)

switch command {

...

case "version":

handleVersion(request, bc)

default:

fmt.Println("Unknown command!")

}

conn.Close()}

下面是命令处理器：

func handleVersion(request []byte, bc *Blockchain) {

var buff bytes.Buffer var payload verzion

buff.Write(request[commandLength:])

dec := gob.NewDecoder(&buff)

err := dec.Decode(&payload)

myBestHeight := bc.GetBestHeight()

foreignerBestHeight := payload.BestHeight if myBestHeight

sendGetBlocks(payload.AddrFrom)

} else if myBestHeight > foreignerBestHeight {

sendVersion(payload.AddrFrom, bc)

}

if !nodeIsKnown(payload.AddrFrom) {

knownNodes = append(knownNodes, payload.AddrFrom)

}}

首先，我们需要对请求进行解码，提取有效信息。所有的处理器在这部分都类似，所以我们会下面的代码片段中略去这部分。

然后节点将从消息中提取的与自身进行比较。如果自身节点的区块链更长，它会回复消息；否则，它会发送消息。

好，上半部分已经结束，接下来的内容会比较复杂。敬请期待。