www.tomveatch.com / blockchain / index.html

Buy: A Blockchain Protocol

...Some baby steps forward on the blockchain...
By Thomas Veatch

Background

Ethereum promises some things which are indistinguishable from lies to me.

Q: What is a smart contract?
A: "Smart contract" in this space means no more and no less than "an ethereum program".

It's smart because you can code theoretically anything in it (because the Ethereum VM is said to be Turing complete). But it's not necessarily, or usually, or perhaps so far ever, an actual contract, which by the accepted and legal definition is a meeting of minds and a valuable exchange. No meeting of minds is necessarily encoded in an ethereum program nor need there be an exchange of anything much less anything valuable, except the gas to the system, in an ethereum program.

But this promise is attractive, it's not actually madness, it is something achieveable, I believe. So let me try to push things in the direction of something real that meets that promise. To wit:

A Concept

It is possible that a SET of ethereum (or other blockchain virtual machine) programs could implement and track the progress of a purchase and sale event including deliverables and payment as well as pre, post, and side steps like agreement, settlement, and dispute. This makes more sense implemented as multiple programs interoperating through a validated protocol, rather than as a single program. This essay demonstrates and elaborates what I mean.

Motivation

If you send some coin to a seller, you must, to avoid being swindled, use a program on your side to engage in a verified protocol that makes sure the steps of a valid purchase (which includes safe steps back out of it in case of non-performance) are carried out. Otherwise the other side can't be trusted to do the right thing. Your side needs its steps verified. Did you receive the deliverable? Do you have any objection to what you recieved? The other side just wants payment, has no returns policy, might even have no delivery policy.

So, No! If you use the other side's program and sign up for a delivery and send it some money, you are totally not protected. You get screwed, simply enough, and after it happened to me I became more interested in fixing this issue with the ethereum universe. If as a buyer, you don't have your interests protected in a validated protocol, Why do they have to send you valid deliverables that you approve, that met the spec you used to decide upon the purchase? They can just take your money, poof, it's gone, they're gone. Where's the escrow? Where's the adjudication of disputes? Why should you trust it?

Properties of a Solution

Multi-Party: On the other hand if you have (at least) two programs, the seller side and the buyer side, and they carry out a proven-correct protocol of messages, perhaps separately adjudicated by a Judge process which can record the evidence and submit disputes to an outside service, then your interests are protected, and the protocol, which should have ways of objecting to deliverables you don't like, and getting answers in the real world, can be trusted, unlike a one-sided single program that a seller might put forth.

Enforcement: Whereas contracts are enforced by commercial law courts with the police behind them, ethereum programs are enforced by the code itself and the system's strength in fending off attempts to subvert it.

Connection with reality: contracts on paper simply memorialize and structure activities of their parties, they don't even have to be written to be valid, and so they are already connected with reality by residing in the participants and their actions. Whereas connecting ethereum with reality is a great big problem that needs an answer: interledger, oracles, participant report/review, adjudication methods/people, possibly supported by transaction records associated with the particular contract and possibly automatically or near-automatically resolveable. Could be answered by stake value (how?)? By adjudicator reputation? Etc.

Transparency: if the code and event history is transparent, that makes it better than paper contracts which are typically private.

A pop machine is a contract (as Szabo points out), with no recourse except not using it again and thus driving the vendor out of business; it has nonnegotiable terms.

Some contracts are more digitizable, maybe a stock market future contract.

Where to start? With a simple transaction: buying something

An extremely typical contract would be a person to person contract with performance and payment.

So if you wanted to make an actual contract out of an ethereum program, it might follow a schema like this:

Contract MyContract {
...; receive deposit (into escrow); ...; send final payment; ...
}

Requirements

Is that a contract? Hardly. It would at least send some value in at least one direction. But to be more meaningful it should also include
  • -- That the other party gets something too (so it is an exchange!)
  • -- some step(s) showing that the actual parties actually intend the actual purpose For example a correct description of the terms, stored with a record of clicking on "I agree", proven to have been done by each side.
  • -- An adjudication method in case of controversy
  • -- Perhaps a "delivery complete"; accept/reject loop to precede adjudication
  • -- might not be bad to have an adjudication data collection/storage function, for example Police reports or delivery records could be useful in verifying facts.
For example, adding part of the above, an improved class of contracts might look like:
contract SaleContract {
  ...; establish parties, price, description of product/service, delivery method,
     adjudication method, timing, etc.;
  ... ; receive deposit into escrow;
  ... ; ship; receive; accept deliverable as received;
  ... accept deliverable as meets expectations (releases payment to seller);
  ... sendpayment;
  ...
}
Each point should provide for documentation that it happened in the real world., such as a UPS photo of the box on the recipient's porch, or a photo of a box with the china recieved in broken condition within it, etc.

