Add address rewards metadata

[Doy-lee]

This adds some new fields to the rewards DB.

Batched Accrued Rewards

• lifetime_locked_stakes
• lifetime_unlocked_stakes
• lifetime_liquidated_stakes
• lifetime_rewards

These numbers expose some more metadata on what exactly is the composition of the amount value (which is rewards + unlocked stake) into separate fields. You can calculate how many tokens are actively locked in the network (lifetime locked - (lifetime unlocked + lifetime liquidated)) or see how many rewards an address has earnt (lifetime_rewards) or how much has been liquidated from the address (lifetime_liquidated).

I've updated the get_accrued_rewards to return a struct now which has all this metadata plus more. It's basically all documented in the API

struct wallet_info {
        uint64_t height;  // Height at which the wallet info was retrieved for

        // True if the wallet has participated in the network or not. When false all values are
        // zeroed (because the wallet has not earnt or spent any tokens on the network).
        bool found;

        // For OXEN addresses, rewards that has been accrued but not paid out to the address yet.
        //
        // For ETH addresses, lifetime rewards _and_ unlocked stakes for the address. (Note that,
        // unlike Oxen addresses, these rewards never reset to zero; but rather the rewards contract
        // keeps track of the current paid and current total and pays out the difference).
        //
        // For ETH addresses, this can be derived by
        // `lifetime_unlocked_stakes + lifetime_rewards - lifetime_liquidated_stakes`
        cryptonote::reward_money amount;

        // For ETH addresses _only_, the total amount of tokens that were locked by this wallet and
        // so forth for lifetime unlocked, rewards and liquidated amounts.
        cryptonote::reward_money lifetime_locked_stakes;
        cryptonote::reward_money lifetime_unlocked_stakes;
        cryptonote::reward_money lifetime_rewards;
        cryptonote::reward_money lifetime_liquidated_stakes;

        // For ETH addresses _only_, the amount of tokens currently locked in the network (e.g.
        // staked in a node). This is defined as `lifetime locked - lifetimed unlocked` and
        // precalculated for convenience. This number includes `timelocked_stakes`.
        cryptonote::reward_money locked_stakes;

        // For ETH addresses _only_, the amount of tokens awaiting to be unlocked from the network
        // (e.g. an exit has been processed and the stake is under a time lock before being
        // claimable by the address)
        cryptonote::reward_money timelocked_stakes;
    };

The way this is achieved is by simply storing the result of the ETH transactions that we confirm and witness and feed it down into the rewards DB where it enumerates them together. These new fields don't kick in until the ETH hardfork so they're all gated and should return 0 if queried before then. This way collecting this metadata only needs to happen on the ETH code path instead of also requiring to work on the OXEN path.

Since it's gated, this will only trigger a rescan on stagenet which has 50k blocks. Since the new fields are written on the ETH hardfork there'll be no rescan needed for mainnet. It'll just gracefully start enumerating the fields when the hardfork elapses.

This does overlap with the Oxen 10 backwards compat fix that was recently patched. I had to patch ontop again to preserve the old behaviour. For Oxen 11, I just made it support parsing the new wallet_info struct that we return in the RPC call.

The get_accrued_rewards now returns something like this

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "balances": [
      {
        "address": "0x26b0227617159797b9301a8EA6FB264f17d37Cb4",
        "amount": 181398273044375,
        "found": true,
        "lifetime_liquidated_stakes": 240000000012,
        "lifetime_locked_stakes": 270774959746030,
        "lifetime_rewards": 8985313298357,
        "lifetime_unlocked_stakes": 172652959746030,
        "locked_stakes": 98122000000000,
        "rewards": 8985313298357,
        "timelocked_stakes": 18122000000000
      }
    ],
    "height": 50062,
    "status": "OK"
  }
}

[darcys22]

Nothing in consensus or in the chain should be affected by this right? Like this should sync independently and then we have a machine that will output the right locked amounts?

So we could test this by simply attaching it to the portal backend server and using these new RPC endpoints?

[Doy-lee]

Yeah that's the intent, if that all looks gucci, I will get this onto canary and Ryan can test using these numbers, which makes it not really urgent at all for merging and so forth.