Delphi Dev Diary 0: The Delphi Sessions

In December of 2017, Mark and myself published Delphi: a Mechanism for Staking and Arbitration. The Delphi paper described a system, but did not mention any specific plans for building the system. Mark and I have been slowly hacking away at some EVM code to support Delphi since the original paper was published, and integrating learnings from that work back into the paper, but we have otherwise been quiet.

No longer. This blog post is about the approach we will be taking to productize Delphi ahead of an October 1 release date. In particular it will describe the Delphi Sessions, a three day workshop conducted in mid-May by the Bounties Network and the Cryptosystem Productization Lab teams in which our sprint towards release was planned.

The Delphi Sessions

After the paper was released, Mark and I continued to work on Delphi in, essentially, our spare time. The project was crawling towards some sort of eventual release, but it was clear to both of us that an intervention would be necessary to get Delphi out the door before the end of 2018. We needed to get serious about assigning full-time resources to Delphi, consider the user interaction layers that would need to wrap the EVM components, and figure out a strategy for making Delphi a tenable and convincing means of adjudicating disputes on the Bounties Network. Mark suggested mid-May for an all-hands: the Delphi Sessions.

Delphi is a somewhat involved system to understand, so we devoted day 0 to mapping out user journeys for every aspect of it. This was as useful in ensuring that our teams had a mutual understanding of the system, as it was in helping us identify more concretely what we would need to build. In doing this work, we identified four main narratives that we will need to build compelling experiences around to make Delphi useful: registry curation, stake initialization, claim opening, and claim adjudication.

Registry Curation

Delphi uses token-curated registries to help stakers and claimants discover mutually agreeable arbiters who can issue rulings in disputes.

The first TCR deployed to the Ethereum mainnet had been adChain, just about a month earlier. TCR curation is well-understood mechanically and several generic UIs exist, but the adChain release exposed important new data: that most token holders do not participate in registry curation, and that user interfaces should provide more opinionated structuring around how curation should be done.

Our user journey mapping for the curation system mostly covered the mechanical curation process as it relates to the TCR’s EVM implementation. This was useful for members of the team who had not worked closely with TCRs before, but we will be sharing more information about how we are modifying the TCR 1.0 design to incentivize greater participation in curation, as well as our more structured approach to the curation process, in future blog posts!

Stake Initialization

In Delphi, users can help other people trust them by putting money at stake and specifying some neutral arbiter to adjudicate in financial claims made against the stake should any disputes arise between a staker and some counterparty. This is all straightforward in theory, but in practice there’s more to it: potential claimants need to be able to assess the stake’s suitability prior to going into business with the staker, which means they need to be able to discover that a stake is connected to a particular staker, and get insight into the stake’s properties (when it expires, who its adjudicator is, what token it is denominated in, et cetera). If those properties are not agreeable, the claimant needs a way to communicate their preferences to the staker to try to negotiate a more agreeable stake. And claimants need to eventually be whitelisted by the staker to make claims, ideally in advance of beginning their work.

Facilitating all of that communication and discovery will be a significant design and engineering challenge. Our aspiration is to provide generic, styleable components for web applications to embed that facilitate these interactions, and use those components ourselves to integrate Delphi into the Bounties Network.

Opening Claims and Settling

If Delphi works very well, it should be rare that claims ever get opened. The threat of adjudication should inspire counterparties using Delphi to play nicely with one another. But, of course, to make the threat of adjudication credible, an experience must be built which does enable kicking off the dispute process. In Delphi, there is actually a phase prior to a dispute being brought to the arbiter, called settlement, where counterparties can attempt to hash out their grievances and reach some happy conclusion before either of them need to forfeit arbiter fees.

Imagine a claim is opened, because a staker refused to pay out a bounty to complete some complex task in a software project. The claimant is upset! They worked hard and they want to get paid! In the settlement phase, the staker should be able to communicate to the claimant why they will not pay the full amount relative to what was promised. The staker may have a genuinely compelling reason: perhaps the work submitted was mostly right, but did not exactly adhere to the spec, or something was omitted. A reasonable claimant, if convinced, should be able to settle then for a lesser amount, or come to an agreement to improve or complete the work. If settling seems untenable, either party can progress the claim into full adjudication at any time.

How much work should we do to facilitate those interactions? If we punt it out to email, how do we facilitate the exchange of contact information? What web components do we need to build to allow users to propose, accept, and reject settlements?

Claim Adjudication

While a Delphi stake can specify any Ethereum address as its arbiter, we imagine many users in the early days of Delphi will elect to use a voting contract in which any arbiter listed in the Delphi TCR can vote on which way a claim should be adjudicated. Delphi arbiters participating in voting are incentivized not only to collect information pertinent to a claim, but to share that information with other arbiters by virtue of the Delphi voting contract’s fee claiming mechanics. To say nothing of the mechanical parts of dispute adjudication involving interactions with EVM systems, there is a lot communication and information discovery that needs to be facilitated here, both between stakers, claimants, and arbiters, and amongst the arbiters themselves.

Stakers and claimants can exist anywhere on the Internet, and Delphi components need to support that fact. But where will adjudicators do their work? To launch Delphi, should we provide centralized software and services that facilitate the communications and consensus-making work that arbiters need to do? Should we provide more decentralized client software and push more communications-centric functionality down to the conventional Delphi protocol layer? Is it desirable to provide embeddable web components for arbiter-centric adjudication services, or would that be less useful work?

After the Sessions

We are running development of Delphi around simulations to be conducted on the first of each month. In these simulations we will attempt to work through, in software, the core user flows we are building for Delphi to see where they break down. We will have more dev diaries coming soon, with lots more information about how we are going about answering the questions we discovered in the Delphi Sessions!