Peter Lawrey, CEO of Chronicle Accelerate, discusses building a digital currency framework using Java, emphasizing performance and throughput improvements for blockchain technologies. The framework targets high transaction speeds, claiming the capability to exceed 400,000 transactions per second with strategies for optimization and fraud protection. The document outlines a roadmap for development and highlights the need for a competitive solution that supports multiple currencies and scales effectively.

1. Building a Digital Currency
Peter Lawrey – CEO
19 Apr 2018
Chronicle Accelerate

2. Peter Lawrey
Java Developer / Consultant for
investment banks and hedge funds.
25 years in IT.
CEO for 5 years

3. Major Banks use
Chronicle’s framework to build
low latency, high throughput
trading systems in Java.
We believe we can make a difference
by bringing HFT to blockchain

4. 5 years old, self funded
Core software is open source
Projects have over 1000 stars

5. Agenda
• Digital currency economics
• Existing solutions
• Architecting for performance
• A Java model for extension

6. BTC, XBC
- All tokens mined
- Reward decreases
exponentially
- Miners also receive
fees

7. ETH
- Initial tokens
- New tokens reduce
dramatically over
time
- Fees for mines

8. IOTA, MIOTA
- All preallocated
- 2.7 ^ 15 IOTA
- Usually expressed as MIOTA
(1 million IOTA)

9. XRP
- All preallocated
- 60% reserved by Ripple
- Might be released over
time?

10. XCL + Fiat & Digital.
- Multiple stable currencies
- 20% preallocated for early
adopters
- 40% sold in ICO
- 40% reserved for market
volatility reduction

11. How much throughput do we need?
VisaNet handles an average
of 150 million* transactions
every day and is capable of
handling more than 24,000
transactions per
second.
* 1,740/s

12. How much throughput do we get today?
3 – 7
txn/sec
500 – 1500
txn/sec

13. How does our block chain perform?
Single Server Nodes
i7-7820X, 8 core, 32 GB
Burst
480,000 trans/sec
Sustained
52,000 trans/sec

14. How does our block chain perform?
Multi-server nodes
i7-7820X, 8 core, 32 GB
Burst
millions trans/sec
Sustained
400,000 trans/sec

15. C-like Java framework,
Assembly sign/verify,
Optimal use of hardware,
Core for speed
and gateways for
integration.

16. Why use Java?
Java brings millions of devs, reasonable speed.
C or assembly is harder but faster
The interesting code is in Java, but most of the
CPU work is in assembly and C
Code type CPUs
Assembly (Ed25519) 40
Operating System (Mostly TCP) 24
Java 4

17. Achieving Consensus
Each node runs concurrently as much as possible
Periodically they;
- Gossip about what has been replicated
- Vote on what to include in a round
- When the majority vote the same, progress

19. Blockchain vs distributed ledger
When running trusted nodes, you don’t need the
overhead of signatures -> distributed ledger (or
database)
When running untrusted nodes, you need to
ensure they don’t act fraudulently -> blockchain.

20. Fraud Protection
Each message is signed is a way that only the
private key holder can create. This can be verified
using the public key.
In our case we use Ed25519 which has a highly
optimized 256-bit public/private key and a 64-byte
signature.

21. Optimising for Throughput
A key optimization for throughput is batching in to
blocks. We use rounds to achieve consensus and
blocks increase the number of transactions in
each round.

22. Optimising for Throughput
Concurrent Serial
Sign/verify Consensus
Client TCP Transaction
processing

23. Weekly Checkpointing
Replaying from the genesis block doesn’t scale.
Ok for 10 trns/sec
Not Ok for 100,000 trns/sec
We chose to checkpoint weekly
NOTE: GDPR requires the ability to be forgotten

24. Multichain
Localize transaction using ISO-3166
Over 4000 regions / sub-chains.

25. Smarter Sharding
If you use hash based sharing, you get fairness
however you get no benefit from locality of use.
Most transactions occur between parties in a
small number of regions (possibly one most of the
time)

26. Smarter Sharding
We use ISO 3166 which breaks the world 4000+
regions.
The region is at the top of the address when is in
base32 e.g.
@usny6db2yfdjs – New York, US
@auvickjhj4hs3f – Victoria, AUS

27. Smarter Sharding
We start with a single chain for the whole world.
As the number of nodes grows, we can split the
chain by the highest bit in 2. Each chain can split
in 2 etc until we have 4000+ chains

