Abstract

Based on Iurii Vinogradovrequirements:

1. We want ability to have turing complete functions with own protected storage.
2. We want that we can control interfaces to access to this functions. Now looks like it is possible to call internal functions of the complex ISI/
3. There are not enough abilities for ISI to work with storage(parse, verify data...)
5. JS client library.
6. We want an easy understandable framework to send arguments from one ISI to another.
Now there is a proposal about sharing arguments through Assets, but it has many questions. how ISI will know from which asset to get data? How ISI will know how to parse it? How to validate?.... So, dedicated solution might be more clear that try to use assets for everything.
7. We need math in ISI for DEX logic if we want to implement it thorough complex ISI>
8. We want Cycles in ISI.

RequirementTarget ReleaseAlready addressed in
Turing complete functions

Whitepaper

Use cases

Protected Storage

Data related ISI (parse, verify, etc.)

JavaScript client library
Web API
ISI Arguments Passing framework2.0.0Query results as isi argument in complex ISI
Math ISI2.0.0
Cycles ISI

Discussion

Turing Complete Functions

As described in the whitepaper Iroha Special Instructions in combination with "listeners" will provide Turing Completeness for Iroha.

If there are additional details or user stories - they should be provided.

Protected Storage

Iroha has `Kura` as a wrapper on top of `BlockStorage` with an ability to store encrypted data. 

If there are additional details or user stories - they should be provided.

Data Related Iroha Special Instructions

As we understand the requirement, Iroha should be able to make verification of asset's based on some form of schema and following questions should be answered:

  • what  data and schema formats should we support?
  • do we need to have native support of these formats?
  • what "etc." part consist of?

Javascript Client Library

As planned we will port `iroha-client` to the `no-std` environment having an ability to compile it into `WebAssembly` module and use directly from Javascript.

Iroha Special Instruction Arguments Passing Framework

In more details described in a separate PR, TL;DR - we may store results of previous Iroha Special Instructions as Assets and retrieve them from later Iroha Special Instructions via execution of Iroha Queries.

Mathematical Iroha Special Instructions

The full list of operations we need to support Out-of-the-Box should be defined.

Cycles Iroha Special Instructions

We may provide Iroha Special Instructions for finite cycles Our-of-the-Box.

For example `For(n_times, instruction_to_execute)` and it will be just a "sugar" on top of `Sequence` instruction.

  • No labels

21 Comments

  1. Iurii Vinogradov

    > Turing complete function or procedures

    It is not only about Turing completeness. It is also about that function constructed with ISI should be encapsulated. So, there are no access to the state and actions used inside the whole function. Protected storage is the one of solutions here. But usage of ISI and general iroha model inside a function makes it difficult to encapsulate functionality.

    Example of a security hole: We have a domain with users. And domain owner creates a bridge inside its domain. This bridge can create assets to be transferred from another blockchain.  To protect changes to assets we have to set up permissions explicitly, but if it can be designed using protected storage, transferable assets will be secured by default. It is better when we have security by default and can open some data if we want, but now we have the opposite approach.

    Another hole is that while we can create permission for assets created by the bridge, we cannot protect names before creation. So users, who can create accounts and assets in the domain can create assets that might conflict with bridge assets in the future. Having protected storage and incapsulated calls inside the procedure can solve this issue.

    1. Nikita Puzankov

      Thank you, Iurii Vinogradov- as I understand you need to set up strict permissions for some Iroha entities to "protect" them from involuntary access.

      User Story:

      Given domain "Soramitsu"
