R3 Corda: Distributed ledger for Fintech applications

Anton Sitnikov Chief Software Architect, Exactpro

GDG DevFest, Tbilisi
08.09.2019

Youtube Channel https://www.youtube.com/c/exactprosystems
Linkedin https://www.linkedin.com/company/exactpro-systems-llc
Instagram https://www.instagram.com/qakostroma/
Twitter https://twitter.com/exactpro

Transcript

2. R3 Corda: Distributed ledger for Fintech applications Anton Sitnikov Chief Software Architect, Exactpro LLC
3. 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.
4. DLT alliances
5. 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.
6. Corda 1 6 7 5 2 3 4 9 8
7. 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
8. State CASH CONTRACT REF PARTICIPANTS Alice Bob CASH STATE PROPERTIES OWNER: AMOUNT: CURRENCY: Alice 10 USD
9. State sequence NO CASH GEL 100 GEL 50 2019-02-01 timeline 2019-02-24 HISTORIC
10. 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
11. Contract CASH 0 CASH CONTRACT CASH 1 BOND 1 BOND 2 BOND CONTRACT REFERENCES VALIDATES REFERENCES REFERENCES REFERENCES VALIDATES CASH COMMAND BOND COMMAND
12. 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
13. 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
14. 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
15. Persistence • Vault is stored in relational database • States are persistent as blobs, AMQP serialized • State fields can be extracted to database columns
16. 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
17. Questions?
18. Thank you!