Introduction

Focus intro

What is Chrysalis?

The name "Chrysalis" represents a fundamental, natural transformation into a mature design. A fitting name for the upcoming major upgrade where IOTA will implement significant improvements in performance, stability, reliability and security. It will also replace some exotic aspects (e.g., Winternitz One-Time Signature) of the protocol with established standards, and provide a wide range of new tools for developers, enterprises, and exchanges.

Chrysalis is the most comprehensive upgrade in the history of IOTA. It affects all aspects of the protocol, libraries, wallets, and software implementations developed by the IOTA Foundation. It truly marks a "new era" for IOTA by becoming production-ready and providing a base for upcoming features such as smart contracts and digital assets (tokenization). With these features, the community will be able to start many innovative startups, such as scalable automated market-makers, feeless decentralized financial platforms, or applications with powerful oracles and smart contracts.

The Chrysalis update already includes many aspects required for the removal of the coordinator. Many groundbreaking changes are anticipated with the upgrade, so only a few adjustments are needed for the actual Coordicide. This will allow enterprises, developers, exchanges, custodians and other partners to also begin implementing their solutions with the launch of Chrysalis.

What's new?

Path to Chrysalis

Firefly

A new wallet for IOTA 1.5

The upcoming fundamental changes in the IOTA protocol (new signature scheme, etc.) require a completely new wallet architecture. IOTA has taken this as an opportunity to completely rethink the wallet from the ground up, from transaction logic to user experience and design. The new wallet, called "Firefly," is intended to serve as a platform for the current and future IOTA ecosystem.

The Wallet's technical architecture and user interface were designed in the context of future additions such as digital assets, chat and contact management. Over the next year, a number of additional features will be added to the wallet. The first version of Firefly initially emphasizes security, ease of use, and an extensible architecture.

There are already some obvious differences from the old Trinity wallet:

• Profiles: The app can be used by multiple people on the same device without accessing each other's wallets.
• Accounts: A user can split their funds between, for example, a main account, an expense account, and a Ledger Nano account.
• Entering a PIN opens the wallet without ever decrypting the seed, so the account balance can be checked securely.
• Reusable addresses: The new Chrysalis addresses (Bech32 standard) look like this: iota11qykf7rrdjzhgynfkw6z7360avhaaywf5a4vtyvvk6a06gcv5y7sksu7n5cs
• 24-word recovery (Bip39 standard)
• Improved usability and network performance
• A network indicator displays information about the current state of the IOTA network
  

Under the hood

An extensible and exportable application core

With this concept, all developments from other programmers can be reused in new applications. Consequently, some useful tools already exist for other developers to create their own applications.

stronghold.rs - A secure multipurpose library for handling and storing seeds

Stronghold is the most relevant new feature that significantly improves the security of the wallet. Sensitive operations such as address generation and transaction signing take place in an isolated application memory, keeping the seed away from potential attackers. Stronghold also serves as a key-value store and is used to store applications. This means that the wallet becomes fully portable. To transfer the transaction history to another device or wallet-app, only a recent Stronghold backup is needed.

wallet.rs - A versatile wallet library.

All transaction logic in Firefly is provided by wallet.rs - a comprehensive IOTA wallet library written in Rust. The library provides all the functionality needed to create wallets and exchange integrations, from account creation and transfer initiation to state management and backup. The first version will come with Neon bindings for Node JS. Python and WASM will follow, with more to come at a later time.

With wallet.rs and stronghold.rs, developers can easily integrate secure wallet and payment functionality across a variety of use cases and environments. In addition, the mindset of reusability is also being applied to user interface design, and IOTA plans to provide a component library for developers to use in their own projects. At the same time, a plugin system with an access control API is being worked on to give users control over what features should be enabled in the wallet. IOTA anticipates a number of community projects developing wallets and other applications using these tools.

The future of Firefly

Firefly serves as an entry point into the IOTA ecosystem. IOTA will be adding new features in the future to improve the user experience as a payment protocol. However, the priority is first on the desktop version before turning attention to mobile devices.

The new wallet is a modular platform for different applications, possibly from third parties. The following section lists a few of these upcoming features:

• Mana delegation: This function will be mandatory in the mainnet after Coordicide. You will then be able to pledge the mana generated by the tokens held to nodes for a fee.

• Contact system: Account addresses can be linked to names. So Firefly solves the problem of complicated addressing of cryptocurrencies for users, for example, to make repetitive transactions (e.g., business contacts or friends) safer and faster.

• Chat with payment function: users should be able to deal with cryptocurrencies as easily as sending text messages or scanning a QR code. The messaging app is similar to the way the app WeChat (by Tencent) works. WeChat already covers more than 30 percent of mobile payments in China and is growing in popularity.

• Digital identity: Providing users with a digital identity increases trust in transactions. Users can enhance their profile with verifiable credentials such as third-party verified KYC information. Also, a user could easily identify themselves at various terminals using their cell phone via NFC. A digital identity implementation opens up a large set of other use cases.

• Browser extension: An extension is coming, however one may be curious about the implementation. Will it be similar to Metamask? Will there be a bridge to ETH? There are a lot of rumors, but none of them have been confirmed yet.

