Transcript Distribted Ledger (Blockchain) Working Group at OMG

Distributed Ledger Technology
Working Group at OMG FDTF
Status and Summary of Activities
Based on OFDG Report Slides + subsequent calls
01 Nov 2016
Introduction
• OMG Finance Domain Task Force
• “Blockchain” initiative
– Introduced in March 2016 in Reston
– Initial exploration calls
•
•
•
•
June 2016 detailed sessions
Sept 2016 Workshop for PoC
Renamed to “Distributed Ledger” WG
Ongoing activities
Blockchain and Distributed Ledgers
• Origin: BitCoin, paper Satoshi Nakamoto
• Ability to post non repudiatable stuff on a distributed
ledger
• What stuff?
– Balances?
– Anything
• Binaries in theory but too cumbersome
• Hash code for any kind of binary file
• What is distributed?
– The content
– Validation rules for what you can post
– Pseudo code for Smart Contracts
• Smart Contracts
The “Blockchain Bundle” Menu
• Ref
– https://gendal.me/2016/04/05/introducing-r3-corda-adistributed-ledger-designed-for-financial-services/
•
•
•
•
•
Consensus
Validity
Uniqueness
Immutability
Authentication
R3 Proposal for FiServ Bundle
• Consensus
– Between parties – not to all
• Validity
– Stakeholders
– Validation logic
• Uniqueness
– Uniqueness service implementations
– Trade-offs and prioritization
• Immutability and Authentication
– As per Blockchain
OMG Motivation
• Are there aspects of Blockchain where some
standardization would be of value?
– If so, what to introduce as OMG standards v what
to coordinate with other WGs
• Potential value of FIBO for Blockchain / DLs
OMG Motivation
• What we think can be standardized:
– Computationally independent representation of
subject matter
• AKA Conceptual Model
– But some participants don’t like that term
• AKA Computationally Independent Model (CIM)
• AKA Ontology
– At least if we include process ontology
– BPMN and OML-Activity give computationally independent
view of process also
FDTF DLTWG Consensus
• Provide computationally independent view of
subject matter suitable for DLT applications
– Based on FIBO
– Is ontology
– Demonstrate process dimension also
• Proof of Concept
– Identify the concepts
– Show hw thee relate to >1 DT aplication or
architcture
Initial Investigation
• Identified 2 areas where there is potential for
standardization
– Common identifiers
– So called “Smart Contracts”
Smart Contracts
•
•
•
•
What gets posted on the DL
Off-blockchain activities
Currently managed at the “code” level (physical)
Variations
– Ethereum – VM where instructions are posted as pseudocode in
the chain
– As soon as logic is executed off chain or information accessed
off chain it is not longer a DLT thing
– Very limited opportunity for BC to be a closed system
– So SC is a heavily hybridized concept. “Permission side chains”
– R3: peer to peer copying of information with off-ledger services
Distributed Ledgers
•
•
•
•
Ethereum
Hyperledger
Interledger
R3
– Not really a “Blockchain” but is a Distributed Ledger
– Messaging application with a shared data model
– Templates dine the data needed to apply the data to a different
contract algorithm
– Not transmitting transctions but routign them as part of the workflow
• At one level this is just another implementation of distributed
database concepts (replication)
– With differences
• Can be implemented publicly or as a private network
Discovery
•
Ethereum
–
–
–
–
–
•
created a programming language like Javascript with a VM in which they run
Less obvious how you wrote these things in the same way everyone else is writing them
No common conceptual model
All sites would have the same logic
All nodes evaluate the same stuff and that is the basis for consensus
Code
– Need to be able generate the code in an idiomatic way that can later be recognized, thereby
improving trust
– Because of the overhead of large apps and large umbers of nodes, what is realistic t put on the
chain is just he results e.g. settled transactions not contracts
– Chain is always evaluated from start to finish each time
•
Smart Contracts
–
–
–
–
Parties related to the contract interact with the object.
State and history of the state is maintained on the BC.
Who defines the template class for e.g. IR Swaps.
Syndicated loans are a hard use case for BC.
Discovery: Smart Contracts
• Can propose a basic tenet of a few standard
templates for those Smart Contracts.
• Banks can take those and inherit those and
create their own SCs.
• People have to trust the class itself.
• "The Contract is on the BC" - the language is
off line, the BC has the business logic.
– In theory – but bear in mind limitations
• Will not be a single smart contract.
SMART CONTRACTS
• Premise: Smart Contracts should standardize around
ontological definitions of contracts (or commitments
etc.) rather than whatever is the "Code" approach that
others in Smart Contracts have been considering.
• One opportunity is that whatever code is distributed,
itself has a hash key, so if that has been vetted and
accepted then the code is known that it can be trusted.
We know we are executing the same code in the same
VM
– So consensus can be at the level of both the business
content and the code that does the work (meta level)
– Then execution is off chain but the DLT validates that you
can trust the outcome
A Model Driven Approach to
Blockchain/DL
• We see things happening at a physical or logical design
level
– Smart Contracts code in e.g. Python, defining required
behaviors, conditions etc. when a thing is posted
– Physical architecture of the different Blockchain and DLs
• We see the need for and benefits of a common
business view
– Computational independent of “Conceptual”
– Business semantics
• Conceptual view for both structural and behavioral
Structural and Behavioral Business
Content (semantics)
• Structural: terms of the contract
– This should be mappable to FIBO and ACTUS
• Behavioral: off-Blockchain behaviors and
activities
– Payments process flow
Structural
• If anything can be hashed and posted to the DL
then:
– Can be at the level of the whole contract (PDF)
• OR
– Can be at the level of the individual Commitment
• FIBO describes commitments individually (based
on REA transaction semantics)
– We think there is benefit in posting specific
commitments to the DL for grater precision
– These also map more directly to process activities
Behavioral
• Business process or workflow
– E.g. payments, settlement delivery workflows
– Swap: two cashflow-based commitments
• Can model these in
– UML Activity Diagram format
– BPMN (Business process modeling notation)
• FIBO Conceptual Abstractions Model
– Includes process and activity primitives
• These currently resemble UML Activity notation
• Can extend to BPMN constructs
Behavioral and PoC
• Cook-off between UML-Activity and BPMN
representations
• Map out in UML Activity for now
– Convert that to FIBO Abstractions for Process
– Extend or convert to BPMN also
• Extend to “hybrid” type of diagram
– Process – information interface
– What information is used by a process step
– What information is generated by a process step
• E.g. Red Herring prospects; terms sheet
Proof of Concept
• Two separate instrument types chosen
– This is to illustrate the benefits of common
semantics of concepts
• Interest Rate Swaps
• Treasury bonds
IR Swaps PoC Component
• Based on a simple vanilla IR Swap example
• Mapped out the process workflow (ongoing)
• Created simple class diagram (placeholder for
ontology)
• Start to combine these as hybrid view
• Then link these to FIBO ontology terms in IR
Swaps PoC ontology
Brainstorming
Workshop
IR Swaps Process
IR Swap process
• Segregate
– business process view of the IR Swap
– Blockchain possible postings
• Q: different DLTs may present different
opportunities or constraints for what to post and
for what happens off-ledger? No
– This need not vary among DL architectures
– Ned to also identify access /visibility requirements
• O we can till do this as a computationally
independent model as proposed standard
Treasury Bonds PoC Component
• Structural:
– FIBO concepts for bonds contractual terms
• Primary market (issuance): Auction process
workflow
– Map out in UML Activity
– Based on earlier FIBO draft issuance process
material
– Focus on specifics of Auction process workflow
Current Status: To Do
• More research on what can be posted where
• DL v Blockchain v Smart Contracts detail
– What to propose
– What architectures support what
– Keeping it “conceptual”
• Treasury Auction process to model
• Hybrid models (as ontology)
• Demonstrate linkage to >1 DL architecture
References
• Smart Contracts
– https://smartcontract.com
• Treasury R3 Initiative
• Corda and R3
– http://www.reuters.com/article/us-banksblockchain-r3-exclusive-idUSKCN12K17E
• Circle (Boston) initiative – mobile phone
enabled payment transfers