IOTA 1.5 Chrysalis Improves Usability, Reliability & Scalability of IOTA(MIOTA) Cryptocurrency.

Major Performance and Reliability Improvements

Chrysalis was the most extensive upgrade in the history of IOTA. It affected all aspects of the protocol, libraries, wallets, and software implementations developed by the IOTA Foundation. The Tangle upgrade fixed open technical issues and inefficiencies and implemented significant improvements in performance, stability, reliability, and security. Exotic aspects of the protocol have been replaced with established standards, and a wealth of new tools have been made available to developers, enterprises, and exchanges.

The Chrysalis update already includes many aspects required for coordinator removal. Many fundamental changes have been made deliberately so that only a few adjustments are needed for the actual Coordicide event. With these important protocol improvements, the process of adoption will be significantly accelerated because it will allow enterprises, developers, exchanges, custodians, and other partners to immediately begin implementing their solutions because there will be no more fundamental protocol changes (signature scheme, ledger state, etc.).//www.youtube.com/embed/4X6TqN6lQhs?feature=oembedSource: Everything Tangle

The results of the improvements

• Transaction confirmation times of about 10 seconds
• Transactions very rarely need to be reattached
• A significant MPS increase (TPS) in the mainnet
• Performance and reliability improvements for nodes
• Reduced node setup times through autopeering
• Reusable addresses and support for more standard cryptography (EdDSA), enabling hardware support for all major architectures
• Simplified transaction layout and a reduction in transaction size, further improving performance
• Introduction of new features, such as tokenized assets (digital assets)
• Significant improvements to the usability and reliability of IOTA.

Which parts of the protocol have been changed?

Support for a new signature scheme

The current IOTA protocol is based on the Winternitz One-Time Signature (W-OTS) scheme, a hash-based signature scheme that uses the ternary 243-trit hash function Kerl. This signature scheme has been shown to be resistant to a sufficiently powerful quantum computer running the Shor algorithm. However, unlike conventional ECDSA or EdDSA signatures, it also has significant drawbacks.

State dependency: W-OTS allows only a single secure signing operation. From the second signature on, so much information is exposed that the private key, and thus the money at that address, is considered insecure. This poses a serious security risk, since signing a single invalid transaction must be considered as dangerous as revealing the private key itself.

Size: The signatures generated are quite large. In IOTA, 2187 to 6561 trytes or 1300 to 3900 bytes (depending on the security level chosen) are reserved for the signature.

Speed: It is based on the hash function Keccak-384 and was developed to achieve a compromise between size and speed. For example, in the default setting, the hashing function must be executed 702 times to validate a signature, which can lead to significant system overhead even on powerful hardware.

Chrysalis introduces the new common signature scheme Ed25519, which completely replaces the old W-OTS scheme. The Ed25519 is a modern EdDSA signature scheme that uses SHA-512 and Curve25519. It drastically reduces the transaction size and consequently allows a significant increase in possible messages per second (mps). Another advantage is the reusability of addresses, which significantly increases usability and also greatly simplifies the implementation of IOTA technology in apps, exchanges or other systems. One disadvantage, however, is that it is less quantum robust, but this is a problem that most conventional encryption systems currently have. Currently, research is already being conducted worldwide on suitable new signature schemes and as soon as there is a viable solution, it can simply be adopted by IOTA.

Atomic transactions

IOTA 1.0 uses the concept of bundles to create transfers. Bundles are a set of transactions that are linked together by their root reference (trunk). These transactions have a fixed layout and size regardless of their “content”. A signature with security level 1 would also fit into only one transaction, but by default security level 2 signatures are used. However, since the level 2 signature of value transactions does not fit into a single transaction, at least 3 transactions must be used to create a simple transfer: 2 transactions for the input + its signature and one transaction (without signature). Another disadvantage of bundles is mainly faced by developers, because it is much more complicated to get all transactions from a bundle and arrange them properly, instead of just processing a single message.

With the update to IOTA 1.5, the old bundle construct was removed, and the simpler Atomic transactions were introduced instead. This change brings the following advantages:

