Error when executing multiple calls via sending single invoke transaction on predeployed ERC20 mintable OZ contract

[DelevoXDG]

Describe the bug (observed vs expected behavior)

Error "Unexpected holes in the event order" when attempting to get a receipt after executing multiple calls via sending single invoke transaction on predeployed ERC20 mintable OZ contract.

Not reproducible on alpha-goerli

• This issue is only present on Devnet and cannot be reproduced on alpha-goerli (check the box if true).
• This error is not present in pythonic devnet, didn't test it on goerli.

To Reproduce
Steps to reproduce the behavior:

1. Run devnet:

starknet-devnet --host 0.0.0.0 --port 5051 --seed 1053545547

2. Create account, prefund address and deploy a new account at that address (sncast was used). Verify that all of said operations completed successfully.
3. Create two calls to predeployed ERC20 contract using the tool of choice (starknet.swift in my case). This is for demonstration purposes only, since raw requests are hard to read.

        let calldata1: [Felt] = [
            "0x34864aab9f693157f88f2213ffdaa7303a46bbea92b702416a648c3d0e42f35",
            1000,
            0,
        ]

        let calldata2: [Felt] = [
            "0xa97c3906ca442b26b68f9b510ee15c4a6994764de828a1b5dc04fe7f717063",
            1000,
            0,
        ]
        let call1 = StarknetCall(contractAddress: "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7", entrypoint: starknetSelector(from: "transfer"), calldata: calldata1)
        let call2 = StarknetCall(contractAddress: "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7", entrypoint: starknetSelector(from: "transfer"), calldata: calldata2)

4. Using the same tool generate and send the request:

let result = try await account.execute(calls: [call1, call2])

The raw RPC request will look something like:

curl -XPOST -H "Content-Type: application/json" -d '{
	"jsonrpc": "2.0",
	"id": 0,
	"method": "starknet_addInvokeTransaction",
	"params": {
		"invoke_transaction": {
			"max_fee": "0x2deb9e83c4000",
			"calldata": [
				"0x2",// number of calls
				"0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7",// call1_contract_address
				"0x83afd3f4caedc6eebf44246fe54e38c95e3179a5ec9ea81740eca5b482d12e",// call1_entrypoint - "transfer"
				"0x0",// count of calldata added up to this point
				"0x3",// count of call1 calldata		
				"0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7",// call2_contract_address_2
				"0x83afd3f4caedc6eebf44246fe54e38c95e3179a5ec9ea81740eca5b482d12e",// call2_entrypoint - "transfer"
				"0x3",// count of calldata added up to this point
				"0x3",// count of call2 calld
				"0x6",// count of calldata added up to this point
				"0x7598217a5d6159c7dc954996eeafacf96b782524a97c44e417e10a8353afbd4",// call1_calldata[0]
				"0x3e8",// call1_calldata[1]
				"0x0",// call1_calldata[2]
				"0x2000c94da25e3772c290db227f1f57358c65d3bdda517dcd3dcbdbb04141900",// call2_calldata[0]
				"0x3e8",// call2_calldata[1]		
				"0x0"// call2_calldata[2]			
			],
			"signature": [
				"0x740ace7624766fe489732ac222dff263ccc558aa5acb8221ef4075b422f6b76",
				"0x3fe8c90caf6cbbeda439a23f248bef3244debf9f01122a794b1a3f8167b7cef"
			],
			"version": "0x1",
			"type": "INVOKE",
			"sender_address": "0x1323cacbc02b4aaed9bb6b24d121fb712d8946376040990f2f2fa0dcf17bb5b",
			"nonce": "0x0"
		}
	}
}' "http://0.0.0.0:5051/rpc"

5. Then, try to retrieve a receipt of generated transaction:

curl -XPOST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"starknet_getTransactionReceipt","params":["0xbbfe0afbd97275d19cab614cb9d35c924f5b0e0298cc1a4b242ec533d70e46"],"id":1}' "http://0.0.0.0:5051/rpc"

Response:

{"jsonrpc":"2.0","id":1,"error":{"code":-1,"message":"Unexpected holes in the event order"}}      

Important:

1. Using the same tools for different contract (without events) will not cause such error
   1.1. You can assume steps 2, 3, 4 are not faulty as they end up generating correct requests.
2. Executing just one of the calls will not cause an error.
3. Works with pythonic devnet.
4. Even if incorrect response or invalid calls were to be made I assume a proper receipt should be generated with transaction marked REJECTED or REVERTED.

Devnet version

• I am using Devnet version: https://github.com/0xSpaceShard/starknet-devnet-rs/tree/02351c9c5665af5180b698a4afe58d60760bbcb7
• This happens with a dockerized Devnet (check the box if true).
• This does not appear on the following Devnet version: devnet.py 0.5.5

System specifications

• OS: MacOS M1 (aarch64)

[ivpavici]

@DelevoXDG seems like this could be a bug on starknet_in_rust, we have reached out to Lambda Class!

[mmsc2]

@DelevoXDG hey hello, i have been working on this issue but i had had troubles to replicate the bug, mainly because i dont have certain information/tools. When you use sncast where do you get the class hash of the ZN contract? because i need it in order to create the account, otherwise i get a contract error. Also, is there another tool similar to starknet.swift to make the calls?

[DelevoXDG]

@mmsc2 hello!
If you are referring to the class hash of the account contract, I'm using the class hash of the predeployed (on devnet) account contract, which needs to be supplied both when running account create and account deploy.
To make the calls if you prefer you can use starknet.py or starknet-jvm which provide similar functionality. Another approach that you may try is using multicall in sncast.

[mmsc2]

@DelevoXDG thank you, that helps a lot and is what i needed. i will be checking the issue with that.

[ClementWalter]

Kakarot entrypoint https://github.com/kkrt-labs/kakarot/blob/main/src/kakarot/kakarot.cairo#L123 is failing with the same error. It does:

• deploy_contract syscall
• emit event
• IERC20.transfer

[ivpavici]

@DelevoXDG can you check please, should be fixed now!

[DelevoXDG]

Thanks, I will let you know when it's checked.

[DelevoXDG]

@ivpavici
Seems like the issue no longer appears in that use case, good job! 🔥