Hashgraph图示未体现节点双向Gossip？协议原理与图示疑问

《The Hashgraph Protocol: Efficient Asynchronous BFT For High-Throughput Distributed Ledgers》（Baird, Luykx, 2020）的图1与Hedera官网的Hashgraph结构示意图高度相似，这类典型图示常做简化展示，但未体现节点gossip的双向通信——比如中间节点M与左节点L通信生成事件A（包含L的事件B状态）时，M已获知右节点R的事件C，但图中没有L的事件显示其获取了C，而协议明确采用双向gossip：节点随机选择另一节点，互相发送对方未知的信息。针对相关疑问解答如下：

1. Hashgraph实际结构是否与图示一致？ #

• 实际结构的核心逻辑和图示一致，但图示做了必要的简化处理。Hashgraph的核心是由事件（Event）构成的有向无环图（DAG），每个事件包含发起节点的自签名、本节点的上一个父事件，以及从gossip中获取的其他节点事件的引用。图示仅聚焦展示某一次gossip触发的事件生成过程，而非完整的全局DAG状态。
• 实际运行中，每个诚实节点的本地Hashgraph会通过gossip不断同步，最终收敛到一致的全局视图（依赖虚拟投票和共识算法）。但图示为了让读者快速理解单个事件的生成逻辑，省略了同步后的后续事件。

2. 协议中双向Gossip为何未在图示体现？ #

• 可视化简化需求：图示的核心目的是解释M生成事件A的逻辑——即M与L gossip时，将已知的R的事件C和L的事件B纳入自己的新事件A。如果同时画出L获取C后生成的新事件，会让图变得杂乱，反而干扰读者理解核心流程。
• 时序差异：图示展示的通常是M生成事件A的时间点状态，此时L可能刚收到C，还未生成包含C的新事件（事件生成由节点自主触发，不一定在gossip完成后立即执行）。后续L会基于新获取的C生成下一个事件，但这部分不在当前图示的展示范围内。

3. 正确的双向Gossip图示应是怎样的？ #

• 补充节点的后续事件：在L的事件链上添加新事件D，D的父事件为B，同时引用M的事件A（或直接引用R的事件C），以此体现L通过双向gossip获取了C的状态。
• 同步更新其他节点的事件链：如果R也通过此次gossip获取了L的B，则R的下一个事件E应引用B或A，完整展示三方节点在双向gossip后的事件更新。
• 标注双向通信过程：在M和L之间绘制双向虚线箭头，分别标注“M发送C给L”和“L发送B给M”，明确双向数据传输逻辑，再对应到各自后续事件的引用关系。

内容的提问来源于stack exchange，提问作者davidbak