GRIN Save States?

Development and Technical Discussion
1

It is written in the original mimblewimble paper, after explaining the problem of data bloat (150 million transactions must be validated for 4 million outputs) and the problem of privacy and the existing solutions to it:

These solutions are very good and would make Bitcoin very safe to use. But
the problem of too much data is made even worse.

I am glad that I had to download only 3 GiB of data to get Grin++ up and running (and I already saved the “.GrinPP” folder for faster download later). Privacy is not what makes mimblewimble unique! There are other solutions for privacy, but the reduced amount of data (useful, because we are in a network transporting it) is what picked my attention. This grandiose claim in the formal mimblewimble paper is what made me take GRIN seriously in detriment of many other projects:

we solve this, and combine it with existing research for compressing proof-of-work
blockchains, to reduce the 15Gb to less than a megabyte.

Why not “save states”, a monthly published tiny blob of data, that describes the state of GRIN one month before? The servers can store the whole blockchain and the mobile phones can pick up the state from the past month (the paranoid ones could also use the same approach as the servers).

I was unable to download the whole blockchain through the command-line “Grin Node” client, which was concerning. Those trying to shut down GRIN could prevent those trying to join the network from fully downloading the 3 GiB of data required to participate on it as of 2025.

What do you think?

1 Like
2

If I understand your concern well, you do not want to re-download the chain_data from the beginning if you turned off the node for long time right?
You may try to use archive node with archive option in config file. It continuously the last synch timestamp.

3

For me making snapshots would only make sence for archive nodes. Regular nodes can sync fast enough using Parralel Innitial Block download (PIBD).
There are reason why we want to sync decentralised from many peers. Relying on any single entity, or place to store snapshots, introduces risk.
What I think is more usefull is to make minor optimizations to PIBD to make it faster. For example MWcoin copied PIBD and made a minor modification, increasing the default size of segments. The result is a massive increase in syncing speed (sync takes 11 minutes) .

This speed most likely comes with some costs such as relying on a few fast and centralised nodes so we should not copy it. But perhaps we can learn a bit from this “pragmatic approach” and change some default settings (such as segment size, number of peers) to get faster syncing without any real costs or downsides.

3 Likes