IOTA Smart Contracts

This article is a translation of the German IOTA Beginner’s Guide by .

IOTA Smart Contracts

Important: All information listed here has not yet been officially confirmed. Everything is based on Discord statements from various IF employees.

Before we define a Smart Contract, it is important to first understand what a legal contract is.

Legal contracts are non-deterministic agreements that are subject to complex legal systems. The laws governing contracts vary depending on a number of factors, such as the country in which all parties entered into the contract. The most important word here is “non-deterministic”. This means that contracts are often ambiguous and their subjective interpretation can lead to disputes.

What is a Smart Contract (SC)?

A Smart Contract is a programmed agreement that is fully deterministic and automatically enforced by encapsulating the contractual obligations between buyer and seller in the software. This makes it impossible to deny this agreement.

Basically, SCs were created to make the enforcement of a contract by third parties, such as a central authority, unnecessary. SCs enable the execution of trustworthy transactions which are traceable, transparent and irreversible. “Experts” are generally expected to use SCs in the future to replace many types of real paper contracts. With these new technological possibilities, many types of business processes in many industries can be executed much more efficiently and costs can be reduced.

Whether and how SCs will find their way into the mainstream in the future remains to be seen. Because in addition to the unresolved legal issues, 99% of existing SCs are currently trying to simply create a “token” that refers to a specific use case. IOTA could also solve this problem with the earmarked digital assets.

IOTA Smart Contracts

The IOTA Smart Contract Protocol (ISCP) was derived from the Qubic project and preserves many of its useful features. The new SCs can be seen as an offset that shifts priorities towards a pragmatic solution. In essence, IOTA Smart Contracts are “Quorum-based Computations” and therefore do not deviate too far from the “original” Qubic vision.

As requested by many members of the community and industry partners, the new SCs are now completely detached from the hardware and computational model. Therefore, in the future it will not be so important what kind of processor (binary, ternary, CPU or dataflow) performs these computations. What matters is how a group of independent processors performs a distributed consensus using quorum voting.

The goal was to specify and implement a concrete architecture that allows Qubics, Assemblies, Oracles, Q-Nodes and Oracle machines to interact, but without the Qubic computational model and the Abra programming language. Many concepts from the original Qubic vision such as on-tangle messaging, on-tangle consensus and Q-tangle had to be abandoned because they were slow and vulnerable to all kinds of attacks. However, some limitations could be solved, Qubics were not able to move tokens (funds) in the old Qubic construct. With the introduction of the UTXO transaction model, this is now possible, allowing IOTA SCs to own and move IOTA tokens and digital assets.

Fees

IOTA Smart Contracts use the logic of UTXO Digital Assets ( also known as Colored Coins). To create an SC, a new Digital Asset must be created and sent to the address of the SC. This transaction becomes the origin transaction (Genesis) of the SC. No additional fees or similar are charged for this process. This created Digital Asset, which represents the SC, remains at the address of the SC for the duration of the SC’s term and is therefore the property of the SC.

To send a request to the SCs, a Digital Asset must also be created in this request transaction and sent to the address of the SC. This request coin is always sent to the SC and remains the property of the SC (at its address). This only temporary Digital Asset will be converted back to the original IOTA Token when the request is processed (settled, confirmed) and remains in the SC.

Since the original transaction usually includes an initialization request to create a SC, at least 2 IOTA Tokens are required to create a SC.

Charges are necessary. They are an incentive to induce nodes to execute the SC code. With this solution, the whole network is not forced to execute every SC code (as with ETH). Instead, only a relatively small group of nodes is specially selected to execute a certain SC and, if necessary, rewarded accordingly.

However, if there are other incentives to execute the SC code a fee is not required. An already sufficient incentive could for example be the registration of the SC state changes on the tangle itself. An example would be the aggregation of Oracle raw data for further processing. Another example would be if a consortium of competing players wants to have an honest audit trail that none of them can influence. Their incentive to perform an SC would be to keep an eye on everyone else.

The IOTA Smart Contracts Fee Model:

• The fee model is hard-coded into the core protocol
• Preset: Fees = 0 (feeless)
• Fees = Validator fee + Chain owner fee
• Different tokens for chain fees possible (colored coins), IOTA color ID is preset
• Chain Level: Preset validator and chain owner fees
• Smart Contract Level: individual validator and chain owner fees for a contract
• Fees are managed / set by the chain owner by consulting the root contract
• The fee model can be extended by smart contracts for each use case

How do SCs work at IOTA?

IOTA SCs are defined as immutable state machines:

