pull down to refresh

I am running a node on an RPI 4. It isn't the quickest but I run a very slim version of Debian on it. When setting up the node what I noticed is early in the chain it downloads and verifys blocks very quick but then you start to notice a slowdown as time goes on. I would say it seems to be related with increased activity because I start to notice signs of my node sync slowing down around the date 2014 and onward.
The biggest slowdown I notice start from about 2019. By late 2022-2023 everything is at snail pace. By this point progress is 0.935600%. It will take a full day to tick up by 0.01%.
I am not entirely sure if this is what everyone else experiences when syncing their node, but if it is then I assume that is because of block size and network activity. If that is the case, I wonder how many devices will benchmark as block size and network activity reach their maximums.
I view the RPI 4 as technically capable, but I am not sure I would recommend it or anything within similar specs since it does take so long to fully sync these days.
Transactions need to be verified during synchronization. As the number of transactions increases, the demand for computing power increases.
reply
That makes sense. If I wanted to benchmark devices with this in mind, what is the maximum number of transactions I should benchmark against?
reply
There were not many transactions in early blocks, but now there are often thousands of transactions in the same block. You can refer to mempool to observe the short-term average.
reply
just use neutrino. thank me later.
reply
I will stick to Bitcoin Core unless there is a opsec reason as to why I shouldn't. Don't plan to self host Lightning anyways. More just curious what is happening and why because where these slow downs happen is definitely repeatable in the many times I have re-installed Bitcoin Core, so I am curious to see if other people experience the same in around the same points when syncing.
reply