• Less network overhead: The transaction format can be adapted so that only the information that is really needed is transmitted. A lot of unnecessary information, such as for the successive transactions of a bundle, can be dispensed
• Fewer signature verifications: After Coordicide, each transaction must include the node ID and signature of the node that issued the transaction. This means that for a simple transmission, the signatures of at least 3 transactions must be verified. Signature verification is the most costly part of transaction processing. Therefore, the introduction of node IDs would reduce node performance by at least 300% if the original bundle approach is maintained. The bottom line is that nodes will be able to process hundreds, perhaps even thousands, fewer transactions than would be the case with atomic transactions.
• Better spam protection and overload control: The size of the bundle is not known until the last transaction has arrived. This could result in a certain number of transactions being accepted and routed, only to discover later that the issuing node has exceeded its quota (rate control) and subsequently disregard all further transactions. This means that transactions were currently being routed and processed that should have been filtered from the beginning if it had been known that the issuing node was trying to send a transfer that was too large. This could even open up an attack vector where a node issues different bundles to different people, who all start processing the bundle’s transactions and then drop them at different times, unnecessarily increasing the load on the network.
• Shorter Merkle proofs (for Sharding): Merkle proofs for inter-shard transactions become much shorter (at least 300%) when not all transactions in a bundle have to be passed through to get to the next transfer. This makes inter-shard transactions much faster and more lightweight.
• Developer-friendly: Individual messages are much easier to process.

Conclusion

Atomic transactions are much faster, more flexible (variable transaction size) and put less load on the network. They are also better suited for later Sharding / slicing than bundles.

Switch to UTXO model

The implementation of the new ledger state is one of the last steps to a fully functional prototype of the Tangle without a coordinator, so it should be implemented immediately and in the right way using the UTXO model. UTXO stands for “unspent transaction output,” which simply means keeping track of not only the credits on the address, but also where the credits come from and where they are sent when they are spent. Each token is uniquely identifiable and each issue names the exact token they want to move.

The “unspent transaction expense (UTXO)” model defines a ledger state where balances are not directly associated with addresses, but with transaction expenses. In this model, transactions specify the outputs of previous transactions as inputs that are consumed to generate new outputs. A transaction must consume the entirety of the specified inputs.

The old model: IOTA 1.0 used a credit model to track addresses, where each address had only a single value associated with it (the current credit balance). The ledger state can therefore be viewed as a simple directory of addresses and their corresponding credit balances:

• Address 1 = Balance 1
• Address 2 = Balance 2
• Address 3 = Balance 3

Problems

In the case of conflicts such as double-spends, it is difficult to figure out which of several transactions is actually a double-spend and which transaction uses legitimate funds. This massively limits the ability to handle conflicts efficiently and increases the size of conflict records.

With IOTA 1.0, this is not a problem, as the “heaviest subtangle wins” rule only needs to ensure that the addresses of a given subtangle never go negative.

With the new voting-based Coordicide solution, it is necessary to identify the conflicts that arise in transactions as quickly and as accurately as possible in order to vote on them. This would massively reduce the number of votes that need to be exchanged.

Another problem with using a credit model is related to reattachments. If someone ever receives funds for an address from which spending has already occurred, anyone can simply reattach the previous spending and empty the address again (even without access to the address’s private key). This has already been used as an “attack vector” when users have not followed the advice to use addresses only once.

The solution

Using the UTXO model to keep track of credits, each address would contain not only its total balance, but also multiple sub-balances tagged with a marker indicating which transaction created the balances. Each token on an address would therefore be uniquely identifiable, and each issue would name the exact token it wishes to move. This would help identify conflicts and also prevent malicious actors from spending newly received funds by reattaching an old transaction.

Using a UTXO-based model offers several advantages:

Parallel validation of transactions.
Easier detection of duplicate issues, since conflicting transactions would point to the same UTXO. This means faster and more accurate conflict handling, accordingly resilience as well as security of the protocol is improved.
Repetition protection, which is important when you have reusable addresses. The repetition of the same transaction would manifest itself as already applied or existing, and thus have no effect.
The UTXO model also allows for easy implementation of features such as “digital assets” where users can mark IOTA tokens to have (and retain) a pre-determined “meaning”. Considering that 99% of existing smart contracts attempt to simply create “tokens” that relate to a specific use case, this is an interesting feature that adds a lot of value to the IOTA ecosystem.

Technically, balances can no longer be linked to addresses, which increases the level of abstraction, allowing for other types of outputs. For example, consider an output type that specifies the balance to be unlocked from a transaction that must meet a proof-of-work difficulty or provide some other unlock criteria, etc.

Within a transaction that uses UTXOs, inputs and outputs form the transaction data to be signed. The section that unlocks the inputs is called an Unlock Block. An Unlock Block may contain a signature that proves ownership of the address of a particular input, and / or other Unlock criteria.

The following image shows the money flow with UTXO:

Auto-Peering

