Method of blockspace distribution detection

Dear Rated team,

I am a contributor to the NOM workstream of the Lido DAO and thus especially interested in your dashboards concerning our modules.

In the overview of the Curated Module I noticed that you listed severals NOs who the explorer claimed had obtained blocks from unvetted Titan relay in the past 30 days.
I was able to confirm this for all but one NO by comparing the slots in which the blocks had been proposed with the relay’s API.
Normally such blocks stick out in our own Fees Monitoring Dashboard as being from slots of an “unknown relay”. What was unique for the NO in question, is, that unlike for the other NOs, for none of this NO’s unknown relay slots I could produce a query that was responded to by the proposer_payload_delivered endpoint of the Titan - or by any other of the APIs of widely known relays - making me fairly certain we are looking at locally built “vanilla blocks”.

But then, where does the Titan relay blockspace you listed for the NO come from?
We got in touch with them - Kiln - and were told that while they do not call the getHeader methode for Titan for blocks available on multiple and ultimately obtained by a different than Titan relay. They do, however, systematically send signatures to all relays, including Titan, to improve the propagation time.
Some examples of such slots that then produce responses from several relays are: 9590392, 9589936, and 9589912

Is it possible that this approach is messing with your methode of collecting the blockspace distribution, listing the blockspace for all of the responding relays?

Please authenticate to join the conversation.

Upvoters
Status

Completed

Board

🗣️ Forum

Tags

Explorer

Date

2 months ago

Author

sssngth

Subscribe to post

Get notified by email when there are changes.