• State Machine: Every Smart Contract has a state that is connected to the Tangle. The state contains data like account balances, input conditions and consequences over time. Each state update represents a state transition on the tangle.
• Unchangeable: The Smart Contract’s state and program code are both unchangeable because they are stored on the tangle. The state can be updated incrementally by appending new transactions to the tangle.

The Tangle provides a verifiable audit trail of state transitions. This provides confidence that the state transitions are valid and cannot be corrupted by malicious or faulty nodes.

The benefits of Second Layer Smart Contracts

To facilitate use cases, including the Internet of Things, IOTA builds its SCs on layer 2, “off-Tangle”.

Although Ethereum’s “on-chain” Smart Contracts are very popular because of their features, they have some significant drawbacks. The most prominent is that each node must keep a copy of the program code and status of the contract for each SC that exists. Each node in the network must execute exactly the same code when the SC is triggered.

There is no limit to the number of nodes that must execute this identical code just to produce a single result. And the larger the network gets, the more processing is needed to achieve the same result. This is a huge barrier to scalability.

In addition to the transaction fees you have to pay to be considered for inclusion in the ledger. You also have to pay gas fees to keep the program running long enough for it to be completed. This means that the cost of running these SCs becomes prohibitively high, except in certain use cases where the cost is relatively insignificant.

For this reason, IOTA SCs are not implemented as part of the core protocol, but as a second layer protocol.

As a result, IOTA SCs provide a more natural way to perform distributed computations. Each smart contract can be executed in a localized context without forcing the entire network to perform the same task. This also means that IOTA SCs will not become a barrier to scaling for the IOTA network with sharding solutions in the future.

Execution

The execution of an SC is performed by a committee of nodes of fixed size (with distributed sharing of private keys), which execute a program by consensus and send the results to the tangle. The fixed size is determined by the owner (issuer & operator) of the SC. For threshold cryptography hundreds are still a practical size. The minimum is one node, which means that it is only one centralized script that processes SC requests. Committee nodes are identified by their addresses in the network, known only to the owner, other committee nodes and other trusted (so called access-) nodes.

Owner of a Smart Contract

Every smart contract has an owner who is responsible for:

• Creating the SC program and submitting it to the network.
• Determining the size of the committee (the number n) and selecting the nodes that will be part of the committee.
• Deciding how many committee nodes need to reach consensus on SC status updates. This number is called a quorum.
• Determining other general configuration parameters of the SC.

An owner may be a single entity, e.g., an organization or an individual, or it may be a decentralized collection of peers, e.g., a consortium of organizations. In either case, the owner only manages the establishment and configuration of the SC and does not participate in its operation.

The owner can choose how SCs are set up depending on the context and purpose. For example, an SC that handles high-value transactions may require a large committee of nodes while an SC that handles microtransactions may only require 20-30 nodes.

Motivations: Rewards and Reputation

There are many possible reasons to create or run an SC. One reason is rewards. Although IOTA transactions are free of fees, IOTA SCs offer companies the opportunity to charge a fee in IOTA tokens, e.g., to cover operating costs. We call this fee a reward.

Both owners and committee nodes can receive SC rewards. It is up to the owner to negotiate with committee node operators to determine the minimum acceptable reward.

Committee Nodes can receive rewards by working a specific SC that offers a reward.

Owners also have the option to create Smart Contracts that give the owner a percentage of the reward.

Another potential motivation for joining a committee is to build a good reputation. Smart contract owners may choose to form committees only of nodes with a good reputation. This type of reputation system could create an open market for committee nodes that encourages good behavior in the network.

The Smart Contract Program

An SC program is an algorithm that contains instructions for a virtual machine (VM). IOTA uses WebAssembly (WASM) as the main VM for IOTA SC. But in general, the VM can be programmed in any language or even hard-coded in the node’s software.

The program takes two transactions as input: the request transaction and the current state transaction. The transaction of the next state always refers to the request transaction and the transaction of the previous state. In this way, the SC program has a deterministic method for building a chain of state updates triggered by incoming requests.

The hash of the program is stored in the tangle and is therefore immutable.

Note: IOTA smart contracts are defined by a transaction rather than a bundle, as they will implement in the post-coordicide IOTA protocol, which uses a UTXO model for value transactions

Example of a smart contract program

The following is a brief description of the FairRoulette SC, which is used for internal testing at IOTA:

Consider an SC that accepts bets on a roulette wheel. The smart contract would hold stacked IOTA tokens in its account, as well as data about each bet placed (amount, color, player). The latter is needed for payouts to roulette game winners.

To place a bet, you send a request transaction to the smart contract. The transaction would include:

• A fee payment of IOTA tokens for processing costs.
• A deposit of IOTA tokens that you would like to bet on
• The color you are betting on

