information out of Ethereum, Ethereum’s event/logging framework was used. Exceptions contain no information so it is hard to use them for situations in which there are many error cases. All of this meant that to understand what happened to a payment the system essentially: • submitted the sendPayment method call request and got back a transaction id • polled the logs looking for the corresponding event • read the event to understand what had happened to the call • used the bespoke returnType field to understand what the outcome was Testing the contract was relatively easy. Initially, Truffle had a built-in framework that worked well with ethereumjs-testrpc. Later, some integration tests using the docker images were built. Performance Testing Initial performance testing focussed on results, rather than total understanding. As such, a path was picked through the solution space that led to a result consistent with a small domestic payment system. With more work, it is believed that higher volume payment systems might be achievable. Issues found have been noted for further investigation. What was Tested? The plan was to run one stack (ISO Broker, RabbitMQ, Payment Service, Geth (ethereum node)) per bank. During the test, transactions to other banks would be submitted to all banks. To simplify results gathering, the time measured was that from when the payment was submitted to when the receiving bank was alerted to the payment. The aim was to get this well under 10 seconds with the system coping with 100 transactions per second entering the network. Test Setup 15 Containerised stacks were deployed on Google Cloud Platform using Kubernetes , which allowed for easy horizontal scaling and topology changes. The timing of transactions was measured by comparing log timestamps from different transaction phases. Google’s Big Query was used to aggregate the desired statistics. GFT prepared an automated, multimode Ethereum network deployment, which allowed for testing various topologies. The initialisation procedure of the bank stack supplied by RBS’ engineers was woven into the setup. Every test run was preceded by a fresh deployment of a new Ethereum blockchain, ensuring its initial state remained constant in every case. 16 The frequency and volume of requests sent to the stack were orchestrated using JMeter in distributed mode. During testing, GFT explored many different topologies. The setup that gave the best performance had: • 1 mining node • 1 node per bank stack • all the nodes connected to all other nodes (full mesh network) 5