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
Current suggestion is focused on improvement of MAINNET . This can introduce some complexity for testnet validators as they are relay on external score collectors. However, I believe mainnet needs should be prioritized and put in first place, in front of developers and testnet noderuners.
Introduce operator config ( operator.toml ) which will not be affected by version staging procedure and coexist together with config.toml
Approximate inclusions and explanations:
[node]
This is very important for node operators, should remain permanent and never be changed by any automation in any case.
sync_to_genesis = false[ current default is true ] [ keep default true ]force_resync = false[ current default false ] [ keep default false ]
[logging]
Json format is typically preferred by professionals who use centralized log collectors or special utility to evaluate log files. However, we have developers at first, testnet "noderunners", researchers and enthusiasts across all our community resources, this people post issues mostly in screenshots format, there json output is close to unreadable. This make any sort of technical support very very complex process and prevent people from understanding internal processes as they simply thinking json strings is some sort of abracadabra which can be only be understand by magicians as such as Joe. People never try to read json logs for this particular porpoise. Default colors would be beneficial to set as true, but it's worth noting that not all terminals may support appropriate output, potentially resulting in eye-straining submissions.
format = 'json'[ current default json ] [ set default to text ]color = true[ current default false ] [ keep default false ]abbreviate_modules = false[ current default false ] [ keep current default false ]
[consensus]
Allow operators the flexibility to store keys in their preferred locations. Various scenarios, best practices, security precautions, and individual deployment preferences may require custom paths to keys. This path should be under the control of the operator and never overwritten by any automated process.
IP addresses ending in zero can be confusing to users and have the potential to cause issues in the future. To ensure safety, it would be best to rewrite the syntax and make it a permanent part of the configuration. Additionally, it's important to allow operators control over the port.
public_address = 'x.x.x.x:0'[ if not set use staging algorithm to find instance IP, if set use user provided IP ]bind_address = '0.0.0.0:35000'[ keep default port ]known_addresses = [ if not set use config.toml ] [ use user provided if exit ]
[rpc_server]
Following best practice we should keep all possible HTTP/WS servers ports bonded to host by default and never overwrite for sake of security.
Following best practice we need to keep all possible HTTP/WS ports bonded to host by default and never overwrite.
enable_server = true[ default true ] [ keep default ]address = '0.0.0.0:8888'[ default on all interfaces ] [ set to host, keep port adjustable ]cors_origin = ''[ default none ] [ set default to host ]
[event_stream_server]
In most cases, event streams are not necessary and can be disabled by default. Additionally, they should be limited to the localhost for security reasons. This configuration should never be overwritten by any automation.
enable_server = true[ default true ] [ set default to false ]address = '0.0.0.0:9999'[ default on all interfaces ] [ set default to host ]cors_origin = ''[ default none ] [ set default to host ]
[storage]
Many operators use custom database path for multiple reasons, this is critical string which should be under operator control and not overwritten by staging procedure.
path = '/var/lib/casper/casper-node'
The current suggestion requires careful integration and multiple testing stages. While it may put some load on testnet operators, implementing these changes will greatly enhance stability, reliability, and security on the mainnet.
Please note that the suggestions provided here are initial examples and should be subject to discussion with the community. It is also important to explore additional values that can be stored in the user config.
The text was updated successfully, but these errors were encountered:
Current suggestion is focused on improvement of
MAINNET
. This can introduce some complexity for testnet validators as they are relay on external score collectors. However, I believe mainnet needs should be prioritized and put in first place, in front of developers and testnet noderuners.operator.toml
) which will not be affected by version staging procedure and coexist together withconfig.toml
Approximate inclusions and explanations:
[node]
This is very important for node operators, should remain permanent and never be changed by any automation in any case.
[logging]
Json format is typically preferred by professionals who use centralized log collectors or special utility to evaluate log files. However, we have developers at first, testnet "noderunners", researchers and enthusiasts across all our community resources, this people post issues mostly in screenshots format, there json output is close to unreadable. This make any sort of technical support very very complex process and prevent people from understanding internal processes as they simply thinking json strings is some sort of abracadabra which can be only be understand by magicians as such as Joe. People never try to read json logs for this particular porpoise. Default colors would be beneficial to set as
true
, but it's worth noting that not all terminals may support appropriate output, potentially resulting in eye-straining submissions.[consensus]
Allow operators the flexibility to store keys in their preferred locations. Various scenarios, best practices, security precautions, and individual deployment preferences may require custom paths to keys. This path should be under the control of the operator and never overwritten by any automated process.
[ network ]
IP addresses ending in zero can be confusing to users and have the potential to cause issues in the future. To ensure safety, it would be best to rewrite the syntax and make it a permanent part of the configuration. Additionally, it's important to allow operators control over the port.
[rpc_server]
Following best practice we should keep all possible HTTP/WS servers ports bonded to host by default and never overwrite for sake of security.
[speculative_exec_server]
Allow users to control the speculative endpoint from the user config, instead of having it overwritten by the staging process.
[rest_server]
Following best practice we need to keep all possible HTTP/WS ports bonded to host by default and never overwrite.
[event_stream_server]
In most cases, event streams are not necessary and can be disabled by default. Additionally, they should be limited to the localhost for security reasons. This configuration should never be overwritten by any automation.
[storage]
Many operators use custom database path for multiple reasons, this is critical string which should be under operator control and not overwritten by staging procedure.
The current suggestion requires careful integration and multiple testing stages. While it may put some load on testnet operators, implementing these changes will greatly enhance stability, reliability, and security on the mainnet.
Please note that the suggestions provided here are initial examples and should be subject to discussion with the community. It is also important to explore additional values that can be stored in the user config.
The text was updated successfully, but these errors were encountered: