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?
Log in to comment and vote
Comments4
sssngth
Aug 5, 2024
Hi Robert,
thanks for your reply and please excuse the lack of clarity on my end.
When I search for proposed blocks obtained from relays not approved by the Lido Relay Maintenance Committee (RMC), one of my first places to look is the aforementioned Fees Monitoring Dashboard.
However, even among the slots with relays labeled “unknown”, which stick out by being highlighted in red and that normally indicate a situation such as a relay misconfiguration, I could not find a block proposed by Kiln that produced a response by the Titan relay API.
E.g. 9652481
It was only when Kiln shared some slots that they used the multi signature approach on that I was successful in identifying otherwise inconspicuous blocks that I could receive a response on by Titan - and the APIs of the other relays Kiln had sent the signatures to, including the relay they actually obtained the block from they later proposed for the specific slot, but which wasn’t Titan.
Now I wonder if e.g. for 9590392 on the Rated explorer not only Flashbots was registered as blockspace but all relays that answer to a query for the slot:
Slot 9590392 found in relays: ['https://bloxroute.max-profit.blxrbdn.com/', 'https://bloxroute.regulated.blxrbdn.com/', 'https://boost-relay.flashbots.net/', 'https://titanrelay.xyz/']This could explain why Kiln is listed with such a relatively high percentage of Titan blockspace, while at the time of writing I believe they didn’t actually obtain a single block they proposed for Lido from Titan.
Robert Tiong
Aug 5, 2024
Hi @sssngth! Thanks for writing in. :)
To clarify, are you saying that you’re not able to independently verify certain slots as coming from the Titan relay by using their data API? And that such examples of these slots are the ones you mentioned (i.e. 9590392, 9589936, 9589912)?
Do correct me if my understanding is wrong because I’m checking the same endpoint right now on those slots and there is a response being returned when querying for those slots (example: here). This is the same endpoint we use to collect data.