[GraphQL] Fix APY for a validator

[stefan-mysten]

trafficstars

Description

This PR fixes the APY for a validator and ensures that historical APYs can be computed. It also reverts some changes in the governance_api, particularly moves exchange_rates as a free function that can be called from the GraphQL crate.

At system start, the task to trigger the exchange rates cache is executed, thus until the next trigger on epoch change, the apys can be fetched pretty fast (~2-3 for the standard 5 items per page).

Long term: switch to a data-loader, but I cannot wrap my mind about how to do it just yet.

Test plan

Updated test. Manual tests and queries.

Response time: ~1s

{
  epoch {
    epochId
    referenceGasPrice
    validatorSet {
      totalStake
      inactivePoolsSize
      activeValidators(first: 5) {
        nodes {
          name
          apy
        }
      }
    }
  }
}

{
  "data": {
    "epoch": {
      "epochId": 405,
      "referenceGasPrice": "751",
      "validatorSet": {
        "totalStake": "8163113083622628156",
        "inactivePoolsSize": 4,
        "activeValidators": {
          "nodes": [
            {
              "name": "ComingChat",
              "apy": 310
            },
            {
              "name": "InfStones",
              "apy": 302
            },
            {
              "name": "Gaucho",
              "apy": 310
            },
            {
              "name": "Astro-Stakers",
              "apy": 310
            },
            {
              "name": "H2O Nodes",
              "apy": 310
            }
          ]
        }
      }
    }
  }
}

Response time for this query: ~2s

{
  epoch(id: 127){
    epochId
    referenceGasPrice
    validatorSet {
      totalStake
      inactivePoolsSize
      activeValidators {
        nodes {
          name
          apy
        }
      }
    }
  }
}

{
  "data": {
    "epoch": {
      "epochId": 127,
      "referenceGasPrice": "765",
      "validatorSet": {
        "totalStake": "7437800674887300328",
        "inactivePoolsSize": 2,
        "activeValidators": {
          "nodes": [
            {
              "name": "ComingChat",
              "apy": 480
            },
            {
              "name": "InfStones",
              "apy": 471
            },
            {
              "name": "Gaucho",
              "apy": 471
            },
            {
              "name": "Astro-Stakers",
              "apy": 485
            },
            {
              "name": "H2O Nodes",
              "apy": 471
            }
          ]
        }
      }
    }
  }
}

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• [ ] Protocol:
• [ ] Nodes (Validators and Full nodes):
• [ ] Indexer:
• [ ] JSON-RPC:
• [ ] GraphQL:
• [ ] CLI:
• [ ] Rust SDK:

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 31, 2024 1:55am

[vercel[bot]]

@stefan-mysten is attempting to deploy a commit to the Mysten Labs Team on Vercel.

A member of the Team first needs to authorize it.

[emmazzz]

From local tests, this was still a bit slow because I did not spin my own indexer with the new changes, so not sure how it will actually fare in a prod env.

From my experience, calculating the APYs has always been slow at the beginning of the epoch due to all the dynamic field loading and calculation but it's only the case for the first time of the epoch and will be cached later, so we were okay with this slowness.

[stefan-mysten]

From local tests, this was still a bit slow because I did not spin my own indexer with the new changes, so not sure how it will actually fare in a prod env.

From my experience, calculating the APYs has always been slow at the beginning of the epoch due to all the dynamic field loading and calculation but it's only the case for the first time of the epoch and will be cached later, so we were okay with this slowness.

You're absolutely right. It takes roughly ~40-50s for the first query to finish, so it times out. This is not ideal, so I think the plan is that from GraphQL side we'll kick the exchange_rates function on epoch boundary to get that cache. One step at a time, I will work on that after this PR.

[stefan-mysten]

I will merge this now, and then revisit it once we decide what to do with this API.