Summary

We think it’s worth sharing a behind-the-scenes look at our ongoing journey to release HoloFuel for public testing. This glimpse into the debugging process will give you insight into the things you might need to think about when you’re designing and testing your own hApp. In this special Dev Pulse we have a part 2.

Challenges endured and wisdom gained building and testing HoloFuel

If you’ve been following Holo host news, you’ll know that we’ve been promising a HoloPortOS update with a working admin dashboard and a test version of HoloFuel for about a month. Every week, we get excited about the impending update, get a release announcement ready… and discover another blocker or two. Why is this taking so long, you might ask?

Many of us in the org are software development veterans. Our developers and project leads have been chosen for their wealth of wisdom, gained from years of working with large and small software projects. Many of these projects were quite demanding. Even with all this experience, it turns out that building Holochain is more complex than, and simply different from, what we’ve faced before. And rightly so, because we’re building something that tackles problems in new ways. We’re not newbies, but we regularly feel like we are.

In sharing the specifics of what’s blocking a HoloFuel release, we hope that you’ll learn from our experience and use it as a guide in your own hApp testing process. By choosing Holochain, you’re putting your faith in something quite unique, which comes with risks. We acknowledge that, and we’re grateful for your boldness. Even with a rich body of literature on eventual consistency, distributed systems, and cryptographic data structures, you’ll likely be facing design problems that nobody else has faced. So as we learn the best ways of developing and testing hApps, we want to make sure that our learnings bear fruit beyond our teams.

In recent internal tests, HoloFuel would work great for the first day, then performance would slow down. Existing participants would try to verify a transaction by contacting its authors, then timeout and get stuck in a holding pattern. Investigation showed that it was due to the behaviour of HoloPortOS after an upgrade: the HoloPort owner’s source chain would get cleared, but their key would remain the same. Often, the upgrade only contained UI fixes, which meant that the HoloFuel DNA hash (and hence the DHT) persisted between updates. This would cause the user to create a new source chain with the same ID.

If you know about Holochain’s data integrity, you know that this breaks the rule that says an agent’s source chain must not branch, because that would create alternate histories and ruin the integrity of the system. But because the HoloPort simply forgot its old source chain, it created awkward situations like:

Validator: “It says here that you committed a transaction with Alice yesterday. Could I get the rest of your source chain so I can validate the transaction?”
HoloPort: “What? I don’t know anything about that; I just joined this morning.”
Validator: “Well, this transaction has your signature on it, so...”
HoloPort: “...”
(a short time later)
Validator: “It says here that you committed a transaction with Alice yesterday…”

These unresolvable conversations eventually ground activity to a halt. We fixed Holochain so that validation would fail if the author’s node can’t produce a validation package. But suddenly, Holochain did what it was supposed to, and marked nearly everyone’s data as invalid.

So we decided to start each testing cycle in a fresh DHT without any history. The simplest way to do this is to change the DNA package so that its hash is different. And the simplest way to do that is to change its UUID field, either in the project’s app.json file or the conductor config. We’re currently working on a way to automate the clean-slate DHT policy to make testing cycles faster.

We’re also working on a fix to HoloPortOS that keeps source chains between updates, which will prevent the source chain conflicts in the first place. This will of course be necessary for live hApps.

Even though this has to do with our work fixing bugs in Holochain or HoloPortOS, we still think that the clean-slate DHT technique could be of use to hApp developers. Here are reasons you might want to create a new DNA hash with every testing cycle:

  • Reproducible context (such as an empty DHT) is important for testing.
  • You’re seeing unexpected behaviour in your hApp, and you’re not sure if it’s caused by bugs in the DNA or issues in the DHT (or even a bug in Holochain itself). In order to isolate the problem, it’s useful to try reproducing the problem with a clean history.
  • Sometimes we might release a Holochain update that fixes outstanding validation bugs, at which point you’ll likely want to bump the DNA hash in both testing and live environments to clean up invalid data.

If a problem in your hApp is caused by bugs in your DNA, you will of course not need to do this when you release a new DNA, because its hash will naturally change as a consequence of the bug fixes.

We’ll share more learnings as we test more hApps in the real world. We want our successes to become your successes!

Lastly, something else we’re very pleased to share is that through this all, our Holochain team has been plugging away to release Holochain v0.0.46, a new Developer Release. Read more about it in Dev Pulse 68 – Part 2.

Development status

Latest

  • Holochain Core: 0.0.46-alpha1 (blessed) | Changelog
  • Holonix: 0.0.72 (blessed)
  • Tryorama: 0.3.3 (blessed)
  • Holoscape: 0.0.8-alpha (contains Holochain Core 0.0.45-alpha1) | Download

Blessed (available via https://holochain.love)

  • Holonix: 0.0.72Holochain Core: 0.0.46-alpha1

Install Holochain Learn about Holochain Join the Discussion