Lisk team just announced a new release v 0.9.16 of Lisk Core that has a fix of a major issue. Announced via a blog post, the problem seems to be a database issue found in a SQL query of its backend PostgreSQL.
On Saturday, June 2, the Lisk network experienced a temporary halt. Despite the fact that the issue was identified and resolved within several hours, we believe the situation warrants a more thorough explanation of precisely what happened to the Lisk network.
Lisk Core uses PostgreSQL, a relational database. Blocks are stored as rows in a `blocks` table. This table has a foreign key constraint requiring that each block contain the ID of the previous block — the constraint here being that the previous block must already exist in the database. Insert operations which do not conform to the constraint will fail and not be saved. Similar to that, transactions are stored as rows in a `transactions` table, with the different parameters of a transaction, like a timestamp, sender, recipient, and amount, being saved in columns.
The fixes of the new release are:
- to handle errors properly and crash the application if an error is returned from the database during blocks/transactions-inserts (when one of the database queries fails).
- to set `lastBlock` into node memory only after the block is successfully written to the database.
- to handle errors properly and crash the application when the round tick fails (the round tick tracks the progress of each round, mainly the weight of votes for particular delegates, blocks’ rewards and transactions’ fee splits).
