More Testing To further prove Ethereum in this use case, the next step would be to delve into the mined time to event time issue. In order to identify the next series of bottlenecks, there are several things to be explored here: • Is the network being stressed? If so, is it blocks or transaction related? • How to optimise block propagation? • Do more, smaller blocks perform better than fewer, bigger blocks? • The non-mining clients have to run the transactions on receipt of the block they are in to establish the end state of the block and generate the log messages - do they need more CPU? • Disk issues? Logging etc? This would need to be driven by an actual use case as the domain this is to be deployed in will define many of the requirements and possibly the topology of the application across banks. Fork or Contribute to Ethereum Ethereum is very much aimed at being a public system. Many of Emerald’s requirements are at odds with the broad direction Ethereum is taking. That said, it would be immensely powerful to extend Ethereum to support both use cases. Some conversations with the core Ethereum team would resolve whether contributing or forking would make the most sense. State Channels Global consensus blockchains have inherent performance issues due to the need to get all the information out to everyone all the time. However, given that the model represents many bilateral relationships which are independent of each other, what level of global consensus is required? In a recent paper written by Vitalik Buterin19, co-founder of Ethereum, he pointed out that using state channels to take most of the actual transactions off the blockchain could result in many orders of magnitude of performance improvements. The broad idea is that clients agree off chain on the current state and periodically the latest agreed state is updated to the chain. The period is something which could be defined at the network level or bilaterally. The “agreement on state” process involves an ordered sequence of states being signed by both parties - essentially containing the new balance between them. If there is ever an argument about the current state then a contract can be written that allows the highest sequence number signed by both parties that either of them can present to the ledger to be used to update the ledger. It is a very elegant way of speeding things up at a cost of some complexity, e.g. how do you setup 20 21 the state channels? Something similar is being done on Bitcoin by the Lightning Network . Other Technologies Not necessarily needing global consensus (at least in the DNS use case) might allow for other technologies to be considered. 22 23 24 R3 Corda, Big Chain DB , Hyperledger and Interledger are possible alternative technologies that take very different approaches that might be more appropriate. 8