以太坊添加新节点

A. Quorum介绍

Quorum和以太坊的主要区别:

Quorum 的主要组件：

1,用其自己实现的基于投票机制的共识方式 来代替原来的 “Proof of work” 。
2,在原来无限制的P2P传输方式上增加了权限功能。使得P2P传输只能在互相允许的节点间传输。
3, 修改区块校验逻辑使其能支持 private transaction。
4, Transaction 生成时支持 transaction 内容的替换。这个调整是为了能支持联盟中的私有交易。

Constellation 模块的主要职责是支持 private transaction。Constellation 由两部分组成：Transaction Manager 和 Enclave。Transaction Manager 用来管理和传递私有消息，Enclave 用来对私有消息的加解密。

在私有交易中，Transaction Manager 会存储私有交易的内容，并且会将这条私有交易内容与其他相关的 Transaction Manager 进行交互。同时它也会利用 Enclave 来加密或解密其收到的私有交易。

为了能更有效率的处理消息的加密与解密，Quorum 将这个功能单独拉出并命名为 Enclave 模块。Enclave 和 Transaction Manager 是一对一的关系。

在 Quorum 中有两种交易类型，”Public Transaction” 和 “Privat Transaction”。在实际的交易中，这两种类型都采用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基础上添加了一个新的 “privateFor” 字段。同时，针对一个 tx 类型的对象添加了一个新的方法 “IsPrivate”。用 “IsPrivate” 方法来判断 Transaction是 public 还是 private，用 “privateFor” 来记录 事务只有谁能查看。

Public Transaction 的机理和以太坊一致。Transaction中的交易内容能被链上的所有人访问到。

Private Transaction 虽然被叫做 “Private”，但是在全网上也会出现与其相关的交易。只不过交易的明细只有与此交易有关系的成员才能访问到。在全网上看到的交易内容是一段hash值，当你是交易的相关人员时，你就能利用这个hash值，然后通过 Transaction Manager 和 Enclave 来获得这笔交易的正确内容。

Public Transaction的处理流程和以太坊的Transaction流程一致。Transaction 广播全网后，被矿工打包到区块中。节点收到区块并校验区块中的 事务 信息。然后根据 Transaction信息更新本地的区块

Private Transaction也会将 Transaction 广播至全网。但是它的 Transaction payload已经从原来的真实内容替换为一个hash值。这个hash值是由Transaction Manager提供的。

有两个共识机制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都采用了 QuorumChain。
从 2.0 版本开始，Quorum 废弃了 QuorumChain 转而只支持 Raft-based Consensus。

QuorumChain Consensus 是一个基于投票的共识算法。其主要特点有：

相比较以太坊的POW，Raft-based 提供了更快更高效的区块生成方式。相比 QuorumChain，Raft-based 不会产生空的区块，而且在区块的生成上比前者更有效率。

要想了解Raft-based Consensus，必须先了解Raft算法

Raft算法
Raft是一种一致性算法，是为了确保容错性，也就是即使系统中有一两个服务器当机，也不会影响其处理过程。这就意味着只要超过半数的大多数服务器达成一致就可以了，假设有N台服务器，N/2 +1 就超过半数，代表大多数了。
Raft的工作模式：
raft的工作模式是一个Leader和多个Follower模式，即我们通常说的领导者-追随者模式。除了这两种身份，还有Candidate身份。下面是身份的转化示意图

1，leader的选举过程
raft初始状态时所有server都处于Follower状态，并且随机睡眠一段时间，这个时间在0~1000ms之间。最先醒来的server A进入Candidate状态，Candidate状态的server A有权利发起投票，向其它所有server发出投票请求，请求其它server给它投票成为Leader。
2，Leader产生数据并同步给Follower
Leader产生数据，并向其它Follower节点发送数据添加请求。其它Follower收到数据添加请求后，判断该append请求满足接收条件（接收条件在后面安全保证问题3给出），如果满足条件就将其添加到本地，并给Leader发送添加成功的response。Leader在收到大多数Follower添加成功的response后。提交后的log日志就意味着已经被raft系统接受，并能应用到状态机中了。

Leader具有绝对的数据产生权利，其它Follower上存在数据不全或者与Leader数据不一致的情况时，一切都以Leader上的数据为主，最终所有server上的日志都会复制成与Leader一致的状态。

