starknet/v0.12.0

New crate versions

• starknet: v0.12.0
• starknet-signers: v0.10.0
• starknet-providers: v0.12.0
• starknet-macros: v0.2.1
• starknet-curve: v0.5.1
• starknet-crypto: v0.7.2
• starknet-core: v0.12.0
• starknet-contract: v0.11.0
• starknet-accounts: v0.11.0

Breaking changes

Signer trait changes

The Signer trait has been updated in #617 and #648 to account for the fact that some Signer implementations are most expensive to use than others, sometimes even depending on the calls being made. The new feature is known as "signer interactivity". When an implementation is behaving as interactive, higher-level types (e.g. Account) in the library would avoid signature requests unless absolutely necessary.

CompiledClass changes

In #651, the type for the bytecode_segment_lengths field in CompiledClass has been changed to fix a deserialization bug. This only affects downstream code that constructs CompiledClass directly.

New features

Ledger signer

Added in #605, a new Signer implementation backed by the Ledger hardware wallet is now available. The feature is off by default and must be turned on via the ledger feature of starknet-signers.

The new type LedgerStarknetApp can also be used outside of the context of Signer to use Ledger-specific functionalities (e.g. getting Ledger app version).

Support for JSON-RPC batch requests

Implemented in #653, it's now possible to send multiple JSON-RPC requests in parallel utilizing the same HTTP request.

starknet/v0.11.0

New crate versions

• starknet: v0.11.0
• starknet-signers: v0.9.0
• starknet-providers: v0.11.0
• starknet-macros: v0.2.0
• starknet-curve: v0.5.0
• starknet-crypto: v0.7.0
• starknet-crypto-codegen: v0.4.0
• starknet-core: v0.11.0
• starknet-contract: v0.10.0
• starknet-accounts: v0.10.0

Breaking changes

The FieldElement type has been replaced by Felt from starknet-types-core

Note

As noted in #562, performance of EC and Poseidon operations has decreased with this type migration. More work is required to investigate the performance drop.

Following an ecosystem-wide initiative to unify field element types across different crates, starknet-rs has replaced the use of its own FieldElement type from the starknet-ff crate with the Felt type from starknet-types-core.

This has resulted in huge breaking changes for most, if not all, users of the starknet-rs library. To resolve the breakage, simply replace all uses of FieldElement with Felt. Note that the new Felt type is available as a re-export from starknet-core as starknet_core::types::Felt (or starknet::core::types::Felt), similar to how the old FieldElement type used to be available from starknet_core::types::FieldElement. You don't have to explicitly import the starknet-types-core crate, unless you have a reason to do so.

The public API of the new Felt type is quite similar to what FieldElement used to offer, with a few notable differences:

1. .from_hex_be() is now .from_hex().

2. .from_mont() is removed. A new method .from_raw() is available for constructing Felt in const contexts. However, note that .from_mont() and .from_raw() DO NOT take the same input. In fact, you must reverse the input you gave .from_mont() to .from_raw().

   You're always advised to use felt!() for constructing const field element instances, which encapsulates this underlying complexity for you.

3. Similarly, .into_mont() has been removed and .to_raw() is available as an alternative.

4. .from_bytes_be() now cannot fail, so it returns Felt istead of Option<Felt>.

Macros like felt!() and selector!() still work the same way they did, except the expression type is now Felt instead of FieldElement.

Removal of the starknet-ff crate

Due to the replacement of FieldElement by Felt, the starknet-ff crate is no longer useful. The crate has been removed from this repository. If you need direct access to the field element crate, change to depend on starknet-types-core instead.

Supported JSON-RPC spec version changed to 0.7.1

As usual, starknet-rs does not support multiple JSON-RPC versions side by side. Users who wish to stay on JSON-RPC v0.6.x should use a previous lib version.

Account and AccountFactory traits

New methods have been added to the Account and AccountFactory traits to support v3 transactions. Downstream crates that implement these traits must be updated.

Deprecation

Deprecating unversioned calls from Account and AccountFactory

Due to the new addition of v3 transaction support, unversioned methods like .execute() and .declare() from Account, along with .deploy() from AccountFactory, are now deprecated. Using these would result in sending pre-v3 transactions - like they did before this upgrade, and hence only a deprecation, users are advised to use verisioned variants like .execute_v1() to clearly indicate the transaction version to be used. These deprecated methods will be removed in the upcoming v0.12.0 release.

New features

Support for JSON-RPC spec v0.7.1

Types have been updated to reflect the spec changes. A new .get_block_with_receipts() method has also been added to the Provider trait to support the new starknet_getBlockWithReceipts method from the specs.

Support for v3 transactions

While low-level types have been available for constructing v3 transaction for a while, the library hasn't offered a way to send them idiomatically, until now. Users can now use the new versioned methods from Account and AccountFactory like .execute_v3() for sending v3 transactions and pay transaction fees in STRK.