Have something to say?

Tell Rated how they could make the product more useful to you.

Chainnodes - delete old solo staker validators

I brought this up a couple of times and it was partially fixed more than 1 year ago. But there are still remains of the old ether.fi solo staker cluster in the node operator account of Chainnodes. As a background, this happened because we manage the solo staker program and the bidding in 2023 was happening through the Chainnodes bidding account. Thought the validators were never operated by us, instead in a DVT setup with multiple solo stakers (home operators). Later, all those validators from the Chainnodes bidding were added automatically as ether.fi integrated with Rated directly. After a while some of the validators got removed, others didn’t. It’s pretty difficult to list the exact public keys as it’s been a back and forth and I don’t know the exact state. The only thing I know is that we (Chainnodes) have metrics from 2023, which we shouldn’t. The cutoff should be approximately January 2024, which is when we started operating validators for ether.fi on our infrastructure. https://explorer.rated.network/o/Chainnodes?network=mainnet&timeWindow=all&idType=nodeOperator As you can see in our all time metrics, there are some weird up and down metrics before 2024. This should be removed. A very weird thing is that listing Chainnodes as operator under ether.fi shows a different start of metrics (though also not start of 2024), as seen below: https://explorer.rated.network/o/Chainnodes%20-%20Ether.Fi?network=mainnet&timeWindow=all&idType=poolShare This does not make sense as we never added our other customers validators to Rated. Only from ether.fi as they wanted to list on Rated. What I would like to do is remove all validators metrics that were started in 2023 and recalculate our all time scores on our operator dashboard as well as the ether.fi Chainnodes operator dashboard. Please let me know if this is clear enough. I am available on Telegram for verification. We are in touch with multiple members from Rated but were asked to post this question on the Forum.

koraykoska_chainnodes 10 days ago

3

💡 Feature Request

Completed

Consensus Client Distribution for "Lodestar"

Previously, the Rated explorer would be able to detect Lodestar clients on the network. As of today, this is no longer the case as we know with certainty that ChainSafe is running 100% Lodestar as part of its staking setup: https://explorer.rated.network/o/ChainSafe%20-%20Lido?network=mainnet&timeWindow=30d&idType=poolShare If Rated uses Sigma Prime’s Blockprint API to identify client usage, there was a bug that was fixed when graffiti standards changed by default via https://github.com/ethereum/execution-apis/pull/517 and the regex detection mechanism was fixed on Blockprint via https://github.com/sigp/blockprint/issues/36. We want to ensure coverage of Lodestar is accurately represented on your explorer, thanks!

Philip Ngo About 1 month ago

3

🐞 Bug Reports

Completed

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?

sssngth 8 months ago

4

🗣️ Forum