Optimism 技术文档

저자 Optimism Collective · 2021

Optimism에는 전통적인 백서가 없습니다. 이더리움 Layer 2 옵티미스틱 롤업으로서, 설계 및 사양은 단일 공식 학술 논문이 아닌 기술 문서, OP Stack 사양, 연구 게시물을 통해 문서화되어 있습니다.

초록

이 백서는 트랜잭션 처리량과 노드를 실행하기 위한 하드웨어 요구 사항 간의 균형을 분석하여 분산형 blockchain의 확장성 문제를 해결합니다. 롤업, 즉 오프체인에서 실행되는 블록의 온체인 검증 기술은 오류 또는 유효성 증명의 형태로 제공됩니다. 출금 시간, 거래 비용, 최적화 기술 및 Ethereum 생태계와의 호환성과 관련하여 낙관적 롤업과 유효성 롤업을 비교합니다. 우리의 분석에 따르면 Optimism Bedrock의 가스 압축률은 현재 약 20:1인 반면 StarkNet의 스토리지 쓰기 비용 압축률은 약 24:1입니다. 또한 캐시 계약 및 Bloom 필터 사용과 같이 이러한 속도를 더욱 최적화하는 기술에 대해서도 논의합니다. 궁극적으로 우리의 결론은 낙관적 롤업과 유효성 롤업 간의 선택에서 복잡성과 민첩성 간의 균형을 강조합니다. 키워드 블록체인, 확장성, 롤업 1. 서론 블록체인 기술은 다양한 산업에 혁명을 일으킬 수 있는 잠재력으로 인해 큰 주목을 받고 있습니다. 그러나 대부분의 blockchain은 일반적으로 확장성 트릴레마[1, 2]라고 불리는 확장성, 분산화 및 보안 간의 균형에 직면하기 때문에 확장성은 여전히 ​​주요 과제로 남아 있습니다. blockchain의 처리량을 늘리기 위한 간단한 해결책은 블록 크기를 늘리는 것입니다. Ethereum의 맥락에서 이는 블록이 보유할 수 있는 최대 가스 양을 늘리는 것을 의미합니다. 각 풀 노드는 모든 블록의 모든 트랜잭션을 검증해야 하므로 처리량이 증가함에 따라 하드웨어 요구 사항도 증가하여 네트워크의 중앙 집중화가 더욱 강화됩니다. Bitcoin 및 Ethereum와 같은 일부 blockchain은 아키텍처 분산을 극대화하기 위해 설계를 최적화하는 반면, 바이낸스 스마트 체인 및 솔라나와 같은 다른 blockchain은 최대한 빠르고 저렴하도록 설계되었습니다. 분산형 네트워크는 네트워크에 참여하기 위한 하드웨어 요구 사항을 낮추기 위해 blockchain의 처리량을 인위적으로 제한합니다. 수년에 걸쳐 상태 채널 [3] 및 플라즈마[4, 5]와 같은 Trilemma에 대한 솔루션을 찾으려는 시도가 있었습니다. 이러한 솔루션은 일부 활동을 오프체인으로 이동하고, smart contracts를 사용하여 온체인 활동을 오프체인 활동에 연결하고, DLT 2023을 검증하는 특징을 가지고 있습니다: 제5차 분산 원장 기술 워크숍, 2023년 5월 25~26일, 이탈리아 볼로냐 $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 이 논문의 저작권은 저자에게 있습니다. Creative Commons License Attribution 4.0 International(CC BY 4.0)에 따라 사용이 허용됩니다. CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) 온체인에서 일어나는 일 오프체인에서 일어나는 일입니다. 그러나 플라즈마 및 상태 채널 모두 일반 smart contract 지원이 제한됩니다. 롤업은 자신의 블록을 다른 blockchain(Layer 1 또는 L1)에 게시하여 합의, 데이터 가용성 및 보안 속성을 상속하는 blockchain(Layer 2 또는 L2라고 함)입니다. 다른 솔루션과 달리 임의 계산을 지원합니다. 롤업에는 세 가지 주요 구성 요소가 있습니다. • 시퀀서: 사용자로부터 롤업 트랜잭션을 수신하고 이를 Layer 1로 전송되는 블록으로 결합하는 노드입니다. 블록은 최소한 상태 루트(예: Merkle 루트)와 상태를 재구성하고 검증하는 데 필요한 데이터로 구성됩니다. Layer 1은 다음을 정의합니다...

摘要

本文通过分析交易吞吐量和运行节点的硬件要求之间的权衡,解决了去中心化 blockchain 的可扩展性问题。 Rollups,即对链下执行的区块进行链上验证的技术,以故障或有效性证明的形式呈现。我们在提款时间、交易成本、优化技术以及与 Ethereum 生态系统的兼容性方面比较了乐观汇总和有效性汇总。我们的分析表明,Optimism Bedrock 目前的气体压缩率约为 20:1,而 StarkNet 的存储写入成本压缩率约为 24:1。我们还讨论了进一步优化这些速率的技术,例如缓存合约和布隆过滤器的使用。最终,我们的结论强调了在乐观汇总和有效性汇总之间选择时复杂性和敏捷性之间的权衡。关键词 区块链、可扩展性、Rollup 1. 简介 区块链技术因其彻底改变各个行业的潜力而受到广泛关注。然而,可扩展性仍然是一个重大挑战,因为大多数 blockchain 面临可扩展性、去中心化和安全性之间的权衡,通常称为可扩展性三难困境 [1, 2]。要增加 blockchain 的吞吐量,一个简单的解决方案是增加其块大小。在 Ethereum 的上下文中,这意味着增加一个区块可以容纳的最大气体量。由于每个全节点必须验证每个块的每笔交易,因此随着吞吐量的增加,硬件要求也会增加,从而导致网络更加集中。一些 blockchain,例如 Bitcoin 和 Ethereum,优化其设计以最大化其架构去中心化,而其他 blockchain,例如币安智能链和 Solana,则被设计为尽可能快速和便宜。去中心化网络人为地限制 blockchain 的吞吐量,以降低参与网络的硬件要求。多年来,人们一直在尝试寻找解决三难困境的方法,例如状态通道 [3] 和 Plasma [4, 5]。这些解决方案的特点是将一些活动移至链下,使用 smart contracts 将链上活动与链下活动链接起来,并验证 DLT 2023:第五届分布式账本技术研讨会,2023 年 5 月 25-26 日,意大利博洛尼亚 $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) Donno) 0000-0001-9221-3529 (L. Donno) © 2023 本文版权归其作者所有。根据 Creative Commons License Attribution 4.0 International (CC BY 4.0) 允许使用。 CEUR 研讨会论文集 http://ceur-ws.org ISSN 1613-0073 CEUR 研讨会论文集 (CEUR-WS.org) 链上发生的事情链下。然而,Plasma 和状态通道对通用 smart contract 的支持都是有限的。 Rollup 是 blockchain(称为 Layer 2 或 L2),它们在另一个 blockchain (Layer 1 或 L1)上发布其块,因此继承其共识、数据可用性和安全属性。与其他解决方案不同,它们支持任意计算。 Rollups 具有三个主要组件: • 定序器:从用户接收 Rollup 交易并将其组合成一个块并发送到 Layer 1 的节点。该块至少由状态根(例如 Merkle 根)和重建和验证状态所需的数据组成。 Layer 1 定义...

