聊聊|聊聊 CITA 节点的那点事聊聊CITA节点的那点事

本周想和大家聊聊 CITA 节点那点事。主要包括以下三方面内容：

普通节点
共识节点
节点个数

普通节点定义
普通节点，其含义是该节点可以同步区块链上的交易，并且对交易进行验证执行，同时，还可以接受 DApp 的 JSON-RPC 请求；但它并不参与共识投票，也不会主动发起区块让其它节点投票。也就是如节点分类中定义的那样，普通节点除了没有出块和投票的权限外，其它能与与共识节点相同。
有些客户也把 CITA 的普通节点称做只读节点，其含义都是同一个，大家需知晓。
如何获得一个普通节点
在向 CITA 网络中添加一个节点时，首先需要获得一个对应链的节点配置文件。
假设有一条链已经在运行（为了下文件描述的方便，暂称 chain_x），现在需要在 chain_x 上添加一个普通节点。要完成这个操作：
首先需要回到原来生成 chain_x 的目录。也就是之前你用命令初始化链的那个目录，你是否还记得如下面的初始化链的命令：
$ bin/cita create --chain_name chain_x --super_admin “0x37d1c7449bfe76fe9c445e626da06265e9377601” --nodes “127.0.0.1:4000,127.0.0.1:4001,127.0.0.1:4002,127.0.0.1:4003”
就是需要把到这个地方！！然后执行：
$ bin/cita append --chain_name chain_x --node “127.0.0.1:4004”
这个 append 命令执行成功后，就能在在 chain_x 目录下获得一个新的节点配置文件，如：
$ ls chain_x/
0 1 2 3 4 template
其中 4 便是新生成的节点配置文件。
将这个配置文件分发到对应该的服务器启动，新节点将自动加入 chain_x 网络，而这个新节点便是一个普通节点。
有这里，我有必要解释一下，为什么一定要回对之前的初始化目录？最重要的原因是，新添加的节点需要使用与 chain_x 其它节点相同的创世块，否则它将无法同步 chain_x 的块，也就无法加入 chain_x 这个网络。
所以，当大家开始运维一条 CITA 链时，在这里有两个 Tips 给到大家：

请妥善保管好这个初始化的目录，因为后面添加节点需要用到它；
在运行单个节点时，最好把对应单个节点的配置从初始化目录中独立出来，初始化目录单独管理会比较好一些。

除了 append 的可以获一个普通节点，还可以将一个共识节点降级为普通节点。这在下面的共识节点小节中会详细说明。
如何删除一个普通节点
CITA 使用的是 p2p 网络来接入新节点，当一个普通节点关闭后（包括关机或关闭相关进程），它将自动退出网络。
p2p 是自由接入的网络，理论上讲一个符合条件的普通节点是可以随时自由地进出网络的。链的管理者如果想去删除一个普通节点，让其强制退出网络，需要使用防火墙机制禁止对应节点的 tcp 连接。
共识节点定义
共识节点具有出块和投票权限，交易由共识节点排序并打包成块，共识完成后即被确认为合法区块。
简单地说，共识节点就是参与出块的节点。
如何获得一个共识节点

所有在初始化时生成的节点都是共识节点。
可以将一个普通节点升级为共识节点。

【聊聊|聊聊 CITA 节点的那点事】如将公钥地址为 0x59a316df602568957f47973332f1f85ae1e2e75e 的节点升级为共识节点：
$ cita-cli scm NodeManager approveNode
–address 0x59a316df602568957f47973332f1f85ae1e2e75e
–admin-private 0x5f0258a4778057a8a7d97809bd209055b2fbafa654ce7d31ec7191066b9225e6
–url http://127.0.0.1:1337
可以看到，这个需要传入 --admin-private，即链的管理员私钥，所以大家在创建链以后，一定要妥善保管好私钥，因为后面链的维护和管理都需要管理员私钥。
重要 Tips ：
大家在增加共识节点前，最好确保这个节点已经是普通节点，并且已经同步到最高的区块。否则，可能因为这个新增的共识节点没有到达最高区块而无法参与共识，从而影响链的容错能力。
不要一次增加多个共识节点，要待前一个增加完成，并且正常出块后再增加下一个。否则可能会因新增的节点暂时无法参加共识而导致整个链无法出块。
如何删除一个共识节点
准确地说，应该是取消一个共识节点的出块与投票权限，即将其降为普通节点。
如取消公钥地址为 0x59a316df602568957f47973332f1f85ae1e2e75e 的节点共识权限：
$ cita-cli scm NodeManager deleteNode
–address 0x59a316df602568957f47973332f1f85ae1e2e75e
–admin-private 0x5f0258a4778057a8a7d97809bd209055b2fbafa654ce7d31ec7191066b9225e6
–url http://127.0.0.1:1337
节点个数之前有好几次与客户交流的时候曾提到以下的问题：

使用 CITA 一定要部署 4 个节点吗？
使用 CITA 部署多少个节点合适？

在这里首先想回答的是 CITA 可以部署 1 个节点，而不是大家常理解的必须部署 4 个节点。
以下，我想从三方面谈谈 CITA 的节点个数问题。
多副本性
CITA 天生就是一个多副本系统，当其中一个副本出错、被意外删除或其它原因导致不可用时，能够自动地从其它节点同步数据。
其实多副本系统部署在不同机器甚至是不同地理位置的机器才能发挥它的最大功效。如果你只有一台机器（或云主机），其实部署一个 CITA 节点就可以了，因为在同一台机器上部署多个 CITA 节点，其容错能力并没有提高，如果这台机器宕机了，整个链也就不能工作了。
那么，部署 2 个或 3 个 CITA 节点是不是就没有意义了呢？在我看来，是有意义的！虽然它没有节点容错能力，但如果你能在不同地理位置部署 2 个或 3 个 CITA 节点，意味着它是一个多副本系统；一方面，它可以承载不同地理位署的业务流量，同时，当其中一个节点的数据不可用时，可以从其它节点恢复正确的数据。
容错性
CITA 采用的是类 PBFT 共识，具有一定的容错能力，其容错的节点个数（这里讲的是共识节点个数）:
n = (N - 1) / 3, 其中 n 与 N 都是自然数
当你希望获得 1 个节点的容错能力时，你就至少要部署 4 个共识节点，当前希望获得 2 个节点的容错能力时，就至少要部署 7 个共识节点，依次类推。
这里所讲的容错能力，是指即使有 n 个节点出错、宕机、或做恶，整个 CITA 区块链系统还能够正常工作。
验证能力大家可能比较困惑普通节点能做什么，以及应该部署几个合适。
我觉得普通节点主要给你带来两方面的能力：