Funding Proposal: PIBD implementation in Grin++

Governance
1

Funding proposal PIBD implementation for Grin++

This is the start of Funding Proposal to implement Parallel Independent Block download (PIBD) [REF] in Grin++.

Why invest in implementing PIBD in Grin++?

The motivation is quite simple. Grin nodes consist for a large part, let’s say around 50%, of Grin++ nodes. Currently Grin++ uses the “. Zip” method to download chain data. There are numerous issues with using zip files such as a) being centralized, b) being vulnerable to attacks, c) easily leading to corrupted or failed downloads, in which case you need to download the whole file again and d) creating zip files requires a lit of memory and cpu recources, making nodes very busy and unavailable, often leading to them being banned because of becoming not responsive.

The grin rust node has switched to using PIBD which is more robust, decentralized and with some further optimizations could easily become a much faster syncing method than downloading zip files from a single peer. This was proven by MWcoin which can sync their chain in 11 minutes with a slightly modified PIBD version [REF].

What is a Funding Proposal?

Some of you might be familiar with Funding Requests by developers but might wonder what a “Funding Proposal” might be. A Funding Proposal is roughly the same as a Funding Requests, but it is initiated by the community or a council, which means it is less of a hassle for developers since there is no question anymore if there is interest to fund implementing a certain function, the only questions to discuss are practicalities like the exact deliverables, estimate time for delivering these deliverables and the amount of funding that is appropriate.
Input from developers is very useful here. Grin rust has PIBD implemented and good documentation exists for PIBD which make implementation easier. However, many optimizations have not been implemented yet in grin rust node. It would be forward thinking to consider the need of a few optimizations in implementation in Grin++ and perhaps put some first optimizations in the deliverables. That might mean some small changes or additions in the existing PIBD messaging are needed.

For who is this Funding Proposal meant?

Although this is an open call, the main idea is to invite @david and @davidtavarez as maintainers of Grin++ and ask if they are interested in taking on this large but important next step in the development of Grin++.
Your input on exact deliverables, how much time you think would be need and appropriate funding, would be examples of valuable contributions to this discussion.

What do we need from community members?

First of all, we discussed this topic shortly between CC members but I would like to invite them formally to give their endorsement and input on how to shape this Funding Proposal:
@Cobragrin @Neo @renzokuken @trab @Trinitron
Also from community members, it would be good to know if you support this initiative and if what you think would be needed to make this endeavor successful.

Pitfalls

We have consider that in the past some of funding towards Grin++ did not lead to a permanent fix. For example, a fix for "no peer " issues was funded before, however this issue persists although for only a few users. It is therefore important to clearly define our deliverables, perhaps put funding to certain deliverables and for developers it is important to inform as early as possible if some unforeseen bottlenecks are encountered that would for example mean deliverables cannot be achieved and perhaps more time and funding are needed?

Deliverables

[Below a list deliverables and update deliverables based on feedback from everyone, below some initial thoughts]

  1. A working PIBD messaging implementation for Grin++. Nodes need to be compatible in their messaging with other peers like grin Rust nodes.
  2. A permanent fix to Grin++ nodes mostly connecting to other Grin++ nodes. Probably due to lack of PIBD support for Grin++ but perhaps as well due to different peer banning rules, currently Grin++ nodes mostly connect to other Grin++ nodes. In a dystopian world this could break decentralization and lead to sub networks of grin nodes. Therefore, this issue needs to be investigated and solved to avoid it ever from happening. It should be to difficult ones PIBD has been implemented.
  3. Some first optimizations, perhaps asking for a list of fragments, or just increasing default segment size. The challenge is that any improvements should not break compatibility with other nodes such as grin rust nodes that not yet have these optimizations implemented.

Funding amount

[Will be based on the discussion]

Information for optimizing PIBD

→ Paralel Initial Block Download PIBD TESTING - #32 by Anynomous
→ MWC coin claims they significantly increased node sync
→ Line 347 mwc-node/core/src/core/pmmr/segment.rs at master · mwcproject/mwc-node · GitHub
→ Line 338 grin/core/src/core/pmmr/segment.rs at master · mimblewimble/grin · GitHub
→ do not check intermediate hashes

  • more peers
  • Start requesting last 48 hours blocks before end of PIBD
  • Larger default segment size, or perhaps a flexible size, increase when a peer has fast response, decrease with slow peers the size
  • Skip checks for intermediate hashes of fragments
5 Likes
2

yes, PIBD is slowing down initial sync up to 24 hours with slow peers, waiting time for every sync step is increasing.

g++ has known problem with peers, banning rust ones, I guess this bug should be fixed before pibd implementation.

comments from @david :

image
image1024×286 95.2 KB

