JSON-RPC 0.9.0: add pre-confirmed block

[kkovaacs]

Starknet 0.14.0 is introducing a new distributed Sequencer architecture and the new status values provide more granular information on the processing status and finality of the transaction.

Two new transaction statuses will be introduced: CANDIDATE (scheduled for inclusion by the proposer but not yet executed) and PRE_CONFIRMED (scheduled for inclusion and executed). JSON-RPC changes are already in the 0.9.0-rc.0 release of the specification.

The feeder gateway API will introduce a new endpoint (get_pre_confirmed_block) that can be used to query list of pre-committed (and candidate) transactions that are being processed by the current proposer. The goal is to allow nodes supporting a "useful" pre-confirmed block in 0.14.0. The response contains the following properties:

• block header fields required for execution (like the pending block currently has)
• transactions: the list of transactions, first the pre-confirmed ones then the candidates (not yet executed)
• transaction_receipts: the list of transaction receipts for pre-confirmed transactions, will contain nulls for candidates
• transaction_state_diffs: the list of per-transaction state diffs, will contain nulls for candidates.

The node is expected to poll the "get_pre_confirmed_block" feeder gateway endpoint every second (?) and re-construct the pre-confirmed block (requires squashing per-tx state diffs) and store the list of candidate transactions.

The pre-confirmed block is to be served exclusively for JSON-RPC 0.9. Older JSON-RPC versions will have to fall back to serving the latest block as "pending" for Starknet 0.14.0 (because of the differences in finality semantics). JSON-RPC 0.9 will rename the "pending" BLOCK_TAG to "pre-confirmed" to reflect the semantics change.

JSON-RPC method changes:

• All execution-related methods should be able to use the new pre-committed block tag for execution (same as pending).
• starknet_getTransactionStatus should search both pre-confirmed transactions and candidate transaction list.
• starknet_getTransactionByHash should search pre-confirmed transaction list (but not candidates).

[kkovaacs]

This should be on hold until Starkware figures out the feeder gateway API (and whether it will be a per-transaction query or something similar to the "pending" block).

[kkovaacs]

We have this implemented now, except for subscription method changes. For that we have issue #2819, so I'm closing this for now.