
Starknet 春季 DeFi 激励计划
原文:Starknet Foundation Introduces: The Start of DeFi Spring 翻译及校对:「Starknet 中文社区」 📑 转载请注明出处 🕹️精选速览「Starknet 春季 DeFi 激励计划」4000 万 STRK 奖励用户3 月 7 日开始领取激励生态任务获得专属 NFT引言2023 年 11 月 9 日,Starknet 基金会宣布 Starknet DeFi 委员会成立及其成员任命,该委员会的任务是促进 Starknet DeFi 增长。 经过两个月的内部和外部研究后,Starknet 基金会非常兴奋地宣布推出为实现这些目标而量身定做的计划。 Starknet 基金会与 OpenBlock Labs 的合作,推出「Starknet 春季 DeFi 激励计划」。本为期六到八个月的项目,在此期间将向参与 Starknet 上 DeFi 协议的参与者分发 4000 万 STRK。 这是 DeFi 委员会扩大 Starknet DeFi 规模系列举措的第一步。第一部分:STRK 分发DeFi 委员会计划在接下来的六到八个月内,D...

Starknet 中文社区 2023 年终汇总
🎀 概述关注回顾 Starknet 在 2023 年的里程碑事件以及「Starknet 中文社区」的丰硕成果。 在网络生态中,Starknet 实现了一系列重要版本和重要事件更新,不仅在技术上取得了显著进展,而且扩展了众多核心开源技术栈。在生态系统中,推进发展 Starknet 优秀项目,在 TVL 和用户量等数据方面实现了可观增长。 「Starknet 中文社区」在过去一年中同样达成令人瞩目的进步,输入内容包括博客翻译、原创文章和视频、组织各类活动、合作 Cairo 训练营等各类活动,这些重要内容显示出社区成员的积极贡献和创造力,以及中文社区的独特魅力,为中国用户提供更多全面了解 Starknet 区块链的方式。 StarkWare 和 Starknet 团队和生态合作伙伴的共同努力实现 Cairo 1.0 成功升级,而 Cairo 开发者数量在过去一年中取得了巨大增长,这一成就让更多区块链开发者看到了 Starknet 背后团队的技术实力,也从侧面反映出 Starknet 生态系统中合作伙伴的紧密协作。 总而言之,Starknet 和「Starknet 中文社区」在生态、技...

聚沙成塔:StarkWare 年度回顾
原文:From Milestones to Masterstrokes: StarkWare’s Year in Review 翻译及校对:「Starknet 中文社区」 📑 转载请注明出处 🕹️不论是现在还是将来,STARK 技术都被视为助力去中心化应用(dApps)在以太坊上实现扩展和繁荣的秘密武器。概要:Starknet 为复杂、高计算要求、创新型的 DeFi 平台、链上游戏、动态 NFT 等应用奠定了基础。Starknet 在所有 L2(以及一些 L1)中,持续拥有增长最快的开发者生态系统。StarkWare 在 2023 年开源了 Stone 证明器、Starknet 排序器和 Papyrus 全节点等关键元素。继续阅读,了解我们的亮点以及 2023 年 Starknet 生态系统的整体进展。去中心化和社区STARK 技术:达到新高度在以太坊上的创新开源时刻:为协议设定新标准Starknet 应用链社区参与和活动去中心化与社区扩展Starknet 上的游戏热潮由于 L1 在规模、用户体验和高成本等方面的限制,创建成功的链上游戏几乎是不可能实现的事情。但随着有效性 R...
「Starknet 中文」社区致力于 Starknet 在中文世界发展,提供最全生态资讯。

Starknet 春季 DeFi 激励计划
原文:Starknet Foundation Introduces: The Start of DeFi Spring 翻译及校对:「Starknet 中文社区」 📑 转载请注明出处 🕹️精选速览「Starknet 春季 DeFi 激励计划」4000 万 STRK 奖励用户3 月 7 日开始领取激励生态任务获得专属 NFT引言2023 年 11 月 9 日,Starknet 基金会宣布 Starknet DeFi 委员会成立及其成员任命,该委员会的任务是促进 Starknet DeFi 增长。 经过两个月的内部和外部研究后,Starknet 基金会非常兴奋地宣布推出为实现这些目标而量身定做的计划。 Starknet 基金会与 OpenBlock Labs 的合作,推出「Starknet 春季 DeFi 激励计划」。本为期六到八个月的项目,在此期间将向参与 Starknet 上 DeFi 协议的参与者分发 4000 万 STRK。 这是 DeFi 委员会扩大 Starknet DeFi 规模系列举措的第一步。第一部分:STRK 分发DeFi 委员会计划在接下来的六到八个月内,D...

