Hi, Zantetsu from Shinobi Systems validator here. I am heavily involved in Solana consensus issues; it’s no secret that I’ve been using voting performance improvements in my validator for years now. Anyone is welcome to question this approach - but if you do so, please provide some evidence of any measurable metric on which these modifications are in question.

That being said, there is a new-ish (in use for a month or so now) way to “cheat” vote credit displays and it’s in use by StakeHaus and Blocksmith.

This technique involves modifying the validator to not vote in the last 100 or 150 slots in an epoch. This is bad for Solana because it essentially means that the block chain would halt, it’s only because only StakeHaus and Blocksmith do this that it’s not halting Solana. In addition, it means that consensus takes that much longer to reach at the end of epochs because there is less stake participating. And epoch transitions are the time when we need Solana to be the most reliable given already known performance issues around epoch boundaries. StakeHaus and Blocksmith are working against this.

Why would they stop casting votes in the last 100 - 150 slots of an epoch? Because then they get to vote on those slots in the next epoch. And then the vote credits, which are what add up to determine the APY that a validator will achieve in the epoch, add to the next epoch.

The thing is, this is just an illusion. Because when the process is repeated at the end of epoch, those “extra” vote credits will all get offset by votes not cast at the end of this epoch, then being pushed to the next epoch to repeat the process.

However, for almost the entire duration of the epoch, the validator “looks like” it is earning extra credits. That’s why these despicable validators do this. To “cheat” and “look like” they have higher APY than they actually do.

I highly recommend that anyone staking these validators reconsider. There are alternatives that are better or equivalent on any metric you can possibly think of.

To explain again what they’re doing:

Step 1: Stop voting close to the end of epoch

Step 2: Vote on those slots once the next epoch starts. Suddenly the validator looks like it is ~100 vote credits ahead of everyone else who didn’t save up these votes to cast later.

Step 3: Enjoy estimates showing ~0.01% higher APY for the epoch for almost the entire duration of the epoch (a meaningless amount, but it will often move you up one slot on “leaderboards”)

Step 4: At the end of the epoch, repeat Step 1. All the “extra APY” disappears because now your vote credits are returning back to where they should be. Anyone looking at the actual achieved APY in the epoch will see that it did not actually match the estimate that was shown for most of the epoch because of this.

For what it’s worth, stakeview.app is not subject to these games because its estimate for the current epoch APY is a weighted average of what was actually achieved last epoch, and what is estimated for this epoch. But other sites are vulnerable to the StakeHaus and Blocksmith trickery.

EDIT: Also I’ve “de-badged” StakeHaus and Blocksmith on stakeview.app because of this. So you won’t see them listed by name there, only vote account key.

  • FDon1@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    This is a really good post. Has this been brought up in any dev calls? Do you have an idea for a proposed solution to stop this “cheating” attempt