State value proofs are not committed in local test node

[aeryz]

Discord user ID

No response

Describe your question in detail.

Hey! I'm working on a custom API endpoint to fetch the inclusion proof of a StateValue at an arbitrary ledger version. I'm calling get_state_value_with_proof_by_version to read the proof similar to how it's done here, but I'm keep getting this error:

{"message":"Missing state root node at version <VERSION>, probably pruned.","error_code":"internal_error","vm_error_code":null}

The only ledger_version's that I'm capable of getting the proof for is the epoch ending ones. Otherwise, the NodeKey for the arbitrary version that I query for does not exist in the merkle tree and an error is raised here. Is this a limitation of the local test node or is this how Aptos works in general where the merkle tree is only being edited during the epoch ends?

What error, if any, are you getting?

No response

What have you tried or looked at? Or how can we reproduce the error?

No response

Which operating system are you using?

Linux (Ubuntu, Fedora, Windows WSL, etc.)

Which SDK or tool are you using? (if any)

N/A

Describe your environment or tooling in detail

No response

[msmouse]

Hey @aeryz,

The Merkle Trees are currently persisted only at selective block endings and all epoch endings

https://github.com/aptos-labs/aptos-core/blob/0987af8f7f3b27758969384e03ef7aaf77ed6ca4/storage/aptosdb/src/state_store/buffered_state.rs#L100-L107

and are subject to aggressive pruning policy

https://github.com/aptos-labs/aptos-core/blob/0987af8f7f3b27758969384e03ef7aaf77ed6ca4/config/src/config/storage_config.rs#L306-L312

https://github.com/aptos-labs/aptos-core/blob/0987af8f7f3b27758969384e03ef7aaf77ed6ca4/config/src/config/storage_config.rs#L323-L330

Internally you can get the version of the latest servable state tree via

https://github.com/aptos-labs/aptos-core/blob/0987af8f7f3b27758969384e03ef7aaf77ed6ca4/storage/storage-interface/src/lib.rs#L385-L385

or find a state tree before a certain version via

https://github.com/aptos-labs/aptos-core/blob/0987af8f7f3b27758969384e03ef7aaf77ed6ca4/storage/storage-interface/src/lib.rs#L294-L294

but these internal APIs are subject to change without notification.

Since we didn't open the merkle proof for querying from outside the node through the RestAPI, may I ask what's your use case?

Thanks,

[aeryz]

Hey! Thanks for the answer! Our use case is trust-minimized bridging. We are implementing an extended version of IBC at Union on various of chains including Aptos. How IBC works is, the protocol commits a packet on the source chain and then prove the inclusion of that packet at the destination chain.

My initial plan was to implement a REST API for the merkle inclusion proof at an arbitrary height and run our full node but since the proof does not exist at all times, I'm thinking maybe we can do this:

1. Modify the buffered state commitment interval to be smaller.
2. The REST API returns the proof at the latest servable state including the proof height when the latest servable state version > requested version. Otherwise, it returns an error.

So a few questions here:

1. I saw that the TARGET_SNAPSHOT_INTERVAL_IN_VERSION is set to 100_000 and saw that there is rougly 30-35 mins difference bteween the tx's that are 100_000 versions apart. So how much lower we can set the interval without the node getting congested?
2. I'm also curious if you see any better way to implement my use case?

[aeryz]

Two more followup questions :)

1. When I get the latest transactions using https://api.mainnet.aptoslabs.com/v1/transactions, I see that there are bunch of transactions with different state_checkpoint_hash and it seems like the state_checkpoint_hash is very frequently being filled (non-null). If the state is not being merklized so often, how is this being calculated?
2. I'm also seeing the transaction type called state_checkpoint_transaction. Does this transaction type also trigger the state merklization?

[aeryz]

Hey @msmouse , kindly bumping this