Incorrect items/bytes for service

[jaymansfield]

In assurances/1_004 the number of items/bytes in both pre-state and post-state services are incorrect.

They should reflect the storage used by the service as mentioned in GP section 9.3 and need to be updated each time storage is changed.

[sourabhniyogi]

Pre-state

For service 0 the prestate of 1_004

            [
                "0xff00000000000000000000000000000000000000000000000000000000000000",
                "0xdf918e2848564f7ff15f0a6686cf42cad7f5c47aad1b461a26e7da904c07a54e00e40b540200000064000000000000006400000000000000430100000000000002000000",
                "service_account",
                "s=0|c=0xdf918e2848564f7ff15f0a6686cf42cad7f5c47aad1b461a26e7da904c07a54e b=10000000000 g=100 m=100 l=323 i=2|clen=32"
            ]

is the same as genesis so I think we have to agree on:

• l=323
• i=2

Derivation is from GP 9.3

• $|a_l|$ = 1
• $|a_s|$ = 0
• so $a_i = 2 * 1 + 0 =2$ which we put into i=2
• the preimage length is 242 here
• so $a_o$ = ( 81 + 242 ) + ( 0 ) = 323 which we put into l=323 (shall we rename this o)

Which part do you derive a different answer?

Post-state

[After we get on the same page on the above ...]

You are correct -- our bootstrap has a write operation here that creates a new storage item here. If you report back what you think the new values should be for bootstrap service 0 like

• $|a_l|$ = 1
• $|a_s|$ = 1
• so $a_i = 2 * 1 + 1 =3$ which we put into i=3 (REQUIRES A FIX)
• so $a_o$ = ( 81 + 242 ) + ( 32 + 4 ) = 359 which we put into l=359 (REQUIRES A FIX)

and then similarly for the new service 3901900966

            [
                "0xffa60048009200e8000000000000000000000000000000000000000000000000",
                "0x1f2acc37e37dc4f99c3fc50202c92d0c148c6e73ef789a37189221e2b24c46fd3398980000000000640000000000000064000000000000003c0100000000000002000000",
                "service_account",
                "s=3901900966|c=0x1f2acc37e37dc4f99c3fc50202c92d0c148c6e73ef789a37189221e2b24c46fd b=10000435 g=100 m=100 l=316 i=2|clen=32"
            ]

like

• $|a_l|$ = 1
• $|a_s|$ = 0
• so $a_i = 2 * 1 + 0 =2$ which we put into i=2
• so $a_o = 81 + 235 = 316$ which we put into l=316

that would be most helpful so we can achieve consensus on the correct answer most quickly!

[jaymansfield]

My mistake on the pre-state. The values are correct.

For service 0 I am getting bytes=359, items=3.

As for the new service, until we get the same accumulation results it's hard to say what the correct output should be for it

[sourabhniyogi]

Great we agree on bytes=359, items=3. Have to do some macro data refinement...

[sourabhniyogi]

Alright, to increase the speed of our reasoning on what we think is the correct service storage keys + corresponding accounting, we dumped some basic logs like this:

SetServiceStorage(s=0, k=00000000, v=63803b10) C(s, concat(0xFFFFFFFF,k[0:28])=0xffffffff00000000000000000000000000000000000000000000000000000000)=00ff00ff00ff00ff000000000000000000000000000000000000000000000000
 a_i [s=0] changed from 2 to 3
 a_o [s=0] changed from 909 to 945
 a_i [s=272334947] changed from 0 to 2
 a_o [s=272334947] changed from 0 to 1230

• At genesis, the bootstrap service 0 has a_i=2 and a_o=909 because the size of the bootstrap preimage is 828 bytes, and by 9.3 we have 81+828=909.
• In assurances 1_004.json
  • for service 0, we have a new storage key with a value of 4 bytes, so
    • a_i [s=0] changed from 2 to 3 (due to the new storage key, which our bootstrap service writes the new service id)
    • a_o [s=0] changed from 909 to 945 (increase of 32 (from the key)+4(from the value)=36 bytes)
  • for NEW service id 272334947 created (see ServiceID generation incorrect, Incorrect Wrangling of Work Results, Demonstrate Option<Hash> in assurances/orderedaccumulation data #74), which initially has a_i=0, a_o=0 immediately after the new but then
    • a_i [s=0] changed from 0 to 2 (due to the codehash preimage + lookup)
    • a_o [s=0] changed from 0 to 1230 (from the codehash having a 1149 byte supplied to new, where 1149+81=1230)