-
Notifications
You must be signed in to change notification settings - Fork 79
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
Check NeoFS chains compatibility with limited MaxTraceableBlocks #3493
Comments
MaxTraceableBlocks: 5760
|
OK, it's just came to my mind that it's a hardfork height. @AliceInHunterland, what is your node configuration? Does it have Domovoi enabled? Which version of NeoGo do you use? |
MaxTraceableBlocks: 40320
|
my config is:
and:
|
Config is correct, and just for future, it's better to take the same version of NeoGo that runs in NeoFS. But for 0.106.3-pre-16-gda40f2de it doesn't matter because there were no breaking changes. So the reason is in NeoFS RPC node, it has an outdated config, should be fixed by @532910 and then we need to re-check states. Likely, everything should be OK with 5760. |
testnet MaxTraceableBlocks: 5760
|
I just leave it here so that it's possible to reference this comment, an outdated config is used for NeoFS mainnet nodes.
|
/config/protocol.mainnet.neofs.yml
|
We want to cut the tail more aggressively, what matters is state, but not old blocks and transactions that contracts don't use in any way. #3493 suggests that it's safe to limit the tail to one day, but let's be a bit more conservative for now. As a sidenote, EVM only allows to fetch things from the recent 256 blocks. Signed-off-by: Roman Khimov <roman@nspcc.ru>
Is your task related to a problem? Please describe.
I'm always frustrated when we have a loooong tail of history in NeoFS chains. Refs. neo-project/neo#2026.
Describe the solution you'd like
Try synchronizing with
MaxTraceableBlocks
of 5760 (a day), if it works --- OK immediately. If it doesn't --- try with 40320 (a week). Success criteria: same state computed for the current height. I expect 40320 to be a bit more realistic setting for a real network, but we need to know our possibilities.The text was updated successfully, but these errors were encountered: