Context

Continuation of:

• JsonString in schema vs in json #4900
• refactor!: shift from JsonString to JsonValue #5012

In short, Iroha supports arbitrary JSON payloads for certain actions. In SCALE they are encoded as JSON strings (JsonString type), while in JSON format they are inlined as values.

This is a proposal of an alternative solution: introduce as SCALE-native JsonValue type, encoded not as a string, but directly as an enum:

enum JsonValue {
    Null,
    Bool(bool),
    Number(Number),
    String(String),
    Array(Vec<JsonValue>),
    Object(Map<String, JsonValue>),
}

this is a literal copy of serde_json::Value

Benefits

• Compact encoding of JSON - no need to encode "[{}], characters & whitespace
• Possibly faster deserialisation - needs benchmarking and careful implementation
• Consistency in the schema - JsonValue represents f

Downsides

• Needs custom implementation

Why it is String now

AFAIK the initial choice of string representation for JSON values is an efficiency concern: we don't want to pay for extra (de)serialization while transmitting data to/from WASM smartcontracts.

Basically, string was used as a way to have lazy encoding of data, as requested.

I think it should be possible to achieve lazy encoding in a more direct way with some sort of Lazy<T> container, making it both more explicit and flexible.