Against the backdrop of The Situation, many of us have been trying to turn it into opportunities when we can. For me, this meant ramping up my fitness levels. We at Digital Asset went fully remote in March 2020, and at the start of April, I committed myself to foster good habits and dropping bad habits, starting by working out every single day and eating healthily.
That lasted about two weeks.
Since then, I’ve been off and on the wagon, managing to keep myself running and lifting weights for a week or three, only to lapse for a few days. Sticking to a habit has always been difficult for me (and everyone else), so my partner and I have been throwing around ideas for apps to keep us motivated and focused.
Of course, being a DAML junkie, once the ideas had taken root, my next thought was, “How do I model this with smart contracts?”
Over the course of the exercise, I learned about implicit trust assumptions in my code and how DAML makes it convenient to describe workflows that keep things honest. But I’m getting ahead of myself. Let’s start from the beginning.
On paper, a habit-tracking system might look like this:
The simplest design I could think of was to model the recording:
This grew a little once I realized I needed to be able to query for the habits themselves in the UI. They became their own contract template:
Now, when I record my exercise, I do my best to track it every day. I don’t want to try and remember whether I did some push-ups on Tuesday; chances are I’ve forgotten and will just have to make something up. By limiting myself to only tracking today (or yesterday, I guess), I keep myself honest.
The obvious place to put this logic was a choice:
But I had a problem. I started asking myself: “what’s stopping me from just creating a
create, rather than
exercise?” And the answer, “nothing”, wasn’t one I was happy about.
Back to pen and paper
When stumped with a problem in DAML, it’s often helpful to go back to the real world, and think about how we’d solve the same problem there. (This is why we often use paper money to explain the concepts behind DAML and smart contracts.)
I want DAML to help me keep myself honest. But just like on paper, DAML assumes we can trust ourselves. So, if I wanted some help making sure I do the right thing, how would I do this with a calendar on my wall?
After phrasing the question like that, the answer was obvious. I can’t cheat at tracking my exercise, because my partner would notice and call me on it. That logic currently lives outside the system, but with a small tweak, I can re-architect my calendar to represent this:
Modelling honesty with multi-party agreements
Once I had it on paper, it was obvious how the model needed to change. I need to represent the party keeping me honest in the system, and make them a counter-signatory on every recording. This changed my workflow from an agreement with myself to a multi-party agreement, where DAML shines.
I needed a two-phase flow for creating the habit, and I’d also need to create the same flow for a recording.
As you can see, Alice now needs a signature from Bob to create a recording, fulfilling our goal of keeping ourselves honest (with help from a friend).
This is under development, and I’m now working on the UI. You’re welcome to check out my progress on GitHub.
What I learned: trust in real-world distributed systems
DAML makes these trust relationships explicit. This may be a simple example, but it forced me to encode the approval process in my household that I had taken for granted. By doing so, I gained some power over the process, and I’m now able to make changes to it to better fit my needs in the future.
The concept of trust isn’t one we think about with simple applications such as this one, but it’s there nonetheless. In a conventional web app, the job of accepting or rejecting my recordings would fall to a centralized server (or cluster of servers, running identical code), which would have similar logic as above.
However, there are plenty of use cases for blockchain or distributed ledger technology, where relying on a central authority is dangerous. For example, if the server goes down, I can’t track anything at all, potentially losing my 100-day streak. (This almost happened to me last week with Duolingo.) Or perhaps I don’t agree with the rigid requirements set by one authority, and I’d rather work with a different one, with a different set of constraints.
DAML offers us a set of tools to solve problems like this explicitly and conveniently. While there would be nothing wrong with using a single “operator” party for all users of my habit-tracking application, I know (and my users know) that we have the option to switch to a distributed model in the future.
We can foresee a future where I’m recording my runs on two ledgers at once: one controlled by Strava, which automatically verifies that I ran, and one which is manually checked by my partner, for redundancy. By distributing and replicating this data across ledgers with the Canton protocol, I could make sure that even if my running tracker of choice goes down, my exercise is still recorded.
DAML doesn’t stop you from lying to yourself, because that doesn’t matter. It just stops you from deceiving anyone else. The ecosystem really shines when we recognize that almost all situations involve more than one party, and model not just the mechanics, but the network. DAML has also a new learn section where you can begin to code online: