TL;DR
- Fees are now mandatory on Testnet, soon on Mainnet
- Contract factory pattern is now possible!
- Starknet is introducing contract classes
- Delegate call is replaced with library call
Intro
We are happy to introduce Starknet Alpha 0.9.0! This is an important version in which Starknet makes significant steps towards maturity, with substantial additions to both functionality and protocol design.
Fees are mandatory (currently only on Testnet, until version 0.9.0 will be live on Mainnet) — any prospering L2 must have its own independent system of fees. After introducing fees as an optional feature in version 0.8.0, we now feel confident to include them as a core component of the protocol, and make them mandatory. More details below.
Another significant change at the protocol level is the introduction of Contract Classes and the class/instance separation. This allows a more straightforward use of the `delegate_call` functionality and deployments from existing contracts, enabling the factory pattern on Starknet.
Contract Classes
Taking inspiration from object-oriented programming, we distinguish between the contract code and its implementation. We do so by separating contracts into classes and instances.
A contract class is the definition of the contract: Its Cairo bytecode, hint information, entry point names, and everything necessary to unambiguously define its semantics. Each class is identified by its class hash (analogous to a class name from OOP languages).
A contract instance, or simply a contract, is a deployed contract corresponding to some class. Note that only contract instances behave as contracts, i.e., have their own storage and are callable by transactions/other contracts. A contract class does not necessarily have a deployed instance in Starknet. The introduction of classes comes with several protocol changes.
‘Declare’ Transaction
We’re introducing a new type of transaction to Starknet: the ‘declare’ transaction, which allows declaring a contract class. Unlike the `deploy` transaction, this does not deploy an instance of that class. The state of Starknet will include a list of declared classes. New classes can be added via the new `declare` transaction.
The ‘Deploy’ System Call and Contract Factories.
Once a class is declared, that is, the corresponding `declare` transaction was accepted, we can deploy new instances of that class. To this end, we use the new `deploy` system call, which takes the following arguments:
- The class hash
- Salt
- Constructor arguments
The ‘deploy’ syscall will then deploy a new instance of that contract class, whose address will be determined by the three parameters above and the deployer address (the contract that invoked the system call).
Including deployments inside an invoke transaction allows us to price and charge fees for deployments, without having to treat deployments and invocations differently. For more information about deployment fees, see the docs.
This feature introduces contract factories into Starknet, as any contract may invoke the `deploy` syscall, creating new contracts.
Moving from ‘Delegate Call’ to ‘Library Call’
The introduction of classes allows us to address a well-known problem in Ethereum’s delegate call mechanism: When a contract performs a delegate call to another contract, it only needs its class (its code) rather than an actual instance (its storage). Having to specify a specific contract instance when doing a delegate call is therefore bad practice (indeed, it has led to a few bugs in Ethereum contracts) — only the class needs to be specified.
The old `delegate_call` system call now becomes deprecated (old contracts that are already deployed will continue to function, but contracts using `delegate_call` will no longer compile), and is replaced by a new library_call system call which gets the class hash (of a previously declared class) instead of a contract instance address. Note that only one actual contract is involved in a library call, so we avoid the ambiguity between the calling contract and the implementation contract.
New API endpoints
We added two new endpoints to the API, allowing retrieval of class-related data:
- `get_class_by_hash`: returns the class definition given the class hash
- `get_class_hash_at`: returns the class hash of a deployed contract given the contract address
Note that to obtain the class of a deployed contract directly, rather than going through the two methods above, you can use the old `get_full_contract` endpoint, which will be renamed in future versions. All the endpoints mentioned above are also usable from the Starknet CLI.
Fees
We proceed to incorporate fees into Starknet, making them mandatory (first on Testnet, and later also on Mainnet) for `invoke` transactions. The `declare` transaction will not require fees at this point. Similarly, `deploy` transactions will also not require a fee, however, note that this transaction type will most likely be deprecated in future versions.
Several open questions remain in this area, the most prominent ones being how to charge fees for contract declarations and Starknet accounts deployment. We will tackle these issues in future versions.
What’s Next?
Following our roadmap that we announced in February, we are committed to improving Starknet’s performance in general, and the sequencer’s performance in particular, to get users faster feedback about their transactions. In the next version, we plan to introduce parallelization into the sequencer, enabling faster block production.
The next major version of Starknet will focus on the structure of Starknet’s accounts, in a way that is similar to ERC-4337. With this, we will have finalized the way Starknet accounts behave, taking yet another major step towards mass adoption!
