Closed njgheorghita closed 5 months ago
Personally, I'm in favor of removing them for the time being. We don't have a current use case. It will not be difficult to re-introduce the content type once the use-case is fully justified.
Removing EpochAccumulayors takes time away from debugging real issues making our network unstable.
Our bandwidth bottleneck has to do with us sending 2 udp packets for every 1 uTP packet. uTP packets are sent over TalkRequests which requires a talk response. This is our biggest networking bottleneck and also a very low priority.
Removing it takes dev time what can resolve issues stopping us from launching a 4444's network.
I am not sure how this PR relates to the MVP Milestones. This seems like a side quest we should talk about in 6-12 months
~Currently nobody uses the network. So of course nobody uses it yet.~ Have gotten confirmation from fluffy that they already use it.
With how I wrote NClientTestSpec and test creation automation on Portal Hive it would take 5-15 minutes to add tests for EpochAccumators the hardest part is me getting the content key/value myself which would be using logs to dump it from the bridge
Have gotten confirmation from fluffy that they already use it.
Yup, closing this issue.
There has been some discussion in Discord regarding whether or not it's worth storing epoch accumulators in the network. I've listed some of the main points below, but please add any other relevant points.
Pro (aka. let's remove the accumulators)
Con (aka. let's keep them in the network)
block_hash
byblock_number
lookups (for pre-merge blocks)