Greenfield vs. Brownfield Horizon

i.e. could we "Horizonify" the current protocol?

https://whimsical.com/horizon-simplified-diagram-HqtZJqAvsF8v9i2hLgmqi7

What would this achieve?

Could we take the current Staking contract and make it evolve to be as close as possible to what HorizonStaking is meant to be?

The main desiderata are:

• Removing centralization points, or at least re-scoping them so they only act at the data service level (C)
• Making all stake and delegation effectively contribute to economic security (S)
• Remove some inefficiencies or waste (instances where tokens spent / burnt / minted do not contribute as much value as they could) (I)
• Allow data services to be added permissionlessly and make all relevant roles permissionlessly configurable (P)
• Make the protocol easier to extend and expand (E)

Note we identify each with a letter (C, S, I, P, E) to mark in the changes below which ones contribute to each desideratum.

Also note I’m not proposing making Staking behave exactly like the Horizon design we have discussed so far, but to make the minimal set of changes to reasonably meet these desiderata like Horizon does. Going forward I’ll call this the “brownfield Horizon” approach, versus the “greenfield Horizon” that would be created from scratch.

But the resulting protocol should have the properties originally described by Zac in:

• Deploy DIPs alongside the existing protocol (P, I, C)
  • This allows anyone to pay for indexing a subgraph even if rewards are denied or if curation is insufficient
  • It also provides indexers a new source of income and a way to predictably charge for indexing services
  • No need for a new staking mechanism, just use allocations (see below)
• Make delegation slashable (S)
  • Should be a straightforward GIP and update to Staking and DisputeManager (more political than technical lift)
  • When slashing, if an Indexer is out of funds, slash from their delegation pool
  • This means the chances of a delegator being slashed are actually very low, and this should be made very clear
• Allocations used as slashable stake for DIPs and query fees (S)
  • Currently there's a fixed slash percentage from total stake per dispute
  • DisputeManager could allow arbitrator to set a per-dispute value as multiple of the disputed value, and slash up to the allocated stake
  • We might need to tweak thawing periods and withdrawals to prevent over-allocations - e.g. only being able to unstake/undelegate tokens that are not currently allocated
  • Gateways should use allocation size as the a-priori measure of economic security
  • DIPs can therefore reuse the POIs posted when closing allocations
• With slashable delegation, delegation tax can be zero (I)