I joined R3 in September as our Chief Technology Officer. Regular readers may have noticed a drop-off in my blogging at precisely the same time. It turns out that joining a high-profile, fast-growing startup consumes a lot of time..!
In this post, I want to share some early thoughts and to introduce my senior leadership team. Regular readers of my blog will know that I have thought deeply and written often about the applications of blockchain and distributed ledger technology in finance. But as I set out on my journey at R3, I tried to imagine myself in a few years, sitting in front of the CIO of one of the world’s largest banks, having a conversation about our project. What would we talk about? How would I describe what we had built? How would I explain why we built it one way rather than another?
I figured it would be an extremely difficult conversation if my opening line was: “well… you know…. I built the platform like this because blockchains were cool in 2015”… No. That simply won’t do. The rules of engineering and architecture don’t fly out of the window just because somebody pulls out the “shared ledger” trump card.
If we aspire to reduce cost, free up capital, improve controls and enable innovation in finance and beyond, we need to build our vision on more than hype and hope. So I’ve gone back to basics: what properties does a technology platform need to possess if it is going to enable the world’s banks – and other firms – to deploy shared platforms to record, manage and report on their contractual agreements with each other and with their customers? What is the irreducible set of functional requirements we must provide? What are the non-negotiable non-functional requirements?
So I’ve spent my first few weeks building my leadership team, establishing an Architecture Working Group with our members and developing a detailed view on what a shared ledger for financial firms needs to look like if it’s going to gain widespread adoption and solve real business problems.
In the coming weeks, I’ll share thoughts on these questions. I’m probably wrong about huge portions of it (I usually am…). But my strong desire is to have this debate in the open: just as we’re driving this discussion with our members, we also want to debate this with other practitioners, firms and projects. Not least, because it’s manifestly obvious that a base “fabric” for the recording of financial events and execution of logic has to be open and if I can persuade you of my vision (or you can persuade me of yours…), perhaps we can work together to drive some standardisation too. Watch this space.
In the meantime, I’d like to introduce my senior leadership team.
First, I’m delighted to announce that James Carlyle, formerly Chief Engineer at Barclays Personal and Corporate Bank, is joining R3 as our Chief Engineer. He is almost too-good-to-believe: he built hugely complex systems for a hugely complex bank, founded two startups and he happens to to be one of the few people I know who can both talk about ethereum and develop for it.
Secondly, I am beyond excited that Mike Hearn has joined us as our Lead Platform Engineer. He brings half a decade of experience of blockchain and cryptocurrency development and over seven years of experience helping run some of Google’s most heavily-trafficked websites. The combination of deep understanding of blockchain technologies and real-life experience of building rock-solid internet-scale production platforms is truly unmatched in the industry. And his involvement in the recent bitcoin blocksize debate gives me confidence he can hold his own against a group of very opinionated bank architects…
Thirdly, I would like to welcome Ian Grigg, our Architecture Consultant. Ian has been building cryptographic ledger platforms for over two decades. He invented the concept of the “Ricardian Contract”, co-invented the concept of triple-entry accounting and astounds me every day with the experience and perspective he brings to the team. You would be amazed how many of the concepts in the shared ledger space today can be traced back to Ian’s work.
Fourthly, Tim Swanson joins as our Head of Research. I have to believe there are people in this space who Tim doesn’t know, but I’ve not met one yet. He teaches me every day that it’s OK to be opinionated, provided you can justify the opinions. And Tim can; his most recent report is a fascinating demonstration. I lean on him heavily for advice and insight and am delighted to have him as a colleague.
They join a fast-growing team, which also includes Jo Lang and Ayoub Naciri, amongst others.
… and what about you? We’re hiring!
We are working on the most interesting and exciting project I can imagine in technology today. We’ll be sharing details of our open roles and how to contact us shortly. In the interim, if you’re interested in working with us, I’d encourage you to think about a few questions that just might come up in interview…
- If you were building a system to enable multiple parties to come to consensus about the state of an agreement between them and maintain that in lockstep for the life of that agreement, what are some of the most important non-functional requirements you would want to explore to validate your design?
- If you were building a shared ledger system between large numbers of regulated financial entities with hugely sophisticated IT infrastructures, what would be your approach to co-existence and integration?
- What would be your answer to the CIO’s follow-up question? “Tell me… why did you build your shared ledger using a blockchain rather than another technology?”
hurrah! you’re back!
An impressive collection of people you’re gathering!
It’s a great team, Congratulations. I am a keen reader of this blog, so good to see it active again.
Not sure I agree with starting with the CIO question personally. That would be useful for an incremental or evolutionary change. Why not start with a blank slate, and ask: If I had to build this from scratch, how would I do it and why (irregardless of blockchain)? then see what it would take to make the blue-sky and reality fit.
For example, in our analysis we found that proof of work is by far the most secure and powerful foundation for a distributed ledger network, and is the key innovation that underlies the security of the network. So we decided to develop a closed chain using the Bitcoin core but with an EVM nodes to execute smart contracts (similar to RootStock but closed rather than on the Bitcoin network). Therefore, we tried to find the most optimal average mining time and actual uses for the “wasteful” mining process. As a result we found that the mining concept is quite useful in finance. While the hashing to find a nonce is wasteful in other industries, it can be a useful byproduct for finance (like HGL byproducts of petroleum refining being used to make plastic). So we found ways to utilise the generated hashes to create pools of random numbers for monte-carlo risk management models e.g. in CCR, a process which is normally very costly. Just a little example, on how starting with a blank slate gives a more divergent field of view to begin the innovation process.
Thanks for sharing, and looking forward to other new updates.
The plot thickens 🙂 Congrats on the expansion of the team, powerhouse! Mike Hearn particularly has the Bitcoin community riled up.: https://www.reddit.com/r/Bitcoin/comments/3tftas/mike_hearn_now_working_for_r3cv_blockchain/
“..we also want to debate this with other practitioners, firms and projects” – that’s the right approach, if this can both be top- down and bottom-up it has a higher chance of success.
Very curious to see how this develops, GL!
regarding the Q/A: 1) I’d study the performance issues when traversing and hopping in ipfs fractal forests of merkle patricia trees 2) nested ecosystem where the foliage and leaves are local vernaculars of ebXML, UBL, etc languages 3)because all that ” pseudonymity on public blockchains” stuff is irrelevant
Good to see you’re back Richard and that sounds like one heck of an impressive team you have there already. Looking forward to your future posts on all things blockchain.
Congrats Richard, and congrats on the not-quite-so-new job yourself (I would have commented earlier but the standard 12 month period had not yet elapsed :). Looks like a fantastic team is forming. A solid blend of cross-protocol, industry and general domain experience seems exactly the right approach. Interested on your early thoughts regarding identity management and whether you envisage some of your previous thoughts (which I agree with) being developed through R3. Consensus around a common (blockchain) standard for interoperable identity management/assurance will unify many disparate initiatives and enable the kind of govt level engagement needed for compliance and formal endorsement/adoption in line with evolving regulation for cross border IDM (e.g. EIDAS). If there is an opportunity to participate just let me know. Best -Tyler
I just love the questions from the arcticle. Let me try to answer them.
Question 1. “If you were building a system to enable multiple parties to come to consensus about the state of an agreement between them and maintain that in lockstep for the life of that agreement, what are some of the most important non-functional requirements you would want to explore to validate your design?”
It is rather difficult to answer question regarding non-functional requirements in general for some abstract multy party consensus system, but in relation to financial applications it is rather simple. I’ve talked a lot with business guys exploring different use cases for blockchain in post-trade environment, and the following list of major concerns have solidified. They all have to be addressed with corresponding non-functional requirements.
1) Security
2) Privacy
3) Performance
4) Scalability
5) Auditability
6) Provability of correctness
Question 2. “If you were building a shared ledger system between large numbers of regulated financial entities with hugely sophisticated IT infrastructures, what would be your approach to co-existence and integration?”
Shared ledger as archiecture architecture pattern do have some prerequisites to be effective:
1) It must be be considered by each party as their own sublegder used to post transactions reflecting contracts of certain type with certain counterparties (it is why non-functional requirements from above are so important).
2) This subledger should be seamlessly integrated into front/middle/back-office systems of the party. There would be three cases to be considered:
a) Integration with legacy applications. For this case I would considered development of standard integratio interfaces within shared ledger system (adapter to Oracle, for example)
b) Development of new applicaions that put shared ledger into foundation of their data layer. For this kind of integratio I would considered development of powerfull data/contract manipulation API.
c) Some standard busines functions (electronic documents exchange, for example) can be built-in into the shared ledger system itself (as standard extension). Standard business application integration approaches can be used for this case.
Question 3. “What would be your answer to the CIO’s follow-up question? “Tell me… why did you build your shared ledger using a blockchain rather than another technology?””
It is a tricky question, because at his very moment I’m not sure that blockchain (and by the way what we exactly mean saying “blockchain”? ) is the best technology for shared ledger satisfying all non-functional requirements stated above and funcional ones that are assumed. I think the answer to the question what is the best technology would be part of design work following agreement on set of requirements. So my answer to CIO would be based non results of that work.
Thanks Artem – good answers 🙂
You are welcome. It would be great to know what are your thoughts 🙂