Implement Rollback Mechanism for Neo Node to Sync Plugin Information about neo HOT 13 OPEN

Implement a system to monitor and record state changes of the blockchain during block commits.

Just reuse MPT with full history. NeoGo can rollback using exactly that. We will need MPT embedded anyway for #1526.

from neo.

Implement a system to monitor and record state changes of the blockchain during block commits.

Just reuse MPT with full history. NeoGo can rollback using exactly that. We will need MPT embedded anyway for #1526.

unfortunately, we will not have mpt for ordinary node. why? because it would require a whole resync of the chain again to calculate the tree. using mpt is really good, we should have it integrated at the very begining. but now its unnecessary as neo has adopted statevalidators solution, and new 'stateroot' solution should based on that. we shall never require another whole chain resync.

from neo.

oh by the way, i am curious how mpt can achieve rollback? isnt it a store tree? how come it can have history data?

update： get that already.

from neo.

Another BTW, this is a plugin~~~~ technically, user will not use it unless they know that it is and they install it.

from neo.

Do you think core should save the TriggerType.OnPersist and TriggerType.PostPersist application_executed states? Pointless to process them to just reprocess them again in ApplicationLogs

from neo.

Do you think core should save the TriggerType.OnPersist and TriggerType.PostPersist application_executed states? Pointless to process them to just reprocess them again in ApplicationLogs

this pr only solve one problem, which is rollback the ledger. taking care of other plugins can be solved in other prs. that is why i make this feature a plugin, we can keep updating it without breaking anything.

previously i had a complete system that handles all plugin store, but just too big to get reviewed.

from neo.

Implement a system to monitor and record state changes of the blockchain during block commits.

Just reuse MPT with full history. NeoGo can rollback using exactly that. We will need MPT embedded anyway for #1526.

unfortunately, we will not have mpt for ordinary node. why? because it would require a whole resync of the chain again to calculate the tree. using mpt is really good, we should have it integrated at the very begining. but now its unnecessary as neo has adopted statevalidators solution, and new 'stateroot' solution should based on that. we shall never require another whole chain resync.

You will need to resync

from neo.

Implement a system to monitor and record state changes of the blockchain during block commits.

Just reuse MPT with full history. NeoGo can rollback using exactly that. We will need MPT embedded anyway for #1526.

unfortunately, we will not have mpt for ordinary node. why? because it would require a whole resync of the chain again to calculate the tree. using mpt is really good, we should have it integrated at the very begining. but now its unnecessary as neo has adopted statevalidators solution, and new 'stateroot' solution should based on that. we shall never require another whole chain resync.

You will need to resync

totally up to the solution, if we have a solution that can be applied at any moment and not require a resync, why would we choose a resync one? and this plugin takes effect when it is installed, no resync is needed at all, unless user want to rollback to revious blocks, but that should not be a concern of this plugin cause he can simply resync the chain as before. this plugin is for answering the question of some plugin falls back the mainchain and miss some block states.

from neo.

but now its unnecessary as neo has adopted statevalidators solution, and new 'stateroot' solution should based on that.

This part I can't understand.

this plugin is for answering the question of some plugin falls back the mainchain and miss some block states.

Plugin to restore plugins? Who is going to use it?

from neo.

but now its unnecessary as neo has adopted statevalidators solution, and new 'stateroot' solution should based on that.

This part I can't understand.

Neo has statevalidators, we can use them to calculate a state root for every single block, then broadcast/share it, other nodes can also calculate its own state root for that block, then compare with statevalidators'. No need to calculate a global stateroot at all, no need to resync at all. As long as we ensure block leverl state consistancy, we ensure the global state consistancy.

We may switch to MPT in the future, but currently, i think we should avoid resync. With block-level MT being calculated and stored, we can have an official snapshot at some height, then those existing node can calculate MPT based on that snapshot and its local MTs without resyning anything.

That is ->

1. Block leverl MT
2. Snapshot (MPT) + MT
3. MPT

this plugin is for answering the question of some plugin falls back the mainchain and miss some block states.

Plugin to restore plugins? Who is going to use it?

Whoever think its useful. its plugin, not something integrated into the core.
First of all i dont think plugin restore plugin has any issue at all. As long as it works efficiently and solves the issue.

Then, its not plugin restoring plugin, rollback plugin works on ledger, moves ledger backwards, it does not communicate, nor interoperate with other plugins.

from neo.

we can use them to calculate a state root for every single block, then broadcast/share it,

This is done already (but neo-project/neo-modules#536 and #2374 (comment)).

other nodes can also calculate its own state root for that block, then compare with statevalidators'

You wouldn't believe, but that's exactly what NeoGo does.

No need to calculate a global stateroot at all

I'd be interested in alternative to #2373 without in-header state root. Snapshots can help somewhat (hi, #1286), but the question is --- why should we trust them?

Although all of this discussion is better for #1526.

from neo.

This is done already (but neo-project/neo-modules#536 and #2374 (comment)).

This is awesome.

You wouldn't believe, but that's exactly what NeoGo does.

Nothing wont i believe neogo has it, you basically have discussed all problems that i am concering now.

I'd be interested in alternative to #2373 without in-header state root. Snapshots can help somewhat (hi, #1286), but the question is --- why should we trust them?

Although all of this discussion is better for #1526.

What i have in mind is exactly not in-header, but directly p2p/rpc validation. as to why should we trust them, very simple, we hardcode snapshot state root into the core. Its public and anyone can challenge that.

from neo.

as to why should we trust them, very simple, we hardcode snapshot state root into the core

What core? Node source code?

from neo.