fix(ethexe): fast-sync allow zero state and hashes request splitting

[grishasobol]

No description provided.

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
ethexe/observer/src/sync.rs	98% smaller
ethexe/ethereum/src/router/mod.rs	56% smaller
ethexe/network/src/db_sync/mod.rs	36% smaller
ethexe/network/src/kad.rs	32% smaller
ethexe/network/src/db_sync/requests.rs	25% smaller
ethexe/network/src/injected.rs	25% smaller
ethexe/network/src/lib.rs	11% smaller
.gitignore	Unsupported file format
ethexe/ethereum/src/lib.rs	Unsupported file format
ethexe/network/src/gossipsub.rs	0% smaller
ethexe/network/src/peer_score.rs	0% smaller
ethexe/observer/src/lib.rs	0% smaller
ethexe/service/src/fast_sync.rs	Unsupported file format
ethexe/service/src/tests/mod.rs	0% smaller

[gemini-code-assist]

Summary of Changes

Hello @grishasobol, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue within the fast synchronization mechanism where the presence of a zero state hash for an actor would erroneously trigger an error and stop the sync process. By eliminating a specific validation check, the system is now able to correctly handle and proceed with zero state hashes, ensuring that fast sync completes successfully in scenarios where such hashes are legitimate.

Highlights

• Fast Sync Logic: Removed a validation check that previously halted fast synchronization if an actor's state hash was zero, allowing the process to continue with valid zero hashes.

Changelog

• ethexe/service/src/fast_sync.rs
  • Removed the anyhow::ensure! check that verified state_hash was not zero during the collection of program states.

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to allow zero state hashes during fast sync by removing a check in collect_program_states. However, this change is incomplete and introduces a critical issue. The downstream function sync_from_network is not prepared to handle zero hashes and will panic in debug builds. My review includes a critical comment explaining the issue and the necessary changes to sync_from_network to correctly handle zero state hashes.

I am having trouble creating individual review comments. Click here to see my feedback.

ethexe/service/src/fast_sync.rs (243-246)

While removing this check is a valid step towards allowing zero state hashes, this change is incomplete and introduces a critical issue that will cause panics in debug builds.

The program_states map, which can now contain zero hashes, is passed to sync_from_network. This function has two problems when dealing with zero hashes:

1. Panic in RequestManager::add: sync_from_network calls manager.add(state, ...) for each state hash. RequestManager::add contains a debug_assert_ne!(hash, H256::zero(), ...) which will panic when a zero hash is passed.

2. Panic when enriching program states: Even if the first panic is avoided (e.g., by not adding zero hashes to the manager), sync_from_network will later panic at this line:

   .expect("program state cached queue size must be restored");

   This is because restored_cached_queue_sizes will not contain an entry for the zero hash.

To correctly fix this, you need to modify sync_from_network to handle zero state hashes gracefully:

• In the loop that populates the RequestManager, you should skip zero hashes:

  for &state in program_states.values() {
      if !state.is_zero() {
          manager.add(state, RequestMetadata::ProgramState);
      }
  }

• When enriching program states with queue sizes, you should handle the zero hash case. For a zero hash, the queue sizes should be 0, which is consistent with ProgramState::zero():

  .map(|(program_id, hash)| {
      let (canonical_queue_size, injected_queue_size) = if hash.is_zero() {
          (0, 0)
      } else {
          *restored_cached_queue_sizes
              .get(&hash)
              .expect("program state cached queue size must be restored")
      };
      // ...
  })

Since these changes are outside the current diff, I cannot provide a direct code suggestion. Please apply these fixes to make the fast sync robust against zero state hashes.

[grishasobol]

Temporary - in order to be able to connect to current Vara.eth testnet