소개

  1. 소개 블록체인 기술은 혁명을 일으킬 수 있는 잠재력으로 인해 큰 주목을 받고 있습니다. 다양한 산업. 그러나 대부분의 blockchain이 직면한 것처럼 확장성은 여전히 주요 과제로 남아 있습니다. 일반적으로 확장성, 분산화, 보안 간의 균형을 유지합니다. 확장성 트릴레마 [1, 2]. blockchain의 처리량을 늘리기 위한 간단한 해결책은 다음과 같습니다. 블록 크기를 늘리려면 Ethereum의 맥락에서 이는 최대값을 늘리는 것을 의미합니다. 블록이 담을 수 있는 가스의 양. 각 전체 노드는 모든 거래의 유효성을 검사해야 하므로 블록, 처리량이 증가하면 하드웨어 요구 사항도 증가하므로 더 큰 문제가 발생합니다. 네트워크의 중앙화. Bitcoin 및 Ethereum과 같은 일부 blockchain는 Binance Smart와 같은 다른 사람들은 아키텍처 분산화를 극대화하도록 설계합니다. 체인과 솔라나는 최대한 빠르고 저렴하게 설계되었습니다. 분산형 네트워크 하드웨어 요구 사항을 낮추기 위해 blockchain의 처리량을 인위적으로 제한합니다. 네트워크에 참여합니다. 수년에 걸쳐 국가와 같은 트릴레마에 대한 해결책을 찾으려는 시도가 있었습니다. 채널 [3] 및 플라즈마 [4, 5]. 이러한 솔루션은 일부 활동을 이동시키는 특성을 가지고 있습니다. 오프체인, smart contracts를 사용하여 온체인 활동을 오프체인 활동에 연결하고 확인 DLT 2023: 제5회 분산 원장 기술 워크숍, 2023년 5월 25~26일, 이탈리아 볼로냐 $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. 도노) 0000-0001-9221-3529 (L. 돈노) © 2023 본 논문의 저작권은 해당 저자에게 있습니다. Creative Commons License Attribution 4.0 International(CC BY 4.0)에 따라 사용이 허용됩니다. CEUR 워크숍 절차 http://ceur-ws.org ISSN 1613-0073 CEUR 워크숍 진행(CEUR-WS.org)온체인에서 오프체인에서 무슨 일이 일어나고 있는지. 그러나 플라즈마와 상태 채널은 모두 제한되어 있습니다. 일반적인 smart contract에 대한 지원. 롤업은 다른 blockchain에 블록을 게시하는 blockchain(Layer 2 또는 L2라고 함)입니다. (Layer 1 또는 L1)이므로 합의, 데이터 가용성 및 보안 속성을 상속합니다. 그들은, 다른 솔루션과 달리 임의 계산을 지원합니다. 롤업에는 세 가지 주요 구성요소가 있습니다. • 시퀀서: 사용자로부터 롤업 트랜잭션을 수신하고 이를 하나의 노드로 결합하는 노드입니다. Layer 1로 전송되는 블록입니다. 블록은 최소한 상태 루트(예: Merkle 루트) 및 상태를 재구성하고 검증하는 데 필요한 데이터입니다. Layer 1은 게시된 데이터의 순서를 설정하여 L2의 표준 blockchain입니다. • 롤업 전체 노드: 레이어에서 롤업 블록을 획득, 처리 및 검증하는 노드
  2. 루트가 올바른지 확인합니다. 블록에 유효하지 않은 거래가 포함된 경우 이는 시퀀서가 유효하지 않은 블록을 포함하는 유효한 블록을 생성하는 것을 방지합니다. 거래. • 롤업 라이트 노드: Layer 1에서 롤업 블록을 얻지만 계산하지 않는 노드 새로운 국가 그 자체. 기술을 사용하여 새로운 상태 루트가 유효한지 확인합니다. 결함이나 타당성 증명과 같은 것입니다. 롤업은 거래의 상각 비용을 숫자만큼 줄여 확장성을 달성합니다. 사용자가 증가합니다. 이는 blockchain 유효성을 보장하는 비용이 준선형적으로 증가하기 때문입니다. 거래를 개별적으로 확인하는 데 드는 비용과 관련하여. 롤업은 다음에 따라 다릅니다. 라이트 노드에서 트랜잭션 실행의 유효성을 보장하는 메커니즘: 낙관적 롤업은 경제 모델과 결함 증명을 통해 보장되지만 유효성은 유지됩니다. 롤업은 유효성 증명을 사용하여 암호화 방식으로 보장됩니다. 라이트 노드는 Layer 1에서 smart contracts로 구현될 수 있습니다. 그들은 근본 원인을 받아들인다. 새로운 상태 및 유효성 또는 결함 증명 확인: 따라서 이러한 롤업을 스마트 계약이라고 합니다. 롤업. 라이트 노드가 독립적인 경우 소버린 롤업(Sovereign Rollup) [6]이라고 합니다. 장점 스마트 계약 롤업을 사용하면 둘 사이에 신뢰가 최소화된 브리지를 구축할 수 있습니다. blockchains: L2 상태의 유효성이 L1에 입증되었으므로 트랜잭션 시스템은 L2~L1을 구현하여 출금이 가능합니다. 단점은 제작비용이 트랜잭션은 L1의 상태를 확인하는 비용에 따라 달라집니다. 기본 레이어가 다음으로 포화된 경우 다른 활동으로 인해 롤업 거래 비용도 증가합니다. 데이터 및 합의 계층은 다음과 같이 시스템의 보안을 결정하는 계층입니다. 트랜잭션 순서를 정의하고, 공격을 방지하며, 상태를 증명할 수 있는 데이터를 제공합니다. 유효성. 논문 투고 본 논문에서는 혁신적인 두 가지 롤업인 낙관적 롤업과 유효성 롤업을 연구합니다. Optimism Bedrock 및 StarkNet와 같은 주목할만한 구현에 중점을 둔 확장성 트릴레마에 대한 솔루션입니다. 우리의 기여에는 다음 사항에 대한 포괄적인 비교가 포함됩니다. 솔루션, 철수 시간 분석 및 Optimism에 대한 가능한 공격에 대한 논의 기반암. 또한 가스 압축 비율을 계산하고, 애플리케이션별 최적화를 제공하며, Ethereum에서 벗어날 때의 장점과 단점을 제시합니다. 가상 머신(EVM).

종이 구조 논문은 다음과 같이 구성되어 있습니다. 섹션 2 낙관적 롤업은 다음과 같습니다. Optimism Bedrock을 분석하여 소개되었습니다. 섹션 3에서 유효성 롤업은 다음과 같이 소개됩니다. StarkNet을 분석 중입니다. 섹션 4에서는 두 솔루션을 비교합니다. 마지막으로 5장에서 그림을 그립니다. 몇 가지 결론.

介绍

一、简介 区块链技术因其革命性的潜力而受到广泛关注 各个行业。然而,可扩展性仍然是一个重大挑战,因为大多数 blockchain 都面临着 可扩展性、去中心化和安全性之间的权衡,通常称为 可扩展性三难困境 [1, 2]。为了提高 blockchain 的吞吐量,一个简单的解决方案是 增加其块大小。在 Ethereum 的上下文中,这意味着增加最大值 一个区块可以容纳的气体量。由于每个全节点必须验证每个交易的每笔交易 块,随着吞吐量的增加,硬件要求也增加,导致更大的 网络的集中化。一些 blockchain,例如 Bitcoin 和 Ethereum,优化了它们的 设计以最大化其架构去中心化,而其他人,例如 Binance Smart Chain 和 Solana 的设计目标是尽可能快速且便宜。去中心化网络 人为地限制 blockchain 的吞吐量,以降低硬件要求 参与网络。 多年来,人们一直在尝试寻找解决三难困境的方法,例如国家 通道 [3] 和 Plasma [4, 5]。这些解决方案具有移动某些活动的特点 链下,使用 smart contracts 将链上活动链接到链下活动,并验证 DLT 2023:第五届分布式账本技术研讨会,2023 年 5 月 25-26 日,意大利博洛尼亚 $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529(L.唐诺) © 2023 本文版权归作者所有。根据 Creative Commons License Attribution 4.0 International (CC BY 4.0) 允许使用。 欧洲欧元区 车间 会议记录 http://ceur-ws.org ISSN 1613-0073 CEUR 研讨会论文集 (CEUR-WS.org)链上正在发生链下的事情。然而,Plasma 和状态通道都受到限制 他们对 smart contract 将军的支持。 Rollup 是 blockchain(称为 Layer 2 或 L2),它们在另一个 blockchain 上发布其块 (Layer 1 或 L1),因此继承其共识、数据可用性和安全属性。他们, 与其他解决方案不同,支持任意计算。 Rollup 具有三个主要组件: • 排序器:从用户接收 Rollup 交易并将其组合成一个 发送到 Layer 1 的块。该块至少包含状态根(例如 Merkle root)以及重建和验证状态所需的数据。 Layer 1 定义 通过建立已发布数据的排序来规范 L2 的 blockchain 。 • Rollup全节点:从Layer获取、处理和验证Rollup块的节点 1、验证root是否正确。如果一个区块包含无效交易,那么 丢弃,这会阻止定序器创建包含无效块的有效块 交易。 • Rollup轻节点:从Layer 1获取Rollup块但不计算的节点 新国家本身。他们使用技术验证新的状态根是否有效 例如错误或有效性证明。 Rollups 通过将交易的摊余成本降低为数量来实现可扩展性 用户数量增加。这是因为确保 blockchain 有效性的成本呈次线性增长 关于单独验证交易的成本。汇总根据不同而不同 他们确保轻节点交易执行有效性的机制: Optimistic Rollups 通过经济模型和故障证明来保证,同时保持有效性 Rollups 使用有效性证明以加密方式确保。 轻节点可以在 Layer 1 上实现为 smart contracts。他们接受事物的根源 新状态并验证有效性或故障证明:因此这些 Rollup 称为智能合约 卷起。如果轻节点是独立的,则它们被称为主权卷[6]。优点 使用智能合约 Rollup 是为了能够在两者之间建立信任最小化的桥梁 blockchains:由于 L2 状态的有效性已向 L1 证明,因此交易系统 可以实现L2到L1,允许提现。缺点是成本较高 交易取决于验证 L1 状态的成本:如果基础层饱和 其他活动中,Rollup 上的交易成本也会增加。 数据层和共识层决定了系统的安全性 他们定义交易的顺序,防止攻击并提供数据来证明状态 有效性。 论文贡献 在本文中,我们研究了乐观和有效性汇总,这两个创新 可扩展性难题的解决方案,重点关注值得注意的实现,例如 Optimism Bedrock 和 StarkNet。我们的贡献包括对这些的全面比较 解决方案、提现时间分析以及对 Optimism 可能的攻击的讨论 基岩。此外,我们还计算它们的气体压缩比,提供特定于应用的优化,并介绍放弃 Ethereum 的优点和缺点 虚拟机 (EVM)。

纸张结构 本文的结构如下。在第 2 节中,乐观汇总是 通过分析 Optimism 基岩引入。在第 3 节中,有效性汇总由 分析 StarkNet。在第 4 节中,我们比较了这两种解决方案。最后,在第 5 节中我们绘制 一些结论。

