Starknet.js support for v0 and v1 transactions

[ivpavici]

Hello!

Opening a discussion about support for v1 transactions in Starknet.js.

This discussion is meant to focus on the new, Starknet.js v5. The current (v4) does not support v1 transactions.

There are 2 possibilities as I see it:

1. Starknet.js v5 would support still both v0 and add support for v1 transactions.
2. Starknet.js v5 would support just v1 transactions

Option 2) is cleaner and based on discussion with Argent, they plan to support only v1 transactions in their new release (I believe Braavos will do the same)

Comment from Tom from dm-s regarding option 2:
The problem I see with it -
Assume I’m a dapp and wallets want to interact with me. There might be a wallet that uses tx v0 and a wallet that uses tx v1. By making it different versions on StarkNet.js we are forcing the dapps to choose one type of users. wdyt?

Comment from @dhruvkelawala :
On ArgentX, we were thinking of forcing user to upgrade account. Instead of “Upgrade Available”, we would just say “Upgrade Required”, without which user won’t be able to make transactions on ArgentX. On starknet.js, we can update documentation to say account.execute() is now mandatory
Hey, I don’t think so dApps will have to make any changes regardless of which starknetjs version the wallet is using
account.execute still has the same signature
. Using Transaction Version v1 solely depends on the wallet. If they want to support both or one of them. dApps just have to do account.execute()

[janek26]

I think in general a user of starknet.js doesn't care about the underlying implementation, as long as the interfaces stay the same, or close to being the same / are still compatible.

that being said I think

1. We dont need v5 to support the new transaction type
2. We should not support both implementations, but simply do the switch to the new transaction type as soon as it's available in testnet. We can release (merge to main) once the new transaction type arrives on mainnet.

I dont think dapps would care a lot about the underlying implementation, but mostly about the interface they use to interact with starknet.js, so I dont see a problem in Tom's statement and agree with Dhruv.

[bbrandtom]

The problem as I see it -

The network will be upgraded to allow both transaction versions this week on Goerli and next week on Mainnet. Transaction v0 will only be removed on the following network major upgrade (v0.11.0).

In the meantime, if we won't release a version that supports both transactions, we will create a time when dapps do not support some wallets. There will be a difference between the time the wallets update to the new version and the dapps update to the new version. It will be very hard to coordinate an upgrade simultaneously for all the parties.

It's unrelated to the underlying implementation but to the ability to support all users during the transition period.

[dhruvkelawala]

I am not sure if dApps will need to go through any major changes (or any at all). Today dApps use either of the two approaches when doing an INVOKE_FUNCTION transaction.

1. account.execute() - The signature of this remains same before and after changes done for v0.10.0 . So even if there is a mismatch in starknetjs version used by dApps vs wallet, it will work fine. dApps doesn't have to care which Transaction Version is being used. With the latest changes, all Transactions will be v1 .

2. contract.invoke() - This is the most common way afaik that dApps make INVOKE_FUNCTION calls. But as seen over here, we check if the contract is connected to the account. It should be connected to the account and at this point we call account.execute.

In both of these cases, dApps doesn't have to go through any changes. It only depends on wallet when they want to support new transaction version by updating their AccountContracts and using the new starknet.js. I hope that I was able to bring more clarity to this discussion. 😄

[dhruvkelawala]

Possible Issue:

Let's say there are 2 wallets - X and Y. X updates AccountContract for v0.10 by decoupling __validate__ and __execute__ while Y doesn't for now. Y plans to do it in upcoming days. Now if the dApp makes account.execute request after updating starknet.js with v0.10 changes where we are defaulting to Transaction Version v1, INVOKE_FUNCTION calls going through Y's AccountContract will fail as it won't have __validate__ method. It will also fail because of different handling of nonces in both versions.

I think this is what @bbrandtom was trying to explain. I am not sure about the best solution though other than all wallets simultaneously using the latest starknet.js . I don't see a way of supporting both versions at the same time.

[janek26]

I don't think this is an issue, as dapps use the account object provided by a wallet, and dont import it from starknet.js
So the wallet has full control of how the transaction gets send - the only thing a dapp cares about is that the transaction completes, no matter how

[dhruvkelawala]

That makes sense. Thanks

[bbrandtom]

My mistake was that I didn't understand that the dapp receives the account object from the wallet. Thanks for the explanation @janek26 and @dhruvkelawala 🙏
This solves my issue. @ivpavici we can close this discussion from my side.