eth2.0时间表 ETH2.0意味着什么

一、eth2.0上线时间

预计在 12月1日，16384名验证者合计投入 524，288枚 ETH时，ETH 2.0就将启动。

拓展资料

1.当验证者将价值约 2亿美元的 ETH质押到 ETH 2.0的智能合约中时，「第 0阶段」就会启动，让区块链开始运作。但这只是漫长过程中的第一步，只有在若干年后，ETH 2.0才能像今天的 ETH 1.0主网一样发挥作用。但如果一切顺利，这一切的等待都是值得的。ETH 1.0目前每秒处理 14笔交易，这是那些试图从区块链中获利的公司常常抱怨的地方，与 ETH 2.0相比，ETH 1.0的速度慢得多。而在未来，可 ETH 2.0的交易速度将能达到每秒 10万次。

2.以太坊 2.0将区块链转移到 PoS共识机制，即交易由持有大量以太币的人验证。这与现有的 PoW共识机制不同，后者奖励最强大的矿机。 12月左右上线后，第 0阶段 ETH 2.0区块链所能做的就是验证区块。「人们所认为的以太坊的核心功能都不是零阶段的一部分，」Staked的 CEO Tim Ogilvie说，Staked是一家代表质押者处理服务器和基础设施的公司。「人们不能发送或接收 ETH，不能参与 DeFi或其他智能合约活动。」「第 0阶段所做的就是建立起保护网络安全的共识机制，并且有足够的资金来保护 ETH的全部资产。

3.稍后，第 1阶段将允许用户在智能合约中发送或接收 ETH，并引入分片技术，这是一种加快区块链速度的技术。第二阶段将重新引入我们使用 ETH1的完整智能合约功能，」基于 ETH的认购公司 Groundhog的首席执行官 Scott Burke说。 Ogilvie说，第一阶段最积极的估计是第二阶段的六个月和两年：「比较保守的估计要长得多。所以，从 ETH 1.0到 ETH 2.0的完全转变还需要几年的时间。」

4.「目前来看，能出问题的地方并不多。已经有很多社区的测试网，包括两个专门为测试信标链的起源而创建的测试网，还支付给了发现客户端问题的个人巨额奖金。」Quantstamp CEO Richard Ma说。Quantstamp已经审核了多个 ETH 2.0客户端。

二、如何参与ETH2.0项目

以太坊 2.0上线之后，普通人主要的玩法，还是通过抵押代币，分享网络的收益。不过想要说清楚，得先简单了解下以太坊 2.0网络的变化。

以太坊

从 PoW到 PoS：以太坊代币机制的变化，以太坊 2.0使用 PoS机制取代 1.0阶段的 PoW算法。无论是以太坊 1.0，还是即将开启的以太坊 2.0，验证人都需要运行节点，并且要保持良好的机器性能。非硬核玩家的普通持币者，参与以太坊 2.0 Staking最好的方式一定不是自己运行节点，不然会遇到一系列困难。参与以太坊质押，收益率丰厚，这会吸引大量的持币人参与。

在全网达到 52万枚 ETH质押量的时候，质押的年化收益率大约为 21.6%左右。即便全网质押量达到 1000万枚 ETH，年化收益也仍然在 5%左右。不同于 DeFi项目的高额收益，这部分以太坊质押收益，可是来自以太坊网络自身，对持币人来说，可以称得上是利润可观了。

自己运行节点挖矿，不仅费时耗力，对技术跟资金量都有要求，因此选择第三方服务商来进行 Staking，会成为更常见的选择。可以粗略将其分为三类：

中心化交易所和矿池。存入门槛低，不用自己运行节点，收益的一部分会成为服务方的手续费。

去中心化钱包和服务商。通过智能合约的方式，实现存币挖矿。至于节点运行，交给服务商来搞定。

平台方。无论是上述哪种方式，最终都需要有人来运行节点，因此有的项目则下潜了一层，充当各类抵押服务提供商的底层基础设施，负责运行节点，获得手续费收益。