Starknet 中文社区 2023 年终汇总
🎀 概述关注回顾 Starknet 在 2023 年的里程碑事件以及「Starknet 中文社区」的丰硕成果。 在网络生态中,Starknet 实现了一系列重要版本和重要事件更新,不仅在技术上取得了显著进展,而且扩展了众多核心开源技术栈。在生态系统中,推进发展 Starknet 优秀项目,在 TVL 和用户量等数据方面实现了可观增长。 「Starknet 中文社区」在过去一年中同样达成令人瞩目的进步,输入内容包括博客翻译、原创文章和视频、组织各类活动、合作 Cairo 训练营等各类活动,这些重要内容显示出社区成员的积极贡献和创造力,以及中文社区的独特魅力,为中国用户提供更多全面了解 Starknet 区块链的方式。 StarkWare 和 Starknet 团队和生态合作伙伴的共同努力实现 Cairo 1.0 成功升级,而 Cairo 开发者数量在过去一年中取得了巨大增长,这一成就让更多区块链开发者看到了 Starknet 背后团队的技术实力,也从侧面反映出 Starknet 生态系统中合作伙伴的紧密协作。 总而言之,Starknet 和「Starknet 中文社区」在生态、技...

聚沙成塔:StarkWare 年度回顾
原文:From Milestones to Masterstrokes: StarkWare’s Year in Review 翻译及校对:「Starknet 中文社区」 📑 转载请注明出处 🕹️不论是现在还是将来,STARK 技术都被视为助力去中心化应用(dApps)在以太坊上实现扩展和繁荣的秘密武器。概要:Starknet 为复杂、高计算要求、创新型的 DeFi 平台、链上游戏、动态 NFT 等应用奠定了基础。Starknet 在所有 L2(以及一些 L1)中,持续拥有增长最快的开发者生态系统。StarkWare 在 2023 年开源了 Stone 证明器、Starknet 排序器和 Papyrus 全节点等关键元素。继续阅读,了解我们的亮点以及 2023 年 Starknet 生态系统的整体进展。去中心化和社区STARK 技术:达到新高度在以太坊上的创新开源时刻:为协议设定新标准Starknet 应用链社区参与和活动去中心化与社区扩展Starknet 上的游戏热潮由于 L1 在规模、用户体验和高成本等方面的限制,创建成功的链上游戏几乎是不可能实现的事情。但随着有效性 R...
「Starknet 中文」社区致力于 Starknet 在中文世界发展,提供最全生态资讯。
Share Dialog
Share Dialog

Subscribe to Starknet 中文

Subscribe to Starknet 中文


