assurances data: recent blocks "Beta" computation from prior state transition Beefy Commitment / C / r

[jaymansfield]

Our delta (services) objects finally fully match after accumulation!

I now have a single difference in post-state beta after running assurances/5.

Yours:

BlockInfo{hash='0xbea2a0bd18d90f052853f81a9747431b0b44f65f5f16eb2ce116dbef5ba2fea5', mmr=Mmr{peaks=[null, 0xad3228b676f7d3cd4284a5443f17f1962b36e491b30a40b2405849e597ba5fb5, 0xb4c11951957c6f8f642c4af61cd6b24640fec6dc7fc607ee8206a99e92410d30]}, stateRoot='0x0000000000000000000000000000000000000000000000000000000000000000', reported=[]}]

Mine:

BlockInfo{hash='0xbea2a0bd18d90f052853f81a9747431b0b44f65f5f16eb2ce116dbef5ba2fea5', mmr=Mmr{peaks=[null, 0x755624dca12d3dead2d2e064a4e060ba5cf6d5d9280acdc4c552cccdbde3c9cf, 0xb4c11951957c6f8f642c4af61cd6b24640fec6dc7fc607ee8206a99e92410d30]}, stateRoot='0x0000000000000000000000000000000000000000000000000000000000000000', reported=[]}]

My service hash pairs

service 0 - hash: 0x549611b000000000000000000000000000000000000000000000000000000000

After encoding (E4(s)⌢ E(h)): 0x00000000549611b000000000000000000000000000000000000000000000000000000000

Accumulate root: - MB([0x00000000549611b000000000000000000000000000000000000000000000000000000000]) = 0x253e7b79a6f60c38d85fa99ae8f0fbf3072e5bb869d39e4319ef609b0395e14b

[sourabhniyogi]

1. We could add a yield call (this is new, and we realized from ServiceID generation incorrect, Incorrect Wrangling of Work Results, Demonstrate Option<Hash> in assurances/orderedaccumulation data #74 that we missed this and are adding it to the "fib" service) at the end of bootstrap service around here (that "output" is out of date) with the new service id so that there is a useful Some value to Option<Hash> rather than a None but we did not do that yet.

In particular, I believe there is no actual hashing of anything for this 32-byte output so we could put a 4 byte service id and the rest can be all 28 0s -- is this a good idea?

2. So as of right now, the result of service 0 is a "null" $y$ B.6, do you agree?

3. If you agree that h a null, then what is its encoding E(h) and thus (E4(s)⌢ E(h))?

Based on C.9 is it 0x00 and thus 0x00000000 or something else still?

We can provide an exact derivation of the the mmr with agreement on the above new concepts.

4. In addition, we are thinking that instead of having $r$ (which is opaque as to its service-Option yield results), we publish ${\bf C}$, a map of serviceids to these <Option>Hash yield results, which in this case would be

C: { 0: null }

but if we added a yield to the bootstrap service could be

C: { 0: "0x1234567800000000000000000000000000000000000000000000000000000000" }

where 0x12345678 would be E_4(s) for s the new service id. Should we make this change so that instead of "opaque hard to debug" $r$ we have "transparent easy to debug" ${\bf C}$?

[jaymansfield]

2. So as of right now, the result of service 0 is a "null"
y
B.6, do you agree?

I'm not sure if I'm following correctly, but I would think if it was intended to be null then register 7 and 8 wouldn't point to a valid memory location.

At the end of the program i have reg7=4278058952 and reg8=32 and thats the memory location where I'm pulling this value from: 0x549611b000000000000000000000000000000000000000000000000000000000

[sourabhniyogi]

We put 0x549611b0 as the "output" ${\bf o}$ (the new service 2953942612), but does reg8=32 actually trigger condition o \in H ?

(If not, what would?)

We'll generate a derivation with the answer being "yes, it does trigger the condition" since we have no answer to the above. The yield function provides a clearer answer.

Same question posed in GP Chat

[jaymansfield]

We put 0x549611b0 as the "output"
o
(the new service 2953942612), but does reg8=32 actually trigger condition o \in H ?

I'm not aware of a requirement that an output is 32 characters.

The condition here is basically as long as the program halts and the memory specified is in a readable location.

[sourabhniyogi]

Ok we found an issue on our side (a $leaf that is not supposed to be there in WBT) and regenerated -- so we now agree on the 0x253e7b79a6f60c38d85fa99ae8f0fbf3072e5bb869d39e4319ef609b0395e14b where our logging of { C => r } is here

This now correctly computed root is used to compute the Beta/RecentBlocks of the NEXT block here

That is, the $r$ from the accumulation of 1_005 only is used as an INPUT to 1_006 and appears in the C3 1_006 post-state. Can you check if you agree with this and explain in detail if you don't?

This $r$, ${\bf C}$ seeping in from the PREVIOUS block is non-normal (but is described as well as it can be). We probably won't see the end of it ... so we'll keep improving our logging to make it easy for us and everyone else to talk about these even more loopy than usual cases.

I'm not sure if there's a requirement that an output is even be 32 characters.

Hmm, hmm, a clarification will be useful !

[jaymansfield]

This now correctly computed root is used to compute the Beta/RecentBlocks of the NEXT block here

That is, the r from the accumulation of 1_005 only is used as an INPUT to 1_006 and appears in the C3 1_006 post-state. Can you check if you agree with this and explain in detail if you don't?

This r , C seeping in from the PREVIOUS block is non-normal (but is described as well as it can be). We probably won't see the end of it ... so we'll keep improving our logging to make it easy for us and everyone else to talk about these even more loopy than usual cases.

I use it for the same block. My STF just has two steps for beta.

Where did you see that it's for the next block?

[sourabhniyogi]

Where did you see that it's for the next block?

Eq 4.7 and here. There is no other sensible interpretation of it based on where 4.7 is located.

[sourabhniyogi]

The "present block" reference here

we take to be describing Eq 4.17

We think the use of C in both Eq 4.7 AND Eq 4.17 is confusing, and something should be done about it notationally.

[dakk]

I use it for the same block. My STF just has two

I'm aligned with this interpretation; I don't think Gavin means two different things with the same letter. My internal process is:

1. I calculate beta dagger
2. I accumulate and calculate C
3. I calculate beta'

[sourabhniyogi]

Since the C of 4.7 is in fact the SAME as the C of 4.17 (this is definitely not reader-friendly) and confirmed to not need some different notation, we'll consider this case closed, will republish a corrected dataset. This means we also don't need a "accumulationRoot" feature in StateTransition.

[sourabhniyogi]

solved in 0.6.2.7