# Iroha smart contracts

In this document, I will try to think about design of smart contracts and ways how to improve it.

## Current design

Currently smart contracts in iroha are implemented in 2 parts:
- Iroha Instructions Set ([ISI])
- [Triggers] (they are unimplemented yet)

### Isi
Isi are made with a some programing language designs and have notions like
- Expressions
- Instructions

Expressions are a lot like programming language expressions, while instructions are statements (more in functional programming way)

### Triggers

Triggers are supposed to be a filler for hole of turing completness. They have some similarities with off chain workers in terms of this properties:
- They are not part of blockchain execution itself
- They happen as some event on chain happends

But have key differences that offchain workers:
- are not part of blockchain at all (triggers execute on each node, while offchain worker are only on one node)
- have more freedom in terms of going to the network, doing computational heavy things

## Current problems for public nets

### ISI

As for isi, one of key problems is its existence in the era of the blockchains which uses currently existing infrastructure around existing virtual machines, like:
- EVM
- WASM
- EBPF

Just not using them or some other VM would require us solving some non-blockchain infrastructural problems like:
- Language, compiler/interpreter/jit compiler design
- Speed of smartcontracts

Speed of smartcontracts can be improved by using some jit compiler with some VM.

#### Data abstractions

Current implementation is unaware of describing structured data, even though it is the most common thing from EVM.

#### Recursion

As for general purpose public net scenario it will certanly need a way to make loops or do functions with calls

### Triggers

As for triggers there are 2 problems

#### Halting problem

Triggers even though in their design are just tuple of predicate and instruction, still makes it difficult to get a dependency graph and make some predictable execution. It just makes impossible or hard some of public net scenarios described below.

### Examples

This design makes hard to implement some of most simple things related to math like:
- square root calculation
- sorting

## Problems for CBDC case

Problem with CBDC case is that even though we can have instruction per each CB function, we still need to take care of several things:
- Serialization of structures
- Decoupling of structures

I would focus on second one as it is more critical. It requires just writing more boilerplate code, in comparison to ordinary native function calls in rust for VM cases. It will be the same in terms of computation.

[isi]: https://wiki.hyperledger.org/display/iroha/Set+of+OOB+ISIs
[triggers]: https://wiki.hyperledger.org/display/iroha/Triggers

## Conclusion

To summarize, there are plenty of issues with Iroha smart contracts, and i think it requires some more thoughts and redesign. I would propose to spend some time on researching of different virtual machines or using EBPF (Solana choice) or WASM (Substrate choice). This design will have whole infrastructure out of box nd will be easy to design around speed (for example it would be easy to build in some requirements for speeding up of building dependency graph to improve speed).