Raft的动态演示： http://thesecretlivesofdata.com/raft/

安全性保证，对于异常情况下Raft如何处理：

1，Leader选举过程中，如果有两个FollowerA和B同时醒来并发出投票请求怎么办？
在一次选举过程中，一个Follower只能投一票，这就保证了FollowerA和B不可能同时得到大多数（一半以上）的投票。如果A或者B中其一幸运地得到了大多数投票，就能顺利地成为Leader，Raft系统正常运行下去。但是A和B可能刚好都得到一半的投票，两者都成为不了Leader。这时A和B继续保持Candidate状态，并且随机睡眠一段时间，等待进入到下一个选举周期。由于所有Follower都是随机选择睡眠时间，所以连续出现多个server竞选的概率很低。
2，Leader挂了后，如何选举出新的Leader？
Leader在正常运行时候，会周期性的向Follower节点发送数据的同步请求，同时也是起到一个心跳作用。Follower节点如果在一段时间之内（一般是2000ms左右）没有收到数据同步请求，则认为Leader已经死了，于是进入到Candidate状态，开始发起投票竞选新的Leader，每个新的Leader产生后就是一个新的任期，每个任期都对应一个唯一的任期号term。这个term是单调递增的，用来唯一标识一个Leader的任期。投票开始时，Candidate将自己的term加1，并在投票请求中带上term；Follower只会接受任期号term比自己大的request_vote请求，并为之投票。 这条规则保证了只有最新的Candidate才有可能成为Leader。

3，Follower的数据的生效时间
Follower在收到一条添加数据请求后，是否立即保存并将其应用到状态机中去？如果不是立即应用，那么由什么来决定该条日志生效的时间？
首先会检查这条数据同步请求的来源信息是否与本地保存的leader信息符合，包括leaderId和任期号term。检查合法后就将日志保存到本地中，并给Leader回复添加log成功，但是不会立即将其应用到本地状态机。Leader收到大部分Follower添加log成功的回复后，就正式将这条日志commit提交。Leader在随后发出的心跳append_entires中会带上已经提交日志索引。Follower收到Leader发出的心跳append_entries后，就可以确认刚才的log已经被commit(提交)了，这个时候Follower才会把日志应用到本地状态机。下表即是append_entries请求的内容，其中leaderCommit即是Leader已经确认提交的最大日志索引。Follower在收到Leader发出的append_entries后即可以通过leaderCommit字段决定哪些日志可以应用到状态机。

4，向raft系统中添加新机器时，由于配置信息不可能在各个系统上同时达到同步状态，总会有某些server先得到新机器的信息，有些server后得到新机器的信息。比如在raft系统中有三个server，在某个时间段中新增加了server4和server5这两台机器。只有server3率先感知到了这两台机器的添加。这个时候如果进行选举，就有可能出现两个Leader选举成功。因为server3认为有3台server给它投了票，它就是Leader，而server1认为只要有2台server给它投票就是Leader了。raft怎么解决这个问题呢？

产生这个问题的根本原因是，raft系统中有一部分机器使用了旧的配置，如server1和server2，有一部分使用新的配置，如server3。解决这个问题的方法是添加一个中间配置(Cold, Cnew)，这个中间配置的内容是旧的配置表Cold和新的配置Cnew。这个时候server3收到添加机器的消息后，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)来做决策。比如说server3在竞选Leader的时候，不仅需要得到Cold中的大部分投票，还要得到Cnew中的大部分投票才能成为Leader。这样就保证了server1和server2在使用Cold配置的情况下，还是只可能产生一个Leader。当所有server都获得了添加机器的消息后，再统一切换到Cnew。raft实现中，将Cold，(Cold,Cnew)以及Cnew都当成一条普通的日志。配置更改信息发送Leader后，由Leader先添加一条 (Cold, Cnew)日志，并同步给其它Follower。当这条日志(Cold, Cnew)提交后，再添加一条Cnew日志同步给其它Follower，通过Cnew日志将所有Follower的配置切换到最新。

Raft算法和以太坊结合
所以为了连接以太坊节点和 Raft 共识，Quorum 采用了网络节点和 Raft 节点一对一的方式来实现 Raft-based 共识

