Add VM concurrency support

[AnkushinDaniil]

Fixes #2016

This PR adds a new flag, VMConcurrencyMode and changes cairoVMExecute.

[AnkushinDaniil]

Tested by running ./build/juno --http --vm-concurrency-mode and requesting

{
	"jsonrpc":"2.0",
	"method":"starknet_traceTransaction",
	"params":["0x5634f2847140263ba59480ad4781dacc9991d0365145489b27a198ebed2f969"],
	"id":1
}

Response body

{
  "jsonrpc": "2.0",
  "result": {
    "type": "INVOKE",
    "execute_invocation": {
      "contract_address": "0x31c9cdb9b00cb35cf31c05855c0ec3ecf6f7952a1ce6e3c53c3455fcd75a280",
      "calldata": [
        "0x20cfa74ee3564b4cd5435cdace0f9c4d43b939620e4a0bb5076105df0a626c6",
        "0x5aee31408163292105d875070f98cb48275b8c87e80380b78d30647e05854d5"
      ],
      "caller_address": "0x0",
      "result": [],
      "calls": [
        {
          "contract_address": "0x20cfa74ee3564b4cd5435cdace0f9c4d43b939620e4a0bb5076105df0a626c6",
          "calldata": [
            "0x5aee31408163292105d875070f98cb48275b8c87e80380b78d30647e05854d5",
            "0x7e5"
          ],
          "caller_address": "0x31c9cdb9b00cb35cf31c05855c0ec3ecf6f7952a1ce6e3c53c3455fcd75a280",
          "result": [],
          "calls": [],
          "events": [],
          "messages": [],
          "execution_resources": { "steps": 25 }
        },
        {
          "contract_address": "0x20cfa74ee3564b4cd5435cdace0f9c4d43b939620e4a0bb5076105df0a626c6",
          "calldata": [
            "0x5aee31408163292105d875070f98cb48275b8c87e80380b78d30647e05854d5"
          ],
          "caller_address": "0x31c9cdb9b00cb35cf31c05855c0ec3ecf6f7952a1ce6e3c53c3455fcd75a280",
          "result": ["0x7e5"],
          "calls": [],
          "events": [],
          "messages": [],
          "execution_resources": { "steps": 31 }
        }
      ],
      "events": [],
      "messages": [],
      "execution_resources": { "steps": 178 }
    }
  },
  "id": 1
}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.47%. Comparing base (67430de) to head (a053ddc).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2059   +/-   ##
=======================================
  Coverage   78.47%   78.47%           
=======================================
  Files         100      100           
  Lines        9234     9235    +1     
=======================================
+ Hits         7246     7247    +1     
  Misses       1350     1350           
  Partials      638      638           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AnkushinDaniil]

The current problem is this bug. It happened in sequential mode.
My hypotheses were:

1. Transaction preparation loop:
   In the updated code, transactions are first prepared and stored in a Vec<Transaction> before being executed. This is different from the old version, where each transaction was processed immediately after preparation. This change in flow can cause the error.
2. State management:
   In the old code, the CachedState is modified transactionally and committed after each transaction. In the new code, transactions are prepared, executed in a batch, and then the state is committed. Delaying the commit of state changes until all transactions are executed might lead to issues.
3. The charge_fee and validate are hardcoded as true in the transaction executor, this might cause the error. I changed them both to false, it doesn't help.

[AnkushinDaniil]

To make it work in my branch:

1. in vm/rust run make clean
2. here and here validate: false
3. in vm/rust run make all
4. make juno
5. ./build/juno --http --network sepolia and ran a test query
6. ./build/juno --http --network sepolia --vm-concurrency-mode and ran a test query
   test query:

{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "starknet_estimateFee",
    "params": {
        "request": [
            {
            "type": "INVOKE",
            "sender_address": "0xf9e998b2853e6d01f3ae3c598c754c1b9a7bd398fec7657de022f3b778679",
            "calldata": [
                "0x1",
                "0x41a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf",
                "0x1987cbd17808b9a23693d4de7e246a443cfe37e6e7fbaeabd7d7e6532b07c3d",
                "0x4",
                "0x16342ade8a7cc8296920731bc34b5a6530f5ee1dc1bfd3cc83cb3f519d6530a",
                "0x77295b07f4b1d4e4fdb18b26faf95d5bdb0087da065b7b0b49d0470d9cbf852",
                "0x1",
                "0x0"
            ],
            "version": "0x100000000000000000000000000000001",
            "signature": [],
            "nonce": "0x2a91",
            "max_fee": "0x0"
            }
        ],
        "block_id": "pending",
        "simulation_flags": [
            "SKIP_VALIDATE"
        ]
    }
}

[AnkushinDaniil]

Pathfinder team encountered the same problem

[rianhughes]

It would be good to add a test for the concurrency mode if possible.

Also curious what the performance of simulating a block in concurrency mode is as well.

[AnkushinDaniil]

I tried to measure performance by running multiple transactions and found a new bug.
The error is Transaction with no fee transfer info must have zero fee.
This happens here only in concurrency mode. According to blockifier, in both modes L1HandlerTransaction must have fee_transfer_call_info: None , i.e. problem in tx_execution_info.receipt.fee, it's not equal to 0.

[AnkushinDaniil]

Also curious what the performance of simulating a block in concurrency mode is as well.

I roughly measured the performance difference. I used a slice of different txs from sepolia block №84662 with length 89.
I measured the time of cairoVMExecute execution.
Results (average):

1. Original version: 100%
2. Concurrency support: sequential mode: ~99,59%
3. Concurrency support: concurrent mode: ~115,76%

I'm trying to get a profile of each version, but I get a weird result
I get ExternalCode only in concurrent mode

In addition, here are the original measurements:

Number of concurrent measurements more because I have a timeout = 60 seconds