It could turn out to be a defining moment in the history of Blockchain. 19 April saw the most significant capital markets test so far, of a distributed ledger platform, when Barclays used the stage of the O2 arena in London to demonstrate how its smart contract templates for ISDA interest rates swaps could be executed on Corda, the smart contract platform from R3, a consortium of more than 40 banks that have pooled resources to develop Blockchain technology.
It wasn’t just the un-bank-like fanfare around the swaps trial that attracted attention. There are other Blockchain platforms out there: Blythe Masters’ Digital Asset Holdings, for example, has attracted plenty of publicity.
But R3 embraces the largest names in banking, including Barclays (which hosted the ISDA trial), Credit Suisse, Goldman Sachs, JP Morgan, RBS and UBS. The consortium, headquartered in New York and headed by former ICAP CEO of electronic broking, David Rutter, allows participation by the IT and business departments of its member banks.
Unlike other distributed ledger technologies, Corda does not share information about trades throughout the entire network, however many counterparties that might involve. Rather, the information is only available between the seller and the end-buyer and other parties with a legitimate need to know. This, says R3, makes Corda particularly suited for the wholesale financial markets and that’s why James Carlyle, R3’s chief engineer, prefers to use the description ‘shared ledger’ rather than ‘distributed ledger’ when he’s talking about the potential for Blockchain in those markets.
QA-Financial.com met with Carlyle, (formerly chief engineer at Barclays before he moved to his new role in at R3 in November 2015), to discuss where Blockchain goes from here. In particular, we asked how Blockchain platforms and contracts will be tested; not just by R3, but by every investment bank that believes that Blockchain technologies really do hold the key to cheaper, more efficient capital markets transactions.
James, the Corda trial was perhaps the most significant public demonstration of the potential of Blockchain in capital markets we’ve seen so far. But where are we on the curve of development and testing of smart contracts?
Testing for smart contract platforms is immature because the platforms themselves are immature. When I started writing Ethereum smart contracts a year ago [Ethereum has been, to date, the most prominent smart contract platform], my testing consisted of sending transactions to a contract and then validating the state of the contract by querying it. In other words: very rudimentary, very labour intensive; manual testing. I quickly realised that automated testing is as important for smart contract platforms as it is for any other kind of software.
There has been a dramatic change in the past year. Since the end of the first quarter of 2015, people started working on automated testing frameworks for Ethereum. Now anyone building smart contract platforms, or even designing the smart contracts themselves, is thinking about automated testing. The smart contract world has caught up, in a sense, with the traditional software engineering world, so there are now multiple smart contract testing frameworks for Ethereum.
Having said that, test automation is still coming. It is still not generally available for all forms of testing.
What tools is R3 using for testing?
By the summer of last year I had started automated testing. I was using the Truffle Framework, which is a scaffolding framework for smart contracts used by UI builders, but which I was using for test automation. Truffle uses a JavaScript-based approach whereby an Ethereum contract can be deployed onto the network. And there is a well-known Ethereum library called web3, which allows JavaScript clients to formulate requests to the Ethereum network. The Truffle Framework allows for unit-tests to be specified using standard JavaScript assertion libraries, and those get translated into calls via web3 to the Ethereum network. Truffle works in a way that people who have built test automation for web frameworks, like AngularJS, would understand.
The alternative, and more recent, approach was proposed by the people at Eris (Eris Industries, the New York-based smart contract software design firm). They suggested testing Ethereum contracts using other Ethereum contracts. You still need scripted interactions to kick the process off, but effectively the test logic is built into the contracts themselves.
We have taken a test-driven approach with our own Corda platform. This is not, formally speaking, test-driven development, but we automate all our testing and we have a very high calibre of engineering staff that follow best practice in terms of test automation. The message is that everyone, regardless of the platform they are writing on, should be thinking of testing.
What do you need to automate the testing of smart contracts?
Test automation requires that the platform being tested must have hooks so that external automated scripts can instruct the platform, observe the outcome, and verify that the outcome is what is expected. Legacy platforms in banking often do not have these hooks, and that makes automation much more difficult. When you compare smart contracts to older software used in banks, I think we can automate testing much earlier and much faster.
And there is a much greater appreciation of automation among the engineers working on shared ledger technology. They now have toolkits for standard-build processes and assertion libraries in JavaScript. These will be re-used and it makes the adoption much faster. All that people have to think about is that final step: making the bridge between an existing JavaScript assertion library and the smart contract platform.
So a smart contract platform can be designed with a view to test automation?
Yes. When you start thinking about test automation, then the functions that the contract exposes to the outside world change, and therefore the structure of the contract changes. At the moment, tutorials for building Blockchain contracts cover the different types of contract without considering testability - ‘this is a voting contract’ or ‘this is a currency contract’, and so on. Testing will be one of the factors that drives contracts to be composable; to become frameworks rather than just simple monolithic contracts.
Another observation is that a year ago I was writing contracts that I thought were operating correctly. But when I subsequently came back and wrote automated tests for them I realised they were full of bugs. The act of writing automated tests for these smart contracts helps greatly in ensuring that they work properly.
Tell us a little more about the smart contract test for interest rate swaps that Barclays conducted in cooperation with R3.
What Barclays showed there was a prototype that allowed an ISDA legal prose contract to be annotated and parameterised, and we then used Corda to simulate the contract execution, in this case an interest rate swap. In terms of maturity, the work we did for the interest rate swap contract was rudimentary. When comparing it with an industrial-grade smart contract it was only about 50 per cent in terms of its capabilities. This was an attempt to create a minimum viable contract that worked.
What makes Corda unique?
The evolution of Corda has been different. Other platform developers have been focused on distributed ledger platforms that are transparent. They have promoted that transparency as one of the key selling-points of their platforms. For example, in Ethereum every node sees every transaction, and the internal data of contracts is visible to all participants. Also, anyone can join the public network. While this definitely makes sense for certain markets, where the information should be public, it makes protecting privacy in commercial deals very difficult. Corda starts out with the idea that for banks and their customers, privacy is important, and so it does not seek to distribute full data to all participants, but does allow privileged visibility to regulators.
Personally I am starting to use the term ‘shared ledger’ rather than ‘distributed ledger’. The key outcome remains that the ledger is authoritative to the parties involved - that is to say, they know that what they see is what the other party sees. We are evolving beyond the term ‘distributed’ because we are arguing that it is not necessary to distribute everything to everyone. That would present a privacy problem.
How are you testing Corda?
The idea is to use off-the-shelf test capabilities to automate testing of all the processes. There are unit tests written by developers, and then there are end-to-end interaction tests between multiple parties involved, and both tests are important. They isolate different aspects of functionality.
Having said that we are still exploring ideas about what the platform might look like. By comparison, Ethereum took 18 months to get from initial inception and yellow paper through to a production network. It will take the same amount of time before we would say Corda has the same level of maturity. It is still in the prototype stage.
Will the focus at R3 be on Corda rather than other platforms moving forward?
The position we take is that we do not think one platform or one approach will be suitable for all use cases. We are presenting and educating consortium members on different options. The banks themselves have been exploring different technologies. UBS, for example, last year ran an experiment with smart-bonds. And the platforms themselves are evolving.
We have two objectives: to bring the requirements of the banks to platform providers so they understand how to evolve those platforms, and to explore with the banks the platforms and their capabilities. That is important when the platform is brand new, such as Intel’s Sawtooth Lake distributed ledger platform.
Previously if banks were interested in a particular platform they would pay a provider to do bespoke work and run an experiment. What we are arguing is that it is cheaper and more efficient to do it in a shared way. Then the set-up costs of the experiment can be amortised.
As you said, ISDA interest rate swaps are relatively simple because, although they are backed by complex legal agreements, they are conducted between two counterparties over-the-counter. Applying Blockchain to the European banking payments system would be far more complex. So how will Blockchain contracts be applied more broadly to financial markets?
I would say at the moment there is not a firm agreement on which financial products would likely be deployed first. More works needs to be done by the banks to build their own business cases. Ultimately the business case is particular to the individual bank. Each bank has its own set of costs, and different levels of efficiency within its existing operations.
I think a key factor is where current operational costs lie, and where efficiencies can be made. Building a business case runs in parallel with the development of the technology. Neither of those is a trivial exercise. In large scale projects, actually figuring out the operating model takes the same amount of work as figuring out the software implementation to support it. And in terms of changing people, the culture and practices, the lead time is the same.
What is next after the swap contracts?
Banks will be moving forward with more smart contract testing. The focus is on setting out the parameters in contracts written in prose, and then automatically deploying them on a smart contract platform. The reason they want to automate the prose aspects, as well as the code aspects, is to improve the quality assurance process and reduce the cost of manual checking by lawyers. So what banks are trying to do is move automation upstream and automate the legal work as well. The dream is to eventually have end-to-end automation and end-to-end quality assurance, removing the opportunity for humans to make mistakes.
As far as Corda is concerned, one of the things we are doing is more work on our continuous integration processes, and this is the natural evolution for any software delivery process. But we will continue to work at the level of unit test suites run on development machines.
This is all done in-house at banks in the consortium?
For Corda, we have growing contributions from banks and their developers, but the main effort is done by our small development team at R3. We apply the same quality of testing regardless who contributes the code. Our developers have a total obsession with possible failure mechanisms and attack vectors. There is the assumption that what can go wrong will go wrong. That upsets people who think it is possible to write prototype code in a relaxed manner. But our conviction is that the cost of building quality in at source is very low, while the cost of imposing quality later is much higher. From a quality assurance perspective, we do worry about every line of code we write and review.
Are regulatory bodies advising you in what you should be doing in the QA process for developing Blockchain?
Not yet. Certain central banks and regulators are more advanced than others in terms of their appreciation of Blockchain technology, but that advice will come later. It is not to say that they will not be concerned about it. I think they are still thinking generally how Blockchains can be best used, and what it means for them as a regulator. The quality aspects of the code are for a later conversation.
At what point will we see quality assurance teams get involved in the process of testing smart contracts?
There are many different test phases. User acceptance testing is still a way away because at the moment we are still looking at how business processes might be impacted or exactly who the users are. Clearly it is not possible to do user acceptance testing with this uncertainty.
Even reliability and performance testing are some way away. Again, it depends on the platform involved. The Ethereum platform itself was put under a degree of performance testing before it was released in August 2015. Transactions were pumped into the network and to test the point that block propagation to nodes in the network started to fail. How does that work? There are always nodes not up-to-date with all the blocks, but as the transaction rate increases the percentage of nodes that fail to keep up increases. That gave them a baseline for what kind of transaction rate they could expect to support.
Banks are still looking at different platforms, some of which are undertaking some sort of performance testing. But I do not think banks are doing more performance testing than the platform developers themselves at this point. It is too early.
Where will smart contracts be 12 months from now?
I think in a year’s time the industry will have deployed some pilot schemes. By pilots, I mean examples where the use case is identified, the users are identified, the process is identified, and value is being exchanged or controlled. It is real value, and therefore the regulators need to be involved, but if there is failure it is not catastrophic.
There might be limited reputational impact if things fail at this point, but not significant financial loss. Pilot implementations imply a degree of responsibility by the involved parties. It is under the scrutiny of others. There is a world of difference building some smart contracts in order to learn, with zero impact, and moving to something where the output has to be reported.
Testing a smart contract platform like Ethereum is a specialised skill, but the general practices of testing are the same. Getting up-to-speed is not particularly hard, but it is a multi-month process. I think banks have recognised the need to build test capability.
But what we have learned about automation is that the more the system is automated, the better the software has to be from a quality assurance perspective. Self-executing smart contracts have a couple of characteristics, and one of them is that they operate beyond the immediate control of humans. Therefore, if there is a bug within them, it will impact the results. There is not necessarily any oversight of what the contract is doing or a human step of verification in the process. That means that quality assurance becomes very important. And since the value traded on the platforms can be very large, the financial loss can potentially be much greater.
What enables a CIO to sign off a smart contract platform? It has to have been tested in ‘the wild’ and have withstood daily use and attacks. But, at this stage, both the maturity of the underlying platforms and some privacy-preserving encryption techniques are issues that still have to be fully resolved. These need to be shown to be reliable before large scale adoption is possible.
