[Neo Plugin New Feature] Rollback ledger

[Jim8y]

Description

Problem:

Neo nodes support various plugins that provide a wide range of services, such as applicationlogs, stateservice, and more. However, these plugins sometimes crash or pause, causing them to miss critical block execution information. This desynchronization between the plugins and the blockchain can lead to inconsistencies and outdated information.

Currently, the only way to resynchronize these plugins is to reprocess the entire blockchain from the genesis block, which is inefficient and time-consuming. This process also increases the risk of further errors and delays in service restoration.

Solution:

To address this issue, we propose implementing a rollback mechanism in the Neo node. This mechanism will allow the blockchain to roll back to a specified block height, enabling plugins to resynchronize their data starting from that point. By rolling back to a known good state and reapplying blocks, plugins can catch up with the latest block execution information without the need for a full blockchain resynchronization.

Proposed Implementation:

Monitor and Record State Changes:

Implement a system to monitor and record state changes of the blockchain during block commits.
Save these state changes to a persistent store indexed by block height.
Rollback Command:

Introduce a new command (fallback ledger) that allows users to specify a target block height to roll back to.
When executed, the command will revert the blockchain state to the specified height by applying the recorded state changes in reverse order.
Reapply Blocks:

After rolling back to the specified height, the node will reprocess blocks from that height onward, ensuring that plugins can update their state with the latest block execution information.

Fixes # #3312

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• TBD

Test Configuration:

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Jim8y]

this should be reverted by setting neo internal accessable to plugin

[cschuchardt88]

@roman-khimov @Jim8y

Can't we use SPV packets? To reset the node? To rebuild the MerkleRoot

neo/src/Neo/Network/P2P/MessageCommand.cs

Lines 139 to 164 in efbdc94

	#region SPV protocol
	/// <summary>
	/// Sent to load the <see cref="BloomFilter"/>.
	/// </summary>
	[ReflectionCache(typeof(FilterLoadPayload))]
	FilterLoad = 0x30,
	/// <summary>
	/// Sent to update the items for the <see cref="BloomFilter"/>.
	/// </summary>
	[ReflectionCache(typeof(FilterAddPayload))]
	FilterAdd = 0x31,
	/// <summary>
	/// Sent to clear the <see cref="BloomFilter"/>.
	/// </summary>
	FilterClear = 0x32,
	/// <summary>
	/// Sent to send a filtered block.
	/// </summary>
	[ReflectionCache(typeof(MerkleBlockPayload))]
	MerkleBlock = 0x38,
	#endregion

[roman-khimov]

No, that's different.