链乔教育在线旗下学硕创新区块链技术工作站是中国教育部学校规划建设发展中心开展的“智慧学习工场2020-学硕创新工作站”唯一获准的“区块链技术专业”试点工作站。专业站立足为学生提供多样化成长路径，推进专业学位研究生产学研结合培养模式改革，构建应用型、复合型人才培养体系。

三、我能自己来运行 Eth 2.0 的验证者吗

可以！

你在运行自己的验证者节点时，首先要意识到的是，你这样做是有助于网络安全性的，而且你无需过度担心正常运行时间。

假设网络总体上是健康的（始终有超过 2/3的节点在线，并且一直在终局化新的区块），在线时间超过 50%的验证者将看到自己的权益会不断增加。

引用以太坊基金会的 ETH Staking指南系列文章中的一句话：

这就减轻了验证者在客户端备份和网络延迟上的负担，因为离线的惩罚并不那么严重。

你遭受较大惩罚的概率很小ETH 2.0协议内设反串谋激励机制，也就是说，会对出错时机上相关的验证者施以惩罚。

惩罚措施包括：比例性罚没（proportional slashing）——被销毁的 ETH比例取决于最近遭受罚没的验证者数量；怠工惩罚（inactivity leak）——如果有超过 1/3的验证者离线且区块链不能终局化区块，离线的验证者就会遭到严惩。

比例性罚没意味着，如果有质押服务提供商因出现 bug或被攻击而导致其控制下的验证者全体失败，他们会比独立运行验证者节点的个体损失更多 ETH。

此外，如果巨鲸和提供商的基础设施全部瘫痪，它们同样会面临遭受怠工惩罚并失去大量 ETH。

即使提供商谨慎地确保了地理位置和客户端软件去中心化，要想避开一切攻击（社会工程、外部攻击者入侵或内部人员作恶）也是难比登天。

你可保有退出的权利身为ETH 2.0验证者，你必须保管好两样东西——签名私钥和取款私钥。

虽然拿回资金必须包邮取款私钥，但你也需要签名私钥来初始化反激活验证者操作（等ETH 2.0进入 Phase 1后，这一规则将发生改变）。

如果你选择使用质押服务提供商，你必须将签名私钥的控制权交给该提供商（如果一个签名私钥存在多个副本，提供商就很难为你提供免遭罚没的服务）。

也就是说，如果提供商离线，或者你不满意其服务，你能否退出还取决于提供商。

虽然在提交质押品之前，你可以通过交换密钥（key exchange）的方式，让你的提供商为你提供一个签过名的退出通道，但这种方案并非万无一失。一旦出现硬分叉，这个消息就会失效。这就需要不断追踪这个消息乃至多个消息的有效性（从用户体验的角度来说，这样并不好）。

质押硬件成本较低且方便易用自己运行验证者节点并不像你想象中那么可怕或昂贵。一旦ETH 2.0上线，你就可以在一个旧手机或树莓派（100美元）上运行验证者节点。

我们专门为开发者撰写了关于如何使用 Nimbus在安卓系统上运行验证者节点的指南（分别是这篇和这篇）。在主网上线前，我们一直在尽可能简化这一流程。尤其值得一提的是，主网指南将面向那些没有编程经历的用户，而且会尽可能实现“安装+质押 ETH=正常运行”。

你可以帮助以太坊增强抗攻击性与其让同一个实体控制 100个节点，不如让一个实体控制一个节点。——Barnabe Monnot

从长远角度来看，以太坊的价值越高，抗攻击性越强，其共识层的去中心化程度就越高。

中本聪最初的愿景是“一 CPU一票制”，但是如今的 PoW系统已经偏离了这一愿景。就目前而言，绝大部分挖矿资源都集中在少数矿池手中。个体矿工都为了缩小自己收入的波动性而加入矿池。

我们之所以选择从 PoW模式转向 PoS模式，也是为了解决这一问题。

如果有越来越多人选择自己运行验证者节点，我们就可以将这一愿景变为现实，增强以太坊的抗攻击性，使之在无需审查的情况下不断发展。

四、请教hadoop2.0的ha如何配置

1 Hadoop HA架构详解

1.1 HDFS HA背景

