Technical Update – August 16

Just as a quick update on what is happening here behind the scenes, about two weeks ago our technical team (David, Stephen and Richard) began a review and refactor of the core Saito code. Our goals are threefold:
1. Fix Bugs:
We spotted two bugs during testing earlier this month that we consider “show-stoppers”, along with a few other minor issues that we wanted to tighten up before advertising and promoting Saito to the general public. While none of these issues technically *broke* the Saito blockchain they could make it less reliable and confuse people.
One of these problems, for example, is the fact that users can make double-spends right now if they lower their default fee, send a transaction, reload their browser, and then immediately send another before the block containing their previous transaction is produced. Because of the way our code works, wallets will happily use the same UTXO twice in this situation, since memory of the spend attempt doesn’t carry across browser reloads. Servers can include both transactions in their mempools, and while the network will never accept a block with a double-spend, the way the code dealt with this can cause important things like confirmation emails (“Address Registration Success!”) to disappear into the ether (sorry, John).
Another example of a usability problem we spotted that we want to get fixed happens if a lite-client waits a few days between Saito sessions. Because our network can produce blocks reasonably quickly, it can take quite a while for browsers to catch up with the chain, during which time the network can seem slow. We have also decided to add unit testing to the scope of this re-write, along with shifting from using callbacks to promises.
2. Simplify Architecture and Find Problems:
As we’ve added features like “Automatic Transaction Rebroadcasting” and VIP transactions to Saito over the past few months, our new code has basically been grafted onto our existing structure. A lot of this is my own personal bias towards getting things working before trying to make them perfect. Unnecessary complexity can also be added when fixing bugs: sometimes it is easier to just patch an implementation problem rather than fix the cause of the problem on a deeper architectural level.
By re-implementing the entire core codebase step-by-step, this re-write is giving us the opportunity to review all of these decisions. And so we are simplifying the way Saito is organized, making sure that all of the relevant bits of code are sitting in the right parts of the codebase (i.e. all block validation functions are in the block class, not hidden away in the storage class) and cleaning up the organization of some of the more complex parts of the codebase (I’m looking at you, addBlockToBlockchain) so that it is more immediately obvious what bits of code do what and how they are related to the overarching structure.
3. Team Education
As the original architect and implementer of most of the existing non-module code, I’ve personally felt like a bottleneck in development for a while. Whenever features have needed to be added to the core code, I’ve typically been the only one with enough holistic knowledge of the codebase to make those changes. Even members of our team have felt trepidation about wandering into certain parts of the codebase out of uncertainty about what it is doing and how various functions fit into the bigger picture.
Since we are fixing these other issues, we are doing it through a process that is forcing two other members of our team (Stephen and Richard) to engage line-by-line with the codebase and write significant parts of the new application. We are also shifting towards a method of programming that is more collaborative: pre-implementation review of the existing code and discussions of what changes we want to see, and then post-implementation review. As a result, by the end of this re-write we should have tripled the number of developers who are experienced enough with Saito to debug Core application logic and help onboard new developers. New developers will also be helped out with more commenting and unit tests.
So how are we doing on timelines? We’ve been slowed down by the fact we are currently closing a round of fundraising as that has kept Richard and I from being able to spend every day focused on the rewrite. Our pace of progress is still pretty rapid though. We’re up to about 4000 LOC complete on a write-up that will probably take us to around 9000 LOC total. If you’re tracking our progress technically, you can check out the latest version of our software at the Github repository below. This is just a temporary repository, as we will be shifting the code back into our main repository once it is finished and sufficiently debugged that we’re willing to run it on the main network:
http://github.com/trevelyan/newsaito
Right now most of the ancillary classes have been re-implemented, and we are stepping through the process of creating blocks and adding blocks to the blockchain. As such, the major changes for the next week will involve fleshing out the Blockchain, Storage and Wallet classes. I’m guessing that we should have all of the important parts of the core software re-implemented by the end of next week, and that once that is done it will take us another week or two to add the new features we want like bloom filters and more robust defences against block-flooding attacks.