Update Friday July 13th, 2018
Testnet 1 was described as ‘bumpy’ by @igno.peverell in one article or another, a nice media-friendly way of presenting its tendency to fall apart at the seams. Testnet2 held up much better due to all of the fixes and learning from Testnet1, and allowed us to focus on a whole load of vital (but consensus-breaking) improvements that became evident after observing a functioning blockchain in the wild.
I have to say that Testnet 3, launched last week, feels very good so far. There doesn’t appear to be any massively odd strangeness in the chain itself or any blocks being accepted that shouldn’t be (yet,) and most of the issues we’ve seen are either user-errors (understandable due to the fast-moving nature of the code) or due to the immaturity of the supporting bits (miner, wallet, etc which themselves are holding up quite well but still need more time for feature-completeness and robustness). Signs are looking good for this chain lasting a while and possibly becoming the official development/testing chain instead of retired on the launch of Mainnet.
So, with the chain underway and issue investigations ongoing as required, there’s time to start focusing on the periphery bits again… so this week’s work mostly consisted of:
-
Wallet API Client trait refactor … which just means abstracting some code to allow for different communication implementations between wallets. The default http wallet-to-wallet code can now easily be replaced with other more robust implementations that use different means of communication, and paved the way for the …
-
Wallet API Test Client … by creating an implementation of the above WalletClient that communicates with a local instance of a chain as well as in-process test wallets, I’ve created a framework that allows for more robust and accurate wallet testing, which then allowed me to confidently build tests to ensure that the transaction API works and is properly covered by automated testing, which then made it easy to finish and verify igno’s work on:
-
The LMDB Wallet Backend, which implements alternate storage for the wallet in an LMDB database instead of flat files. Right now it’s just at parity with the File Backend functionality-wise, but more is planned and it should become the default. (instructions on how to start using it are found in that issue.
So, with all of that done, the wallet code is in a good place to begin the next trick, storing transaction metadata within the wallet, which should allow all sorts of good things like showing activity of funds going in and out of the wallet, as well as finally allowing you to cancel transactions and un-lock previously locked outputs if it’s become evident that a particular transaction isn’t going to hit the chain. There’s still plenty more to do beyond this around security, deployment, and the web wallet, (along with more tests and generally ironing out all the bugs,) I think this is the last missing piece with respect to the wallet’s usability. Looking very forward to getting it in there.
Have a good weekend, and kudos to the rest of the team for their really impressive work so far!