• DApp interaction: Various third-party apps will be able to communicate with the wallet and possibly with each other. For example, exchanges, stock exchanges or banks could use the IOTA wallet platform as a basis for their own applications to interact with the Tangle. This creates entirely new services and application areas. In addition to easier and faster buying / selling of MIOTA, this could also enable real-time EUR / MIOTA exchange transactions if the wallet would get a third party app with a banking license and thus direct banking connection.

• Access Control: Access can be granted to a wide variety of devices / locations with IOTA Access.

• Digital Assets: The management of Colored Coins and NFTs will also be possible with the wallet in the future.
  

Migration: What to keep in mind

Trinity

Ledger

Next stop: Coordicide!

What is...

Dust Protection

Since IOTA is feeless and allows microtransactions, such as 1 IOTA, attackers can easily "spam" the network. We refer to this "spamming" as "dust." To avoid this, we only allow microtransactions under 1.000.000 IOTA tokens to another address if it has already been loaded with at least 1.000.000 IOTA tokens.

How does it work?

Dust protection is hardcoded into the core protocol.

Each node must know the balance of each address (apart from zero value addresses). Otherwise you could spend more money than you have.

However, this circumstance could be used as an attack vector, in which one simply "loads" many addresses with 1 IOTA token each, because then all these addresses would have to be stored by the entire network, and so the memory requirement that each node basically needs (even without saving the current history of all transactions) would already grow immeasurably. To clarify the whole thing once again, with 1.000.000 IOTA (countervalue at the time of this article in about 1,40$) - one could already "dust" a million addresses with one IOTA each, and these would have to be saved forever by all nodes. This will be much more expensive for an attacker - and thus factually not "affordable" with the introduction of a "minimum balance", that each address must have according to Chrysalis. Strictly speaking, this value is at least 1.000.000 IOTA per address.

However, it is not impossible to send smaller amounts. Because as soon as an address has this minimum number of value, one can receive with it 10 smaller transactions of any amount, until one must recharge the minimum value again. However, further action is required for this - you have to enable so-called "SigLockedDustAllowanceOutputs".

RFC Link

EdDSA Support

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 Shor's 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, enough information is exposed that the private key, and thus the money at that address, is considered insecure. This is 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 Transaction

IOTA 1.0 used the concept of bundles to create transfers. Bundles are a set of transactions that are linked together by their root reference. These transactions have a fixed layout and size regardless of their "content". A signature with security level 1 would also fit into just one transaction, but security level 2 signatures are used by default. 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 transmission: 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 more simple Atomic Transactions were introduced instead. This change brings the following benefits:

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: Single 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.

UTXO

The implementation of the 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 with the UTXO model. UTXO stands for “unspent transaction output”, which simply means keeping track of not only the balances on the address, but also where the balances come from and where they are sent when they are spent. This means that each token is uniquely identifiable and each output names exactly the token that it wants to move. Each transaction consists of any number of inputs and any number of outputs. The inputs of a transaction are always also outputs of a previous transaction.

This enables faster and more accurate conflict handling and improves the resilience as well as the security of the protocol. In addition, the move to UTXO will enable the use of digital assets on IOTA. Together with Mana (Coordicide), this will result in a very attractive tokenization model in the near future and will further drive the adoption of the IOTA token.

The old model: IOTA 1.0 used a credit model to track addresses, where each address has 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. Example:

Image: Which of these three transactions is a double spend? This is unclear for a credit model, so all 3 would have to be considered as a double spend.

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. Example:

Image: In a UTXO model, each expenditure uniquely identifies which funds were spent. In this way, it is possible to directly identify which transactions are inconsistent (the yellow funds are used twice).

A UTXO model would also allow for easy implementation of features such as “Digital Assets” where users can mark IOTA tokens to have (and keep) 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.

Advantages UTXO model:

• Faster and more accurate conflict handling
• Support for digital assets
• It is impossible to steal funds by reattaching old transactions

Disadvantages UTXO model:

• Somewhat larger transactions, as the identifier of the tokens being moved must be “named”.

Autopeering

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, that are not trying to harm the network. In IOTA's autopeering 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 autopeering mechanism will attempt to create a small global network in which nodes can be reached by any other node through a small number of intermediate steps. This feature speeds up the time to reach consensus.

Whiteflag

URTS Tip-Selection

Due to the white flag confirmation algorithm, it is no longer necessary to perform a 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 used 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 random walk. This was essential for consensus building, but also introduced some undesirable properties: Honest transactions could become 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 messed with the 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 accidentally attached to the wrong part of the Tangle. Using different mechanisms for tip selection that are no longer based on cumulative weighting and have a lower chance of leaving valid transactions behind.

New Milestone Selection

Binary Transaction Layout

Switch to an internal binary representation of the ternary 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. This is only the result of an additional conversion to base 3.

The old ternary transaction layout consisted of the following types:

• Integers: Integers are simple to encode in binary form.
• Hashes (hash (Curl), address (Kerl), bundle (Kerl)).
• Signature message fragment

In the future, ternary strings will be encoded as:

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