Proposal: Change "Accepted" block label definition

[herr-seppia]

1. Preamble

• DIP Number: (To be assigned upon acceptance)
• Title: Change "accepted" block label definition
• Author(s): @herr-seppia
• Status: Draft
• Category/Type: Core
• Creation Date 2024-04-05

2. Abstract

Flag block accepted after executing fallback to "Accepted" instead of apply "Instant Finality" define here dusk-network/rusk#1118

3. Motivation

Until the proper "Rolling Finality" is implemented, there is the need to avoid stalled fork. Currently, due to the naive implementation of rolling finality implemented by dusk-network/rusk#1211, there is an edge case when a node N is marking a block as final, while the rest of the network is marking another chain as final too.
Example:
Block #80 - Accepted at iteration=1 with NoQuorum for iteration=0
Block #81..#99 -> Attested
While the network is accepting block #100 (marking it final for any reason) a very slow node N can receive block #80 at iteration=0 and executing the fallback properly.

This lead the node N to an inconsistent state where it's not able to sync with the current network.

Changing the local applied finality to "Accepted" for the first accepted block after a fallback, will allow the node to revert to last finalized state

4. Technical Specification

In addition to what specified above, the out-of-sync detection should be changed to revert to last finalized block when idle and receiving blocks with height greater than RollingFinalityThreshold that are not able to be accepted due to "invalid previous block hash" error.

5. Rationale

Discussion on the decision-making process and trade-offs considered. TBD

6. Backwards Compatibility

Analysis of how the proposal interacts with existing features or might affect backward compatibility. TBD

Test Cases

Practical examples and test cases for validating the proposed changes. TBD

8. Implementation

Reference to the implementation code; this may include links to PRs in external repositories. TBD

9. Security Considerations

Assessment of potential security implications and how they are addressed. TBD

10. References

dusk-network/rusk#1118
dusk-network/rusk#1211

11. Updates (Optional)

Documenting significant changes or updates to the proposal post-acceptance. TBD

[autholykos]

TBC, does this mean that this DIP proposal would modify the definition of finality as follows?

A node marks a block as final when either:

• the node accepts the block candidate at iteration 0, the previous block is marked as final, and this is not the first block accepted after a fallback OR
• the node accepts the block candidate at an iteration N, all N-1 previous iterations have a Quorum, the previous block is marked as final, and this is not the the first block accepted after a fallback OR
• the node accepts the block candidate in accordance to the rules of the rolling finality, and this is not the first block accepted after a fallback

[herr-seppia]

I would collapse the first 2 using the concept of ATTESTED blocks defined by dusk-network/rusk#1158

Anyway, the result is the same, it just change where we want to introduce exceptions into the definitions

I believe that If from fallback: then always mark Accepted; otherwise do everything as it is right now is the more concise way

[autholykos]

Fair point

[fed-franz]

I think this is superseded by #11