Missing service representation in state.json

[danicuki]

Services in state.json are null:

    "service_account": null

They should be added according to w3f format (example):

{
        "accounts": [
            {
                "id": 1729,
                "data": {
                    "service": {
                        "code_hash": "0x29fe14bc79ab8942dc22494680fddbd51051dfcedcf10b9d15f20cecf58316d5",
                        "balance": 12114,
                        "min_item_gas": 10,
                        "min_memo_gas": 10,
                        "bytes": 11894,
                        "items": 2
                    },
                    "preimages": [
                        {
                            "hash": "0x29fe14bc79ab8942dc22494680fddbd51051dfcedcf10b9d15f20cecf58316d5",
                            "blob": "0x1234"
                        }
                    ]
                   "lookup_meta": [
                        {
                            "key": {
                                "hash": "0x6989ea1c2d5d81e7ef17b32e23d56e5ec90d9d48e19c634e14dd630dd5dd2ce1",
                                "length": 18
                            },
                            "value": []
                        },
                        {
                            "key": {
                                "hash": "0x7a71eb4834e36bcea488abf607e408569bd27cab1ca9c6075f4a4cf64d0a6048",
                                "length": 49
                            },
                            "value": [
                                37,
                                40
                            ]
                        }
                    ]
                }
            }
        ]
}

[sourabhniyogi]

Very reasonable (see also #38) , have we spotted the key value representation in a w3f test vector to get 4/4 rather than just 3/4?

[danicuki]

sorry, I didn't get, what is 3/4 - 4/4?

[sourabhniyogi]

sorry, I didn't get, what is 3/4 - 4/4?

https://graypaper.fluffylabs.dev/#/5f542d7/384e03384e03 has FOUR (4) elements for services. Your format covers THREE (3) of the FOUR (4) of them:
(1) service
(2) preimages
(3) lookup_meta

The fourth one is missing:
(4) _________
which would be the key-value representation in GP of:

Gav found this dumping of service data to present scalability issues for RPC (e.g. jam_getState), which we generally agree with -- so perhaps its best to just omit service data? BUT to compute state roots and reason about state root differences between JAM implementers, obviously the COMPLETE raw data of encoded state for C1-C15 AND the service data is necessary, which is served already by state_transitions. Your request is that we can cover (1)-(3) in state_snapshots, but without (4), its not complete and does not serve this goal. We just want to wait until we get (4) as well -- we can make a good guess but we can wait since the state_transitions is strictly more complete -- it checks teams encoding/decoding powers as well as state_root computation powers AND has the metadata of (1)-(4) in the 3rd and 4th element, in a simple way that doesn't involve JSON attribute/format details exactly of this sort.

[sourabhniyogi]

Brought up this topic here

[danicuki]

I got it. This forth element we call "storage" in our side. There is no test vectors using it, so your can define any structure you like, and we will follow. If any future test vector uses this field, we try match.

Something like:

"storage": {
"key1": "value1",
"key2": "value2"
}

is perfect for us

[sourabhniyogi]

Based on davxy comment here the storage element we'll implement as:

"storage": {
 "0x81e47a19e6b29b0a65b9591762ce5143ed30d0261e5d24a3201752506b20f15c": "0x1cb5ef77",
...
}

[sourabhniyogi]

We have general agreement!