https://medium.com/starkware/starknet-alpha-0-9-0-dce43cf13490
13/06/2022 from 06/06/2022
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.
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.
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.
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 ‘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.
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.
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 hashget_class_hash_at: returns the class hash of a deployed contract given the contract addressNote 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.
We proceed to incorporate fees into StarkNet, making them mandatory (first on Testnet, and later also on Mainnet) for [invoke](<https://docs.starknet.io/docs/Blocks/transactions#invoke-function>) 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.
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!
我们很高兴推出 StarkNet Alpha 0.9.0！这是一个重要的版本，StarkNet 在其成熟度方面迈出了重要的一步，对功能和协议设计进行了大量补充。
费用是强制性的（目前仅在测试网上，直到 0.9.0 版将在主网上上线）——任何繁荣的 L2 都必须有自己独立的费用系统。在 0.8.0 版本中将费用作为可选功能引入后，我们现在有信心将其作为协议的核心组件，并使其成为强制性的。更多详情如下。
协议级别的另一个重大变化是引入了合同类和类/实例分离。这允许更直接地使用 delegate_call 功能和现有合约的部署，从而在 StarkNet 上启用工厂模式。
从面向对象编程中汲取灵感，我们区分了合约代码及其实现。我们通过将合约分成类和实例来做到这一点。
合约类是合约的定义：它的 Cairo 字节码、提示信息、入口点名称以及明确定义其语义所需的一切。每个类都由其类哈希标识（类似于 OOP 语言中的类名）。
合约实例，或简称合约，是对应于某个类的已部署合约。请注意，只有合约实例表现为合约，即有自己的存储空间并且可以被交易/其他合约调用。合约类不一定有在 StarkNet 中部署的实例。类的引入伴随着一些协议更改。
我们正在向 StarkNet 引入一种新型交易：“声明”交易，它允许声明合约**类。**与 deploy 事务不同，这不会部署该类的实例。StarkNet 的状态将包括已声明类的列表。可以通过新的 declare 事务添加新类。
一旦声明了一个类，即相应的“声明”事务被接受，我们就可以部署该类的新实例。为此，我们使用新的 deploy 系统调用，它采用以下参数：
然后，“部署”系统调用将部署该合约类的新实例，其地址将由上述三个参数和部署者地址（调用系统调用的合约）确定。
在调用事务中包含部署允许我们为部署定价和收取费用，而不必区别对待部署和调用。有关部署费用的更多信息，请参阅文档。
此功能将合约工厂引入 StarkNet，因为任何合约都可以调用 deploy 系统调用，创建新合约。
类的引入使我们能够解决以太坊委托调用机制中的一个众所周知的问题：当一个合约对另一个合约执行委托调用时，它只需要它的类（它的代码）而不是一个实际的实例（它的存储）。因此，在进行委托调用时必须指定特定的合约实例是不好的做法（实际上，它导致了以太坊合约中的一些错误）——只需要指定类。
旧的 delegate_call 系统调用现在已弃用（已部署的旧合约将继续运行，但使用 delegate_call 的合约将不再编译），并被新的 library_call 系统调用取代，该系统调用获取类哈希（之前声明的类）而不是合约实例地址。请注意，库调用只涉及一个实际合约，因此我们避免了调用合约和实现合约之间的歧义。
我们向 API 添加了两个新端点，允许检索与类相关的数据：
get_class_by_hash：返回给定类哈希的类定义get_class_hash_at：返回给定合约地址的已部署合约的类哈希请注意，直接获取已部署合约的类，而不是通过上述两种方法，您可以使用旧的 get_full_contract 端点，该端点将在以后的版本中重命名。上面提到的所有端点也可以从StarkNet CLI中使用。
我们继续将费用纳入 StarkNet，使其成为强制交易（首先在测试网，后来也在主网上）用于“调用”交易。declare 交易此时不需要费用。同样，“部署”交易也不需要费用，但是请注意，这种交易类型很可能在未来的版本中被弃用。
该领域仍有几个悬而未决的问题，最突出的问题是如何对合同声明和 StarkNet 账户部署收取费用。我们将在未来的版本中解决这些问题。
按照我们在 2 月份宣布的路线图，我们致力于提高 StarkNet 的总体性能，特别是定序器的性能，以便让用户更快地获得有关其交易的反馈。在下一个版本中，我们计划在排序器中引入并行化，从而实现更快的块生产。
StarkNet 的下一个主要版本将侧重于 StarkNet 的帐户结构，其方式类似于ERC-4337。有了这个，我们将最终确定 StarkNet 帐户的行为方式，朝着大规模采用又迈出了重要一步！