The Daily Degen Interviews Jonas Theis of the IOTA GoShimmer Team
Jonas Theis is an IF Research Engineer on the GoShimmer Team working on IOTA 2.0 (coordicide) and its implementation. We asked him some questions about the future since these features will soon be tested on the Shimmer network.
DD: In what order can the community expect different GoShimmer modules to be released on Shimmer? If this is still in development, which module will likely be released first?
JT: “In some way this is already happening right now: initial ideas for colored coins and output types were first tested on GoShimmer, iterated upon, improved and ultimately bundled into the Stardust upgrade.
As for upcoming components, one reasonable approach seems to be to start with the innermost components, meaning the UTXO VM abstraction and the parallel-reality ledger with its ConflictDAG. With these changes parallel, optimistic execution is possible which in turn needs changes to the data flow of incoming blocks and the white flag rule. However, the outcome of consensus could still be the exact same. Therefore, such an initial upgrade could be seen as implementation detail but under the hood new components are already battle tested. Following, components such as mana, congestion control and OTV can be ported of course as breaking changes.
Such a more iterative approach has the benefit of being fairly safe as components are tested step by step. However, it also creates additional overhead as many of the new concepts are not directly compatible with the current IOTA. Therefore, these concepts would need to be modified, newly implemented and tested in their new environment. Knowing how well we’re progressing with GoShimmer and how much we could simplify ideas, concepts and code recently, in my opinion, a better approach would be to take the solution as a whole in a bigger upgrade.”
DD: To build on this question: Which module needs to be tested the most on the Shimmer network?
JT: “Obviously consensus. We need to make sure that our theoretical results hold true and every participant eventually comes to the same conclusion and agrees on a common state especially in adversarial situations.”
DD: Let’s assume the modules have been tested thoroughly on Shimmer. Will the integration order on the mainnet be the same?
JT: I don’t see a reason why it shouldn’t be the same. But then again, maybe there are multiple modules already on Shimmer that can be activated on mainnet in a single upgrade.
DD: As new features are added to Shimmer, the network will likely need to be halted to allow time for the nodes to update. How often should we expect such outages and are there any negative effects of this we should be aware of?
JT: “We are planning to integrate an update signaling mechanism where nodes can signal their readiness for any given update starting from a specified epoch. Thus, it should be possible to create seamless upgrades in the future without downtime.”
DD: What would you identify as the biggest hurdle in executing a successful Coordicide event (or series of events)? Will it be hard to coordinate everything with other involved teams, like Hornet?
JT: “I currently don’t see any big technical hurdles regarding the solution itself. However, due to the vastly different nature of the IOTA 2.0 protocol compared to the current one, many of the APIs will need to change at least to some degree. We will try to keep these changes as little as possible but this still means that the whole ecosystem needs to adjust.
Regarding organizational structure, the Hornet and GoShimmer team are going to merge very soon to work on a common code base. It surely will be a big change in the way the GoShimmer team works: rapid prototyping and coming up with ideas and scratching them again vs. writing well structured TIPs and following proper software engineering principles to produce stable, secure, performant and well-maintainable software. But all our team members are very versatile and highly capable, so we should be able to shift gears easily :)”
DD: What fascinates you the most about the current solution?
JT: “Its simplicity at the core, the emerging complexity of these simple mechanisms interacting together and finally the resemblance of the physical universe. This is quite abstract, let me explain a bit more:
At the very core of our solution is the reality-based UTXO ledger which is basically taking the concept of UTXO, simply allowing conflicts to coexist and modeling these in a ConflictDAG (like quantum superpositions, in the end only one can survive, Schrödinger’s cat). This allows us to populate conflicts into the Tangle by means of the block that introduced the conflict. Now, every block that references a block with a conflict votes for it and implicitly its entire past (concept of causality).
Once a certain threshold is reached, the conflict will collapse and only the winning one “survives”, meaning consensus is found.
This process is utterly beautiful: the Tangle itself begets asynchronous convergence and thus ultimately consensus. No matter when and how a participant receives and “replays” the Tangle locally, it will always conclude the same result by just looking at the data structure. This is very different to blockchain: here the data structure is the result of consensus.”
DD: Since ZK-Rollups will greatly improve the scalability of IOTA, will research into sharding still be a focus? Why do we need sharding if we have ZK-Rollups?
JT: “I’m by no means an expert in sharding, ZK and rollup tech, and the question whether it will be a focus is anyway above my paygrade but here are some thoughts on it.
L2 solutions like ZK rollups rely on sequencers that usually need to be rewarded with fees for their service to produce these proofs. However, with the IOTA 2.0 L1 we are envisioning and building a system where you don’t need to spend your tokens to participate. So sharding can still be very interesting to keep this vision for as many participants as possible. Along these same lines, it might help to keep resource requirements relatively low so that many people can join the L1 network and verify, thus it should help to keep decentralization high.
Another reason might be that there will simply be too many specialized ZK rollups that are competing for scarce L1 bandwidth. Also “pure” rollups (posting data to the same settlement layer to retain L1 security) need to be considered.
And finally, a very practical consideration. It seems that ZK tech would also be very helpful when talking about sharding (e.g. going stateless, each block could proof its correctness). Therefore, advancing the ZK tech in the context of rollups makes a lot of sense now to enable more future use cases.”