http://www.coindesk.com/dutch-central-bank-preparing-boldest-blockchain-experiment-yet/

They should built on HEAT 

Here's another one, this is a generic balance tracker which supports versioned balances which can be rolled back in case of blockchain reorg.
It also is transactional and can restore itself after a system crash.

com.heatledger.persist.AccountBalanceMap.java

To put credit where credit is due.

The idea of versioned balances that can be restored to their previous heights and the trimming of unreachable balances comes from NXT, afaik Jean-Luc first invented those.
I got the idea to use Memory Mapped files in the first place from James from SuperNet, his RAM-Chains implementation first introduced me to the concept.

Good day..

Doing some tests again..

Output is below, I'll explain further down.


So how to interpret..

That's a write throughput of 20,969.008 transactions per second (Visa average is 12,000 transactions per second), working on my desktop atm (old machine).

Read speed lays at 544,942.01 transactions per second (so that's over 32,696,520 per minute).

If we'd compare with the total number of transactions in the Bitcoin Blockchain which is 140,000,000.
It would take us less than 5 minutes to scan the entire bitcoin blockchain.

But that's not possible of course because of the way balances are tracked in Bitcoin, which happens with inputs and outputs.

BCNext (the anonymous NXT creator) probably understood this very well and its why he chose for a data model of not tracking inputs and outputs, but use account numbers instead.

Through the further help of the Chronicle software components I've mentioned a few posts back (who can do up to 40 mil updates a second) we now have what I think is the most optimal data structure for a blockchain system possible.

We are not yet ready to share the entire source code, its not ready for that.
What I can share is an important part which is our implementation of what we call a BlocksFile, as mentioned our chain consists of multiple blocks files to allow HEAT to scale infinitely.

Please check it out.

com.heatledger.persist.BlocksFile.java

Our reputation exceeds us. 

Some late night nerd-porn for the coders  
 
Who can guess what these guys have to do with HEAT?

http://chronicle.software/

Tip:
It has something to do with HFT (High Frequency Trading).

But seriously:
These guys deserve the exposure, truly amazing piece of tech.

After having seen 150.000 transactions a second fly by on my monitor.
And considering you could fit many billions of balances on just a single SSD disk.

I can now totally imagine Mastercard and Visa running on a crypto-backend in the future. 
Didn't think it was possible before.

The thing with basically every crypto-currency out there is that they are not designed to do just the things needed by the consensus protocol.

They do too much.

While completely understandable, the choice for instance to have an embedded database in the first place (Bitcoin, Ethereum) is far from optimal.
Key/value structure (ETH + BTC) or full on indexed SQL (NXT) is ok for storage of balances (albeit a custom solution is much more efficient) but much too slow for block/transaction storage.

Since those, when designed right in the first place, are only ever needed to be accessed sequentially.

NXT makes this impossible by design, this is through their referenced transaction feature (one transaction depends on the existence of another transaction) if this is possible it means the consensus part has to have access to all transactions since forever.

Thats why HEAT doesnt have that particular feature.
In HEAT the consensus plane only ever needs to know about balances and public keys, which is, by design.

That is considered a minimum.
Local tests have shown peaks of 150.000 transactions per second, and this was on a relatively old linux desktop with spinning disks, SSD will have much higher throughput.

And these are atomic writes which means that you can pull the plug at any time and the system will recover back to when it was you when you started the write transaction.
I had the same reaction btw when we started measuring things and it turned out to be that fast.

To achieve this we have built custom storage solutions for blocks and transactions and tailored solutions to store balances and such.
Scanning of the blockchain happens at an even higher rate, at around 300k/s. Edit: this is wrong actually, cant remember exactly will try again when time (its higher).

We advertise 1000tps since it also has to run in a decentralized enviroment and we need to handle unconfirmed-txn pooling and blockchain reorgs, max 720 blocks reorg.
I'm still writing the unconfirmed transaction storage which had to be done over, this was a key/value type of structure very much like balance storage but this did not scale.
Now its a combined key/value for index storage and a plain binary file loaded through MMAP for actual txn storage.

LOL indeed  

There was a post some time back that describes this.
https://bitcointalk.org/index.php?topic=1543991.msg15522831#msg15522831

As for the purpose.
It's an incentive to store otherwise not required archived transactions.

If you scroll to the bottom there is a mention on inflation rate.
http://heatledger.com/ico.htm

We seek developers with the following skills

- Java
- Scala
- Play! Framework
- MySQL
- DEVops Chef (but switching to Docker is an option)
- Gradle
- JUnit
- TypeScript
- Angular (2)
- Angular Material
- Gulp
- DEB/RPM packages (creation of)
- Building massively scalable server backends consisting of an auto-resizing cluster of app servers driven by a load balancer
- IPhone app devs
- Android app devs

The other categories (non-dev) I'm sure Svante will add  

Can't agree more 


Thanks.


What existing platform?


Thank you.


I am also in slack. My user name on supernet slack is Dirk

Hi,

Svante Lehtinen is from Finland.
Dennis de Klerk is from Holland.

Company details and our mug-shots are on the website http://heatledger.com.

I don't do facebook, linked-in, twitter (like my privacy) but will likely have to at least give in to that now for business purposes.
Can't speak for Svante on that, I'm sure he'll explain himself.

Thanks

It sure is 

Not just using memory mapped files (which are amazingly fast).
Also the structure of the data is important, where no indexes are needed for data only accessed sequentially, there are no indexes.

The memory mapped files are so fast actually that at almost no extra cost we can write both the "real" data and write "recovery" data before that.
This is how we implemented atomic writes where no matter when the system crashes, our data storage can always recover on start up.

But don't be fooled that we have a poor API or lack of deep data access since there is no embedded database.

Through a method we (and others) call replication we can keep a MySQL db (or a cluster of them) in perfect real-time sync, which allows us to build a web frontend that shows live transaction data. But also allows for real-time instant order matching against existing orders in the db.

We have already used the replication mechanism (event based mysql sync) in a commercial project Eliphaz will undoubtedly tell more about in the near future.

Hi James,

Nice to see you here!
Happy to have you on-board.

Thanks for setting up the slack!

Doing it every block is far too resource intensive and not needed.
The exact number of blocks will vary per challenge but will always be in a fixed range.


The rewards are paid to everyone who provides proof they host the specific blocks file.
The total reward for POP is set per block and divided over the number of blocks files that exist (this will grow with time) the amount you get depends on the total number of users who provided proof they host that specific blocks file and the number of blocks in the current challenge range.

All decisions are made in a cryptographic, random method very much like how the next block forger is selected in POS.

HEAT server is build with Java and runs on basically any machine Java runs on with the exception of phones and tablets and such.

What remains of course.. Is never loose your brainwallet key!

What has been possible with FIMK since ages and what will be possible with HEAT is that you can create a brainwallet address (those twelve word passphrases).
You could do this in the hosted wallet https://lompsa.com or (more secure) download the desktop wallet and turn that on.

FIMK desktop wallet is fully functional without the need to download the blockchain so there you have a safe, easy and quick method to create your brainwallet (those 12 words and it's accompanying FIMK address).

When you write down, print out or email this brainwallet key (the key being those 12 words) to yourself.
You now have your own address where you can keep your funds for the next 100 years  

If you send out your funds from c-cex or which ever exchange to that address, it's as safe as can be and fully under your control.
You can even check your funds straight from your browser since all addresses in the hosted wallet can be bookmarked (see this example https://lompsa.com/#/accounts/FIM-5PGB-BFNZ-KCSF-9XJWB/activity/latest).

The mentioned wallet at https://lompsa.com is our old wallet software btw, for HEAT we have build a completely new client from scratch.
It uses the latest client side techniques (Angular 2, TypeScript and Google Material).

That's probably the most hilarious username I've seen since I joined this forum.