Skip to content

Latest commit

 

History

History
235 lines (167 loc) · 12.6 KB

joyc.md

File metadata and controls

235 lines (167 loc) · 12.6 KB
timezone
Asia/Tokyo

请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 时区请参考以下列表，请移除 # 以后的内容

timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)

timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)

timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)

timezone: America/Denver # 山地标准时间 (UTC-7)

timezone: America/Chicago # 中部标准时间 (UTC-6)

timezone: America/New_York # 东部标准时间 (UTC-5)

timezone: America/Halifax # 大西洋标准时间 (UTC-4)

timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)

timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)

timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)

timezone: Europe/London # 格林威治标准时间 (UTC+0)

timezone: Europe/Berlin # 中欧标准时间 (UTC+1)

timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)

timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)

timezone: Asia/Dubai # 海湾标准时间 (UTC+4)

timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)

timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)

timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)

timezone: Asia/Shanghai # 中国标准时间 (UTC+8)

timezone: Asia/Tokyo # 日本标准时间 (UTC+9)

timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)

timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)

hython

  1. Base Tokyo的web3从业者
  2. 你认为你会完成本次残酷学习吗？可能会

Notes

2024.12.10

Note

A gentle introduction to Arbitrum

Arbitrum 简介

  • 一种扩展以太坊的技术套件，使交易更便宜、更快，同时保持以太坊级别的安全性。
  • 背景以太坊的局限性：每秒只能处理 20-40 笔交易，竞争导致费用上升。

Arbitrum 的优化

  • Rollup 的工作原理
    作为以太坊的子模块运行，遵循“无罪推定”，必要时回到 L1 解决争议，保持安全性。
  • 交易效率的提升
    批量提交交易，数据压缩存储在 L1，显著降低费用。

安全与信任

  • 验证者的角色
    提供状态声明、处理争议，任何人都可以运行验证者以确保系统无需信任。
  • 欺诈检测
    通过缩小到单一计算步骤解决争议，确保诚实方获胜。

用户体验

  • 兼容性
    支持现有以太坊工具，提供类似以太坊的使用体验，但成本更低、速度更快。
  • 快速提现
    使用快速桥接应用可避免 1 周延迟。

技术扩展

  • Stylus 新功能
    支持 Rust 和 C++ 等高性能智能合约语言，提供更大灵活性。
  • AnyTrust 链的优势 数据离链存储，费用更低，适用于高吞吐量但去中心化要求较低的场景。

多链选择

  • 现有链
    • Arbitrum One：Rollup 链，去中心化、安全性高。
    • Nova：AnyTrust 链，费用低。
  • Orbit 链 开发者可构建自定义 Arbitrum 链。

决策机制

  • Arbitrum One 和 Nova 的未来由治理系统决定。

2024.12.11

Note

轻松理解Rollup，ZK Rollups与Optimistic，Arbitrum的区别

Rollup

是一种交易整理方法，将交易任务外包至 Layer2 协议执行，从而提升以太坊网络的效率与 TPS。

ZK Rollups

  • 特点：
    1. 零知识证明：无需查看完整数据即可验证。
    2. 简洁算法：验证过程简练高效。
    3. 非交互性：验证者身份无需公开。
    4. 数据真实性保障：通过复杂算法确保验证结果可靠。
  • 优点：
    • 提币到 Layer1 快速，适合支付和快速结算场景。
  • 缺点：
    • 算法复杂，对开发者有一定技术门槛。

Optimistic Rollups

  • 特点：
    1. 默认信任所有交易有效，后续验证期间通过奖惩机制处理错误。
    2. 支持智能合约和项目迁移，兼容性强。
  • 优点：
    • 开发 Dapp 方便，支持无缝迁移项目。
  • 缺点：
    • 提币速度慢（通常需一周），存在验证者作恶风险。

Optimism与Arbitrum对比

  • 共同点：基于 Optimistic Rollups 开发，专注提升以太坊扩容性能。
  • 区别：
    • Optimism：一次欺诈验证，交易计算依赖 Layer1 执行。
    • Arbitrum：多轮欺诈验证，交易执行在独立虚拟机中完成，更兼容 ETH 网络。