HDFS集群中NameNode存在单点故障（SPOF）。对于只有一个NameNode的集群，如果NameNode机器出现意外情况，将导致整个集群无法使用，直到NameNode重新启动。

影响HDFS集群不可用主要包括以下两种情况：一是NameNode机器宕机，将导致集群不可用，重启NameNode之后才可使用；二是计划内的NameNode节点软件或硬件升级，导致集群在短时间内不可用。

为了解决上述问题，Hadoop给出了HDFS的高可用HA方案：HDFS通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

1.2 HDFS HA架构

一个典型的HA集群，NameNode会被配置在两台独立的机器上，在任何时间上，一个NameNode处于活动状态，而另一个NameNode处于备份状态，活动状态的NameNode会响应集群中所有的客户端，备份状态的NameNode只是作为一个副本，保证在必要的时候提供一个快速的转移。

为了让Standby Node与Active Node保持同步，这两个Node都与一组称为JNS的互相独立的进程保持通信(Journal Nodes)。当Active Node上更新了namespace，它将记录修改日志发送给JNS的多数派。Standby noes将会从JNS中读取这些edits，并持续关注它们对日志的变更。Standby Node将日志变更应用在自己的namespace中，当failover发生时，Standby将会在提升自己为Active之前，确保能够从JNS中读取所有的edits，即在failover发生之前Standy持有的namespace应该与Active保持完全同步。

为了支持快速failover，Standby node持有集群中blocks的最新位置是非常必要的。为了达到这一目的，DataNodes上需要同时配置这两个Namenode的地址，同时和它们都建立心跳链接，并把block位置发送给它们。

任何时刻，只有一个Active NameNode是非常重要的，否则将会导致集群操作的混乱，那么两个NameNode将会分别有两种不同的数据状态，可能会导致数据丢失，或者状态异常，这种情况通常称为“split-brain”（脑裂，三节点通讯阻断，即集群中不同的Datanodes却看到了两个Active NameNodes）。对于JNS而言，任何时候只允许一个NameNode作为writer；在failover期间，原来的Standby Node将会接管Active的所有职能，并负责向JNS写入日志记录，这就阻止了其他NameNode基于处于Active状态的问题。

基于QJM的HDFS HA方案如上图所示，其处理流程为：集群启动后一个NameNode处于Active状态，并提供服务，处理客户端和DataNode的请求，并把editlog写到本地和share editlog（这里是QJM）中。另外一个NameNode处于Standby状态，它启动的时候加载fsimage，然后周期性的从share editlog中获取editlog，保持与Active节点的状态同步。为了实现Standby在Active挂掉后迅速提供服务，需要DataNode同时向两个NameNode汇报，使得Stadnby保存block to DataNode信息，因为NameNode启动中最费时的工作是处理所有DataNode的blockreport。为了实现热备，增加FailoverController和Zookeeper，FailoverController与Zookeeper通信，通过Zookeeper选举机制，FailoverController通过RPC让NameNode转换为Active或Standby。

1.3 HDFS HA配置要素

NameNode机器：两台配置对等的物理机器，它们分别运行Active和Standby Node。

JouralNode机器：运行JouralNodes的机器。JouralNode守护进程相当的轻量级，可以和Hadoop的其他进程部署在一起，比如NameNode、DataNode、ResourceManager等，至少需要3个且为奇数，如果你运行了N个JNS，那么它可以允许(N-1)/2个JNS进程失效并且不影响工作。

在HA集群中，Standby NameNode还会对namespace进行checkpoint操作（继承Backup Namenode的特性），因此不需要在HA集群中运行SecondaryNameNode、CheckpointNode或者BackupNode。

1.4 HDFS HA配置参数

需要在hdfs.xml中配置如下参数：

dfs.nameservices：HDFS NN的逻辑名称，例如myhdfs。

dfs.ha.namenodes.myhdfs：给定服务逻辑名称myhdfs的节点列表，如nn1、nn2。

dfs.namenode.rpc-address.myhdfs.nn1：myhdfs中nn1对外服务的RPC地址。

dfs.namenode.http-address.myhdfs.nn1：myhdfs中nn1对外服务http地址。