This protocol tries to prevent swindles. What is a swindle? A party bought but didn't receive (e.g. in the ethereum namespace auction; you can very easily send ether to an address and not get what it's owner advertised and you intended.) To prevent it, "transfer" above encodes many real-world-connected conditions: was it sent? Was it received? Was it right? Etc. And purchases in the ethereum space ought to be protected in those ways. But the above "contract" while describing some events in some sequence, doesn't clarify who is doing what when actually the roles of buyer and seller and even of the judge can and should be separated. In a trustworthy protocol, messages that will be sent from one side to another might include some like the following.

  • Seller: M1 I OFFER to sell PRODUCT according to DESC at PRICE plus TAX plus COSTTOSHIP at SCHEDULE subject to JUDGE and PROTOCOL v
  • Buyer: M2 I OFFER to buy PRODUCT according to DESC at PRICE plus TAX plus COSTTOSHIP at SCHEDULE subject to JUDGE and PROTOCOL
  • Judge: M3 I accept to carry out the Judge role with S and B under PROTOCOL
  • Judge: M4 Seller do you agree to terms, Buyer do you agree to terms
  • Seller: M5 I reject terms (then Judge says Cancel order to S & B)
  • Seller: M6 I accept terms
  • Buyer: M7 I accept terms
  • Judge: M8 Buyer: sent TOTAL PRICE
  • Buyer: M9 sends AMOUNT
  • Judge: M10 partial payments not accepted, you owe AMOUNT, please send it.
  • Judge: M11 Timeout, returns AMOUNT to Buyer, cancels order with Seller
  • Buyer: M12 sends AMOUNT
  • Judge: M13 Seller: Buyer has deposited full amount into escrow. You are obligated to deliver per SHIPMETHOD on SCHEDULE.
  • Seller: M14 Shipment receipt.
  • Buyer: M15 Judge: Received shipment.
  • Buyer: M16 Judge: Purchase meets expectations. Release payment.
  • Judge: M17 Seller: Buyer happy, sends AMOUNT.
  • Buyer: M18 Product warrantee service required. Breakage description, documentation, photos, etc.
  • Judge: M19 Seller: please handle it. Sending documentation.
  • Seller: M20 Judge: pass on this RMA number.
  • Judge: M21 Buyer: here's the RMA number. Box it safely and ship it to Seller.
  • Buyer: M22 Shipped.
  • Seller: M23 RMA Received.
  • Seller: M24 Replacement shipped.
  • Buyer: M25 Replacement received.

This set of messages is essentially a protocol that governs the process of a purchase.

A protocol is the kind of thing to describe in the Protocol Meta Language, Promela, and verify using the SPIN model checker. A Promela protocol description, including messages, processes, and states, looks like, for example, this:

mtype = { RED, GREEN, YELLOW };  // Three messages
active proctype TrafficLight() { // Here is a process
  byte state=GREEN;              
  do
  :: (state==GREEN)  -> state = YELLOW;
  :: (state==YELLOW) -> state = RED;
  :: (state==RED)    -> state = GREEN;
  od;
}
This tiny example doesn't model drivers' behavior, nor the interaction of cars, safe or unsafe. But here our Judge program is like a TrafficLight; it interacts with particular cars, Buyer and Seller, so that they do the right thing at the right time and leave the intersection with the result each wants. How exactly? Here is a draft promela specification for the BUY protocol:
mtype = {M1..M32}; // This is a simplification.  Some messages contain
                   // data, amounts, money... We will get to that later.
chan BtoJ = [1] of {byte}; // Buyer to Judge message channel
chan JtoB = [1] of {byte}; // Judge to Buyer
chan StoJ = [1] of {byte}; // Seller to Judge
chan JtoS = [1] of {byte}; // Judge to Seller

init { Buyer(); Seller(); Judge(); }  // Start our modeling with just one of each.

proctype Buyer() {
  // First, a human shopper discovers product, seller, terms;
  // downloads Buyer app, selects product, seller, terms within Buyer app. Then...
  // The person might renegotiate terms here, but let's assume those are by now fixed.

  // So now the buyer likes the description and terms and trusts the protocol and
  // now sends the details to ask a judge to carry out the BUY protocol with seller.
  BtoJ!BUY,seller,terms; // Buyer: M2 I OFFERtoBUY product according to DESC
                     // at PRICE plus TAX plus COSTTOSHIP at SCHEDULE subject to JUDGE and
                     // PROTOCOL

  JtoB?terms; // Judge: M4 Seller, Buyer do you agree to terms;
  // Objection, this is pro forma!  terms are already agreed!
  // But the judge needs the evidence, and Buyer app must affirm that the
  // humans agreed explicitly and so as to become conclusive evidence of
  // their participation in the contract

  if
  :: BtoJ!rejectTerms; JtoS?CancelOrderNotAccepted; quit;
  // Buyer: M5 rejects terms (then Judge says Cancel order to S & B)

  :: BtoJ!AcceptTerms; // Buyer: M7 I accept terms
  fi

  JtoB?DemandAmount; assert(AmountCorrect); // Buyer: M9 sends AMOUNT
  BtoJ!SendingAmount // Buyer: M12 sends AMOUNT
  // Wait here until shipment arrives (outside the protocol).
  BtoJ!RecievedShipment;                  // Buyer: M15 Judge: Received shipment
  BtoJ!ShipmentSatisfactoryReleasePayment
    // Buyer: M16 Judge: Purchase meets expectations.  Release payment.
}

