Blockchain 3.0 project HEATLedger with its unlimited scalability releases their whitepaper 6 days before end of ICO
For anyone who may have an interest in the ICO of HEATLedger and their Blockchain 3.0 project with its unbounded vertical scalability - only limited by the performance of the hardware used - still has a chance to buy in at the early level 2 and perhaps even have an added bonus, as any remaining tokens from the assigned 25 million will be shared proportional with all investors.
Their whitepaper was released August 2nd and it may be what you need to either dig in or finally accept not for you anyways.
HEAT will end its ICO August 8th 2016.
Either way it gives more clarity on its various offerings as mentioned on their website and also as per below:
If you wish to take part in this actively by trading HEAT on OpenLedger up untill launch sometime in September, you may well profit from the option offered by ICO OpenLedger and its crowdfunding engine offering ICO subscription with a 4% subscription fee, in this way allowing you to buy into HEAT and trade the same day.
You may do so, by simply using the following link https://www.ccedk.com/ico/heat for the necessary instructions if new to OpenLedger.
If already a user you may send your funds directly to: ico.openledger account mentioning in memo: HEAT
If investor only you may go directly to HEAT official website and order from there: http://heatledger.com/ico.htm
Heuristically Enhanced Asynchronous Transactions
White Paper V1.01
D.M. de Klerk | SvanteLehtinen | Heat Ledger Ltd
2016-08-02
Directly download pdf version here as the 32 pages seems too much http://heatledger.com/HEATWhitepaper.pdf
I list the table of contentss just for clarity
Table of contents
- Introduction
- Unlimited scalability
- 2.1.Removal of embedded database
- 2.2.Use of off-heap memory
- 2.3. Split balances from transactions and blocks
- 2.4. Chain of blockchains
- Slicing of the blockchain
- 3.1. General description
- 3.2.HEAT token distribution and the genesis block
- 3.3.Details of slicing
- 3.4.Added security from PoS consensus
- 3.5.Validating the most recent blocks segment
- Networking improvements
- Real-time external replication
- 5.1.The replication layer
- 5.2.Extending the message protocol
- Real-Time Asset-to-Asset Exchange
- 6.1. Bringing Decentralized Asset Exchange to web scale
- 6.2. Colored accounts and private assets
- 6.3. Custom Asset Exchange [A2AE]
- 6.4. Crowfunding and Fiat trading gateways
- Distributed Services Architecture
- 7.1. DSA
- 7.2. Services are not smart contracts
- 7.3. Writing Distributed Services
- 7.4. Service example
- 7.5. What type of services can we expect
- 7.6. Service operator’s privileges and liabilities
- 7.7. Ability to chain services
- Smart (offline) vouchers
- E2EE off-chain messaging
- Account structure and aliases
- 10.1. HEAT account identifiers
- 10.2.Aliases
- 10.3.Empty balance pruning and temporary accounts
- 10.4. Minimum forger balance
- Account control and multi-sig
- 11.1. Protecting your stake
- 11.2. Limit on amount transferred per day
- 11.3. Multi-sig accounts
- HEAT Rewards mechanism
- 12.1. Two-tier rewards
- 12.2. How to reward block generators (PoS model)
- 12.3. How to reward blockchain storage (PoP model)
- 12.4. Each segment gets the same reward
- PoP Challenges
- 13.1.Fair beyond fair
- 13.2.The challenger account
- 13.4. Challenge Generation
- 13.5. The actual challenge
- Conclusion
- White Paper Version history
###Introduction###
HEAT Ledger is a self-appointed “Gen 3.0” cryptocurrency platform focusing on resolving the two most pressing pitfalls of the existing 2.0 and 1.0 cryptocurrency server software solutions; Low transaction rate throughput and the burden of hosting large blockchain files on any single p2p node.
Like the HEAT software itself, this document is work in progress that will be amended and expanded as the project evolves. V1.0 is designed to deliver a reasonably complete, quasi-technical treatise on the basic elements of the initial HEAT system available at the time of genesis block in September 2016.
HEAT is in part inspired by open source NXT as it uses the time proven Proof-of-Stake consensus algorithm but tuned up for 25-second blocks. Feature wise, many parts of the HEAT service offering
and middleware solutions are based on those originally developed for FIMK. On other parts the
HEAT core is fully rewritten in Java, making it optimally suited for custom financial business applications by providing microsecond latency (up to 15-30 million writes per second), vastly increased vertical scalability, and superior failover resiliency when compared to legacy datasystems.
HEAT general technical highlights:
- Written in enterprise friendly Java
- Based on secure, MIT licensed NXT for cryptography and p2p consensus code
- Architected with re-use for private chains in mind
- Optimized for speed and low memory usage
- Massively scalable through the use of not one single blockchain, but a chain of blockchains (only the last one in the chain is required on each node)
- On application level contains all the latest 2.0 cryptocurrency features and more, including custom asset-to-asset trading, distributed apps and end-to-end encrypted instant messaging.
HEAT as a cryptocurrency employs radically new approaches to the way cryptocurrencies are built, the most notable of these being complete removal of the embedded database. Another major core change consists of changes to the mechanism the network layer works. For storing the consensus blockchain, HEAT does not use single blockchain file ever increasing in size. Instead HEAT makes use of serialized blockchain files of a limited size, accompanied by small balance files. When the latest blockchain file reaches threshold size (of a few GB, specified at genesis
block) the protocol will automatically switch to a new blocks file cryptographically linked to the previous blocks & balance files. The details to achieve this are in principle rather similar to how blocks are chained to each other.
Through these radical changes to both the storage layer and the networking layer we estimate it is possible to sustain at least 1000 transactions per second load 24/7 all year round.
A theoretical constant rate of 1000 tps would produce 6.3 TB worth of archivable blocks files per year or roughly 3 new block files per day, all on commodity (affordable) hardware.
Would however the need arise to process even higher numbers - eventually approaching the VisaNet max level of 56.000 tps) thanks to the vertical scalability of HEAT all that’s needed to support these kind of boost rates are just stronger servers with more processing cores and RAM onboard.
###Unlimited Scalability###
Many of us have heard of the issue of "scalability" which most popular blockchains face. The difficulty of handling an ever increasing number of transactions on the blockchain puts a growing pressure on the resources of each node in the network.
Of the current generation of blockchains (eg. Bitcoin, Ethereum, Dash, NXT) most have an embedded database where they store both all blocks data and all balances.
Those embedded databases give the user the ability to ask the running coin daemon for any block or transaction from the past. While in lack of a better solution this sure helps users, it in fact does not help the core p2p operations at all. Instead it comes at a brobdingnagian cost, especially for blockchains that skip the usage of more performant LevelDB but opt for the featureful and thus slower H2 SQL database.
LevelDB has its limitations also; you cannot store anything in LevelDB that requires more than one hard disk, more practically the maximum size is as low as 100 GB.
As stated, the core p2p process has no use for the past blocks and transactions. All access that is really
required on constant basis is access to the most recent 720 blocks. This is needed for removing transactions in the rare case of a blockchain fork resolution.
Removal of embedded database
Not embedding LevelDB or H2 to store transactions and blocks, account balances and the order books for all asset pairs, HEAT uses custom build storage and access solution based on Memory Mapped Files and tailored specifically to address the needs of a cryptocurrency node.
In computing, mmap(2) is a POSIX-compliant Unix system call that maps files or devices into memory. It is a method of memory-mapped file I/O. It naturally implements demand paging, because file contents are not read from disk initially and do not use physical RAM at all. The
actual reads from disk are performed in a "lazy" manner, after a specific location is accessed. (source)
Memory mapped files offer us the possibility to access disk stored data in random sequence and at near RAM memory speeds - without the need to load this data in RAM. (The idea originally inspired by Ramchains implementation by jl777).
Use of off-heap memory
HEAT is written in Java and thus uses the Java Garbage Collector to manage and free app memory not used any longer. While Java offers much safer code with regard to memory management than do apps written in C or C++, this safety comes at a big cost. Applications written in C or C++ don't have a Garbage Collector and thus don't have to pause execution of other code while the GC is doing its
thing.
Inspired by the High-Frequency Trading industry we were lead to investigate the software components used by these HFT companies. HFT requires massive amounts of data that need to be accessed at lightning speeds. The needs of HFT systems and Blockchains systems overlap.
Our search lead us to Chronicle Software, more specifically their LGPL licenced product Chronicle Map.
Chronicle Map/Queue Properties
- High throughput, low latency, cross process, persisted key value store.
- Off heap data storage, with microsecond latency.
- Designed to be used in Java, in a pauseless, garbage free manner.
- Better utilizes your existing hardware by offering vertical scalability.
- Concurrent writes on one machine using single copy in memory.
- Resilient writes ( if a process dies, the last write is not lost).
- Entirely embedded, no need for any additional processes.
- 30 million updates per second with 500 million key-values on a 16 core machine,
with a 64 MB heap and no minor collections. - Data is not lost even if the JVM crashes on the next line.
An important part is the application startup process, where it might be needed to scan all transactions
on the blockchain to rebuild or validate the various running balances. Loading a multi-giga-byte block
file into a memory mapped file is not a problem since this takes just about a second.
Subsequently scanning through all the transactions is made extremely fast by using off-heap memory during the scanning process exclusively, eliminating the need for the Garbage Collector to even run.
Regular startups of HEAT without the need to scan transactions are near instant since all that has to be
loaded are the balance files which require much less space than the block files.
Split Balance Storage from Transactions & Blocks
Incryptocurrency / decentralized ledger architecture you always have a list of transactions since the Genesis block. Reading all those transactions allows you to build up the balances for each account.
The storage needed for balances is much less than what we need to store the actual transactions. As an example let's imagine that 100,000 individual accounts have made a total of 100,000,000 transactions.
As can be seen the total amount of storage needed to store the balances for 100,000 accounts is just 2 MB. Translate this to an account for all the ~3 billion users on the internet and we'll end up with a balance file of just 60 GB.
HEAT produces several distinct files all loaded as memory mapped files and all serving a homogenous data type. There are files for unconfirmed balances, confirmed balances, unconfirmed and confirmed asset balances but also for open buy and sell orders. Each of these files comes with an
accompanying recovery file that holds the transactional data of the last grouped update.
The recovery files serve dual purpose: we use them to rollback a transaction (grouped set of updates) and we use them to recover on startup when the app process has crashed or was stopped for another reason (system crash/power outage).
A Chain of Blockchains
(to be implemented after the HEAT main net has been successfully released)
In HEAT instead of one single blockchain we have segmented parts of the blockchain. Segments are numbered and there is no limit to the number of segments.
Balances are distributed separately from the blocks and transactions in the blockchain segment. Balance files are much smaller than blockchain files.
The balance files accompany each segment file, you need to scan a segment using the balance file as a starting point to get at the final balance for that segment. Contained in the balance file is a cryptographic checksum of the expected post-scan balance which should match - if there is no match the segment is invalid.
Let’s take an example of a new HEAT user, Bob. Bob downloads HEAT client-server package, and with this comes the initial balance file. Bob then also downloads all balance files for all segments (these are around 2 MB per segment). Finally Bob downloads the most recently sealed segment.
Bob can verify that all balance files that he has downloaded all link back all the way to the original
genesis segment.
Each balance file comes with a SHA256 hash of the previous balance file, plus a 265 bit CHECKSUM of all the balances in the previous balance file.
So when Bob downloads all balance files (1/~10,000 the size of the blocks) his HEAT software can verify all balance files all the way to the last one for which he has downloaded the segment.
When Bob’s HEAT server software now applies all transactions he gets the starting balance from where he can start downloading transactions from the network.
Block height counter is tracked separately and it keeps increasing normally when a new blockchain segment is started.
read the rest please on Heatledger website or using above link for the pdf download.
###CONCLUSION###
The HEAT decentralized crypto ledger platform is an ambitious business project bringing together several dramatic server level changes, client side features and middleware system arrangements to form the basis to software solutions suitable for financial applications of today and the future.
Extensive in scope and going boldly where no crypto geek has gone before, we the HEAT Team look forward to bringing the maximum technological capacity of modern commodity hardware to the use of everyday distributed blockchain applications.
Eventually, this feat will be made possible only through the engagement of a supportive community. By careful technical and structural design - together with the enthusiastic users involved with the distribution of the HEAT system and token - we strive to achieve the status of HEAT being rightfully recognized a proper, first “Gen 3.0” cryptocurrency platform.
White Paper Version history
2016-08-01 v1.0 Initial publication
2016-08-02 v1.01 Minor wording changes, improved pdf formatting
If you like ICOO you might want to take a look at following link:
Good way to actively grow your investment:
BUY ICOO - UPVOTE THIS POST - SHARE WITH EVERYONE YOU KNOW
Buy your ICOO directly on the OpenLedger BTC market:
https://bitshares.openledger.info/#/market/ICOO_OPEN.BTC
For more information and eventually buy: https://www.ccedk.com/dc/icoo
ICOO Social Networking
Facebook https://www.facebook.com/icooio/?fref=ts
Twitter https://twitter.com/icoo_io
LinkedIn https://www.linkedin.com/company/icoo---the-official-ico-pre-launch-token
Website: https://www.ccedk.com/dc/icoo
Keep up the great work @bloggersclub
Upvoted
Nice @bloggersclub
Shot you an Upvote :)
Upvoted
Hi! This post has a Flesch-Kincaid grade level of 9.5 and reading ease of 59%. This puts the writing level on par with Michael Crichton and Mitt Romney.
Upvoted