一个Transaction完整流程
1，客户端发起一笔 Transaction并通过 RPC 来呼叫节点。
2，节点通过以太坊的 P2P 协议将节点广播给网络。
3，当前的 Raft leader 对应的以太坊节点收到了 Transaction后将它打包成区块。
区块被 编码后传递给对应的 Raft leader。
leader 收到区块后通过 Raft 算法将区块传递给 follower。这包括如下步骤：
3.1，leader 发送 AppendEntries 指令给 follower。
3.2，follower 收到这个包含区块信息的指令后，返回确认回执给 leader。
3.3，leader 收到不少于指定数量的确认回执后，发送确认 append 的指令给 follower。
3.4，follower 收到确认 append 的指令后将区块信息记录到本地的 Raft log 上。
3.5，Raft 节点将区块传递给对应的 Quorum 节点。Quorum 节点校验区块的合法性，如果合法则记录到本地链上。

参考链接： http://blog.csdn.net/about_blockchain/article/details/78684901

B. 以太坊多节点私有链部署

假设两台电脑A和B
要求：
1、两台电脑要在一个网络中，能ping通
2、两个节点使用相同的创世区块文件
3、禁用ipc;同时使用参数--nodiscover
4、networkid要相同，端口号可以不同

1.4 搭建私有链
1.4.1 创建目录和genesis.json文件
创建私有链根目录./testnet
创建数据存储目录./testnet/data0
创建创世区块配置文件./testnet/genesis.json

1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json

1.4.3 启动私有节点

1.4.4 创建账号
personal.newAccount()
1.4.5 查看账号
eth.accounts
1.4.6 查看账号余额
eth.getBalance(eth.accounts[0])
1.4.7 启动&停止挖矿
启动挖矿：
miner.start(1)
其中 start 的参数表示挖矿使用的线程数。第一次启动挖矿会先生成挖矿所需的 DAG 文件，这个过程有点慢，等进度达到 100% 后，就会开始挖矿，此时屏幕会被挖矿信息刷屏。
停止挖矿，在 console 中输入：
miner.stop()
挖到一个区块会奖励5个以太币，挖矿所得的奖励会进入矿工的账户，这个账户叫做 coinbase，默认情况下 coinbase 是本地账户中的第一个账户，可以通过 miner.setEtherbase() 将其他账户设置成 coinbase。

1.4.8 转账
目前，账户 0 已经挖到了 3 个块的奖励，账户 1 的余额还是0：

我们要从账户 0 向账户 1 转账，所以要先解锁账户 0，才能发起交易：

发送交易，账户 0 -> 账户 1：

需要输入密码 123456

此时如果没有挖矿，用 txpool.status 命令可以看到本地交易池中有一个待确认的交易，可以使用 eth.getBlock("pending", true).transactions 查看当前待确认交易。

使用 miner.start() 命令开始挖矿：
miner.start(1);admin.sleepBlocks(1);miner.stop();

新区块挖出后，挖矿结束，查看账户 1 的余额，已经收到了账户 0 的以太币：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')

用同样的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json

启动私有节点一,修改 rpcport 和port

可以通过 admin.addPeer() 方法连接到其他节点，两个节点要要指定相同的 chainID。

假设有两个节点：节点一和节点二，chainID 都是 1024，通过下面的步骤就可以从节点二连接到节点一。

首先要知道节点一的 enode 信息，在节点一的 JavaScript console 中执行下面的命令查看 enode 信息：

admin.nodeInfo.enode
" enode://@[::]:30303 "

然后在节点二的 JavaScript console 中执行 admin.addPeer()，就可以连接到节点一：

addPeer() 的参数就是节点一的 enode 信息，注意要把 enode 中的 [::] 替换成节点一的 IP 地址。连接成功后，节点一就会开始同步节点二的区块，同步完成后，任意一个节点开始挖矿，另一个节点会自动同步区块，向任意一个节点发送交易，另一个节点也会收到该笔交易。

通过 admin.peers 可以查看连接到的其他节点信息，通过 net.peerCount 可以查看已连接到的节点数量。

