So Ethereum is released. How come the dream of an open, transparent, jurisdiction-neutral techno-legal system hasn’t arrived?!

Well, it turns out that “Ethereum” (Frontier, eth, geth, whatever) is actually only a relatively small piece of the puzzle. The “kernel” of an operating system, if you like. While planned upgrades to this kernel, like proof-of-stake (nudging throughput, providing finality and increasing the network’s green credentials) and light-client support (reducing bandwidth, memory, hard-disk and computation requirements on some nodes) are helpful, there is only so much that one can do to propel the platform forward at this level.

In fact, like operating systems, the vast majority of the code lies not in the kernel, but rather in “userland” software; the executables (that typically provide services to the user) and the libraries (providing services to other software). The parallel here to a crypto-law system (like that which could surround the Ethereum kernel) are the software “contracts”, providing services to the user (by virtue of being included in a Dapp or web-based proxy) or to still other contracts.

Just as the GNU portion of GNU/Linux provides important pieces of software “infrastructure” for a functional operating system (such as a C library and shell tools), the Ethereum platform, at present, needs this infrastructure before it can be properly exploited. This article is about mapping out and exploring the interrelationships between those pieces and doing so in terms of defining and (re)combining simple primitives.

While I relate much of this article to Ethereum (since that’s the crypto-law system I’m most familiar with), the points are quite general and can probably be applied to many of the other mooted systems around now.

The Three Pillars

There are three key pillars of a crypto-law ecosystem:

• Identity (1)
• Assets (n)
• Data (inf)

Identity

Roughly speaking these are contracts that encode the notion of identifying a unique individual actor. They model the things with “self”. Typically, this will be a person or organisation in the real world (“legal entity”) — new technology always tries to imitate old as it finds its feet. However, it will eventually take on the meaning of quite abstract “crypto-legal” entities, of which a multi-signature account would be a primitive example. Eventually, IoT promises, many “inanimate” objects (e.g. door handles and toasters) will gain their own identity, able to make autonomous economic actions and be intrinsically different to other instances of their class.

Ethereum already comes with a low-level notion of identity built in — it’s the 160-bit (currently hex-encoded) address. However, being so low-level it is essentially meaningless to anyone wanting to express real-world “crypto-legal” notions.

Contracts that manage identity will range from heavily decentralised and transient (e.g. swarms of individuals doing regular synchronised meetings across the world to determine uniqueness), heavily centralised and permanent (e.g. government-issued “cold signing devices”) to hybrid meta-identity models (e.g. piggy-backing on pre-existing Facebook/Twitter/PGP identities).

The thing these all have in common is that they provide a service to ascertain to who or what corporeal entity, if anything, a particular address represents.

Assets

Asset encoding within a crypto-legal system is to attempt to model ownership over a particular amount of a class of “stuff”. Assets that initial contracts will model will probably be those we are already used to; real-world item classes (SKUs, make & models), commodities, stocks and currencies. One important difference between assets and identity is that assets tend to be strictly fungible or, at least, generally interchangeable. In terms of platonic philosophy, assets are the prototypes or classes of things, rather than the individual instances themselves.

Aside from “real” asset tracking, infrastructure will be built to track purely virtual assets. Indeed, Ethereum already has a low-level virtual asset built-in; the Ether “token”. However, at least for now, it is generally too low-level to be useful for most crypto-law applications.

Asset contracts will be implemented in a multitude of manners, not least as a centralised commodity repository (see e.g. Digix Global) and as a purely algorithmic currency (Gavcoin?). Supply-chain platforms implemented within Ethereum would include components that ascribed “asset-class” meaning within contracts.

Data

Data contracts are those which ascribe information to other entities within the ecosystem or otherwise supply “global” information, perhaps about externalities. In the first group, we might ascribe particular pieces of information to an identity (is it a real person? what is their name?) or an asset (it is physical? how much does it weigh?). In the second group, we typically think about oracles; contracts which describe external information inside Ethereum — e.g. the current market price of Ether in terms of Euros. However, in principle, the information could be entirely internal; for example metadata concerning a currency like its name and TLA.

