cairo_native
cairo_native copied to clipboard
[BUG][Block 626173]Bug Native execution error: SM_SUB_UF
Check this error we are getting in the tx 0x7286e45814889d2dc7dbbf26c5b96b4950280c3fd3f2e38a44d8239a00db336 You can reproduce it with the replate crate. The tx should execute correctly.
ERROR replay: rpc and execution status diverged, transaction_hash: "0x7286e45814889d2dc7dbbf26c5b96b4950280c3fd3f2e38a44d8239a00db336", chain: "mainnet", execution_status: "REVERTED", rpc_execution_status: "SUCCEEDED", execution_error_message: "Transaction execution has failed:\n0: Error in the called contract (contract address: 0x02fd0a2c6c751b9b4cec4f61ee8cdc2f07955a8ef4b79fd5b6986a8ee8b1e6f4, class hash: 0x01a736d6ed154502257f02b1ccdf4d9d1089f80811cd6acad48e6b6a9d1f2003, selector: 0x015d40a3d6ca2ac30f4031e42be28da9b056fef9bb7357ac5e85627ee876e5ad):\nNative execution error: argent/multicall-failed\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Native execution error: Native execution error: SM_SUB_UF\n"`
Error Status
The contract triggered by the tx is Market, which belongs to zkLend. Basically it is in charge of user data maintenance and provides almost all the entrypoints for user operations.
The tx executes the withdraw entrypoint, which seems to be the one in charge of take some amount from a user's balance. There's a method called sub, which lives inside the libraries/safe_math module of the contract's repo:
fn sub(a: felt252, b: felt252) -> felt252 {
assert(Into::<_, u256>::into(b) <= Into::<_, u256>::into(a), errors::SUBTRACTION_UNDERFLOW);
a - b
}
It is executed during this process with which seems to be wrong values that make the assert become true.
Since the contract is constantly interacting with the storage, there's no way we can replicate the error from cairo_native. This because the same error is happens earlier due to a misread of the storage. Thus it is not possible to get the exact same error that the replay is throwing by just executing the contract with cairo native.
Update 29/07 There's another tx reverts with the same error. I've run the same tx both with cairo-native and cairo-vm, and the result is the same error.
One posible reason of this could be the timestamp the contract sometimes uses in calculations (in subtractions for example), which might be different from the original tx. However it is still difficult to say if it really is the source of the issue since it being is read from the storage. Sometimes it is obtained be calling this function
Relevant links:
ZkLend repo: https://github.com/zkLend/zklend-v1-core Tx (StarkScan): https://starkscan.co/tx/0x07286e45814889d2dc7dbbf26c5b96b4950280c3fd3f2e38a44d8239a00db336 Contract Account (Market): https://starkscan.co/contract/0x04c0a5193d58f74fbace4b74dcf65481e734ed1714121bdc571da345540efa05
Update
Using starknet-replay's main branch with llvm 18
Running again block 626173 with both native and vm, the results were the folowing:
-
Native:
0xb2867a82804fcf3c9f99c11f58ee417f03e1524f44a3a5693f4fc293005761fails withNative execution error: u256_mul Overflow0x8eb8b1b474172281ea9616166faba9bd1c41972762cfd6e299b2a605592dfbfails withNative execution error: u256_mul Overflow0xce5e8c9abb185eb9fa91bdcdfb356d7692bfd1d538c57f39514abc4c7706b2fails withNative execution error: u256_mul Overflow0x10b00fcea9baac38510875f8cffcb1ba13897c2b38c6a4cac9949e785970e05fails withNative execution error: u256_mul Overflow
The rest of the transactions have the same result both in native and the vm. The
SM_SUB_UFdoes not seem to be gone, though is also appear while using the vm so my guess is that its execution depends on something (like time, as stated in the previous comment).
Fixed with #787 and #763