Dev Status Update January 2020
Published by the IOTA dev team every month, this update will provide you with news and updates about our key projects! Please click here if you want to see the last status update.
The whole engineering team is back after the Holidays break and we’re going full steam ahead towards implementing upgrades that will be visible both pre and post-Coordicide. You can see all the upcoming improvements on our roadmap. We will be using these monthly updates to summarize any changes to the roadmap, any additions, delays, or updates.
We are also discussing several improvements to the current Mainnet that would be implemented as a follow-up to the current improvements listed on the roadmap. These improvements would mostly be functionalities that will also be part of Coordicide, but might be worth implementing on the current network as well.
The Bee team has been finalizing different RFCs. The cryptographic hashes RFC, together with implementation examples. The RFC will now be in the final comment period before getting merged. The signing scheme RFC can then be finalized right after, implementing Seed, WOTS, and MSS. An async network prototype has also been implemented. This includes type/length denoted messages, a notify/callback mechanism, and the channel interface.
The team has been investigating possible storage backends for Bee, currently experimenting with SQLX, for example. The storage RFC and its first prototype will be then reviewed.
You can find all the RFCs and submit your own in their respective GitHub repository.
A prototype has also been initiated, gathering the different crate prototypes to have a first impression of the big picture, verify that there are no interoperability issues, give early feedback on the designs from RFCs and give something to the community to play with. The prototype is currently available here and will be updated during Q1. As soon as designs are validated by both RFCs and the prototypes they can be merged to the bee repository.
You can always see what the Bee team is up to in the open Discord channels where the day-to-day communication happens. See the 'bee-dev', 'bee-discussion', and 'bee-rfcs' channels. You can find the meeting minutes for both RFC and development meetings in the meeting minutes repository.
The IRI team has released two new versions of the software in the past weeks to fix immediate network issues.
Since then, we have been focusing on releasing the next major version of IRI, 1.9.0. This version will contain multiple fixes, as well as security and performance improvements. We are currently testing the new version and are about to provide a release candidate to the community next week.
The Qubic FPGA team is mainly focused on implementing the first PoC that can run an arbitrary function on the FPGA hardware by the end of January as per the roadmap.
Meanwhile, Evaldas has started implementing a first version of the Q-node and consensus layer on GoShimmer. We are also discussing two additional base protocol features with the research team. These features, once implemented in GoShimmer, will allow the protocol to support smart contract functionality.
The Trinity team has been hard at work to finalize the Trinity V1 feature set. The plan is to sign off on Trinity V1 and only engage in maintenance activities (i.e. bug fixes, stability fixes, etc.). The team would like to move full steam ahead and focus efforts on developing Trinity V2. Trinity V2 will be a much more extensive application with a decentralized chat and decentralized identity system.
In the past month, the team has made three key releases: exchange integration through MoonPay, a web-based wallet called Spark, and now a release candidate for a Spent Address Recovery tool. The Spent Address Recovery Tool will be released in full once sufficient community testing has been conducted.
Why do we need a Spent Address Recovery tool?
IOTA’s one-time signatures mean that it is unsafe to spend from an address more than once. So if tokens arrive on a spent address, spending them would put them at risk. While Trinity prevents sending funds to and from an address that has already been spent from, other clients and exchanges may not have these same checks.
The tool added in the Trinity Desktop 1.3.0 will allow users to unlock funds from spent addresses by a process we call “bundle hash mining”. This improves the security of the bundle and reduces the chance of the funds being stolen.
The GoShimmer team is a great example of the collaboration between the research and engineering departments at the IOTA Foundation. Members from both departments work together on feeding initial versions of researched components into a node software prototype.
We expect the prototype to be released at the end of January, as you can see on our Roadmap. The prototype will support 0-value transactions.
The team will then move on to follow-up components, like initial FPC implementation, or mana-based rate control in a version of GoShimmer that will enable Ledger state and support value transactions.
We have finalized the first draft of the MAM v1.1 specification and are now preparing a high-level overview to share along with the spec. Please stay tuned in the #MAM channel on our Discord where we’ll soon be sharing the spec, the overview, and the initial prototype. We’ll be happy for any feedback that will let us improve the specification and implementations of MAM v1.1.
As always, we welcome everyone to stop by on Discord— every project mentioned here has a channel (or more) for discussion with the devs!
Follow the IOTA Foundation on our official channels for the latest updates
Discord | Twitter | LinkedIn | Instagram | YouTube