낙관적 롤업

  1. 낙관적 롤업 실행을 검증하지 않고 블록의 출력을 낙관적으로 받아들이는 아이디어는 다음과 같습니다. 라이트 노드에 대해 논의하는 Bitcoin 백서 [7]에 이미 나와 있습니다. 이 노드는 다음과 같습니다. 합의 규칙을 검증하여 헤더 체인을 블록 수용에 취약하게 만듭니다. 51% 공격이 발생한 경우 유효하지 않은 거래가 포함됩니다. 나카모토는 이 문제를 해결할 것을 제안합니다. 문제는 블록에 유효하지 않은 트랜잭션이 포함되어 있음을 라이트 노드에 경고하는 "경고" 시스템을 사용하는 것입니다. 이 메커니즘은 Al-Bassam, Sonnino 및 Buterin [8]에 의해 처음 구현되었습니다. 오류 수정 코드 [9]을 기반으로 한 증명 시스템이 사용됩니다. 생성이 가능하도록 하기 위해 결함 방지를 위해서는 유효하지 않은 블록을 포함한 모든 블록의 데이터를 사용할 수 있어야 합니다. 네트워크: 이것은 확률적 데이터를 사용하여 해결되는 데이터 가용성 문제입니다. 샘플링 메커니즘. 최초의 낙관적 롤업 디자인은 John Adler가 발표했으며 2019년 Mikerah Quintyne-Collins [10], 블록이 다른 blockchain에 게시됨 이는 주문에 대한 합의를 정의합니다. 2.1. Optimism 기반암 Bedrock [11]은 스마트 계약 롤업인 Optimism의 최신 버전입니다. 이전 버전, OVM(Optimistic Virtual Machine)은 Solidity를 자체 버전으로 컴파일하기 위해 임시 컴파일러가 필요했습니다. 자체 바이트 코드: 대조적으로 Bedrock은 실행 엔진이 EVM과 완전히 동일합니다. Ethereum Yellow Paper 사양 [12]을 따릅니다. 2.1.1. 예금 사용자는 Ethereum, Optimism 포탈의 컨트랙트를 통해 예금거래 기능을 호출하여 거래를 입금할 수 있습니다. 트랜잭션이 실행되면, Rollup의 각 노드가 처리를 위해 수신 대기하는 TransactionDeposited 이벤트가 발생합니다. 예금. 입금된 트랜잭션은 L1에서 파생된 L2 트랜잭션입니다. 전화를 건 사람이 함수는 계약이므로 주소는 상수 값을 추가하여 변환됩니다. L1 계약의 주소는 L2 계약과 동일하지만 코드가 다른 공격입니다. 예치된 트랜잭션의 L2 포함은 시퀀스 내의 사양에 의해 보장됩니다. 창. 예치된 거래는 접두사가 0x7E인 새로운 EIP-2718 호환 거래 유형 [13]입니다. 여기서 rlp로 인코딩된 필드는 다음과 같습니다. • bytes32 sourceHash: hash 트랜잭션 소스를 고유하게 식별합니다. • 주소 보낸 사람: 보낸 사람의 주소입니다. • 주소: 수신자 주소 또는 입금된 거래가 다음인 경우 0 주소입니다. 계약 생성.• uint256 mint: L2에 생성될 값입니다. • uint256 value: 수신자에게 전송될 값입니다. • 바이트 데이터: 입력 데이터입니다. • bytes gasLimit: 트랜잭션의 가스 한도입니다. sourceHash는 L1 블록 hash의 keccak256 hash과 L1 로그로 계산됩니다. 블록의 이벤트를 고유하게 식별하는 인덱스입니다. 입금된 트랜잭션은 L1에서 시작되지만 L2에서 실행되므로 시스템에는 L2에 소비된 가스에 대해 L1에 지불하는 메커니즘입니다. 한 가지 해결책은 포털을 통해 ETH를 보내는 것입니다. 그러나 이는 모든 발신자(간접 발신자 포함)가 지불 대상으로 표시되어야 함을 의미하며 이는 많은 기존 프로젝트에서는 불가능합니다. 대안은 L1에서 해당 가스를 연소하는 것입니다. 입금된 거래에 할당된 가스𝑔를 보장가스라고 합니다. L2 가스 가격은 L1은 자동으로 동기화되지 않지만 EIP-1559와 유사한 메커니즘을 사용하여 추정됩니다. [14]. Ethereum 블록당 보장되는 최대 가스량은 800만 개이며, 목표는 다음과 같습니다. 200만. L2의 가스 비용을 지불하는 데 필요한 ETH의 수량 𝑐은 𝑐= 𝑔𝑏L2입니다. 여기서 𝑏L2는 L2의 기본 수수료. L1 계약은 𝑐/𝑏L2에 해당하는 양의 가스를 소모합니다. 통화에 소비된 가스 예금 거래는 L2에서 상환됩니다. 이 금액이 보장된 가스보다 큰 경우, 가스가 연소되지 않습니다. rollup 블록의 첫 번째 트랜잭션은 등록하는 데 사용되는 L1 속성 예치 트랜잭션입니다. L2에서는 Ethereum 블록의 속성을 사전 배포합니다. 사전 배포가 제공하는 속성 액세스 권한은 블록 번호, 타임스탬프, 기본 수수료, 블록 hash 및 시퀀스입니다. number는 연관된 L1 블록에 대한 L2의 블록 번호입니다(epoch라고도 함). 이 숫자는 새로운 시대가 시작되면 재설정됩니다. 2.1.2. 시퀀싱 롤업 노드는 Ethereum에서 완전히 Optimism 체인을 파생합니다. 이 체인은 확장되었습니다 L1에 새로운 트랜잭션이 게시될 때마다 해당 블록이 재구성됩니다. Ethereum 블록이 재구성되었습니다. 롤업 blockchain은 여러 시대로 구분됩니다. 각 𝑛에 대해 Ethereum의 블록 번호에 해당하는 𝑛epoch가 있습니다. 각 시대에는 최소한 하나의 시대가 포함됩니다. 블록이며, 한 시대의 각 블록에는 L1 속성 예치 트랜잭션이 포함됩니다. 첫 번째 블록 한 시대에는 포털을 통해 입금된 모든 거래가 포함됩니다. Layer 2 블록은 또한 순차 트랜잭션이 포함되어 있습니다. 즉, 시퀀서로 직접 전송되는 트랜잭션입니다. Sequencer는 사용자의 트랜잭션을 수락하고 블록을 구축합니다. 각 블록마다 구성됩니다. Ethereum에 게시될 배치입니다. 여러 배치를 압축된 방식으로 게시할 수 있습니다. 이름 채널을 복용. 채널이 너무 큰 경우 여러 프레임으로 나눌 수 있습니다. 단일 거래. 채널은 rlp로 인코딩된 ZLIB [15]을 사용한 압축으로 정의됩니다. 배치. 배치의 필드는 에포크 번호, 에포크 hash, 상위 hash, 타임스탬프와 거래 목록. 에포크로 식별되는 시퀀싱 윈도우에는 고정된 수의 연속 L1 𝑤이 포함됩니다. 파생 단계에서 가변 개수의 L2 블록을 구성하기 위해 입력으로 사용하는 블록입니다. 에 대한 epoch 𝑛, 시퀀싱 창 𝑛에는 블록 [𝑛, 𝑛+𝑤)이 포함됩니다. 이는 주문을 의미합니다. 시퀀싱 윈도우 내의 L2 트랜잭션 및 블록 수는 해당 윈도우가 끝날 때까지 수정되지 않습니다. rollup 트랜잭션이 포함된 배치가 L1에서 확인된 경우 안전하다고 합니다. 프레임L1 블록에서 읽어 배치를 재구성합니다. 현재 구현에서는 다음을 허용하지 않습니다. 모든 해당 프레임이 수신될 때까지 채널의 압축 해제가 시작됩니다. 유효하지 않음 배치는 무시됩니다. 개별 블록 트랜잭션은 배치에서 획득됩니다. 상태 전환을 적용하고 롤업 상태를 얻기 위해 실행 엔진에서 사용됩니다. 2.1.3. 인출 인출을 처리하기 위해 L2-to-L1 메시징 시스템이 구현됩니다. Ethereum 인출을 수락하려면 L2의 상태를 알아야 하며 이는 게시를 통해 수행됩니다. L2 출력 Oracle smart contract on L1 각 L2 블록의 상태 루트. 이들 뿌리 오류 증명이 수행되는 동안 오류가 수행되지 않으면 낙관적으로 유효(또는 최종)된 것으로 받아들여집니다. 분쟁기간. 제안자로 지정된 주소만 출력 루트를 게시할 수 있습니다. 타당성 제안자가 삭감된 지분을 예치하도록 함으로써 생산량 루트에 대한 인센티브가 부여됩니다. 잘못된 루트를 제안한 것으로 나타났습니다. 트랜잭션은 함수를 호출하여 시작됩니다. L2의 사전 배포에서 Withdrawal을 시작한 다음 함수를 호출하여 L1에서 마무리했습니다. 앞에서 언급한 Optimism 포털의 finalizeWithdrawalTransaction입니다. L2 블록에 해당하는 출력 루트는 L2 출력 Oracle에서 가져옵니다. 그것은이다 확정되었음을 확인합니다. 즉, 분쟁 기간이 경과했음을 확인합니다. 출력되는 것이 확인됩니다. 루트 증명은 Oracle 증명과 일치합니다. 출금의 hash이 포함된 것으로 확인됩니다 인출 증명을 사용하여; 철회가 아직 완료되지 않았습니다. 그리고 나서 지정된 가스 한도, Ether 양 및 데이터를 사용하여 대상 주소에 대한 호출이 실행됩니다. 2.1.4. 대포: 결함 방지 시스템 롤업 전체 노드가 로컬에서 일괄 처리 및 입금된 트랜잭션을 실행하여 다음을 발견한 경우 Layer 2 상태가 제안자가 체인에 게시한 상태 루트와 일치하지 않으면 실행할 수 있습니다. 블록 전환 결과가 잘못되었음을 증명하기 위해 L1에 대한 결함 증명. 때문에 오버헤드로 인해 L1에서 전체 Rollup 블록을 처리하는 데 비용이 너무 많이 듭니다. 구현된 솔루션 Bedrock은 minigeth의 불일치에 대한 첫 번째 지시만 온체인에서 실행합니다. 온체인 인터프리터에서 실행되고 게시되는 MIPS 아키텍처로 컴파일 L1에. minigeth는 합의, RPC 및 데이터베이스가 포함된 geth 1의 단순화된 버전입니다. 제거되었습니다. 불일치하는 첫 번째 명령을 찾기 위해 대화형 이진 검색이 다음 사이에서 수행됩니다. 결함 증명을 시작한 사람과 출력 루트를 게시한 사람입니다. 증명할 때 시작하면 양 당사자는 실행 중간에 MIPS 메모리 상태의 루트를 게시합니다. 챌린지 계약의 차단: hash이 일치하면 양 당사자가 다음에 동의한다는 의미입니다. 실행의 전반부는 후반부의 절반의 루트를 게시하고, 그렇지 않으면 절반을 게시합니다. 상반기 등이 게재됩니다. 그렇게 하면 첫 번째 불일치 지시가 달성됩니다. 원래 실행과 비교하여 로그 단계 수로 표시됩니다. 둘 중 하나가 멈추면 분쟁 기간이 끝나면 다른 참가자가 자동으로 승리합니다. 명령어를 처리하려면 MIPS 인터프리터가 메모리에 액세스해야 합니다. 루트는 다음과 같습니다. 필요한 메모리 셀이 포함되어 있음을 증명함으로써 공개될 수 있습니다. 접근하려면 EVM의 상태, Preimage Oracle이 사용됩니다. 반환되는 블록의 hash이 제공됩니다. 1https://geth.ethereum.org/docs

