Technical Progress Update September

[ - by ID.Iota]

GM 🌅 #IOTA Fam 🤖

We have managed to stay alive during September - notoriously known for being the month with the worst crypto performance year over year - and thus are ready for October and November - historically good performing months.

Fitting to that Theme, the IOTA Foundation also announced their plans to change the tokenomics of #IOTA within September. With the Stardust Upgrade the maximum Token Supply gets increased to 4,600,000,000,000,000 IOTA tokens (post Stardust upgrade they are called “micros”). 40% of the token supply will be allocated for a “New Ecosystem Fund”.

While this is hard to grasp, it also allows us to sustain and fund the development efforts for Layer 1 Smart Contracts and obviously IOTA 2.0. And with that lengthy introduction we are finally at the core of what we are trying to discuss today.

What happened with IOTA 2.0 in September?

Let’s start with a look into the statistics, since this should give you a little bit of insight into progress being made. Last time we analyzed the work on pull requests within the GitHub repositories of iota-core, iota.go and hive.go so let’s continue with that approach. The team has collectively worked on 90 (94 in August) pull requests, of which 83 (87 in August) have already been merged into the codebase, leaving 7 (7 in August) still open. So arguing by numbers you can assume that the overall activity is on the same high level that we have seen last month.

Before we dive into the actual Issues and PRs that are worked on remember to “Read the disclaimer baby!”:

