Our tech team has been working hard. For those who don’t want a deep-dive into our development roadmap the takeaway is that we are expecting to release our Rust Client on-schedule.

For those seeking more detail on where we are in our roadmap, at present we are about 3-4 months into development of the Saito Rust Client. This is the scalable reference implementation for Saito Consensus that we are building in the Rust language. It does not replace our in-browser client, but it is intended to be the main network client for full-nodes. We need it up-and-running to figure out the maximum practical blocksize for the next few years, to finalize the burn-fee algorithm that determines the blocktime, and to understand how permissive or restrictive our congestion controls will need to be to discourage spam-attacks at small fee throughput.

As of our last tech update about three months ago, we were nearing completion of what we call “Saito Classic”, a throttled-back implementation containing the basic features needed for consensus. The implementation covered a single machine creating transactions that contained routing work and producing blocks. Our major challenge during this first stage of development was ensuring our architecture would not create problems for Rust. The reason for this is that while Rust offers very fast parallel-processing for non-mutable data, the language itself strictly forbids different threads from owning or accessing different kinds of mutable data at the same time. As our javascript code did not have this limitation, a major part of our focus was making sure the components in our architecture *could* communicate, and that the limitations the Rust language imposes on sharing data structures would not drive us into a position where we would need to re-architect the entire codebase six months to a year out. In our last update we covered details on this as well as shared some data showing the performance gains we are experiencing with Rust.

After our last update we needed another two weeks or so to finish implementing Saito Classic, after which we moved on to scaffolding the major components that were not included in that implementation but are needed for any Rust client to join the live network. These include Automatic Transaction Rebroadcasting (the blockchain pruning mechanism), our staking mechanism, and our Networking code. These features have been more time-intensive to add because they combine in complicated ways: once tokens are being managed by a staking mechanism it is necessary to rebroadcast them if ATR exists, for instance, while nodes winding/unwinding the chain must keep the staking tables in sync as well. In addition to working on these problems we’ve also taken some additional work on our plate, such as shifting to use of a binary-format for block and transactions. This will eliminate the need for our core network to handle JSON data-format and is a step up in efficiency, since parsing JSON (reading and writing) is much more complicated than simply reading N bytes into memory.

Where does this put us for the next 2-3 months? My guess is that we have another two weeks of work on staking and networking before we can be comfortable that those components can support the functionality they need. The networking code will bring us to the point Saito-Rust can run as a full-node and connect to other full-nodes (we will continue to use Saito-Lite as the connection-point for lite-clients). Our staking implementation will support two-block payouts to start, with the golden ticket being used to pay out the block immediately preceding the block in which the golden ticket is found, but we will not recursively iterate beyond that to payout any unsolved blocks before that point.

Once our work on staking and networking is complete, all of the major components that need implementation in Rust should have been implemented. At this point, we will have a lot of somewhat arbitrary tasks to complete (i.e. distribute tokens on network start) and will need to develop systematic tests that cover different kinds of blockchain reorganization attempts. Our priorities for the remaining two months will cover:

fleshing out our testing suite not only to help debug the software and identify problems, but also ensure that monetary policy is working as intended and the amount of tokens in circulation remain constant across the range of network activities.
polish and improve documentation so it is easier for us to onboard new developers and our reference implementation is cleaner and has consistent naming conventions and behavior.
updating Saito-Lite (our in-browser client) so that it is compatible with Saito-Rust — the changes we have made to consensus have currently broken compatibility between the two codebases — this will likely be the most time-intensive part of the work that remains.
testing, testing, testing…
Beyond Saito-Rust, we have a few other tasks that are getting attention as time permits. These include polishing a new game for addition to the Saito Arcade, creating a general framework for easier crypto-integration so as to more easily support 3rd party cryptos people want to use, and finishing milestone #2 for our Web3 Foundation grant. We do not expect to spend time on public-facing materials like the website until Rust is complete.

Where does this put us in terms of our long-term roadmap? Once Saito-Rust joins the network we will make a substantive announcement about the timeline for development moving forward, including our target dates for supporting token persistence on the live network. The speed at which that will happen will largely depend on which kinds of work we need to prioritize once Rust is live on the network.

Hey, nice to meet you all! New to the site and to altcoins in general but loving the ideas and the community