Please login or register.
Login with username, password and session length

HEAT Forum

January 21, 2019, 10:49:24 AM
News: 2017-10-10 Heatledger 2.0 with Heatwallet 2.2.0 released! NOTE: Balance leasing and hard fork at block 777777
Pages: [1]   Go Down

Author Topic: Core development update  (Read 358 times)

verymuchso wrote Core development update on December 01, 2017, 12:19:20 PM
The reason we needed the hard fork so badly was because of a bug.

It turned out through a not so obvious coding error that when you'd send HEAT to yourself it would incorrectly affect your forging stake. Not your spendable balance, only the amount of stake considered by the protocol.

What went wrong was that where a transaction comes in and is first processed two objects where instantiated, one for the sender account and one for the recipient account. These objects are passed on to lower level operations where depending on the transaction types these account objects are updated and these updates are recorded to a versioning mechanism.

What happened was that when the objects where first created some initial balance info was kept in object memory and when we first saved the sender object and later the recipient object, it turned out that updates to the first where not available to the second.

Solution was to check if sender and recipient are equal and simply instantiate a single object.

The fork was kindof difficult since we could not foresee if anyone would trigger this in between us releasing the update and the fork height. To deal with this at the fork height we had to make a scan of the blockchain (which luckily can do that in about a second) to search for offending transactions and correct the account stake for those accounts.

All in all the effect has been that just some of these payments have occurred and always with low amounts, the single large transfer was reported to us and we did the fork within the week.


Apart from this work has been progressing on finalizing the microservices, lets call it version 2. The main difference being that the usage has been greatly simplified, the api as published in heat-dev-kit will remain the same for the most part but some of the more difficult aspects are handled by the heat platform now and dont need any work on the part of the microservice author.

Its hard to describe this in a few words, but I'll try anyway..

Because of the nature of a decentralized consensus network, basically being decentralized, it can happen that the order of transactions differ at different points in the network. Since microservices are invoked through transactions a microservice had to be aware of this fact. Another aspect of a blockchain is that blocks get generated and accepted at some point, while at a later moment a better block could come along which required the old one to be undone and the new one to be applied, this also had to be handled by your microservice.

These two things are handled now by a transaction cache solution which is at the heat core, this cache ensures transactions are reported to your microservice only once and in case the order of transactions changes only the transaction that has shifted position is reported to your microservice.

The cache is also persisted to disk so that when you redownload the blockchain or rescan it, your microservices are not invoked again.

Off to slush now for the second day in a snowy Helsinki.

Pages: [1]   Go Up