SNIP-16: Deprecation of Transaction Versions 0,1,2

📜 Development Proposals SNIPs
1

snip: 16
title: SNIP-16: Deprecation of Transaction Versions 0,1,2
author: Ilia Volokh iliav@starkware.co
status: Review
type: Standards Track
category: Core
created: 2024/07/02
Github link

Simple Summary

In the context of a fee market, transaction versions 0,1,2 are inferior to and incompatible with transaction version 3: they support a different fee token and have inferior bid structure.

We propose to deprecate transaction versions 0,1,2 and to stop supporting them once the mempool is implemented in the sequencer.

Motivation

The sequencer currently processes transactions in FIFO. During congestion block space becomes scarce. To improve UX in such cases, Starknet will have a fee market which will allow users to express value and time preference.

Transaction version 3 was introduced with a 1559-type fee market in mind. First, it facilitates fee payment in STRK, which is designated as the only native fee token. Second, its bid structure names a price per unit resource, allowing the sequencer to easily compare bids.

Transaction versions 0,1,2 only support fee payment in ETH. Moreover, they have an inferior bid structure which causes inefficiencies in economic calculation by the sequencer. Specifically, the user submits a max fee, but does not directly specify a max fee per unit resource nor a max amount. There is no way to deduce either of these numbers from max fee. Consequently, there’s no intelligent way to decompose the user’s bid into a “base” fee and a “tip”.

Proposal

We propose for the sequencer to stop support for transaction versions 0,1,2 in an upcoming version in preparation for integrating the mempool and fee market, which is expected to happen within 6-8 months.

To facilitate continuation of fee payment in ETH, we propose to adopt paymasters. The decision between applicative paymasters such as the one by AVNU or protocol-level paymasters will be left to applications/wallets. (A detailed SNIP for a protocol-level paymaster is in the works.)

Rationale

We submit that paymasters are the correct solution for multiple fee tokens. Consequently there is no justification for contrived solution to facilitate continued support for old transaction versions.

Drawbacks

  1. Transaction versions 0,1,2 facilitate native fee payment in ETH. Their deprecation means ETH will no longer be a native fee token.

  2. At present a large portion of transactions pay fees in ETH. Consequently, a large portion of the demand will have to go through a different flow for fee payment, likely requiring changes from wallets and potentially (depending on the method of paymaster adoption) also DApps and infrastructre (SDKs).

  3. Old accounts, namely those predating the separation of validate and execute, can only be accessed via transactions v0. Hence deprecating this transaction version renders all such accounts (and their assets) inaccessible. We will address this issue in a separate SNIP.

Alternatives

Below we present some alternative proposals and our reasoning against them.

  1. Reserved but gradually decreasing block space for transaction versions ≤2, with temporary support for a designated FIFO queue.

  2. Concurrent fee markets on transactions paying in ETH and in STRK, with the sequencer taking on ETH↔STRK conversion. Note it’s unclear how to implement a fee market for transaction versions 0,1,2 since merely sorting according to max fee disregards the computational resources expended by the tx.

Backwards Compatibility

This proposal kills off the currently supported flows of sending transaction versions 0,1,2. Moreover, a separate proposal is required to address access to old accounts.

Security Considerations

This proposal introduces no vulnerabilities, but necessitates a separate discussion about accounts which predate the separation of validate and execute.

2

GM!

The sequencer currently processes transactions in FIFO

I thought Block-STM was implemented in .13.2. Does this mean ordering within blocks is FIFO instead of the fee based mechanism that other implementations use?

Or does it mean V0, V1, V2 and V3 transactions are executed as soon as they reach the sequencer?

It could mean neither but the point is I’m not sure I understand how blocks are built anymore.

Also, how are conflicting versioned transactions currently managed? Say if a V0, V1, V2, and V3 are to be processed; what does the sequencer do?

3

Hey @fikunmi_ap!

Block-STM was indeed implemented in v0.13.2 and is running in production now.

The block-building process now is roughly as follows:

  1. There are multiple instances of a service called a “gateway”. Think of these as gateways to the sequencer’s mempool whose job is to accept valid txs and reject invalid ones. Gateways expose an add_transaction API which full nodes consume. Gateways do not execute transactions.
  2. Right now, the gateways jointly try to write to a single queue. Disregarding duplicate txs (occurring if the same tx was accepted by multiple gateways), this queue determines the ledger, i.e the order of transactions in Starknet blocks.
  3. At the beginning of 2025, this queue will be replaced by a proper mempool which will be sorted into a queue via fee market.

Note Block-STM explicitly receives a queue (i.e ordered list) of transactions as its input. In this context, the question of how you order txs is unrelated to how you should concurrently execute a given ordered list of txs.

Concurrent execution is agnostic to transaction versions. Why do you call different versions ‘conflicting’?

4

I call them conflicting because I wonder how the queue is arranged. Does a v3 take priority over the other transaction types or are they treated equally?

5

All tx types are treated equally. Note the impending termination of all old transaction versions though!

6

Oh ok thank you!

(Sorry about botching your name btw)

7

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

We’re voting FOR this proposal.

However, we would like to point out that the lack of backward compatibility from the get-go is a bit concerning. While we understand this is going to be addressed in the future SNIPs, we hope that those will be proposed shortly after that proposal passes, without unnecessary delays.

Moreover, we would like to point out that switching solely to fee payment being made in STRK tokens raises questions about Starknet Ethereum alignment and Starknet anchoring in ETH ecosystem. With fees not being paid in ETH there is likely going to be less demand for ETH in Starknet in general, which can result in less ETH being bridged to Starknet. This issue and its’ implications for Starknet overall security should be analysed broader later, but we don’t think it should stop this change right now.

8

GM,

I agree that the lack of backward compatibility for <V3 transactions is a significant issue that should be addressed before proceeding further.
Users should not encounter blocked accounts if they are still on an older version that does not support >=V3 transactions. Additionally, we must consider un-deployed accounts, for which it’s impossible to determine their exact number.
We need a solution for those, we can’t just drop them.

Regarding the payment in STRK only, this “issue” is already gradually emerging due to the use of (AVNU) paymasters.
With this system, users don’t even need to hold STRK directly. However, when sending the proof, there is still a requirement to pay in ETH.
You could argue that the (AVNU) paymaster needs to pay at some point, which will be done in STRK, so this remark is a bit pointless.

G.