Data-infrastructure differs from the other two pillars in that it provides no directly referencable or manipulatable concepts; rather it exists solely to add richness of meaning to other existential entities, be they asset-classes or identities. In Ethereum, it will likely be implemented as an on-chain hash with an off-chain reverse-hash-lookup service (though a more advanced hybrid system may not need to make the distinction as our relatively unbaked protocols do at present).

Ethereum also contains a few built-in pure information services, too. For example, the EVM operation codes allowing a contract to retrieve the block-number and timestamp provide global information points. While a timestamp is a relatively high-level piece of information, it sits essentially alone against the rest of the intrinsic information-provision mechanisms.

Building on the Pillars

While contracts that provide pure services concerning each one of these pillars will be extremely useful, these should be considered merely building blocks from which a crypto-lawyer (or crypto-lawmaker?) may construct appropriate shades. Combinations of these base layer services will lead to far greater, more meaningful and more relevant concepts, contracts and services being provided in the ecosystem.

Data + Assets

Combining the data and assets (and notably not identity), we can imagine several additional services mostly revolving around how assets or ownership and be altered through data.

• Asset Classification The simplest combination of data and assets, this would just be data attached to assets to express attributes, perhaps in a structured fashion. It would be a key building block for most asset-based services as it allows a rich “asset language” to be built. Assets of differing classes may compared.
• Insurance A kind of escrow service where assets are dispersed one or more owners after a period of time depending on a particular data series. The initial applications of this will see the data series coming from e.g. weather reports, but we can imagine it combined with Identity for having insurance against theft through authorised police reports. A special type of insurance is the contract-for-difference, where you’re insuring the value of one asset against another. CFDs form a very useful financial instrument, potentially a simple way of implementing a Pegged Currency.
• Pegged Currency Through the combination of the primitives of a data-feed and an asset class, we can create an economic model of a currency which tracks a real-world value feed, such as the US Dollar. There are several possible ways of implementing this including through CFD-shares and so-called “stable/volatile-coin” dualisms.
• Gaming Insurance where the incoming data is a random series morphed to have the risk characteristics the party(-ies) choose.

Assets + Identity

Combining assets and identity (but rather not data), we can compose new services and concepts that involve the relationship between ownable “stuff” and individual actors.

• Certification Through attaching a particular non-ownership relationship between an identity and an asset, we can synthesise the notion of certification. The essential meaning is that while identity X (e.g. “The Organic Growers Association”) does not own asset-class Y (e.g. coffee beans in my shipment) it associates itself with it, thus labelling my shipment of coffee beans as having been grown organically.
• Asset Tracking We may apply the relationship inversely: taking an owned unit within an asset class and creating an identity for it, changing the situation from “A pint of beer” to “this pint of beer” in a process we might call instancing. This can happen when I purchase a particular item or when an item’s configuration alters from a pristine state. A smartphone, for example, prior to purchase may be considered fungible. Following purchase it becomes individual (with the accordingly unique data, phone plan and scratches).
• Judged-Escrow Escrow services, combining an appeal to an identifiable authority along with the ownership provide an important foundation for trustless trade. Notably, basic escrow services without any authority being involved can exist, though are more useful when combined with badges or a reputation system (next).
• Bonded Identity An identity attached to which is some known assets that may be controlled by some external mechanism(s). Such a notion is extremely useful to help guarantee good behaviour within an ecosystem and provide “teeth” to other crypto-legal services whose mechanisms require that a party may be punished.

Identity + Data

The combination of identity services and data services allows for data to be associated with an individual, or conversely, an individual to be associated with some particular data:

