Author: Sjors Provoost 2018-06-07 09:39:59
Published on: 2018-06-07T09:39:59+00:00
The proposal suggests storing only the hashes of unspent outputs, which would reduce the size of a pruned node by 40%. However, the ongoing bandwidth increase of 5% may not be worth it. The storage issue is not cited as a usage limiting factor for pruned nodes. The inefficiency of transaction mechanisms could lead to a 25% increase in overhead when considering the size of a transaction versus the size of transactions with scriptpubkeys and amounts. Implementations can adopt this proposal without permanently changing the blockchain data structure. Low-end devices typically use eMMC storage, which comes in 2x increments. Running a pruned full node on 8GB is difficult if not impossible, but 16 GB is only €10 more expensive. This proposal may help squeeze more out of limited RAM on low-end devices, which usually have only 1 or 2 GB of RAM. The benefits during initial sync and ongoing operation need to be distinguished. The former is mostly done on a faster computer and copied to the device while the latter needs far less RAM. Testing Cory's branch would determine if squeezing more out of limited RAM actually matters in practice.
Updated on: 2023-06-13T02:21:20.543533+00:00