cairo_native icon indicating copy to clipboard operation
cairo_native copied to clipboard

[BUG][Block 626173]Bug Native execution error: SM_SUB_UF

Open pefontana opened this issue 1 year ago • 1 comments

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"`

pefontana avatar Jul 10 '24 17:07 pefontana

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

FrancoGiachetta avatar Jul 16 '24 16:07 FrancoGiachetta

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:

    • 0xb2867a82804fcf3c9f99c11f58ee417f03e1524f44a3a5693f4fc293005761 fails with Native execution error: u256_mul Overflow
    • 0x8eb8b1b474172281ea9616166faba9bd1c41972762cfd6e299b2a605592dfb fails with Native execution error: u256_mul Overflow
    • 0xce5e8c9abb185eb9fa91bdcdfb356d7692bfd1d538c57f39514abc4c7706b2 fails with Native execution error: u256_mul Overflow
    • 0x10b00fcea9baac38510875f8cffcb1ba13897c2b38c6a4cac9949e785970e05 fails with Native execution error: u256_mul Overflow

    The rest of the transactions have the same result both in native and the vm. The SM_SUB_UF does 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).

FrancoGiachetta avatar Sep 10 '24 18:09 FrancoGiachetta

Fixed with #787 and #763

pefontana avatar Sep 26 '24 23:09 pefontana