[FEATURE]: Clarify Fork Choice Rule for Proof-of-Work Consensus

[dhruvi-16-me]

Feature and its Use Cases

📄 Description

MiniChain proposes implementing a Proof-of-Work consensus mechanism. However, the fork choice rule is not yet explicitly defined.

In Proof-of-Work blockchains (such as Bitcoin), temporary forks can occur when two miners produce valid blocks at roughly the same time. In such cases, nodes must follow a clearly defined rule to decide which chain to consider canonical.

To avoid ambiguity during implementation, it would be helpful to clarify the fork choice rule early in the design process.

Questions for Clarification

1. Should MiniChain follow:

   • Longest chain rule (most blocks)?
   • Highest cumulative difficulty rule (most total work)?

2. How should ties be resolved if two chains have equal difficulty?

3. Should chain reorganization (replacing the current chain with a heavier one) be supported?

4. Is there any intended limit on reorganization depth?

Why This Is Important

• Ensures deterministic consensus behavior across nodes
• Guides networking and synchronization logic
• Prevents inconsistent implementations
• Aligns with MiniChain’s goal of being a clean and research-oriented reference implementation

Clarifying this rule early will help keep the consensus mechanism minimal and well-defined.

Additional Context

No response

Code of Conduct

• I have joined the Discord server and will post updates there
• I have searched existing issues to avoid duplicates

[dhruvi-16-me]

Hey @Zahnentferner since the prototype is not yet added to the codebase. So for the time being can i work on this. If it sounds okay so please assign me this.