State root mismatch before and after commit when using QMDB

[NikhilSharmaWe]

Description

When using the QMDB crate inside a monorepo, I am observing a state root mismatch between:

• the state root obtained after calling merkleize (before commit), and
• the state root obtained after calling commit.

This happens even when no additional state changes are made between these two steps.

Expected Behavior

• merkleize computes the state root based on the in-memory state after execution.
• commit should only persist the already-computed state to the database.

Given this, the state root should remain the same before and after commit, since no new state transitions are introduced during persistence.

Actual Behavior

• Calling commit introduces a new commit operation that changes the resulting state root.
• As a result, the state root after merkleize does not match the state root after commit.

Question / Clarification Needed

Is this the intended design for QMDB?

Specifically:

• Should commit affect the state root?
• Or should the state root be fully determined by execution + merkleize, with commit only persisting data to storage?

This distinction is important for verification logic, where the state root is expected to remain stable between execution and persistence.

[roberto-bayardo]

Thanks for the report. commit in our QMDB implementations is a state-changing operation, as it:

• triggers "floor raising" (aka compaction) which repositions older operations to eliminate gaps and
• writes an explicit "commit" operation to the log which contains the new inactivity_floor location.

Since the state root in QMDB is the state of the log (and not strictly the state of the active key/values) both these steps will affect it.

I will clarify this in the documentation before closing this issue.