When the committee nodes then see this transaction, they will run the SC’s program to update the state with your bet. The payout to the winners will be executed automatically after the game ends according to the SCS’s program.

There are also many ways in which SCs can be executed together with other SCs. For example, multiple SCs can share the same program but run on different addresses / committees. If they are automatically requested together, this configuration would create a redundant processing group of duplicate SCs. However, multiple SCs with different programs can also run on the same address (=same committee), or that one SC spawns another SC, and so on.

The committee and the quorum

The account address of the smart contract is owned by the committee. This address contains the deposited IOTA tokens. Only a quorum of committee nodes is able to transfer tokens away from the address. In other words, a quorum of committee nodes must work together to transfer the IOTA tokens from the account.

IOTA uses the Boneh-Lynn-Shacham threshold signature scheme (BLS) for multisignature addresses to give the nodes on the committee equal ownership rights over the address. These addresses enable threshold signatures, which means that a certain number of nodes in the committee, the quorum, must sign the same transaction with their secret key.

Each node on the committee owns a secret share of the key and only collectively through the quorum consensus process (usually 2/3 plus 1), a valid signature can be generated, the state of the SC updated, and funds moved that are controlled by the SC.

In other words, this means that signatures for transactions are created without knowledge of the master key (seed) through collaboration between nodes. The seed management required for this is implemented using the BLS. The seed for the monetary value transfer is divided between the committee nodes, because there is no such thing as “the seed”. Instead there are many private keys that together control the address. Each private key is hidden in the registry of the node and is not known to anyone else. Together, these private keys represent a master private key, a virtual one because it is not known to anyone including the Nodes. The SC account address is controlled by this private master key.

How Smart Contracts are created

The owner of an SC creates the program, and its binary code is stored in committee nodes. The hash of the program is always accessible through the state of the transaction, so the SC is immutable.

The owner appoints a committee of nodes responsible for executing the program, listening to the tangle for request transactions, and collectively updating the state of the SC.

During the establishment of the committee, the owner determines the size of the committee and the quorum, and initializes a Distributed Key Generation (DKG) process among the committee nodes. This process generates:

• An account address controlled by the SC
• A private key for each committee node (not known to the owner or other committee nodes)

This process can be either centralized or decentralized. In the centralized version, the owner can use a master key to override committee decisions if needed. In the decentralized version, the owner cannot override decisions.

How the status of a Smart Contract is updated

Committee nodes always listen to the Tangle for request transactions to be sent to the SC.

When a committee node detects a transaction, it computes the next state by running the SC program. In this way, honest and synchronized nodes will always generate exactly the same state update. Committee nodes never exchange real results, only hashes. So there is no risk of nodes copying each other’s results to try to get the reward.

If nodes do not agree on the updated state, each will sign a different transaction, resulting in an invalid signature. Therefore, the nodes must reach a majority consensus on the updated state.

In the asynchronous setting of the Tangle, each committee node may see a different state depending on its local clock or its neighbors. Committee nodes must therefore run a distributed consensus algorithm to reach consensus on the outcome. The result of the consensus is a hash of the result kernel, a collection of partial signatures of the BLS, and a timestamp. All SC transactions are timestamped, and the timestamp matches the local clocks of most nodes. When all nodes have reached consensus, a committee member, the leader, collects all partial BLS signatures from the nodes before submitting the final transaction to the Tangle. This transaction must reference the previous state to create a chain of state updates that serves as an audit trail. When the transaction is committed, it becomes the new state of the smart contract.

Trust, decentralization, data security, mana, rate control system

Every actor should know that there is no such thing as 100% trust, neither in cryptography nor anywhere else. There is always only a certain, traceable level of decentralization and trust. Basically, like any other participant, the owner of the SC / committee should trust the committee as a whole, not each individual part, just like in a blockchain.

The new IOTA SCs also allow only a selected community of interest to execute “trusted” SC transactions among themselves. This required node selection for the committee is currently outside the scope of the IOTA protocol. The SC owner who creates the committee is the one who has to decide which nodes to trust. For an SC created and operated by a company, this could be their own node, or if more trust is needed, a consortium could each provide a node. For example, consortia could operate an SC to have a common view for logistical transactions, or for an SC operated only by different banks would increase the correct flow of transactions tremendously (hardly any conflicts).

Maximum decentralization is also not always necessary, e.g., because an organization may want to set up a committee just to have a fault-tolerant configuration, for example, for a sensor Oracle on its own premises.

