Blockchains provide a computer network with the ability to establish consensus between computer executions and data state transitions in a trust-less way. This works very well for when actions of computers on the network are defined by data that exists only within the executing code itself. For example, if you wanted to create a contest for the first successful discovery of two prime numbers whose product is defined, the reward payout for it could be done in a trust-less way. This is because the notion of primality, product, first, and equality can be defined within the executing code of the network. However, as soon as the code has to rely on data that is representative of something in the physical world, it has to be translated to some degree subjectively before it can be fed into the trust-less execution context of a blockchain. Here is another example for a payout contract that illustrates the point. Lets say the goal is to write a car insurance contract that would pay an individual who experiences an accident in which they are not at fault. In this case, it is obvious that even though accident and fault can be defined within code, the entity that has to feed that data in needs to be trusted to some degree.
There are many ways to mitigate the amount of trust that has to be given to any single individual to ensure valid input to smart contracts. For example, the responsibility for who provides the data can be designated to several individuals and through a penalization system of those who fall outside some threshold from the majority, create incentives to act honestly. This sort of ranking system and other game theoretic incentive mechanisms are leveraged in prediction markets like Augur (https://www.augur.net/faq/#what-is-reputation). Another method is to use a third party oracle kind of service that is agreed upon, such as Provable (https://provable.xyz). These and other tried and true techniques work well with the public chains to ensure honest code execution and correct payouts. The business case has some other challenges and can make different assumptions for which a more catered set of solutions can work much better.
Disputes and the Cost to Business
Despite the fact that input to a distributed ledger introduces a component of trust, it actually only becomes an issue in the event of a dispute. Taking again the insurance example from before. If that smart contract simply relied on an API provided by a police website for accident reporting, it would most likely falsely determine a payout and require some kind of off-chain dispute resolution very rarely. Unfortunately, it is those rare occurrences (especially in business) that are the primary sinks of large cost overhead. According to the US Chamber of Commerce, commercial disputes cost the United States just over $300 billion in 2011, a number that was 1.66% of the countries GDP that year: https://www.weforum.org/agenda/2017/12/commercial-disputes-conflicts-costs-trillions-dollars-alternative-dispute-resolution! An effective way to interface a smart contract with the physical world of business agreements has the potential to automate these resolutions, and would create enormous value in society.
Adding to the tried and tested good solutions already mentioned that are used on public blockchains, another approach to solving these kinds of problems particular for the business use case is to leverage the chain as an audit log, where the data being shared in the platform is committed to the chain (in the current product this is done with a hash of the data). With this technique no revealing information is shared publicly within the platform, while any individual that has access to the data can attest to it being on chain. Moreover, the functionality of the smart contract within the Cambridge Blockchain platform and the isolated access it grants to different stakeholders through cryptographic keys, separates isolated functionality to any one individual. In so doing from the point of view of the blockchain, only certain actions could be taken by specific individuals.
Agree to Disagree
Now, lets walk through a hypothetical dispute in a legally binding agreement between two individuals to demonstrate how attestations on the blockchain can assist in the resolution. In such a scenario an authority (such as a judge) can first be provided documents that they will be able to check were the ones provided to the chain (e.g. explicitly given consent to be shared via the Cambridge Blockchain platform) by checking the hashes. This step verifies that the parties did in fact share the data they claim in order to enter into an agreement without any potential discrepancies. In this simplified solution, the blockchain layer will provide value in preventing fraud of any individual supplying the incorrect information, in addition to information related to the sequence of events and time thereof, etc. This is already a big step up from what is needed to validate user agreements today, were in many cases additional work is required in order to agree on what data was shared when and for what purpose.
However, after this stage the remainder of the interaction becomes subjective. The judge must then read the documents, understand the context for the agreement, and gleam semantic information from each of the participants. And here is where the Cambridge Blockchain application stack aims to go further, and attempts to provide a means of removing the subjective component in this interaction. To do this, the software leverages semantic agreements between counterparties. By focusing on automating the work of the authority, such a solution has the potential to create large cost savings and impartiality in all dispute resolutions.
As described, the Cambridge Blockchain platform has ambitious aspirations to remove the subjectivity inherent in user agreements and data sharing. To do this we have introduced semantic information that is attached to any of the data shared by utilizing the RDF , RDFa , and JSON-LD syntaxes. To better understand the usefulness of semantic information take as an example a web page that describes a book, it might be necessary to distinguish between the author of the book and the author of the post. Obviously, for a human this is a straightforward task by gathering contextual information from the rendered page, but to automate the process and build an ontology of information for automated agents, semantic schemas can be powerful tools.
Below is an HTML snippet for a power of attorney (POA) web form, which is a document that allows an individual to appoint a person or organization to manage their affairs if they become unable to do so. In the provided example each of the input fields have additional tags providing standardized semantic information from Google’s https://schema.org project.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dc="http://purl.org/dc/elements/1.1/"> <head> <title>Durable Power of Attorney</title> <meta property="dc:creator" content="Rocket Lawyer" /> <link rel="foaf:topic" href="http://schema.org/LegalService" /> </head> <body vocab="http://schema.org"> <h1 typeof="LegalService" property="subjectOf">Durable Power of Attorney</h1> <form typeof="AgreeAction" property="description"> I, <span typeof="Person"><input property="givenName"></span> residing at<span typeof="PostalAddress"><input property="streetAddress"></span>, <span typeof="PostalAddress"><input property="addressLocality"></span>, <span typeof="PostalAddress" property="addressRegion">Massachusetts</span> <span typeof="PostalAddress"><input property="postalCode"></span>, hereby appoint <span typeof="Person"><input property="givenName"></span> of <span typeof="PostalAddress"><input property="streetAddress"></span> <span typeof="PostalAddress"><input property="addressLocality"></span> <span typeof="PostalAddress" property="addressRegion">Massachusetts</span> <span typeof="PostalAddress"><input property="postalCode"></span>, as my attorney-in-fact ("Agent") to exercise the powers and discretions described below. </form> ... </body> ... </html>
Now, whenever a user interacts with the web form they are given semantic information of the data they read and provide semantic information along with any data they submit.
It is straightforward to see how any contractual agreement an individual may enter can leverage this technology. Specifically, at Cambridge Blockchain we provide Know Your Customer (KYC) capabilities within our platform where the user and trusted party agree to the data they provide and check, but even more so to the schema they used and semantics of what they have shared. In fact, any scenario in which two or more individuals enter some kind of agreement (all business through the history of the world for example) could benefit from this technology. Including health care information sharing, financial data, and much more. It is only left now to describe how contractual agreements of the future can be radically cheaper and more equitable with the adoption of the technology provided by Cambridge Blockchain.
Giving Meaning to Data
Now, with the real world problem and potential solution using semantic data described, we can have a new flow where the subjectivity of the judge in the first example can be completely removed from the interaction. Upon signing up with our platform the user is presented with semantic descriptions of all the different types of data supported. This semantic ontology will likely be managed by an administrator for some specific service provider. In the legal context, this could be a judge or a senior clerk working for one of the fifth circuit of a district or what have you. Once the user reads through the semantic information and enters an agreement with a counterparty through our platform, in addition to hashes stored for each individual piece of data they share with that individual a corresponding hash for a publicly accessible schema graph is also stored. This data is protected through the immutability of the blockchain and access controlled only through cryptographic keys, so the data can always be referenced as correct and shared through explicit consent of the data owner.
So what have we done? Well, by forcing explicit consent by the user in order to make any changes within their immutable state representation within the platform, and including semantic information into any agreement between two counterparties, we’ve brought a reference of the real world onto the blockchain! So now, as long as you fill out a form, and agree to the semantics of a car accident and fault when singing up insurance, the delegation for dispute resolution could be fully allocated to an automated agent. What would have to be encoded is a check on the data that was shared (verified with the hashes on chain), parse along with a corresponding semantic ontology graph (verified with the hash of the schema graph on chain), and information provided as values in the context of the schema.
As is central to the philosophy that motivates the engineering work done at Cambridge Blockchain, we aim to bridge the gap between established and emerging businesses in traditional sectors with the latest in emerging state of the art technology just coming online. Solving pain points and lowering costs is central to what we aim to do and some of the motivation for this post is to detail how our platform can benefit traditional business; particularly in the compliance and legal space. But, the work we do is also very forward thinking, and we already have advanced protocols for the future of business and data sharing. Well positioned to integrate with companies working on the most recent technologies with blockchain networks, Internet of things (IoT), and the like.
The design of our semantic markup processing along with dynamic smart contracts can facilitate automated verification with minimal data sharing, supporting state of the art cryptography. One of the improvements we are looking to provide is the ability for KYC and Anti Money Laundering (AML) capabilities at the highest level of security and anonymity through zero-knowledge data sharing, but that is for another post. Stay tuned!