STACKING

Ethereum 主网合并 在今年的八月份，ETH goerli测试网进行了2.0的合并，我也参与了测试网的合并，整个合并过程是成功的，我采用lighthouse做为ETH Consensus layer，geth做为Execution layer，目前测试网运行的validator节点状态是good。在接下来的九月份，ETH主网将进行2.0的合并，我也单独运行了Consensue Layer和Execution Layer，希望这次重大的合并能够顺利完成。 goerli testnet validator 状态 合并过程 ETH 2.0 Beacon Chain 将首先进行一次Bellatrix升级，从而激活两条链的合并，时间大概会在UTC 2022-09-06，之后当PoW链达到一定工作量难度时，会启动合并程序，PoW的链上数据将合并到PoS Beacon Chain上，PoW到达终止难度的日期大概在2022-09-10 - 2022-09-20。文章最开始的第一张图，可以很直观的看出当开始合并之后，PoW将被废弃，整个网络都将由validator来维护。 Bellatrix升级将在beacon chain epoch 144896开启，Paris升级将在Terminal Total Difficulty (TTD) 58750000000000000000000 开启，当难度到达TTD时，之后的块都将由beacon chain validator生成，生成第一个Post TTD 块大概需要13分钟，当beacon chain能敲定validator生成的新块时，意味着合并成功了。 问题 node ops 节点运维 节点维护者需要运行consensus layer(CL)和execution layer(EL)，并且EL需要开启Engine API，然后CL通过JWT认证接入EL。 Staker Validator 质押者 在post merge阶段，validator 需要独立运行EL，并且配置fee recipient地址来获得收益。 contracts 合约#### post merge对合约的影响非常小，几乎所有的接口都是保持稳定的状态。 ETH holder 持有者 合并之后，ETH持有者不需要做任何处理。 Miner 矿工 合并之后，PoW已经被移除，Miner无法再将算力贡献到PoS中。

回顾 ETH2.0 Phase0 BeaconChain Blog 2020年的12月份，ETH上线了2.0-0阶段的信标链，ETH2.0 Proof of Stacking(pos)的底层应用，它不像现在在运行的ETH1.0主链，Beacon Chain上面没有智能合约也没有账户管理，它的主要功能就是2.0的共识机制，用户通过质押ETH(我们称之为validator)来保护整个2.0主网的安全性，更多的人运行validator节点，能够更好的去中心化以及抵御外部攻击。0阶段，用户是只能质押ETH代币，无法运行合约以及转账操作。 合并 在2022年的三月份ETH开发者上线了kiln ETH2.0合并测试网，当前的1.0主网将合并到2.0的Beacon Chain，这样做是为了结束1.0上面的pow共识机制，并全面的过渡到pos，用ethereum.org官方的表述意思就是像宇宙飞船的对接，1.0已经无法再进行较远距离的星际航行，于是开发者们设计2.0的新引擎，1.0将与2.0飞船进行对接合并，然后驶向宇宙的更深处。当合并完成之后，ETH1.0主网将与Beacon Chain进行合并，成为ETH分片链，并且将转向Pos权益证明而非Pow工作量证明。主网将智能合约带入到Proof-of-stack系统中，并且导入ETH1.0中的所有历史数据和现状，确保ETH的持有者和用户能够平滑的过度到2.0。当合并发生时，validator节点将接管主网，miner将不再需要。 操作指引 我选择的是lighthouse beacon chain做为自己的验证节点，以下是具体在kubernetes中进行操作的yaml文件，还可以参考相关网站用于部署节点。 帮助文档 ETH Kiln TestNet kiln testnet on arm How to run a node on Kiln Join the kiln testnet - lighthouse 我的节点 kubernetes kiln testnet node and validator geth-kiln-net.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: geth-merge-devnets namespace: eth labels: app: geth-merge-devnets spec: strategy: type: Recreate selector: matchLabels: app: geth-merge-devnets template: metadata: labels: app: geth-merge-devnets spec: nodeSelector: kubernetes.io/hostname: deep-dream initContainers: - name: geth-init image: 192.168.1.114:5000/geth-merge-devnets:4c57d09-20220316 args: - geth - --datadir=/execution_data - init - /custom_config_data/genesis.json volumeMounts: - name: geth-merge-devnets-data mountPath: /execution_data - name: merge-devnets-genesis-json mountPath: /custom_config_data containers: - name: geth-merge-devnets resources: limits: memory: 5Gi cpu: 4 requests: memory: 2Gi cpu: 1 image: 192.168.1.114:5000/geth-merge-devnets:4c57d09-20220316 args: - geth - --datadir=/execution_data - --syncmode=full - --http - --metrics - --http.api - "engine,eth,web3,net,debug" - --authrpc.jwtsecret=/execution_data/jwtsecret - --metrics.expensive - --networkid=1337802 - --http.corsdomain - "*" - --authrpc.addr - "0.0.0.0" - --authrpc.vhosts=* - --http.addr - "0.0.0.0" - --http.vhosts=* - --bootnodes - "enode://c354db99124f0faf677ff0e75c3cbbd568b2febc186af664e0c51ac435609badedc67a18a63adb64dacc1780a28dcefebfc29b83fd1a3f4aa3c0eb161364cf94@164.92.130.5:30303" ports: - containerPort: 8545 name: port - containerPort: 8551 name: secure volumeMounts: - name: geth-merge-devnets-data mountPath: /execution_data volumes: - name: geth-merge-devnets-data persistentVolumeClaim: claimName: geth-merge-devnets-data - name: merge-devnets-genesis-json configMap: name: kiln-genesis-json --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: geth-merge-devnets-data namespace: eth spec: accessModes: - ReadWriteOnce storageClassName: openebs-hostpath resources: requests: storage: 500Gi --- apiVersion: v1 kind: Service metadata: labels: app: geth-merge-devnets-service project: geth-merge-devnets-service name: geth-merge-devnets-service namespace: eth spec: ports: - protocol: TCP port: 8545 targetPort: 8545 name: port - protocol: TCP port: 8551 targetPort: 8551 name: secure selector: app: geth-merge-devnets lighthouse-beacon-chain-kiln-net.yaml ...