除了上面的方法，也可以在启动节点的时候指定 --bootnodes 选项连接到其他节点。 bootnode 是一个轻量级的引导节点，方便联盟链的搭建 下一节讲 通过 bootnode 自动找到节点

参考： https://cloud.tencent.com/developer/article/1332424

C. geth以太坊客户端轻节点模式启动怎么与全节点启动的geth连接

一般来说，Undefined index就是自己编写过程中出现了的的确确的写法问题notice一般提示关于与执行代码没有直接关系的错误，但不要忘记，notice有时会返回一些多余的错误信息

D. 可以用云服务器搭建以太坊私有链节点吗

可以的，但是建议使用海外服务器会比较好，另外服务器的配置要中等或以上。

E. 什么是区块链扩容

扩容，是当某个容器或承载物不足以支撑或承载现有事物需求时，我们通过扩大容器的容量或承载物的体积来满足日益增长的需求，从而缓解当前容器或承载物所受压力的一种手段。
在比特币诞生之初比特币创始人中本聪并没有特意限制区块的大小，区块最大可以达到32MB，当时平均每个区块大小为1~2KB。
时比特币用户少，交易量也没有那么大，并不会造成区块拥堵，然而2013年至今随着比特币价格的直线上升，用户越来越多因此造成比特币网络拥堵，用户交易费用上升的问题逐渐涌现出来。
到现在，比特币区块链上最高时有几十万笔交易积压，比特币的平均交易费用比 2010 年 9 月上涨了 376 倍，每秒 7 笔交易的处理速度已经明显无法满足用户需求，比特币社区开始探索如何给比特币“扩容”。
通过修改比特币底层代码，从而达到提高交易处理能力的目的。
比特币扩容本身发展和设计方案有两种，即第一层和第二层扩容技术。
· 第一层扩容技术即改进区块链自身，把区块链自身变得更快、容量变得更大，总的来说就是改变区块链共识部分的内容。
· 第二层扩容技术目的是把计算移到链下，即通过侧链的技术加以解决问题。
扩容协议及结局
扩容协议一般需要矿工们的支持，大致可以分为修改区块大小、软分叉、硬分叉、隔离见证等方式。
以比特币举例：
比特币现在分裂成为大区块Bitcoin Cash(BCH)和隔离见证。隔离见证现在是市场上公认的比特币，而大区块币被冠名为比特现金。可以预见的往后的发展方向，比特币将会以链下交易为主。包括闪电网络、侧链。这两个新东西目前不成熟，但是被很多人寄予厚望的。
比特币将会大量发展隔离见证交易，并在隔离见证的基础上做更多的衍生技术。最有可能是以技术推动比特币往前发展。
比特现金将会以链上交易为主，重点发展货币功能，以降低交易摩擦为主要方式，以获利更广泛的链上用户量为主要发展方向。
链乔教育在线旗下学硕创新区块链技术工作站是中国教育部学校规划建设发展中心开展的“智慧学习工场2020-学硕创新工作站 ”唯一获准的“区块链技术专业”试点工作站。专业站立足为学生提供多样化成长路径，推进专业学位研究生产学研结合培养模式改革，构建应用型、复合型人才培养体系。

F. 2022以太坊节点数量

2022以太坊节点数量达到了2000多点，数量非常的稳定庞大，能够体现出目前以太币的强势和利好，非常适合投资。

G. 以太坊硬分叉是什么

