15
ineterview
with
CORE: Hey Dennis , could you give us an introduction on yourself, your team and how you got into cryptocurrencies.
DENNIS : Hi! I'm Dennis and live in Holland. I have worked professionally and mostly full time on NXT related technologies basically since NXT was launched (that's becoming 3 years next November). Together with Svante we launched the FIMK crypto platform in May 2014 and we created the multicurrency (NXT & FIMK) full client/wallet which was called MofoWallet back then. I also created the Offspring desktop client (in early 2014) which was basically an NXT client for enterprise use and I maintain the NXT+ project, which is standard NXT but with the real time FIMK websocket API added to it.
Before I had read the NXT announcement thread on bitcointalk forum which was exploding at that time, I never before heard of bitcointalk, let alone know how a Bitcoin worked. But reading that NXT thread among the other bitcoin clone threads, as a developer, this immediately stood out and caught my interest. Around that time all the fundamentals of NXT/POS were still being discussed (with hundreds or more posts each day). I don't know why but probably the fact that almost everything discussed there was completely alien to me is what made me try and understand it all.
From there I started building various solutions on NXT tech which allowed me to not only earn a living but also slowly improve my skills in something that I believed had a lot of potential (blockchain technology). From that position I came in contact with Svante with whom I launched FIMK and who now is my partner in HEAT.
CORE: What is HEAT? You describe HEAT as a "chain of blockchains". How does this differ from projects such as NXT? How do you plan to compete against these projects?
DENNIS: HEAT is our implementation of an NXT style POS peer to peer consensus network. HEAT’s core working mechanisms resemble those of NXT. You start the app, it connects to a list of other `peers`, you exchange blocks and transactions to/from those peers. Blocks are stored on your drive, transactions in those blocks are applied and finally balances are updated. That is basically how a peer to peer consensus network works. But that is where the similarities end. On the inside HEAT is very different from NXT, overall architecture remains the same but the implementation has changed in a big way.
Before I continue I’d like to point out our choice to build on NXT as opposed to one of the other existing POS frameworks. NXT, I believe, is (one of) the most mature frameworks and has been under heavy real world use for many years now. It's a complex code base, sure, but once you understand how it all works there is no better or more mature base to start from.
We have rewritten most subsystems (storage, networking, view plane, mempool etc.) So HEAT can’t really be considered NXT clone but maybe rather a rewrite of NXT. Even though fundamental operation rules remain the same we did not alter the POS consensus mechanisms the internal implementations have changed in major ways. What is unique about HEAT compared to other crypto platforms, is that it basically solves the blockchain scaling problem both in size and in speed of processing. HEAT solves these problems to such extremes that since we've started live testing the components that we have made so far.
It has become clear to me that not so far in the future literally all banks and all of the Visas and Mastercards of the world will be running a good part of their systems on systems based on these same principles. It simply must happen, you get such an amount of affordable security from the blockchain in the middle and your redundancy through the p2p network is so cheap and so fast! And as HEAT will prove you can scale consensus networks to Mastercard processing and storage levels. To understand how we can make such bold claims you need to understand cryptocurrency code architecture. You need all the parts that make your cryptocurrency tick to be able to sustain tens to hundreds of thousands of transactions per second (to keep up with Mastercard for instance).
It took a while for me to understand what all these parts were in the first place, which is most likely what kept me from thinking about follow up solutions. But once all parts and their workings became clear and I had touched on and worked with all them, finally I could do what I think I am actually best at which is looking for combinations to come to new solutions. Not so much invent anything, but combining existing ideas and technology in new ways. Everyone has his/her talents and I think this is mine. It was clear now that we had to solve the following problems to make a crypto platform that could scale to world scale usage.
- Best utilized network bandwidth
- Balance lookups and updates happen at microsecond level speeds (up to tens of millions of reads/updates per second)
- Total balances count should support tens of billions of individual balances/accounts
- Blockchain scans happen as fast as possible (at RAM speed data is organized linearly)
- Old blocks and transactions should be able to be archived (after all disk space is cheap) and should not be needed by all nodes on the network
While not being a homegrown cryptocurrency builder it was something I had to learn I do know, or better, know how to figure out how to … solve all those individual issues. And it's exactly what we did for HEAT. We are replacing the single threaded and non-optimized network layer in NXT with one that uses not only a more efficient binary protocol but also has peers that are smarter and communicate with each other before sending large pieces of data I have not done the math on that part but it's my estimate that we use about 75 to 90% less bandwidth that way. On top of that we have replaced the rather heavy single threaded Jetty networking library with the asynchronous and more performant Netty networking library, exclusively running over websockets but with a much higher capacity even for relatively light servers.
So we have reimplemented the networking internals in order to have enough bandwidth on the HEAT network. The next important step was to solve the storage problem, which was both: too slow and not able to scale beyond any serious usage. The current NXT Ardor rewrite is partially about this same scalability problem (as well as a means to allow for child chains in HEAT we solve that through Colored Accounts and eliminating the need to limit blockchain storage in the first place).
But back to the storage plane. Let's start with the slowness of existing systems like NXT, Ethereum, Bitcoin etc.. almost all suffer from the same inherent weakness and most will not scale beyond a certain usage. It's just not possible, you can try it yourself, get one of those apps setup a testnet for yourself and see how many transactions per second they can handle (on a full chain not talking about the first few blocks). You won't get above 10 transactions a second for any serious amount of time (say you bombard them for 3 hours and take the average). With HEAT this is completely different: HEAT guarantees to do 100 to 1000 times those numbers. In fact during testing we have been able to push the number of transactions applied and written to the blockchain close to 150,000 per second.
Yes you read that correct 150 THOUSAND per second, and this was on my slow (10 year old) desktop with spinning disks (however not over a network). Imagine the speed on a 16 CORE server with SSD disks, what will that be? 5 times? 10 times as fast? Can't wait to try that out! Or better even private in house networks Mastercard datacenter? The transaction speeds will no doubt be sufficient to support any level of processing requirements. The reason those systems don’t come above 10 transactions a second is twofold.
First there is the limit to the number of transactions that fit in a block and the number of blocks that fit in a minute. Secondly and this was the hard part to fix, the storage and consensus parts need to be able to cope with those huge numbers and still be transactional (support rollbacks/reorgs and recover from system crash). What we came up with was to write our custom storage backend from scratch and replace the NXT H2 database with that customized and optimized solution. This however came at a huge (and continuing) cost, standard NXT heavily relies on the H2 SQL database to perform lots and lots of tasks and have transactions and blocks applied in an atomic/transactional manner. Using plain SQL this is easier, doing this without relying on SQL meant we had to look hard at what exactly our storage backend had to do to make it as reliable and safe as NXT is through their use of a full SQL database but now through our custom storage solutions that allowed for 10,000 times or more traffic.
What this lead to was a data store with custom storage optimized for archiving transactions and another part optimized for storing and updating balances. Those two things (transaction archival and balance keeping) are totally different in nature, the first has to be able to flush binary data to disk as fast and efficiently as possible (write and forget stored in such a way that you can iterate over them as fast as possible which is why it needs to be stored linearly) the second part has to support random lookup and updates to a data pool as big as physically possible (in theory each balance store can be as big as the biggest hard disk which is enough to store hundreds of billions of account balances).
First I need to explain one other important principle of HEAT. We believe there are three different planes in a consensus network (this is also described in a whitepaper called “On Scaling Decentralized Blockchains”). These are the important planes:
1. Consensus plane
2. Block/data distribution plane
3. View plane
I’ll try to keep this short. The consensus plane can be seen as anything that involves validating transactions, the distribution plane is the part where one peer can ask another peer for past or current transactions finally the view plane is what a desktop or web client uses to display user transactions, forged blocks or balances. In HEAT the view plane is implemented as an external add on to the HEAT server, it works through event listeners that act on unconfirmed transactions and transfer the derived data in realtime to a powerful MySQL database model. The view plane API which powers clients also looks in the MySQL database for its real time blockchain data. The huge benefit with this model is that with each new transaction that arrives we don’t have to update some big and slow detailed MySQL view model with indexes and constraints and all that comes with that.
As a bonus, MySQL or other cloud based mass storage solutions (the addon mechanism is flexible) is perfect for serving truly web scale numbers of users. The real time integration through events to the mass view/storage also allows us to match orders in the HEAT asset exchange (virtually) in real time, displayed instantly in your client. We already had this feature in FIMK but made it better and scalable this time through what we call the replication layer (the view plane implementation). Now that we have removed all speed bottlenecks (this includes a rewrite of the unconfirmed transaction pool, .. etc) what remained was the issue of storing an ever increasing collection of transaction and block data.
The amount of transactions in a blockchain is virtually endless, which means that the consensus plane or the distribution plane could never work as long as they are dependent on access to all this data. By separating balance and transaction storage we were able to keep the cryptographic security that comes from a set of interlocking blocks but instead of only blocks there also is a similar interlocking through the checksums we perform on each balance store. Transactions in HEAT are stored in files of a capped size (blocks files), if the max is reached (several GB) a new file is started, you can keep the old file around on your server if you wish but to function as a peer on the network, you only need the most recent blocks file. To promote data redundancy the protocol rewards users for keeping archived files around, this works through a challenge that is written to the chain and anyone with those files can solve the challenge.
To ensure that a new user who comes on the network and who does not have any blocks downloaded can validate transactions back to the genesis block. He needs to download all balance files for each blocks file from the past (remember these are less than 10,000th the size of a transaction store). The following balance file has a cryptographic signature that has to match the checksum of the previous balance file and so on and on. When the user has all the balance files and knows the latest balance store is valid all the way from genesis, he can now validate all transactions he receives based on the balance data he has.
This mechanism will however not be in the initial release, it’s what everything else in HEAT is aligned for but also something which needs a large amount of attention and testing. We are touching the core POS principles here afterall. There is more to HEAT, I haven’t even talked about our powerful DAPP platform which we call Distributed Services Architecture. For more on that please check out the discussions on the forums.
CORE: Is the technology being written from scratch?
DENNIS: Because of the maturity and completeness of a system like NXT it would be foolish to lay out all that architecture by ourselves. Our client framework, which is something very special, is however written from scratch. Using the experience from building and maintaining the MofoWallet client (which has a very large code base) we have created a new project that gives us a maintainable and extensible advanced realtime client framework. The framework was created to create the frontend for a commercial project where we implemented a FIMK based private blockchain which had to do account management, trading and messaging.
The client framework uses Angular/Google Material design, Angular 2 (style) code structure (through a wrapper that we built) and is written in TypeScript. TypeScript is a typed language similar to java created by Microsoft and which compiles to javascript. Through strong typing and excellent tooling you can code a javascript app as if you had a powerful full IDE. Bringing on frontend developers and starting a successful and popular crypto client project has proved to be difficult, which is totally understandable since they are so complex to work with for a starting developer. Through our simple gulp based build setup and use of TypeScript and a prepared package to start development with the open source cross platform Atom editor. We think we have a good chance of bringing on skilled or starting frontend developers to this powerful but fun to work with framework.
CORE: What was your inspiration for HEAT?
DENNIS: When we ran into limitations while pushing FIMK to the max, it was clear that something fundamental had to change to handle the potential larger user base.
CORE: On the mind of a lot of investors is marketing since it was so successful for Ethereum. Do they have a marketing strategy for HEAT?
Svante: Heat Ledger Ltd is a fintech startup company. Thus the HEAT blockchain is just one of Heat Ledger Ltd’s products, designed to showcase on live crypto platform and real use cases the various solutions available for corporate customers and joint venture partners. HEAT’s marketing will emphasize the implementation of real world use cases that the crypto world strongly needs. Any kind of tokens can be easily traded against each other in the HEAT blockchain.
As we know, this is a feature already a few platforms carry (at least WAVES, FIMK, and the NXT Ardor) but although the claim for easy transmittal of fiat currency (USD, EUR) is easy to make, the regulatory arrangements are a whole different ball game. Heat Ledger Ltd is sorting that out with our JV partners through a pending money transmitter license in an EU country.
CORE: Where does this leave FIMK now that you are focusing on HEAT?
Svante: FIMK will be supported by the HEAT multicurrency client. FIMK is also accepted on the HEAT ICO at favorable rates, so FIMK holders can exchange some or all of their FIMK to the HEAT tokens. FIMK will however continue on a separate blockchain on its own right, supplying technically advanced community crypto platform and coordinated by the nonprofit association. Community based features such as the blockchain strong ID authorization, decentralized webshops and monthly basic income will continue to draw interested participants towards the FIMK economy to sustain its growth. This target market and mode of operation are very different from HEAT’s commercial business based focus. Our goal is that the synergy from HEAT’s business solutions will also help FIMK to attain its place in the world more clearly.
CORE: What sort of timeline do you have? When do you estimate testnet and mainnet to be released?
Svante: Testnet and alpha client release goal is the latter half of August. Mainnet preliminary release date is September 5th.
CORE: What are the details for the HEAT ICO?
Svante: For the HEAT ICO we use four escrow companies as well as accept direct investments to our BTC, FIMK, ETH and NXT accounts. Detailed instructions for participating in the ICO can be read at http://heatledger.com/ico/. There are four different price ladders for each cryptocurrency separately, based on first come first served basis. Token prices, for instance those payable in BTC, started from 0.0001 BTC. Once a price ladder is “sold off”, the token investment price increases some 20% to 30%.
At the simplest, the participant needs to only send cryptocurrency to our account to ensure his stake in the HEAT token distribution. No registration whatsoever is necessary at this phase. After the ICO period is over from August 9th onwards, we aggregate the various funding sources and run through accounting to distinguish and verify the price stage of each individual investment, and assign a number of tokens from the total pool of 25 Million HEAT.
HEAT tokens will be distributed to the HEAT wallets of the stakeholders through an online facility on our web site, after verifying each investor’s access to the original investment source cryptocurrency account. When the HEAT tokens and mainnet are live, we’ll release the company options plan for preparation of the Heat Ledger Ltd IPO. Each HEAT holder will be eligible to receive options in proportion to a still undecided number of HEAT tokens they hold. Each option enables its holder to purchase Heat Ledger Ltd shares from the IPO at a minimum 50% discount compared to standard IPO purchase price.
IPO stock options can be traded on the public HEAT p2p blockchain exchange. The IPO is planned to be completed in November 2016. Since then the Heat Ledger Ltd stocks can be traded on the online HEAT p2p exchange, and possibly on other online exchanges a bit later.
heat interview