Learnings Bearing in mind that the Ethereum platform has not been aimed at this use case before, the results have been encouraging. Clearly, more investigation needs to be undertaken to make this work at scale. Most interesting was that a lot of the complexity in Ethereum is not needed in this private network use case. Gas - is used in Ethereum to stop infinite loops taking out the whole network. However, Emerald only has a small number of well-tested contracts. The need for a gas-like concept tracking the cost of operations (it is not possible to tell in advance whether a program will complete) led to the development of the EVM (Ethereum Virtual Machine) and to solidity. Not needing this concept 17 means that in principle Emerald could use the richer and more mature JVM and perhaps Java rather than Solidity. Gas is probably part of the reason that transactions seem to be run twice on each mining node. Damping - is not needed in the Emerald use case. Fixed block times would make the system much more predictable. Proof of Work - is an amazing concept that allowed Bitcoin to solve the double spend problem by creating distributed consensus about the order in which transactions are applied to the blockchain. A key point is that it costs so much (kit, electricity) that miners are incentivised to make sure that the Bitcoins they get rewarded with for mining a block maintain their value - i.e. they will not cheat. At its heart, it is a way of a dictator electing themselves so that they can say “I am going to put these specific transactions, in this order, in the next block”. The election involves solving an, on average, hugely compute-intensive problem. This works fine when the amount of work to find the next block is massive - but Emerald needs small, consistent block times. Arguably, the trust issues that lead to the need for proof of work do not exist in the payments world - for example, a bank is trusted to put the right amount for a payment in the destination account, so banks implicitly trust each other right now. A much simpler round-robin-based approach might be more suitable for Emerald - each bank taking it in turn to pick the transactions into the next block. 18 This is discussed much more thoroughly in R3’s excellent “Introducing R3 Corda” white paper . Mined Time To Event Time - most of the time lost was between a transaction being mined in a block and then the event being fired on the two nodes that care about this event (payer and payee). Next Steps There are several possible paths that can be explored as next steps to improve performance: • More testing • Fork or Contribute to Ethereum • State Channels • Look at other technology 7