Transaction v3 SNIP

đź“ś Development Proposals SNIPs
1

This is to discuss the Transaction V3 Structure SNIP:

Open questions:

  1. Should we separate the fields nonce_data_availability_mode and fee_data_availability_mode or use one data_availability_mode that will be used both for nonce and fee?
3

I had envisioned paymaster’s being offered by dapps generally on a per-dapp basis. In which case I imagine providing the paymaster_address would allow the dapp’s paymaster to validate the “request” by the account that the tx fees be covered.

4

I appreciate that backward compatibility is addressed with a transition period for the tx sender, but are there any backward compatibility issues on the contract side? I.e. would an immutable / non-upgradeable Cairo 1 contract deployed prior to 0.13 still be compatible with a v3 tx sent after 0.13?

And although the pre-0.13 contract wouldn’t be able to take advantage of volition with its internal storage, would a user by able to submit a v3 tx to the pre-0.13 contract with a L2DA fee selected, and / or with a paymaster selected?

5

Yes, Cairo 1.0 contracts won’t break. The OS keeps all syscalls and execution backward compatible for Cairo 1.0.
As you mentioned, non-upgradable contracts won’t be able to benefit from new features (e.g., volition) or the new TxInfo (e.g., max L1_gas price for the tx), but the deployed contract won’t break and will continue functioning.

Users initiating a v3 transaction will be able to enjoy paying fees from their L2DA balance and the use of the paymaster (once implemented in Starknet) regardless of the contracts they’re interacting with.

6

I have various random questions:

  1. In the document, you use the || operator in some places. What does it do? Is it string concatenation?
  2. The Resource can only be L1_GAS or L2_GAS correct?
  3. How does the nonce_data_availability_mode and fee_data_availability_mode work? What are they for? Isn’t nonce_data_availability_mode set only once when an account is deployed?
  4. How is compiled_class_hash calculated? The link in the document leads to something unrelated. Why do we need it at all? Update: I’ll partially answer myself - v2 declare tx also already has compiled_class_hash.
  5. In the reply above you write “Users initiating a v3 transaction will be able to enjoy paying fees from their L2DA balance” - how will this work? Won’t the token itself need to support L2 DA balance in the first place?
7

Great proposal! A few questions:

  1. We’re adding a tip for tx order, is this somehow enforced? Or just implemented at the sequencer level but can be changed by the sequencer?
  2. Why is account_init_code needed in the declare fields?
  3. I’m not really sure why account deployments are treated differently (Deploy_account_v3_tx_hash, deploy_account as TX_PREFIX). Can’t validate_deploy be used by any other, regular contract? I don’t think it should be account specific.
  4. What does || mean?
  5. I assume that if no paymaster is being used, paymaster_address should be 0? or oneself?
  6. on the get_execution_info changes, the first element is not named, just typed (List[Resource]) i guess the obvious name would be resources.
  7. How will single-tx deployments (deploy + invoke) would look like?
  8. and what about declare + invoke? this one confuses me a bit

Also, some small typos:

  • hybris → hibryd
  • Daeclare → declare
  • __validate_delcare__ → __validate_declare__