Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

R3 Corda: Distributed ledger for Fintech applications Anton Sitnikov Chief Software Architect, Exactpro LLC

Slide 3

Slide 3 text

Exactpro • A specialist firm focused on functional and non functional testing of exchanges, clearing houses, depositories and other market infrastructures • Incorporated in 2009 with 10 people, our company has experienced significant growth as satisfied clients require more services; now employing 550 specialists. • Part of London Stock Exchange Group (LSEG) from May 2015 till January 2018. Exactpro management buyout from LSEG in January 2018. Headquartered in UK, with operations in US, Georgia and Russia. • We provide software testing services for mission critical technology that underpins global financial markets. Our clients are regulated by FCA, Bank of England and their counterparts from other countries.

Slide 4

Slide 4 text

DLT alliances

Slide 5

Slide 5 text

Corda ● A Corda network is an authenticated peer-to-peer network of nodes, where each node is a JVM run-time environment hosting Corda services and executing applications known as CorDapps. ● All communication between nodes is direct, with TLS-encrypted messages sent over AMQP/1.0. This means that data is shared only on a need-to-know basis; in Corda, there are no global broadcasts. ● Corda networks are semi-private. Each network has a identity service that enforces rules regarding the information that nodes must provide and the know-your-customer processes that they must complete before being admitted to the network.

Slide 6

Slide 6 text

Corda 1 6 7 5 2 3 4 9 8

Slide 7

Slide 7 text

Network and Identity • Identities are attested to by X.509 certificate • Well known identities are published in the network map • Confidential identities are only shared on a need to know basis

Slide 8

Slide 8 text

State CASH CONTRACT REF PARTICIPANTS Alice Bob CASH STATE PROPERTIES OWNER: AMOUNT: CURRENCY: Alice 10 USD

Slide 9

Slide 9 text

State sequence NO CASH GEL 100 GEL 50 2019-02-01 timeline 2019-02-24 HISTORIC

Slide 10

Slide 10 text

Vault BHEAD CHEAD AHEAD SHEAD B1 A3 S2 B0 A2 S1 A1 S0 A0 HISTORIC CONSUMED HISTORICAL STATES UNCONSUMED HISTORIC HISTORIC HISTORIC HISTORIC HISTORIC HISTORIC HISTORIC HISTORIC

Slide 11

Slide 11 text

Contract CASH 0 CASH CONTRACT CASH 1 BOND 1 BOND 2 BOND CONTRACT REFERENCES VALIDATES REFERENCES REFERENCES REFERENCES VALIDATES CASH COMMAND BOND COMMAND

Slide 12

Slide 12 text

Transaction • Is identified by a hash • Is atomic • Can have multiple input states • Can have multiple output states • Should have at least one command CASH 0 CASH 1 BOND 0 BOND 1 TRANSACTION SIG 0 SIG 1

Slide 13

Slide 13 text

Transaction validity • Transaction validity: For both the proposed transaction, and every transaction in the chain of transactions that created the current proposed transaction’s inputs: ▪ The transaction is digitally signed by all the required parties ▪ The transaction is contractually valid • Transaction uniqueness: There exists no other committed transaction that has consumed any of the inputs to our proposed transaction

Slide 14

Slide 14 text

Notary • Notaries provide uniqueness consensus which prevents “double-spends” • Notaries may optionally also validate transactions • A network can have several notaries, each running a different consensus algorithm

Slide 15

Slide 15 text

Persistence ● Vault is stored in relational database ● States are persistent as blobs, AMQP serialized ● State fields can be extracted to database columns

Slide 16

Slide 16 text

Flows INITIATOR GET DATA FROM INTERNAL SYSTEM CREATE TX RESPONDER INSPECT AND VERIFY TX SIGN TX COMMIT TX END INSPECT AND VERIFY TX COMMIT TX END SEND (TX+SIG) SEND (TX+SIG) FLOW SUSPENDED AND CHECKPOINTED

Slide 17

Slide 17 text

Questions?

Slide 18

Slide 18 text

Thank you!