Portal Implementers Call #48 - March 24th

Protocol Calls & happenings
1

Meeting Info

Agenda

GitHub Issue

2

This week’s call notes below:

1. Team update

  • Update on Trin by Ognyan

    • Cleaned up history storage by removing old content value types
    • Refactored e2store header types for compatibility
    • Implemented ping extensions for JSON RPC endpoints
    • Added ephemeral store as a step toward ephemeral content for the History network

  • Update on Fluffy by Kim

    • Tuned the PoC syncing Nimbus EL from Portal Netowrk: incl. adjust recursive finContent concurrency (reducing requests from 3 to 2 slightly improved performance)
    • Observed that ~10% of recursive findContent requests timeout when sending 2-3 concurrent queries, potentially due to udp packet loss or async lib issue
    • Improved ContentDB pruning mechanism for speed
    • Integrated EVM and implemented eth_call, yielding a ~20% performance improvement
    • Started investigating the issue of discv5 protocol handling multiple concurrent requests

  • Update on Ultralight by ScottyPoi

    • Finalized ping extension for JSON RPC endpoints
    • Improved pruning mechanism (now more deterministic behavior with reduced overlaps)
    • Released major update with EthereumJS lib
    • Progressed on ephemeral header implementation
    • Preparing on Portal integration with EthereumJS client

  • Update on Shisui by Qi Zhou

    • Geth integration process update
      • PR re. repeat challenge in “who you are” handshake: Merged and currently being tested on Hive, have some issues with Fluffy nodes (need further investigation)
      • PR re. ping extension for JSON RPC endpoints: In final review stasge, expected to be merged shortly
    • Collaborated with Geth to make Shisui run as an independent sub-process for Portal Network access
      • Initial implementation planned by end of this month
    • Other work incl.
      • Participated in protocol versioning discussion
      • Start working on detailed offer decline code
      • Fixed race condition issues

  • Update on Samba by Meld

    • Close to passing all Hive tests, except a bug in putContent gossip handling
    • Slightly behind on SSZ union removal and ephemeral headers implementation
    • Working in parallel to integrate Samba as a plugin for Besu
    • Nearest goal is to fix the putContent bug and make initial progress on Besu plugin integration

2. Roll out network changes using Protocol Versioning

3. Banning/ Peer handling

  • Risk of peer banning
    • Could backfire in edge cases, eg. banning all peers during local network outage
    • May accidentally isolate nodes from the network
  • Peer scoring is preferred over hard bans
    • Prioritize good peers rather than punishing bad ones

4. Handling Ephemeral State Content

  • Main issue

    • Current trie-based model struggles with ephemeral state management during chain reorgs, as state content can exist on both canonical and non-canoncial chain
    • The issue arises when attempting to migrate state content to permanent storage or delete non-canonical chain related content after finality

  • Potential solutions

    • Solution 1: Modify content keys to include block hashes, enabling proof tracking across forks (but risks redundant storage)
    • Solution 2: Restrict trie-based model to finalized state only, using the flat model for ephemeral data near the chain head

  • Team consensus

    • Favored Solution 2 for simplicity
    • Open questions
      • Define the threshold of “finalized” (EL/ CL finality vs practical limits)
      • Document verification rules for headers near the head of the chain

  • Action items

    • Formalize flat model spec, led by Milos
    • Clarify finality checks in the state network specs

  • Related PR/ issue

5. Storage of Ephemeral Block Bodies/ Receipts

  • Main question
    • How clients choose to store the ephemeral block bodies/ receipts? Whether they should be store permanently?
  • Potential approach
    • Pre-finalized data: Keep in-memory cache (auto-purged on finalization)
    • Finalized data: Persist permanently (proofs are immutable post-finalization)
  • Client plans
    • Trin: Testing in-memory storage for pre-finalized bodies/ receipts
    • Fluffly: Exploring separate tables for headers/ bodies to enable efficient access & pruning, but still need further exploration