其他Layer2方案

  • Zksync：基于 ZK Rollups 方法，专注快速支付场景。
  • Plasma、Metis：其他 Layer2 协议，探索不同扩容方式。
  • Truebit：结合博弈与 AI，提升以太坊计算效率。

总结

  • Rollup 是以太坊扩容的核心思路。
  • ZK Rollups：适合支付类业务，验证严谨但开发难度较高。
  • Optimistic Rollups：适合 Dapp 和 Defi，但提币速度较慢。
  • Optimism 与 Arbitrum：基于乐观归纳的 Layer2 代表项目，各有优势与特性。

2024.12.12

Note

Arbitrum 欺诈证明机制详解 文档

欺诈证明详解

  1. 挑战的开始
  • 一个断言（Assertion）在链上被创建，声称某个 Arbitrum 节点在特定时间段内从一个状态转换到另一个状态。如果此断言被质疑，挑战开始。挑战通过对全局状态（包括区块哈希）进行二分开始。
  • 在执行有争议的 L2 交易之前，争议首先被缩小到特定的 L2 区块（含多个 L2 交易）。这个过程被称为“争议二分”(Dissection of Dispute)，通过对一系列 L2 区块的哈希链进行二分查找来确定有争议的 L2 区块。
  1. 执行挑战机制
  • 在确定到具体包含争议交易的区块后，攻击者（Challenger） 可以调用 challengeExecution 发起执行挑战。
  • 被挑战者（Defender） 需提供与此区块执行相关的竞争性的全局状态和机器状态断言，以推进到执行挑战阶段。
  • 具体来说，Defender 需要将有争议的 L2 区块分解成多个 One-Step Proof（单步证明），并创建一个 Assertion 树，用于后续的执行二分。
  1. 单步执行验证
  • 当挑战缩小到单步执行时，攻击者 可调用 oneStepProveExecution 质疑 Defender 提供的某一个单步证明。
  • 被挑战者 需提供证明数据来执行机器的单步操作 (包括操作码、操作数、内存状态等)。
  • 如果执行结果与先前断言的状态不符，攻击者 即赢得挑战。反之，如果被挑战者提供的单步证明通过了验证，则攻击者输掉挑战，并受到惩罚。
  1. 通用二分协议
  • 在确定了包含争议交易的 L2 区块后，挑战将围绕该区块的执行展开，这部分挑战遵循通用的二分协议。
  • 挑战从仅包含两个片段的初始断言（一个度数）开始，由挑战方发起。这里的“片段”可以理解为 L2 区块执行过程中的一段。一个片段对应多个 AVM 指令。
  • 每轮中，被挑战者 (Defender) 需选择相邻片段进行质疑，并提供新的二分，进一步缩小争议范围。这意味着被挑战者需要将有争议的片段继续进行二分，直到争议被缩小到单个 AVM 指令。
  • 最小度数为 40 或挑战片段步长。步长为 1 的片段不能再二分。这意味着，最小的争议片段可以包含 40 个 AVM 指令，如果某个片段的步长（包含的 AVM 指令数）小于等于 40，它就不能被继续二分。
  1. 挑战逻辑对称性 ♟️
  • 与传统乐观 Rollup 的单边挑战协议不同，该协议中双方轮流选择挑战点并提出二分，双方在挑战过程中的权利和义务是对等的。这意味着攻击者和被挑战者可以相互质疑对方的断言，直到最终确定争议所在。
  1. 胜利条件
  • 胜利不是即时的；当前占优的一方 成为胜者，对方没有有效动作后将通过超时失败。
  • 这是一种保护措施，以便在错误解决的情况下可以升级合约修复问题。这意味着即使一方在当前挑战中获胜，也需要等待一段时间才能最终确认胜利，这为合约升级留出了时间窗口。
  1. 辅助库功能
  • ChallengeLib 提供了 hashChallengeState 方法，可生成挑战状态哈希，包含片段哈希列表、起始位置和总片段长度等信息。这有助于验证挑战状态的一致性。
  • 此外，ChallengeLib 还提供了 bisectExecution (执行二分)、computeOneStepProofHash (计算单步证明哈希) 等方法，用于支持欺诈证明的各个阶段。

