No need for centralized action at the time of the protocol upgrade

[kantp]

At the last upgrade, there was a script that created the new ledger state. The script was used to package a new ledger, as well as for validation of its integrity by community members. In the future, it is preferable that each node constructs the new ledger independently.

[georgeee]

I suggest that we view it in the following way: each node that is deployed with a version supporting the upgrade will simultaneously maintain both new and old ledgers, so that at the moment of hardfork we simply need to start using the new ledger (and eventually remove the old ledger, maybe two epochs into the new network running?).

[EmrePiconbello]

Considering how long the ledger state take to be created from latest state unless fork process changes significantly. I don't understand how we can just flip to a new ledger and that ledger can be ready.

Unless we are talking about network stop processing transactions then blocks and just doing the ledger calculation automatic while waiting on a halt. If that's the plan it would be very significant improvement while issues can be cartographic.

[kantp]

@EmrePiconbello I think the minimal requirement is that computing the new ledger state happens on every node, without the need to download a new package at a specific point in time. This could still mean that service goes down for a while, long enough for the nodes to compute the new ledger.

We could also add a requirement that there is no downtime, or that the downtime should not exceed a certain number of blocks. Might be harder to implement it that way, though.

[kantp]

I suggest that we view it in the following way: each node that is deployed with a version supporting the upgrade will simultaneously maintain both new and old ledgers, so that at the moment of hardfork we simply need to start using the new ledger (and eventually remove the old ledger, maybe two epochs into the new network running?).

I like that! It would allow a smooth, switchover upgrade! It would imply that we'll need one node that supports both protocols, right? Otherwise, we can't ensure that both versions of the ledger have the same transaction content. Does that fit the current development methodology for the node, or would we need to change that?

[EmrePiconbello]

long enough for the nodes to compute the new ledger.

My question is are we talking for all kind of forks here? Because a fork like zkapp fork also requires archive node for the ledger calculation. How that's going to be provided. If we can mitigate that need for all kind of forks that would be very significant improvement but I don't think that's in scope for forks with significant changes.

[kantp]

Yes, the goal is to support any kind of protocol upgrade, including something like the Berkeley hard fork.