We are happy to announce the launch of znet, the first iteration of the Coordinator-less testnet. This testnet has in fact been alive for several weeks, but we would like to officially open it up to community participation and contribution. To that end, we invite community members to join the discussion on Discord, to check out the live visualization of the znet Tangle, to contribute issues and code to the CLIRI Github repo, and of course: to run CLIRI nodes and join the network.

CLIRI and the Coordinator

Let’s take a step back and discuss why we need yet another testnet, and what makes CLIRI special. CLIRI stands for “Coo-less IRI”. At its core, it is a fork of IRI, with all Coo-related components removed. Its purpose is to provide a testbed for running a Coordinator-less IOTA network. This is a necessary first step towards understanding the challenges that a Coo-less mainnet will one day face.

Let us recap what the Coordinator actually does, in order to see what changes we have had to code into CLIRI. Every minute or so, Coo releases a milestone, which is a transaction signed by the IOTA Foundation. All transactions referenced by a milestone are immediately considered confirmed.

On its face, getting rid of Coo appears straightforward: we can just stop sending these milestones, or have CLIRI treat them like ordinary transactions, and we are done. Unfortunately, milestones come creeping back in several contexts:

Starting point selection. In IRI, the random walk starts a few milestones in the past. With no milestones to guide us, we need an alternative method for deciding where to start the random walk. We have come up with a rather rough heuristic algorithm , which works by backtracking from a recent tip until it reaches a point with enough cumulative weight. This part of tip selection is proving quite tricky to get right, and more review would be welcome.

In IRI, the random walk starts a few milestones in the past. With no milestones to guide us, we need an alternative method for deciding where to start the random walk. We have come up with a rather rough , which works by backtracking from a recent tip until it reaches a point with enough cumulative weight. This part of tip selection is proving quite tricky to get right, and more review would be welcome. Ledger state calculation. Milestones are used for optimizing ledger calculation. Rather than compute the full ledger state starting from the genesis, we save an intermediate state for each milestone.

Milestones are used for optimizing ledger calculation. Rather than compute the full ledger state starting from the genesis, we save an intermediate state for each milestone. Node synchronization. Milestones are helpful for determining when a node has fallen out of sync. If a node’s latest solid milestone is much older than its neighbor’s, it is probably lagging behind.

Zero-value testnet

In order to simplify the first iteration of CLIRI, we have decided to completely remove ledger validation: all transactions are valid, as long as they meet the PoW requirement. This version will be run on a new testnet, which we call znet, which stands for “zero-value’. Our aim is to stabilize this code and establish its resilience, before implementing more complex validation logic.

We would also like to gather more analytics about the performance of znet. For example, we introduced a new getConfidence API, which calculates a transaction’s confirmation confidence, as defined in the white paper. It would be interesting to track confidence levels over time, see what percent of transactions reach a high confidence, and how long it takes them to reach it.

We welcome community participation. You can help by running a CLIRI node, identifying issues, and participating in the discussion on Discord, in the #cliri-discussion channel.