4 Likes
3

Would this work also benefit Grim wallet in some way? I forget Grim’s relationship to node software

4

Grim uses the reference rust implementations under the hood. This would still benefit it however as grin-node will connect to Grin++ nodes while attempting PIBD which doesn’t help with sync speeds atm.

3 Likes
5

It would perhaps make it easier to implement optimizations to grin rust node since optimizations are already getting tested already in Grin++. And yes, grin rust nodes and as such Grim nodes will always benefit from more peers that support PIBD, even ignoring possible optimizations.

I am mostly looking for lowing hanging fruits regarding optimizing the speed of PIBD, e.g. increasing default fragment size for request, perhaps a call to ask for a list of fragments with a single hash to check etc.
Regarding slow and fast peers. I think the code in Grin++ could aim towards getting a response with a certain amount of time per peer. Meaning, if the response from Peer A is slower than a maximum response time over the last 10 calls or failed due to time out, the fragment size to be requested for that peers can be decreased by a factor 2. Is peer A faster than minimum a threshold for response time in the last 10 calls, the fragment size can be increased by a factor 2 for that peer. Keep tracking of something like that is super easy, a structure per peer which contains session settings and statistics provides enough information to make the syncing smart and adjusting. In this way you get auto-tuning of the sync speed per peer without it leading to any issues since there are no assumptions on whether a peer is slow or fast, it is a real time adjustment to what sync speed is observed. The only think that I do not know is if the messaging system as implemented right in the grin rust node supports different fragment size requests. So implementing it in grin rust might still involve quite some work depending on how it is implemented right now.

6

not sure what kind of optimization you are talking about, but cooperative work is needed 100%, so we can fix Rust node faster and with proper testing as we made some fixes back at 2023.

slow peers can be disconnected manually and automatically, we just need to find a way to detect them, I will make a patch of grin_p2p crate for Grim GUI with these experiments as now we have no external control on p2p server outside node.

There is another frequent issue like disconnection at background on Mobile when internet is going down and so on. After better testing we can push changes grin_p2p crate under mimblewimble organization.

4 Likes
7

The optimizations I talk about are mostly about increasing the sizes of individual requests, so send more data per request. Now its ping-pong, for each time a very small segment each with their own hash. It makes things slow. A lot can be learned from how torrents work and optimize on data chunk sizes. Making chunks larger should make it much faster, at least for PC’s. I think a lot of waiting is from slow peers waiting to respond, not slowness of the internet connection itself.
For mobile devices it might be much more complex since they tend to connect disconnect all the time. So perhaps there more checking/pings of peers being online is needed. You and @i1skn have most experience there, so any input is very welcome.

3 Likes
8

As I read this so far it’s an idea to fund PIBD implementation in Grin++. Correct me if I’m not caught up or that’s incomplete.

I weakly and vaguely support the specific goal of PIBD in G++. I don’t think it would turn away or attract any users, it works ok enough without it. It would depend on the amount and agreement from DT.

If DB was coming back to work on it though, I’d pay whatever fee he was asking for any task. Not for G++ specifically but just anything to get his specific mind on Grin again even just for a bit I think would be fantastic for Grin.

4 Likes
9

I think it would stop things like this from happening (correct me if I’m wrong @Anynomous I’m not sure if PIBD would solve the below issue exactly)

I regularly see forum posts about not being able to complete a sync or it taking super long. Which is odd to newcomers because Grin is supposed to be minimal and light.

10

@trab Yes, it should solve those kind of issues. Downloading a zip is all or nothing, so absolute not a robust way of sharing chain data since you might download many GB’s just to have to start all over. I can with great certainty say that PIBD is the way forward for both grin rust node and Grin++.

I agree with @Trinitron, PIBD it is not the type of future that will attract new users, but for sure it might make those first experiences for new grinners a much smoother and user friendly experience and as such lead to higher retention of people who try grin who chose to stick with the project.
The best crypto magic just works without an average user even being aware of it. PIBD is like that, a major change under the hood that is for sure worth it, but go unnoticed by many.
Next to that I am very much a believer of greater sync speed with a few optimizations. I will look into these myself when I have time. There are some default parameters in PIBD that I am quite certain of can be tweaked to improve sync time significantly with only marginal extra cost in terms of memory usage. So probably there is not even a need to change anything to the messaging system itself.

1 Like
11

Definitely not a draw for people, but fixing things that turn people off is just as important. I do wonder how many people downloaded a Grin wallet, had trouble syncing, and then got disillusioned and thought the project was abandoned bc it didn’t work smoothly.

Grin needs to do the basics really, really well. I feel like that’s part of what it is (basic crypto currency as it was always intended).

3 Likes