You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To run a gno.land node in both production and local testnet environments, the node must have the capability to reset to its original state during migration, upgrades, and testing.
Currently, to achieve this, we delete the "testdir" which is created by default when starting gno.land. However, this action also deletes testdir/config/config.toml, leading to the loss of any configuration changes.
There are two primary methods to reset the network:
Hard Reset (Unsafe): This method involves removing the data and resetting the validator state back to its genesis. It is typically used in testnet environments. There is no coordinated upgrade and reset needed.
Soft Reset (Safer): In this approach, only the data is removed while retaining the validator state from the time of the reset. This method is favored in production environments to prevent issues like double signing and network forking. After a soft reset, the node must synchronize transactions and states from other nodes until it reaches the height where the soft reset occurred.
The text was updated successfully, but these errors were encountered:
Description
To run a gno.land node in both production and local testnet environments, the node must have the capability to reset to its original state during migration, upgrades, and testing.
Currently, to achieve this, we delete the "testdir" which is created by default when starting gno.land. However, this action also deletes testdir/config/config.toml, leading to the loss of any configuration changes.
There are two primary methods to reset the network:
Hard Reset (Unsafe): This method involves removing the data and resetting the validator state back to its genesis. It is typically used in testnet environments. There is no coordinated upgrade and reset needed.
Soft Reset (Safer): In this approach, only the data is removed while retaining the validator state from the time of the reset. This method is favored in production environments to prevent issues like double signing and network forking. After a soft reset, the node must synchronize transactions and states from other nodes until it reaches the height where the soft reset occurred.
The text was updated successfully, but these errors were encountered: