How to know which releases are mandatory/recommended and how much time I have

I’m a bit confused as to when I need to upgrade my node, and when I can wait. I heard about a popular youtuber in the fall forgetting to update his nodes and the delegators missed out on blocks.

But then, I also read comments of people choosing not to upgrade their node or even downgrade their node.

Is there a heuristic / method I can use to know when I must updated?

What happens if I don’t update my node for 2 weeks, or 2 months after it is released?

Is any of this posted somewhere so I can look at each release and know that I need to upgrade it before XYZ date?

IMO it’s a good idea to upgrade whenever IOG says to do so. Their software is usually well tested and even if some serious bug pops up it gets fixed reasonably fast.

People choosing to downgrade (at least in this forum) use features not officially supported like p2p network.

1.34.0 is a bit different, as it actually had some issues, but it was only about tracing, which should not cause any problems unless you have to analyze something on your node, and the KES key rotation date computation is wrong. One can easily bypass that issue by using gLiveView.sh which shows the correct date.

1 Like

Thank you, then I guess I wonder about timing.

1.34.1 came out a couple days ago, if I don’t upgrade to 1.34.1 during Epoch 326, will I stop producing blocks in Epoch 327?

What if I don’t upgrade until Epoch 336 (10 Epochs later)?

What about if I wait until Epoch 426 (100 Epochs later)?

I guess I wonder when not upgrading will cause me to miss blocks / what the actual deadline is.

It pretty much depends on how far away you are from the current release. In order to produce blocks your node software must support the current era. I.e. you’ll have to run at least 1.29.0 to produce blocks in the current Alonzo era.

But there are serious performance enhancements in newer releases which allowed for increasing parameters like block size. I.e., if your node is not fast enough with some older software you’ll miss your block(s) and even worse it is possible that the next block will be determined in a block height battle, thus preventing the payout of the reward of some other pool. And of course it does not help the network if one (yours) or more blocks (follow up) are not validated because your node is too slow.

1 Like

Ok thanks, right now I am trying to upgrade within 5 days of a new release being posted. I had a lot of anxiety, thinking that if I don’t upgrade within 5 days (or 3 days etc, before epoch switches) that I would not get blocks. But it sounds like there is no rush.

You should always read the release notes on Github. When a release is mandatory, you will usually find this information in the release notes.

1 Like

I agree to read the release notes. I think what’s missing from those notes is language like “version 1.x.x will not longer work after release 1.x.x”. I think this is needed to provide a definitive line in the sand so people know what’s expected. There are breaking changes noted, but it isn’t clear what’s required.

I say this because I have a buddy that has multiple layer 2 sites that use the js-api library to work with their nodes. He told me that the 1.33 release was horribly slow. He had to pull his nodes back to 1.32. I was actually doing some of the testing after he mentioned this and I found huge differences in time working with (at the time) the 1.33 release.

Even using the command line directly to query utxos from an address took around 8-10 seconds. One 1.32 this was a consistent 1-2 seconds. I have not tried 1.34 version(s) yet and will soon.

I guess to sum it up, you should probably check the release notes and do your own checks to see if it performs to your requirements.

There’s a simple reason for that. From version 1.33.0 on the ledger state is no longer stored in memory. Instead, parts of the state is stored on disk. Searching on disk takes longer than in memory. IOG continues to move more and more data from in memory storage to disk to decrease the memory footprint. This helps full node wallets and pools with tiny hardware like raspberries.

It is still important to upgrade rather sooner than later, because even if a block is scheduled for your pool - if your node is not fast enough to deliver in time, it will get lost. There are no rewards for lost blocks.

The latest releases improved performance, so that parameters could be increased. Older software is too slow to handle larger blocks in time.