<100 subscribers
<100 subscribers
与 L1 不同,有效性证明 Rollup 吞吐量不受限制。L2 有效性证明 Rollup 上可以产生更高的 TPS
StarkNet 性能路线图解决了系统中一个关键要素:排序器(sequencer)
性能改进路线图如下:
— 排序器并行化
— Cairo 虚拟机用 Rust 实现
— 排序器用 Rust 重新实现
经过实战考验的证明器并不是瓶颈,处理量可以比现在更多!
StarkNet 大约在一年前登上主网,团队一开始专注于功能性,而现在重点转移到了提高性能上,通过一系列步骤来提升 StarkNet 用户体验。
在这篇文章中,将解释为什么只有有效性证明 Rollup 可以有广泛优化空间,并分享在 StarkNet 上实施这些优化的计划。其中一些已在 StarkNet Alpha 0.10.2 中实现,该版本于 11 月 16 日上线测试网,并在 11 月 28 日上线主网。那么在讨论解决方案之前,先来回顾一下性能的限制及其原因吧。
提高区块链可扩展性和 TPS 的一种潜在方式是取消区块限制(在 gas 或区块大小方面),同时保持出块时间不变。对生产区块者(L1 上的验证器和 L2 上的排序器)和组件性能要求更高。为此,现在团队的开发重点转移到优化 StarkNet 排序器上,下文将对此部分进行更详细的描述。
这里自然还会出现一个问题。为什么排序器优化仅限于有效性证明 Rollup?换句话说,为什么不能就在 L1 上优化,非要费事部署有效性证明 Rollup?在下一小节中,将阐述两者之间的根本区别,解释为什么可以在 L2 上进行广泛优化,而在 L1 不适用。
如果解除 L1 的区块限制,将会有个严重的问题。提高区块链的吞吐增长率,也会提高对全节点的需求,来保证跟进最新的状态。由于 L1 全节点必须重新执行所有的历史记录,区块大小的大幅增加(就 gas 而言)会带来巨大压力,再次导致较弱的机器退出系统,并将运行完整节点的能力留给足够强大的实体。结果就是,用户无法自己验证状态,也不能无需信任地参与网络。
所以应该限制 L1 吞吐量以维护真正去中心化和安全的系统。
只有从全节点的角度考虑,我们才能看到有效性证明 Rollup 的真正实力。L1 全节点需要重新执行整个历史记录以确保当前状态的正确性。而 StarkNet 节点只需要验证 STARK 证明,且这种验证所占用的计算资源呈指数级下降。特别是,从头开始同步不必涉及执行;节点可以从其他节点获取当前状态的转储,只需通过 STARK 证明来验证状态是否有效。这样就可以增加网络的吞吐量,而不增加全节点负载。
因此可以得出结论,优化 L2 排序器即是全方位提升系统性能,而在 L1 上是无法实现的。
下文将讨论 StarkNet 排序器优化计划。
路线图的第一步是将并行化引入交易执行,在 11 月 28 日上线主网的 StarkNet Alpha 0.10.2 中已引入。现在来深入了解下什么是并行化(这是个半技术性的部分,若要了解路线图,请跳到下一节)。
那么「交易并行化」是什么意思呢?简单来说,并行执行多个交易区块是不可能的,因为不同的交易可能是相互依赖的。下方示例中进行说明,假设有一个区块包含来自同一用户的三笔交易:
交易 A:将 USDC 兑换为 ETH
交易 B:用 ETH 购买某个 NFT
交易 C:将 USDT 兑换为 BTC
显然,交易 A 必须在交易 B 之前发生,但交易 C 完全独立所以可以并行执行。如果每执行一笔交易需要 1 秒时间,那么引入并行化后,出块时间就可以从 3 秒减少到 2 秒。
问题的症结所在是事先并不知道交易的依赖关系。实际上,只有当执行交易 B 时,才能知道它依赖于交易 A 所做的更改。更正式一点的说法是,这种依赖性源于交易 B 从交易 A 写入的存储单元中读取的事实。可以把交易看作一个依赖图,从交易 A 到交易 B 有一个边界,仅当 A 写入以一个由 B 读取的存储单元时,交易 B 才可以执行。下图显示了这种依赖图的一个示例:

在上面这个示例中,每一列都可以并行执行,这是最佳安排(一般会按顺序执行交易 1-9)。
为克服事先不知道依赖图这一难题,团队根据 Aptos Labs 开发的 BLOCK-STM 为 StarkNet 排序器引入了乐观并行化(optimistic parallelization)。在此范式下,系统将乐观地尝试并行执行交易,在发现冲突时重新执行。例如,并行执行图中的交易 1-4 时,会发现交易 4 依赖于交易 1。因此,它的执行是无效的(尽管执行交易 4 需要依照交易 1 执行后的状态,但先尝试对照交易 1 相同的状态同步执行)。在这种情况下,将重新执行交易 4。
请注意,乐观并行还有许多可优化之处。比如,不是单纯等待每次执行结束再判断,而是可以在发现有无效交易依赖项时中止执行。
另一个可以优化的例子是选择哪些交易来重新执行。假设上图中所有交易打包进一个区块送入 5 核 CPU 的排序器。首先尝试并行执行交易 1-5,如果完成顺序是交易2、交易 3、交易 4、交易 1,最后是交易 5,那么只有在交易 4 已经执行完之后,才会发现交易 4 依赖于交易 1,此时应重新执行。一般可能会想也重新执行交易 5,因为考虑到重新执行交易 4 可能会导致交易 5 的行为有所不同。然后,遍历执行已终止的交易所构建的依赖图,可以发现只需重新执行依赖于交易 4 的交易,而不是仅仅交易 4 无效之后重新执行所有交易。
StarkNet 中的智能合约是用 Cairo 编写的,并在 Cairo 虚拟机中执行,说明可查阅 Cairo 白皮书。目前,排序器使用 Python 版 Cairo 虚拟机实现。为优化虚拟机的实现性能,开发团队正在用 Rust 重写虚拟机。感谢 Lambdaclass 的出色工作,他们是 StarkNet 生态系统中非常宝贵的团队,这项工作也很快就会取得成果。
虚拟机的 Rust 实现(cairo-rs)现在可以执行原生 Cairo 代码。下一步是处理智能合约的执行,并与 python 兼容的排序器集成,一旦与 cairo-rs 集成,排序器的性能有望得到显著提升。
从 python 转到 Rust 对性能的提升不仅限于 Cairo 虚拟机。除了上述改进之外,团队还计划用 Rust 重新开始写排序器。除了 Rust 的内部优势之外,还能从其他方面优化排序器。比如可以兼容 cairo-rs,无需负担 python-rust 的通信开销。也可以完全重新设计状态的存储和访问方式(现在是基于 Patricia-Trie 结构)。
在上文中还未提到有效性证明 Rollup 里最重要的原件 — 证明器。可以想象,作为可以说是架构中最为复杂的组件,证明器应该是性能瓶颈,因此也应该是优化的重点。但有趣的是,现在 StarkNet 的瓶颈是更加「标准」的组件。特别是有了递归证明,证明中的可容纳交易量比当前测试网和主网更高。事实上,StarkNet 区块与 StarkEx 交易一起得到有效的证明,后者有时会有数十万 NFT 的铸造事件。
为即将到来的 StarkNet 新版本中改进的 TPS 做好准备吧,敬请期待并行化、Rust 还有更多!
与 L1 不同,有效性证明 Rollup 吞吐量不受限制。L2 有效性证明 Rollup 上可以产生更高的 TPS
StarkNet 性能路线图解决了系统中一个关键要素:排序器(sequencer)
性能改进路线图如下:
— 排序器并行化
— Cairo 虚拟机用 Rust 实现
— 排序器用 Rust 重新实现
经过实战考验的证明器并不是瓶颈,处理量可以比现在更多!
StarkNet 大约在一年前登上主网,团队一开始专注于功能性,而现在重点转移到了提高性能上,通过一系列步骤来提升 StarkNet 用户体验。
在这篇文章中,将解释为什么只有有效性证明 Rollup 可以有广泛优化空间,并分享在 StarkNet 上实施这些优化的计划。其中一些已在 StarkNet Alpha 0.10.2 中实现,该版本于 11 月 16 日上线测试网,并在 11 月 28 日上线主网。那么在讨论解决方案之前,先来回顾一下性能的限制及其原因吧。
提高区块链可扩展性和 TPS 的一种潜在方式是取消区块限制(在 gas 或区块大小方面),同时保持出块时间不变。对生产区块者(L1 上的验证器和 L2 上的排序器)和组件性能要求更高。为此,现在团队的开发重点转移到优化 StarkNet 排序器上,下文将对此部分进行更详细的描述。
这里自然还会出现一个问题。为什么排序器优化仅限于有效性证明 Rollup?换句话说,为什么不能就在 L1 上优化,非要费事部署有效性证明 Rollup?在下一小节中,将阐述两者之间的根本区别,解释为什么可以在 L2 上进行广泛优化,而在 L1 不适用。
如果解除 L1 的区块限制,将会有个严重的问题。提高区块链的吞吐增长率,也会提高对全节点的需求,来保证跟进最新的状态。由于 L1 全节点必须重新执行所有的历史记录,区块大小的大幅增加(就 gas 而言)会带来巨大压力,再次导致较弱的机器退出系统,并将运行完整节点的能力留给足够强大的实体。结果就是,用户无法自己验证状态,也不能无需信任地参与网络。
所以应该限制 L1 吞吐量以维护真正去中心化和安全的系统。
只有从全节点的角度考虑,我们才能看到有效性证明 Rollup 的真正实力。L1 全节点需要重新执行整个历史记录以确保当前状态的正确性。而 StarkNet 节点只需要验证 STARK 证明,且这种验证所占用的计算资源呈指数级下降。特别是,从头开始同步不必涉及执行;节点可以从其他节点获取当前状态的转储,只需通过 STARK 证明来验证状态是否有效。这样就可以增加网络的吞吐量,而不增加全节点负载。
因此可以得出结论,优化 L2 排序器即是全方位提升系统性能,而在 L1 上是无法实现的。
下文将讨论 StarkNet 排序器优化计划。
路线图的第一步是将并行化引入交易执行,在 11 月 28 日上线主网的 StarkNet Alpha 0.10.2 中已引入。现在来深入了解下什么是并行化(这是个半技术性的部分,若要了解路线图,请跳到下一节)。
那么「交易并行化」是什么意思呢?简单来说,并行执行多个交易区块是不可能的,因为不同的交易可能是相互依赖的。下方示例中进行说明,假设有一个区块包含来自同一用户的三笔交易:
交易 A:将 USDC 兑换为 ETH
交易 B:用 ETH 购买某个 NFT
交易 C:将 USDT 兑换为 BTC
显然,交易 A 必须在交易 B 之前发生,但交易 C 完全独立所以可以并行执行。如果每执行一笔交易需要 1 秒时间,那么引入并行化后,出块时间就可以从 3 秒减少到 2 秒。
问题的症结所在是事先并不知道交易的依赖关系。实际上,只有当执行交易 B 时,才能知道它依赖于交易 A 所做的更改。更正式一点的说法是,这种依赖性源于交易 B 从交易 A 写入的存储单元中读取的事实。可以把交易看作一个依赖图,从交易 A 到交易 B 有一个边界,仅当 A 写入以一个由 B 读取的存储单元时,交易 B 才可以执行。下图显示了这种依赖图的一个示例:

在上面这个示例中,每一列都可以并行执行,这是最佳安排(一般会按顺序执行交易 1-9)。
为克服事先不知道依赖图这一难题,团队根据 Aptos Labs 开发的 BLOCK-STM 为 StarkNet 排序器引入了乐观并行化(optimistic parallelization)。在此范式下,系统将乐观地尝试并行执行交易,在发现冲突时重新执行。例如,并行执行图中的交易 1-4 时,会发现交易 4 依赖于交易 1。因此,它的执行是无效的(尽管执行交易 4 需要依照交易 1 执行后的状态,但先尝试对照交易 1 相同的状态同步执行)。在这种情况下,将重新执行交易 4。
请注意,乐观并行还有许多可优化之处。比如,不是单纯等待每次执行结束再判断,而是可以在发现有无效交易依赖项时中止执行。
另一个可以优化的例子是选择哪些交易来重新执行。假设上图中所有交易打包进一个区块送入 5 核 CPU 的排序器。首先尝试并行执行交易 1-5,如果完成顺序是交易2、交易 3、交易 4、交易 1,最后是交易 5,那么只有在交易 4 已经执行完之后,才会发现交易 4 依赖于交易 1,此时应重新执行。一般可能会想也重新执行交易 5,因为考虑到重新执行交易 4 可能会导致交易 5 的行为有所不同。然后,遍历执行已终止的交易所构建的依赖图,可以发现只需重新执行依赖于交易 4 的交易,而不是仅仅交易 4 无效之后重新执行所有交易。
StarkNet 中的智能合约是用 Cairo 编写的,并在 Cairo 虚拟机中执行,说明可查阅 Cairo 白皮书。目前,排序器使用 Python 版 Cairo 虚拟机实现。为优化虚拟机的实现性能,开发团队正在用 Rust 重写虚拟机。感谢 Lambdaclass 的出色工作,他们是 StarkNet 生态系统中非常宝贵的团队,这项工作也很快就会取得成果。
虚拟机的 Rust 实现(cairo-rs)现在可以执行原生 Cairo 代码。下一步是处理智能合约的执行,并与 python 兼容的排序器集成,一旦与 cairo-rs 集成,排序器的性能有望得到显著提升。
从 python 转到 Rust 对性能的提升不仅限于 Cairo 虚拟机。除了上述改进之外,团队还计划用 Rust 重新开始写排序器。除了 Rust 的内部优势之外,还能从其他方面优化排序器。比如可以兼容 cairo-rs,无需负担 python-rust 的通信开销。也可以完全重新设计状态的存储和访问方式(现在是基于 Patricia-Trie 结构)。
在上文中还未提到有效性证明 Rollup 里最重要的原件 — 证明器。可以想象,作为可以说是架构中最为复杂的组件,证明器应该是性能瓶颈,因此也应该是优化的重点。但有趣的是,现在 StarkNet 的瓶颈是更加「标准」的组件。特别是有了递归证明,证明中的可容纳交易量比当前测试网和主网更高。事实上,StarkNet 区块与 StarkEx 交易一起得到有效的证明,后者有时会有数十万 NFT 的铸造事件。
为即将到来的 StarkNet 新版本中改进的 TPS 做好准备吧,敬请期待并行化、Rust 还有更多!
No activity yet