In peer-to-peer networks like IOTA, a node’s neighbors are the only source of information. A peering mechanism must therefore focus on a healthy number of honest neighbors, hence on nodes that are not trying to harm the network. In IOTA’s auto-peering mechanism, each node has its own criteria for selecting potential neighbors. An attacker cannot influence a node’s decisions in the peer selection process. Therefore, a node’s particular “view” of the network is both local and unpredictable. This serves to protect against outside attacks (e.g., Eclipse attacks) and makes it virtually impossible for attackers to target specific nodes in the peering process, while ensuring that nodes always have at least a certain number of honest neighbors.

In addition, the auto-peering mechanism will attempt to create a small world network where nodes can be reached by any other node through a small number of intermediate steps. This feature speeds up the time to reach consensus.

White-flag approach

The white-flag approach to calculating credits is a simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks (e.g., conflict spam), and significantly reduces the need for reattachments. Coordinator milestone provisioning is a powerful tool, which provides global and immutable timestamps. In this way, a well-defined and globally accepted method is specified to calculate the ledger status of a milestone, even if it contains conflicting transactions in its past.

Advantages of the new approach:

• The complexity of the balance calculation is the same as the complexity of sorting all new transactions by hash (or similar), which can be done very efficiently.
• A conflict has no other impact on the system than any other transaction. Thus, the conflict spam attack is completely eliminated.
• Reattachment is simple: If two reattachments are approved by milestones, the second one is ignored.
• Since conflicts are ignored in the balance calculation, they do not need to be considered when selecting the peaks of the nodes. This allows for much simpler peak selection algorithms and speeds up this step significantly.
• If you use this approach in combination with an appropriate TSA, no honest transaction will ever need to be reattached if used regularly.

Improved tip selection

Due to the white flag confirmation algorithm, it is no longer necessary to perform complex tip selection such as the “random walk”. Therefore, a simpler, more powerful tip selection algorithm can be used, which in turn increases overall message throughput. The new URTS tip selection in the Node software is significantly faster and more efficient than the old approach in IOTA 1.0.

The tip selection algorithm is the process by which transactions are selected for approval. A good algorithm allows the Tangle to grow in a stable and secure manner.

To attach a new transaction to the Tangle, the algorithm can select and approve up to eight previous transactions – preferably tips. This approval mechanism represents the “belief” in the Tangle: If transaction y approves transaction x, it means that y believes that transaction x is valid and that its entire history is also valid.

In the past, the algorithm used for tip selection was the “random walk”. This was essential for consensus building but also introduced some undesirable properties:

• Honest transactions could go neglected if they did not have enough weighting. This led to an increased need for promotions and reattachments (even without attacks), which in turn significantly affected transaction reliability.
• Attackers played with random walk and created malicious structures such as parasitic chains, thus splitting attacks were carried out to prevent the network from reaching consensus.
• Calculating the cumulative weights of transactions is relatively expensive and poses a problem for the scalability of the protocol, especially in high-throughput scenarios.

Adding a voting layer to identify the preferred part of the tangle (as an additional module) results in the following benefits:

• Faster conflict resolution, reducing the likelihood that a transaction will be inadvertently attached to the wrong part of the Tangle.
• Use of different tip selection mechanisms that are no longer based on cumulative weighting and have a lower chance of leaving valid transactions behind.

New milestone selection algorithm for the coordinator

A new milestone selection algorithm (IOTA 1.X only) that aims to ensure that the network supports as much CTPS as possible, with higher computational efficiency.

Switch to an internal binary representation of the trinary transaction

This allows binary data (1,0) to be used for validation and other processing without requiring many binary-to-ternary conversions as in the old IOTA 1.0 node software. This should lead to further performance improvements.

Technical details: in the IOTA 1.0 mainnet, a transaction consists of 2,673 tryte-encoded characters and is composed of various fields of different tryte lengths.

It is important to note that with the currently used Kerl hash function, a hash (and thus an address) is naturally composed of 48 bytes rather than 243 trits. This means that for each address or hash, the 48 byte representation is absolutely equivalent to the 243 trits representation currently used, which is only the result of an additional conversion to base 3.

The old ternary transaction layout consisted of the following types:

• Integers > Simply to be encoded in binary form.
• Hashes (hash (curl), address (Kerl), bundle (Kerl).
• Signature message fragment

Ternary strings will be encoded in the future as

• 1 byte per tryte (3 trits),
• 1 byte per 5 trits or
• native 48 bytes for Kerl hashes.

https://www.youtube.com/embed/3dFLbPup9gY?feature=oembedSource: IOTA Foundation

More Details

Official Homepage

Infos about the upcoming Chrysalis migration – IF

A new dawn – IF

Coordicide – The road ahead – IF

Release strategy for Chrysalis – IF

Sources

Source: IOTA Foundation