And "Makoto@Soramitsu" account with permission "Any" constrained by this domain
And "Bridge@Soramitsu" account with permissions "Register(Account), Mint(Asset), Register(AssetDefinition)" constrained by this domain
When "Makoto@Soramitsu" account registers new account with name "name_used_by_bridge"
And "Bridge@Soramitsu" account tries to register new account with name "name_used_by_bridge"
Then "Bridge@Soramitsu" account fails to register new account with already occupied name

      Questions:

      You proposed to not use permissions to work with this case and to introduce "protected storage" - can you answer several questions about this concept:

      • What means "protected" in this case? Who will be able to work with it and how Iroha should check legitimacy of this action?
      • What means "storage" in this case? Will it be stored on the blockchain, if so - where it should be placed according to our domain model?
      • What will be the difference between access to assets and access to protected storage?
      • Only Iroha Special Instructions will have access to this storage or Iroha Queries too?
      • Will be information about storage encrypted or it will be open?


      1. Iurii Vinogradov

        User story where we will have problems:
        A creates a bridge in its own domain. The bridge should create assets for third party blockchain(lets say BTC) tokens in the domain. A also can do it. A can register BTC and when the bridge will try to register BTC it will fail. If We have some internal storage for Bridge were it can create assets, then it will not intercept with anyone other. Just like a smart contract on Ethereum handles token information inside itself, not referencing to any external data.

        > What means protected. Who will be able to work with it. - that why we asking about encapsulated procedures. If we can define a procedure, which encapsulates all logic and storage inside and, maybe, gives an account to it than no one can access the internal state of this procedure except calling it.

        > Only Iroha Special Instructions will have access to this storage or Iroha Queries too -
        In a Smart contract normally we can define actionable methods and get some data methods. So, queries and ISI might use the data being part of something like "one contract". for example, we can define bridge as one contract and add some ISI and queries to it, which will share one storage, protected from access from other places. If it is possible to make using permissions and assets model, that it is good to have a higher-level abstraction being easier to follow.

        > Will be information about storage encrypted or it will be open?
        I think it should follow the general Iroha2 approach.

        > where it should be placed according to our domain model?
        It is up to you. While we will have some storage function or abstraction on top of it. 

        1. Nikita Puzankov

          User story where we will have problems:
          A creates a bridge in its own domain. The bridge should create assets for third party blockchain(lets say BTC) tokens in the domain. A also can do it. A can register BTC and when the bridge will try to register BTC it will fail. If We have some internal storage for Bridge were it can create assets, then it will not intercept with anyone other. Just like a smart contract on Ethereum handles token information inside itself, not referencing to any external data.

          We register Asset Definitions under domain, but Assets placed under Accounts - so Bridge already has "internal storage" - which are assets. 

          that why we asking about encapsulated procedures. If we can define a procedure, which encapsulates all logic and storage inside and, maybe, gives an account to it than no one can access the internal state of this procedure except calling it.

          If we will use `solidity` as an example:

          A contract in the sense of Solidity is a collection of code (itsfunctions) and data (itsstate) that resides at a specific address on the Ethereum blockchain. The lineuintstoredData;declares a state variable calledstoredDataof typeuint(unsignedinteger of256bits). You can think of it as a single slot in a database that you can query and alter by calling functions of the code that manages the database. In this example, the contract defines the functionssetandgetthat can be used to modify or retrieve the value of the variable.

          Than I don't see much difference from this case between solution via "internal storage" and Assets, but work via Assets applies all the guarantees (Permissions, Events, etc.) that work for any other case, so we have a Generic solution, with abstraction over modules specific, an ability to turn them on and off without polluting blockchain and many other advantages.

          In a Smart contract normally we can define actionable methods and get some data methods. So, queries and ISI might use the data being part of something like "one contract". for example, we can define bridge as one contract and add some ISI and queries to it, which will share one storage, protected from access from other places. If it is possible to make using permissions and assets model, that it is good to have a higher-level abstraction being easier to follow.

          It seems that we need a separate whitepaper for this design because it's too far from what Makoto Takemiyawrote there. We have Iroha Special Instructions to manipulate the Blockchain State and Iroha Queries to retrieve information about it. So Iroha Special Instruction is a Smart Contract, a Function, a Procedure and any other synonim.


          TL;DR

          In general - if we will replace "internal storage" words with "assets" we will have our current design.

          1. Iurii Vinogradov

            Some points from you are interesting.

            1. One of the problems is that developers struggling with understanding of such a framework. Not I created this list, so for developers who work with this framework it is not clear how to solve problems and we can try to make it easier to understand. I think one of the main goals of Iroha2 is to make development easier.
            2. You can try to implement things on top of what is mentioned in the whitepaper. Then the original spirit of Makoto Takemiya will be safe. it can be Also implemented as a module for developers to use in other apps development. Then Core Iroha will follow whitepaper.

            1. Nikita Puzankov

              1. We are very limited in resources right now - so we wrote only one guide - feel free to share with devs.
              2. Yes - but on top of means that it should be able to be decomposed to "core" or basic blocks, another case we will have unsupported types inside blockchain.

              1. Iurii Vinogradov

                2. As an iroha2 architect, you can create a proposal for such decomposition. Who except you better understands it. Also, you will understand if it is possible or not.

                1. Nikita Puzankov

                  I'm Senior Rust Dev)

                  We will work on guides next week and I will try to add this case to them.

          2. Iurii Vinogradov

            > We register Asset Definitions under domain, but Assets placed under Accounts - so Bridge already has "internal storage" - which are assets. 

            Yes, this I understand. I'd like to ask help from Vladislav Markushinto define how internal storage can be different from assets and why this request arises.

            But the problem with naming still exists, as you mention in your post. 

            1. Iurii Vinogradov

              As I see, in the request for "protected storage", we want that storage is owned by one or several complex ISI. Can we set up permissions this way? That only dedicated ISIs can interact with this storage, no matter which accounts call this ISI?

              1. Nikita Puzankov

                ISI always executed on behalf of an authority, so we really should list use cases before going to discuss possible options.

                1. Iurii Vinogradov

                  As I mentioned before, some ISI can be executed by any authority. The problem in current complex ISI design that if ISI contains A, B, C ISIs, every of A, B, C, ISI can be called directly, which can cause unexpected state results. For example, we can call C directly without preprocessing of A and B.

                  Now we working on one of the use case explanations. it takes significant time, so? please understand that we cannot prepare much of it.

  2. Iurii Vinogradov

    Also, if you made an RFC, it is also good to mention here that ISI instruction framework requires a lot of development which we can avoid if we will support make one of the following: 
    1. WASM
    or

    2. Iroha-core-interface, to be used in modules. Then we can write code in Rust while the core will be encapsulated behind the interface. this design also gives the ability to solve Turing complete functions requirements easier.

    1. Nikita Puzankov

      1. What is the difference between Rust based Iroha Special Instructions and WASM? We still have some API and restrictions, just in another format. After migration of `iroha-client` to `no-std` we will be able to compile Rust Iroha Special Instructions into WASM.
      2. I don't see any correlation between Iroha domain model and Turing completeness, but Vladislav Markushinalready working on `iroha-client` for `no-std`, while every Iroha module can use API from Iroha application as Bridge did.

      1. Iurii Vinogradov

        1. The first thing is that we don't have to develop a Rust language. With ISI we have to spend a lot of time developing DSL for everything and it still not so good for development. If we want to provide some high-level wrappers, it is easier to develop a library which will be useful in regular Rust, then to develop everything from scratch.
          And For modules, we can develop native code even without WASM.
          Even having no-std compilable in WASM lib we will have to develop each ISI itself. 
        2. I don't see the correlation between my point and your answer. By Iroha core I mean all Iroha functionality that now is hidden behind base ISI and there is no direct access from modules.

        1. Nikita Puzankov

          1. So your suggestion about WASM is to provide an ability to execute WASM inside Iroha Special Instructions? If so - pure WASM runtime is not aware of I\O and what interface do you see for this functionality? I don't completely understand that one.
          2. This is done to encapsulate logic inside Iroha application that is not a part of Iroha API. If Iroha modules will have full access to every aspect of Iroha application we will not be able to change it during development of 2.x.x releases. We may "breal" this rule temporarily and by purposes for complex cases but till now every case we had an ability to cover with public API (Iroha Special Instructions and Iroha Queries).

          1. Iurii Vinogradov

            2. I don't speak about giving access to every aspect of the Iroha application. I speak about the interface. you can encapsulate everything behind this interface and change whatever you want. ISI generally is an interface. But you want that ISI not only an interface but only brick that developers can use. If we safe ISI as an interface to Iroha, but give the ability to write Rust code between ISI calls in "complex ISI", 

            1. Nikita Puzankov

              What this code will do?

              1. Iurii Vinogradov

                Finally, I think that approach to writing rust code between ISI might have very restricted usage because ISI will be executed on blockchain and rust code not. So, they cannot interact. If so then we will not have expected benefits from this.

          2. Iurii Vinogradov

            1. WASM really is one of the possibilities. The benefit of WASM is that it can provide runtime code updates. To think more about the interface for WASM it will be your work as Iroha2 architect. =) We can get some experience from other projects like Polkadot. 

  3. Iurii Vinogradov

    > Mathematical Iroha Special Instructions

    > The full list of operations we need to support Out-of-the-Box should be defined.


    I have analyzed smart contracts which we have to implement. So we at least need addition, subtraction, multiplication, division, sqrt, exponentiation. All math operations should support precise floating point calculations.