# Efficient Utilization of Sequencer Capacity in Starknet v0.12.1 **URL:** \ **Category:** 📜 Development Proposals\ **Created:** [June 26, 2023, 12:12pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607 "2023-06-26T12:12:39Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [June 26, 2023, 12:12pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/1 "2023-06-26T12:12:39Z")
In the process of Starknet becoming more decentralized, the development of the network is also transitioning towards a decentralized approach. The upcoming version of Starknet will be developed based on a public specification, enabling infrastructure providers and developers to prepare for future versions in advance. This post is a part of this ongoing process, and for upcoming versions, we plan to share detailed SNIPs in advance. This post proposes an enhancement to Starknet v0.12.1, addressing the issue of valuable sequencer resources being allocated to processing transactions that do not contribute to the final block. Currently, failed transactions do not pay fees, resulting in a flood of failed transactions occupying the space intended for other fee-paying transactions. To optimize the utilization of the sequencer capacity and fully leverage Starknet’s processing potential for valid transactions, the proposal suggests charging fees and including failed transactions in a block in a trusted manner. This enhancement elimantes the inefficiency observed in Starknet v0.11.0, where no fees are charged for failed transactions, resulting in significant investments of up to 66% of the sequencer capacity on transactions that are not included in the block. * * * # Outline of the proposal In a high-level perspective, the current process in Starknet involves a transaction being initially accepted by one of the gateways, functioning as the Mempool, marking its status as RECEIVED. The Sequencer operation, a single service, then sequentially applies the transactions to the state, marking them as ACCEPTED\_ON\_L2. The Prover stage executes the operating system on the new block, computes the proof, and transmits it to L1. ![|700x349.8293515358362](https://europe1.discourse-cdn.com/flex005/uploads/starknet1/original/3X/1/8/185ea10fe323b1dad28abb0f78d2995ef6deecd6.png) The proposed changes aim to enhance this process. Firstly, a validation stage will be added to the mempool to prevent invalid transactions from consuming valuable time of the sequencer. This ensures that only valid transactions proceed further. Additionally, transactions that fail during the execution stage in the sequencer will be included in the block with the status REVERTED. ![|688x344.5127388535032](https://europe1.discourse-cdn.com/flex005/uploads/starknet1/original/3X/6/7/6709a25de4da8d2d0bb6e4b1fcea14cbb7c74818.png) # Protocol changes In the context of Starknet, the protocol level refers to modifications made to the underlying Starknet OS cairo program that is proven. This section outlines the necessary changes at the protocol level to enable the inclusion of failed transactions in a block. 1. Transaction status: 2. State implications of REVERTED transaction: 3. The fee that will be charged is fee = Min(max\_fee, consumed\_resources) \* configurable\_factor when the configurable\_factor will be 1. 4. The Starknet OS will execute the following for failed transactions: 5. In the future, when only Cairo 1.0 is supported on Starknet, the OS will prove REVERTED transactions by executing the entire transaction. # API changes This section describes the [API-level changes](https://github.com/starkware-libs/starknet-specs) necessary to support the inclusion of failed transactions. See changes in [starknet-specs](https://github.com/starkware-libs/starknet-specs/commit/96e0bfb3cd5166d93c31d91897e7e62c2f3b67f5) 1. TRANSACTION\_TRACE: trace of a failed invoke tx will include the revert reason for the failed execution and will not include the **execute** call stack. 2. New TXN\_STATUS: REVERTED. 3. New fields will be added to the transaction receipt in order to better describe the transaction status in light of the newly introduced `REVERTED` status, as discussed in this post. This allows for transactions to be both unsuccessful and included in a block that is accepted on L2/L1. ![shaked (1)](https://europe1.discourse-cdn.com/flex005/uploads/starknet1/original/3X/b/b/bb8f281995b3e988987b4e8cfa4d8a07373b2051.png) * * * # StarkWare’s Current Sequencer changes The current centralized sequencer implementation in Starknet will undergo specific modifications to facilitate the successful inclusion of failed transactions. This section, which is not part of the Protocol/API changes, provides an explanation of the validation process that will be conducted in the temporary centralized sequencer of Starknet, as its behavior impacts all users of Starknet: ## The validation phase in the gateway 1. Check max\_fee is higher than the minimal tx cost 2. Check Account balance is at least max\_fee 3. Check nonce is bigger than the current nonce 4. Execute ` __validate__ ` 5. Limit #txs per account in the Gateway ## Rejected status for transactions `REJECTED` - will denote a transaction that passed the gateway and didn’t pass validation in the sequencer. This status is not part of the protocol, as the rejected transaction will not get included in a block. # Conclusion The proposed changes in Starknet v0.12.1 aim to improve the efficiency of the sequencer capacity by addressing the issue of processing failed transactions. Through the inclusion of failed valid-transactions in a block and charge fee for them, Starknet aims to optimize its processing potential for valid transactions. ---
**Author:** ![MempoolSurfer](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/mempoolsurfer/32/2955_2.png) [@MempoolSurfer](https://community.starknet.io/u/MempoolSurfer)\ **Post date:** [June 27, 2023, 1:17pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/2 "2023-06-27T13:17:35Z")
> [@EvyatarO](#): > > Min(max\_fee, consumed\_resources) \* configurable\_factor Just for my curiosity, what cases are there such that `consumed_resources` exceeds `max_fee`, and how significantly can it do so? ---
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [June 27, 2023, 2:04pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/3 "2023-06-27T14:04:35Z")
It’s not supposed to happen, the sequencer should terminate the execution when the resources limit is reached, but even in the case that a sequencer exceeds the resources derived from `max_fee` - the OS will still force the tx to be charged for no more than `max_fee`. ---
**Author:** ![MempoolSurfer](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/mempoolsurfer/32/2955_2.png) [@MempoolSurfer](https://community.starknet.io/u/MempoolSurfer)\ **Post date:** [June 27, 2023, 4:48pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/4 "2023-06-27T16:48:50Z")
Okay, thank you 😃 Would it be possible to reject transactions and express that failure in the response code of the originating POST request since the validation phase is bounded? If possible, the sequencer wouldn’t even have to store the rejected transaction in any way. ---
**Author:** ![DevenMat](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/devenmat/32/1399_2.png) [@DevenMat](https://community.starknet.io/u/DevenMat)\ **Post date:** [June 29, 2023, 6:37pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/5 "2023-06-29T18:37:33Z")
Interesting thought. Seems that currently `REJECTED` txns would have to be stored by the sequencer and be available for querying by the feeder gateway. If block explorers and indexers could themselves cache `REJECTED` txns through the original `POST` request, the sequencer doesn’t need to store txns that didn’t pay for resources. Would there need to be a harsh time limit on on the sequencer returning a txn as `REJECTED`? Would this have an affect on rate-limiting txns sent to the sequencer? ---
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [July 2, 2023, 8:53am UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/6 "2023-07-02T08:53:31Z")
This is the plan. Currently, if the gateway fails to process a transaction (e.g., due to a duplicate transaction hash), an error message will be returned from the gateway. In v0.12.1, with the introduction of an additional validation phase, if a transaction is found to be non-valid, the gateway will return an error message with relevant information (e.g., insufficient balance), and the sequencer will not save the transaction. The `REJECTED` status will be assigned to a transaction that passes the validation phase in the Mempool but fails in the validation phase during sequencing. This can occur, for example, if the account balance decreases between the transaction’s submission and the sequencing process. In such cases, the transaction will not be included in a block and will not be marked as `REVERTED`. ---
**Author:** ![maciejka](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/maciejka/32/96_2.png) [@maciejka](https://community.starknet.io/u/maciejka)\ **Post date:** [July 2, 2023, 10:29pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/7 "2023-07-02T22:29:14Z")
Will failed transactions corresponding to L1-\>L2 messages be included in the block? If so, what will happen during state update on L1 (in Starknet Core contract), will it still be possible to execute compensating action for L1-\>L2 message in case failed L2 execution? ---
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [July 4, 2023, 9:37am UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/8 "2023-07-04T09:37:50Z")
Hey! L1Handler won’t be reverted at this point, meaning no failed L1Handler be include in a block on v0.12.1 ---
**Author:** ![maciejka](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/maciejka/32/96_2.png) [@maciejka](https://community.starknet.io/u/maciejka)\ **Post date:** [July 4, 2023, 2:40pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/9 "2023-07-04T14:40:35Z")
So it will still be possible to cancel them as if they were not executed at all? ---
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [July 11, 2023, 9:17am UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/10 "2023-07-11T09:17:04Z")
Same as today, v0.12.1 won’t affect L1Handler ---
**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\ **Post date:** [July 13, 2023, 6:37am UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/11 "2023-07-13T06:37:32Z")
> [@EvyatarO](#): > > - All changes that occurred during the ` __validate__ ` stage are not reverted. what’s the rationale behind this? ---
**Author:** ![juniset](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/juniset/32/40_2.png) [@juniset](https://community.starknet.io/u/juniset)\ **Post date:** [July 13, 2023, 12:14pm UTC](https://community.starknet.io/t/efficient-utilization-of-sequencer-capacity-in-starknet-v0-12-1/95607/12 "2023-07-13T12:14:21Z")
@martriay I think this makes sense in the context of AA and it better aligns with the EVM where all the modifications to the account state (which only consists of the nonce and ETH balance) are persisted when a transaction reverts. There are also scenarios where it is needed. Imagine an account having multiple signers with different roles, and suppose signer `S` can only change a boolean flag on the account. Seems pretty harmless. However, if signer `S` is compromised he can now burn all the ETH of the account by submitting many transactions with insufficient gas (such that it passes validation but fails in execution). One solution to that problem would be to limit the number of failed transactions `S` can do by updating a counter in `validate` (and resetting it to 0 when the execution succeeds). Not saying it is the only way to address that problem, but it illustrates that there might be a need to persist the changes to the state that happened during `validate`.