Define and review the interface of the stake table

[sveitser]

interfaces need to support:

READ:

• stake table commitments (for the Snapshot::LastEpochStart and Snapshot::EpochStart)
• total stake and total number of participants/keys
• stake lookup (fine-grained results maybe through multiple getters, one returning actual owned amount, the other returning voting power with delegated included)
• registering and exiting queue info,

WRITE:

• register (batch?)
• deposit (you can deposit more once register)
• exit (signal your withdraw intent and get queued)
• withdraw
• delegate/approve
• disapprove

[alxiong]

There is an important aspect left unspecified so far:

How to interpret overall voting weight from dual-staking

In contract (see #748 ), we specify the dual-staking interfaces where validators can stake both native token and re-stake ETH.

In stake table module (see impl here), we only attach a single amount: U256 field to each staker.

This bears the question of the deterministic derivation function to compute this final effective voting power (i.e. the amount value in hotshot-stake-table)

There are some potential caveats I can think of when designing it:

• if the exchange rate between the two tokens are market rate (e.g. based on chainlink/DEX price oracle), then the rate cannot be updated more frequently, or else even honest replicas would disagree on the rate.
  • There better be some consensus on this rate -- implying we should add voting on this value into HotShot consensus
• if the exchange rate is flat/fixed, and only updated very rarely (once every contract update/hardfork), then this leaves high uncertainty on the opportunity cost due to capital lock-up for the stakers.
• tricky thing is, apart from the exchange rate variable, the weight computing function itself could also be updated, thus we need to come up with some future-proof and easily upgradable design

Concrete TODO

IMO, since we plan to launch without dual-staking, this is not a high-priority issue.
But we should think about forward comptability/upgradability issue now.

Concretely, I propose the following for now:

• add trait/API for a separate module/crate called middleware-stake-table
  • this used to be a part of the monolithic "prover service" under hotshot-state-prover (see [hotshot-state-prover] Define Prover Service API HotShot#1987), this is currently designed to be an API from the hotshot-query-service and now I suggest we separate it out as its own crate.
• add a default implementation which reads from L1 and only accept native token and directly populate the amount as the native staked amount as we need for the mainnet launch

cc @fkrell @philippecamacho @chancharles92 @mrain @jbearer @sveitser

---

Current decision

keep it simple and only read native stake for now, keep a single implementation at any time.
Leave weight computation for dual-staker to future iterations.

[jbearer]

I agree with only reading native stake for now, since it will be a while before we have restaking implemented. I'm not sure we really need to do this reading through a trait, since we never plan to have more than one implementation at the same time. I think we can just directly implement a function to read the stake table from L1, for now it will only return native stake, later we will change the implementation to read both stake types and combine them.

[alxiong]

I'm not sure we really need to do this reading through a trait, since we never plan to have more than one implementation at the same time

true. but I suggested that with "future upgrade" in mind. I was hoping a trait would help ease the migration. but maybe too many abstraction also complicates code.

Alright, then we keep it simple for now then.