Dev Status Update — March, 2020

Published by the IOTA engineering 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 IOTA research team is also releasing a monthly update.

Most of you are probably aware that the IOTA Foundation’s focus has significantly shifted throughout February into resolving the Trinity attack incident. The incident temporarily affected many of the development projects since the mitigation and resolution were pretty much ‘all hands on deck’ on many occasions. Nevertheless, we were able to keep on progressing towards our goals of making Chrysalis a reality.

Chrysalis

The research and engineering teams, together with the Hornet team, have been working on finalizing the specifications for the first Chrysalis changes. You can see the specifications in the linked RFCs, as well as comment and contribute yourself:

Weighted Uniform Random Tip Selection(Protocol RFC #8)
White Flag(Protocol RFC #5)
The ed25519 Signature Scheme(Protocol RFC #9)

The autopeering implementation is already being tested in the Hornet node software. The plan is to include autopeering already in the next release of Hornet.

The Bee team is making the final strides in building a prototype that will be, at first, internally tested in private networks with other node software implementations. The prototype ties together all the different existing crates to verify that there are no interoperability issues and we are now eager to test the crates in a heterogeneous network. The prototype is currently available here and will keep getting updated in the upcoming months. As soon as the functionality is validated, this will become an official iotaledger repo.

The RFCs have also been steadily progressing. You can find all the RFCs in their respective GitHub repository.

The IRI team has two versions of the node software in the pipeline to be released soon. The first IRI that goes out will be 1.8.5, with important changes to bundle validation rules.The current plan is to release IRI 1.8.5 and on Monday, March 23.These changes allow nodes to use simpler logic to validate bundles and address potential vulnerabilities.

We advise all node operators, especially public node operators, to update to 1.8.5 as soon as it is released.

Another version that will be released shortly after 1.8.5 is IRI 1.9.0. This has been in preparation for quite some time at this point and contains significant changes, like memory management, which significantly increase the amount of transactions the software can process. We will be describing these changes in more detail in a separate post.

Evaldas got a PoC of the smart contract layer working on GoShimmer. We’re evaluating the results right now to see where to go next.

The hardware PoC was delivered pretty much on schedule but the publication was delayed by the Trinity attack. We’re evaluating the results of the PoC and finalizing the associated blog post at the moment.

Given the Trinity attack incident of the previous month, we still recommend that users who have not migrated their funds do so immediately.

The team has released an updated version of both the mobile (Android,iOS) and desktop wallets recently. Please make sure you update to the latest versions on the respective platforms. Both versions include important fixes and updates.

The GoShimmer team is currently working on developing further components, like initial FPC implementation in a version of GoShimmer that will enable Ledger state and support value transactions.

You can follow the project on its GitHub repository. If you want to get involved, check out our updated contributing guidelines.

We are preparing to release an alpha version of the new MAM v1.1 to the public very soon. Please stay tuned for more information, and we’ll be looking for your feedback on the implementation.

One key thing about the new version of MAM is that it will function as an application called ‘Channels’ — that can be thought of as a significantly improved version of the previous MAM — and as a cryptographic framework on top of which the Channels application is built. This will let you build separate applications based on your specific needs using the same cryptographic constructs in case you need functionality different from what the Channels application supports. We believe this will significantly improve the area of scenarios that the new MAM implementation will be used for in the future.

As always, we welcome everyone to stop by on Discord— every project mentioned here has a channel (or more) for discussion with the devs!