Page History

Background

What details are important in making this decision?

Problem

Define the problem we are going to discuss

Solution

Describe the way it should be solved in your opinion

Decisions

List all decisions you and other stakeholders made

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

List all risks in form "description \[probability (from 0 to 9); impact (from 0 to 9)\]"

Additional Information

...

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. The scheme brings such benefits:

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

Basically we can consider 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 necessary

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]