Intro to R3. R3 Engineering 05/12/16.

Transcription

1 Intro to R3 R3 Engineering 05/12/16.

2 How is R3 enabling collaboration? Most Start-ups: Create a Product Market it and sell it Refine it (maybe) R3: Create a Consortium 70+ global institutions Collaborate on requirements; open source passionate people Build it together

3 R3 Global Members

4 Bridging the gap towards mainstream adoption Tipping Point We are here Hype Talk POCs Collaboration Early Adoptions Building Value Blocks Definition Collaboration Governance Technology Regulation Standards Early Scaled Deployments Market Interfaces Main Stream Deployments The Norm

5 Consortium Projects

6 The Empire Strikes Back! December 6 th 2016.

7 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.

8 That s us! HyperLedger London p8.

9 OK, so how does it work?

10 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 HyperLedger London p10.

11 Bitcoin-esque tx structure 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 only checks presence of pubkeys Commands parameterise transactions Key randomisation with separable identities* HyperLedger London p11.

12 p12.

13 But with extras 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. HyperLedger London p13.

14 But with extras 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. HyperLedger London p14.

15 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 HyperLedger London p15.

16 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.

17 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 HyperLedger London p17.

18 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 HyperLedger London p18.

19 <show flow code>

20 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 HyperLedger London p20.

21 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 HyperLedger London p21.

22 p22.

23 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* HyperLedger London p23.

24 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 enforced everywhere No invokedynamic Class libraries bytecode rewritten as well (+more!) HyperLedger London p24.

25 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. HyperLedger London p25.

26 Experimental universal contract val one_touch = arrange { actions { highstreetbank may { "expire".giventhat(after(" ")) { zero } } acmecorp may { "knock in".giventhat(eur / USD gt 1.3) { highstreetbank.owes(acmecorp, 1.M, USD) } } } } HyperLedger London p26.

27 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* HyperLedger London p27.

28 Corda: Next steps

29 The 4 s s Until now: experimentation and design Starting now: the road to production Security Serialisation Scalability Finishing the features HyperLedger London p29.

30 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 HyperLedger London p30.

31 Goal API and protocol stability by EOQ p31.