The question about the security of the data cannot be answered in general, because the size of the committee influences the validity of the resulting data. Valid data from 100 committee nodes has of course a higher validity than data from only 3 committee nodes participating in the quorum. The number of committee nodes is determined by the owner of the SC, so he could also decide to impose only the minimum of 1 node, which means that he now has a centralized script that processes SC requests. It is therefore up to the owner of the SC to decide what level of security he needs for his use case, for example, for an internal use case that is only executed within his own company, one could forgo very high security in favor of a fast execution of the SC and only allow own internal committee nodes.

The committee nodes will not use mana for SCs. A committee is considered permissioned, so there is no need for Sybil protection like mana.

However, according to SC developer Evaldas, there is a distinct possibility in the future that the SC network will eventually require its own reputation system and even a rate control system. This reputation system could be implemented as a set of SCs, while rate control must be based on the charging behavior of SCs and node operators. Otherwise, it is easy to set up an SC that endlessly sends requests to itself, flooding the network with useless spam transactions. This is due to the fee-less nature of IOTA and it is currently unclear how to prevent this from happening. For this reason Evaldas believes fee-less SC transactions are a bad idea due to spamming attacks. So for now IOTA will hard-code a protection mechanism as described above. The “owner” of the SC should be known and recognized by the node operator. Also both must be accountable and receive the right incentives. (Committee and Rewards)

Wasp: A Node for IOTA Smart Contracts

The IOTA Smart Contract Protocol (ISCP) is a 2-layer protocol built on top of the core protocol and executed by GoShimmer nodes. The development of this protocol is fully decoupled into a separate node called Wasp. Thus, IOTA’s smart contracts are run through the network of Wasp nodes, all of which are connected to the Tangle.

Smart Contract Chain

Smart contracts are transacted through a so-called contract chain, the representation of the contract state. A smart contract updates its state on every request and on each of these state updates a new block is added. All these updates are collected and confirmed in one block. So the Chain also contains all the past states. The Chain can contain many Smart Contracts, all working on the same global state of the Chain. From this perspective, the Contract Chain is essentially a blockchain anchored on the Tangle. IOTA Smart Contracts can be considered “classic” Smart Contracts, but with the added feature that you can have multiple such parallel Chains all using the same native IOTA token and trading between them in a trusted manner on the Tangle. This allows for trusted interoperability between different applications.

Multi-chain environment

With the Alpha release, a multi-chain environment has been integrated, which is secured by the Tangle (base layer 1): Subnets, consisting of Wasp nodes (committees), can run many blockchains in parallel on it without losing sight of the Tangle environment, which secures IOTA’s digital assets. Each of these Chains, which are a functional equivalent of an Ethereum blockchain, is capable of hosting many Smart Contracts.

The IOTA Foundation’s approach to smart contracts is a departure from existing architectures and removes their inefficiencies, such as the inability to run in parallel and at scale, the inability to run “third-party” smart contracts on different virtual machines, and the interference of volatile and sometimes unaffordable fees, to name a few.

With the IOTA Smart Contracts Protocol, developers and enterprises are free to define their own flexible environments that meet their needs (Smart Contract languages / virtual machines) as well as sizes of validation committees that meet their required or desired level of decentralization and security. The IOTA Smart Contract Protocol allows them to run a “permissioned” Smart Contract chain validated by a committee of their own nodes, for example, or define a committee of nodes among consortium partners. ISCP is also built with the intention of running completely “permissionless”, meaning that a committee of validators can be chosen from an open market of validators. All Smart Contract chains – whether open or private – benefit from the inherent security and interoperability that comes from anchoring each Smart Contract state and their outcomes on the IOTA feeless base layer.

IOTA Smart Contracts therefore do not require all nodes in the network to execute all Smart Contracts, but allow for a more flexible, meaningful definition that meets the needs of the Smart Contract owner. This will dramatically reduce cost and power while greatly increasing flexibility and not compromising on individual security requirements and the compatibility and interoperability required by dApps.

Conclusion

IOTA SCs are smart contract programs run by an approved committee on the second layer (off-tangle). The committee of nodes collectively updates the ledger by submitting signed transactions (using threshold signatures) to the Tangle.

IOTA SCs are very flexible and require much fewer resources than blockchain alternatives. They enable use cases that would not have been possible with fees as the only incentive. This is especially true in the IoT space, where micro-contracts and micro-transactions are likely to become the norm. In the first SC release, IOTA will initially use WebAssembly, but in the future this will not remain the only virtual machine (VM), so other programming languages and VMs will be usable.

Legal issues

In general, there are still many open legal questions and corresponding restrictions for all SCs.