proctype Seller() {
  // Seller publishes product/service terms & protocol, awaits buyer engagement.
  JtoS?terms; // Judge: M4 Seller, do you agree to terms
  if
  :: StoJ!rejectTerms; JtoB?CancelOrderNotAccepted; quit;
     // Seller: M5 I reject terms (then Judge says Cancel order to S & B)

  :: StoJ!AcceptTerms;// Seller: M6 I accept terms
  fi
  
  StoJ!FOBShipReceipt; // Seller: M14 Shipment receipt.

  JtoS?BuyerHappy;
  JtoS?SendingAmount; // Judge: M17 Seller: Buyer happy, sends AMOUNT.
}

proctype Judge() { // Judge is intermediary, escrow holder and adjudicator.
  // Startup initialization.  Know terms, seller, buyer. 
  // Judge:  M3 I accept to carry out the judge role with S and B under PROTOCOL

  // Terms includes:
  //    product/svc, price, ship method & cost, tax, schedule,
  //    judge, protocol, parties, return process, adjudication process
  
  both
  :: JtoB!terms; // Judge: M4 Seller, Buyer do you agree to terms
  :: JtoS!terms; // Judge: M4 Seller, Buyer do you agree to terms
  htob

  both
  :: BtoJ?AcceptTerms; // Buyer: M7 I accept terms
  :: StoJ?AcceptTerms;// Seller: M6 I accept terms
  htob
  
  JtoB!DemandAmount;  // Judge: M8 Buyer: send TOTAL PRICE

  // Judge: M10 partial payments not accepted, you owe AMOUNT, please send it.
  BtoJ?RecvAmount;
  while
  :: !AmountCorrect -> JtoB!DemandDueAmount;
  :: else           -> continue;
  elihw

  if // Judge: M11 Timeout, returns AMOUNT to Buyer, cancels order with Seller
  :: timeout -> JtoS!CancelOrderTimedOut; JtoB!CancelOrderTimedOut; JtoB!ReturningAmount
  :: else ->
         BtoJ?SendingAmount;  // Buyer: M12 sends AMOUNT
         JtoS!ObligationInitiated; // Judge: M13 Seller: Buyer has deposited 
                            // full amount into escrow.  You are obligated
                            // to deliver per SHIPMETHOD on SCHEDULE.
  fi

  BtoJ?RecievedShipment;                  // Buyer: M15 Judge: Received shipment

  // Buyer: M16 Judge: Purchase meets expectations.  Release payment.
  if
  :: BtoJ?ShipmentSatisfactoryReleasePayment ->
     JtoS!BuyerHappy;
     JtoS!SendingAmount; // Judge: M17 Seller: Buyer happy, sends AMOUNT.
  fi
}
This is a buggy first draft that lets us begin to see who does and asserts what, when, during the process of a purchase/sale. Once converted to syntactically correct Promela and debugged using SPIN and elaborated with warrantee service, dispute resolution, partial performance, negotiated or penalized delays, etc., the group of processes are simultaneously verified and validated so as to work together as a group, via the structured interactions of this BUY protocol to carry out the intentions of the buyer and seller. Further implemented in Ethereum/Solidity, Rholang, etc., including apps for buyer, seller, and outside dispute adjudicator service providers, users can hope to trust that their interests are protected. Now that's a promise worth working for.

Additional Warrantee Service Steps

Buyer: M18 Product warrantee service required. Breakage description, documentation, photos, etc.

BtoJ!WarranteeClaim;
Judge: M19 Seller: please handle it. Sending documentation.

JtoS!RMARequest;
Seller: M20 Judge: pass on this RMA number.

StoJ!RMANumber;
Judge: M21 Buyer: here's the RMA number. Box it safely and ship it to Seller.

JtoB!RMANumber;
Buyer: M22 RMA Return Has Shipped.

StoJ!ReturnFOBShipReceipt;
Seller: M23 RMA Return Received.

StoJ!ReturnRecievedShipment;
Seller: M24 Replacement shipped.

StoJ!ReplacementFOBShipReceipt;
Buyer: M25 Replacement received.

BtoJ!ReplacementReceivedShipment;
 

Copyright © 2018, Thomas C. Veatch. All rights reserved.
Modified: March 6, 2018