Intro to R3 R3 Engineering 05/12/16.
How is R3 enabling collaboration? Most Start-ups: Create a Market it and Refine it Product sell it (maybe) R3: Collaborate on Create a requirements; Build it together Consortium open source 1400 + 70+ global passionate institutions people
R3 Global Members
Bridging the gap towards mainstream adoption Tipping Point We are here Main Stream Collaboration Early Scaled Deployments POCs Deployments Governance Collaboration Early Technology Adoptions “The Norm” Hype Market Building Regulation Interfaces Value Blocks Standards Talk Definition
Consortium Projects
The Empire Strikes Back! December 6 th 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 • 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* Corda @ HyperLedger London p11.
p12.
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. Corda @ HyperLedger London p13.
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. Corda @ HyperLedger London p14.
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 How? the database • Uses fibers behind the scenes 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 enforced everywhere • strictfp • 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 • S ecurity • S erialisation • S calability • Finishing the feature s 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.
Goal API and protocol stability by EOQ3 2017 p31.
Recommend
More recommend