补充说明:

  • Arbitrum 使用 AVM (Arbitrum Virtual Machine) 作为其虚拟机，与 EVM 部分兼容。
  • 欺诈证明的目的是确保 Arbitrum 链上状态的正确性。如果验证者发布了错误的状态，任何人都可以通过发起挑战来证明其欺诈行为。
  • Arbitrum 的欺诈证明机制是交互式的，需要在链上进行多轮交互才能完成。
  • 该机制的安全性基于密码学假设和博弈论，能够激励验证者诚实地执行交易。

总结:

Arbitrum 的欺诈证明机制是一个复杂而精妙的系统，它通过多轮交互式的二分协议，将争议逐步缩小到单个 AVM 指令的执行，最终确定状态转换的正确性。这种机制结合了密码学证明和博弈论，确保了 Arbitrum 链的安全性和可扩展性。

2024.12.13

Note

Arbitrum 交互式欺诈证明

交互式欺诈证明的原理

交互式欺诈证明的核心思想在于，不在链上执行所有的计算，而是仅在出现争议时才进行验证，并且通过多轮交互，逐步缩小争议范围，最终只在链上执行最少量的必要计算。 这是一种“按需验证”的模式，极大地提升了效率。

传统的欺诈证明可能需要在链上重新执行整个计算过程以验证结果，这非常耗费资源。而交互式欺诈证明通过“挑战-回应”的机制，将复杂的计算验证过程分解为一系列简单的步骤，每次只在链上执行一部分，从而大幅降低了以太坊主链的负担。

关键概念：

  • 链下执行： 大部分计算在链下进行，速度快且成本低。
  • 争议： 当有人认为链下计算的结果不正确时，会发起争议。
  • 二分搜索： 争议发起后，双方会逐步将争议范围缩小，类似于二分查找算法，每一次交互都将争议范围减半。
  • 链上验证： 只有在争议范围被缩小到最小后，才在链上执行最终的、极小部分的计算进行验证。

交互式欺诈证明的执行步骤

  1. 链下计算： 验证器（Validator）在链下执行智能合约，并生成一个状态承诺（State Commitment），即计算结果的摘要，并将其提交到以太坊主链。
  2. 争议发起： 如果有人（挑战者）认为验证器提交的状态承诺不正确，则会发起争议（Challenge）。
  3. 二分交互（多轮）：
    • 初始挑战： 挑战者指出验证器提交的状态承诺的哪个部分可能有错误。
    • 范围缩小： 验证器回应，提供更多关于计算过程的细节，缩小有争议的计算范围。
    • 反复迭代： 挑战者和验证器之间会进行多轮交互，双方轮流指出或解释计算过程中的细节，不断缩小争议范围。
    • 关键点： 每一次交互都将有争议的计算范围减半，直到最后只剩下一个最小的计算步骤。
  4. 链上验证： 最终，争议被缩小到一个非常具体的计算步骤，这部分计算将被放在以太坊主链上执行，以确定是否真的存在欺诈。
  5. 仲裁： 如果链上执行结果与验证器声称的结果不符，则判定验证器存在欺诈，并将惩罚该验证器。如果链上执行结果与验证器声称的结果一致，则判定挑战者存在错误，并惩罚挑战者。

比喻：

这个过程类似剪刀石头布游戏：

  • 验证器： 就像玩家“宣称”自己出了剪刀，但实际上可能出了石头。
  • 挑战者： 就像玩家质疑对方“宣称”的结果，并试图找出对方作弊的证据。
  • 二分交互： 双方在游戏的过程中会不断地“试探”，逐步暴露双方的策略，最终将作弊的可能性缩小到最小。

通过这种多轮交互，Arbitrum 能够在保持以太坊安全性的前提下，大幅提高交易速度和降低交易成本。