文章链接
本文仅作试验研究用,不对参考本文操作产生的各种结果承担任何责任。
前言
昨天以太坊发生一个里程碑时间–以太坊的共识机制由费钱费电的PoW转型环保的PoS机制,业界简称以太坊合并(既有的PoW链与平行运行的PoS链合并成一条PoS链)。合并后的PoS机制能让ETH挖矿也更加环保,生态更加健康,但对于ETH的币价,短期有可能是一个打击。闲话少说,这次升级,所有的节点必须完成一个升级,否则就无法同步数据,失去节点功能。
合并后的以太坊链,分为执行层(以前称为ETH1.0)和共识层(以前称为ETH2.0)。每层都有多种客户端,比如执行层有最常用的Geth,Nethermind,Besu等,共识层有Nimbus,Teku,Prysum等,详细参考Run a client pair . 以太坊官网的意思是大家尽量选择多样化已保持客户端生态的平衡。因为我比较习惯用Geth,所以选用了同样为go语言开发的Prysum。
节点硬件需求
CPU:4核2.8GHz以上 内存:16GB以上 存储:SSD 1T以上。Prysm建议2T以上,但实际同步完成后Prysm的共识层数据只占了5G空间。可能因为我使用了检查节点原因。但有人认为共识层数据20G最多100G就足够了。 网络:8Mbit/s 以上
安装Prysum
我这里使用了最简洁的shell脚本安装方式。安装过程主要参考Quickstart: Run a node and (optionally) stake ETH using Prysm
mkdir prysm && cd prysm
curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh
在国内最麻烦的就是GWFW,没有梯子这个shell下载不下来。 因为试验节点上没有梯子,我就在其它环境下载下来了,大小只有9.4k,同样可以用。
chmod +x prysm.sh
生成JWT令牌
执行层与共识层需要通过JWT令牌来认证链接。生成这个256位令牌有几种方式,网站, openssl命令(openssl rand -hex 32 | tr -d “\n” > “jwt.hex”),执行层客户端,prysum。我用的prysum命令方式。
./prysm.sh beacon-chain generate-auth-secret
数分钟即可安装好prysum客户端(beacon-chain-v3.1.1-linux-amd64)并生成jwt.hex令牌。
启动执行层客户端Geth
我是用的Geth。 注意最后的这个参数–authrpc.jwtsecret必须正确指定
geth --http --http.api eth,net,engine,admin --authrpc.jwtsecret /path/to/jwt.hex
建议用nohup实现后台启动。
启动共识层客户端Prysum
通过指定JWT令牌来启动prysum,并同步共识层数据。
./prysm.sh beacon-chain --execution-endpoint=http://localhost:8551 --jwt-secret=path/to/jwt.hex
如果要做验证节点,需要加参数 --suggested-fee-recipient=0x01234567722E6b0000012BFEBf6177F1D2e9758D9
安装prysum官网的说法,这个过程需要花费数天时间,网络不好需要更长时间。 我的实操经历是,无梯子同步18小时,只完成了11%左右的数据。简直慢得不能接受。
加速共识层数据同步速度
好了,重点来了,花费数天时间难以忍受,如何加快这个共识层数据同步,让你的执行层节点可以尽快用起来? 答案是:从最近的检查点开始同步。只要保证你这个检查点的状态(BeaconState 和SignedBeaconBlock)是正确的,那就可以放心从检查点开始同步,这无疑节约了99%的同步时间哦。
1. 获取可信检查点
这里是检查点获取地址列表链接:Ethereum Beacon Chain checkpoint sync endpoints(需要梯子) 为了方便大家,贴出几个主网检查点公示地址:
2. 从检查点启动共识层客户端
nohup ./prysm.sh beacon-chain --checkpoint-sync-url=https://sync.invis.tools --genesis-beacon-api-url=https://sync.invis.tools --execution-endpoint=http://localhost:8551 --jwt-secret=/path/to/jwt.hex >> prysm.log 2>&1 &
3. 验证检查点正确性
通过slot编号和其对应的state_root 来判断检查点是否正确
curl -s http://127.0.0.1:3500/eth/v1/beacon/headers/finalized | jq .'data.header.message'
下面是输出例子:
$ curl -s http://127.0.0.1:3500/eth/v1/beacon/headers/finalized | jq .'data.header.message'
{
"slot": "4710016",
"proposer_index": "70928",
"parent_root": "0xff02266fa46664708d07e51d49705a0e4789c21afc2263f7c4e4e930617b456c",
"state_root": "0x57ca32400b5fe29a17398728d0d49e15de1b29cc14d16183952d5a9e55655a91",
"body_root": "0x0feafb803566f987f275cdb9ecc7c021a1fed09df0466854ce8399b565d4d921"
}
然后去https://beaconstate.info/或者https://beaconstate.ethstaker.cc/等网页(参考1. 获取可信检查点,注意换一个接入点)上确认同样slot对应的State root. 如果一致,表明所使用的检查点是正确的。到这里就大功告成了。
防火墙设置
为了保证节点正常、安全运行,需要正确设置防火墙。下面内容详细参考Configure ports and firewalls for improved peer-to-peer connectivity
端口/协议 | 防火墙规则 | 原因/警告 |
---|
8545/TCP | 阻止所有流量 | 这是执行层节点的API 的 JSON-RPC 端口。您(和应用程序)可以使用此端口检查执行节点状态,查询执行层链数据,甚至提交交易。这个端口一般不应该暴露给外界。 | 3500/TCP | 阻止所有流量 | 这是信标(共识)节点API 的 JSON-RPC 端口。您(和应用程序)可以使用此端口检查信标节点状态并查询共识层链数据。这个端口一般不应该暴露给外界。 | 8551/TCP | 阻止所有流量 | 您的信标节点使用此端口连接到执行节点的引擎 API。只有当您的本地信标节点连接到远程执行节点时,才应允许通过此端口的入站和出站流量。 | 4000/TCP | 阻止所有流量 | 您的验证器使用此端口通过 gRPC 连接到您的信标节点。只有当您的本地验证器连接到远程信标节点时,才应允许通过此端口的入站和出站流量。 | */UDP+TCP | 允许出站流量 | 为了发现对等点,Prysm 的信标节点通过随机端口拨出。允许来自任何端口的出站 TCP/UDP 流量将有助于 Prysm 找到对等点。 | 13000/TCP | 允许入站和出站流量 | 在我们发现对等点之后,我们通过这个端口拨叫它们为 libp2p 建立一个持续的连接,并且所有 gossip/p2p 请求和响应都将通过该连接流动。 | 12000/UDP | 允许入站和出站流量 | 你的信标节点公开这个 UDP 端口,以便其他以太坊节点可以发现你的节点,请求链数据,并提供链数据。 | 30303/TCP+UDP | 允许入站和出站流量 | 30303/TCP 是你的执行节点的监听端口,而 30303/UDP 是它的发现端口。此规则允许您的执行节点连接到其他对等节点。请注意,某些客户端默认使用 30301。 |
|