Intro to R3 R3 Engineering 05/12/16. How is R3 enabling - - PowerPoint PPT Presentation

Intro to R3

05/12/16.

R3 Engineering

How is R3 enabling collaboration?

Create a Product Market it and sell it Refine it (maybe)

Create a Consortium Collaborate on requirements;

• pen source

Build it together

70+ global institutions 1400 + passionate people

Most Start-ups: R3:

R3 Global Members

Hype

POCs Early Scaled Deployments Talk Main Stream Deployments Early Adoptions Value Definition Building Blocks Collaboration

Tipping Point

Market Interfaces “The Norm”

Standards Regulation Technology Governance Collaboration Bridging the gap towards mainstream adoption

We are here

Consortium Projects

The Empire Strikes Back!

December 6th 2016.

Stuff we will cover

• Interesting features
• Unusual design decisions
• Next steps

Caveat: will mix implemented vs pending work. Will call out what’s not coded with a *

p7.

That’s us!

Corda @ HyperLedger London p8.

OK, so how does it work?

Basics you must know

• No block chains, no mining
• Permissioned networks
• JVM based
• Open source reference implementation, unfinished
• Tech white paper is a design doc

Corda @ HyperLedger London p10.

Bitcoin-esque tx structure

Corda @ HyperLedger London p11.

• Ledger is composed of (output) states
• Execution of code for both inputs and outputs
• Signatures external to the transaction data
• Platform checks signatures, contract code
• nly checks presence of pubkeys
• Commands parameterise transactions
• Key randomisation with separable identities*

p12.

But with extras …

Corda @ HyperLedger London p13.

Transactions can have attachments. Attachments are zip files referred to by hash. Can contain:

• Contract bytecode
• Legal documents explaining what it’s meant to do
• Static reference data (e.g. holiday calendars)
• Identity certificates
• Anything else

Attachments form a per-tx filesystem and files cannot overlap. Attachments are deduplicated on the wire.

But with extras …

Corda @ HyperLedger London p14.

Transactions are structured as a Merkle tree. Can selectively reveal different parts. States (outputs) can contain arbitrary object graphs

(at present – may restrict this soon)

Encumbrances allow you to combine different contract logic.

Unusual design decision 1

No broadcast: transactions resolved lazily Consequence: DoS handling is simpler Consequence: bulk data import is silent Consequence: must specify where data is sent

Corda @ HyperLedger London p15.

P2P network structure

• All communication bidirectional
• Messages organised into flows
• A “flow” is an uber-thread that

survives process restarts, stored in the database

• Uses fibers behind the scenes

How?

p16.

Flows

• Flows specify the identities to which messages are sent
• Flows are type safe
• Corda network is SMTP-like

– Messages are buffered to disk and delivery is retried up to the event horizon

• Flows can interact with people* and internal systems
• Protocol is AMQP/1.0 + TLS, node is services connected to

an MQ broker

Corda @ HyperLedger London p17.

Flows

• Flows have progress tracking
• Flows can read/write to the node’s relational database
• Flows can invoke sub-flows
• Corda provides a standard library of flows for common tasks

Corda @ HyperLedger London p18.

<show flow code>

SQL support

Pity the fool who tries to build a block chain app! New databases are hip but:

• How to analyse data in them?
• How to combine with private data?
• Don’t even think about migrating existing apps or

data … Most platforms give you REST and then you’re alone

Corda @ HyperLedger London p20.

SQL support

Corda built on the JVM Embeds the H2 relational database. JDBC access.

Support for other external DBs in future*

State schemas can be JPA annotated with conversion code in the smart contract “Relevant” states written to DB tables State schemas commonly contain slots for join keys

Corda @ HyperLedger London p21.

p22.

Notaries and consensus

• Pluggable consensus algorithms
• “Notaries” can be/should be distributed
• Notary implementations:

– Onebox: for local testing/dev work – Raft: robust against node failure, not malice – Above x2 for non-validating modes – In future, BFT-SMaRT*

Corda @ HyperLedger London p23.

Deterministic JVM

Corda contracts defined using restricted, cut down bytecode Most features are gone, e.g.

• No threading or finalisers
• No access to external data (files, networks, RNGs, clocks)
• Object.hashCode modified to be derived from tx hash*
• No native code
• Bytecode instrumented to do cost accounting
• Exception handlers adjusted to prevent thread termination
• strictfp

strictfp enforced everywhere

• No invokedynamic
• Class libraries bytecode rewritten as well

(+more!)

Corda @ HyperLedger London p24.

Client RPC

Primary comms is via Client RPC

• Small (~800 loc) RPC stack that operates over MQ
• Can marshal Rx observables: streaming of results is natural
• Can handle temporary connection problems, backpressure

management*, buffering etc …

• Thin client library exposes reactive collections that can be

directly bound to JavaFX UI and mapped/filtered/sorted Functional, pipeline oriented programming.

Corda @ HyperLedger London p25.

Experimental universal contract

val one_touch = arrange { actions { highStreetBank may { "expire".givenThat(after("2017-09-01")) { zero } } acmeCorp may { "knock in".givenThat(EUR / USD gt 1.3) { highStreetBank.owes(acmeCorp, 1.M, USD) } } } }

Corda @ HyperLedger London p26.

Lots more!

• Novel design for client-side signing devices (e.g. TREZOR)*
• Identity management*
• Event scheduling
• Type system for modelling nettable obligations, assets,

fungibility

• Network permissioning infrastructure
• Data distribution groups*

Corda @ HyperLedger London p27.

Corda: Next steps

The 4 s’s

Until now: experimentation and design Starting now: the road to production

• Security
• Serialisation
• Scalability
• Finishing the features

Corda @ HyperLedger London p29.

Privacy and scalability

• Start random key usage once identity cert

management is done

• Novel privacy research in prototype phase that

we will talk about more if/when it’s more mature

• Implement vault soft-locks and start load testing,

eliminating bugs

Corda @ HyperLedger London p30.

p31.

Goal API and protocol stability by EOQ3 2017