Disclaimer: The information provided in these updates comes from the official IOTA GitHub (https://github.com/iotaledger) and the IOTA discord server (https://discord.iota.org). The interpretation of that information, however, does not represent official information from the IOTA Foundation. While we strive to ensure the accuracy and reliability of the content, it is important to note that the updates reflect community perspectives. For official announcements and statements, please refer to the IOTA Foundation's official channels and communications.

As usual, let's take a brief moment to recap what we discussed last month. In August we said that an initial release candidate of IOTA 2.0 might be nearly feature complete. We discussed four features that were missing to reach feature completion.

1. Adaption of the Autopeering Mechanism. ✅

In order to participate in the IOTA network a node needs to discover and maintain a small list of "neighbor" nodes that it communicates with. This process of discovery and start of communication is called autopeering. The iota-wiki contains a good overview of the process.

This Feature was tracked in Issue #49. It has been resolved with the merge of PR #316. So that Item is off the list.

2. WarpSync ✅

The second missing feature was WarpSync (Issue #193). A short summary by @hus_qy of the WarpSync Implementation is given in the picture below.

With PR #280 being reviewed and merged into the code base, the WarpSync Feature is adjusted according to the needs and the corresponding issue resolved.

3. TipSelection ✅

The TipSelection Process for Validators was due for a rework. The corresponding Issue was initially Issue #240, however it has been closed to restructure the problem into three separate Issues (Issue #299, Issue #308, Issue #309) that need to be addressed separately.
Relevant for the IOTA 2.0 testnet is only Issue #309 so far, since it will come with a PoA Consensus. Issue #309 has been resolved with PR #307.

4. Implicit Account Creation ✅

Last but not least, the Account Creation - Issue #278. I’ll cut it a little short here. This Issue has been resolved with finalization of PR #344 and PR #497.

So if the mentioned Issues were the only ones that needed to be implemented to be feature complete we should be feature complete right? RIGHT?!??

Well… Yes. We are actually super close. At least the node software is actually super close to being feature complete. Let me show you the newly integrated IOTA-core development Kanban-Board:

What you can see is the overview of Issues necessary to address to get the Node Software feature complete. As you can see the column “backlog” is empty. So they don’t have anything planned feature wise for the initial release of a iota 2.0 testnet.

There are three Issues being “in Progress” at the moment. Those are:

1. Add time restriction on the transaction creation slot #355

This Feature just adds a validation rule, that a transaction can only be added into a block if the transaction creation time is lower than the slot index of the block. This should be natural behavior, but they might have found a problem where they had to make sure only blocks that follow that rule are allowed.

The Issue is linked to iota.go PR #519. The PR has been merged a week ago. Usually this should resolve the Issue. Since i don’t have additional information i don't know if they just haven't updated the status of the Issue (to “Done”) or if they hold it for a particular reason. I’ll keep you posted.

Update 6th of October. The Issue is resolved. The corresponding PR is merged into the code base.

2. Faucet INX plugin #110

This issue is likely just a testnet feature allowing the community to automatically receive a few testnet tokens to play around with. It’s likely a simple task and should be resolved within a few hours, if someone finds time to work on it.

No PR is assigned yet.

3. Deal with loss of acceptance correctly #315

This is actually a pretty interesting topic. If you have the time please read through the Issue on GitHub. It’s just so well-documented.

Since most of you (including me obviously) are lazy however, and only get your butts up to ask for "wen?" I'll try to summarize it… In a cryptocurrency network, validators need to handle situations where they lose acceptance and don't have commitments for a certain period in the past (MaxCA). We need a set of rules to decide on how to behave if we lose acceptance. Those rules are discussed in the Issue.

The solution for loss of acceptance is defined in PR #379. This PR again is very well-documented and absolutely worth a read. Hans wrote a little bit of an TL:DR how it works. You can see it in the picture below.

The PR itself seems to be finished. It is ready to be reviewed and should be resolved soon. So that Issue won’t stay with us for much longer.

Update 6th of October. The PR has been successfully reviewed. The Issue should be resolved now.

So as you can see the Issues in the “In Progress” column all seem to be easy to handle or done. That leaves us with the Issues in “Discussion Needed”.

1. TX issuing user flow with Mana allotting #345

The Issue is well-explained. A block issuer needs to allot exactly the amount of mana in the contained transaction as it gets burned for issuing the block. This leads to a Hen/Egg problem, since the transaction itself leads to increased network workscore and therefore to increased Mana demand for block issuing. While issuing a block you would need to anticipate the necessary work score for that block.

The team has very likely managed to work around that issue through adjusting the mana calculation in a way it is predictable. This change makes it necessary to adjust the Evil-Spammer for test cases in order to align them. I don’t see why the Issue hasn’t moved on to “done” or at least to “in Progress” but it most definitely shouldn’t be blocking.

2. SegWit: TX ID over Essence only #346

This Issue with transaction malleability is also a well known one in the blockchain world. The Mt.Gox Hack was actually one of the biggest known exploit of “Transaction Malleability”. This Transacation Malleability has been solved through Segregated Witness (BIP141) - or SegWit. The team is aiming to implement a similar solution in IOTA 2.0.

I don’t see any actual progress yet. There is no discussion documented in the Issue, nor a pull request linked to solve the issue. So we will likely need to wait a week until we see some progress here. Nothing to worry about, more like a fix to think about and implement.

Update 6th of October: A corresponding pull request has been opened (# 389) and is already merged into the codebase. The issue hasn’t been moved to “Done” yet however, so there might be more to come?

That shall be it for this monthly development recap and outlook. As you can see the team is not only making progress on being feature complete but is also greatly improving the transparency of the code base and the actual development progress. This is huge, since it marks the first step towards actual permissionless innovation for the IOTA protocol. I have written in a Twitter Thread about that topic here.

So I expect us to be feature complete in the coming two weeks. This does not mean that we will get a testnet to play with in October. There is still a lot to do for getting the feature complete node protocol into a releasable state. At the moment the IF team is looking for additional 16 issues, they want to fix before they are happy to release a testnet. Furthermore I can’t comment on the progress for infrastructure that is necessary to use the network like a block explorer or wallets. So that might or might not lead to a few more additional weeks.

Keep your hopes high. We are still fully on track to get a testnet to play around this year. I wouldn’t expect to get a Shimmer Release of IOTA 2.0 but let’s hope for the best.

ID_IOTA