Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed totalDifficulty from Blockschema #570

Merged
merged 1 commit into from
Sep 4, 2024

Conversation

Giulio2002
Copy link
Contributor

@Giulio2002 Giulio2002 commented Aug 12, 2024

Context

With Ethereum's transition from Proof of Work (PoW) to Proof of Stake (PoS) through the Ethereum 2.0 upgrade, the role of certain fields in the blockchain's schema has fundamentally changed. Specifically, the totalDifficulty field, which played a crucial role in chain selection and synchronization under PoW, is no longer relevant in the PoS consensus mechanism.

Motivation

  1. Obsolescence in PoS

    • Under PoW, totalDifficulty was essential for determining the canonical chain by identifying the chain with the highest cumulative difficulty. This metric was critical for chain selection and block validation.
    • In Ethereum's current PoS consensus, chain selection and block validation mechanisms are entirely different. The concept of "difficulty" has been replaced with more relevant metrics. Therefore, totalDifficulty no longer plays any role in the core protocol's operation.
  2. Redundancy in JSON-RPC

    • Maintaining totalDifficulty in the Block schema within the JSON-RPC interface introduces unnecessary redundancy. Since the field is no longer required for synchronization, verification, or any critical protocol operations, its presence serves no practical purpose.
    • Keeping this field in the JSON-RPC could be considered code debt—a remnant from the PoW era that no longer aligns with the current PoS consensus.
  3. Opportunities for Refactoring

    • By allowing clients to omit the totalDifficulty field from the JSON-RPC, client teams can gradually remove dependencies on outdated concepts. This opens the door to cleaner, more efficient codebases that are easier to maintain and extend.
    • Removing this field would streamline the block schema, reducing the cognitive load for developers and decreasing the risk of maintaining legacy code that does not contribute to the current protocol's functioning.

Current usage in application

For as far as I was able to gather (I still need to get more input on this), the 2 places were totalDifficulty is useful in the jsonrpc are:

  • Block Explorers
  • Transition hive tests

Block explorers

Although totalDifficulty is used by block explorers, it is probably not so useful information to display. Additionally, Block explorers do not directly query the node but create their own indexing from the json RPC. Therefore, creating a new indexing for totalDifficulty should be trivial if it is deemed of critical importance.

Transition hive tests

the totalDifficulty field is checked in hive tests for engine api transition but such check is mostly something extra and can be safely removed (albeit it will reduce the insights of merge transition).

Copy link
Contributor

@g11tech g11tech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm from ethereumjs

Copy link
Contributor

@onbjerg onbjerg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtu from reth

@garyschulte
Copy link

Besu still supports PoW (for ETC for example). It would be less than ideal to have to have chain-specific rpc header response formats, but it would not be the end of the world if the rest of the EL clients signal they would prefer to drop total difficulty.

@GIgako19929
Copy link

``

@GIgako19929
Copy link


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants