19
ineterview
with
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