SSV has great properties to anchor it to ETH mainnet trends but balancing productization and tokenomics is a significant challenge. The utility of the token itself may be desirable to expand for the sake of stability, but consciously that can hurt productization because of the risks acquired. Please hear my comments in the context of tokenomics, where an economy of money is the first priority and an economy based on that money’s velocity, ie operation and utility, is the second priority, if not tied for first.
Through our discussions, I’ve cited a handful of considerations that I find valuable, mainly dynamic self adjustment, where an epoch would map a scope of time for each validator (not each operator) and the DAO would have a cadence of access to change the epoch, but no requirement to regularly attest any config/network:
In this equation, we see a ratio of activity rolling in ETH validators joining and leaving the network, a ratio of valid/invalid signatures of an operator threshhold, and an inclusion of ETH gas at the base and [up to the] burstable block size of 30M gwei. This ensures that large blocks would not harm the SSV network over time, where validator costs could increase without SSV incentives/changes. Additionally, I believe this would mitigate some volatility as long as the main epoch is 30000 blocks or less, approximately 100 hours. The “minimum viable signatures” could be maintained with broadcasts or a series of parties responsible for segwit, likely the validators/operators of last resort.
I believe this is worthwhile but I’m not sure how to manage the mini-epoch where validators would need to add a module for caching/reading messages at the point of round change (so that they can maintain validator joining/leaving stats), meaning that no SSV reward would be feasible until that broadcast was observed. I’m being honest about my unknown unknowns here: if there’s any broadcasts from ETH or SSV that note a validator joining or leaving that should satisfy the requirement as long as the mini-epoch is ≤50% smaller than the epoch in the right side of the equation.
ETH block headers are a lightweight recommendation to consider [for validators to monitor/cache/trust] but it hasn’t been confirmed what hardware requirements would be needed for gaslimit and gasused to be monitored over a larger number of blocks (30k??), or by a sequence of roots from prior blocks the size of the mini-epoch.
Other concepts were lightly discussed/dismissed, including but not limited to:
-adding a second identity value to SSV operators for future tagging and obfuscated data tooling (opt-in)
-requiring buyers of last resort to run a minimum of 3 validators, granting them special treatment for offnet engagements with a foundation (central planning not recommended)
-requiring other values from ETH block headers and calculating a “stability ratio” somewhat like the equation above, but with price replaced by a “network health” number (too big of a businees/value pivot). I’m wording this poorly but it’s the idea that user/operator stats on ETH could be provided by SSV before that data is visible/settled on ETH, however that would be data visible to all SSV operators, a dicey thing for a[ny entity like a] central planner. Realistically, the foundation could pivot on this model and become compliant as a central planner and arbiter if desired, but we don’t recommend that for longevity sake, and recommend similar options be discarded.
-participating heavily in EVM testnets to support buyers of last resort (socially confusing, not recommended)
-prepositioning to incoming EIPs, for example, offering summary stats from abstracted mempools and getting rewarded for relaying that to other operators who opt-in to that data from other offchain mempools (EIP too new, risks unclear)
References:
-A Platform Architecture for Multi-Tenant Blockchain-Based Systems, 2019
-ETH foundation gas, fees, blocks, etc
-relevant posts