Busy few days and we’re behind on posting, so wanted to scratch down a few notes so those that are staking with us understand some of the things going on behind the scenes.
Our goals for the Shelley Testnet phase are:
- Primary: help IOHK and the community get the CSL (Cardano Settlement Layer) software behaving correctly prior to putting real money on it
- Close Second: maintain as close to 100% fully-operational uptime for the StakeHodlers stake pool during the testnet phase, given the current and ongoing state of the CSL (currently jormungandr; later the Haskell-based node). Note that fully-operational uptime is much different than just uptime. The testnet is going well, but there are definitely problems that we’re wrestling with as a community.
- Third: education and communication… while there are larger technical issues to resolve, education and communication will need to take a back seat. We are a small operation and need to be smart about applying available resources. We don’t want to drop any of these goals, but there will be times when they are far from being in perfect balance. This is one of those times…
This is a very complex project, and we are all part of it in some way. It is perfectly fine to state reality (today was a frustrating day, for sure), but try not to criticize unfairly, especially if you’ve never been in a project like this. Many folks are losing sleep; harmony at home, and other important aspects of their lives so you, the community, can eventually enjoy a robust financial ecosystem that greatly improves upon our current state of affairs. Progress drives the world forward, but it comes with both costs and great sacrifices by a few, that tend to benefit the many. (We’re mostly referring to the developers at IOHK here. These Engineers are working very hard on some very complex stuff. Solutions to problems in this space don’t just magically appear. They require lots of work; often a tremendous amount of time and brainstorming, and real dedication. Their teams are working exceptionally hard, and we should each thank them as the opportunity presents itself.)
This is a marathon; not a sprint. Well, those who follow Scrum may argue…
Without getting into the details, IOHK reportedly follows something called Scrum, which is a development methodology. This can concisely be defined as “inspect and adapt”, or “fail fast”. This applies to process as well… not just software and systems. In a nutshell, that is what they are doing: release the software that runs the CSL, and when something is discovered that is broken, change it and release new software. Same with process — listen to the community and change what is not optimal or downright broken. Quickly! Rinse; lather; repeat. There are plenty of studies that show that this is the quickest way to get to a mature, robust system. The IOHK teams are operating in a very smart manner.
Testing community-behaviors (part of IOHK’s stated goals, as espoused by their Marketing Director, Tim) is impossible prior to actual release to the community. That’s why IOHK has created the testnet, and that’s why they’re providing incentives for participation. Things will continue to break until they don’t. This is expected for a project this ambitious; complex, and widespread. The community of stakers; stake pool operators, and developers must work together to yield the best final result. It will come, but we must have reasonable patience.
Things under investigation at StakeHodlers:
- Best monitoring strategy/automation? This is heavily needed while the CSL is not fully stable, and it should be much less needed as the testnet forces the software through a maturing process. Automation is not the best place to create robustness, but it’s the best we’ve got at the moment. If you care to look at some of the nitty gritty detail, here’s an example issue filed with IOHK: https://github.com/input-output-hk/jormungandr/issues/1470 … and another: https://github.com/input-output-hk/jormungandr/issues/1468 .
- Running on non-cloud infrastructure (see comments in item 3);
- What mix of cloud/non-cloud provides the best resiliency, while still allowing the community the freedom to maintain the decentralized nature of the Cardano blockchain? Cloud provides economies of scale; ease of use; and helpful redundancies, but there’s a significant amount of decentralization we give up for those usability/efficiency features. Then again, ultimately, network bandwidth is still largely under central control, and probably will be for a long time. Each option has pros and cons, and we’ve been running back and forth on both, trying to figure out the nuances of each for this application…