Notes on Corda

Technology
Corda: An Introduction
A White paper by Richard Gendal Brown, James Carlyle, Ian Grigg, Mike Hearn
August, 2016
 
Below my bullet points summary of the White paper.

Introduction:

  • Eliminate effort to keep disparate ledgers synchronised
    • Parties to financial agreements record them once and collaborate to maintain accurate shared records of these agreements.
    • Agreements that can be deployed within existing legal frameworks and relies on proven technologies
  • Duplication of ledgers can lead to inconsistencies and drives a need for costly matching, reconciliation and fixing errors.
  • Complexity and plurality of technology leads to operational risks
  • Platform and open innovation and competition
    • Greater level of code sharing reducing cost of financial services for everyone (vision of a platform and open innovation)
      • Centralised market infrastructure utilities have gone a long way to share data and business logics, but overall, the degree of integration achieved in the realm of financial transactions still lags far behind that which has been achieved in the realm of information exchange since the advent of the web.
      • Blockchain technology opportunities: implementing a new shared platform for the recording of financial events and processing of business logic, this architecture will define a new shared platform for the industry, where parties can compete to deliver innovative new products and services.
    • Ledger common but consuming service and market infrastructure providers on an open and competitive basis.
  • Result:
    • higher quality data
    • fewer discrepancies
    • quicker agreement (multiple systems recording same trade is major driver of cost and complexity)

👓 Vision:

  • From authorative systems-of-record maintained within firms to global authoritative systems-of-record shared between firms.
  • End state principles:
    • Regulatory acceptance of facts recorded in the ledger
    • Data becomes golden source and not shadow/proxy of authoritative data held elsewhere (i.e. pre settlement)
    • Immutability incentivises accuracy across users
    • Existing and new service providers can connect and compete to offer differentiated services
    • Only those who have a reason to see the data will see the data
  • Multiple states in between
    1. Prototyping (Now)
    2. Co-existence/Integration/Migration paths (Interim state)
      1. Today’s systems will be with us for the foreseeable future while legal and non-technical implications of the longer term vision are addressed in parallel.
      2. Sharing only of business logic
    3. Full potential (Future state)
  • One global logical ledger is the direction of travel but its realisation may be in the form of multiplicity of ledgers
  • Architectural and strategic choices underpinning the vision include:
    1. Records accessible only to those actors with a legitimate interest in the assets and agreements they manage
    2. Computer code that explicitly refers to and gains its legitimacy from overarching legal prose
    3. Contractual disputes can occur even in automated settings and should be supported by the contracts and further upgrades
    4. Network effect requires adoption = portions of the system must and will be open (open source, open dvt, open standards)
    5. Modular competitive approach: incentives to adoption is driven by what you can do with it
    6. This may include layers which will be proprietary
    7. Security is a design component
  • Ingredients are already here:
    • Robust cryptography
    • Global comm. networks
    • Standards for the definition of financial instruments
    • Effective algorithms for consistency at a global scale
  • Regulatory engagement is a key element of the design process.
 

👾Corda:

 
(1) Definition:
  • Distributed ledger platform for recording (1) and processing (2) financial agreements among registered financial institutions, designed to implement the vision detailed above.
  • Supports smart contracts:
    • Which as defined by Clack, execution is both automatable by computer code working with human input and control, and whose rights and obligations, as expressed in legal prose, are legally enforceable.
    • Example: Barclays Smart Contract Templates Prototype built on top of R3 Platform:
      • Clack programming language developed specifically for this
      • Link Legal prose to Business Logic
      • Neutralise the cost by sharing common components
      • Optimisation of legal processes and to enable legally enforceable smart contracts
(2) Features:
  • Recording and managing contracts in way that is grounded to existing legal constructs
  • Network monitor (Choreographing workflow)
  • Consensus at the level of individual deals (not global system)
    • R3 rejects the notion that all data should be copied to all participants, even if it is encrypted.
  • Regulatory and supervisory as observer node
  • Validating transactions solely between parties to the transaction
  • Various consensus mechanisms
  • Link Legal prose to Business Logic
  • Industry standard tools
  • Data available to relevant users only
(3) Concepts:
  • State object: digital document which records the existence, content and current state of an agreement between two or more parties.
  • Ledger: set of immutable state objects
  • Objective:
    • make sure that all parties to the agreement remain in consensus as to this state as it evolves and
    • make sure that data held by actors is and remains consistent as operations are applied to update that data
      • As opposed to consensus over the state of the entire ledger (Bitcoin) or the state of an entire virtual machine (Ethereum)
 
(4) Consensus (how to reach consensus without POW)
  • Updates are applied using transactions, which consumes existing state and produce a new one
  • Transaction validity: parties can run the transactions on their own to verify validity
  • Transaction uniqueness: transaction is unique consumer of all its input states (no double spending), an action that proves that the states consumed by a given transaction have not previously been consumed.
    • Validity can be tested on their own, but uniqueness requires a predetermined observer, which will be required to be independent.
      • Corda has pluggable uniqueness services, the technology varies depending on the requirement of the concept, if a change of state requires signatures of parties, uniqueness service won’t be required.
    • On ledger: at least two actors are in consensus as to its existence and can have an arbitrary combinations of actors can participate in the consensus process
    • Off ledger: Data held by only one actor
    • Uniqueness services are not required to see the full contents of any transactions, improving privacy and scalability.
(5) Business Logic:
  • Function that consume states as inputs and producing output states through the application of smart contract commands, and accept the transaction if the proposed actions are valid (and unique).
  • Contracts are mobile: nodes will download and run contracts inside a sandbox.
  • Standardised the bytecode set (deterministic execution) rather than a language.
(6) Core Financial Concepts: (usage cases)
  1. A cash balance
    • there is no “money in the bank” but a cash claim that an owner has with respect to a named institution.
  2. A security under custody
  3. A bilateral derivative agreement

Summary core concepts:

  1. State objects represents an agreement between two or more parties, governed by machine readable contract code, which is liked to human readable Legal Prose.
  2. Transactions, which transition state objects through a lifecycle
  3. Transaction Protocols enabling parties to coordinate actions without a central controller.
  4. APIs, wallet plugins, UI components are part of a CorDapp

Source: Corda White paper [link]

Comments are closed.