Smart contracts are computer programs and are based on simple if-then commands. They are not direct contracts in the civil law sense (§ 158 BGB). This means that the SC is not the contract itself, it only serves to enforce the contract. Offer and acceptance, i.e. the conclusion of the contract itself, take place outside the blockchain / tangle. For example, in a contract for the sale of an item, SC can be used to deposit that the buyer will not receive the item until he has paid the purchase price.

SC are not (yet) suitable for handling more complicated contracts, which often involve a gray area. Today’s contracts are designed to be adaptable and require a valuation in the individual case, which an SC code cannot do. In addition, for special contracts such as a real estate purchase, there is a lack of the clarification, consultation and, if necessary, warning function of a third party (e.g. notary) prescribed by law. These cannot be replaced by automated processes, so this advice must take place outside the blockchain.

Further problems are:

• Data protection, for example, consent to data processing and revocation of it.
• Right to the deletion of private data (right to be forgotten).
• Reversal of contracts after court order.
• Each country has different laws
• There are quite a few more points, for more details see Blockchain and Law in the context of Industry 4.0.

From a legal point of view, SCs are on very unstable ground; there is not yet a standardized and, moreover, international approach to solving these problems. At present, SCs can probably best be compared with so-called “button contracts”, which regulate sales on the Internet. A contract with the inherent rights and obligations is only concluded between the seller and the buyer when the buyer clicks on the purchase button.

Smart Contract – IOTA vs. Ethereum

Except for the buzzword “smart contract,” these two approaches don’t have much in common.

In Ethereum, SCs are part of the core protocol. They are executed on the baselayer (“on-chain”). This means that they are executed and validated by all nodes in the network.

Benefits

• The security of smart contracts is proportional to the size of the network
• Smart contracts can transfer tokens from their account without signature

Disadvantages

• Smart contracts scale poorly because their programs must be executed by all nodes
• SCs incur network transaction fees that are as volatile as the underlying token price. If the network is heavily utilized, the cost increases very sharply and micro-transactions are impossible.
• The average cost of a smart contract transaction is roughly proportional to the underlying token price

In IOTA, SCs are a second layer protocol (“off-chain”) and are executed outside the core protocol. Only a subset of nodes, called a committee, is required to execute them. This means that consensus can be reached outside of the core protocol.

Benefits

• Smart contracts do not burden the rest of the network. Therefore, a popular application (a la “Crypto Kitties”) on IOTA should not affect the performance of another application or activities in the base layer.
• The average cost of a smart contract transaction is low and predictable, use cases over micro-transactions are enabled.
• The required level of decentralization (and thus security) of a smart contract can be customized to each use case.

Disadvantages

• To transfer tokens, SCs must sign transactions to prove they have access to the account address
• The decentralization (and thus security) of smart contracts depends on the size of the committee, the members of the committee, and the entity that establishes the committee

Conclusion

Who would want to build their business in the future on a technology that cannot guarantee predictable transaction costs?

Example: each ETH Oracle has to spend fees to publish its valuations, then miners read these valuations from the blockchain when performing SC, evaluate their consistency and implement the resulting action. The cost and time required to perform this operation with, say, 100 Oracles, is certainly very high. Due to the volatile cost and time required for mining, both can never be accurately quantified because cost and time are interdependent; higher fees mean faster mining.

A similar process performed in IOTA has much lower costs because writing transactions to the tangle is not burdened by fees. Also the time spent by all 100 nodes performing SC is much lower because writing to the tangle can be done in parallel.

The high flexibility of the IOTA SCs also has disadvantages. If you want to lock large amounts of money in a contract for a long period of time, you are currently much safer with the ETH SCs, because you can count on the entire network still being there for a longer period of time to continue processing them.  This is less certain with IOTA because the committees have a limited size and having them still around after a long period of time is less certain.  For these use cases, a SC would / could have different contingency plans on a case by case basis.

In IOTA, committee security is based on different game theory principles compared to a layer 1 ledger like ETH.  In blockchain, it is a global consensus equilibrium maintained by greedy miners; in IOTA, it is the cooperative behavioral principles of tangle consensus. Committee security should be based on several principles, and these principles depend on the use case. Security operates similarly to how communities operate in human society, how trust hierarchies form in society, and the motives of the actors must be known on a case-by-case basis. When we select a board to lead an organization or a jury in court, we do so not by blind random selection, but by examining who the members are: their historical reputations, possible connections and conflicts of interest, what is at stake, and so on.

More Details

IOTA Smart Contracts Protocol Alpha Release – IF

IOTA Smart Contracts Beta Release – IF

Sources:

https://blog.iota.org/an-introduction-to-iota-smart-contracts-16ea6f247936

Original source

https://iota-einsteiger-guide.de/iota-smart-contracts.html

Last Updated on 4. November 2021