Dev Status Update — November, 2020
The full article was originally published by Jakub Cech on Medium. Read the full article here.
Dev Status Update — November, 2020
The Chrysalis phase 1 components were deployed to mainnet in August. The engineering team is now working on Chrysalis phase 2.
Winternitz one time signature scheme support in Chrysalis phase 2
The initial IOTA protocol was designed with certain assumptions in mind. One of those assumptions was that we would make it resilient to quantum computing. To do so, we introduced the Winternitz one-time signature scheme (W-OTS). However, as time progressed, we realized that our dependency on this novel signature scheme brought drawbacks that hindered our technological progress in other areas. One time signatures present significant usability hurdles for users. That is why, earlier this year, we announced that we would add a more standard signature scheme to the protocol with ed25519. As we move towards Chrysalis phase 2, we have decided to take this one step further and start preparing for the complete removal of W-OTS from the IOTA protocol. We will share more details on what the transition will entail in an upcoming, separate post.
The removal of W-OTS will allow for a much more lightweight IOTA protocol, with smaller transactions, greater usability, and faster progress when developing new technology.
Nonetheless, we still consider post-quantum cryptography a critical topic for the long-term future of the project and are already working with leading post-quantum cryptographers to align with the NIST standards that arrive in 2021.
Implementing Chrysalis phase 2
We are making great progress towards implementing Chrysalis phase 2 in the IOTA protocol. We already have a testnet with working Hornet and Bee node implementations, with which we are finalizing the new node API and testing the new client libraries.
In the upcoming weeks, we plan on:
- Testing the first version of our new wallet software on the network.
- Making the testnet public. Our partners and exchanges will be welcome to test the new client libraries and plan for the transition of their integrations, while the public will be welcome to join the testnet as we test it more thoroughly in later stages.
With that in mind, we plan on having all the important integrations finalized (or close to finalized) in December. This will allow us to kick off audits and comprehensive rounds of final testing. We expect this audit and testing phase to take several weeks, meaning the new Chrysalis mainnet will launch early in the new year. Moving forward, we will release more frequent, weekly updates as we progress, so stay tuned!
Bear in mind we have also added the removal of W-OTS into the scope of Chrysalis phase 2. This saves us a later transition between Chrysalis phase 2 and Coordicide, or with Coordicide. We think it makes most sense to remove W-OTS now with Chrysalis phase 2 rather than waiting.
We will be releasing a new version, 0.3.1, of the Pollen network this week. This update will include different fixes, changes in dependencies, refactor of the message structure and more. You can read about the update in a post coming out tomorrow.
The team is working on the next large milestone, Nectar. Specifically, we will be focusing on the mana module.
You can read more about Pollen, Nectar, and Honey, concepts we introduced to talk about the milestones on the path to Coordicide, in this post.
The Bee team has finished the transition to a libp2p network and is working on setting up Bee nodes on the Chrysalis phase 2 alphanet that we use for initial Chrysalis phase 2 testing. The nodes are starting to process messages. After some design iterations, the storage layer is done and the mapping of the different types is ongoing. The new Local Snapshot format is implemented and the snapshot generation is yet to be done. Most of the White Flag UTXO ledger logic has been implemented. Most of the new Chrysalis phase 2 APIs have also been implemented.
The Bee team live streams have been moved to Monday. You can find all the live streams here.
You can find all Bee RFCs in their respective GitHub repository.
The team has significantly progressed with the implementation of Chrysalis phase 2 changes in the node software. One of the pieces has been the Proof of Work (PoW) for binary messages, which has been submitted to iota.go and delta local snapshots, which are in progress. Changes like the new node API, and local snapshots and solidification are working in the current development build.
The team has also been working on a release candidate of the 0.5.4 of Hornet, which mainly fixes a coordinator start-up race condition.
We have released the pre-alpha version of IOTA Smart Contracts. You can read all about it in this blog post. We are now working on scoping up the future development of the smart contracts protocol, to Wasp alpha, fully integrated Wasmtime VM and VM sandbox API, all the way to Wasp beta and more. You can find that on our roadmap.
Several improvements to the Stronghold engine have been undertaken during the recent refactoring, but most notably we are introducing a restricted runtime with memory-allocator that has been formally proven with COQ . We are currently building a proper top-level client library using Riker that will serve as the only entry point to Stronghold for all consuming applications (and bindings). The client will delegate incoming message requests to internal actors. Finally, we are finishing off the libp2p engine-actor to enable communication between Strongholds.
During the refactoring, we decided that it would be wise to move all cryptographic primitives outside of Stronghold, and thus the external crate known as crypto.rs was born. This crate will serve as the single source of acceptable and compliant cryptographic algorithms for all Rust projects at the IOTA Foundation — and will use feature flags so that consuming libraries and applications will be able to pick and choose what cryptography they will need. This library will then be audited by an external security consultancy. Ultimately, this will mean not only that we are using the same cryptography across product lines, but the tricky parts of choosing, configuring and implementing will only have to be done once.
The final few details of the wallet design are coming together, with the settings and onboarding illustrations still being worked on. The reworked dashboard is more or less complete, paving the way for the front end team to build out the dashboard UI. The wallet dashboard has been designed, thrown out, and reworked several times, and the version we have arrived finds a great balance between customizability and simplicity. This will provide a foundation from which to expand with additional features further down the road.
With the launch of the internal Chrysalis testnet, we have been able to begin testing wallet.rs against a Chrysalis Hornet node. wallet.rs has been built in isolation while we were waiting for the testnet, and unsurprisingly, hooking it up to a Chrysalis node has illuminated a number of bugs. We have been working through these and they are for the most part fixed. Now we await the Stronghold refactor before we can consider the library to be stable.
Work continues on hooking up wallet.rs to the wallet application. The vast majority of wallet functionality is provided by stronghold.rs and wallet.rs, so this task will form the bulk of the remaining work. Things are moving along and we are really looking forward to a first wallet alpha within the community. In parallel, pmaxuw AKA MicroEngineer has been working on the new Ledger Nano application, replacing WOTS with Ed25119.
We are releasing the first alpha version of DID later today. You will be able to read more information on the release on our blog.
We have recently released the last alpha version of IOTA Streams. You can read all about it and the next plans in this blog post.
The Chronicle team is now working on an RFC for the selective permanode functionality. The team, together with other members has also worked on the infrastructure for our new explorer. The explorer is wired to a cluster of permanodes.
IOTA Experience Team
The latest blog post regarding the X-Teams talks about how our efforts towards building bridges between the IOTA Experience Teams and the Tangle EE working groups, where IOTA community members can contribute to the IOTA vision alongside industry partners.
A big thank you to the IOTA X-Team members that supported the launch of the new Tangle Explorer by providing valuable feedback and user experience suggestions.
On November 4th the IOTA community kicked off the first 100% community-driven IOTA Experience Team, the Identity X-Team.
The IOTA Identity Initiative is a collaborative effort to help people in the IOTA Community by introducing consistent workflows around IOTA Identity with content, and open source contributions.
IOTA Identity is an implementation of decentralized digital identity also known as Self Sovereign Identity (SSI). It implements standards such as DID and Verifiable Credentials from W3C and other related (proposed) standards.
We welcome Carpincho Dem#0315, herrkpunkt#3501, Thoralf#3558, Stefano Della Valle#1445, Martin N#8948, Oostech#6884, Marek Tichy#7429, Tensor#2912, 31k3#8053, @anistark#4015, @openwebmarket#1623 and Aconitin#1833 to the Identity X-Team.
Learn more about this initiative and the goals in this GitHub repository.
Everyone is invited to the IOTA Experience Teams to pave the road for IOTA to have the best experience in the DLT and IoT space. Discover the IOTA Experience Team on GitHub, explore the IOTA Experience Initiatives and then apply through this form.
We have made the following updates to our roadmap:
- We added Smart contracts alpha as an item to finish early next year.
- We moved Chrysalis phase 2 items to finish early next year.
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 us on Twitter to keep track of all the latest news: https://twitter.com/iotatoken