Page History

Background

...

• Iroha 2 peer receive messages from it clients primarily serialized in SCALE  codec, but also some endpoint accept JSON messages
• Iroha 2 has some client libraries in development (Rust, Java/Kotlin, JavaScript, Python)
• Scale codec do not need the name of the properties and containers, but JSON do need

Problem

Iroha 2 has a lot of model-objects that peer can receive as input from blockchain clients and can respond with. Currently Iroha 2 in the active development process and set of this model-objects changes very often. These changes must be reflected in the Iroha 2 client's library and it requires a lot of affords to keep client's implementation up to date.

Solution

We can generate a scheme which would introspect details of object-models. These scheme allow to achieve The scheme brings such benefits:

• Code generation of models and deser serialization/deserialization tests
• Type safe checks in clients code (if programming language support such checkstype safety)

Requirements for scheme

Basically we can consider three type of items 

• Scalars (int, bool)
• Built-in containers (Option, Result, Vec, tuples)
• Custom containers (custom struct and enums)

Alternatives

Present at least two alternatives to the solution you suggested

Concerns

Write down all the things that worry you or other stakeholders

Assumptions

Document any assumption that you made

Risks

3 types of items

1. Scalars 

In SCALE integers can be encoded as fixed-width integer and compact integer. Compact integer itself has 4 modes. So generally we have 5 ways to serde integer (1 fixed-width + 4 modes of compact integers) 

{
  "u8": {
    "Int": "FixedWidth"
  },
  "iroha_introspect::Compact<u8>": {
    "Int": "Compact"
  }
}

2. Built-in basic types

•  bool: no tricks here
• String

{
  "alloc::string::String": "String",
  "bool": "Bool"
}

3. Built-in containers 

• Option / Result / Map / Vec : basically we are interested in only inner values of the container

  Code Block
  language js
  { "core::option::Option<iroha_data_model::isi::Instruction>": { "Option": "iroha_data_model::isi::Instruction" }, "core::result::Result<i32, i32>": { "Result": { "ok": "i32", "err": "i32" } }, "alloc::collections::BTreeMap<alloc::string::String, i32>": { "Map": { "key": "alloc::string::String", "value": "i32" } }, "alloc::vec::Vec<i32>": { "Vec": "i32" } }

  
  

4. Custom containers 

• Named structures – structures which have field names
• Unnamed structures – structures with no field names (like zero sized structures in rust, or tuples, or struct WrappedTuple(i32, i32))
• Enums
  

  
  

  Code Block
  language js
  { "iroha_crypto::PublicKey": { "NamedStruct": { "declarations": [ { "name": "digest_function", "ty": "alloc::string::String" }, { "name": "payload", "ty": "alloc::vec::Vec<u8>" } ] } }, "iroha_data_model::account::SignatureCheckCondition": { "UnnamedStruct": { "types": [ "iroha_data_model::expression::EvaluatesTo<bool>" ] } }, "iroha_data_model::events::pipeline::EntityType": { "Enum": { "variants": [ { "name": "Block", "discriminant": 0, "ty": null }, { "name": "Transaction", "discriminant": 1, "ty": null } ] } }, }

  
  

Concerns

Currently we are not support polymorphism via TraitObjects, but it can be implemented if necessaryList all risks in form "description \[probability (from 0 to 9); impact (from 0 to 9)\]"

Additional Information

1. Scale codec description in Substrate docs [https://substrate.dev/docs/en/knowledgebase/advanced/codec]
2. Scale codec Github page [https://github.com/paritytech/parity-scale-codec]