StarkNet架构之L1-L2消息传递机制

2024-06-13 15:12

本文主要是介绍StarkNet架构之L1-L2消息传递机制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • StarkNet架构之L1-L2消息传递机制
    • L2 → L1消息
    • L2 → L1消息结构
    • L2 → L1消息哈希
    • L1 → L2消息
    • L1 → L2消息取消
    • L1 → L2报文费用
    • L1 → L2哈希
    • 额外资源

StarkNet架构之L1-L2消息传递机制

原文地址:https://docs.starknet.io/architecture-and-concepts/network-architecture/messaging-mechanism/

Starknet与L1互动的能力至关重要。消息传递是实现这种交互的机制。

例如,您可以在L2上执行计算并在L1上使用结果。

Starknet上的桥使用L1-L2消息传递机制。假设你想将代币从以太坊桥接到Starknet。您将代币存款到L1桥合约中,这会自动触发L2上相同代币的铸造。L1-L2消息传递的另一个很好的用例是Defi pooling。有关更多信息,请参阅https://www.starknet.io上的dApps。

请注意,消息传递机制是异步和非对称的。

  • 异步:您的合约代码,无论是Cairo还是Solidity,都不能等待在合约代码执行过程中的另一层上发送的消息的结果。
  • 不对称:从以太坊向Starknet发送消息,L1→L2,是由Starknet序列器完全自动化的,因此消息会自动传递到L2上的目标合约。然而,当从Starknet向以太坊发送消息时,L2→L1,序列器只发送消息的哈希值。然后,您必须使用L1上的交易手动使用该消息

这篇关于StarkNet架构之L1-L2消息传递机制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1057657

相关文章

通信系统网络架构_2.广域网网络架构

1.概述          通俗来讲,广域网是将分布于相比局域网络更广区域的计算机设备联接起来的网络。广域网由通信子网于资源子网组成。通信子网可以利用公用分组交换网、卫星通信网和无线分组交换网构建,将分布在不同地区的局域网或计算机系统互连起来,实现资源子网的共享。 2.网络组成          广域网属于多级网络,通常由骨干网、分布网、接入网组成。在网络规模较小时,可仅由骨干网和接入网组成

Linux系统稳定性的奥秘:探究其背后的机制与哲学

在计算机操作系统的世界里,Linux以其卓越的稳定性和可靠性著称,成为服务器、嵌入式系统乃至个人电脑用户的首选。那么,是什么造就了Linux如此之高的稳定性呢?本文将深入解析Linux系统稳定性的几个关键因素,揭示其背后的技术哲学与实践。 1. 开源协作的力量Linux是一个开源项目,意味着任何人都可以查看、修改和贡献其源代码。这种开放性吸引了全球成千上万的开发者参与到内核的维护与优化中,形成了

Spring中事务的传播机制

一、前言 首先事务传播机制解决了什么问题 Spring 事务传播机制是包含多个事务的方法在相互调用时,事务是如何在这些方法间传播的。 事务的传播级别有 7 个,支持当前事务的:REQUIRED、SUPPORTS、MANDATORY; 不支持当前事务的:REQUIRES_NEW、NOT_SUPPORTED、NEVER,以及嵌套事务 NESTED,其中 REQUIRED 是默认的事务传播级别。

响应式架构

介绍 响应式架构(Reactive Architecture)是一种面向服务和事件的系统设计方法,旨在提高系统的可扩展性、弹性和容错能力。它适用于构建分布式系统,特别是在云环境和微服务架构中。响应式架构的核心理念是通过事件驱动和数据流来实现各个组件之间的解耦,从而提高整个系统的响应能力和可靠性。 响应式架构的主要特点包括: 响应性:系统能够快速响应外部事件和内部变化,确保在各种负载和故障情

大型网站架构演化(六)——使用反向代理和CDN加速网站响应

随着网站业务不断发展,用户规模越来越大,由于中国复杂的网络环境,不同地区的用户访问网站时,速度差别也极大。有研究表明,网站访问延迟和用户流失率正相关,网站访问越慢,用户越容易失去耐心而离开。为了提供更好的用户体验,留住用户,网站需要加速网站访问速度。      主要手段:使用CDN和反向代理。如图。     使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速

大型网站架构演化(五)——数据库读写分离

网站在使用缓存后,使绝大部分数据读操作访问都可以不通过数据库就能完成,但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库,在网站的用户达到一定规模后,数据库因为负载压力过大而成为网站的瓶颈。      目前豆粉的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能,

大型网站架构演化(四)——使用应用服务器集群改善网站的并发能力

使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,不要企图去更换更强大的服务器,对大型服务器而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。 对网站架构而言,只要能通过增加一台服务器的方式改善负载压力,就可以以同样的方式持续增加服务器不断改善系统性能,从而实现系统

大型网站架构演化(二)——应用服务和数据服务分离

随着网站业务的发展,一台服务器逐渐不能满足需求:越来越多的用户访问导致性能越来越差,越来越多的数据导致存储空间不足。这时就需要将应用和数据分离。应用和数据分离后整个网站使用三台服务器:应用服务器、文件服务器和数据库服务器,如图。              这三台服务器对硬件资源的要求各不相同: 应用服务器需要处理大量的业务逻辑,因此需要更快更强大的CPU;

大型网站架构演化(一)——初始阶段的网站架构

大型网站的技术挑战主要来自于庞大的用户,高并发的访问和海量的数据,任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户,问题就会变得很棘手。大型网站架构主要是解决这类问题。         大型网站都是从小型网站发展而来,网站架构也是一样,是从小型网站架构逐步演化而来。小型网站最开始时没有太多人访问,只需要一台服务器就绰绰有余,这时的网站架构如图所示。

大型网站架构演化(总)

如果把上世纪90年代初CERN正式发布WEB标准和第一个WEB服务的出现当做互联网站的开始,那么互联网站的发展只经历了短短20多年的时间。在20多年的时间里,互联网的世界发生了巨大变化,今天,全球有近一半的人口使用互联网,人们的生活因为互联网而产生了巨大变化。从信息检索到即时通信,从电子购物到文化娱乐,互联网渗透到生活的每个角落,而且这种趋势还在加速。因为互联网,我们的世界正变得越来越小