dht pubsub区块轻广播方案
bysomeone opened this issue · comments
上下文
-
类似广播, pubsub系统同样是写放大的, 设D为广播网络出度, 则需要同时发送D份数据到邻接节点, 同时发送时使用的是上传带宽, 通常和下载带宽有几倍的差距, 基于上述考虑, pubsub更适合用为信号发布系统, 而不是数据传输系统
-
区块在广播中占用了50%左右带宽, 且高并发下区块较大, 可能导致网络阻塞, 区块广播优化优先处理
-
区块轻广播, 之前在gossip上的广播优化方案, 区块主要数据是交易, 而交易本身也会广播, 轻广播即区块超过一定大小, 如100k时, 区块内交易采用哈希标识, 由接收节点根据交易组装还原
初步方案
pubsub结合轻广播方案
引入新的topic, 作为轻区块数据发布, 触发条件可以和之前保持一致, 设置一个大小阈值
轻广播方案流程优化
gossip轻广播方案, 涉及多次来回交互, 流程上较为复杂, 不适用于pubsub系统, 主要从以下几个方面进行调整
-
对于轻区块, 区块内的交易需要从mempool中获取, 并重新组装成完整区块
-
由于广播网络存在先后, 组装区块需要一定的等待时间, 等待区块内的交易广播, 组装区块需要异步队列处理
-
引入组装区块超时机制, 超过时长t, 则直接向指定节点获取完整区块, 这个超时机制需要兼并考虑blockchain模块区块落后触发下载的超时, 避免重复请求同样的区块数据
-
理论上交易广播应该不丢失, 或丢失率保持很低, 轻区块应该总是能组装成功, 也符合轻区块方案效果
-
不考虑部分组装成功交互获取缺失数据实现, 会涉及较多中间状态数据保存, 增加了流程和复杂度
相关问题
目前本地小规模测试未发现交易广播丢失, 需要在实际网络进一步测试和验证, 决定了触发获取完整区块的概率, 将影响轻广播方案的效果
@libangzhu @yann-sjtu 你们两个有问题可以在这里讨论
The release is available on GitHub release
Your semantic-release bot
The release is available on GitHub release
Your semantic-release bot