Add ephemeral history gossiper #1851

KolbyML · 2025-05-22T17:35:36Z

This PR depends on

feat: add select_random_peers to census #1850

What was wrong?

This is a chunk from #1846

We need a Gossiper which handles the unique cases fund in the Ephemeral History Bridge we do different functions

flushing proven headers once a period is provable
gossiping an ephemeral bundle which includes a chain of Header's, but it can include multiple bodies/receipts if a re-org happens

How was it fixed?

Add the code

Work for followup PR's

Add support for metrics for header series
Think about how the AcceptCodeList from HeaderSeries would make sense in terms of the census OfferResult algo

KolbyML · 2025-05-23T15:54:54Z

@morph-dev this PR is ready to review now

morph-dev

There is one/two high level comments that I would like to discuss.

But no major concerns and PR looks mostly ok.

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

bin/portal-bridge/src/bridge/ephemeral_history/ephemeral_bundle.rs

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

morph-dev · 2025-05-24T19:55:40Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

+            .collect()
+    }
+
+    async fn send_offer_with_header_series(


nit: maybe rename to send_multi_offer?

This function assumes that the content is a header series. Multi offer would imply you could multi offer any set of data which isn't the case here

That's true for gossip_content_header_series (because of the select_random_peers), but how would this function be different for other type of content?

I will change it's input parameter's then to restrict it more

I'm not sure I understand your arguments, can you elaborate more?

Multi offer would imply you could multi offer any set of data which isn't the case here

Why couldn't we offer any set of data usign this function? If you have a peer and you want to send it multiple content items, why can't you use this function?

I will change it's input parameter's then to restrict it more

No change was done to this function (or it's parameters). Why would you rectrict function if it can be broad (without downsides)?

Ultimately, it doesn't matter much, it's just a function name. I think it would be nice if we have both send_offer and send_multi_offer and they behave similarly.

Well this function can't be used to gossip not ephemeral content, and there is no justification to added support for that. It isn't a priority and this function can't be used on generic content. It requests for random peers. send_multi_offer would require logic we don't need now, this clearly isn't a 1 line change.

morph-dev · 2025-05-24T20:07:54Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

+
+    /// The finalized state root should be for a finalized period. The beacon blocks passed in must
+    /// be contained with that respective period's block roots to be provable.
+    pub async fn gossiped_proven_headers(


If I'm not mistaken, this would start close to 8192*2 gossiping tasks.
I'm worried that all these tasks might starve the offer permit semaphore, especially because semaphore is fair. Meaning, we might not be able to gossip ephemeral content for some time.

Instead, we could do one of the following:

send this content sequentially (it will take longer)

use different semaphore

What do you think?

I did the third non-listed option of using a future stream then buffering the futures, which will basically rate limit it so only X futures can run at the same time.

sequentially
this one isn't good

semaphore
There are many ways this could be implemented using semaphore, so the suggestion is too broad for me to make any direct statements.

Anyways let me know what you think

I think that you implementation doesn't work as you want it. I tried it in simplified form here:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f9efd12f88caac5f19a20c9e2b8a1310

The reason is that because we have tokio::spawn, background task will start as soon as it's called (not when it's buffered).

Your simplifed code isn't the same as our code hence it gives an invalid result. I updated it so that tokio::spawn is awaited in the function called and it works as expected https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5acc022e9180d573e1e0b4769a2377da

We talked on the call, and I did have an oversight in my implementation. After discussion using a semaphore makes the most sense, so I implemented it.

KolbyML · 2025-05-25T03:42:17Z

@morph-dev ready for another look, let me know if I missed anything

morph-dev

I think that buffered futures doesn't work as you are expecting. Happy to have a call and discuss it.

Other than that, no big concerns.

bin/portal-bridge/src/bridge/ephemeral_history/ephemeral_bundle.rs

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

morph-dev · 2025-05-27T10:20:35Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

+        let mut bodies = vec![];
+        let mut receipts = vec![];
+        for (header, body, receipt) in ephemeral_bundle.blocks {
+            bodies.push((header.hash_slow(), body));


nit: maybe calculate header.hash_slow() once and reuse?

morph-dev · 2025-05-27T10:41:24Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

+            .collect()
+    }
+
+    async fn send_offer_with_header_series(


I'm not sure I understand your arguments, can you elaborate more?

Multi offer would imply you could multi offer any set of data which isn't the case here

Why couldn't we offer any set of data usign this function? If you have a peer and you want to send it multiple content items, why can't you use this function?

I will change it's input parameter's then to restrict it more

No change was done to this function (or it's parameters). Why would you rectrict function if it can be broad (without downsides)?

Ultimately, it doesn't matter much, it's just a function name. I think it would be nice if we have both send_offer and send_multi_offer and they behave similarly.

morph-dev · 2025-05-27T11:15:46Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

+
+    /// The finalized state root should be for a finalized period. The beacon blocks passed in must
+    /// be contained with that respective period's block roots to be provable.
+    pub async fn gossiped_proven_headers(


I think that you implementation doesn't work as you want it. I tried it in simplified form here:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f9efd12f88caac5f19a20c9e2b8a1310

The reason is that because we have tokio::spawn, background task will start as soon as it's called (not when it's buffered).

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

KolbyML · 2025-05-27T15:55:34Z

@morph-dev ready for another review

morph-dev

Looks good! 🚀

morph-dev · 2025-05-27T18:22:36Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

 }

 impl Gossiper {
    pub fn new(
        census: Census,
        history_network: Arc<HistoryNetwork>,
        metrics: BridgeMetricsReporter,
-        offer_limit: usize,
+        head_offer_limit: usize,
+        proven_headers_offer_limit: usize,


nit: maybe name the variable (proven_headers_offer_limit) and semaphore (non_ephemeral_headers_semaphore) in the same way? Meaning, non_ephemeral_offer_limit

Yeah I missed this when renaming the variables, nice catch

morph-dev · 2025-05-27T18:34:45Z

bin/portal-bridge/src/bridge/ephemeral_history/gossiper.rs

+            let offer_permit = if is_head_offer {
+                self.head_semaphore
+                    .clone()
+                    .acquire_owned()
+                    .await
+                    .expect("to be able to acquire semaphore")
+            } else {
+                self.non_ephemeral_headers_semaphore
+                    .clone()
+                    .acquire_owned()
+                    .await
+                    .expect("to be able to acquire semaphore")
+            };


Suggested change

let offer_permit = if is_head_offer {

self.head_semaphore

.clone()

.acquire_owned()

.await

.expect("to be able to acquire semaphore")

} else {

self.non_ephemeral_headers_semaphore

.clone()

.acquire_owned()

.await

.expect("to be able to acquire semaphore")

};

let semaphore = if is_head_offer {

self.head_semaphore.clone()

} else {

self.non_ephemeral_headers_semaphore.clone()

};

let offer_permit = semaphore

.acquire_owned()

.await

.expect("to be able to acquire semaphore")

KolbyML requested a review from morph-dev May 22, 2025 17:35

KolbyML self-assigned this May 22, 2025

KolbyML mentioned this pull request May 22, 2025

feat: implement ephemeral history bridge #1852

Open

KolbyML force-pushed the add-ephemeral-history-gossiper branch from a8cb9ba to 860fd2f Compare May 23, 2025 15:51

feat: add Ephemeral History Bundle + Gossiper

860fd2f

morph-dev reviewed May 24, 2025

View reviewed changes

fix: address PR concerns

baccf10

morph-dev reviewed May 27, 2025

View reviewed changes

KolbyML added 2 commits May 27, 2025 08:48

fix: address PR feedback

18a7aee

fix: address feedback

63a8531

KolbyML added 3 commits May 27, 2025 10:01

fix: slight rename of semaphore variable

49df3e7

fix: f

bc60f73

fix: clean stuff up a bit

e299c1c

morph-dev approved these changes May 27, 2025

View reviewed changes

fix: addressed concerns

21aa3b5

KolbyML merged commit 4c7897d into ethereum:master May 27, 2025
16 checks passed

Add ephemeral history gossiper #1851

Add ephemeral history gossiper #1851

Uh oh!

Conversation

KolbyML commented May 22, 2025

What was wrong?

How was it fixed?

Work for followup PR's

Uh oh!

KolbyML commented May 23, 2025

Uh oh!

morph-dev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KolbyML May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KolbyML commented May 25, 2025

Uh oh!

morph-dev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

KolbyML commented May 27, 2025

Uh oh!

morph-dev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

KolbyML May 27, 2025 •

edited

Loading