• Reputation For something so commonly used, reputation is a difficult notion to pin down. At its root, reputation is simply an attribute of an identity, a means of linearly measuring the entity’s virtuosity and typically related to how well other “identities” perceive it. Reputation systems within a crypto-legal system help make up for the lack of social-contact inherent with purely machine-to-machine systems and form the precursors and prototype for Web-of-Trust and more formal credit-rating and AML/KYC systems.
• Badges Badges are essentially a non-transferable, non-linear attribute attached to an identity. Depending on the level of badge-prototyping, they could be argued to be either Identity + Information or Identity + Asset. Badges of non-structured data may include, e.g. character-testimony. For structured-data they may include notes of events attended (OMG he went to see the first ever episode of Red Dwarf being filmed) or intrinsic roles & rights (I believe in the celestial teapot, I am a human).
• Oracles Reversing the relationship, we can allow an identity to vouch for data. One means of getting reliable information concerning external phenomena is to decide to take a particular identity as ones authority and accept data coming from it. While it is far from the ideal, it is relatively cheap and easy to implement so will likely become the de facto standard.

The Rest

We can recombine many of these service classes into higher-order crypto-law concepts and services on which we may truly see the beginnings of analogies to modern legal tools and services.

• Credit Rating, KYC (Reputation) Derivatives from the reputation primitive, credit rating systems provide richer, more meaningful semantics over particular aspects of identity which can be useful primitives for financial systems.
• Trustless Oracles (Reputation + Oracles) A reputation system combined with an off-chain compute service (perhaps similar to Codius) could facilitate a very general and low-trust means of delivering arbitrary external information into a crypto-legal ecosystem.
• Virtual Retail (Pegged Currency + Assets) Through combining asset classes and pegged currencies, we can imagine an online shop. Asset classes can be swapped for a pegged currency allowing for purely on-chain assets to be bought and sold trustlessly and off-chain assets to be bought from a trustworthy retailer.
• “Real” Marketplace (Reputation + Escrow + Virtual Retail) Through the use of a reputation system and escrow, we can imagine a low-trust decentralised retail system for trading on- and off-chain assets.
• Truth Engine (Data + Reputation) The Truth Engine is a critical component of many high-level crypto-legal mechanisms such as a crypto-Court. Given a statement, it would provide a Boolean answer to denote its truth. In many cases, the answer would be farily trivial and a reasonable implementation could be reputation-weighted voting, perhaps backed with an adversarial evidence-submission system. A prediction market would provide another, more complex and resilient, mechanism.
• Court (Truth Engine + Bonded Identity) A theoretical minimal “Court of the Internet” would include a Truth Engine to determine the correct course of action together with a “bailiff” to implement the judgement; the bailiff component would properly be implemented through a ubiquitous system of Bonded Identities. The Bond would be transferred in order to punish the culprit and compensate the victim.
• Trade Mediator (Truth Engine + Escrow) A simpler version of the court which comes from a per-transaction Escrow service, it would hold the assets of a trade and transfer them to according to a set of rules, possibly (in the case of dispute) helped through the Truth Engine.
• Trade Finance (Credit Rating + Currency + Asset Tracking) Trade-finance systems, providing favourable credit for predetermined low-risk assets tied up in shipping provide liquidity to the global economy with trillions of dollars at any one time. Existing systems are implemented in “civil law” (makes me think of “snail mail”) through complex, costly and forgeable contracts (“letters of credit”). Through a combination of financial primitives and asset-tracking, such contracts can be synthesised within a crypto-law system more cheaply, flexibly and reliably.
• Transparent Supply-Chain (Certification + Asset-tracking) Being able to attach unforgeable attributes to real-world commodities such as pharmaceuticals, foodstuffs and luxury goods allows for a number of high-value problems to be solved or assuaged, including counterfeiting, redirection, shrinkage and mislabelling.

Conclusion

While far from complete, I’ve tried to map out some of the ways in which we can take some primitive crypto-legal notions and build a system with useful primitives that perhaps some of the first “programmer-lawyers” can take to. Notably missing are IoT (which probably just adds an extra dimension to the notion of identity) and DAOs (which are really just the corporations in the crypto-legal world of identities).

If anyone fancies it, it would be nice to see a visual DAG of all this :)