Top Rated Pune Call Girls Pashan â 6297143586 â Call Me For Genuine Sex Serv...
Â
Chronicle accelerate building a digital currency
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
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
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
18.
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.
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
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.
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.