-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include max memory size of GVM in genesis parameters? #761
Comments
I think Option 1 ~ 3 is too risky since it can make different results. For Option 4, we could limit node binary version just like cosmos does for Option 5 looks good but because of BTW, can you leave source code line number url for where |
Yes, we need to fix this and other parameters to ensure determinism, maybe also the go runtime, arch? I suggest trying to put such parameters on-chain, updatable by DAO ( Edit: related discussion here: #871 (comment) |
@r3v4s, sorry for the confusion. The maxAlloc parameter isn't set via the gno.land node command line, but rather as a Machine option when creating the machine instance. In addition, we can provide the parameter for testing through cmd/gno/test.go by modifying the tests.TestMachine(testStore, stdout, "main") and adding the required parameters for maxAlloc. Regarding option 5, its purpose is to avoid unintended or accidental changes that could cause discrepancies among nodes. As for malicious nodes, the execution result must undergo BFT consensus before being accepted by the network. The result will be as expected unless over 1/3 of voting power from the malicious nodes votes for different outcomes. |
Description
Should we include a maximum memory size for GVM execution in the app's genesis state to ensure deterministic contract execution across nodes? We are open for discussion and propose option 5
The allocator (pkg/gnolang/alloc.go) manages the maximum memory size in bytes allocated to the VM. By default, there is no limit, but the maximum value can be set when we start the nodes from CLI.
Option 1: Keep the default setting. Since each machine has distinct physical memory limitations and Go environment configurations, the same contract execution may succeed or fail on different machines due to memory allocation variations in the Go runtime.
Option 2: Set the maximum value via the command line, as it is currently implemented. Different users may set different values, leading to inconsistent contract execution results across machines due to varying max alloc size settings.
Option 3: Set the maximum value in the config.toml. Users may still set different values or values could change between release, causing the same contract execution to have varying outcomes on different machines because of differing max alloc size settings.
Option 4: Hard-code the maximum value. If different values are used between releases and users run various node versions, the same contract execution may succeed or fail on different machines due to different max alloc size settings.
Option 5: Incorporate the GVM's maximum memory size as a genesis parameter, and verify the value when starting the node to ensure the machine has adequate memory and extra buffers to run the GVM. This ensures that a node joining the network has a deterministic maximum memory size allocation in GVM.
The text was updated successfully, but these errors were encountered: