Boolberry Monthly Progress Report: July
July was a busy month full of key updates and bug fixes. We’ve fixed a bug with un-relayed transactions, solved a brutal pain point for restoring a broken wallet, speed up a syncing issue, and worked on general improvements across the board. Check out the details.
Fixed bug with un-relayed transactions
We’ve all complained about sending a transaction that went unconfirmed. One way this can happen is when the transaction gets sent while network connections are unstable and a connection is dropped. This means that the core and protocol have not recognized that the connection is broken while it’s waiting for a timeout. If this takes place when user tries to send money then the data isn’t actually being sent to the peers and the transaction will not get relayed. This problem was one of the reasons that exchanges have requested the implementation of specific APIs for transferring data, allowing exchanges to manually send transactions as many times as needed until the transaction gets confirmed.
We implemented re-relaying for every unconfirmed transaction in the wallet after every new block arrived at the host. This approach assumes that in normal situations the wallet expects the transaction to be confirmed in the next mined block and if this not happened, something went wrong and the wallet initiates this transaction again.
Loading a broken wallet
For a few different reasons (broken file system, incompatibility of versions, corrupted files, etc.) there have been multiple instances of fails while opening wallet files. We definitely understand the stress of this experience having been there ourselves. This stress is only compounded by the fact that this bug forces you to back up your wallet files, without making a typo or any other small mistake… nerve-wracking for sure. To make life easier, we’ve decided to cover this problem with few fixes. These fixes automatically resync the wallet if there is a problem while loading historical data. This should solve the problem for everyone, without the risk of losing everything. Yeah, we’re super excited about it too.
Fixed unfull wallet synchronization when it is restored from a seed phrase
In an emergency, a wallet account can be restored using a 24-word seed phrase. Upon restoring it will have to be fully synced, meaning it needs to scan the entire blockchain for coins that have been sent to it. After that, the wallet will show up the coins it had before it needed to be restored. It was reported that we had a problem with the scanning optimization procedure( when the wallet doesn’t take into account the coins which were received up to the restoration point) In this case, a user with a spendable balance may have seen lack of coins after restoration. All that was fixed.
Performance analysis and optimizations
Along with a general code clean up we also dedicated time to performance analysis and improvements. We had changed the way scratchpad loading from the database which increased the speed of this operation in a hundred times. Sounds really impressive, but this behavior has shown only if the daemon/GUI was exited in a problematic way. We’ve now been implementing those changes for regular performance as well.
Another performance problem, “bottleneck” as it’s called, we have is with flushing data to the database after every transaction (don’t be confused with currency transactions, here we’re talking about database transactions). We always want to have the database in a consistent state, so we have the setup database engine settings to flush all the data to disk drive after every database transaction is committed. In this mode whatever happens (electricity turned off or OS crashed) we always have our storage date in the correct state and operations on the currency core can be continued. But as soon as we do commit the database transaction after every new block added to core, we have to wait while all the data is flushed to a hard drive. It’s not a big problem if you have an SSD as a storage on your host, and if you have HDD it could seriously slow down synchronization speed. We’re now trying to implement some elegant solutions for batch database operations, but while we work on this we added workaround which could help, a special startup parameter “ — db-sync-mode” which sets up the database engine in the correct mode when the data is flushed to drive. This doesn’t happen after every transaction, it’s rare and only need to take place for optimized performance. This is a trade-off between performance and reliability related with hardware and OS. For HDD (not SSD) users experiencing a slow initial sync with the network it may worth be using “ — db-sync-mode=fast”.
Thanks for sticking with us through these interesting months. Lots more to come, as thing continue to move quickly.