블록 헤더에서 이전 블록의 hash을 얻고 이전 블록으로 돌아갈 수 있습니다. 체인을 연결하거나 사전 이미지를 얻을 수 있는 상태 및 로그의 hash을 가져옵니다. oracle minigeth에 의해 구현되며 데이터베이스를 대체합니다. 쿼리는 다른 노드에 수행됩니다. 사전 이미지를 얻습니다.

乐观汇总

  1. 乐观汇总 乐观地接受块的输出而不验证其执行的想法是 已经出现在 Bitcoin 白皮书 [7] 中,讨论了轻节点。这些节点仅遵循 头链通过验证共识规则,使它们容易受到接受块的影响 包含发生 51% 攻击时无效的交易。中本聪提议解决这个问题 通过使用“警报”系统来警告轻节点某个区块包含无效交易来解决这个问题。 该机制首先由 Al-Bassam、Sonnino 和 Buterin [8] 实现,其中一个故障 使用基于纠错码[9]的证明系统。为了能够创建 故障证明,所有块(包括无效块)的数据都必须可用 网络:这是数据可用性问题,可以使用概率数据来解决 抽样机制。第一个 Optimistic Rollup 设计由 John Adler 提出, Mikerah Quintyne-Collins 在 2019 年 [10],其中区块发布在另一个 blockchain 上 这定义了他们对订购的共识。 2.1. Optimism 基岩 Bedrock [11] 是 Optimism(智能合约汇总)的最新版本。之前的版本, 乐观虚拟机 (OVM) 需要一个临时编译器将 Solidity 编译到其 自己的字节码:相比之下,Bedrock 完全等同于 EVM ,因为执行引擎 遵循 Ethereum 黄皮书规范 [12]。 2.1.1.存款 用户可以通过调用depositTransaction函数,通过Ethereum(Optimism门户)上的合约存入交易。 当一笔交易被执行时, 发出 TransactionDeposited 事件,Rollup 中的每个节点都会监听该事件并进行处理 存款。存入交易是源自 L1 的 L2 交易。如果呼叫者 函数是一个合约,地址通过添加一个常量值来转换:这可以防止 L1 上的合约与 L2 上的合约具有相同地址但代码不同的攻击。 存储交易包含在 L2 中是通过排序中的规范来确保的 窗口。 存入交易是新的EIP-2718兼容交易类型[13],前缀为0x7E, 其中 rlp 编码字段是: • bytes32 sourceHash:hash,唯一标识交易源。 • 地址来自:发件人的地址。 • 地址:接收者地址,或零地址(如果存入的交易是 合同创建。• uint256 mint:要在L2 上创建的值。 • uint256 值:要发送给接收者的值。 • 字节数据:输入数据。 • bytes GasLimit:交易的gas 限制。 sourceHash 计算为 L1 块 hash 的 keccak256 hash 和 L1 日志 索引,唯一标识块中的事件。 由于存入的交易是在L1上发起但在L2上执行的,所以系统需要一个 向 L1 支付 L2 所花费的 Gas 的机制。一种解决方案是通过门户发送 ETH, 但这意味着每个呼叫者(甚至间接呼叫者)都必须标记为应付,这是 对于许多现有项目来说这是不可能的。另一种方法是在 L1 上燃烧相应的气体。 分配给存入交易的gas𝑔称为保证gas。 L2 汽油价格 L1 不会自动同步,而是使用类似于 EIP-1559 的机制进行估计 [14]。每个 Ethereum 区块保证的最大 Gas 量为 800 万,目标 200万。在 L2 上支付 Gas 费用所需的 ETH 数量为 𝑐= 𝑔𝑏L2,其中 𝑏L2 是 L2 的基本费用。 L1 上的合约燃烧的 Gas 量等于 𝑐/𝑏L2。打电话所花费的gas 存款交易在 L2 上偿还:如果该金额大于保证气体, 没有气体被燃烧。 rollup区块的第一笔交易是L1属性存入交易,用于注册 在 L2 上预部署 Ethereum 块的属性。预部署提供的属性 访问的是区块号、时间戳、基本费用、区块 hash 和序列 number,L2 相对于关联的 L1 区块的区块编号(也称为纪元); 当新纪元开始时,该数字会重置。 2.1.2.测序 Rollup 节点完全从 Ethereum 派生出 Optimism 链。这条链条被延长了 每次在 L1 上发布新交易时,每次都会重新组织其区块 Ethereum 块被重新组织。 Rollup blockchain 分为多个纪元。对于每个 𝑛 区块号为Ethereum,有对应的𝑛纪元。每个纪元至少包含一个 一个 epoch 中的每个区块都包含一个 L1 属性的存入交易。第一个区块 一个纪元包含通过门户存入的所有交易。 Layer 2 块也可能 包含排序交易,即直接发送到排序器的交易。 排序器接受用户的交易并构建区块。对于每个块,它构造 一批将在 Ethereum 上发布。可以以压缩方式发布多个批次, 采取名称频道。一个通道可以分成几个帧,以防通道太大 单笔交易。通道被定义为使用 RLP 编码的 ZLIB [15] 进行压缩 批次。批次的字段包括纪元号、纪元 hash、父代 hash、 时间戳和交易列表。 一个由 epoch 标识的排序窗口,包含固定数量 𝑤 的连续 L1 推导步骤将其作为输入来构造可变数量的 L2 块。对于 纪元𝑛,排序窗口𝑛包括块[𝑛,𝑛+𝑤)。这意味着排序 排序窗口内的 L2 事务和块的数量直到窗口结束才固定。 如果包含 rollup 的交易已在 L1 上得到确认,则该交易被称为安全交易。镜框从 L1 块中读取以重建批次。当前的实现不允许 开始对通道进行解压缩,直到接收到所有相应的帧。无效 批次被忽略。单个区块交易是从批次中获得的,这些交易是 执行引擎使用它来应用状态转换并获取 Rollup 状态。 2.1.3.提款 为了处理提款,实施了 L2 到 L1 消息传递系统。 Ethereum 需要知道 L2 的状态才能接受提款,这是通过发布来完成的 L2 输出 Oracle smart contract 在 L1 上每个 L2 块的状态根。这些根 如果在期间没有执行故障证明,则乐观地认为是有效的(或最终确定的) 争议期。只有指定为提议者的地址才能发布输出根。有效性 的输出根是通过让提案者存入股份来激励的,如果他们 显示提出了无效的根。交易是通过调用该函数发起的 在 L2 上的预部署上启动撤回,然后通过调用该函数在 L1 上完成 FinalizeWithdrawalTransaction 在前面提到的 Optimism 门户上。 从L2 Output Oracle中获取L2块对应的输出根;是的 核实已最终确定,即争议期已过;经验证,输出 根证明与预言机证明相匹配;经核实,已包含提款的hash 使用提款证明;撤回尚未最终确定;然后是 使用指定的气体限制、以太币数量和数据执行对目标地址的调用。 2.1.4. Cannon:防故障系统 如果 Rollup Full Node 通过本地执行批次和存入交易发现 Layer 2 状态与提议者在链上发布的状态根不匹配,它可以执行 L1 上的故障证明,证明块转换的结果不正确。因为 开销,在 L1 上处理整个 Rollup 块的成本太高。实施的解决方案 by Bedrock 的目的是仅在链上执行 minigeth 不一致的第一条指令, 将其编译成 MIPS 架构,在链上解释器上执行并发布 在 L1 上。 minigeth是geth 1的简化版本,其中共识、RPC和数据库 已被删除。 为了找到第一个不一致的指令,在之间进行交互式二分搜索 发起故障证明的人和发布输出根的人。当证明 开始,双方在执行中途发布 MIPS 内存状态的根 挑战合约上的区块:如果 hash 匹配,则意味着双方都同意 执行的前半部分,从而发布后半部分的根,否则一半 上半年已出版等等。这样做就实现了第一个分歧指令 与原始执行相比,步骤数为对数。如果两者之一停止 互动时,在争议期结束时,另一方自动获胜。 为了处理该指令,MIPS 解释器需要访问其内存:因为根是 可用时,可以通过证明其包含性来发布必要的存储单元。访问 EVM 的状态,使用原像 Oracle:给定它返回的块的 hash 1https://geth.ethereum.org/docs

块头,从中可以获取前一个块的 hash 并返回到 链,或者获取可以获取原像的状态和日志的 hash 。 oracle 由minigeth实现并取代数据库。向其他节点进行查询 获得原像。

유효성 롤업

  1. 유효성 롤업 유효성 롤업의 목표는 상태 전환의 유효성을 암호화로 증명하는 것입니다. 준선형적으로 비교하여 검증할 수 있는 짧은 증거가 있는 일련의 거래를 고려했을 때 원래 계산 시점까지. 이러한 종류의 인증서를 계산 무결성 증명이라고 하며 실제로 산술 연산을 사용하는 SNARK(Succint Non-interactive ARgument of Knowledge)로 구현됩니다. 회로를 계산 모델로 사용합니다. 다양한 SNARK 구현은 증명 시간이 다릅니다. 검증 시간, 신뢰할 수 있는 설정 및 양자 저항의 필요성 [16, 17]. STARK(확장 가능 투명한 지식 인수) [18]은 신뢰할 수 있는 정보가 필요하지 않은 SNARK 유형입니다. 증명 및 검증의 효율성을 일부 포기하면서 설정 및 양자 저항성을 갖습니다. 다른 솔루션에 비해. 3.1. StarkNet StarkNet은 STARK를 사용하는 StarkWare에서 개발한 스마트 계약 유효성 롤업입니다. Ethereum에 대한 상태를 검증하는 증명 시스템입니다. 타당성 증명의 구축을 용이하게 하기 위해, EVM과 다른 가상 머신이 사용되며, 고급 언어는 Cairo입니다. 3.1.1. 예금 사용자는 sendMessageToL2를 호출하여 Ethereum의 계약을 통해 거래를 입금할 수 있습니다. 기능. 메시지는 hash을 계산하고 카운터를 증가시켜 기록됩니다. 시퀀서 LogMessageToL2 이벤트를 수신하고 StarkNet 트랜잭션의 정보를 인코딩합니다. l1_handler 데코레이터가 있는 계약의 함수를 호출합니다. 실행이 끝나면, 상태 전환 증명이 생성되면 메시지 소비가 여기에 첨부됩니다. 카운터를 줄임으로써 삭제됩니다. StarkNet 사양에서는 예치된 거래를 포함할 것을 요구하지 않으므로 가스 시퀀서가 L2에 게시하도록 장려하려면 시장이 필요합니다. 현재 버전에서는 시퀀서는 예치된 거래 비용인 StarkWare에 의해 중앙 집중화되고 관리됩니다. 예금 실행 비용에 의해서만 결정됩니다. 이 비용은 ETH를 전송하여 지불됩니다. sendMessageToL2. 이 Ether는 L1에 고정된 상태로 유지되며 L1의 Sequencer로 전송됩니다. L1, 예치된 트랜잭션이 상태 전환에 포함될 때. 다음과 같은 경우 전송된 ETH 금액 예치된 거래가 포함되어 소비된 가스량에 관계없이 완전히 소비됩니다. L2에. StarkNet에는 L1 블록 속성을 자동으로 사용할 수 있게 만드는 시스템이 없습니다. 또는 Fossil은 Oiler Network 2에서 개발한 프로토콜로, 주어진 hash을 허용합니다. 블록, 사전 이미지 게시를 통해 Ethereum에서 얻을 수 있는 모든 정보. 2https://www.oiler.network/3.1.2. 시퀀싱 StarkNet의 현재 상태는 Ethereum에서 완전히 파생될 수 있습니다. 모든 상태 차이 전환 간은 L1에 호출 데이터로 게시됩니다. 각 계약에 대한 차이점이 게시됩니다. 다음 인코딩을 사용하여 uint256[]으로 저장됩니다. • 계약 배포와 관련된 분야의 수. • 게시된 각 계약에 대해 다음을 수행합니다. – 게시된 계약의 주소입니다. – 게시된 계약의 hash. – 계약 생성자의 인수 수. – 생성자 인수 목록 • 저장공간이 수정된 계약의 수. • 수정된 각 계약에 대해: – 수정된 계약서의 주소. – 스토리지 업데이트 횟수. – 새 값이 포함된 저장소 주소의 키-값 쌍입니다. 상태 차이는 순서대로 공개되므로 순차적으로 읽어도 충분합니다. 상태를 재구성합니다. 3.1.3. 인출 L2에서 L1으로 메시지를 보내려면 시스템 호출 send_message_to_L1이 사용됩니다. 메시지는 증명과 함께 hash 카운터를 늘려 L1에 게시하고 L1의 StarkGate smart contract에 있는 ConsumerMessageFromL2 함수는 감소합니다. 카운터. 누구나 출금을 완료할 수 있습니다. 3.1.4. 유효성 증명 Cairo Virtual Machine [19]은 STARK 증명 구축을 용이하게 하도록 설계되었습니다. Cairo 언어를 사용하면 계산을 고급 프로그래밍으로 설명할 수 있습니다. 언어가 아닌 회로로 직접적으로 사용됩니다. 이는 다항 방정식 시스템에 의해 수행됩니다. 단일 계산을 나타내는 그림 3: 폰 노이만 아키텍처의 FDE 사이클. 번호 따라서 제약 조건은 고정되어 있고 계산 유형에 독립적이므로 하나만 허용됩니다. 계산을 증명해야 하는 모든 프로그램에 대한 검증 프로그램입니다. StarkNet은 공유 증명자를 사용하여 여러 거래를 단일 STARK 증명으로 집계합니다. SHARP라는 이름이 붙었습니다. 증명은 Ethereum의 smart contract로 전송되어 유효성을 확인합니다. 새로운 상태에 해당하는 Merkle 루트를 업데이트합니다. 검증의 하위 선형 비용 유효성 증명을 통해 여러 거래를 통해 비용을 분할 상환할 수 있습니다. 3대수 중간 표현(AIR)이라고 함

有效性汇总

  1. 有效性汇总 有效性汇总的目标是以密码方式证明状态转换的有效性 给定具有可进行亚线性比较验证的简短证明的交易序列 到原始计算的时间。 此类证书称为计算完整性证明,实际上是通过 SNARK(简洁非交互式知识论证)实现的,它使用算术 电路作为他们的计算模型。不同的 SNARK 实现在证明时间上有所不同, 验证时间、可信设置的需要和量子电阻 [16, 17]。 STARK(可扩展 透明的知识论证)[18] 是一种 SNARK,不需要可信的 设置和量子抗性,同时放弃一些证明和验证的效率 与其他解决方案相比。 3.1. StarkNet StarkNet 是 StarkWare 开发的智能合约有效性汇总,使用 STARK 证明系统将其状态验证为 Ethereum。为了促进有效性证明的构建, 使用与EVM不同的虚拟机,其高级语言为Cairo。 3.1.1.存款 用户可以通过调用 sendMessageToL2 通过 Ethereum 上的合约存入交易 功能。通过计算其 hash 并增加计数器来记录消息。测序仪 监听 LogMessageToL2 事件并将信息编码到 StarkNet 事务中 调用具有 l1_handler 装饰器的合约函数。执行结束时, 当状态转换的证明产生时,消息的消费被附加到它上面 并通过减少其计数器来删除它。 StarkNet 规范不要求包含存入交易,因此气体 需要市场来激励测序者在 L2 上发布它们。在当前版本中,因为 Sequencer 由 StarkWare 集中管理,存入交易的成本 仅由执行存款的成本决定。该费用通过将 ETH 发送至 发送消息到L2。这些以太币仍然锁定在 L1 上,并在 L1,当存入的交易包含在状态转换中时。发送的 ETH 数量,如果 无论消耗的 Gas 量如何,存入的交易都已包含在内并已全部花费 在 L2 上。 StarkNet 没有一个系统可以自动使 L1 块属性可用。 另外,Fossil 是由 Oiler Network 2 开发的协议,允许给定 hash 块,通过发布原像从 Ethereum 获得的任何信息。 2https://www.oiler.network/3.1.2.测序 StarkNet 的当前状态可以完全从 Ethereum 导出。任何状态差异 转换之间作为 calldata 在 L1 上发布。每个合同的差异均已公布 并保存为 uint256[],编码如下: • 涉及合同部署的领域数量。 • 对于每份已发布的合同: – 已发布合约的地址。 – 已发布合同的 hash。 – 合约构造函数的参数数量。 – 构造函数参数列表 • 存储已修改的合约数量。 • 对于每份已修改的合同: – 修改后的合约的地址。 – 存储更新的数量。 – 存储地址与新值的键值对。 状态差异是按顺序发布的,因此按顺序读取它们就足够了 重建国家。 3.1.3.提款 要从 L2 向 L1 发送消息,请使用系统调用 send_message_to_L1。消息是 通过增加其 hash 计数器以及证明来发布到 L1,并通过调用 L1 上 StarkGate smart contract 上的函数 ConsumerMessageFromL2 会递减 柜台。任何人都可以完成任何提款。 3.1.4.有效性证明 Cairo 虚拟机 [19] 旨在促进 STARK 证明的构建。 开罗语言允许用高级编程来描述计算 语言,而不是直接作为电路。这是通过多项式方程组来完成的 3 代表单个计算:冯诺依曼架构的 FDE 循环。数量 因此,约束的数量是固定的,并且与计算类型无关,仅允许一个 每个需要证明其计算的程序的验证程序。 StarkNet 使用共享证明者将多个交易聚合到单个 STARK 证明中 名为夏普。证明将发送至 Ethereum 上的 smart contract,以验证其有效性 并更新与新状态对应的 Merkle 根。验证一个的次线性成本 有效性证明允许其成本在多个交易中摊销。 3称为代数中间表示(AIR)

비교

  1. 비교 4.1. 출금시간 낙관적 롤업과 유효성 롤업을 구별하는 가장 중요한 측면은 출금 초기화부터 완료까지 소요되는 시간입니다. 두 경우 모두, 인출은 L2에서 초기화되고 L1에서 완료됩니다. StarkNet에서 다음과 같이 마무리가 가능합니다. Ethereum에서 새로운 상태 루트의 유효성 증명이 승인되자마자 이론적으로는 다음과 같습니다. 초기화 후 L1의 첫 번째 블록에서 자금을 인출할 수 있습니다. 실제로는 Ethereum에서 유효성 증명을 보내는 빈도는 블록 속도 간의 균형입니다. 마무리 및 증명 집계. 현재 StarkNet은 검증을 위한 유효성 증명을 제공합니다. 10시간마다 4. 단, 거래 활동이 증가함에 따라 감소하도록 의도되었습니다. Optimism Bedrock에서는 분쟁이 끝난 후에만 출금을 완료할 수 있습니다. 기간(현재 7일)이 지나면 루트는 자동으로 유효한 것으로 간주됩니다. 길이 이 기간은 주로 결함 증명이 Ethereum에서 검열될 수 있다는 사실에 의해 결정됩니다. 그것의 끝. 이러한 유형의 공격의 성공 확률은 시간이 지남에 따라 기하급수적으로 감소합니다. E[감산값] = 𝑉𝑝𝑛 여기서 𝑛는 간격의 블록 수, 𝑉는 차감할 수 있는 자금의 양입니다. 유효하지 않은 루트를 게시하여 𝑝는 검열을 성공적으로 수행할 확률입니다. 단일 블록으로 공격합니다. 이 확률이 99%라고 가정하면 Rollup에 고정된 값이 는 100만 이더이고, 간격의 블록은 1800개입니다(12개의 블록이 있는 6시간의 블록). 초 간격): 예상 값은 약 0.01391 Ether입니다. 시스템은 다음에 의해 안전하게 만들어집니다. 제안자에게 예상 가치보다 훨씬 더 많은 양의 Ether를 스테이킹하도록 요청합니다. Winzeret al. 간단한 smart contract을 사용하여 검열 공격을 수행하는 방법을 보여주었습니다. 이는 상태의 특정 메모리 영역이 변경되지 않도록 보장합니다([20]). 공격 모델링 마르코프 게임으로서 이 논문은 검열이 합리적인 판단을 위한 지배적인 전략임을 보여줍니다. 블록 생산자가 변경된 거래를 포함하는 것보다 더 많은 보상을 받는 경우 기억. 위에서 논의된 𝑝값은 합리적인 블록의 백분율로 볼 수 있습니다. 네트워크의 생산자는 "합리적"이라고 할 때 처벌 가능성을 고려하지 않습니다. 암호화폐 가치를 감소시키는 blockchain에 대한 신뢰도 저하와 같은 외부 효과. 다음 코드는 검열 공격을 수행하는 데 사용할 수 있는 smart contract을 나타냅니다. 베드락에. 공격은 뇌물을 제공하여 블록 생산자의 인센티브를 이용합니다. 주의 특정 부분을 수정하는 거래를 검열합니다. 계약의 주요 내용 함수인 ClaimBribe를 사용하면 블록 생산자가 검열에 성공한 경우 뇌물을 요구할 수 있습니다. 유효하지 않은 출력 루트가 건드리지 않았는지 확인하여 대상 트랜잭션을 처리합니다. 함수 ClaimBribe(바이트 메모리 StorageProof) 외부 { require(!claimed[block.number], "뇌물은 이미 청구되었습니다."); OutputProposal 메모리 현재 = StorageOracle.getStorage(L2_ORACLE, block.number, SLOT, 저장 증명); require(invalidOutputRoot == current.outputRoot, "공격 실패"); 청구됨[block.number] = true; (부울 전송됨, ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, "이더 전송 실패"); } 목록 1: Bedrock에 대한 검열 공격을 장려하는 계약의 예. 분쟁 기간의 길이는 또한 결함 증명이 다음과 같다는 사실을 고려해야 합니다. 대화형 증거이므로 참가자가 상호 작용할 수 있는 충분한 시간이 제공되어야 합니다. 모든 상호작용은 검열될 수 있습니다. 마지막 이동이 매우 가까운 시간에 발생하는 경우 분쟁 기간이 끝나면 검열 비용이 훨씬 적습니다. 검열이 이루어지긴 하지만 지배적인 전략에서는 검열 노드가 취약하기 때문에 성공 가능성이 낮습니다. 서비스 거부 공격: 공격자는 다음으로 끝나는 매우 복잡한 트랜잭션을 생성할 수 있습니다. 수수료가 지불되지 않으므로 무료로 결함 증명을 게시합니다. 극단적인 경우 긴 분쟁 기간을 통해 성공적인 경우 조정이 가능합니다. 검열 공격을 통해 포크를 구성하고 공격하는 블록 생산자를 배제합니다. 또 다른 가능한 공격은 논쟁자가 확인할 수 있는 것보다 더 많은 상태 루트 제안을 게시하는 것으로 구성됩니다. 이는 주파수 제한을 사용하여 피할 수 있습니다. 4.1.1. 빠른 낙관적 인출 낙관적 롤업의 유효성은 언제든지 전체 노드에서 확인할 수 있으므로 신뢰할 수 있는 oracle을 사용하여 L1에서 출금이 안전하게 완료될 수 있는지 확인할 수 있습니다. 이 메커니즘은 Maker [21]에 의해 처음 제안되었습니다. oracle는 출금을 확인하고, 이자부 대출이 사용자에게 할당된 L1의 결과는 자동으로 7일이 지나면 종료됩니다. 즉, 인출이 실제로 완료될 수 있는 시점입니다. 이 솔루션 신뢰 가정을 도입하지만 Maker의 경우 oracle 연산자 이후로 최소화됩니다. 대출을 제공함으로써 위험을 감수하는 동일한 조직에 의해 관리됩니다. 4.2. 거래비용 L2 트랜잭션 비용은 대부분 L1과의 상호작용에 의해 결정됩니다. 두 솔루션 모두 트랜잭션의 계산 비용은 완전히 오프체인에서 실행되므로 매우 저렴합니다. Optimism은 L2 트랜잭션 calldata를 calldata로 게시하고 오류를 거의(또는 전혀) 실행하지 않습니다. 증명하므로 calldata는 가장 비싼 리소스입니다. 2022년 1월 12일 Bedrock 네트워크 Ethereum의 Goerli 테스트넷에서 출시되었습니다. 가스 압축률을 계산할 수 있습니다. 특정 기간 동안 베드락에서 사용된 가스의 양을 추적하고 이를 비교함으로써 해당 블록의 L1에 소비된 가스의 양입니다. 이 방법을 사용하여 가스 압축 ~20:1의 비율이 발견되었으나, 이 수치는 메인넷의 실제 활동과 다를 수 있습니다. StarkNet은 L2 상태의 모든 변경 사항을 Ethereum에 호출 데이터로 게시하므로 스토리지는 가장 비싼 자원. 네트워크는 EVM을 사용하지 않으므로 거래 비용은 압축은 사소하게 추정할 수 없습니다. 실행 비용과 호출 데이터를 가정하여 무시할 수 있으므로 스토리지 쓰기의 압축률을 계산할 수 있습니다. L1. 배포된 계약이 없고 StarkNet에서 이전에 액세스하지 않은 10개의 셀이 다음과 같다고 가정합니다. 수정된 결과 ~24:1의 스토리지 쓰기 비용 압축률이 발견되었습니다. 셀을 덮어쓴 경우 𝑛데이터 게시 사이에 각 쓰기 비용은 비용과 비교하여 1/𝑛입니다. 단일 쓰기의 경우 마지막 쓰기만 게시되기 때문입니다. 비용을 더욱 최소화할 수 있습니다.자주 사용되는 값을 압축합니다. 유효성 증명 검증 비용은 다음과 같이 나뉩니다. 참조하는 트랜잭션: 예를 들어 StarkNet 블록 4779에는 200개의 트랜잭션이 포함되어 있으며 그 유효성 증명은 각 거래마다 267830개 가스 또는 1339.15개 가스를 소비합니다. 4.2.1. 통화 데이터 최적화: 캐시 계약 아래에는 자주 사용되는 주소 캐시를 구현한 smart contract이 나와 있습니다. 저장 및 실행 비용이 훨씬 저렴하다는 점을 활용하여 주소를 지정합니다. 리소스와 그 사용을 보여주는 Friends 계약이 함께 제공됩니다. 후자는 다음을 추적합니다. addFriend 함수를 호출하여 등록할 수 있는 주소의 "친구"입니다. 주소인 경우 이미 한 번 이상 사용된 경우 addFriendWithCache를 호출하여 추가할 수 있습니다. 함수: 캐시 인덱스는 4바이트 정수이고 주소는 20바이트로 표시됩니다. 따라서 함수 인수가 5:1로 절약됩니다. 다른 데이터에도 동일한 논리를 사용할 수 있습니다. 정수 또는 더 일반적으로는 바이트와 같은 유형입니다. 계약 AddressCache { 매핑(주소 => uint32) 공개 주소2키; 주소[] 공개 키2주소; 함수 캐시Write(address _address) 내부 반환(uint32) { require(key2address.length < type(uint32).max, "AddressCache: 캐시가 가득 찼습니다."); require(address2key[_address] == 0, "AddressCache: 주소가 이미 캐시되었습니다."); // 0은 "찾을 수 없음"을 의미하므로 키는 1부터 시작해야 합니다. uint32 키 = uint32(key2address.length + 1); address2key[_address] = 키; key2address.push(_address); 리턴 키; } 함수 캐시읽기(uint32 _key) 공개 보기는 (주소) {를 반환합니다. require(_key <= key2address.length && _key > 0, "AddressCache: 키를 찾을 수 없습니다."); return key2address[_key - 1]; } } 목록 2: 주소 캐시 계약. 계약 친구는 AddressCache입니다. 매핑(주소 => 주소[]) 공개 친구; 함수 addFriend(주소_친구) 공개 { 친구[msg.sender].push(_friend); 캐시쓰기(_friend); } 함수 addFriendWithCache(uint32 _friendKey) 공개 { 친구[msg.sender].push(cacheRead(_friendKey)); } 함수 getFriends() 공개 보기는 (주소[] 메모리)를 반환합니다. 친구에게 돌아가기[msg.sender];} } 목록 3: 주소 캐시를 상속하는 계약의 예. 계약은 캐시에서 약 40억(232)개의 주소를 지원하며 1바이트를 추가하면 약 1조(240). 4.2.2. 스토리지 최적화: Bloom의 필터 StarkNet에는 스토리지 사용량을 최소화하는 몇 가지 기술이 있습니다. 꼭 필요하지 않은 경우 원본 데이터의 가용성을 보장하면 hash을 온체인에 저장하는 것으로 충분합니다. ERC-721(NFT) [22], 즉 IPFS 링크를 해결하는 데이터를 저장하는 데 사용되는 메커니즘입니다. 사용 가능한 경우 데이터의 hash. 여러 번 저장된 데이터의 경우 조회 기능을 사용할 수 있습니다. 테이블은 Optimism에 도입된 캐싱 시스템과 유사하며 모든 값을 다음 위치에 저장해야 합니다. 적어도 한 번은. 일부 애플리케이션의 경우 Bloom 필터를 사용하면 모든 값을 저장하지 않을 수 있습니다. [23, 24, 25], 즉, 확실하게 알 수 있는 확률적 데이터 구조입니다. 요소는 집합에 속하지 않지만 작지만 무시할 수 없는 거짓 확률을 허용합니다. 긍정적인 점. 블룸 필터는 0에서 𝑚비트 배열로 초기화됩니다. 요소를 추가하려면 𝑘hash 함수를 사용하세요. 균일한 무작위 분포가 사용되며 각각은 설정된 배열의 비트에 매핑됩니다.
  2. 요소가 세트에 속하는지 확인하기 위해 𝑘hash 함수를 실행하고 확인합니다. 𝑘 비트가 1로 설정되어 있습니다. 간단한 Bloom 필터에서는 요소가 실제로 세트에 속하거나 위양성(수에 따라 증가하는 확률)입니다. 항목이 증가합니다. 𝑛요소를 삽입한 후: P[거짓양성] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≒ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 각 비트 세트의 확률은 독립이라고 가정합니다. 𝑛요소(임의의 크기)가 다음과 같은 경우 포함될 것으로 예상되며 허용되는 잘못된 긍정의 확률은 𝑝, 즉 배열의 크기입니다. 다음과 같이 계산할 수 있습니다. 𝑚= −𝑛ln 𝑝 (2)2 hash 함수의 최적 개수는 다음과 같습니다. 𝑘= 𝑚 𝑛2에 허용오차가 1%인 1000개의 요소를 삽입한다고 가정하면 배열의 크기는 9585비트입니다. 𝑘= 6인 경우 허용 오차가 0.1%인 경우 𝑘= 9인 경우 14377비트가 됩니다. 요소가 백만 개이면 삽입될 것으로 예상되면 배열의 크기는 1%의 경우 약 1170kB, 1%의 경우 약 1775kB가 됩니다. 0.1%, 𝑝[26]에만 의존하므로 𝑘 값이 동일합니다. 플레이어가 이미 도전한 상대에게 배정되어서는 안 되는 게임에서, 각 플레이어의 저장소에 과거 상대 목록을 저장하는 대신 Bloom을 사용할 수 있습니다. 필터. 일부 플레이어에게 도전하지 않는 위험은 대개 허용되며 필터는 재설정될 수 있습니다. 주기적으로.4.3. Ethereum 호환성 EVM 및 Ethereum과 호환되는 주요 이점은 사용 가능한 모든 항목을 재사용한다는 것입니다. 도구. Ethereum smart contracts는 수정 없이 Optimism에 게시될 수 있습니다. 새로운 감사. 지갑은 호환성을 유지하며 개발 및 정적 분석 도구, 일반 분석 도구, 색인 도구 및 oracles. Ethereum 및 Solidity는 오랫동안 잘 연구된 역사를 가지고 있습니다. 재진입 공격, 오버플로 및 언더플로, 플래시 대출 및 oracle과 같은 취약점 조작. 이로 인해 Optimism은 단시간에 많은 가치를 포착할 수 있었습니다. 시간. 다른 가상 머신을 채택한다는 것은 전체 생태계를 재구축해야 한다는 것을 의미합니다. 구현의 자유도가 더 높다는 장점이 있습니다. StarkNet은 기본적으로 계정을 구현합니다. 추상화는 각 계정이 구현할 수 있는 smart contract인 메커니즘입니다. 인터페이스를 준수하는 한 임의의 논리(따라서 추상화라는 용어가 사용됨): 이를 통해 다양한 디지털 서명 체계 사용, 개인 키를 변경하는 기능 동일한 주소를 사용하거나 다중 서명을 사용하세요. Ethereum 커뮤니티에서 이 기능의 도입을 제안했습니다. 2020년에 EIP-2938과 함께 메커니즘을 도입했지만 제안은 1년 넘게 오래된 상태로 남아 있습니다. 다른 업데이트에는 더 많은 우선순위가 부여되었습니다([27]). 호환성을 통해 얻을 수 있는 또 다른 중요한 이점은 기존 클라이언트를 재사용한다는 것입니다. Optimism 자체 노드에 약 800줄의 차이만 있는 geth 버전을 사용합니다. 2014년부터 개발, 테스트 및 유지 관리되었습니다. 강력한 클라이언트를 갖는 것은 정의에 따라 매우 중요합니다. 네트워크에서 유효한 것으로 허용되는 것과 그렇지 않은 것. 결함 증명 구현의 버그 시스템으로 인해 잘못된 증거가 올바른 것으로 받아들여지거나 잘못된 증거에 대한 올바른 증거로 받아들여질 수 있습니다. 차단을 잘못된 것으로 받아들여 시스템을 손상시킵니다. 이런 종류의 확률 더 넓은 클라이언트 다양성으로 공격을 제한할 수 있습니다. Optimism는 geth 외에 재사용할 수 있습니다. 다른 Ethereum 클라이언트는 이미 유지 관리되고 있으며 다른 Erigon 기반 클라이언트의 개발은 이미 진행 중입니다. 2016년에는 geth의 메모리 관리 문제가 악용되었습니다. DoS 공격과 첫 번째 방어선은 두 번째로 가장 많이 사용되는 Parity의 사용을 권장하는 것이었습니다. 당시 사용했던 클라이언트 5. StarkNet은 유효성 증명과 관련해 동일한 문제에 직면했지만 클라이언트는 처음부터 작성해야 하며 증명 시스템은 훨씬 더 복잡합니다. 정확성을 보장하는 것도 훨씬 더 복잡합니다.

比较

  1. 比较 4.1.提款时间 区分乐观汇总和有效性汇总的最重要方面是 提款初始化和结束之间经过的时间。在这两种情况下, 提款在 L2 上初始化并在 L1 上完成。在 StarkNet 上,最终确定是可能的: 一旦新状态根的有效性证明在 Ethereum 上被接受:理论上,它是 初始化后可以在 L1 第一个区块中提取资金。在实践中, 在 Ethereum 上发送有效性证明的频率是区块速度之间的权衡 最终确定和证明聚合。目前StarkNet提供有效性证明以供验证 每 10 小时 4,但计划随着交易活动的增加而减少。 在 Optimism Bedrock 上,只有在争议结束时才有可能最终确定提款 期限(当前为 7 天),之后根自动被视为有效。长度为 这个时期主要是由以下事实决定的:故障证明可以在 Ethereum 上进行审查,直到 它的结束。随着时间的增加,此类攻击的成功概率呈指数下降: E[减去值] = 𝑉𝑝𝑛 其中𝑛是一个区间内的区块数量,𝑉是可以减去的资金量 通过发布无效根,𝑝是成功执行审查的概率 在单个块中进行攻击。假设这个概率是 99%,即 Rollup 中锁定的值 是一百万个以太币,一个时间间隔内的区块是 1800 个(6 小时的区块,12 个区块) 秒间隔):预期值约为 0.01391 以太。该系统的安全性是通过 要求提案者抵押比预期值多得多的以太币。 温泽等人。展示了如何使用简单的 smart contract 进行审查攻击 确保状态中的某些内存区域不会更改 [20]。对攻击进行建模 作为马尔可夫博弈,本文表明审查是理性的占优策略 如果区块生产者获得的补偿多于包含更改的交易 记忆。上面讨论的𝑝值可以看作是有理块的百分比 网络中的生产者,其中“理性”没有考虑可能的惩罚 外部性,例如对 blockchain 的信任度降低,从而降低了其加密货币的价值。 以下代码呈现了可用于执行审查攻击的 smart contract 在基岩上。该攻击通过向区块生产者提供贿赂来利用他们的动机 审查会修改国家特定部分的交易。合同主要内容 ClaimBribe 函数允许区块生产者在成功审查后索取贿赂 通过检查是否未触及无效的输出根来确定目标交易。 函数 ClaimBribe(字节内存 storageProof) 外部 { require(!claimed[block.number], "已索取贿赂"); OutputProposal 内存当前 = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, 存储证明); require(invalidOutputRoot == current.outputRoot, "攻击失败"); 声称[区块数] = true; (bool 发送, ) = block.coinbase.call{值: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, "发送以太币失败"); } 清单 1:激励对 Bedrock 进行审查攻击的合约示例。 争议期限的长短还必须考虑到过错证明是 交互式证明,因此必须为参与者提供足够的时间进行交互 并且任何互动都可能受到审查。如果最后一次移动发生的时间非常接近 争议期结束后,审查成本明显减少。虽然审查是 占优策略,成功的可能性较低,因为审查节点容易受到 拒绝服务攻击:攻击者可以生成非常复杂的交易,并以 免费发布故障证明,因为无需支付任何费用。 在极端情况下,较长的争议期可以在成功解决问题后进行协调 审查攻击,组织分叉并排除攻击区块生产者。另一个 可能的攻击在于发布比争议者可以验证的更多的国家根提案, 可以使用频率限制来避免这种情况。 4.1.1.快速乐观提款 由于任何全节点都可以随时验证 Optimistic Rollup 的有效性,因此 受信任的 oracle 可用于在 L1 上了解提款是否可以安全完成。这个 机制最初由 Maker [21] 提出:oracle 验证提现,发布 L1 上的结果,在该结果上将计息贷款分配给用户,该结果自动 7 天后关闭,即提款可以实际完成时。这个解决方案 引入了信任假设,但在 Maker 的情况下,由于 oracle 运算符,它被最小化 由通过提供贷款承担风险的同一组织管理。 4.2.交易成本 L2 交易的成本主要由与 L1 的交互决定。在两种解决方案中 交易的计算成本非常便宜,因为它完全在链下执行。 Optimism 将 L2 事务 calldata 发布为 calldata 并且很少(或从不)执行错误 证明,因此 calldata 是最昂贵的资源。 2022 年 1 月 12 日,基岩网络 已在 Ethereum 的 Goerli 测试网上启动。可以计算气体压缩率 通过跟踪特定时期内基岩上使用的气体量并将其与 相应区块的 L1 上花费的 Gas 量。使用这种方法进行气体压缩 发现比率为 ∼20 : 1,但该数字可能与主网上的实际活动有所不同。 StarkNet 在 Ethereum 上发布 L2 状态的每个更改作为 calldata,因此存储是 最昂贵的资源。由于网络不使用EVM,交易成本 压缩不能简单地估计。通过假设执行成本和调用数据 可以忽略不计,可以计算出存储写入的压缩比 L1。假设没有部署合约,并且之前未在 StarkNet 上访问过的 10 个单元格 修改后,发现存储写入成本压缩率为~24:1。如果单元格被覆盖 数据发布之间的𝑛次,每次写入的成本将是成本的1/𝑛 一次写入,因为仅发布了最后一个写入。成本可以通过以下方式进一步最小化压缩常用值。有效性证明验证的成本分为 它所指的交易:例如,StarkNet区块4779包含200笔交易及其 有效性证明消耗 267830 个单位的 Gas,即每笔交易消耗 1339.15 个 Gas。 4.2.1.优化calldata:缓存合约 下面介绍的是 smart contract,它实现了经常使用的地址缓存 通过利用存储和执行成本便宜得多的事实来解决问题 资源,以及演示其用途的 Friends 合约。后者跟踪 可以通过调用 addFriend 函数注册的地址的“好友”。如果一个地址 已经至少使用过一次,可以通过调用addFriendWithCache来添加 功能:缓存索引是4字节整数,而地址是20字节表示, 因此函数参数节省了 5:1。相同的逻辑可以用于其他数据 类型,例如整数或更一般的字节。 合约地址缓存 { 映射(地址=> uint32)公共地址2key; 地址[]公钥2地址; 函数cacheWrite(地址_地址)内部返回(uint32){ require(key2address.length < type(uint32).max, "AddressCache: 缓存已满"); require(address2key[_address] == 0, "AddressCache: 地址已缓存"); // 键必须从 1 开始,因为 0 表示“未找到” uint32 key = uint32(key2address.length + 1); 地址2键[_地址] = 键; key2address.push(_address); 返回键; } 函数cacheRead(uint32 _key)公共视图返回(地址){ require(_key <= key2address.length && _key > 0, "AddressCache: 找不到密钥"); 返回 key2address[_key - 1]; } } 清单 2:地址缓存合约。 合约好友是AddressCache { 映射(地址=>地址[])公众好友; 函数 addFriend(地址_friend) 公共 { 朋友[msg.sender].push(_friend); 缓存写入(_friend); } 函数 addFriendWithCache(uint32 _friendKey) 公共 { 朋友[msg.sender].push(cacheRead(_friendKey)); } 函数 getFriends() 公共视图返回 (address[] memory) { 返回好友[msg.sender];} } 清单 3:继承地址缓存的合约示例。 该合约在缓存中支持大约 40 亿(232)个地址,并且添加一个字节给出 约 1 万亿 (240)。 4.2.2.优化存储:Bloom 过滤器 在 StarkNet 上有多种技术可以最大限度地减少存储使用。如果没有必要的话 保证原始数据的可用性,那么将其 hash 保存在链上就足够了:this 是用于保存 ERC-721 (NFT) [22] 数据的机制,即解析 数据的 hash(如果有)。对于多次存储的数据,可以使用查找 表类似于 Optimism 引入的缓存系统,要求将所有值保存在 至少一次。对于某些应用程序,可以通过使用布隆过滤器来避免保存所有值 [23,24,25],即一种概率数据结构,可以让人们确定地知道是否 一个元素不属于一个集合,但承认有很小但不可忽略的错误概率 积极的一面。 布隆过滤器被初始化为 𝑚 位为零的数组。要添加元素,𝑘hash 函数 使用均匀随机分布,每个映射到设置的数组的一位
  2. 要检查某个元素是否属于集合,我们运行 𝑘hash 函数并验证 𝑘位设置为 1。在简单的布卢姆过滤器中,无法区分是否是 元素实际上属于该集合或者是误报,概率随着数量而增长 条目数量增加。插入𝑛元素后: P[假阳性] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 假设每个位组的概率独立。如果 𝑛 元素(任意大小!)是 预期包含在内,并且容忍误报的概率是 𝑝,即数组的大小 可以计算为: 𝑚= −𝑛ln 𝑝 (ln 2)2 而 hash 函数的最佳数量是: 𝑘=𝑚 𝑛2 如果我们假设以 1% 的容差插入 1000 个元素,则数组的大小为 9585 位 𝑘= 6,而对于 0.1% 的容差,当 𝑘= 9 时,它变成 14377 位。如果一百万个元素 预计将被插入,数组的大小变为约 1170 kB(对于 1%)和 1775 kB(对于 1%) 0.1%,与 𝑘 的值相同,因为它仅取决于 𝑝[26]。 在游戏中,玩家不得被分配给他们已经挑战过的对手, 可以使用 Bloom 来保存过去对手的列表,而不是为每个玩家保存存储空间 过滤器。不挑战某些玩家的风险通常是可以接受的,并且可以重置过滤器 定期。4.3. Ethereum 兼容性 与 EVM 和 Ethereum 兼容的主要优点是重用所有可用的 工具。 Ethereum smart contracts 可以在 Optimism 上发布,无需任何修改,也不 新的审计。钱包保持兼容,开发和静态分析工具,一般分析 工具、索引工具和 oracles。 Ethereum 和 Solidity 有着悠久的深入研究历史 漏洞,例如重入攻击、溢出和下溢、闪贷和 oracle 操纵。正因为如此,Optimism 能够在短时间内获取大量价值 时间。 选择采用不同的虚拟机意味着必须重建整个生态系统, 具有更大的实施自由度的优点。 StarkNet 本机实现帐户 抽象,这是一种机制,每个帐户都是一个 smart contract ,可以实现 任意逻辑,只要它符合接口(因此称为抽象):这允许 使用不同的数字签名方案,使用更改私钥的能力 相同的地址,或使用多重签名。 Ethereum 社区提议引入此功能 2020 年与 EIP-2938 的机制,但该提案已经过时了一年多,因为 其他更新已被赋予更高优先级[27]。 兼容性带来的另一个重要好处是现有客户端的重用:Optimism 使用 geth 版本作为自己的节点,只有 ∼800 行差异,这已被 自 2014 年以来开发、测试和维护。拥有强大的客户至关重要,因为它定义了 网络中哪些内容被认为有效,哪些内容无效。故障证明实施中的一个错误 系统可能会导致错误的证明被接受为正确的,或者正确的证明被无效的 块被认为不正确,从而损害系统。出现这种类型的可能性 可以通过更广泛的客户端多样性来限制攻击:Optimism 除了 geth 之外还可以重用 已维护其他 Ethereum 客户端,并且正在开发另一个基于 Erigon 的客户端 已经在进行中。 2016年,geth的内存管理问题被利用 DoS攻击的第一道防线是推荐使用Parity,第二道最 当时使用的客户端 5. StarkNet 面临同样的有效性证明问题,但是客户端 必须从头开始编写,证明系统要复杂得多,因此 确保正确性也要复杂得多。

결론

  1. 결론 롤업은 오늘날 확장성 문제를 해결하기 위해 사용할 수 있는 가장 유망한 솔루션입니다. 탈중앙화된 blockchain, 모듈형 blockchain 시대의 길을 열다 모놀리식 blockchains. 낙관적 롤업 또는 유효성 롤업 개발 선택이 주로 표시됩니다. 복잡성과 민첩성 사이의 절충안입니다. StarkNet은 빠른 속도와 같은 많은 장점을 가지고 있습니다. 인출, 유효하지 않은 상태 전환의 구조적 불가능, 낮은 거래 비용 개발 기간이 길어지고 EVM과의 비호환성이 발생하는 반면 Optimism은(는) 네트워크 경제를 활용하여 시장의 주요 점유율을 빠르게 확보했습니다. Optimism 그러나 Bedrock은 Validity가 될 수 있는 모듈식 설계를 보유하고 있습니다. 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

향후 롤업: Cannon은 현재 오류 방지를 위해 MIPS로 컴파일된 minigeth를 사용합니다. 시스템이지만 동일한 아키텍처를 사용하여 회로를 얻고 유효성 증명을 생성할 수 있습니다. 마이크로아키텍처에 대해 EVM과 같은 복잡한 시스템을 컴파일하면 더 간단해집니다. 업그레이드 시 수정 및 재검증이 필요하지 않은 회로입니다. RISC 제로는 RISC-V을 기반으로 이미 개발 중인 STARK 증명을 갖춘 검증 가능한 마이크로 아키텍처 MIPS [28] 대신 이 목적으로 사용할 수 있습니다. 과소평가해서는 안되는 한 가지 측면은 어떻게 이해하는 것이 복잡하다는 것입니다. 기술이 작동합니다. 기존 blockchain의 장점은 상태를 확인할 수 있다는 것입니다. 제3자 실체를 신뢰하지 않고 blockchain. 그러나 StarkNet의 경우에는 다양한 구성요소를 검증하는 것이 불가능할 때 구현을 신뢰하는 데 필요함 암호화 및 고급 수학을 기반으로 합니다. 이로 인해 처음에는 마찰이 발생할 수 있습니다. 기술을 채택했지만 무결성 증명의 도구와 사용이 발전함에 따라 blockchain 필드 외부에서는 이 문제가 해결되기를 바랍니다.

结论

  1. 结论 Rollups 是当今最有前途的解决方案,可解决可扩展性问题 去中心化的 blockchains,为模块化 blockchains 时代铺平了道路,而不是 整体 blockchains。 主要显示了开发 Optimistic Rollup 或 Validity Rollup 的选择 作为复杂性和敏捷性之间的权衡。 StarkNet 具有许多优点,例如速度快 提款、结构上无法进行无效的状态转换、较低的交易成本 开发周期较长且与 EVM 不兼容,而 Optimism 有 借助网络经济,迅速占领市场主要份额。 然而,Optimism Bedrock 拥有模块化设计,使其成为 Validity 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

未来的 Rollup:Cannon 目前使用编译为 MIPS 的 minigeth 来防止故障 系统,但可以使用相同的架构来获得电路并产生有效性证明。 为微架构编译复杂的机器(例如 EVM)会产生更简单的结果 升级时无需修改和重新验证电路。 RISC 零是 可验证的微架构,具有 STARK 证明,已基于 RISC-V 开发 可用于此目的作为 MIPS [28] 的替代。 不应低估的一个方面是理解如何实现这一目标的复杂性。 技术有效。传统 blockchains 的优点是能够验证 blockchain 而不信任任何第三方实体。然而,对于 StarkNet 来说,它是 当无法验证各个组件时,有必要信任实现 基于密码学和高等数学。这最初可能会产生摩擦 技术的采用,但随着工具和完整性证明的使用的进步,甚至 在 blockchain 字段之外,这个问题有望得到解决。