3. April 2016 Roadmap

April 2016 Roadmap

  • admins

    Previous roadmap update: February 2016

    Though we've been very busy, we only hit one milestone from the previous roadmap: improved networking code. However, the improvements are substantial, and the upgrade process was very smooth. I think it was our best upgrade yet, very few bugs in the release-candidates, and the one bug that did get discovered has actually been in the code for a while, and is not a fault of the new release. @Jordan, our newhire, was largely responsible for the recent update, and he did a great job. Most of the networking code appears in v0.5.2, which is still in the release-candidate stage, though we expect to have the full release out in just a few days. Upgrades include the following:

    • Faster blockchain download
    • Blockchain download does not get stuck as frequently, and should get un-stuck automatically after 5-10 minutes. No restarting necessary. (nor is restarting recommended, though it may appear stuck it might not actually be stuck)
    • Less download bandwidth consumed when downloading the blockchain
    • Less upload bandwidth consumed when giving the blockchain to other peers
    • Less download bandwidth consumed when receiving a new block
    • Less upload bandwidth consumed when giving a new block to other peers
    • Less RAM consumed by the gateway, on the order of 100MB - 500MB.
    • Blocks propagate faster, miners have lower orphan rates.
    • A handful of bugfixes, including bugs in the miner that have been around (but mostly invisible) for a long time.

    Overall bandwidth consumption for full nodes should be decreased somewhere between 5x and 50x. Overall we are very happy with the changes, and strongly encourage everyone to upgrade once the full release is out.

    Upcoming Product Changes:

    • More stable, lightweight explorer. There is untested code right now that brings the memory impact of running an explorer down to about 100kb.
    • Scalable, efficient, renter-host protocol.
    • Multi-drive support for the host.
    • Better pricing tools for both the renter and the host.

    We've been working on the host and renter upgrades for quite a while at this point, almost 3 months. Between trying to get investment and enterprise clients, we've been slowed down significantly but the biggest bumps are behind us at this point. The most significant parts of the renter and host code have been written at this point, and the protocol design is mostly complete. We are now working on getting them talking to eachother and restoring our integration tests. A huge amount of code has been written in this overhaul, with the diff being nearly 9,000 lines of code, and likely exceeding 10,000 lines of code by the time we merge the code into the master branch. This does mean that the amount of testing necessary to guarantee a smooth release is going to be very large, so it may still be a few weeks before we are fully ready to launch the new file code. The upgrades are substantial, and should turn Sia into a useful backup platform. I want to thank everyone for their patience and understanding as we pull everything together, the amount of engineering needed to make this work has surprised everybody, but I'm confident that a full-featured product is near.

    We've decided to push back the 1.0 estimation to June. While we expect the full renter and host to be ready sometime in mid-April, we want more time to be able to test everything, and to make sure that the protocol + api for all components of Sia are ready to be finalized. Once we enter v1.0, we will be committing to not changing any of the protocols, which means that certain types of upgrades will be unavailable to us. This is great for the stability of Sia, but does mean that we'll be stuck with whatever bugs and inefficiencies remain. Though that may sound bad, I do feel confident that stability is more important than perfection - it's difficult to use a system when the protocol is being upgraded or broken every few months. It's much better to have a few bugs that everyone knows they need to work around than to have constantly changing code. Especially if the code you have is already very good, and the bugs are minor.

    We do expect to more-or-less have a feature freeze in April. That means that we won't be adding anything new, instead we will purely be working on testing, bugfixes, and improving UX on the existing features. We'll have a full 6 weeks between the release of v0.6.0 and v1.0 which will purely be dedicate to improving the existing features.

    0
Log in to reply