Trustworthy Contract Handling - Comparison Of Approaches

Just started

Tentative title and limited content so far. Stay tuned or better: send me your comments.

Intended audience: interested computer scientists.

Thanks for feedback to: Ian Grigg, Nicholas H. Tollervey, Evan Hanson, Chris Odom

What To Compare (To become columns)

Alphabetical: Askemos/BALL/Wallet, Bitcoin, Ethereum, Hyperledger, OpenTransactions, Ricardian Contracts.

Which did I miss?

Properties To Compare (rows)

Note that not all properties are even applicable to all columns.

  1. General Purpose
  2. Defined as a concept or an implementation?
  3. Turing Complete?
  4. What's a contract? How to understand and check it? (What are the "4 corners of a page"?)
  5. Types of proofs; tamper evidence/resistance wrt: correctness, time, input&state (a.k.a. funds in payments), permissions
  6. Privacy: a) number of parties and witnesses (auditors), b) confidence of payment messages
  7. Attack vectors against evidence (hash sig) and veracity (SPOF, Sybil/51%, 67%)
  8. Access control (capabilites)
  9. Method of arbitration to resolve disputes
  10. Money creation policy

Skip the memos, table below for technical reasons.


On Language & Concepts

When it comes to "automated processing of contracts" to any extend, there is ONE thing the CS people MUST NOT fall for: their tendency to invent new concepts. We must model the real world as good as commonly understood. Otherwise the widespread saying that the courts don't understand software is not only true. It would be entirely the CS guys fault. And this software would be first and foremost: wrong.

What's a contract?

Correct the Ricardian Contract is a written document that presents the primary intent of the issuer. However, the final contract would be that other stuff which the holder could also convince the court was part of the contract. For example, any websites or displays on the client software. Specifically, the Ricardian Contract can never be the entire contract because it does not include an identified holder as a party, and so cannot include an acceptance of contract, nor a date for the transaction. [IanG]

Corresponds to the "payment instrument definition" of the demo.

The key difference seems to be

  • (g) the [lack or] presence of a secure identifier over (c) the [lack of] presence of terms and conditions readable by the judge.
  • (d) machine readable/executable code included with the human readable form to produce the secure self-sealing identifier.

Ethereum related answers


Ricardian Contract Askemos Smart Contracts
Purpose finance contracts in general state machine with money
Turing complete? n y y
Self-sealing Identifiers y y n
veracity (witnessed by) 3 parties 2+ parties and N notaries (byzantine fault tolerance) everyone (block chain)
input&state of automates Not applicable active replication (parties&notaries) trusted automaton (SPoF)
Capability distribution not applicable (not turing complete) strict subset Missing
Privacy entrusted to 3 parties parties and notaries everyone (block chain)
Arbitration In Dispute Human Human None


Ricardo OpenTransactions Hyperledger v1 BALL/Wallet Ethereum Codius Tendermint
Conceptual School Ricardian Ricardian n/a Askemos (more) Zabo "Smart" Zabo "Smart" ?? (new 2017-02-11)
Self-sealing Identifiers y y no y no ???
integrity Ricardian Hash Ricardian Hash missing see asset name clash issue and trusted automaton for ledger OID (==Ricardian Hash) full copy with ECDSA (secp256k1) ???
veracity (witnessed by) 3 party n-notary n-notary n-notary everyone ??? n-notary
input&state of automates Not applicable trusted automaton trusted automaton (the client) active replication (parties&notaries) trusted automaton ??? active replication (apparently)
autonomy/coercion 0 67%(? to be confirmed) 67% known, contracted peers 67% known, contracted peers 51% anon peers ??? 67%
Max. Mutation Rate n/a (would be "R. contracts issued per second") ?? several seconds 2 per sec. 1 per min. ??? 1 per sec.