Support Starknet 0.13 #129
Conversation
…pe.swift to ./Data
- Add `StarknetDeprecatedTransaction` (v1, v2) - Add `StarknetTransactionV3` - Add `StarknetDeclareTransaction`, `StarknetDeployAccountTransaction`, `StarknetInvokeTransaction` - Add `StarknetExecutableTransaction` (helpful for #128) - Add `StarknetExecutableInvokeTransaction`, `StarknetExecutableDeployAccountTransaction`
- Make `value` type `BigUInt` - Change to lowercase
| } | ||
|
|
||
| let defaultBlockId = StarknetBlockId.tag(.pending) | ||
|
|
||
| let defaultSimulationFlagsForEstimateFee: Set<StarknetSimulationFlagForEstimateFee> = [] |
There was a problem hiding this comment.
In Account estimateFee functions, I think we should (for now) default to passing the .skipValidate flag, since, as I remember, some nodes had problem validating signatures for txs with query versions.
As for Provider.estimateFee, I'm not sure, as Provider methods should probably be more explicit. Might be better to send request with no flags by default, or remove default value for simulation_flags altogether, as in simulateTransactions.
WDYT?
There was a problem hiding this comment.
In Account estimateFee functions, I think we should (for now) default to passing the .skipValidate flag, since, as I remember, some nodes had problem validating signatures for txs with query versions.
hmm, that's weird. was this checked with some newer nodes' releases? Do you happen to know if that was by design, or by mistake? Either way, I'm afraid we will set this up and not change it, ever. So (if that's by mistake) let's maybe pass on this idea, and push on nodes maintainers to fix this? If that's by design then you're right, and we can add this.
As for Provider.estimateFee, I'm not sure, as Provider methods should probably be more explicit. Might be better to send request with no flags by default, or remove default value for simulation_flags altogether, as in simulateTransactions.
I'd lean towards sending without flags by default, but up to you really
There was a problem hiding this comment.
hmm, that's weird. was this checked with some newer nodes' releases?
Checked this now. Can't test all of it, since we don't have goerli testnet funds, but invoke and deploy account seem to work fine on goerli integraiton and sepolia integration as of now.
Do you happen to know if that was by design, or by mistake?
Query versions should work, so probably by mistake. The problem was also present on devnet and now seems to be resolved.
Considering this, it might be actually reasonable to not skipValidate by default.
- Rename StarknetDeployAccountParams -> StarknetDeployAccountParamsV3 - Rename StarknetInvokeParams -> StarknetInvokeParamsV3 - Split StarknetDeprecatedExecutionParams into StarknetInvokeParamsV1 and StarknetDeployAccountParamsV1
Describe your changes
Support RPC 0.6.0 with Starknet 0.13 limitations
StarknetExecutableTransactionsimulateTransactionsandestimateFeearguments to invoke and deploy account transactions #128StarknetDeprecatedTransaction- for v0, v1 and v2 transactionsStarknetTransactionV3- for v3 transactionsStarknetExecutableInvokeTransactionandStarknetExecutableDeployAccountTransactionStarknetAccountmethods:signV3,executeV3,estimateFeeV3,estimateDeployAccountFeeV3StarknetAccountmethods related to v1 transactionsStarknetInvokeParamsV3andStarknetDeployAccountParamsV3StarknetExecutionParamsandStarknetOptionalExecutionParamsremoved in favor ofStarknetInvokeParamsV1,StarknetOptionalInvokeParamsV1andStarknetDeployAccountV1Provider.addInvokeTransactionnow accepts anyStarknetExecutableInvokeTransactionProvider.addDeployAccountTransactionnow accepts anyStarknetExecutableDeployAccountTransactionestimateFeesimulation flags; Currently it's justSKIP_VALIDATE, it can be used by passingskipValidate = truetoStarknetAccountfee estimation methodsUInt64AsHex,UInt128AsHex; Add clamped constructor toNumAsHexProtocolactualFeeis now of typeStarknetFeePaymentinstead ofFeltStarknetExecutionResourcesStarknetExecutionResourcestoStarknetFunctionInvocationdatafield toJsonRpcErrorStarknetAccount.sign(typedData: StarknetTypedData)adjusted for new errorDevnetClientLinked issues
Closes #124
Closes #128
Closes #89
Breaking changes
StarknetAccountProtocol,StarknetAccount.sign,estimateFee,execute,signDeployAccount,estimateDeployFeeare now split into two versions, withV1andV3postfix for transactions version 1 and 3 respectfullyStarknetExecutionParamsandStarknetOptionalExecutionParams; UseStarknetInvokeParamsV1,StarknetOptionalInvokeParamsV1andStarknetDeployAccountV1insteadStarknetProviderProtocol,StarknetProvider:estimateFeeandsimulateTransactionsnow only support transactions that conform toStarknetExecutableTransactionStarknetTransactionReceipt:actualFeeis now of typeStarknetFeePaymentinstead of `FeltStarknetExecutionResourcesfields are now of typeIntinstead ofNumAsHex