硬分叉是一种不支持向后兼容的软件升级方式。通常，这些情况发生在节点以与旧节点的规则冲突的方式添加新规则时。新节点只能与运行新版本的软件节点进行交互。结果，区块链发生了分裂，生产出两个单独的网络：一个按照旧规则运行，一个则按照新规则运行。节点在升级后变为蓝色。之前的黄色节点拒绝蓝色节点的连入，而蓝色的节点之间可以相互连接。因此，现在有两个网络并行运行。他们将继续产生区块和交易，但不再在同一区块链上工作。在区块链网络达到分叉区块之前，所有节点都具有相同的区块链（并且历史记录仍然存在），但是这之后它们将具有不同的区块和交易。由于存在相同的历史记录，因此如果您在分叉之前持有代币，那么您将在这两个网络上同时获得代币。假设在600,000区块高度发生分叉时，您手里有5 BTC。您可以选择在区块高度到达600,001时，在原始区块链上将这5个代币花费掉，但是在新产生的区块链上并不会记录这笔在600,001区块高度的消费。假设加密方式没有发生变化，那么在新的分叉网络上您的私钥中仍然会存在这5个代币。 以太坊硬分叉的一个案例是2016 年 6 月 17 日，the DAO 合约上出现漏洞并被攻击者乘虚而入，导致约三百六十万 ETH 被盗取。根据该合约的设计，这些资金需要被冻结 28 天才能成功被转移。如果没有采取任何措施的话，黑客会拥有 ETH 总额的 4.4%。为解决这个问题，备受争议的 EIP 779 被提出来，其目的在于修改攻击者的锁定合约。如此一来，ETH 持有者便可以从 the DAO 合约上提出其 ETH。7 月 20 日，以太坊大部分成员支持实行硬分叉，然而少数社区成员持反对意见，并决定实行硬分叉，分叉后的原链改名为以太坊经典 (Ethereum Classic)。

H. Docker 搭建以太坊私有链

首先需要安装 Docker，Docker 的安装和使用可以参看阮一峰老师的 《Docker 入门教程》 。
Ethereum 官方是支持 docker 的，可以参看 官方文档 。

centOS

其中 -v /home/linshan/works/block-chain/ethereum:/root 是把我们当前的 ethereum 目录，挂到了docker 的 /root 下。
在 Windows 环境下使用 -v /home/linshan/works/block-chain/ethereum:/root 不能启动容器，原因不明，所以在 Windows 下先不要使用目录挂载。

各字段具体用途参看 官方文档 。
Windows
Windows 不必创建 start-ethereum.sh 文件， genesis.json 也可以在 Docker 容器启动后创建。

centOS

Windows

运行成功后执行

进入 docker 容器命令行
因为 Windows 没有挂载共享目录，所以 root 目录下没有 genesis.json 文件，我们要在这里手动创建 genesis.json 文件，内容要和 centOS 的一致。

data 用来存放区块数据

geth 的参数参看 以太坊客户端Geth命令用法-参数详解

启动私有节点后进入 geth 命令行执行：

输出的内容就是节点信息，我们在手动连接节点是会用到，注意要把“0.0.0.0“换成你自己的IP，然后将这个信息发送给其他节点。手动连接节点有两种方式：

当然不管使用哪种方法连接节点都要保证创世区块文件 genesis.json 一致，还有在启动时 networkid 也要一致。

至此以太坊私有链已搭建完毕。

geth命令

docker命令

I. 以太坊无法连接节点

把你的TCP/IP协议设置成自动获取状态试试,方法:右键网上邻居-属性- 右键"本地连接"属性-双击"Internet 协议 TCP/IP"-改为自动获取

IPX/SPX协议，IPX是NetWare最底层的协议，它只负责数据在网络中的移动，并不保证数据是否传输成功，也不提供纠错服务。IPX在负责数据传送时，如果接收节点在同一网段内，就直接按该节点的ID将数据传给它；如果接收节点是远程的（不在同一网段内，或位于不同的局域网中），数据将交给NetWare服务器或路由器中的网络ID，继续数据的下一步传输。SPX在整个协议中负责对所传输的数据进行无差错处理，所以我们将IPX/SPX也叫做“Novell的协议集”。

J. 以太坊源码分析--p2p节点发现

节点发现功能主要涉及 Server Table udp 这几个数据结构，它们有独自的事件响应循环，节点发现功能便是它们互相协作完成的。其中，每个以太坊客户端启动后都会在本地运行一个 Server ，并将网络拓扑中相邻的节点视为 Node ，而 Table 是 Node 的容器， udp 则是负责维持底层的连接。下面重点描述它们中重要的字段和事件循环处理的关键部分。

PrivateKey - 本节点的私钥，用于与其他节点建立时的握手协商
Protocols - 支持的所有上层协议
StaticNodes - 预设的静态 Peer ，节点启动时会首先去向它们发起连接，建立邻居关系
newTransport - 下层传输层实现，定义握手过程中的数据加密解密方式，默认的传输层实现是用 newRLPX() 创建的 rlpx ，这不是本文的重点
ntab - 典型实现是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 与其他节点建立连接时的握手信息，包含本地节点的版本号以及支持的上层协议
addpeer － 连接握手完成后，连接过程通过这个通道通知 Server

