Schedule of work
Like Jehan says, several of the items in our roadmap are closely integrated. I’ll speak to the maintenance (both Gaia and ICS) and testing components since those are the ones that have a clear schedule.
This is a quarterly schedule for two releases per quarter, equating to a total of eight releases over 2024. At this point, we can’t predict or commit to exact features or core tech version updates for each release – we don’t have the information necessary to make those decisions or estimates yet.
Similarly for ICS support at Hypha, we can’t accurately predict how many chains we might be onboarding (however, we expect this to be in the range of 2-5). For a sovereign-to-consumer transition rehearsal, this is what our schedule looks like:
This work occurs for every rehearsal and must fit into the continuous Gaia release cycle – launch rehearsals, Gaia upgrades, and mainnet upgrades all happen on Wednesdays in approximately the same 15:00 UTC time slot to reduce coordination overhead. We have approximately a two week process for a launch rehearsal.
As part of ICS maintenance and testing, Hypha onboards incoming consumer chains to the Hub’s Replicated Security testnet. Each launch rehearsal has a runway of at least two weeks during which Hypha is on-call and supporting consumer chains both in putting together their Replicated Security chain parameters and approaching the Hub governance process. Hypha works most closely with consumer chain teams during the onboarding process, and then again at mainnet launch when we are on-call alongside the Informal Hub team to troubleshoot, debug, and support their launch on the Cosmos Hub.
Testnet Wednesday events include Gaia upgrades, consumer chain upgrades, consumer chain launch rehearsals, and consumer chain sovereign-to-consumer transition rehearsals. During sovereign-to-consumer rehearsals, Hypha works closely with the consumer chain team and testnet validators over the course of two hours for a coordinated launch.
Our testnet work is measurable less with a deliverable and more with the operational smoothness experienced by validators and the incoming consumer chains onboarding onto the Hub. However, we do publish our Testnet Wednesday reports here on the Hub forum.
KPIs
Testing and maintenance have the overall goal of steady, consistent progress in the development of the Hub. We propose these as metrics for measuring against that goal:
- Smooth upgrades measured in time per upgrade
- Testnet operational smoothness measured in time taken every Testnet Wednesday
- Testnet participation measured in validator participation during upgrades and consumer chain launches
- Quality of learnings measured in testnet reports
Headcount
Hypha’s current headcount is all focused on the testing and testnet line item. If we work strictly on testing, our 2024 headcount would be 2 - 3 FTE. Over 2024, we plan to be more involved with Gaia maintenance and release integration work, which would push our headcount to the upper end of our estimation (3 - 4) as we take on tasks such as release integration.
On Hypha’s side, all the FTE funded by this proposal are working directly towards our KPIs as eng/ops. We aren’t funding separate marketing or BD out of this budget, though the rate does include general operational expenses.
Ongoing funding and oversight structure
Like Spaydh says, the overall format of core development funding on the Hub is probably going to take many iterations of experimentation. Between RMIT’s recent essays on ICS governance and Noam’s DRIP proposal, there are lots of really interesting directions to investigate.
This is one of the reasons that our proposal is only for a yearlong funding period – by the time we are making a second proposal, research in this area will likely have progressed and we’ll have more options.
Direct responses
Can you please explain how Informals proposal and Notionals proposal differ? Or is this a ‘double spend’ for this area?
- Rarma
Afaik (and Lit or Jacob can chime in here to correct me if need be), Notional’s scoped work is:
- Monitoring the Hub for vulnerabilities
- Coordinating with Hub teams to produce a security patch and assist in rollout
- Advising core teams of issues in upcoming releases for safety or liveness
- Improvement and development of products like the Hub
Monitoring the Hub is something many teams do, and it’s good for many teams to do this. There’s warranted overlap here. Similarly, improvement and development of products like the Hub has some overlap - it’s an open source repo and many people contribute to it.
However, the other items involve coordinating or advising the core Hub team (that’s us right now). We work with the Notional team on identifying and resolving issues that affect the Hub. For example, Notional has recently been doing security testing using the testnets operated by Hypha and we have been closely in contact throughout this process and potential resolutions for it on the Hub.