Demo RTGS on Corda

(Marcus Vinícius Cursino Suares) #1


I just started to study Corda and trying to think about how to make a simple RTGS system with two banks and a central bank. I am thinking about using the Bank of Corda demo as a baseline. The central bank will issue the current balance to the banks as cash, then the banks can start transferring money to each other, using the central bank as notary.
I need that the central bank receives a copy of all transactions, but as I understood, the notary only validates the transaction, so I need to create/change a flow to send a copy of the transaction to the central bank so he can see what is happening.

Is that making any sense? Is it a good approach?

(Mike Hearn) #2

Is your requirement that the “central bank” learns about all transactions eventually, or controls all transactions in real time?

A notary is intended to be a distributed thing. A single organisation notary is technically possible and we provide an implementation of that for testing, but at that point, you are getting close to the point where you could just have the CB host a regular database as done today (unless you wish to combine this app with other kinds of transaction/smart contract that are more decentralised).

I think it’s important to keep in mind with any blockchain inspired distributed platform that these tools are only helpful if you’re willing to distribute social power, at least to some extent. If your requirement is “entity X sees all data and controls all changes” then a distributed ledger is the wrong tool to use, almost by definition, because you have a hard requirement that the system not be decentralised.

If your requirement is simply to CC a repository on all transactions, and you aren’t worried about technical enforcement of that (parties are trusted to report), then you can indeed just append something like

send(signedTx, repositoryParty)

to a flow after the transaction is notarised. I’m actually changing and hopefully simplifying the transaction commit APIs at the moment and you’ll probably be able to specify extra participants when committing/notarising a transaction.

(Marcus Vinícius Cursino Suares) #3

Hi Mike, thanks for the reply.

My requirement is that the central bank must only see all transactions, so I think that the append in the flow will work for me.

I thought that the central bank would control only how much cash each bank has, issuing it before the banks can start trading. After that, the central bank will have no control over the system, just monitor the transactions.

I understood about the notary and I will include at least one more notary node in my proof of concept, trying to use a Raft-based scheme.

(Nick Fett) #4

Thanks for the answer Mike, on that note, is there any situation where a single org notary would be more efficient than (or even as efficient as) a regular database? Could maybe it be worth it from a data sharing or regulatory reporting synchronization standpoint?

(Mike Hearn) #5

Marcus, yes, that sounds right to me. At the moment there’s no way to force a transaction to be sent to a particular party, but we’ve been looking at ways to co-opt the notaries into doing that for cases where you don’t trust parties to always file the right “paperwork”.

Nick, generally replicated systems have worse performance than single machine systems yes. Single-org notaries are supported in a technical sense, but as I said, at that point the value of a system like Corda is lower.

(Nick Fett) #6

Thanks Mike, that’s what I thought. In case you wondering though, my question came from the DTCC announcement and how if only information (as far as I know) is being transferred back and forth with the end goal of reporting it all to one node (DTCC) how this could possibly be more efficient than a single db solution.

(Mike Hearn) #7

I don’t know much about the DTCC project myself, but I think the assumption behind such deployments is that to create a global worldwide ledger, someone has to go first. And for the period of time that others are catching up, the tech will look a bit pointless or at least over-complicated because there won’t be a large number of parties transacting on the same ledger.

It is inevitable, all distributed ledger systems start like that. When I first used Bitcoin the only transaction I could make was sending money back and forth with Satoshi, there was nothing else to do. It was, at that time, something of a Rube Goldberg machine. Of course the complexity came in useful later.

(Charles) #8

@thefett hi Nick, do you mind sharing the specific DTCC announcement you are referring to ? thanks

(Nick Fett) #9

Hey charles, no specific announcement, I was just thinking about using a blockchain for reporting and clearing purposes. On the reporting purpose, the end goal is to report it to DTCC who reports it to the regulator. Unless all trades are done on the system and DTCC can just scrape the relevant info, I don’t see how setting up a blockchain type system could make it faster than an API. For the clearing purpose, I don’t know how the regulations stand on the matter, but I just imagine an issue where software at one bank is clearing the swaps of another bank. Do you have the protection before or after DTCC signs off on it? So in my mind, they’ll all have to get ‘cleared’ through the DTCC node anyway.