Venus next stage development planning / Venus下阶段工作计划头脑风暴

[Fatman13]

背景

2022年度Venus即将结束。Venus的开发也将走到第55个sprint。在此将思考/研究接下来新的季度，新的一年的开发计划。

需求征集

Venus团队在此向社区征求使用Venus时需要的需求，或者希望Venus能够集成的新需求。

需求征集对象

• 社区用户
• 企业级用户
• 企业级解决方案用户（基于venus体系对外提供解决方案的用户）

关联资源

• Product Roadmap / `Venus`下6个月路线图 Roadmap #5062

[Fatman13]

背景

• 在filecoin本身协议上，filecoin不同实现如何差异化？
• 23年将是fvm元年，如何把fvm结合到开发计划中？

方向

从SP的角度出发，让SP体验使用Venus实现能够带来差异化优惠。我提议一个可能的开发方向 -- Venus对DataDao方向的支持。围绕DataDao方向进行开发计划，不仅可以满足Venus实现相对其他实现的差异化需求，也能在PL提出的fvm的datadao方向上获得潜在的支持。通过在venus本身现有的分布式架构，以及智子多矿工管理上做文章，向DataDao概念上靠拢。

DataDao优势

以智子为核心的多矿工DataDao模式的探索。

DataDao Case 1

DataDao Case 2

（未完待续...)

[Fatman13]

之前社区建议的一个方向：

建议把VSM的winpost和winning功能砍掉，它的角色就是负责好调度，消息和节点数据的管理。 把worker分成2类，一类的封装类型的，一类是winpost和winnpost类型的，启动的时候配置好就可以了。这样C/S的架构更利于维护和灵活扩展。
链服务跟VSM之间的工作模式不正是C/S架构。官方的lotus，最新版本也是在这样实现了，让worker有多种类型，负责封装的和负责做winpost的，可以学习下。有时候刻意的追求分布式，反而让运维和实现更复杂。

[Fatman13]

社区snapdeal优化方向：

• snapup扇区的ProveReplicaUpdates消息对扇区WdPost时间点的检测有几率导致消息失败 ipfs-force-community/damocles#494

[Fatman13]

Dapp基建方向，参考Alchemy，同时也结合go-fvm-sdk。