Server 的监听循环，启动底层监听socket，当收到连接请求时，Accept后调用 setupConn() 开始连接建立过程

Server的主要事件处理和功能实现循环

Node 唯一表示网络上的一个节点

IP - IP地址
UDP/TCP - 连接使用的UDP/TCP端口号
ID - 以太坊网络中唯一标识一个节点，本质上是一个椭圆曲线公钥(PublicKey)，与 Server 的 PrivateKey 对应。一个节点的IP地址不一定是固定的，但ID是唯一的。
sha - 用于节点间的距离计算

Table 主要用来管理与本节点与其他节点的连接的建立更新删除

bucket - 所有 peer 按与本节点的距离远近放在不同的桶(bucket)中，详见之后的 节点维护
refreshReq - 更新 Table 请求通道

Table 的主要事件循环，主要负责控制 refresh 和 revalidate 过程。
refresh.C - 定时(30s)启动Peer刷新过程的定时器
refreshReq - 接收其他线程投递到 Table 的 刷新Peer连接 的通知，当收到该通知时启动更新，详见之后的 更新邻居关系
revalidate.C - 定时重新检查以连接节点的有效性的定时器，详见之后的 探活检测

udp 负责节点间通信的底层消息控制，是 Table 运行的 Kademlia 协议的底层组件

conn - 底层监听端口的连接
addpending － udp 用来接收 pending 的channel。使用场景为：当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复，pending用来记录一次这种还没有到来的回复。举个例子，当我们发送ping包时，总是期待对方回复pong包。这时就可以将构造一个pending结构，其中包含期待接收的pong包的信息以及对应的callback函数，将这个pengding投递到udp的这个channel。 udp 在收到匹配的pong后，执行预设的callback。
gotreply - udp 用来接收其他节点回复的通道，配合上面的addpending，收到回复后，遍历已有的pending链表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一个 Table

udp 的处理循环，负责控制消息的向上递交和收发控制

udp 的底层接受数据包循环，负责接收其他节点的 packet

以太坊使用 Kademlia 分布式路由存储协议来进行网络拓扑维护，了解该协议建议先阅读 易懂分布式 。更权威的资料可以查看 wiki 。总的来说该协议：

源码中由 Table 结构保存所有 bucket ， bucket 结构如下

节点可以在 entries 和 replacements 互相转化，一个 entries 节点如果 Validate 失败，那么它会被原本将一个原本在 replacements 数组的节点替换。

有效性检测就是利用 ping 消息进行探活操作。 Table.loop() 启动了一个定时器（0~10s），定期随机选择一个bucket，向其 entries 中末尾的节点发送 ping 消息，如果对方回应了 pong ，则探活成功。

Table.loop() 会定期（定时器超时）或不定期（收到refreshReq）地进行更新邻居关系（发现新邻居），两者都调用 doRefresh() 方法，该方法对在网络上查找离自身和三个随机节点最近的若干个节点。

Table 的 lookup() 方法用来实现节点查找目标节点，它的实现就是 Kademlia 协议，通过节点间的接力，一步一步接近目标。

当一个节点启动后，它会首先向配置的静态节点发起连接，发起连接的过程称为 Dial ，源码中通过创建 dialTask 跟踪这个过程

dialTask表示一次向其他节点主动发起连接的任务

在 Server 启动时，会调用 newDialState() 根据预配置的 StaticNodes 初始化一批 dialTask ， 并在 Server.run() 方法中，启动这些这些任务。

Dial 过程需要知道目标节点( dest )的IP地址，如果不知道的话，就要先使用 recolve() 解析出目标的IP地址，怎么解析？就是先要用借助 Kademlia 协议在网络中查找目标节点。

当得到目标节点的IP后，下一步便是建立连接，这是通过 dialTask.dial() 建立连接

连接建立的握手过程分为两个阶段，在在 SetupConn() 中实现
第一阶段为 ECDH密钥建立 ：

第二阶段为协议握手,互相交换支持的上层协议

如果两次握手都通过，dialTask将向 Server 的 addpeer 通道发送 peer 的信息