Historical ledger correctness

[apenzk]

While the current state of the ledger may be identical, when transferred, semantically the data values may have a different meaning.

A more complete correctness check (that considers the semantics) is to replay from genesis and identify at what block height (and why) the value entries differ between the state created by 1) movement and 2) aptos.

Criteria:

• get ExecutableBlock at each block height and execute with 1) . Record the state root root(1,h)
• get ExecutableBlock at each block height and execute with 2) . Record the state root root(2,h)
• Compare the roots.

If they differ at some height lowestErrorHeight, we have identified a height, at which the VMs would produce differing results.

Optimistically, this passes all the way to the current height.

[franck44]

So to be able to implement this correctly we need to:

• define criteria about the states "equivalence" (is it the same hash if we can reproduce it, or the same state without the hash)?
• be able to replay from the beginning (genesis). If I understand from previous discussions, updates like gas schedule are transactions on-chain, so they should be no issue taking them into account. Are there any other modifications to the MoveVM that were deployed since genesis and are not deployed through transactions?

[l-monninger]

define criteria about the states "equivalence" (is it the same hash if we can reproduce it, or the same state without the hash)?

Yes, if you guys can give me this, that would be helpful, so that these criteria are not just my determining.

be able to replay from the beginning (genesis). If I understand from previous discussions, updates like gas schedule are transactions on-chain, so they should be no issue taking them into account. Are there any other modifications to the MoveVM that were deployed since genesis and are not deployed through transactions?

We'll start with the optimistic assumption.

[apenzk]

@franck44 @l-monninger I was thinking we can simplify the correctness check:

As described above the resulting state updates from a block for Movement (Mvmt.vLatest) and (Maptos = Maptos.vLatest) should be the same when replaying with movement and aptos. For this we can replay from genesis with the latest movement version (vLatest) only.

Reasoning:

• The current state S is derived through application of a sequence of node softwares Mvmt.v1, Mvmt.v2, ...., Mvmt.vLatest
• The current state S is valid with respect to Mvmt.vLatest.
• When replaying with the latest movement version we may arrive at a different state S' compared to S due to, for example, gas related changes in the network. I.e., state(Mvmt.v1 --> Mvmt.v2 --> ... --> Mvmt.vLatest ).
• If we apply all transactions in order AND the state(Mvmt.vLatest) = state(Maptos) after each block, then by some transitive argument i would say that the current state is correct with respect to Maptos with great probability.

[l-monninger]

@apenzk

Okay, but you still want me to check for the actual ledger_info API elements to be read and constructed correctly, right?

[apenzk]

@l-monninger is it practical to identify the entries by the changeset of a block and compare this?

I don't think that block_id, and other difficult to derive values are necessarily required or reliable. But this means also we may not be able to be able to compare hashes of states. Between maptos and mvmt

[l-monninger]

@l-monninger is it practical to identify the entries by the changeset of a block and compare this?

I don't think that block_id, and other difficult to derive values are necessarily required or reliable. But this means also we may not be able to be able to compare hashes of states. Between maptos and mvmt

I have essentially already compared all change sets in #46 .

[0xmovses]

What's the state of this, are we good to close it?

[apenzk]

@l-monninger states this is resolved iiuc

[l-monninger]

I wouldn't call it done. But, we are already comparing all change sets. I was going to seek clarity yesterday on whether we do still want to validate metadata. But, I wasn't able to figure out what is going on with the replay.