Cairo v0.6.2: API change - Pending block

TLDR

  • The semantics of status PENDING is changed
  • PENDING status is broken into PENDING and ACCEPTED_ON_L2
  • State changes for transactions in the new PENDING state are reflected in the API by adding the argument blockNumber=pending to call, support in the CLI will be added soon.
  • Pending transactions don’t have block hashes
  • Added ability to query the current block under construction with blockNumber=pending

You may have noticed that we recently made a small change to the life cycle of a transaction. So far, the transaction status cycle was RECEIVED, PENDING, and ACCEPTED_ONCHAIN. As the names suggest, RECEIVED implied a transaction was received internal and ACCEPTED_ONCHAIN implied that a proof for a block containing this transaction was accepted on L1. PENDING indicated that the sequencer closed the next block to be proved.

Following a recent upgrade to the sequencer’s behavior, a transaction now becomes PENDING before the next block is closed (while the block it’s expected to be included in is still under construction). A new status was added to better capture this flow, a transaction lifecycle now follows the path: RECEIVED, PENDING, ACCEPTED_ON_L2, and ACCEPTED_ON_L1.

Note that the semantics of PENDING is now different: a transaction becomes PENDING once the sequencer decides to include it in the next block, but is still updating said block. Consequently, pending transactions will not have a block hash. The new status, ACCEPTED_ON_L2 (analogous to the previous semantics of pending) indicates that the block was closed.

To query the block under construction and see the transactions it currently includes, simply use the get_block API with blockNumber=pending. To see the effects of pending transactions on the state, use the call API with blockNumber=pending (by default call will not reflect changes caused by pending transactions). Note that this is still not supported in the CLI, but only by calling the API directly.

7 Likes