概要 这篇文章不会过多讲述ETH的具体技术细节，主要会涉及如何成为ETH2.0的验证者。 今年年底，ETH将完成阶段0的升级，从PoW工作量证明迁移到PoS权益证明，之前自己在公司的黑马活动上思考了如何利用过剩的算力来做有价值的事情，PoW从理论上来说比较浪费能源，矿工购买大量矿机进行运算，而采用PoS机制之后，只要成为一名验证着，我们就能完成对区块的铸造，而不需要像PoW一样，购买大量矿机通过挖矿来产生新区块，但是要成为验证者中的一员，你需要将一定数量的加密货币进行锁仓做为权益的证明，如果你运行的验证节点验证一个区块，并检查里面的交易是否都是有效，如果通过，你将收到一笔奖励以做为回报。 ETH2.0 架构 架构图引用自prylabs Beacon Node 中文称之为信标链，是ETH2.0的核心部件，类似于海洋上的灯塔，引导船只前进的方向。 Validator Client 会连接信标链，并且管理质押的ETH密钥对。 如何加入 ETH 2.0 目前运行在 Medalla(已经更新为prater)测试网 访问Become a validator and help secure eth2 开始进入Get Started环节 Generate Key Pairs 这一步是用来生成验证者的密钥对 选择你使用的操作系统，然后安装eth2.0-deposit-cli 生成密钥对比如: python3 ./eth2deposit/deposit.py –num_validators 2 –chain medalla –folder ./keys/ 生成的keystore会保存在./keys文件夹下，因为目前是测试网所以需要指定 –chain medalla，像deposit_data-1600238876.json这样的文件里面存放了公共信息，下一步我们就需要上传该文件deposit_data-1600238876.json Upload Deposit File: 上传deposit_data-1600238876.json文件 Connect Wallet: 连接到你自己的本地钱包，这里我们使用Chrome MetaMask插件 如果你的钱包里面没有测试ETH，那么可以去这里申请，在自己的推特上发一条包含自己ETH地址的推文，比如0x0bDebe6eF5D0Ca744451946a70fEbd1B505dD92a my TestNet addr，然后将推文链接复制到上述网站的提交项中，最后选择87.5ETH/9days，你就会收到87.5个测试ETH，记住metamask上一定要选择goerli测试链。 下一步就是将32ETH打到对应的Medalla Beacon Contract合约地址上，如果你像我一样启动了两个验证者，那么总和就是64ETH，完成之后，我们就可以看到类似以下的页面。 0x0bDebe6eF5D0Ca744451946a70fEbd1B505dD92a 最后就是选择支持ETH2.0的多客户端，这里我们选择golang版本的prysm 完成对信标链beacon chain和验证者validator的部署 部署文档可以参考这里 获取prysm.sh: curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh –output prysm.sh && chmod +x prysm.sh ...