...
Page properties | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
|
Background
Currently we have Iroha Special Instructions and Expressions as a main smart contract language. Later we will call both Instructions and Expressions simply ISI.
...
- As part of the transaction that user submits
- Inside a trigger that is registered and executed on chain based on some events (see Trigger RFC) - not developed yet
Problem
Current state of ISI has several important limitations preventing it from being a fully usable smart contract language:
- Different instruction and expressions might operate on complex values (like structs, enums), but they do not have an ability to destructure/access inner fields/variants of this complex values.
- ISI do not have an std lib to operate Vec(s), String(s), etc.
- In ISI it is not possible to define new structures, objects, closures, functions, modules etc. which is needed to write big programs
- ISI can not be written in text
- ISI do not have loops or recursion (needed for most of the programs)
- They do not manage memory in any way
Given time all this can be solved and ISI can be turned into a fully interpreted language or compiled (JIT/or precompiled) language with a VM and assembly set. But this will take a lot of time as any language and compiler/interpreter development does and would require the team to dive heavily into this mostly new area of expertise. I would estimate about 6 month for 1 full time developer before we have a tangible prototype.
Also ISI as they are have several good important features:
- They are relatively simple to understand and support
- They can be easily permissioned
- They can provide both low level and high level high performance native features
Therefore let's get to suggested solution.
Solution
It is suggested to proceed in the following way:
- Keep ISI runtime:
- For simple use cases
- For high level features provided by Iroha natively
- Add some other established interpreter/VM with existing scripting language such as (WASM, eBPF, Lua, Rhai)
- Let the ISI calls be the interface between this full scripting language and our WSV (scripts will call ISI and queries to change and get information from WSV) - for universality of common interface and easy permission management
Preliminarily it is suggested to use Rust with WASM target with wasmtime runtime.
Decisions
Alternatives
Here the list of possible alternative runtimes and languages is listed with their pros and cons:
Rust - WASM
Language: Rust
Assembly: WASM
Runtime: wasmtime
Prototype: https://github.com/soramitsu/iroha2-wasm-prototype
pros | cons |
---|---|
|
|
*- Nightly Rust means that some of it its features are unstable and may be removed or changed in the later versions of the language.
Rust - eBPF
Language: Rust
Assembly: eBPF
Runtime: solana_rbpf rbpf
pros | cons |
---|---|
|
|
Needs more research
Lua
Language: Lua
Runtime: rlua
pros | cons |
---|---|
|
|
Needs more research
Rhai
Language: Rhai
Runtime: custom
pros | cons |
---|---|
|
|
Needs more research if deemed necessary
Concerns
Other projects developing on Iroha2 might strongly depend on this decision.
Assumptions
Projects developing on Iroha2 need a more robust scripting language
Risks
Additional Information
Useful links:
https://www.w3.org/TR/wasm-core-1/#control-instructions%E2%91%A0
https://learnxinyminutes.com/docs/wasm/
https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/