State Diff: Truncated Storage Value: 0x1ce1460cf29b2439b458263b121c7a82651b77dab69f861a9850eb2145eb3ab

[JulianGCalderon]

Tx 0x1ce1460cf29b2439b458263b121c7a82651b77dab69f861a9850eb2145eb3ab differs when comparing with Cairo VM.

Traces:

• Native
• VM

This was recorded with trace dump feature in starknet-replay: lambdaclass/starknet-replay#58

Other transactions with similar bug:

• 0x7192cb38bf8414ce0a88fe678a156e742b99371e38174d947d9fedf4f98ff3
• 0x759fd709b0986e42f91319b143a8b3e7ffc695c828eae2eed4b24dfb9a7de63
• 0x1eb296226969571bc17d335f9db894bd817edd12064d2e1c86d5f5d414bf6b6
• 0x4d492ccfb9b924b79289046f7607ce0c949497c5f431af48e81b8705f53e6af
• 0x2b043bb30da7b8d4ac83ec31f48fb17ff14d8c51584ba91031ba0afede55597
• 0x3bcf976c04d9d147537138891b59c12a43c257487343f6106609437e81257e0

[JulianGCalderon]

All transaction diffs look like this: different numbers, same pattern.

[pefontana]

Just to add info here. This states dumpls where generated running the block range 742000 to 742644

cargo run --release --features state_dump block-range 742000 742644 mainnet

cargo run --release --features state_dump,onlt_cairo_vm block-range 742000 742644 mainnet

[FrancoGiachetta]

Update 03/10

It seems like the source of issue might be during the call of the storage_write syscall, the value argument (which holds the value to write) is already the incorrect one during the execution of the wrapper of this syscall (not to be confued with the syscall itself). It could be because this call is done through mlir and so there could be some bytes misinterpretation, producing the value's truncation.