本篇文章给大家谈谈以太坊分几个阶段，以及以太坊的四个阶段对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
写在文前：视频版本和文字版本略有不同，想要看我深情并茂演绎，请看视频版本 (喵懂区块链22期|分片（Sharding）：以太坊太慢，“盘”他！)，思维逻辑怪，请看文案加长版。
最近以太坊由于君士坦丁堡升级（Constantinople）而出现了压倒性的积极走势，而以太坊的升级之路则犹如升级打怪一般，落入了rabbit hole，谁也不知道这洞有多深。既然是“路漫漫其修远兮”，则把脚下的每一步走好走准，则成了至关重要的点。攻破这一难点之后，以太坊的下一技术难点---Sharding分片，则又被摆到了台面上。本期《喵懂区块链》会带大家走进让以太坊快起来的法宝--- Sharding分片。
什么是sharding分片？
分片技术其实并不是什么新概念，起初是针对大型中心数据库提出的优化方案，具体来说就是将大型数据库中的数据划按照某种规则分成很多数据分片（shard），再将这些数据分片分别存放在不同的服务器中，以减小每个服务器的数据访问压力，从而提高整个数据库系统的性能。
我们举一个通俗的小例子：
比如我们平时经常使用的美团，滴滴打车等软件，就可以按照“城市”来进行分片，由于不同城市的数据不需要互通，就可以将不同城市的数据存放在不同数据库中，这样既可以把数据库服务器部署到离对应城市最近的节点上，还可以提高访问速度，何乐而不为呢？！
从上面的例子中，我大家应该对分片的概念有了初步了解，那么对应到区块链场景中来说，分片又是怎么样的呢？
以以太坊分片为例，在原有的单链系统中，公链整体的性能取决于单个节点的性能，进行分片之后，每个节点只需要承当全网部分工作，各个分片并行工作，按照Vitalik的话来说，each shard is like a separate galaxy每个分片都像是独立的小宇宙，这样效率自然噌噌噌提升！原本以太坊链全网TPS约为20，现在若增加到100个分片，那么全网TPS可以提升至2000，同理，全网容量也将提升至原来的100倍。
“每个节点只需要承担全网部分工作”，这就会引出几大问题，1.怎么确定这个节点是负责哪个分片的工作？2.哪些交易应该归类到哪些分片当中去？3.每个节点是否只需要储存自己所在分片的交易信息（账本）？
根据以上问题的实现与否，我们可以将分片依次分为三种类型：网络分片，交易分片，状态分片。
网络分片：如何将全网节点划分到不同分片当中去。
交易分片：如何将全网交易划分到不同分片当中去。
状态分片：如何让各个节点只维护各自分片内的账本，但又不影响整个系统的安全性。
主链和分片链的区别和联系？
分片的类型我们已经明白了，那么主链（Main chain）和分片链（shard chain）有什么不同呢？
在主链中，我们知道记账的人叫做矿工，账本是存在区块当中，对应到分片链当中，则是Collator校对人和Collation校对块。
类似于区块的构成，Collation校对块也包含Collation header校对头和tansaction list具体的交易信息。
对比下来，主链和分片链本身来说，还是大同小异，但是一但要把他们联系起来，问题就变得复杂了，这里我们举个通俗的小例子类比一下：
假设，
以太坊主链=温州银行
每个分片=温州银行分行
比如：
shard1（分片1）=温州银行（杭州分行）
Shard2（分片2）=温州银行（宁波分行）
……
在这个系统中，我们就会清晰看到几大问题：1.各大分行的账本如何汇总到总行里去？2.各大分行的账本如何互联？
对应到主链和分片链系统当中来，则变成了1.分片链和主链如何实现跨链链接？2.分片之间怎么互联？甚至分叉的场景要怎么办?
分片链和主链如何实现跨链链接？
为了将分片链加入到主链中，在主链上需要有一个叫做验证人管理员合约（Validator Manager Contract）VMC的特殊合约。VMC具体是这样的：
所有的验证人把它们的保证金（stake）存入 VMC当中，这些验证人就会被收录在VMC的common validator pool验证人备选池中。系统将会“隔一段时间”根据stake权益的多少随机为每个分片抽取一名验证人，将各个分片的collation header校对头信息同步到主链中去。
这里的“隔一段时间”，我们需要额外解释一下：“时间”，也叫period周期，这到底是怎么确定的呢？答案是主要看开发人员在最终代码中的实现为准，比如说我们把周期定为5个区块，那么就意味着主链出5个区块，所有分片链分别出一个collation校对块，这就间接决定了分片链的出块时间。
这种随机的形式，使得验证者无法提前预测他们何时会成为验证者，也无法预测会成为哪个分片的验证人，从而预防作恶的可能性。
如果一旦发现我们的分片验证人作恶了，他的stake权益就会被剥夺。
跨分片通信（cross-shard communication）怎么办？
比如说一个转账方小A在分片M中，收款方小B在分片N中，小A可以通过主链这个桥梁，完成扣款操作，并创建一个带有ID的 receipt收据，代表着“自己已经完成了扣款操作”，收款方小B可以根据这个 receipt ID 创建一个receipt-consuming收据消费交易，“消费”成功了之后，收款也就成功了。
分片链分叉了怎么办？（fork choice rule）
在以往的分叉情况中，都是“以最长链为主链”，在分片当中，分叉规则是“以最长主链里面的最长分片链为有效分片链（the longest valid shard chain within the longest valid main chain）”。
什么意思呢？我们举个例子：
一条主链出现了分叉，一条分叉连续跟了两个区块，同时也跟了两个Collation校对块，另一条则是一个区块和一个校对块，那么很明显，第一条是有效链。
接下来，第二条链又加了一个区块，变成两个区块和一个Collation校对块，依然很明显，第一条链仍然是有效链：
接下来，第一条链上又加了一个区块，虽然这条链上只有一个Collation校对块，但是它的主链长度已经超过了第一条，那么第二条则成为了现在的有效链，这就是分片场景下的分叉规则，首先比较主链长度，再比较分片链长度！
以太坊分片的实现是一个漫长的过程，就连Vitalik自己也说将会分阶段来逐步实现，分片到底能不能从理论走向实践，我们还是小小期待一下吧。
参考资料：
创建一个引用EOS报表构件包的项目。引用该构件包后，即可在此项目上创建报表模板，以及调用报表运算逻辑。用户也可以现有项目上添加引用报表构件包。
2. 创建报表模板。
o 确定数据库的连接方式。
o 在报表模板中定制数据的汇总、统计。
o 确定最终显示样式。
3. 开发JSP，展现逻辑，业务逻辑。
实现数据的提取、显示、打印、导出等功能。
4. 调试发布。 1. 根据调用位置的不同，调用EOS报表的方式有两种：
o 在JSP页面上调用tag。
o 在业务逻辑中调用EOS报表的运算逻辑。
2. 根据数据库的连接方式分为：
o JDBC/XML数据源。
o EOS数据源。 一般情况下，报表都是一组有条件的查询结果，下面将用四个示例分别介绍针对同一需求的四种不同开发方式。
用户需求如下：
查询现有系统中的用户角色和用户信息，以报表的形式展示出某些角色所对应的用户名和用户ID。既可以查询某一角色对应的用户信息，也可以查询所有角色对应的用户信息，并可以将查询结果打印或导出到EXCEL中。
案例分析：
1. 查询要求
o 要求实现条件查询，条件为角色。
o 分组显示，按角色分组。
o 可以以html,applet,excel格式返回结果集。
2. 实现要点
o 需要创建条件查询页面，做为用户查看报表的入口，在该页面需要实现：选择角色、选择结果的显示格式。
o 需要实现分组显示，该功能在报表模板中实现。
o 需要设定显示格式，该功能在结果页面完成。
o 数据的提取可以由结果页面直接调用报表模板实现，也可以由后台调用“展现逻辑+业务逻辑”的方式实现。
3. 表结构和数据显示
以下关联的三个表均为eos的系统表。
查询SQL语句如下：
select
o.userid,o.operatorname,r.rolename
from
EOSOPERATOR o,
EOSOPERATORROLE eor,
EOSROLE r
where
o.operatorid=eor.operatorid and
eor.roleid=r.roleid and
r.rolename like '%'
order by r.rolename
4. 实现结果展示
o 查询条件页面
o 查询结果页面
随着以太坊合并（The Merge）的临近，社区对合并的相关影响以及未来以太坊的路线规划愈发频繁。本文，我们便围绕这一主旨，提炼出五大常见问题，为大家画画重点。
什么时候合并？
目前没有确定的官宣时间，只是社区普遍认为在 6~8 月，因为预计难度炸弹将于 6 月底引爆。
那有没有可能推迟？有可能。
以太坊基金会社区经历 Tim Beiko 近期曾表示，在 4 月中旬，他将与社区讨论是否有必要再次推迟难度炸弹。安全稳定合并的优先级势必是要高于快速实现合并，另外他也表示，虽然以往难度炸弹推迟都是 6 个月左右，但是只要各方面合适，推迟一两个月也是可以的。
为什么说：合并后 ETH 通胀率下降 90%，价格 TO THE MOON?
以太坊合并其实也是从 PoW 过渡为 PoS。
PoW 下的以太坊，是以区块奖励的形式进行 ETH 增发，目前年通胀率约 4.3%；
PoS 下的以太坊，将以质押奖励的形式进行 ETH 增发，不过质押奖励是根据质押总量动态调整的，这里假设质押量为 1 千万 ETH，那么年通胀率约 0.43%；（注意：通胀率随着质押量的上涨而上涨，所以具体的年通胀率是会变化的）
在这种假设下，ETH 的通胀率将下降 90%，相当于完成三次减半。
另外，在 EIP1559 的配合下，手续费销毁的 ETH 有可能超过新增发的 ETH，实现 ETH 的通缩，对价格是长期的利好。
相反观点，合并后 ETH 将迎来巨大抛盘，为什么？
持有这种观点的人，主要是认为前期质押进信标链存款合约的大量 ETH 成本极低，存在数倍的盈利，合并后提款获利砸盘的可能性很大。
的确是存在这种可能性，但是我们可以结合以下几个因素综合考虑：
激活提款这个功能目前是被纳入到上海升级中，上海升级将是合并后的第一个硬分叉，鉴于当前时间的不确定性以及行情可能的熊性（即使近期回暖），急于获利了结的投资者可以通过衍生品以及场外交易进行对冲。
类似于存款排队，提款也需要排队，大约每天最多只能有 1125 个验证器提款（合计 3.8w ETH）。
目前市场上已经有很多类似 Lido 的流动性质押方案，部分质押者其实可以随时退出。
出现大量提款时，质押收益会升高，进而吸引投资者存款。
合并后质押收益有望接近 10%？怎么算的？
是有可能的。要知道，合并后，质押收益的来源将有三种：
质押通胀奖励
手续费收入
MEV
具体数据我们参考以太坊研究员 Justin Ðrake 的推算模型，便可以推算出 9.6% 的年化收益。
不过值得注意的是，这只是合并早期我们理想的收益率，长期来看，收益率可能在 3.3%~5.4% 之间波动。
以太坊最新的未来路线规划是怎样的？
总体来说，关于 ETH2.0（其实基金会已经取消这种叫法） 的路线图其实已经改变过两次。
最开始，ETH2.0 的路线图是经典的三阶段：
Phase 0：以 PoS 为共识机制的信标链
Phase 1：数据分片，但不包括计算分片
Phase 2：为所有分片增加执行功能（计算分片）
但是 2020 年 11 月 18 日，在以太坊基金会的 ETH2.0 研究团队的第五次 AMA 活动中，V 神已经明确表示，ETH2.0 路线图已发生变化，将以 Rollup 为中心推进 ETH2.0 的实施：
暂时不再强调 Phase 2 的重要性，主推 Phase 1 实现数据分片，以实现分片 Rollup；当前以太坊的 TPS 大约为 15~45，使用 Rollup 可以提升吞吐量 100 倍，同时 64 个分片以太坊网络吞吐量即可提高 64 倍，两者叠加，即分片 Rullup 可实现 6400 倍的扩容。
信标链将具备执行功能，即 PoS 合并之后，信标链区块将直接包含交易。
而近期，在分片方案上也有了一些更新，未来以太坊更有可能采用名为 Danksharding 的分片方案，该方案能够有效优化跨域 MEV 问题，同时更有助于分片 Rollup 的实施。
不过在此之前，我们先来了解一下 V 神针对跨域 MEV 问题提出的 PBS（proposer-builder separation，区块提议者与构建者分离）解决方案。
在以前的模式中，矿工负责出块，他们从内存池中挑选交易进行排序并纳入区块，同时他们也有权利审查某些交易。
而在 PBS 的设计中，将这一职责划分为两个角色：区块提议者和区块构建者。
区块提议者负责从内存池中收入交易，并创建一个包含区块交易信息的列表 crList 传递给区块构建者们。区块构建者们以最大化 MEV 为目的对 crList 中的交易进行重新排序并构建区块，然后再向区块提议者提交他们的出价，而区块提议者就会选择出价最高者为有效的区块。
在了解了 PBS 后，我们再来了解 Danksharding 就更为轻松了。
我们以前的分片方案为平行数据分片模式，即每个分片和信标链都有独立的验证者，虽然独立的验证者更有利于去中心化，但是在当前 MEV 盛行的背景下，在利润的驱动下势必会导致区块生产者的中心化（例如同个实体下运行着大量验证节点，有利于 MEV）。Danksharding 除了采用了上文提及的 PBS 架构外，还做出了一个改变，即所有的信标区块和分片数据都会被一个由验证者组成的委员会进行统一验证。
这种设计严格来说是对分片的一种简化，分片之间没有了复杂的数据访问同步问题，具备许多有优点：
能够有效降低网络工作量（近百倍）；
L1 与 L2 的数据同步加快；
crList 能够使 L1 上实现即刻交易确认；
MEV 市场化，解决潜在的验证者中心化问题
因此，目前来说，以太坊的最新路线规划可以概况为 以 Rollup 为中心 + Danksharding 。不过 Danksharding 尚在理论阶段，整体路线未来或许还会有所变动。
节点发现功能主要涉及 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 的信息
分为64个。
分片链机制会将以太坊链拆分成64条不同的链，拆分以后，将数据处理的任务分配给许多节点，这样就可以并行处理交易，而非串行。
关于以太坊分几个阶段和以太坊的四个阶段的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
评论