There was a post on nxtforum not so long ago that touches on some technical HEAT concepts, among which Services Architecture.
Thought I'd share it here.
I'm just a simple developer, I'll happily answer all
tech related questions.
HEAT slices the currently used blockchain database technology to modular components
I'm not a dev so I don't understand how this happens. It sounds like a "modified" blockchain. Like you are changing the fundamental structure of the typical blockchain. Is that the case? Can you go into a bit more detail keeping in mind I (and others) are not software developers?
What it means is that we have a blockchain structure that allows us to slice it in pieces.
Unlike NXT we dont use a standard database (NXT uses the H2 java db, ETH and BTC use LevelDB etc..) with tables and columns and indexes and all that stuff.
Instead HEAT blockchain data is placed sequentially in files where we start with all the block details and then a multiple of transactions that go in that block, then a block and so on and on.
This structuring allows us to scan a full chain of 5 million transactions in just seconds (other optimizations where needed for this but i'll leave them out now), while in NXT this would take up to a day at worst or many many hours at the least (this is not since NXT is slow, try scanning the bitcoin chain).
The NXT database also keeps tracks of all balances, there are account balances, asset balances but also order balances (how much of your order is eaten) with NXT all that goes in the same H2 database.
HEAT has created custom storage solutions where we have a storage for account balances, unconfirmed balances, guaranteed balances, asset balances, order balances etc etc (doing this from the top of my head).
The big advantage of building custom tailored storage for those things is that we basically do what SQL and H2 does for NXT, yet extremely optimized, using open source components borrowed from the HFT industry. We can read many many millions (30 million plus) balances a second where with a database you only get to do standard crypto currency speeds.
A really really big part of the NXT source code goes into all the H2 database hand-lings (which we've all removed - so please don't dismiss us as 'just' a clone) while structurally very smart (Jean-Luc basically taught me crypto system architecture
) all those 'solutions' like rollbacks, derived tables, trimming etc all build on SQL and SQL transactions.
All of that we needed to write custom solutions for, all the way up to system crash recovery which in NXT is solved basically by H2 db.
But now to the fun part.. After HEAT has run for a while and our blockchain has grown to about 1 or 2 GB..
We start a new file and we'll be storing blocks and transactions in that new file and people only need that last file and dont need the transactions or blocks that have gone in previous blocks files.
What is needed to be able to validate that last blockchain, without having access to previous transactions... are the balances that came out that previous blocks file.
The nice thing here is that while a blocks file might be 1.5 GB. The balances coming from that are just a few MB. (i'll leave the details for later - but key here is a combination of balance checksums combined with expected before and after scan balance numbers).
PS (1). Some might ask ... if there is no db ... how do you provide deep data analytics to power advanced clients/cloud api hostings/wallets?
The answer to that is our replication layer, its where we
optionally and in real-time sync everything and more that H2 knows about in NXT.
But in the case of HEAT to a much more powerfull MYSQL database (this comes out of the box) or if you choose so to a super sized storage like
dynamodb to power really serious user levels (decentralized Facebook anyone).
And in HEAT the consensus parts has nothing to do with the replication or view parts (its basically what they propose here:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf - funny to see how we came to the same conclusion).
PS (2). This same replication mechanism allows us to present a real-time status of all orders, confirmed or unconfirmed which again works great to power our AE UI which basically works as instant as for instance poloniex or any other exchange does (we can discuss this later if anyone wants).
users can trade cryptocurrencies right from their wallet on p2p orderbooks without going through an exchange.
Provided they are trading with others on HEAT is that correct? Is this like taking a USD out of my pocket and giving it to someone who gives me a Euro? If we are trading wallet to wallet is there a fee?
Not sure where but I've mentioned my idea on this forum once before (lucky no-one developed that further) but HEAT comes with Decentralized Services Architecture.
Call it luck but I've used to do be quite active in the field of building scripting solutions that integrated inside Java applications (thats probably what lead me to the idea).
What Decentralized Services Architecture is in its simplest form is that you write a Javascript (or TypeScript - thats what i do - so in love with TypeScript lately) which you simply drag/save in a special folder inside your HEAT installation. This script then registers as a listener for blockchain events (we use Java nashorn for that - but anyway) but the script will not run everytime a new transaction comes in. The script itself knows what account its working for.
Users anywhere in the world can create a transaction with a special structure and send that to the service account (we have client software that automates all this - even the UI is generated) , the script now runs and does what it needs to. This even involves talking back (and forth etc) with a customer.
To give an example:
Alice is a service provider, she exchanges BTC for ETH. You send her BTC and she'll send you ETH.
Now BOB calls to Alice her service, bob knows what params are needed since Alice advertises that on the chain.
Bob sends his BTC amount and his ETH recipient address (as message attached to a transaction with recipient Alice).
Alice now replies, taking in the BTC amount Alice lets Bob know that he will get X ETH and that if he wants to he needs to send the amount he proposed (of btc) to BTC address Y.
Bob in turn does what Alice requests and could optionally send another message to Alice (over the chain) that he send that BTC combined with the transaction id.
Alice now has her bot look up the best price for ETH on polo or any other exhcange, or she has it herself, she exchanges the BTC Bob send and she sends him his ETH.
Alice is a service provider so she definitely sends proof back to Bob which includes the transaction id.
Voila we have a
truly decentralized Shapeshift now
Yet all transactions (and thus reputation) of each service provider can be confirmed through going over all transactions she send and received.
Sounds complicated (which it is) but distilled to its bare essentials and using a nice Javascript lib who handles things under the cover, writing services actually becomes dead simple.
And its even easier if service providers publish their service code (in order to get more trust) which anyone basically can copy.
Yeah its a head spinner I know, but it works and it can be used for millions of things.
1. Buying on Amazon
2. Renting movies
3. Exchanging currency etc etc
Distributed Services Architecture is what I personally like best, it can truly grow into a whole new economy on itself
What will be the incentive for Java software developers to use HEAT? How are DSAs > dApps?
DS (distributed services) are written in javascript or java but why use Java? For DS JS or even better TypeScript is way better.
But if you want to make use of our blockchain as a way of safely storing your data, yet want to write custom replication plugins to interpret your data and feed that into your custom MySQL or Progress models, Java is your friend (or Scala, Clojure, JRuby .. what ever tickles you).
With HEAT that is totally possible.
I asked a lot of questions and I hope none offend. I'm sure others are wondering the same things. I look forward to your response
Thank you
No problem