dfs.namenode.shared.edits.dir：JournalNode的服务地址。

dfs.journalnode.edits.dir：JournalNode在本地磁盘存放数据的位置。

dfs.ha.automatic-failover.enabled：是否开启NameNode失败自动切换。

dfs.ha.fencing.methods：配置隔离机制，通常为sshfence。

1.5 HDFS自动故障转移

HDFS的自动故障转移主要由Zookeeper和ZKFC两个组件组成。

Zookeeper集群作用主要有：一是故障监控。每个NameNode将会和Zookeeper建立一个持久session，如果NameNode失效，那么此session将会过期失效，此后Zookeeper将会通知另一个Namenode，然后触发Failover；二是NameNode选举。ZooKeeper提供了简单的机制来实现Acitve Node选举，如果当前Active失效，Standby将会获取一个特定的排他锁，那么获取锁的Node接下来将会成为Active。

ZKFC是一个Zookeeper的客户端，它主要用来监测和管理NameNodes的状态，每个NameNode机器上都会运行一个ZKFC程序，它的职责主要有：一是健康监控。ZKFC间歇性的ping NameNode，得到NameNode返回状态，如果NameNode失效或者不健康，那么ZKFS将会标记其为不健康；二是Zookeeper会话管理。当本地NaneNode运行良好时，ZKFC将会持有一个Zookeeper session，如果本地NameNode为Active，它同时也持有一个“排他锁”znode，如果session过期，那么次lock所对应的znode也将被删除；三是选举。当集群中其中一个NameNode宕机，Zookeeper会自动将另一个激活。

1.6 YARN HA架构

YARN的HA架构和HDFSHA类似，需要启动两个ResourceManager，这两个ResourceManager会向ZooKeeper集群注册，通过ZooKeeper管理它们的状态（Active或Standby）并进行自动故障转移。

2高可用集群规划

2.1集群规划

根据Hadoop的HA架构分析，规划整个集群由5台主机组成，具体情况如下表所示：

主机名

IP地址

安装的软件

JPS

hadoop-master1

172.16.20.81

Jdk/hadoop

Namenode/zkfc/resourcemanager/

JobHistoryServer

hadoop-master2

172.16.20.82

Jdk/hadoop

Namenode/zkfc/resourcemanager/

WebProxyServer

hadoop-slave1

172.16.20.83

Jkd/hadoop/zookeepe

Datanode/journalnode/nodemanager/

quorumPeerMain

hadoop-slave2

172.16.20.84

Jkd/hadoop/zookeeper

Datanode/journalnode/nodemanager/

quorumPeerMain

hadoop-slave3

172.16.20.85

Jkd/hadoop/zookeeper

Datanode/journalnode/nodemanager/

quorumPeerMain

需要说明以下几点：

HDFS HA通常由两个NameNode组成，一个处于Active状态，另一个处于Standby状态。Active NameNode对外提供服务，而Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

Hadoop 2.0官方提供了两种HDFS HA的解决方案，一种是NFS，另一种是QJM。这里我们使用简单的QJM。在该方案中，主备NameNode之间通过一组JournalNode同步元数据信息，一条数据只要成功写入多数JournalNode即认为写入成功。通常配置奇数个JournalNode，这里还配置了一个Zookeeper集群，用于ZKFC故障转移，当Active NameNode挂掉了，会自动切换Standby NameNode为Active状态。

YARN的ResourceManager也存在单点故障问题，这个问题在hadoop-2.4.1得到了解决：有两个ResourceManager，一个是Active，一个是Standby，状态由zookeeper进行协调。

YARN框架下的MapReduce可以开启JobHistoryServer来记录历史任务信息，否则只能查看当前正在执行的任务信息。

Zookeeper的作用是负责HDFS中NameNode主备节点的选举，和YARN框架下ResourceManaer主备节点的选举。

2.2软件版本

操作系统：CentOS Linux release 7.0.1406

JDK：Java(TM)SE Runtime Environment(build 1.7.0_79-b15)

Hadoop：Hadoop 2.6.0-cdh5.7.1

