TL;DR
●?Starknetalphav0.11.0已经发布并在测试网上线。
●?你现在可以在Starknet测试网上部署Cairo1.0合约并与之交互。
●?Starknet上的计算成本便宜5倍。
●?主网升级到Starknetalphav0.11.0将首次进行治理投票，
●?这标志着过渡期的开始。
●?只有在测试网上运行几周后，我们才能确保新系统顺利运行，才能在主网上部署Cairo1.0合约。
介绍
我们很高兴地宣布，期待已久的Starknetalphav0.11.0已在测试网上上线！为什么说这是Starknet迈出的一大步？在Starknetv0.11.0中，你可以部署和运行Cairo1.0智能合约。我们还引入了一个新的系统调用，允许将现有合约平稳过渡到Cairo1.0运行。
Cairo1.0在两个不同方面改进了Starknet。首先，它通过提供更丰富的编程语言改善了开发体验，该语言向Cairo引入了类型/泛型/特征/错误处理。其次，Cairo1.0在Starknet的去中心化进程中发挥了关键作用：Starknetalphav0.11.0中发送的Cairo1.0合约编译为Sierra。Sierra保证每个合约的执行都是可证明的，这是实现去中心化Starknet的一个重要步骤。
此版本中的另一项重要改进是计算成本降低了5倍。这将使Starknet对计算密集型应用程序更加友好。详情如下。
为Regenesis做好准备
Starknetalphav0.11.0标志着过渡时期的开始，这将为Starknet的Regenesis做准备。Starknet的Regenesis计划是在几个月前发布的，它的重点是从基于Cairo0的系统过渡到基于Cairo1.0的系统。
在过渡期间，现有的Cairo0合约(如果它们是可升级的)有机会维护它们的地址和存储，并无缝地将它们的实现过渡到Cairo1.0(请参阅下一节)。
作为一个Starknet用户，这意味着你只需要在你的账户的新Cairo1.0实现发布时升级你的钱包(你可以在任何时间升级到Regenesis本身)。预计不会出现停机，系统中的所有dapp将继续正常运行。
在Regenesis之后，Starknet将在整个系统中停止支持剩余的Cairo0合约。这将提前进行沟通，开发者将有足够的时间来迁移他们的合约。预计过渡期将持续几个月，dapp开发人员已经可以开始将他们的实现迁移到Cairo1.0。在过渡时期结束时，Regenesis将会启动。
顺利迁移至Cairo1.0
随着向Cairo1.0过渡，现有的Cairo0合约将被弃用，并且在Regenesis时将不再受支持。为了允许可升级的Cairo0合约继续运行，并保持构建状态，我们添加了一个新的系统调用-'replace_class'。可升级的合约升级到Cairo1.0没有问题，但是底层代理(持有实际状态的合约)将仍然停留在Cairo0。'replace_class'系统调用通过允许代理合约替换其底层类来解决这个问题，即保持相同的地址和存储，但替换实现。
计算成本便宜了5倍!
目前，Starknet的交易费用有两个主要组成部分:计算和链上数据。Starknet交易费用的计算元素是由在L1上验证其证明的边际成本决定的(详情请参阅文档)。
最初，我们认为2亿Cairo合约证明步骤需要500万Gas验证，这导致我们天真的以为Cairo每个合约步骤需要0.05Gas。自此，我们转向递归证明，这将大幅减少L1验证成本(只有递归树的根到达L1)。现在是时候更新我们原来的估算了-L2上的每个合约步骤成本将降低5倍，现在将花费0.01Gas。
这种成本的降低对于计算密集型应用程序来说意义重大，例如具有非本地签名的帐户合约。简单交易的成本会略有降低(约5%)。在未来的版本中，我们将处理第二个组件:链上数据成本。一旦Starknet(又名Volition)引入链上数据的替代方案，将全面实现成本降低。
Starknet治理首次投票
Starknet治理的第一阶段已经启动(更多细节在这里)。社区成员现在可以通过一个额外的渠道，即对协议更改进行投票，参与优化Starknet。
Starknet治理第一阶段将集中于Starknet协议升级。每一次Starknet版本升级都将首先部署在测试网上;投票者将有6天的时间来检查和测试在Goerli上运行的升级版本。在此期间，将开放一个Snapshot提案，社区可以投票决定是否批准主网部署新版本。
如果提案在6天的投票期间获得多数“赞成”票，则提案通过，Starknet主网将相应升级。
Starknetalphav0.11.0是Starknet第一个进行投票的版本。Starknetalphav0.11.0的投票将从测试网部署开始时计算，开放6天。
Cairo1.0和Sierra
Sierra是一种可以编译为Cairo字节码(CASM)的中间表示层。在Starknetalphav0.11.0之前，开发者会将Cairo0编译到CASM中，并将结果发送到Starknet测序器。在Cairo1.0中，开发者将其代码编译到Sierra，并将这个中间表示发送到排序器。随后，定序器将其编译到CASM。Sierra被保证编译为“安全的CASM”，即CASM的一个子集，它不会失败，每一次执行都是可证明的。这保证了排序器将能够收取费用，即使是恢复的交易，防止DOS。有关更多信息，请参阅文档。
Starknetalpha0.11.0将使用Cairo1.0alpha.6版本。该版本接近Cairo0的特性，所有的Starknet系统调用都已经存在。
请注意，Starknet排序器使用固定的编译器版本，这意味着语言改进可能不会立即在Starknet中可用，只有在Starknet版本更新后才可用。具体来说，虽然影响Cairo1.0→Sierra编译的改进可能会立即生效，但Sierra→CASM编译器的更改(更多细节请参阅文档)只会在等待Starknet升级后才会更新。
还有什么新进展?
新交易类型-Declarev2
我们为Cairo1.0类添加了一个新的交易类型。这个新的'declare'交易版本类似于现有的'declare'，但有两个重要的区别:
现在发送的类对象表示Sierra而不是CASM，即类的语义由Sierra表示定义。
用户还对编译后的类哈希进行签名。在Sierra→CASM编译被证明是Starknet操作系统的一部分之前，这是至关重要的一步。
要了解更多细节，请参阅文档。
从开发者的角度来看，体验还是一样的。编写完Cairo1.0代码后，可以使用CLI声明该类。
请注意，最初，'declarev2'交易将不被Starknet主网接受。在测试网上试用一段时间后，新的交易类型将在主网上启用，Cairo1.0类也将可用。
Poseidon来了
Poseidon是一个系列哈希函数，设计用于非常有效的代数电路。因此，它们可能在ZK证明系统(如stark和SNARKs)中非常有用。从Starknetalphav0.11.0开始，开发者将能够使用Poseidon。此外，作为Starknet协议一部分的一些哈希计算将过渡到Poseidon(具体来说，类哈希，编译类哈希，以及部分状态承诺将使用Poseidon，详情请参阅文档)。在未来，更多的内部组件将过渡到使用Poseidon哈希函数。
在Starknet中使用的确切版本和参数可以在这里找到。
各种各样的变化
像之前的Starknet版本一样，升级也会对我们的api和其他低级组件产生影响。下面我们列出了这些，并说明了所做的具体更改:
●?不再支持v0调用/发起交易
●?L1→L2消息现在需要费用。也就是说，Starknetsequencer不会处理零费用发送的消息
●?链上数据格式改变
●?API更改：
●?添加了一个新的`get_compiled_class_by_class_hash`端点
●?`get_class_by_hash`返回Cairo0/Cairo1.0类
●?`get_state_update`有一个用于替换类的新部分，并且声明分为Cairo0和Cairo1类。
●?`estimate_fee`和`simulate_tx`现在可以跳过验证
●?新的StarknetJSON-RPC版本
接下来会发生什么?
现在所有与Cairo1.0相关的基础设施都已就绪，你可以期待:
对Cairo1.0语言的进一步改进；
性能改进：正如承诺的那样，我们继续朝着显著提高TPS的方向前进。路线图中的下一步是过渡到Rust序列器，它是在Apache2.0许可下开发的。新的排序器将使用RustCairoVM和Papyrus全节点，形成性能三重奏；
OffchainDA!在该版本中，我们处理了交易成本的计算组件。在即将推出的版本中，我们将处理链上数据成本，这是目前平均交易的主要成本。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。