Dev Status Update, August 2019

As we mentioned last time, the monthly update has become less Qubic-specific as we’ve recognized the need for more information about different projects, not only Qubic. With that in mind, we’ll be trying out this new format and including updates for all of the various project teams in a single post. Big updates such as new releases and the like will still get a separate post, but hopefully, this post serves as a good way to keep track of what’s going on at a high level.

And as always, feel free to stop by on Discord— every project mentioned here has a channel (or two) for discussion with the devs!

The Bee team is hard at work setting up the project and the initial architecture in a structured way. The Bee architecture will be based on the EEE specification developed by the Qubic team, which allows for maximum decoupling between modules. The team has been brushing up on the Rust programming language and the way it supports ‘fearless concurrency’ through the Rust ownership model. We already have a few community developers contributing their knowledge as well.

The Qubic FPGA team is making good progress with the Qubic Logic Element design that should allow us to use any FPGA as a programmable device for Qubics and even should allow us to have Qubic-programmable ASICs. We are expecting the programming interface document within the next few weeks so that Qupla can be adapted to generate the correct configuration data.

Apart from that, we are currently mapping out the messaging interface that will enable Assemblies to run their quorum consensus model as originally envisioned.

The team has made some big strides on IRI in the last month. Synchronization has received a huge speed boost — the synchronization TPS was previously under 100 and is now averaging around 2,000. During testing, we were able to sync a full day’s worth of transactions in under 45 minutes. The cumulative weight algorithm was also optimized, resulting in a 3x speed boost. These changes, together with the transaction caching layer that is still in progress will ultimately result in a smoother node operator experience and better overall network performance.

We’ve also been working on the developer-facing side of things, with improved regression tests and build pipelines, as well as some useful tooling like the database merge utility, which combines multiple database files into a single database.

GitHub: iotaledger/iri

The cIRI network refactor, local snapshots and pruning are all in, which puts cIRI very close to feature parity with IRI. The C Client, meanwhile, is up and running on ESP32 devices, and able to issue transactions and check balances (although the PoW should be offloaded to a more capable remote device). You can check out the C Client v1 beta on Github. The team is now working on some improvements to the TangleScope utility, general performance optimization, and getting Entangled to build on Windows.

GitHub: iotaledger/entangled

Last month was huge for Trinity, with the release of Trinity v1 across all mobile and desktop platforms. As discussed in the most recent Trinity blog update, the team is currently in the planning and ideation phase for Trinity v2, which will be a more extensible and flexible application that allows for third party plugins. If you haven’t already, download Trinity v1 right now at trinity.iota.org!

GitHub: iotaledger/trinity-wallet

The base layer of MAM is written in C and lives in the Entangled repository, but most developers will probably prefer to use MAM as part of their favorite client SDK. The Go, Java, and JS wrappers are well underway. Based on the feedback we have seen so far, we are planning a higher-level API that will make MAM easier to use for developers, and more capable of meeting different business requirements. In particular, we are looking at key distribution or key exchange, and group channels where multiple parties can securely write to the same stream.

GitHub: iotaledger/entangled/mam

As the usage of the Devnet has grown, we have added more resources and servers to keep the network running smoothly for developers building IOTA applications. The community-run IOTA Community Committee network is available for people who wish to experiment with the IOTA node software itself for things like stress tests and spam.

Since the ICC net launch, we have seen the IOTA Foundation’s Spamnet go largely unused and as such it will be decommissioned in the near future.

We hope this gives you a better idea of everything our team has been up to. We look forward to chatting with you on Discord!