ZooKeeper：zookeeper-3.4.5-cdh5.7.1

3 Linux环境准备

集群各节点进行如下修改配置：

3.1创建用户并添加权限

//切换root用户

$ su root

//创建hadoop用户组

# groupadd hadoop

//在hadoop用户组中创建hadoop用户

# useradd-g hadoop hadoop

//修改用户hadoop密码

# passwd hadoop

//修改sudoers配置文件给hadoop用户添加sudo权限

# vim/etc/sudoers

hadoop ALL=(ALL) ALL

//测试是否添加权限成功

# exit

$ sudo ls/root

3.2修改IP地址和主机名

//切换root用户

$ su root

//修改本机IP地址

# vim/etc/sysconfig/network-scripts/ifcfg-eth0

//重启网络服务

# service network restart

//修改主机名

# hostnamectl set-hostname主机名

//查看主机名

# hostnamectl status

3.3设置IP地址与主机名映射

//切换root用户

$ su root

//编辑hosts文件

# vim/etc/hosts

172.16.20.81 hadoop-master1

172.16.20.82 hadoop-master2

172.16.20.83 hadoop-slave1

172.16.20.84 hadoop-slave2

172.16.20.85 hadoop-slave3

3.4关闭防火墙和Selinux

//切换root用户

$ su root

//停止firewall防火墙

# systemctl stop firewalld.service

//禁止firewall开机启动

# systemctl disable firewalld.service

//开机关闭Selinux

# vim/etc/selinux/config

SELINUX=disabled

//重启机器后root用户查看Selinux状态

# getenforce

3.5配置SSH免密码登录

//在hadoop-master1节点生成SSH密钥对

$ ssh-keygen-t rsa

//将公钥复制到集群所有节点机器上

$ ssh-copy-id hadoop-master1

$ ssh-copy-id hadoop-master2

$ ssh-copy-id hadoop-slave1

$ ssh-copy-id hadoop-slave2

$ ssh-copy-id hadoop-slave3

//通过ssh登录各节点测试是否免密码登录成功

$ ssh hadoop-master2

备注：在其余节点上执行同样的操作，确保集群中任意节点都可以ssh免密码登录到其它各节点。

3.6安装JDK

//卸载系统自带的openjdk

$ suroot

# rpm-qa| grep java

# rpm-e--nodeps java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64

# rpm-e--nodeps java-1.7.0-openjdk-headless-1.7.0.75-2.5.4.2.el7_0.x86_64

# rpm-e--nodeps tzdata-java-2015a-1.el7_0.noarch

# exit

//解压jdk安装包

$ tar-xvf jdk-7u79-linux-x64.tar.gz

//删除安装包

$ rmjdk-7u79-linux-x64.tar.gz

//修改用户环境变量

$ cd~

$ vim.bash_profile

exportJAVA_HOME=/home/hadoop/app/jdk1.7.0_79

exportPATH=$PATH:$JAVA_HOME/bin

//使修改的环境变量生效

$ source.bash_profile

//测试jdk是否安装成功

$ java-version

4集群时间同步

如果集群节点时间不同步，可能会出现节点宕机或引发其它异常问题，所以在生产环境中一般通过配置NTP服务器实现集群时间同步。本集群在hadoop-master1节点设置ntp服务器，具体方法如下：

//切换root用户

$ su root

//查看是否安装ntp

# rpm-qa| grep ntp

//安装ntp

# yum install-y ntp

//配置时间服务器

# vim/etc/ntp.conf

#禁止所有机器连接ntp服务器

restrict default ignore

#允许局域网内的所有机器连接ntp服务器

restrict 172.16.20.0 mask 255.255.255.0 nomodify notrap

#使用本机作为时间服务器

server 127.127.1.0

//启动ntp服务器

# service ntpd start

//设置ntp服务器开机自动启动

# chkconfig ntpd on

集群其它节点通过执行crontab定时任务，每天在指定时间向ntp服务器进行时间同步，方法如下：

//切换root用户

$ su root

//执行定时任务，每天00:00向服务器同步时间，并写入日志

# crontab-e

