State trie differences

[danicuki]

I found two differences in our state tries on service related stuff. Files: chainspecs/state_snapshots/genesis-tiny.json
and chainspecs/traces/genesis-tiny.json

Service encoding

The service 0 value. Your side:

key: "0xff00000000000000000000000000000000000000000000000000000000000000",
      value: "0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601ffffffffffffffff640000000000000064000000000000000d0100000000000002000000"

Our side:

key: "0xff00000000000000000000000000000000000000000000000000000000000000",
      value: "0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601ffffffff0000000064000000000000006400000000000000710000000000000002000000"

You have b=18446744073709551615 which is different from json value (4294967295)
also l is not 269 as stated (incorrect value of bytes). Formula 9.8 says value is (81 + z) and z here is 32, so the correct value should be 81 + 32 = 113

account_lookup encoding

check if you are using the correct formula D.2:
∀(s↦ a) ∈ δ,((h,l) ↦ t) ∈ al ∶ C(s,E4(l)⌢ H(h)2...30)↦ E(↕[E4(x) ∣ x<−t])

our key: "0x00000000003400c23d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c"
yor key: "0x00200000000000003d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c"

[sourabhniyogi]

Service encoding

• We picked needlessly high balance (2^64-1) and will reduce it to 10B (bigger than 2^32 but easy to remember, 1 with 10 zeros) and change %d to %ld, thank you!
• You are right we have the wrong value, but we believe it should be

StorageSize = 81 + codeLen (188) + 32 = 301

from our bootstrap preimage here which is 188 bytes:

0x0000000000000000002000ad0000000000809628120000002811000000281d00000028830033073200140a0400fffe00000000330b24330732009511e87b10107b15087b1614070000fffe00000000827820330964330a640a096475140600e0fdfe0000000049067b6704140904e0fdfe00000000330804330a04140700e0fdfe000000000a0333087f9698003309646457646a0a0b3307821010821508821695111832003307320021845400a9240590a4022801240114a42a2915

account_lookup

From our redo of the account_lookup encoding:

• blob_len=188 => E4(l)=bc000000
• H(h)2...30 => 3d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c10639812
• concatenating the above yields 0xbc0000003d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c10639812

(Earlier we had 32 with 0x20 instead of 0xbc, which was wrong... thank you for your report)

So, if you agree, we will correct to:

 {
-    "state_root": "0x364971f27b609efc73690e94bec0efb24ac2083d4bb921536af8be21e66d98a9",
+    "state_root": "0xc5939d8905bd451e10a29f3826ce3388caa43189636fb24053a1b4851f6adc44",
     "keyvals": [
         [
-            "0x00200000000000003d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c",
+            "0x00bc0000000000003d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c",
             "0x0100000000",
             "account_lookup",
-            "s=0|h=0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601 l=32 t=[0]|tlen=1"
+            "s=0|h=0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601 l=188 t=[0]|tlen=1"
         ],
         [
             "0x00fe00ff00ff00ffc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f",
@@ -105,9 +105,9 @@
         ],
         [
             "0xff00000000000000000000000000000000000000000000000000000000000000",
-            "0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601ffffffffffffffff640000000000000064000000000000000d0100000000000002000000",
+            "0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b12760100e40b5402000000640000000000000064000000000000002d0100000000000002000000",
             "service_account",
-            "s=0|c=0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601 b=18446744073709551615 g=100 m=100 l=269 i=2|clen=32"
+            "s=0|c=0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601 b=10000000000 g=100 m=100 l=301 i=2|clen=32"
         ]
     ]
 }

Note the b=10000000000 l=301 and l=188 in there instead of b=18446744073709551615 l=269 and l=32.

Please confirm you agree with the above fixes and we will republish today! Thank you!

[sourabhniyogi]

See 0.6.2.1 for genesis fixes. @danicuki can you confirm this matches your expectations?

[danicuki]

StorageSize = 81 + codeLen (188) + 32 = 301

I am talking about a_o: Storage size is referring to a_s (not a_p), in this case it is null - so 81 + 32 seems correct

blob_len=188 => E4(l)=bc000000

l is not blob_len, is the value in l in the lookup_meta field. You put 32 - maybe the 32 is wrongly put and should be 188, but the l on E4(l) comes from preimage_storage_l field (a_l)

[danicuki]

Formulas 9.6 and 12.33 (GP 0.6.2) should guarantee that a_l and a_p are correctly matched.

[danicuki]

I found a bug on own side also, I was take the wrong slice of hash. Should be:
200000003d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c10639812

[sourabhniyogi]

The lookup_meta has 188 here for the 188 byte preimage here

The storage size formula has TWO components:

The first component accounts for the a_p / a_l part (81+z) where z for the single preimage is 188.
The second compon accounts for the a_s part but since there are no storage elements is 0.

So I think its actually 81+188=269, which is what we had before!

[danicuki]

Where do you see a_p in this formula? I see only a_l.

The data comes from a_l, which is 32 in your json. I suppose the a_l value is wrong and should be correctly changed to 188. But the a_o is calculated only based on a_l, not a_p

a_p => a_l 
a_s + a_l => a_o

[sourabhniyogi]

Conclusion:

• 81+188=269 is the storage_size and not 301 here
• still see balances serialization overflow here
• 0x00bc0000000000003d20cfa828824e6ef2b78893d800de0cfd3a02465865fa4c is the key since 0xbc matches 188

[danicuki]

improved, but still differences in two fields:

• balance (a_b: json value: 4294967295, encoded: ffffffff00000000. you have 00e40b5402000000 don't know why
• a_o: 269 => 0d01000000000000 and I don't know why yours is 2d01000000000000 (still 301)

My full service value:
0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601ffffffff00000000640000000000000064000000000000000d0100000000000002000000
yours:
0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b12760100e40b5402000000640000000000000064000000000000002d0100000000000002000000

[sourabhniyogi]

I adjusted balances to a nice number like 10000000000 -- which is 1 DOT (decimals 10)
"0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b12760100e40b5402000000640000000000000064000000000000000d0100000000000002000000",
"s=0|c=0x0dc0cb2d76b3296edddf4256bb4b388c4dfa3a9e10c3a6412f00e0150b127601 b=10000000000 g=100 m=100 l=269 i=2|clen=32"

I committed the 269 in this commit -- thank you for the taking the time to haggle this out!

[sourabhniyogi]

Addressed in 0.6.2.2