Does an uninitialized ValueState occupy memory in checkpoints in Flink?

I'm using a ValueState with TTL and I want to understand the difference (if any) in the checkpointed state size/memory between two scenarios:

First scenario

I create/obtain the ValueState but never call update(...) on it:

ValueStateDescriptor<MyState> myStateDescriptor =
    new ValueStateDescriptor<>("MyState", MyState.class);
myStateDescriptor.enableTimeToLive(ttl);
this.myValueState = getRuntimeContext().getState(myStateDescriptor);

Second scenario

I create the ValueState and update it once (e.g., myValueState.update(someValue)).

Questions:

• Does Flink allocate or write anything into the checkpoint for scenario (1) — i.e., is an empty/unset ValueState stored for each key, or is nothing persisted until the first update()?
• If something is stored for scenario (1), what does Flink store (e.g., a null placeholder, metadata, or a serialized empty object)?
• How do different state backends (heap/state backend vs RocksDB) behave in this regard? Are there backend-specific differences about whether empty/unset states consume checkpointed space?
• Any practical guidance or best practices to minimize checkpoint size when many keys have ValueState that rarely gets updated?

Environment notes: AWS Managed Apache Flink 1.18 with RocksDB

In the first scenario, nothing is stored in the state backend (for any of the state backends).

In the second scenario, the value stored persists forever in the state backend, unless you've configured it to be removed by the state TTL mechanism.

With RocksDB, you'll want to be sure to use incremental checkpointing. Note that execution.checkpointing.incremental defaults to false.