0 0***/usr/sbin/ntpdate hadoop-master1>>/home/hadoop/ntpd.log

//查看任务

# crontab-l

5 Zookeeper集群安装

Zookeeper是一个开源分布式协调服务，其独特的Leader-Follower集群结构，很好的解决了分布式单点问题。目前主要用于诸如：统一命名服务、配置管理、锁服务、集群管理等场景。大数据应用中主要使用Zookeeper的集群管理功能。

本集群使用zookeeper-3.4.5-cdh5.7.1版本。首先在hadoop-slave1节点安装Zookeeper，方法如下：

//新建目录

$ mkdir app/cdh

//解压zookeeper安装包

$ tar-xvf zookeeper-3.4.5-cdh5.7.1.tar.gz-C app/cdh/

//删除安装包

$ rm-rf zookeeper-3.4.5-cdh5.7.1.tar.gz

//配置用户环境变量

$ vim.bash_profile

export ZOOKEEPER_HOME=/home/hadoop/app/cdh/zookeeper-3.4.5-cdh5.7.1

export PATH=$PATH:$ZOOKEEPER_HOME/bin

//使修改的环境变量生效

$ source.bash_profile

//修改zookeeper的配置文件

$ cd app/cdh/zookeeper-3.4.5-cdh5.7.1/conf/

$ cp zoo_sample.cfg zoo.cfg

$ vim zoo.cfg

#客户端心跳时间(毫秒)

tickTime=2000

#允许心跳间隔的最大时间

initLimit=10

#同步时限

syncLimit=5

#数据存储目录

dataDir=/home/hadoop/app/cdh/zookeeper-3.4.5-cdh5.7.1/data

#数据日志存储目录

dataLogDir=/home/hadoop/app/cdh/zookeeper-3.4.5-cdh5.7.1/data/log

#端口号

clientPort=2181

#集群节点和服务端口配置

server.1=hadoop-slave1:2888:3888

server.2=hadoop-slave2:2888:3888

server.3=hadoop-slave3:2888:3888

#以下为优化配置

#服务器最大连接数，默认为10，改为0表示无限制

maxClientCnxns=0

#快照数

autopurge.snapRetainCount=3

#快照清理时间，默认为0

autopurge.purgeInterval=1

//创建zookeeper的数据存储目录和日志存储目录

$ cd..

$ mkdir-p data/log

//在data目录中创建一个文件myid，输入内容为1

$ echo"1">> data/myid

//修改zookeeper的日志输出路径(注意CDH版与原生版配置文件不同)

$ vim libexec/zkEnv.sh

if ["x${ZOO_LOG_DIR}"="x" ]

then

ZOO_LOG_DIR="$ZOOKEEPER_HOME/logs"

fi

if ["x${ZOO_LOG4J_PROP}"="x" ]

then

ZOO_LOG4J_PROP="INFO,ROLLINGFILE"

fi

//修改zookeeper的日志配置文件

$ vim conf/log4j.properties

zookeeper.root.logger=INFO,ROLLINGFILE

//创建日志目录

$ mkdir logs

将hadoop-slave1节点上的Zookeeper目录同步到hadoop-slave2和hadoop-slave3节点，并修改Zookeeper的数据文件。此外，不要忘记设置用户环境变量。

//在hadoop-slave1中将zookeeper目录复制到其它节点

$ cd~

$ scp-r app/cdh/zookeeper-3.4.5-cdh5.7.1hadoop-slave2:/home/hadoop/app/cdh

$ scp-r app/cdh/zookeeper-3.4.5-cdh5.7.1 hadoop-slave3:/home/hadoop/app/cdh

//在hadoop-slave2中修改data目录中的myid文件

$ echo"2">app/cdh/zookeeper-3.4.5-cdh5.7.1/data/myid

//在hadoop-slave3中修改data目录中的myid文件

$ echo"3">app/cdh/zookeeper-3.4.5-cdh5.7.1/data/myid

最后，在安装了Zookeeper的各节点上启动Zookeeper，并查看节点状态，方法如下：

//启动

$ zkServer.sh start

//查看状态

$ zkServer.sh status

//关闭