28. Multichain
Grow to 10 to 100 nodes.
More nodes means more
sub-chains.
Aggregate volume to over
100 million per second.

29. FIX protocol for
traditional market integration

30. AI managed exchanges
to reduce volatility

31. Roadmap
Q1 2018 – Working prototype
Q2 2018 – increase throughput to
500K/s/sub-chain
Test System running.
Pre-ICO investment
Q3 2018 – ICO
Q4 2018 - production

32. Extending the platform
In active development now.
Extension is via sub-chains, main chain rarely
changes
Programming is in Java to make it more
accessible to more developers.

33. Extending the platform
Key components to supply;
- The Data Transfer Object to hold the
transactions. Supports YAML or Binary.
- Pre blockchain stage, run on a per client
basis. Can handle queries which don’t go to
the blockchain.
- Post blockchain stage, run by all nodes in the
cluster, recorded in the distributed legder.

35. package cash.xcl.helloworld;
public interface HelloWorld {
void hello(TextMessage textMessage);
}

36. public class TextMessage extends SignedTextMessage {
private long toAddress;
private String text;
public long toAddress() { return toAddress; }
public String text() { return text; }
public TextMessage toAddress(long toAddress) {
this.toAddress = toAddress;
return this;
}
public TextMessage text(String text) {
this.text = text;
return this;
}

37. public class HelloWorldGateway implements HelloWorld {
private final ErrorMessageLogger client;
private final HelloWorld blockchain;
public HelloWorldGateway(ErrorMessageLogger client,
HelloWorld blockchain) {
this.client = client;
this.blockchain = blockchain;
}
@Override
public void hello(TextMessage textMessage) {
if (textMessage.text() == null || textMessage.text().isEmpty())
client.commandFailedEvent(
new CommandFailedEvent(textMessage,
"text must be set"));
else
blockchain.hello(textMessage);
}
}

38. public class HelloWorldBlockchainProcessor implements HelloWorld {
final MessageLookup<HelloWorld> lookup;
public HelloWorldBlockchainProcessor(
MessageLookup<HelloWorld> lookup) {
this.lookup = lookup;
}
@Override
public void hello(TextMessage textMessage) {
lookup.to(textMessage.toAddress())
.hello(textMessage);
}
}

39. @Test
public void testMarshalling() {
TextMessage tm = new TextMessage(
XCLBase32.decode("my.friend"),
"Hello World");
assertEquals(
"!TextMessage {n" +
" sourceAddress: .,n" +
" eventTime: 0,n" +
" toAddress: my.friend,n" +
" text: Hello Worldn" +
"}n", tm.toString());
TextMessage tm2 = Marshallable.fromString(tm.toString());
assertEquals(tm, tm2);
}

40. @Test
public void testHelloWorldGateway() {
ErrorMessageLogger logger = createMock(ErrorMessageLogger.class);
HelloWorld hello = EasyMock.createMock(HelloWorld.class);
MessageLookup<HelloWorld> lookup = to -> {
assertEquals(2002, to);
return hello;
};
HelloWorldBlockchainProcessor proc =
new HelloWorldBlockchainProcessor(lookup);
HelloWorldGateway gateway = new HelloWorldGateway(logger, proc);
hello.hello(new TextMessage(2002, "Hello World"));
EasyMock.replay();
gateway.hello(new TextMessage(2002, "Hello World"));
EasyMock.verify();
}

41. Data driven tests
hello: {
sourceAddress: my.address,
eventTime: 0,
toAddress: my.friend,
text: !!null ""
}
---
hello: {
sourceAddress: my.address,
eventTime: 0,
toAddress: my.friend,
text: "Hello, How are you?"
}
---

42. commandFailedEvent: {
sourceAddress: .,
eventTime: 0,
origSourceAddress: my.address,
origEventTime: 0,
origProtocol: !!null "",
origMessageType: hello,
reason: text must be set
}
---
hello: {
sourceAddress: my.address,
eventTime: 0,
toAddress: my.friend,
text: "Hello, How are you?"
}
---

44. Q & A
Blog: http://vanilla-java.github.io/
http://chronicle-accelerate.com
enquiries@chronicle-accelerate.com
https://github.com/OpenHFT/Chronicle-Accelerate
Australia/APAC Contact
jerry.shea@chronicle.software