The ICON Foundation will submit a Network Proposal (Revision Proposal) to activate the Revision 8 feature on January 7th. This Revision 8 is already included in Loopchain 2.4.20, ICON Service 1.5.20, ICON RPC Server 1.4.9 and Reward calculator 1.2.0 but is not yet activated. The purpose of the proposal is to stabilize the network. Below are the summary of the update. Release note for this update is at Python API Reference - ICON DevPortal
Summary of this update
Edit logic to prevent confirmation of the previous block if it has a mismatch round with the current round of the node
Fix the state inconsistency for claimIScore between iconservice and rc
Fix score data corruption on score query call
Impose low productivity penalty when a P-Rep gets penalized for block validation failure and low productivity at the same time
Fix infinite loop on ipc_server termination
Pass a new main prep list to loopchain when a p2pEndpoint of the main prep is modified
Fix a crash on processing queryIScore request with malformed address
Rollback function is a necessary in the BFT consensus algorithm. If a node proposes a block and receives votes from other nodes but then fails to broadcast the block to other nodes (due to node shutdown or something like issue), only the node will have a different block hash because the block which the node has was already confirmed from other nodes but it was not broadcasted. So the node need to rollback the unnecessary block and try to sync with other nodes to recover its block data status.
Actually the rollback function is not fully implemented yet. It will be fully implemented in the Revision 9. Thank you for the question.
In short if someone hack a exchange and withdraw like millions of icx preps can roll back with majority. The important part is with chain issues. Most preps know what happened when chain had some issues they try to get all nodes on at the same time try to force same block number from main nodes etc. all these painful process happened because there is no rollback function. We are still going to have issues but fixing and recovering from that gonna be much more easier since function assist whole network going back in these situations.
Actually, it is a bit different thing. We have changed its name to Block Recovery function. It is the function to remove an invalid block, not for the roll-back function for governance purpose. It is necessary to remove an invalid block and sync from other P-Reps to align same block height.
Don’t get me wrong but afaik there is no difference for chain so delete function should work for “valid” blocks as well as “unvalid” blocks you stated so in the end it will result as a same thing. If that’s not the case can you please explain.