JPMorgan’s distributed ledger project "Juno" was unveiled at the latest meeting of the Linux Foundation’s Hyperledger Project steering committee on March 3. The Project is exploring developing an open source blockchain.
At the meeting, JPMorgan Executive Director David Voell revealed that the bank has been working on Juno since September. The prototype was presented by Will Martino, one of the developers of the project.
Martino said the team had considered methods besides proof of work and proof of stake, and began Juno from a fork of the Haskell implementation of Tangaroa, a Byzantine Fault Tolerant implementation of the consensus algorithm Raft.
He mentioned that as Juno doesn’t require anonymous participation, this has been explicitly disabled. Use of Tangaroa also removes the need for mining.
Using the Raft protocol as a basis allows a cluster of servers to order messages and distribute them to the network. Within the network, election of a "Leader" ensures that consensus can be reached among the "Followers." Martino explained that as Juno requires only consensus on inputs and not outputs, slow nodes are less likely to slow down the whole system.
When messages transmitted within the network have been ordered and replicated, they are interpreted by a replicated state machine. Juno allows the Leader to feed an input into the state machine when an entry has been replicated by the majority of nodes.
Juno is making use of a language named Hopper in its replicated state machine in order to run smart contracts. The language is still in development. When complete, it is expected to be sequentially consistent, fully deterministic, completely serializable, and will include a measure of execution cost.
For the immutable ledger itself, the JPMorgan team has not gone for Bitcoin-style Merkle trees. Instead, they use a Tangaroa-style incrementally hashed log of entries. This essentially creates a blockchain of single transaction blocks, reducing the potential for forking. The team is currently considering whether to further secure the log through a hash at checkpoints at set times, or to use a hash several steps behind the latest transaction.
The team has identified issues that would require human input to fix, including differences in incremental hashes among Followers in the network.
Considering the debate over blockchain capacity in the Bitcoin network, scalability is, of course, the elephant in the room. With an un-optimized instance running on a MacBook Pro, Juno managed throughput of consensus of 500 per second, and 2ms latency of consensus. This is very big news. Due to restrictions in its block size, Bitcoin can process only up to seven transactions per second. In comparison, Visa’s network processes on average around 2,000 transactions per second.
The Juno team forecasts two to three times its current performance with basic optimizations including GC tuning, batching log entries and messaging layer configuration.
A stable version of the code has been posted on GitHub for anyone considering trying it. According to the JPMorgan team, the open source version performs slightly worse than the internal version used in tests.
The features the JPMorgan team hopes to include in the next release of Juno include additional node states, integrated client command HTTP servers, persistence via SQLite, and system monitoring integration.