Testing initially used geth 1.4.3 and later switched to 1.4.7 to pick up some block syncing performance improvements (though this uncovered some Ethereum issues). The very different use case for Emerald meant that some code changes were required to hit the targets. Issues Faced The following is a high level list of issues faced during testing: BlockTime - this is hard coded to 13 seconds in Ethereum and damping means that while it is possible to start with a low difficulty to achieve fast block times, this trends upwards over time. To help with this, the DurationLimit was set to 2 in protocol_params.go. Second Time Resolution - due to Ethereum having a target block time of 13 seconds, it only needs second time resolution. It guards against blocks getting too far into the future by pausing. When block times are less than 1 second, this gets invoked fairly quickly. It was decided that it was safer to turn off the guards, rather than port Ethereum to millisecond resolution, given the timescales. Small changes were made in worker.go and block_validator.go to remove this and BlockFutureErr as issues. Forks - as block times diminished, running multiple miners started mining blocks at the same time. For reasons discussed later, it was felt having one miner was a reasonable way to proceed, not least because it allows the presumption that all blocks are valid. Funding - although Emerald does not really need gas, it was necessary to continuously fund accounts to pay for the volume of work being attempted. Multiple Threads Mining - commitNewWork could be called in several ways that sometimes resulted in two threads mining the same block with slightly different sets of transactions in. This was turned off in worker.go. Damping - one new block every second would be appropriate. Damping is not needed for this use case so to increase stability difficulty was hard coded (block_validator.go). Blocks from Same Source - with only one miner, all the blocks come from one source. Ethereum guards against this so the hashLimit and blockLimit were changed in fetcher.go. Logging and Metrics Capture - these were turned off to help - certainly high log levels stressed performance though this might have been related to the disks in the VMs being used. Block Syncing Times - block sync times seemed to be the limiting factor - getting the blocks out to the nodes. This needs the most investigation going forwards. Results The best results achieved were for a 6 node setup - thus emulating a small domestic setup with 6 banks, with 100 transactions entering the network each second, spread across the banks. In this setup a steady state was achieved with the following transaction times: • minimum - 665 milliseconds • mean - 2805 milliseconds • maximum - 8085 milliseconds 6