Skip to content

easyshellworld.md

Latest commit

 

History

History
2031 lines (1625 loc) · 120 KB

easyshellworld.md

File metadata and controls

2031 lines (1625 loc) · 120 KB
timezone UTC+8

请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区

None

  1. 自我介绍: 无名的人阿！

我是这路上 没名字的人 我没有新闻 没有人评论 要拼尽所有 换得普通的剧本 曲折辗转 不过谋生 我是离开 小镇上的人 是哭笑着 吃过饭的人 是赶路的人 是养家的人 是城市背景的 无声 我不过 想亲手触摸 弯过腰的每一刻 留下的 湿透的脚印 是不是值得 这哽咽 若你也相同 就是同路的朋友

  1. 你认为你会完成本次残酷学习吗？ 坚持一下呗！

  2. 你的联系方式:

Notes

2025.03.10

重走学习路

  • 主要针对：https://epf.wiki/#/eps/week1第一周内容进行学习
  • 回顾uinx UNIX 是一种多用户、多任务、文件系统、模块化、权限管理的操作系统。
    • 从而衍生出来设计理念：

    “小而精”（Do One Thing and Do It Well）：每个程序应该只做一件事，并且做到极致。 “一切皆文件”（Everything is a File）：设备、进程、网络等都用文件表示，统一操作方式。 “管道”机制（Pipes & Filters）：将多个小程序组合，利用 |（管道）连接，使数据流动，提高灵活性。 模块化设计：程序可以像乐高积木一样组合使用，而不是一个庞大复杂的单体程序。

  • 非对称加密 使用一对密钥：公钥用于加密，私钥用于解密，解决了对称加密中密钥分发的难题，允许安全的通信和身份验证。此外，非对称加密支持数字签名功能，发送者使用私钥签名，接收者使用公钥验证签名的真实性和完整性。其他功能与应用包括：密钥交换，例如ElGamal加密算法用于安全地交换对称加密所需的密钥；基于身份的加密，通过将用户的身份信息直接用作公钥，简化密钥管理过程，如组合公钥（CPK）是一种基于标识的非对称公钥管理体制，能够通过微小的生成矩阵产生近乎无限的密钥，解决密钥管理中的规模化难题；椭圆曲线密码学（ECC），利用椭圆曲线数学结构，提供与传统加密算法相同的安全性，但使用更短的密钥长度，提高了效率，广泛应用于资源受限的环境，如移动设备和智能卡；最优非对称加密填充（OAEP），是一种与RSA加密一起使用的填充方案，通过添加随机性元素和防止部分解密，增强了加密的安全性。
  • 黄白书 以太坊是一个去中心化的平台，旨在支持智能合约和去中心化应用（dApps）的开发和运行。其核心架构包括以下关键组件：
    • 框架结构：
      • 账户： 以太坊支持两种类型的账户：外部拥有账户（EOA）和合约账户。EOA由私钥控制，主要用于用户发起交易；合约账户由智能合约代码控制，能够在接收到交易时执行特定代码。
      • 交易： 交易是从一个账户到另一个账户的信息传递，可能包含数据和价值转移。交易可以触发智能合约的执行，导致状态的改变。
      • 区块链： 以太坊的区块链由一系列区块组成，每个区块包含多个交易。区块按时间顺序链接，形成一个不可变的记录。
    • 状态机： 以太坊的状态机定义了系统的状态及其变化规则。系统状态由所有账户的状态组成，包括账户余额、存储数据等。每笔交易都会引起状态转换，新的状态取决于当前状态和交易的具体内容。
    • 执行层： 执行层负责处理交易和执行智能合约。以太坊虚拟机（EVM）是执行层的核心组件，能够解释和运行智能合约的字节码。EVM提供了一个沙盒环境，确保合约代码的执行不影响主机系统的安全性。
    • 共识层： 共识层确保网络中所有节点对区块链的状态达成一致。以太坊最初采用工作量证明（PoW）共识机制，要求矿工解决复杂的数学问题以验证交易和生成新区块。然而，随着以太坊2.0的推进，网络正逐步转向权益证明（PoS）机制，通过质押以太币来参与共识过程，提高网络的可扩展性和能源效率。

2025.03.11

2th

  • 路线图
    • 这个路线图展示了 以太坊（Ethereum） 的未来发展计划，包括多个主要阶段和改进方向。它分为 五大部分，分别代表以太坊的关键技术升级：

      1. The Merge（合并）

        • 已完成（2022 年 9 月）
        • 以太坊从 工作量证明（PoW） 过渡到 权益证明（PoS），减少能源消耗，并为未来扩展奠定基础。

      2. The Surge（激增）

        • 目标是 提高以太坊的交易吞吐量，主要通过 Danksharding 和 Rollups（汇总） 技术。
        • EIP-4844（Proto-Danksharding） 作为过渡阶段，引入“Blob 交易”，降低 Layer 2（如 Arbitrum、Optimism）的成本。

      3. The Scourge（净化）

        • 解决 MEV（最大可提取价值） 相关问题，确保网络去中心化和公平性。
        • 主要目的是减少矿工/验证者对交易排序的操控，并优化以太坊的 去中心化中立性。

      4. The Verge（边界）

        • 重点是 Verkle Trees（弗克尔树），优化存储和状态证明。
        • 使以太坊节点更轻量级，减少存储需求，提高验证效率。

      5. The Purge（清理）

        • 通过删除旧的历史数据，减少以太坊的 状态膨胀（State Bloat），提高节点同步速度和存储效率。

      6. The Splurge（锦上添花）

        • 其他改进和优化，确保以太坊运行更稳定和高效，比如 EIP-4337（账户抽象） 以及未来协议改进。
  • 客户端多样性 以太坊客户端多样性对于网络的安全性、去中心化和弹性至关重要。客户端是运行以太坊协议的软件，负责处理交易、验证区块和与其他节点通信。以太坊的客户端可以分为执行层（EL）和共识层（CL）两部分，执行层客户端如 Geth、Nethermind、Besu 和 Erigon，主要处理智能合约执行和账户状态，而共识层客户端如 Prysm、Lighthouse、Nimbus 和 Teku，负责验证区块和参与共识协议。客户端多样性能提高网络安全性，因为如果某个客户端占据主导地位，出现漏洞或遭受攻击时，可能会导致整个网络受损。通过分散使用多个客户端，即使某个客户端出现问题，网络仍能正常运行，从而增强网络的弹性。此外，去中心化程度也依赖于客户端的多样性，避免了单一客户端的集中控制。在现实中，过去以太坊的执行层主要依赖 Geth，而共识层则大多验证者使用 Prysm，导致集中化问题。因此，社区鼓励验证者和开发者选择不同的客户端，增强网络的去中心化和安全性。总的来说，客户端多样性是以太坊网络健康运作的基础。

2025.03.12

3th toaday is CL

  • CL共识层组成和运行方式 1. 信标链（Beacon Chain）：是CL的主要组件，于2020年12月启动，作为PoS共识机制的核心。 2. 验证者（Validators）：代替矿工成为网络安全的守护者，需要质押32个ETH才能成为验证者。 3. 委员会（Committees）：每个时隙（slot）随机选择的验证者小组，负责对区块进行投票。 4. 时隙和纪元（Slots and Epochs）： - 每个时隙持续12秒 - 32个时隙组成一个纪元（约6.4分钟） - 每个时隙由一个验证者提议新区块 5. 证明（Attestations）：验证者对区块有效性的投票。 6. 分叉选择算法（Fork Choice Rule）：用于确定最长合法链，目前使用LMD-GHOST算法。

  • 拜占庭协议在以太坊CL层的应用 拜占庭容错（Byzantine Fault Tolerance，BFT）在以太坊CL层的多个方面得到应用： 1. Casper FFG（Friendly Finality Gadget）： - 这是以太坊使用的BFT共识机制 - 当区块获得2/3以上验证者的投票时，会被标记为"确认的"（justified） - 当一个"确认的"区块的子区块同样被确认后，原区块变为"最终确定的"（finalized） - 这保证网络能够容忍最多1/3的恶意或离线节点 2. 同步委员会（Sync Committees）： - 负责为轻客户端提供更新，使用BFT机制确保信息准确性 - 每256个纪元（约27小时）更换一次 3. RANDAO机制： - 用于生成验证者选择的随机数 - 设计为抗拜占庭攻击，即使部分参与者是恶意的也能维持随机性 4. 惩罚机制（Slashing）： - 对违反协议的验证者实施经济惩罚 - 惩罚恶意行为（如同时为两个冲突区块投票） - 这部分解决了拜占庭将军问题中的"叛徒"问题 5. 分叉选择： - LMD-GHOST算法考虑验证者的投票权重 - 能够在存在拜占庭节点的情况下仍选择正确的链

2025.03.13

4th toaday is EL

  • EL定义 Execution Layer（EL）是以太坊架构中的关键组成部分，负责处理交易和执行智能合约。

  • EL构成部分 * EVM（以太坊虚拟机）： EVM是执行层的核心组件，负责在以太坊网络上执行智能合约。它提供了一个运行环境，使得智能合约能够以一致且可预测的方式执行。 * 交易池： 交易池存储待处理的交易，这些交易由网络中的节点收集，并等待验证和执行。 * 状态数据库： 该数据库记录了以太坊网络的当前状态，包括账户余额、智能合约代码和存储等信息。

  • 执行层的运作机制： * 接收交易： 用户发起交易，交易被广播到以太坊网络，并被节点接收到交易池中。 * 打包交易： 验证者从交易池中选择交易，打包成区块，并将区块提议给网络。 * 验证交易： 验证者验证交易的有效性，包括检查签名、账户余额等。 * 执行交易： 通过EVM执行交易，更新状态数据库中的相关信息。 * 添加区块： 验证者将验证通过的区块添加到区块链中，完成交易的确认。

  • 区块验证 共识层（CL）通过 process_execution_payload 函数验证区块的有效性，并将执行负载发送给执行层（EL）进行进一步验证。执行层通过状态转换函数（STF）执行区块交易，并更新 StateDB。验证过程包括检查区块头信息（如 gas 限制变化、EIP-1559 基础费用等）和执行交易。如果交易无效，则整个区块被拒绝。

  • 区块构建 建区块的过程涉及从交易池（tx pool）获取最高收益的交易，并依次执行直到达到 gas 限制。过程中，若某笔交易无效，会跳过该交易继续执行剩余交易。最终，Finalize 函数将所有交易整理成完整区块并返回。交易池按交易费用优先级排序，保证构建者最大化收益。

  • 进一步探讨 STF、EVM 和 P2P 协议 状态转换函数（STF）在 Geth 中的实现涉及 newPayload、insertBlockWithoutSetHead 等函数，它们执行区块并持久化区块状态。EVM 运行基于栈机，指令包括算术、位运算、环境信息、控制流、内存等。P2P 协议（devp2p）用于获取历史数据、同步待处理交易，并通过 Snap 同步机制高效获取链上状态，确保数据完整性和正确性。

2025.03.14

4th 测试与安全

  • EVM测试

    • 目的 确保每个执行客户端（Execution Client）都符合以太坊规范，否则可能导致链的分叉。
      • 以太坊执行层规范（Ethereum Execution Layer Specification）来源：https://github.com/ethereum/execution-spec-tests
    • 测试要素
      • Pre-state（前置状态）：描述以太坊链的状态，包括账户余额、nonce、代码和存储。
      • Environment（环境变量）：定义区块链状态，如时间戳、前区块哈希值、gas 限制等。
      • Transaction（交易）：测试区块链交互，涉及账户信息、交易金额、gas 限制等。
      • Post-state（后置状态）：修改或创建账户的最终状态。

  • EVM 测试格式

    • State Testing（状态测试）：使用 state root（状态根） 进行验证。
    • 预期结果：相同的输入应返回相同的 state root
    • Fuzzy Differential State Testing（模糊差分测试)：在基础交易上添加 FuzzyVM 生成的智能合约代码，检查所有客户端是否仍能返回相同的 state root。
    • Blockchain Testing（区块链测试）：需要完整区块测试（如 EIP-1559 基础费用计算）。
    • Blockchain Negative Testing（区块链负面测试）：向区块链添加无效区块，验证客户端是否能正确拒绝，并回溯到正确区块。

  • 主要测试网络

测试网 状态 共识机制 用途 启动时间 RPC 端点
Sepolia ✅ 运行中 权益证明（PoS） 推荐 dApp & 合约测试 2021 年 10 月 https://ethereum-sepolia.publicnode.com
Holesky ✅ 运行中 权益证明（PoS） 推荐 验证者、Staking & 共识测试 2023 年 9 月 https://ethereum-holesky.publicnode.com

2025.03.15

5th -又见路线图

以太坊发展路线图

以太坊的路线图旨在提升网络的可扩展性、安全性和可持续性，主要包括以下阶段：

  1. 合并（The Merge）：已完成的阶段，将以太坊从工作量证明（PoW）转向权益证明（PoS），提高了网络的能源效率和安全性。

  2. 涌现（The Surge）：目标是通过引入分片技术和改进的Rollup方案，将交易处理能力提升至每秒10万笔以上。

  3. 清除（The Purge）：旨在减少历史数据和技术债务，简化协议，降低节点存储需求，提升网络性能。

  4. 飞跃（The Splurge）：包括各种小的升级和优化，以确保网络的稳定性和性能。

这些阶段并非线性推进，许多改进是并行进行的，具体实施时间可能会根据研究和开发的进展而调整。

活跃的以太坊研究领域

以太坊社区积极参与多个研究领域，以持续改进网络功能和性能，主要包括：

  1. 共识机制研究：关注以太坊的权益证明机制，包括识别和修补漏洞、量化加密经济安全性、提高客户端实现的安全性或性能，以及开发轻客户端等。

  2. 执行层研究：涉及交易执行、以太坊虚拟机（EVM）运行和生成执行有效负载等领域。研究内容包括构建轻客户端支持、研究Gas限制以及引入新数据结构（如Verkle树）等。

  3. 客户端开发：将协议研究成果应用于以太坊客户端的开发，包括更新客户端规范和构建具体实现。

  4. 零知识证明和加密技术：零知识证明（ZKP）和加密技术对于构建以太坊及其应用程序的隐私性和安全性至关重要。零知识是一个相对年轻但发展迅速的领域，存在许多开放的研究和开发机会。 citeturn0search1

Blobspace与数据可用性 为解决可扩展性问题，以太坊引入了Blobspace的概念，特别是在EIP-4844（Proto-Danksharding）中。Blobspace旨在降低Rollup方案提交数据的成本，从而提高网络的整体可扩展性。

以太坊的最终目标 Vitalik Buterin在《Endgame》一文中探讨了高交易吞吐量区块链的去中心化和抗审查性问题，提出了通过分层质押、引入欺诈证明或零知识证明、数据可用性采样以及次级交易通道等方式，确保即使在高交易量的情况下，区块验证仍然是信任最小化和高度去中心化的，同时防止区块生产者进行审查。

2025.03.16

6th-spec 规范

  • 以太坊共识规范（consensus-specs）

    • 具体内容：
      • 共识机制：详细描述了以太坊权益证明（Proof-of-Stake, PoS）共识机制的规则和协议。
      • 信标链规范：定义了信标链的结构、状态转换函数、验证规则等。
      • 验证者操作：规定了验证者的职责、激励和惩罚机制，以及验证者的生命周期管理。
      • 同步协议：描述了节点之间如何同步区块和状态，以保持网络一致性。
    • 关键要点：
      • PoS共识机制：通过质押以太币，验证者被选中提议和验证区块，取代了工作量证明（PoW）机制。
      • 信标链：作为以太坊2.0的核心链，协调分片链的共识和跨链通信。
      • 验证者激励：通过奖励和惩罚机制，确保验证者的诚实行为，维护网络安全性。
    • 规范的意义：
      • 标准化：提供了统一的共识协议规范，确保不同客户端实现的一致性。
      • 安全性：通过明确的规则和验证者管理，增强网络的安全性和可靠性。
      • 可扩展性：为未来的网络升级和功能扩展奠定基础。

  • 以太坊执行层规范（EEL-spec）

    • 具体内容：
      • 交易处理：定义了交易的格式、验证规则和执行逻辑。
      • 智能合约执行：描述了EVM（以太坊虚拟机）的操作码、执行环境和合约调用机制。
      • 状态管理：规定了账户模型、存储结构和状态转换函数。
      • Gas机制：解释了交易和合约执行的费用计算和Gas限制。
    • 关键要点：
      • EVM：作为以太坊的核心执行环境，负责智能合约的部署和执行。
      • 账户模型：以太坊采用账户余额和合约存储的状态管理方式。
      • Gas机制：通过费用机制，防止资源滥用，确保网络的健康运行。
    • 规范的意义：
      • 一致性：确保不同客户端在交易处理和合约执行上的行为一致。
      • 安全性：通过明确的执行规则，防范潜在的攻击和漏洞。
      • 开发指导：为客户端开发者和智能合约开发者提供清晰的参考。

  • 以太坊执行规范（execution-specs）

    • 具体内容：
      • 网络升级：记录并规范了以太坊各次网络升级（硬分叉）的具体内容和技术细节。
      • 协议变更：详细描述了每次升级中协议的修改，包括共识规则、EVM改进等。
      • 升级流程：定义了网络升级的提案、测试和部署流程。
    • 关键要点：
      • 网络升级：以太坊通过定期的硬分叉，引入新功能和改进，提升网络性能和安全性。
      • 协议变更：每次升级都会对协议进行调整，可能涉及Gas成本、操作码行为等方面。
      • 社区协作：网络升级需要开发者、矿工和用户的共同参与和协作。
    • 规范的意义：
      • 透明性：清晰记录协议的演进过程，增强社区信任。
      • 指导性：为客户端和dApp开发者提供升级参考，确保兼容性。
      • 安全性：通过规范的升级流程，减少潜在的分叉和网络分裂风险。

2025.03.17

7th-Reth client

  • Reth 客户端

    • 具体内容：
      • 以太坊执行层（EL）客户端：Reth 作为 Rust 实现的以太坊执行层客户端，支持 Engine API，与共识层（CL）兼容。
      • 轻量级、高效设计：Reth 采用 Rust 语言，专注于性能优化，目标是成为最轻量级、最模块化的以太坊节点。
      • 模块化架构：核心组件可单独使用，开发者可以灵活组合使用不同模块。
      • 自由开源：采用 Apache/MIT 许可，所有代码和设计均可公开访问和贡献。
    • 关键要点：
      • 兼容性：Reth 遵循以太坊协议标准，与主流共识层（CL）客户端无缝配合。
      • 高性能：借鉴 Erigon 的分阶段同步策略，提高节点运行效率。
      • 模块化：所有组件均可独立使用，开发者可根据需求自由调整。
    • 客户端的意义：
      • 促进客户端多样性：降低以太坊对 Geth、Nethermind 等客户端的依赖，增强网络稳定性。
      • 提高开发灵活性：为开发者提供灵活的 Rust 组件，支持自定义区块链应用。
      • 优化同步和存储：减少资源占用，提高节点运行效率。

  • Reth 设计和架构

    • 具体内容：
      • 核心架构：Reth 采用模块化设计，拆分不同功能组件，如数据库存储、EVM 执行、交易池管理等。
      • 存储优化：使用高效的数据结构（如 MPT、索引优化）来减少磁盘 IO，提高查询效率。
      • 同步模式：支持从创世块同步、快速同步，以适应不同场景需求。
      • Rust 生态：依赖 Alloy、revm 等 Rust 以太坊库，提升代码复用性和安全性。
    • 关键要点：
      • 模块独立性：每个组件都可以单独作为库使用，提高可维护性和扩展性。
      • 性能优化：利用 Rust 的并发特性和内存安全机制，提升执行效率。
      • 高可用性：优化存储和网络传输，降低运行成本，提高可靠性。
    • 架构的意义：
      • 增强可维护性：模块化架构便于开发者维护和扩展功能。
      • 提高效率：优化存储和同步方式，提升以太坊节点运行性能。
      • 支持多样化应用：可作为全节点、轻节点或离线数据索引器使用。

  • Reth 代码库概述、示例

    • 具体内容：
      • GitHub 代码库：Reth GitHub 提供完整的 Rust 代码实现。
      • 核心模块：
        • reth-node：完整的 Reth 节点实现，负责区块同步、交易处理等功能。
        • reth-db：存储模块，提供高效的数据库存储解决方案。
        • reth-primitives：封装了区块、交易、状态等基本数据结构。
        • reth-network：管理以太坊 P2P 网络连接，处理数据同步和消息传递。
      • 示例代码： 
        use reth_node::NodeConfig;
fn main() {
    let config = NodeConfig::default();
    println!("Reth 节点配置: {:?}", config);
}
    • 关键要点：
      • 代码结构清晰：核心模块独立，便于扩展和修改。
      • Rust 生态整合：充分利用 Rust 语言的安全性和性能优势。
      • 开发者友好：提供详细的文档和示例，方便开发者快速上手。
    • 代码库的意义：
      • 提供完整实现：让开发者可以直接运行 Reth 节点，或基于其代码进行二次开发。
      • 支持模块化使用：开发者可选择性地使用 Reth 的某些组件，而不必运行完整节点。
      • 提升 Rust 以太坊生态：为 Rust 开发者提供高质量的以太坊客户端代码库。

  • Reth 的特点和亮点

    • 具体内容：
      • 高效同步：采用优化的分阶段同步策略，减少存储占用和数据处理时间。
      • 轻量级设计：相比 Geth 和 Erigon，Reth 的存储和计算开销更低。
      • 模块化开发：所有核心功能均可独立使用，支持不同应用场景的定制开发。
      • 开源透明：代码完全开源，任何人都可以审查、修改和贡献。
    • 关键要点：
      • 速度快：优化同步和数据库访问，提高节点启动和运行效率。
      • 存储优化：减少磁盘占用，降低存储成本，提高数据检索性能。
      • 灵活扩展：可用于全节点、轻客户端或定制区块链应用。
    • 特点的意义：
      • 提升以太坊生态：提供更高效的客户端，实现网络去中心化。
      • 降低运行成本：减少存储和计算资源占用，提高运营效率。
      • 支持创新：开发者可以利用 Reth 的模块进行更多 Web3 应用开发。

2025.03.18

8th-Teku CL client

  • Teku CL 客户端概述

    • 具体内容：
      • GitHub 代码库：Teku GitHub 提供完整的 Java 代码实现。
      • 核心模块：
        • beacon-chain：实现信标链的核心逻辑，包括区块处理、状态管理和验证者职责。
        • validator-client：管理验证者的签名、密钥处理和提案任务。
        • networking：处理 P2P 网络通信，管理 Libp2p 连接。
        • storage：提供持久化存储，支持数据库备份和恢复。
      • 示例代码： 
        public class TekuExample {
    public static void main(String[] args) {
        System.out.println("Teku 客户端示例运行成功！");
    }
}
    • 关键要点：
      • 模块化架构：各核心模块独立，便于扩展和维护。
      • Java 生态整合：利用 Java 语言的稳定性和可移植性。
      • 企业级支持：由 ConsenSys 维护，适用于机构级 Staking 需求。
    • 代码库的意义：
      • 提供完整的共识层实现：支持以太坊 2.0 验证者运行和网络同步。
      • 支持模块化使用：开发者可灵活组合 Teku 的各组件。
      • 提升以太坊 PoS 生态：助力共识层客户端的多样化，增强网络安全性。

  • REST API 声明式框架

    • 具体内容：
      • Teku 提供 REST API，方便开发者远程访问信标链数据。
      • 核心 API 端点：
        • /eth/v1/beacon/blocks：获取最新信标链区块信息。
        • /eth/v1/validator/duties：查询验证者的职责。
        • /eth/v1/node/identity：获取节点身份信息。
    • 关键要点：
      • 标准化 API 设计，便于集成和扩展。
      • 提供 OpenAPI 文档，简化开发者对接流程。
      • 适用于 Staking 运营商，可远程监控和管理验证者。

  • 开发流程一瞥：EIP -> Spec -> Code

    • 具体内容：
      • Ethereum 改进提案（EIP）流程：
        1. EIP 提出：社区成员提出新特性（如 EIP-7251）。
        2. 规范（Spec）制定：编写详细技术规范，确保一致性。
        3. 代码实现：共识层客户端（如 Teku）根据 Spec 进行开发。
    • 关键要点：
      • 规范化开发流程：确保协议改进的一致性和可行性。
      • 社区驱动：开发者和研究人员共同维护。
      • 测试与审计：确保改动不会影响网络稳定性。

  • EIP-7251（maxEB） 示例

    • 具体内容：
      • EIP-7251 提出 maxEB（最大有效区块）的概念：
        • 允许共识客户端调整最大区块大小，提高吞吐量。
        • 影响区块验证逻辑，使其适应不同的网络环境。
      • Teku 代码实现：
        • 增加 maxEB 配置项，允许用户调整区块大小。
        • 变更信标链状态处理逻辑，使其兼容动态区块大小。
    • 关键要点：
      • 提高网络扩展性：适应不同 Staking 运营需求。
      • 灵活的区块大小控制，优化链上交易处理。
      • 与现有共识逻辑兼容，不会影响安全性。

  • 信标 API

    • 具体内容：
      • 信标 API（Beacon API）提供访问以太坊 2.0 信标链数据的能力。
      • 主要端点：
        • /eth/v1/beacon/states：获取信标链最新状态。
        • /eth/v1/validator/attestations：查询验证者的证明数据。
        • /eth/v1/node/peers：获取当前 P2P 连接的节点列表。
    • 关键要点：
      • 提供统一的 API 访问方式，兼容不同客户端（Teku、Lighthouse）。
      • 支持数据监控和分析，方便 Staking 运营商优化策略。
      • 适用于自动化管理，降低人工干预成本。

  • Lighthouse 共识客户端架构

    • 具体内容：
      • Lighthouse 是 Rust 实现的共识层客户端，与 Teku 类似。
      • 架构特点：
        • 模块化设计：独立的信标链、P2P 网络、存储等组件。
        • 高效性能优化：Rust 语言特性提升吞吐量和资源利用率。
        • 轻量级实现：适用于资源受限的环境。
    • 关键要点：
      • 与 Teku 形成对比，展示 Java 与 Rust 在共识客户端中的应用差异。
      • 强调安全性与高效性，适合不同以太坊 2.0 参与者。
      • 共识层的多样性，增强网络稳定性和去中心化。

  • 贡献者的 Teku 代码约定

    • 具体内容：
      • 代码风格：
        • 遵循 Java 最佳实践，代码清晰、易维护。
        • 使用 Checkstyle 和 SpotBugs 进行静态分析。
      • 开发流程：
        • 提交 PR 需通过 CI 测试。
        • 变更需要完整的单元测试和集成测试。
    • 关键要点：
      • 维护高质量代码，提高可读性和可维护性。
      • CI/CD 自动化，确保代码合规性。
      • 友好的贡献流程，降低新开发者的学习成本。

  • Teku 与合并，PEEPanEIP#83

    • 具体内容：
      • 以太坊合并（The Merge）：
        • Teku 作为共识层客户端，确保以太坊从 PoW 过渡到 PoS。
        • 需要与 Execution 层（如 Geth）保持同步。
      • PEEPanEIP#83：
        • 讨论 Teku 适配 The Merge 的过程。
        • 影响共识规则变更、状态转换和交易验证等关键技术点。
    • 关键要点：
      • Teku 在以太坊合并中的核心作用，确保 PoS 过渡顺利。
      • 与 Execution 层的交互优化，提升网络运行效率。
      • 技术社区的广泛参与，推动以太坊协议的演进。

2025.03.19

9th-kurtosis

  • 安装kurtosis CLI
echo "deb [trusted=yes] https://apt.fury.io/kurtosis-tech/ /" | sudo tee /etc/apt/sources.list.d/kurtosis.list
sudo apt update
sudo apt install kurtosis-cli

  • 本地测试

    • 启动本地开发网络(my-testnet为网络命名)： 
      kurtosis run --enclave my-testnet github.com/ethpandaops/ethereum-package
    • 访问服务Shell： 
      kurtosis service shell my-testnet el-1-geth-lighthouse
    • 连接到 Geth 控制台: 
      geth --datadir /data/geth/execution-data/ attach
    • 监听区块信息 
      var filter = eth.filter('latest');
filter.watch(function(error, result) {
    if (!error) {
        var block = eth.getBlock(result, true);
        console.log(block);
    }
});

  • 常用命令

    • 引擎管理

      • kurtosis engine status：查看当前 Kurtosis 引擎的状态。
      • kurtosis engine logs：查看 Kurtosis 引擎的日志。
      • kurtosis engine start：启动 Kurtosis 引擎。
      • kurtosis engine stop：停止 Kurtosis 引擎。
      • kurtosis engine clean：清理所有环境和关联资源，并停止引擎。

    • 环境管理

      • kurtosis run <package>：通过 GitHub URL 或本地路径启动指定的包。
      • kurtosis enclave rm -f <enclave-name>：删除指定名称的环境及其资源。
      • kurtosis clean -a：清理所有环境和资源。

    • 服务管理

      • kurtosis service shell <enclave-name> <service-name>：获取服务的 shell 访问权限。
      • kurtosis service logs <enclave-name> <service-name>：查看服务的日志。

2025.03.20

10th-Pre-reading

  • 定义 以太坊虚拟机（EVM）预编译合约是部署在特定地址上的原生合约，旨在提供高效的底层功能，如加密操作。这些合约直接在EVM中实现，以提高性能并降低复杂性。

  • 预编译合约的集成方式 预编译合约在EVM中以固定地址存在，通常从0x1到0x8，每个地址对应一个特定功能。例如，0x1地址对应椭圆曲线数字签名算法的公钥恢复功能（ecrecover），0x2地址对应SHA-256哈希函数。这些合约在EVM内部实现，开发者可以通过调用这些固定地址来使用相应功能。

  • 现有的预编译合约 根据EVM的规范，以下是一些常见的预编译合约及其对应功能：

    • 0x1：ecrecover，用于从签名中恢复公钥。
    • 0x2：sha256，计算SHA-256哈希值。
    • 0x3：ripemd160，计算RIPEMD-160哈希值。
    • 0x4：identity，返回输入数据本身。

  • L1和L2对预编译合约的使用 在以太坊第一层（L1）上，预编译合约被广泛用于执行复杂的加密操作，以提高效率并降低计算成本。在第二层（L2）解决方案中，预编译合约同样扮演重要角色。例如，Optimism的Bedrock升级中，L2账户可以通过调用预部署的Message Passer合约与L1合约交互，实现ETH从L2到L1的转移。

2025.03.21

11th-DAS

  • 以太坊可扩展性

    • 具体内容
      • 以太坊的扩展性挑战：
        • 计算能力受限，所有交易需由全网节点验证，导致吞吐量低。
        • 存储负担大，随着区块链增长，全节点存储需求持续增加。
        • 去中心化与扩展性的权衡，直接增加区块大小可能影响去中心化。
      • 扩展方案：
        • Layer 2 方案：如状态通道（State Channels）、Rollups（Optimistic Rollup 和 ZK-Rollup）。
        • 分片（Sharding）：以太坊 2.0 主要扩展方案，通过拆分多个并行处理的分片链提升性能。
    • 关键要点
      • 以太坊目前面临扩展性瓶颈，需要更高的吞吐量支持去中心化应用（DApp）。
      • 分片技术与 Layer 2 方案相结合，提高交易处理效率，同时保持去中心化和安全性。
      • Danksharding 方案的引入，进一步优化 Rollups 依赖的数据存储，降低 Layer 2 交易成本。

  • 分片的历史和前进的道路

    • 具体内容
      • 早期分片方案：
        • 参考传统数据库的分片概念，计划将计算、存储、交易执行拆分到多个分片链。
        • 早期架构较复杂，跨分片交易同步困难。
      • 分片架构的演变：
        • 早期设计（2018 年前后）：
          • 采用多层分片架构，每个分片链有独立的状态、交易和验证者。
        • 以太坊 2.0（2020-2022 年）：
          • 引入 信标链（Beacon Chain） 作为协调者，管理验证者和随机分片分配。
          • 逐步从 计算分片（State Execution Sharding） 转向 数据分片（Data Availability Sharding）。
        • 当前发展（2023+）：
          • 采用 Danksharding 方案，重点提升数据可用性，支持 Rollups 进行交易执行。
          • 通过 Proto-Danksharding（EIP-4844） 作为过渡方案，引入“Blob 交易”优化存储。
    • 关键要点
      • 以太坊分片架构经历了从计算分片到数据分片的演变，以适应 Layer 2 发展。
      • 信标链作为核心协调层，确保分片的安全性和验证者管理。
      • Danksharding 通过数据分片优化存储和处理能力，结合 Rollups 提升吞吐量。

  • 数据可用性

    • 具体内容
      • 数据可用性问题：
        • 如何确保分片区块的数据完整且可访问，即使部分节点离线或作恶。
        • 传统方案需要全节点存储所有数据，但这会影响扩展性。
      • 解决方案：
        • 数据可用性采样（DAS）：
          • 允许轻客户端只检查部分数据，利用概率机制检测数据完整性。
          • 结合 Erasure Coding（纠删码），即使部分数据丢失，也能恢复完整信息。
        • KZG 证明（Kate-Zaverucha-Goldberg Commitments）：
          • 通过数学证明，确保数据完整性，无需所有验证者存储完整数据。
        • Danksharding 方案：
          • 采用 Blob 交易 存储 Rollup 交易数据，减少以太坊主链存储负担。
          • 轻客户端可利用 KZG 证明和 DAS 验证数据，而无需下载完整数据。
    • 关键要点
      • 数据可用性是分片架构的核心问题，影响整个以太坊 2.0 的安全性和扩展性。
      • 数据可用性采样（DAS）结合 KZG 证明，实现高效的数据完整性验证。
      • Danksharding 通过优化数据存储方式，使 Layer 2 方案更加高效，降低 Rollups 交易成本。

2025.03.22

12th-Verkle Trees

  • The Verge：以太坊的未来阶段

    • 动机和好处
      • 动机：采用 Verkle 树的主要动机是实现无状态客户端，使节点无需存储完整状态即可验证交易，从而降低硬件要求，促进网络的去中心化。
      • 好处：
        • 减少证明大小：相比传统的 Merkle Patricia 树，Verkle 树的证明大小更小。例如，对于包含 10 亿个数据对象的树，传统 Merkle 树的证明大小约为 1 KB，而 Verkle 树的证明仅需不到 150 字节。
        • 提高验证效率：更小的证明尺寸和更高效的验证过程，有助于提升网络性能。

  • Verkle 密码学

    • Verkle 树：基于多项式承诺的树形结构，支持高效的证明和验证操作。与传统的 Merkle Patricia 树不同，Verkle 树使用多项式承诺来替代哈希函数，从而实现更小的证明尺寸和更快的验证速度。

  • 数据结构

    • 向量承诺（Vector Commitments）：
      • 允许存储在 Verkle 树中的数据被高效地验证，而无需下载整个树。
      • 通过多项式承诺确保数据完整性，并减少存储和计算成本。

  • Gas 定价

    • 影响：引入 Verkle 树可能影响以太坊的 Gas 定价模型。由于状态访问和修改的成本可能降低，Gas 费用可能需要重新评估，以反映更高效的状态操作。这有助于提高交易处理效率，降低用户成本。

  • 将状态树转换为 Verkle

    • 转换过程：将以太坊现有的 Merkle Patricia 树转换为 Verkle 树需要进行状态迁移。这包括重新构建状态树，并确保所有节点和客户端能够兼容新的数据结构。

  • 现状和挑战

    • 现状：截至目前，Verkle 树的研究和开发仍在进行中。
    • 挑战：
      • 兼容性：确保现有客户端和基础设施与新的数据结构兼容。
      • 安全性：验证新结构的安全性，防止潜在漏洞。
      • 性能优化：在实际应用中优化 Verkle 树的性能，以满足以太坊网络的需求。

  • 总结

    • Verkle 树通过减少状态证明大小，提高验证效率，使无状态客户端成为可能。
    • 未来以太坊将从 Merkle Patricia 树迁移到 Verkle 树，以降低存储需求并优化 Gas 费用。
    • 仍需解决兼容性、安全性和性能优化等挑战，以确保平稳过渡。

2025.03.23

13th-MEV

  • 以太坊中的 MEV、协议服务及其影响

    • 最大可提取价值（MEV）

      • 最大可提取价值（MEV）指的是区块生产者通过在区块中包含、排除或重新排序交易，所能提取的超出标准区块奖励和 Gas 费用的最大价值。
      • 在以太坊从工作量证明（PoW）转向权益证明（PoS）后，验证者取代矿工，负责交易的包含和排序。然而，MEV 的提取方式依然存在，可能导致抢先交易、交易费用增加等问题，影响网络公平性和用户体验。

    • 提议者与构建者分离（PBS）及相关提案

      • 提议者与构建者分离（PBS） 是一种提高以太坊网络可扩展性和安全性的机制。核心思想是将区块提议者和区块构建者的职责分离，分别负责提议新区块和构建区块内容。
      • 嵌入式提议者与构建者分离（ePBS）（EIP-7732）进一步将 PBS 机制直接集成到以太坊协议中，减少对第三方服务的依赖，优化区块验证过程，提高网络性能。

    • MEV 烧伤

      • MEV 烧伤是一种通过将部分 MEV 收益销毁来减少其负面影响的机制。
      • 该机制旨在降低验证者过度追求 MEV 的动机，维护网络公平性。然而，具体实施方案和效果仍在研究和讨论中。

    • 彩虹质押

      • 彩虹质押是一种多元化质押策略，允许验证者在不同的协议和链上分散其质押资产，以降低风险并提高收益。
      • 这种方法有助于增强网络的去中心化程度和安全性。

    • 分片的历史和前进的道路

      • 早期分片方案

        • 参考传统数据库的分片概念，计划将计算、存储、交易执行拆分到多个分片链。
        • 由于架构复杂，跨分片交易的同步存在困难。

      • 分片架构的演变

        • 早期设计（2018 年前后）：
          • 采用多层分片架构，每个分片链拥有独立的状态、交易和验证者。
        • 以太坊 2.0（2020-2022 年）：
          • 随着研究的深入，分片设计逐渐简化，强调数据可用性和跨分片通信的效率，旨在提高网络的可扩展性和用户体验。

2025.03.24

14th-Portal

  • 历史数据过期（History Expiry）

    • 历史数据过期允许节点删除它们不太可能需要的旧数据，只保留少量历史数据。这意味着节点在同步和服务数据请求时，只需处理最新的数据块，从而减少存储需求。然而，这也带来了需要从网络中其他节点请求已删除数据的挑战。为此，开发了门户网络（Portal Network），旨在通过点对点网络分发历史数据，使轻节点能够在无需信任全节点的情况下访问所需的数据，同时减轻全节点的负担。

  • 状态数据过期（State Expiry）

    • 状态数据过期使得不经常使用的状态数据变为非活动状态。这些非活动数据可以在需要时重新激活。这种方法有助于减少节点需要存储的活跃状态数据量，从而降低存储需求。与历史数据过期类似，状态数据过期也需要解决如何高效访问非活动数据的问题。

  • 弱无状态性（Weak Statelessness）

    • 弱无状态性意味着只有区块生产者需要访问完整的状态数据，而其他节点可以在没有本地状态数据库的情况下验证区块。这进一步减少了节点的存储和计算需求。然而，这要求区块生产者能够高效地访问完整的状态数据，并确保网络中的其他节点能够验证区块的有效性。

  • 强无状态性（Strong Statelessness）

    • 强无状态性是无状态性的最终形式，其中没有节点需要访问完整的状态数据。所有节点都可以在没有本地状态存储的情况下验证区块和交易。这种方法最大程度地减少了节点的存储和计算需求，但也面临着如何高效处理交易和区块验证的挑战。

  • 以太坊改进提案（EIP）标准

    • 以太坊改进提案（EIP）是对以太坊协议进行修改或扩展的建议。每个EIP都有一个状态，表示其当前的开发和审查阶段。常见的状态包括：
      • 草案（Draft）：提案正在开发中，等待进一步的审查和讨论。
      • 审查（Review）：提案已准备好进行同行评审。
      • 最后一次通告（Last Call）：提案进入最后审查阶段，通常持续14天。
      • 最终（Final）：提案已被接受为正式标准。
      • 停滞（Stagnant）：提案在草案、审查或最后通告阶段超过6个月没有活动，将被标记为停滞。
    • 此外，还有一些其他状态，如撤销（Withdrawn），表示提案已被作者或社区撤回；生效（Living），表示提案已永久生效，如EIP-1；过时（Obsolete），表示提案已被其他提案取代。

  • 过时的EIP标准

    • 随着以太坊的发展，一些早期的EIP可能已被新的提案取代或不再适用。例如，EIP-233曾建议将硬分叉管理和规范管理分开，但这一提案已被新的流程所取代。要查看当前有效的EIP列表，可以访问以太坊官方的EIP存储库。

2025.03.25

15th-SSF

  • Gasper 回顾

    • Gasper 是以太坊 2.0 信标链采用的权益证明共识协议的理想化版本。
    • 它结合了 Casper FFG（最终确定性工具）和 LMD GHOST（分叉选择规则），旨在平衡区块链的安全性和效率。
    • 设计目标是提供中等的最终确定时间、中等的链负载和中等的节点数量，以适应以太坊网络的需求。

  • Gasper 的问题和修复

    • 用户体验：当前区块需要约 15 分钟才能最终确定，用户不愿等待如此长时间。
    • 复杂性：混合机制增加了协议的复杂性，可能引入安全漏洞。
    • 短期重组风险：在最终确定之前，区块链可能发生短期重组，影响网络稳定性。
    • 修复方案：提出单时隙最终确定性（SSF）等改进方案，旨在减少最终确定时间，提高用户体验和网络安全性。

  • 单时隙最终确定性（SSF）

    • SSF 指在一个时隙内完成区块的提议和最终确定，避免当前约 15 分钟的延迟。
    • 实现 SSF 需要在去中心化、时间和计算资源之间进行权衡。
    • 通过优化认证处理方式，可以在不增加每个节点计算负担的情况下，实现更快的最终确定。

  • 分叉选择如何影响其他以太坊升级：PeerDAS 和 ePBS 案例研究

    • 分叉选择规则对以太坊的其他升级，如 PeerDAS 和 ePBS，有重要影响。
    • 这些升级旨在提高数据可用性和区块提议的效率，需要与现有的分叉选择机制兼容。
    • 在设计这些升级时，必须考虑分叉选择规则的特性，以确保网络的整体性能和安全性。

2025.03.26

16th-Gasper

  • Fork Choice 简介

    • 在区块链中，分叉选择规则用于在出现多个链分叉时确定哪条链是规范链。以太坊的信标链采用了特定的分叉选择算法来确保网络的一致性和安全性。

  • LMD GHOST

    • LMD GHOST（Latest Message-Driven Greedy Heaviest Observed Sub-Tree）是一种分叉选择算法。它通过选择具有最大证明累积权重的分叉作为规范链来运作。具体而言，该算法仅考虑每个验证者的最新投票（最新消息驱动），并选择最重的子树作为主链。citeturn0search0

  • Casper FFG

    • Casper FFG（Friendly Finality Gadget）是以太坊引入的一种最终确定性机制。它通过两步投票过程来实现区块的最终确定性：

      1. 一个区块必须获得总质押以太币三分之二的投票，才能被视为“合理”区块。
      2. 当一个合理区块上有另一个区块被合理化时，前者被升级为“最终确定”状态。citeturn0search0

    • 此机制确保了区块链的安全性，即除非攻击者控制或销毁大量质押的以太币，否则最终确定的区块不会被回滚。

  • Gasper

    • Gasper 是将 LMD GHOST 分叉选择算法与 Casper FFG 最终确定性机制相结合的共识协议。它结合了两者的优势，确保了以太坊权益证明区块链的安全性和活性。Gasper 定义了验证者如何受到奖励和惩罚，决定了接受和拒绝哪些区块，以及在区块链分叉上如何构建区块。

2025.03.27

17th-EVM

  • 以太坊状态转换 以太坊的状态转换过程由交易驱动，每笔交易都会修改全局状态。以太坊使用账户模型（而非UTXO模型），账户分为外部拥有账户（EOA）和合约账户（CA）。状态转换包括：

    • 验证交易签名
    • 计算交易费用并调整账户余额
    • 执行合约代码（如果涉及智能合约）
    • 更新全局状态（账户余额、存储等）

  • EVM 以太坊的核心是以太坊虚拟机（EVM），它是一个图灵完备的沙盒环境，运行智能合约的字节码。EVM 通过一系列操作码（opcodes）执行计算，并维护栈、内存和存储。

  • Ethereum 虚拟机 EVM 运行在所有以太坊节点上，负责处理交易、执行智能合约。主要特点：

    • 基于堆栈的执行模型
    • 256 位字长（适用于加密计算）
    • 访问权限控制（合约存储、外部合约调用）
    • 采用 gas 机制防止滥用计算资源

  • 内部呼叫 在 EVM 中，智能合约可以调用其他合约，称为内部调用（internal call）。内部调用主要方式：

    • CALL：普通调用，可修改状态
    • DELEGATECALL：调用另一个合约，但使用调用者的存储
    • STATICCALL：只读调用，不允许修改状态

  • GAS计量 EVM 使用 Gas 作为计算资源的度量单位，以防止无限循环和滥用。主要规则：

    • 每条指令消耗不同数量的 Gas
    • 存储、合约创建等操作消耗大量 Gas
    • 交易费用 = Gas 消耗 * Gas 价格
    • 未使用的 Gas 会退还给发送者

  • EVM 对象格式（EOF）简介 EVM 对象格式（EOF）是改进 EVM 执行模型的提案，旨在提高代码结构化、优化性能：

    • 规范合约字节码的结构
    • 提供更好的静态分析能力
    • 限制不安全操作（如 SELFDESTRUCT）
    • 可能引入新的验证规则以提升安全性

  • EVM 中的控制流 EVM 通过操作码控制代码执行流程，主要包括：

    • JUMP 和 JUMPI（条件跳转）
    • CALL 和 RETURN（合约调用与返回）
    • STOP、REVERT、SELFDESTRUCT 终止合约执行
    • EVM 执行时，每个指令会影响栈、内存或存储，从而改变合约状态

2025.03.28

18th-devp2p

  • EL 网络（EL networking） EL 网络指以太坊的执行层（Execution Layer）网络架构，负责处理交易执行和智能合约的状态管理。在以太坊的分层架构中，执行层与共识层（Consensus Layer）协同工作，共同维护网络的正常运行。

  • devp2p 规范（devp2p specs） devp2p 是以太坊的点对点（P2P）网络协议集合，定义了以太坊节点之间的通信方式。该规范包括多个低层协议，如 RLPx（负责加密和多路复用）、节点发现协议 v4 和 v5（用于节点发现）等。此外，devp2p 还定义了多个基于 RLPx 的应用层协议，如以太坊线协议（eth/68）、轻客户端协议（les/4）等。

  • 以太坊节点记录（ENR） 以太坊节点记录（Ethereum Node Records，ENR）是用于描述以太坊网络中节点信息的可扩展格式。每个 ENR 包含节点的公钥、IP 地址、端口等信息，并通过签名进行验证。ENR 提供了一种通用且向前兼容的结构，用于传递节点的元数据，支持通过多种渠道（如 DNS）传播节点信息。

  • 节点发现协议 v5（Discv5） 节点发现协议 v5（Discv5）是以太坊网络中用于节点发现的协议，基于 UDP 运行，旨在提高节点发现的效率和灵活性。Discv5 支持自认证的灵活节点记录（ENR）和基于主题的广告功能，满足以太坊网络的需求。

  • 子协议（Subprotocols） 子协议是构建在 devp2p 之上的应用层协议，定义了特定功能的通信方式。以太坊的子协议包括以太坊线协议（eth/68），用于区块和交易的传播；轻客户端协议（les/4），支持轻量级客户端访问区块链数据；快照协议（snap/1），用于区块链状态的同步等。这些子协议通过扩展 devp2p，实现了以太坊网络的多样化功能。

2025.03.29

19th-libp2p

  • CL 网络协议
    CL 网络协议主要指 libp2p 中用于连接建立、管理和升级的底层协议。它负责协调握手、加密和多路复用等关键环节，使得多个子协议能够在单一连接上共存，从而实现安全、稳定和高效的点对点通信。

  • libp2p
    libp2p 是一个模块化的点对点网络协议栈，由多个独立但互相协作的协议组成。它提供地址管理、节点发现、连接管理、安全传输、多路复用以及发布/订阅等功能，是构建去中心化应用的基础工具。通过抽象和分层设计，libp2p 能够适应各种网络环境和应用需求。

  • Yamux
    Yamux（Yet Another Multiplexer）是一种流多路复用协议，用于在单一传输连接上承载多个逻辑流。它设计简单高效，支持动态创建和关闭流，并具备流量控制和错误恢复功能，从而提高了连接的利用率和整体传输效率。

  • Noise
    Noise 是基于 Noise 协议框架的加密握手协议，主要用于在通信双方之间建立安全且经过认证的加密通道。其设计简洁且高性能，采用了现代密码学技术，确保数据在传输过程中的机密性和完整性，是 libp2p 中的重要安全协议之一。

  • GossipSub
    GossipSub 是 libp2p 实现的发布/订阅协议，采用基于 Gossip 的消息传播机制。它将推送和拉取相结合，通过节点之间的随机连接来高效分发消息，同时具备消息验证、节点评分和自适应传播策略，能够在大规模分布式网络中实现可靠且可扩展的消息传递。

  • exp code

// 示例1：创建一个基本的 libp2p 节点，使用 TCP 传输、Noise 加密和 Yamux 多路复用

import Libp2p from 'libp2p'
import TCP from 'libp2p-tcp'
import { NOISE } from 'libp2p-noise'
import Yamux from 'libp2p-yamux'

const createLibp2pNode1 = async () => {
  const node = await Libp2p.create({
    addresses: {
      // 监听所有 IP，TCP 端口由系统自动分配
      listen: ['/ip4/0.0.0.0/tcp/0']
    },
    modules: {
      transport: [TCP],
      connEncryption: [NOISE],
      streamMuxer: [Yamux]
    }
  })
  await node.start()
  console.log('节点启动成功，监听地址：', node.multiaddrs.map(addr => addr.toString()))
  return node
}

;(async () => {
  const node1 = await createLibp2pNode1()
  // 节点启动后，可通过 node1 进行拨号或接收连接
})()

2025.03.30

20th-Validator

  • Validator Client

    • Validator客户端是以太坊信标链网络中的核心组件，主要负责与其他节点进行数据交换和共识信息的传递。
    • 它运行在节点上，通过处理网络中的区块、执行验证任务来确保链上数据的一致性和安全性。
    • 客户端通常集成了对密钥管理和远程签名的支持，以保障签名操作的安全与高效。

  • Validator Service Initialization

    • 服务初始化阶段主要包括系统配置、网络连接以及密钥加载等工作，确保验证者能够正确接入信标链网络。
    • 在初始化过程中，会完成验证者密钥的解密与加载，配置远程签名API，并建立与其他网络节点的通信连接。
    • 同时，客户端会执行自检和同步校验，确保所有组件正常运行，以便在后续工作中及时响应网络共识事件。

  • Keystore Management

    • 密钥库管理是验证者操作中的关键环节，涉及验证者私钥的生成、加密存储与安全调用。
    • 通过采用加密的keystore文件和远程签名API，可以将私钥与签名操作隔离开来，从而降低密钥泄露风险。
    • 此外，密钥管理还要求定期备份和更新，加上对异常访问的监控，确保整个签名过程始终处于受控安全的环境中。

  • Performing Validator Duties

    • 执行验证者职责包括区块提议、区块验证和参与共识过程，是维护网络稳定与安全的基础工作。
    • 验证者在每个周期内需要按时签署区块和提交验证信息，确保网络中产生的共识数据正确无误。
    • 同时，验证者需要关注激励和惩罚机制，积极响应网络状态变化，避免因延迟或错误操作导致的经济损失。

2025.03.31

21th-Engine API

  • Engine API 的设计空间与历史

    Engine API 是以太坊节点中执行层（EL）与共识层（CL）之间的通信接口。自合并（The Merge）以来，该 API 成为以太坊架构中至关重要的组成部分，负责协调区块验证和区块提议等关键任务。理解其设计空间和演变历史，有助于深入掌握以太坊的运行机制。

    • 设计空间

      • Engine API 的设计经历了从最小功能集到复杂功能的渐进式扩展。
      • 初始设计包括基本的方法，如 engine_preparePayload 和 engine_getPayload，用于通知执行客户端即将需要提议区块，并在适当时机获取执行有效负载。
      • 随着需求增加，引入了异步处理、一致性检查点等机制，以增强 API 的扩展性和可靠性。
      • 例如，engine_consensusStatus 和 engine_executionStatus 方法用于在启动时进行一致性检查，确保执行层和共识层的区块树保持一致。

    • 历史演变

      • 在合并之前，执行层和共识层的通信相对简单。
      • 随着以太坊从工作量证明（PoW）过渡到权益证明（PoS），需要更复杂的交互。
      • Engine API 的开发旨在满足这一需求，提供了一个标准化的接口，支持两层之间的高效通信。

  • 执行层客户端在导入区块时的行为

    执行层客户端在导入区块时，需要与共识层客户端紧密协作，确保区块的有效性和链的连续性。以下是关键步骤：

    • 启动阶段

      • 当启动信标节点时，CL 会调用 EL 的 engine_exchangeCapabilities 和 engine_forkchoiceUpdatedV2 方法，交换支持的 Engine API 方法，并更新 EL 的分叉选择状态。

    • 区块构建

      • 当验证者被选中提议区块时，CL 调用 EL 的 engine_forkchoiceUpdatedV2 方法，传递 ForkchoiceState 和 PayloadAttributes，启动有效负载构建过程。
      • 随后，CL 调用 engine_getPayloadV2 获取构建的 execution_payload，将其整合到信标区块中，并计算 state_root，最终传播区块。

    • 乐观同步

      • 在某些情况下，EL 可能会以“乐观”方式导入区块，即在尚未完全验证执行有效负载的情况下，暂时接受区块。
      • 这种方式允许链的快速推进，但需要在后台继续验证有效负载的有效性。
      • 如果稍后发现有效负载无效，必须回滚相关区块，并通知 CL。

    • 错误处理

      • 如果 EL 在处理 engine_forkchoiceUpdatedV2 或 engine_newPayloadV2 时遇到错误，例如引用的有效负载无效，EL 会返回相应的错误状态。
      • CL 需要根据这些状态采取适当的措施，如重新同步或调整分叉选择。

    执行层客户端在导入区块时，遵循严格的验证和同步机制，与共识层客户端协同工作，确保以太坊网络的安全和稳定运行。

2025.04.01

22th-CL Data

  • CL DATA
    • 概述
      • CL DATA是指以太坊共识层（Consensus Layer）的数据结构和相关信息。
    • Beacon State
      • 定义
        • Beacon State是以太坊2.0中Beacon链的状态，包含链的当前状态信息。
      • 组成部分
        • 状态根（State Root）
          • 状态的哈希根，用于验证状态的一致性。
        • 区块根（Block Root）
          • 区块的哈希根，表示区块的唯一标识。
        • 其他组件
          • 包括验证者集合、随机数、投票信息等。
      • 功能
        • 维护和更新Beacon链的状态，支持共识协议的运行。
      • 相关提案
        • EIP-4788: 在EVM中暴露Beacon状态根
          • 提议在EVM中引入新的操作码，以获取Beacon链的状态根，支持智能合约验证Beacon链状态。

2025.04.02

23th-Cryptography/ecdsa

  • 椭圆曲线数字签名算法（ECDSA）
    • 简介
      • ECDSA（Elliptic Curve Digital Signature Algorithm）是一种基于椭圆曲线密码学的数字签名算法。
      • 相较于传统的数字签名算法（如DSA），ECDSA在提供相同安全级别的情况下，使用更短的密钥长度，提高了效率。
      • 1985年，数学家Neal Koblitz和Victor S. Miller独立提出了将椭圆曲线应用于密码学的概念。
      • 1991年，NIST开发了DSA算法，随后Scott Vanstone提出了基于椭圆曲线的ECDSA算法。
      • 1998年至2000年间，ECDSA被多个标准化组织采纳为标准，包括ISO 14888-3、ANSI X9.62、IEEE 1363-2000和FIPS 186-2。
      • 椭圆曲线
        • 定义在有限域上的椭圆曲线方程为：y² = x³ + ax + b，其中a, b ∈ F_q，且满足4a³ + 27b² ≠ 0，以确保曲线是非奇异的。
      • 有限域
        • ECDSA通常使用素数阶有限域F_p，其中p为大素数。
      • 基点（G）
        • 在椭圆曲线上选择一个基点G，其阶为大素数n，即nG = O，其中O是无穷远点。
    • 算法组成
      • 参数生成
        • 选择有限域F_q的阶q，以及表示方法FR。
        • 选择椭圆曲线参数a和b，确保曲线非奇异。
        • 计算曲线的阶N，选择一个大素数n，使得N能被n整除，并计算余因子h = N / n。
        • 选择基点G，使其阶为n。
      • 密钥生成
        • 随机选择私钥d ∈ [1, n-1]。
        • 计算公钥Q = dG。
      • 签名生成
        • 选择随机数k ∈ [1, n-1]。
        • 计算椭圆曲线点(kG)的x坐标x₁，令r = x₁ mod n。如果r = 0，重新选择k。
        • 计算消息m的哈希值e = H(m)。
        • 计算s = k⁻¹(e + dr) mod n。如果s = 0，重新选择k。
        • 签名为(r, s)。
      • 签名验证
        • 检查r和s是否在区间[1, n-1]内。
        • 计算e = H(m)。
        • 计算w = s⁻¹ mod n。
        • 计算u₁ = ew mod n和u₂ = rw mod n。
        • 计算点X = u₁G + u₂Q，设X的x坐标为x₂。
        • 验证v = x₂ mod n是否等于r，若相等，则签名有效。
    • 安全性分析
      • ECDSA的安全性基于椭圆曲线离散对数问题（ECDLP）的难解性。
      • 与传统的DSA相比，ECDSA在相同的安全级别下使用更短的密钥。例如，160位的ECDSA密钥提供与1024位RSA密钥相当的安全性。
    • 应用领域
      • ECDSA广泛应用于需要数字签名的场景，如SSL/TLS协议、加密货币（如比特币）中的交易签名等。
    • 注意事项
      • 随机数k的选择至关重要，重复或预测k可能导致私钥泄露。
      • 确保使用经过验证的椭圆曲线参数，以防范潜在的安全漏洞。

2025.04.03

24th-Cryptography/BLS

  • BLS签名算法概述

    BLS签名算法 是由斯坦福大学的Dan Boneh、Ben Lynn和Hovav Shacham于2001年提出的一种基于椭圆曲线密码学的数字签名方案。该算法以其短签名长度、快速验证和签名聚合等特性，在区块链、分布式系统和密码学领域得到了广泛应用。

  • BLS签名算法的基本组成

    • 参数选择

      • 选择一个大素数 $p$，定义三个循环群 $G_1$、$G_2$ 和 $G_T$，它们的阶为 $p$。
      • 定义一个双线性映射 $e: G_1 \times G_2 \rightarrow G_T$，满足以下性质：
        • 双线性性：对于所有 $P \in G_1$，$Q \in G_2$ 和整数 $a, b$，有 $e(aP, bQ) = e(P, Q)^{ab}$。
        • 非退化性：存在 $P \in G_1$ 和 $Q \in G_2$，使得 $e(P, Q) \neq 1$。
        • 可计算性：对于所有 $P \in G_1$ 和 $Q \in G_2$，$e(P, Q)$ 可有效计算。

    • 密钥生成

      • 随机选择一个整数 $x \in \mathbb{Z}_p^*$ 作为私钥 $SK$。
      • 计算公钥 $PK = x \cdot g_2$，其中 $g_2$ 是 $G_2$ 的生成元。

    • 签名生成

      • 对消息 $M$ 进行哈希，得到 $h(M) \in G_1$。
      • 计算签名 $\sigma = x \cdot h(M)$。

    • 签名验证

      • 验证等式 $e(\sigma, g_2) = e(h(M), PK)$ 是否成立。
      • 若等式成立，则签名有效；否则，签名无效。

  • BLS签名算法的特点

    • 短签名长度

      • BLS签名的长度仅为一个群元素的大小，通常为 48 字节（使用曲线 BLS12-381 时），远小于其他签名方案，如 ECDSA。

    • 快速验证

      • 验证过程主要涉及双线性映射的计算，计算复杂度较低，适合需要快速签名验证的应用场景。

    • 签名聚合

      • 多个签名可以聚合成一个签名，且聚合签名的大小与单个签名相同。
      • 验证聚合签名时，只需一次验证操作即可验证所有签名的有效性。

    • 确定性

      • BLS签名过程不使用随机数，对同一消息和密钥对，签名是确定的。

  • BLS签名算法的应用

    • 区块链验证

      • 在区块链网络中，BLS签名算法允许节点快速验证多个交易或消息。
      • 由于签名的可聚合性，多个签名可以合并为一个，从而减少验证所需的时间和计算资源。

    • 分布式系统

      • 在分布式系统中，BLS签名算法可以用于确保消息的完整性和真实性，同时减少通信开销。
      • 这对于需要高吞吐量和低延迟的应用尤为重要。

    • 物联网（IoT）

      • 在物联网设备中，BLS签名算法可以用于高效地验证大量设备的消息，同时节省宝贵的计算资源和能量。

    • 匿名凭证系统

      • 在需要保护用户隐私的应用中，BLS签名算法可以用于创建匿名凭证系统，允许用户向第三方证明其拥有某些属性，而无需泄露身份信息。

  • BLS签名算法的局限性

    • 计算成本

      • 虽然BLS签名验证过程相对高效，但双线性映射的计算仍比传统签名验证（如 ECDSA）更昂贵，尤其在硬件资源受限的设备上。

    • 恶意密钥攻击（Rogue Key Attack）

      • 如果攻击者控制部分公钥，可能伪造签名。解决方法是要求签名者提供“公钥知识证明”（Proof of Possession）。

    • 依赖特定椭圆曲线

      • BLS签名依赖支持配对的椭圆曲线（如 BLS12-381），这限制了其通用性。

2025.04.04

25th-Cryptography/Keccak256

  • Keccak256 简介
    Keccak256 是 Keccak 哈希函数家族中的一种，输出长度为 256 位。它被广泛应用于以太坊等区块链系统中，是 SHA-3 标准的一部分。Keccak 与传统 SHA 系列不同之处在于它采用海绵结构（Sponge Construction），提供更高的安全性和灵活性。

  • 海绵结构（Sponge Construction）
    Keccak 的核心设计是一种称为“海绵结构”的机制，包括以下步骤：

    • 初始化：状态变量通常为 1600 位（200 字节）
    • 吸收（Absorbing）：将输入数据与状态进行 XOR，并多轮调用 Keccak-f 函数混淆状态
    • 挤出（Squeezing）：从状态中提取固定长度的输出作为哈希值

  • 参数设置

    • 状态大小（state size）：1600 位（固定）
    • 输出长度（digest length）：256 位（Keccak256 指的是输出为 256 位）
    • 速率（r）：输入和输出的有效位数，Keccak256 中为 1088 位
    • 容量（c）：1600 - r = 512 位，用于抵御碰撞攻击和预映像攻击

  • Keccak-f 函数结构 Keccak-f 是状态变换函数，它对整个 1600 位状态进行迭代处理，分为 24 轮，每一轮包含以下 5 个步骤：

    • θ（Theta）：扩散操作，每一位都与其它多位组合
    • ρ（Rho）：位旋转
    • π（Pi）：位位置重排
    • χ（Chi）：非线性操作，当前位与同列其它位组合
    • ι（Iota）：添加轮常数，打破对称性

  • Keccak256 的应用

    • 以太坊智能合约：函数签名选择器、事件日志、地址计算等
    • 加密货币钱包：地址生成、私钥签名等
    • 数据完整性校验：Keccak256 可用于检测数据是否被篡改

  • Keccak 与 SHA3 的区别 尽管 Keccak 被采纳为 SHA-3 标准，但在一些实现细节上存在不同：

    • SHA-3 在最后添加了 padding 字节 0x06，Keccak 添加的是 0x01
    • 以太坊中使用的是原始 Keccak，而非严格意义上的 SHA3-256

  • 安全性分析

    • 输出为 256 位，抗碰撞强度为 2^128，抗第二原像攻击强度为 2^256
    • 截至目前，未有有效的攻击方法能破解 Keccak256，因此它被认为是安全的

  • Keccak256 的示例

    • 输入字符串 "hello" 的 Keccak256 值（以太坊风格）为：
      0x06d2c6d4107e0030ab6cba9de3a5c1a5c0e2a4d1e2e6e81b295f6b2f0b2e41b8
    • 常用的实现方式包括 web3.js、ethers.js、Python 的 pycryptodome、Go 的 sha3 包等

2025.04.05

26th-Cryptography/KZG

以下是对 KZG 承诺方案的详细分层介绍：

  • KZG简介

    KZG（Kate-Zaverucha-Goldberg）承诺方案是一种多项式承诺机制，允许承诺者对一个多项式进行承诺，并在稍后证明该多项式在特定点的评估值，而无需透露多项式的具体系数。 citeturn0search1

    该方案具有以下特性：

    • 生成的证明大小恒定（单个椭圆曲线群元素）。
    • 验证时间恒定（两个配对运算）。
    • 使用椭圆曲线配对作为其加密引擎。 citeturn0search3

  • 预备知识和符号

    在介绍 KZG 承诺方案之前，需要了解以下概念：

    • 椭圆曲线群：设 ( G_1 ) 和 ( G_2 ) 为两个阶为 ( p ) 的椭圆曲线群，具有非平凡的双线性映射 ( e: G_1 \times G_2 \rightarrow G_T )。设 ( g ) 为 ( G_1 ) 的生成元，( h ) 为 ( G_2 ) 的生成元。 citeturn0search1

    • 有限域：设 ( \mathbb{F}_p ) 为素数阶 ( p ) 的有限域。

  • 1. 信任设置（Trusted Setup）

    在进行任何 KZG 承诺之前，需要执行一次性的信任设置，包括以下步骤：

    1. 选择一个随机的域元素 ( \tau \in \mathbb{F}_p )。
    2. 设定要承诺的多项式的最大度数为 ( l )。
    3. 计算并公开以下值：( (g, g^\tau, g^{\tau^2}, \dots, g^{\tau^l}) ) 和 ( h^\tau )。

    需要注意的是，( \tau ) 的值应保持秘密，并在设置完成后销毁，以防止潜在的攻击或利用。 citeturn0search1

    为了在最小信任假设下进行信任设置，可以使用多方计算（MPC）技术，允许参与者共同生成必要的参数，而无需依赖单一的受信任实体。

  • 2. 对多项式进行承诺

    给定一个多项式 ( \phi(X) = \sum_{i=0}^{d} \phi_i X^i )，其中 ( d \leq l )，承诺者可以计算承诺值 ( c )：

    [ c = g^{\phi(\tau)} = \prod_{i=0}^{d} (g^{\tau^i})^{\phi_i} ]

    尽管承诺者不知道 ( \tau ) 的具体值，但可以利用信任设置中公开的参数计算上述承诺值。

  • 3. 生成评估证明

    为了证明多项式在某点 ( a ) 处的评估值 ( \phi(a) = y )，需要计算商多项式 ( q(X) )：

    [ q(X) = \frac{\phi(X) - y}{X - a} ]

    然后，计算评估证明 ( \pi )：

    [ \pi = g^{q(\tau)} ]

    该证明利用了多项式余数定理。

  • 4. 验证评估证明

    验证者拥有承诺值 ( c = g^{\phi(\tau)} )、评估值 ( y = \phi(a) ) 和证明 ( \pi = g^{q(\tau)} )。验证过程如下：

    1. 计算 ( g^{\tau - a} )。

    2. 验证以下配对等式是否成立：

      [ e(c / g^y, g) = e(\pi, g^{\tau - a}) ]

      展开后，可验证：

      [ e(g^{\phi(\tau) - y}, g) = e(g^{q(\tau)}, g^{\tau - a}) ]

      这实际上检查了在 ( X = \tau ) 处，商多项式的构造是否正确，即验证多项式余数定理是否成立。

  • 5. 批量证明

    可以对多个评估值 ( (\phi(e_i) = y_i)_{i \in I} ) 生成一个常数大小的批量证明 ( \pi_I = g^{q_I(\tau)} )，其中：

    [ q_I(X) = \frac{\phi(X) - R_I(X)}{A_I(X)} ]

    其中：

    • ( A_I(X) = \prod_{i \in I} (X - e_i) )
    • ( R_I(e_i) = y_i, \forall i \in I )

    ( R_I(X) ) 可以通过拉格朗日插值法在 ( O(|I| \log^2 |I|) ) 时间内计算得到。

  • 6. 验证批量证明

    验证者拥有承诺值 ( c )、评估值对 ( (e_i, y_i)_{i \in I} ) 和批量证明 ( \pi_I = g^{q_I(\tau)} )。验证过程如下：

    1. 计算累积多项式 ( A_I(X) = \prod_{i \in I} (X - e_i) ) 并生成其承诺值 ( a = g^{A_I(\tau)} )。

    2. 计算插值多项式 ( R_I(X) ) 使得 ( R_I(e_i) = y_i, \forall i \in I ) 并生成其承诺值 ( r = g^{R_I(\tau)} )。

    3. 验证以下配对等式是否成立：

      [ e(c / r, g) = e(\pi_I, a) ]

      该等式验证了在 ( X = \tau ) 处，商多项式的构造是否正确，从而确认所有评估值的正确性。

2025.04.06

27th-Cryptography/Post-Quantum

  • 后量子密码学概述

    • 后量子密码学（Post-Quantum Cryptography，PQC）旨在开发能够抵抗未来量子计算机攻击的加密算法。量子计算机有潜力破解当前广泛使用的公钥加密算法，如RSA和椭圆曲线加密（ECC），因此需要新的加密方法来确保信息安全。

  • 后量子密码学的目标

    • 量子抗性：开发对经典计算机和量子计算机攻击均安全的算法。
    • 性能：确保新算法在现有硬件上具有足够的效率，适用于实际应用。
    • 易于集成：设计易于整合到当前协议和系统中的算法，减少迁移成本。
    • 多功能性：提供适用于加密、数字签名和密钥交换等多种密码学需求的解决方案。

  • 后量子密码学算法的主要类别

    • 基于格的密码学

      • 数学基础：利用格结构中的难题，如最短向量问题（SVP）和带误差学习问题（LWE）。
      • 特点：
        • 提供强大的安全性证明。
        • 具有良好的效率和可扩展性。
        • 支持全同态加密等高级功能。

    • 基于编码的密码学

      • 数学基础：依赖于纠错码，特别是解码一般线性码的困难性。
      • 特点：
        • 长期以来的安全记录。
        • 缺点：公钥尺寸较大。

    • 多变量多项式密码学

      • 数学基础：求解有限域上多变量二次方程组的问题。
      • 特点：
        • 计算速度快。
        • 缺点：公钥尺寸大，实施复杂。

    • 基于哈希的签名

      • 数学基础：依赖于密码学哈希函数的安全性。
      • 特点：
        • 具有非常强的安全假设。
        • 可分为有状态和无状态操作。
        • 缺点：签名尺寸较大。

    • 基于同源性的密码学

      • 数学基础：利用椭圆曲线之间同源映射的困难性。
      • 特点：
        • 公钥尺寸小。
        • 目前尚不成熟，仍在积极研究中。
      • 示例：超奇异同源密钥交换（SIKE）。

    • 对称密钥的量子抗性

      • 方法：通过增加对称算法的密钥长度来抵御Grover算法的攻击。

  • NIST后量子密码学标准化计划

    • 概述
      • 美国国家标准与技术研究院（NIST）于2016年启动了后量子密码学标准化计划，旨在评估并标准化一种或多种抗量子攻击的公钥密码算法。
    • 目标
      • 识别安全算法：寻找能够抵御量子攻击的算法。
      • 标准化：开发新的标准以替代易受攻击的密码算法。
      • 行业采用：鼓励将这些算法整合到现有系统中。
    • 流程
      • 征集提案（2016）
        • NIST邀请提交抗量子攻击的密码算法提案。
        • 收到82个初始提交。
      • 评估轮次
        • 第一轮（2017-2019）：接受69个候选算法进行初步评估。
        • 第二轮（2019-2020）：根据安全性和性能缩小到26个候选算法。
        • 第三轮（2020-2022）：进一步缩小到15个决赛入围者（7个决赛入围者和8个替补）。
      • 评估标准
        • 安全性：对经典和量子攻击的抵抗能力。
        • 性能：计算效率，密钥和签名尺寸。
        • 实施考虑：易于实施，抵抗侧信道攻击。
        • 算法成熟度：分析和同行评审的程度。

2025.04.07

28th-EOA

  • 外部拥有账户（EOA）

    • 定义
      • EOA是以太坊网络中的基本账户类型，由私钥控制，可直接发起交易和签名消息。
    • 特点
      • 直接由用户控制，无需智能合约支持。
      • 只能执行基本的交易和合约调用，缺乏复杂的交易逻辑支持。

  • 账户抽象（Account Abstraction）

    • 概念
      • 账户抽象旨在统一以太坊账户模型，使EOA具备智能合约账户的功能，支持更复杂的交易逻辑和用户体验。
    • 潜力
      • 允许开发者将复杂功能（如自动交易、钱包恢复机制）直接集成到用户账户中，提升以太坊的可用性和安全性。

  • EIP-7702

    • 简介
      • EIP-7702由Vitalik Buterin等核心开发者提出，旨在通过优化账户抽象，加速以太坊的采用。
    • 主要特性
      • 无信任性：在单笔交易中临时分配智能合约代码给EOA，消除对中心信任点的需求。
      • 兼容性：与现有ERC-4337基础设施兼容，无需硬分叉或引入新操作码。
      • 基于功能的验证：紧密耦合验证（AUTH）和执行（AUTHCALL），简化过渡过程。
      • 未来可扩展性：确保与ERC-4337账户的向后兼容，降低技术债务。

  • 相关其他EIP

    • ERC-4337

      • 简介
        • 允许智能合约作为用户账户运行，使开发者能够构建复杂的交易逻辑和用户体验改进。
      • 局限性
        • 缺乏将EOA转换为智能合约账户的本地支持，向后兼容性差，交易成本高昂。

    • EIP-3074

      • 简介
        • 引入AUTH和AUTHCALL两个新的操作码，增强EOA功能，使其临时充当智能合约账户。
      • 局限性
        • 需要硬分叉并依赖调用者，可能导致中心化风险。

    • EIP-5003

      • 简介
        • 引入AUTHUSURP操作码，用于永久迁移EOA到智能合约账户。
      • 实现方式
        • 通过部署智能合约代码到EIP-3074授权地址并撤销原私钥访问，实现账户的永久迁移。

  • EIP-7702的优势

    • 无信任性
      • 通过在单笔交易中临时分配智能合约代码给EOA，消除了对中心信任点的需求，交易后消除任何访问或合约签名。
    • 兼容性
      • 与现有ERC-4337基础设施完全兼容，无需硬分叉或新操作码，实现EOA和智能合约账户之间的无缝工作。
    • 基于功能的验证
      • 设计紧密耦合验证（AUTH）和执行（AUTHCALL），减少干扰，简化过渡，降低开发者的学习曲线。
    • 未来可扩展性
      • 确保与ERC-4337账户的向后兼容，技术债务低，无需硬分叉进行维护，便于开发者构建长期解决方案。

2025.04.08

29th-EL Data

  • Merkle Patricia Trie（MPT）

    MPT结合了Merkle树和Patricia树的特性，提供了高效的键值存储和验证机制。在MPT中，每个节点都包含一个键、一个值以及到子节点的引用。这种结构允许以太坊以 O(log(n)) 的时间复杂度进行插入、查找和删除操作。

    • 账户存储中的Trie嵌套结构

      在以太坊中，每个账户都有自己的存储Trie，用于存储该账户的合约数据。这形成了一个“Trie中的Trie”结构，其中全局状态Trie包含每个账户的存储Trie的根哈希。

    • 状态根的定义及其作用

      状态根（State Root）是全局状态Trie的根哈希值。它提供了对整个以太坊状态的唯一加密摘要，使得任何对状态的更改都会导致状态根的变化，从而确保数据的完整性和可验证性。

    • 状态大小和性能随时间的挑战

      随着以太坊网络的增长，状态的大小也在不断增加，导致存储和检索的开销增大，影响了网络的性能。管理不断增长的状态数据成为以太坊面临的一个重要挑战。

  • 状态解决方案的演进：从基于哈希到基于路径

    为了应对状态大小和性能的挑战，以太坊社区提出并实施了多种解决方案。

    • 森林模型

      森林模型将状态Trie分解为多个子Trie，每个子Trie独立存储一部分状态数据。这种方法旨在减少单个Trie的大小，提高数据访问的并行性和效率。

      • 大小和性能限制

        尽管森林模型在一定程度上缓解了状态增长的问题，但它引入了额外的复杂性，并且在数据同步和一致性方面存在挑战。

    • Bonsai

      Bonsai是一种基于路径的Trie结构，旨在优化状态存储和检索。它通过减少冗余数据和优化节点结构，提高了存储效率和访问速度。

      • 路径基于Trie

        在路径基于Trie中，节点按照键的路径进行组织，减少了存储开销，并提高了查找效率。

      • 扁平数据库

        扁平数据库将Trie结构展开为键值对的形式，利用传统的数据库技术进行存储和检索，进一步提高了性能。

    • 其他存储模型

      其他存储模型包括Half-Path、Nethermind、Erigon/Reth的扁平数据库模型和Bonsai归档等。这些模型各有特点，旨在在不同的应用场景下优化状态存储和访问。

  • 状态管理中的挑战和解决方案

    以太坊在状态管理中面临多种挑战，并针对这些挑战提出了相应的解决方案。

    • 跨不同硬分叉的持续演进和历史准确性

      以太坊经历了多次硬分叉，每次升级都需要确保状态的连续性和历史数据的准确性。

      • 以Self Destruct为案例研究

        Self Destruct操作的处理在不同的硬分叉中有所变化，确保其在新旧版本中的一致性是一个挑战。

      • Snap Sync作为跳过历史的方法

        Snap Sync允许节点快速同步当前状态，而无需下载完整的历史数据，从而加快了新节点的同步过程。

    • 状态增长

      状态的持续增长对存储和检索带来了压力，需要有效的管理策略。

      • 随时间的大小和增长率

        随着时间的推移，状态的大小和增长率不断增加，对网络性能和存储资源提出了更高的要求。

      • 状态过期提案

        状态过期提案旨在移除长期未使用的状态数据，以控制状态的大小和增长。

    • 无状态性

      无状态性的概念旨在减少验证者需要存储的状态数据量，提高网络的可扩展性。

      • 提议与验证：状态与状态见证

        在无状态模型中，提议者提供交易和状态见证，验证者使用这些信息进行验证，而无需存储完整的状态。

      • MPT的证明大小

        MPT的证明大小影响了无状态模型的效率，优化证明大小是提高无状态性可行性的关键。

      • 基于向量承诺的Verkle/Starkle树

        Verkle和Starkle树利用向量承诺技术，提供更小的证明大小和更高的验证效率，被认为是实现无状态性的潜在解决方案。

2025.04.09

30th-Upcoming upgrades

  • 账户相关改进

    • EIP-7702：为交易设置EOA账户代码
      此提案允许外部拥有账户（EOA）在交易期间临时拥有与智能合约相同的功能，旨在增强账户抽象，提升用户体验和安全性。

  • 验证者相关改进

    • EIP-7251：增加最大有效余额
      将验证者的最大有效余额从32 ETH提高到2048 ETH，使单个验证者可以质押更多ETH，有助于简化操作并减少网络开销。

    • EIP-6110：在链上提供验证者存款
      该提案旨在改进验证者存款的处理方式，提升存款过程的效率和透明度。

    • EIP-7002：可触发的执行层退出
      允许验证者通过执行层触发退出，简化了验证者的退出流程。

  • 数据存储与处理改进

    • EIP-7691：增加Blob吞吐量
      将每个区块的目标Blob数量从3个增加到6个，最大值从6个增加到9个，以提高数据存储容量，降低Rollup费用。

    • EIP-7623：增加Calldata成本
      提高Calldata的费用，以鼓励使用更有效的Blob数据存储方式，优化网络资源利用。

  • 密码学相关改进

    • EIP-2537：BLS12-381曲线操作的预编译
      引入对BLS12-381曲线操作的预编译支持，提升相关密码学操作的效率和安全性。

    • EIP-7212：支持secp256r1曲线的预编译
      增加对secp256r1曲线的预编译支持，扩展以太坊对不同密码学曲线的兼容性。

  • 历史数据访问改进

    • EIP-2935：在状态中保存历史区块哈希
      建议在系统合约中存储最近8192个区块的哈希，支持无状态客户端更高效地访问历史数据。

  • 其他改进

    • EIP-7549：将委员会索引移出证明
      优化共识层数据结构，提升网络效率。

    • EIP-7685：通用执行层请求
      引入通用的执行层请求机制，增强执行层的灵活性和可扩展性。

    • EIP-7547：包含列表
      该提案的具体细节尚未明确，但被考虑作为Pectra升级的一部分。

    • EIP-7742：解除共识层和执行层之间的Blob计数关系
      旨在改进共识层与执行层之间的交互，提升网络性能。

2025.04.10

31th-Byzantine

  • 拜占庭协议概述

    • 拜占庭协议旨在解决分布式系统中节点可能出现任意（包括恶意）故障时，如何在所有非故障节点之间达成一致的问题。这一问题最初由Leslie Lamport等人在1982年的论文《拜占庭将军问题》中提出。

  • 问题定义

    • 在拜占庭将军问题中，若干将军围攻一座城市，他们通过信使传递消息，需要就进攻或撤退达成一致。然而，其中可能存在叛徒将军试图通过发送虚假信息来扰乱决策。目标是设计一个算法，使所有忠诚的将军能够达成一致，即使存在一定数量的叛徒。

  • 基本条件

    • 为了在拜占庭环境下达成一致，系统需要满足以下条件：
      • 一致性：所有非故障节点必须就相同的值达成一致。
      • 有效性：如果所有非故障节点的初始值相同，那么他们达成的一致值也应为该初始值。

  • 节点数量要求

    • Lamport等人的研究表明，在纯口头消息（无签名）的情况下，只有当系统中超过三分之二的节点是忠诚的，即总节点数n满足n > 3f（f为故障节点数）时，才能实现一致性。这意味着系统最多能容忍f < n/3个故障节点。

  • 消息传递模型

    • 拜占庭协议通常假设以下消息传递模型：
      • 同步模型：假设消息传递和处理在已知的有限时间内完成。
      • 异步模型：不对消息传递和处理时间设定上限，可能导致协议无法区分故障节点和仅仅是响应迟缓的节点。

  • 解决方案示例

    • 实用拜占庭容错（PBFT）：由Castro和Liskov在1999年提出，旨在在异步环境中实现高效的拜占庭容错。PBFT通过主节点提议、节点间投票等步骤，在最多三分之一的节点故障情况下，实现快速一致性。

  • 协议层次结构

    • 消息编码层：确保消息的完整性和真实性，防止篡改和伪造。
    • 共识算法层：实现具体的一致性算法，如PBFT、Raft等，处理节点间的消息交换和决策过程。
    • 应用接口层：为上层应用提供一致性服务的接口，屏蔽底层复杂性，方便开发者使用。

  • 性能优化

    • 为提高拜占庭协议的实际应用性能，研究者提出了多种优化措施：
      • 减少消息复杂度：设计高效的消息传递机制，降低通信开销。
      • 使用高效的加密技术：如消息认证码（MAC）替代传统的公钥加密，减少计算开销。
      • 批处理技术：将多个请求合并处理，提高吞吐量。

  • 实际应用

    • 拜占庭协议在多个领域有广泛应用：
      • 区块链技术：如Polkadot采用GRANDPA协议，实现快速最终确定性。
      • 分布式数据库：确保数据一致性和高可用性。
      • 云计算服务：提供容错和高可靠性的服务。

  • 挑战与未来方向

    • 尽管拜占庭协议在理论和实践上取得了重要进展，但仍面临以下挑战：

      • 扩展性：在大规模节点环境下，如何保持高效性和低延迟。
      • 动态成员变更：处理节点的动态加入和退出，保持一致性。
      • 抗攻击性：面对更复杂的攻击手段，增强协议的安全性和鲁棒性。

    • 未来的研究方向可能包括：

      • 结合机器学习：预测和检测恶意行为，提高协议响应能力。
      • 跨链协议：在不同区块链系统间实现一致性和互操作性。
      • 轻量级协议：为资源受限设备设计高效的拜占庭容错机制。

2025.04.11

32th-solc

  • 概述

    • solc 是以 C++ 编写的命令行 Solidity 编译器，负责将高层次的 Solidity 源代码转换为以太坊虚拟机（EVM）可执行的字节码，同时支持生成 ABI、AST、汇编和 Gas 估算等多种输出格式
    • solc-js 是基于 Emscripten 将 solc C++ 源码编译为 JavaScript 的版本，接口稍有差异但与 solc 保持功能兼容

  • 发展历史

    • 起源与首个版本
      • 2014 年 8 月，Gavin Wood 提出 Solidity 语言构想，2015 年 8 月发布首个 0.1.0 版本，开启了智能合约语言的新时代
    • 早期演进（0.1.x–0.4.x）
      • 引入基本类型、安全检查、ABI 编码器和优化器等功能，社区与核心团队持续完善语法和安全特性
    • 成熟阶段（0.5.x–0.8.x）
      • 0.5.x 系列强化类型系统与 ABI 接口；0.6.x–0.7.x 引入改进的错误处理和 Gas 优化；0.8.x 系列发布 IR 基于新代码生成器，并支持 EVM Object Format、Storage Layout Specifiers 等高级功能

  • 编译器架构

    • 核心组件

      • 词法分析器（Lexer）：将源代码分解为记号流
      • 语法分析器（Parser）：基于记号流生成抽象语法树（AST）
      • 语义分析：类型检查与符号解析，确保代码语义正确
      • 中间表示（IR）：支持经典 AST 到 Yul IR 或直接 IR 的转换，为优化与代码生成做准备
      • 优化器：在 IR 层进行常量折叠、函数内联、冗余消除等多轮优化，平衡部署成本与执行成本
      • 后端代码生成器：基于“旧代码生成”或“IR-based Codegen”将 IR 转换为 EVM 字节码

    • Yul 与 IR

      • Yul 是一种面向多后端的中间语言，设计目标包括可读性、易于验证与优化，并可独立使用或嵌入内联汇编
      • 通过 --via-ir 选项启用 IR-based Codegen，可实现跨函数的更强大优化和更透明的代码生成流程

  • 编译实现过程

    • 输入处理
      • solc 读取并预处理 .sol 文件，展开 import 路径与宏定义等
    • 词法分析
      • 将源代码字符流转换为标记（Token）序列，识别关键字、标识符、常量等
    • 语法分析
      • 基于 Token 序列构建 AST，表示合约结构、函数定义和表达式树等
    • 语义分析
      • 对 AST 进行类型检查、作用域解析与符号表构建，报告类型不匹配或未定义符号错误
    • IR 生成
      • 从 AST 生成 Yul 或自定义 IR，作为优化与代码生成的中间层
    • 优化
      • 在 IR 层执行多轮优化，包括常量折叠、死代码消除、函数内联和循环优化等，以降低字节码体积与 Gas 消耗
    • 代码生成
      • 根据启用的模式（旧代码生成或 IR-based Codegen）将优化后的 IR 转换为 EVM 字节码，并生成 ABI、源映射和其他输出文件

  • 未来发展情况

    • Solar 前端：Paradigm 推出的 Solar 作为高性能编译前端，已能解析、词法分析并生成 solc 兼容 ABI，性能超越 solc >41×，未来将补齐中端优化与后端代码生成
    • 持续优化：核心团队计划引入更智能的优化策略、支持更多 EVM 扩展格式，并改进多合约增量编译与缓存机制

2025.04.12

33th-EVM ASM

  • EVM内部字节码概述
    • 字节码结构
      • 创建字节码 (creation bytecode)：包含合约构造函数逻辑和参数，仅在部署时执行。
      • 运行时字节码 (runtime bytecode)：部署后存储在链上，用于合约调用执行，不包含构造逻辑。
      • 元数据 (metadata)：编译器生成的元数据附加在字节码末尾，用于ABI和调试。
    • 字节码格式
      • 由一系列opcode和立即数(PUSH)组成，每个opcode占1字节，PUSH后跟随相应长度的数据。
      • 采用256位大端栈机模型，使用256位字(word)进行运算。
  • EVM汇编演变
    • Yellow Paper原始汇编
      • 初始定义于Ethereum Yellow Paper，包括基本算术、逻辑、存储和控制流操作。
    • 独立汇编 (Standalone Assembly)
      • Solidity早期版本支持独立assembly文件，可生成EVM字节码。
    • Yul中间语言
      • 从Solidity 0.5开始引入，作为IR用于优化和inline assembly，支持多后端编译。
    • EVM对象格式(EOF)
      • EIP-3540引入EOF，将字节码分段并版本化，支持一次性部署时验证，便于EVM升级。
  • Solidity中使用汇编
    • inline assembly语法
      • 使用assembly { ... }块，在Solidity函数内部编写Yul代码。
    • 常用指令示例
      • mload/mstore：内存读写。
      • sload/sstore：存储读写。
      • let：定义局部变量。
    • 示例：retrieve函数 
      function retrieve() public view returns (uint256) {
    assembly {
        let v := sload(0)
        mstore(0x80, v)
        return(0x80, 32)
    }
}
    • 示例：store函数 
      function store(uint256 newValue) public {
    assembly {
        sstore(0, newValue)
    }
}

2025.04.13

34th-EVM EIP

  • Homestead (2016)

    • EIP-2: Homestead Hard-fork Changes – core protocol和gas调整
    • EIP-7: DELEGATECALL opcode – 引入DELEGATECALL，用于在被调用合约上下文中执行调用
    • EIP-8: devp2p Forward Compatibility – 网络层前向兼容性要求
    • 给Solidity带来变化:
      • address.delegatecall 在Yul/inline assembly中支持，方便实现代理合约逻辑
      • 无需变更语言层级，但优化了ABI编码和gas估算

  • Tangerine Whistle & Spurious Dragon (2016)

    • EIP-150: Gas cost changes for IO-heavy operations – 调整IO密集型操作gas成本
    • EIP-160: EXP cost increase – 增加EXP操作gas成本
    • EIP-161: State trie clearing – 清理空账户以释放状态树空间
    • EIP-170: Contract code size limit – 合约字节码大小上限24KB
    • 给Solidity带来变化:
      • gasleft() 全局函数用于获取剩余gas，替代旧的 msg.gas
      • 优化合约部署代码结构以符合字节码大小限制

  • Byzantium (2017)

    • EIP-100: Difficulty adjustment including uncles
    • EIP-140: REVERT opcode – 支持带错误消息的回滚
    • EIP-196 & EIP-197: alt_bn128 precompiles – 椭圆曲线加密原语
    • EIP-198: Big integer modular exponentiation precompile
    • EIP-211: RETURNDATASIZE & RETURNDATACOPY opcodes – 访问返回数据
    • EIP-214: STATICCALL opcode – 无状态调用
    • 给Solidity带来变化:
      • 引入 require 和 revert 语句，支持错误消息字符串
      • 支持 try/catch 及 RETURNDATASIZE/RETURNDATACOPY 用于动态返回数据处理
      • staticcall 在 view/pure 函数中自动使用，无需手动assembly

  • Constantinople & St. Petersburg (2019)

    • EIP-145: Bitwise shifting (SHL, SHR, SAR)
    • EIP-1014: CREATE2 opcode – 带salt的合约创建
    • EIP-1052: EXTCODEHASH opcode – 获取合约字节码哈希
    • EIP-1234: Difficulty bomb delay & block reward reduction
    • EIP-1283: Net gas metering for SSTORE (later replaced by EIP-2200)
    • 给Solidity带来变化:
      • 添加位移操作符 <<, >>，Solidity 0.5.0开始原生支持
      • 支持 new Contract{salt: bytes32 _salt}() 语法用于CREATE2
      • 引入 address.codehash 属性获取代码哈希

  • Istanbul (2019)

    • EIP-152: BLAKE2 F precompile
    • EIP-1108: alt_bn128 precompile gas cost reduction
    • EIP-1344: CHAINID opcode
    • EIP-1884: Reprice trie-size-dependent opcodes
    • EIP-2028: Calldata gas cost reduction
    • EIP-2200: Rebalance net-metered SSTORE gas cost
    • 给Solidity带来变化:
      • 全局变量 block.chainid 可直接访问链ID
      • 支持 ZK 相关预编译函数 pairing 等 via 内置库
      • calldata 参数成本下降，鼓励使用 calldata 修饰节省gas

  • Muir Glacier (2020)

    • EIP-2384: Difficulty bomb delay
    • 给Solidity带来变化:
      • 无直接语言层改动，仅影响网络难度调整

  • Berlin (2021)

    • EIP-2565: Modexp gas cost reduction
    • EIP-2929: Gas cost increase for cold access
    • EIP-2718: Typed transaction envelope
    • EIP-2930: Access list transaction
    • 给Solidity带来变化:
      • AccessList 交易类型支持需工具链升级后生效
      • 更新 sload/sstore gas 估算，影响合约调用成本

  • London (2021)

    • EIP-1559: Fee market change (base fee & tip)
    • EIP-3198: BASEFEE opcode
    • EIP-3529: Refund reduction
    • 给Solidity带来变化:
      • 全局变量 block.basefee 可访问当前区块基础费
      • 建议使用 tx.gasprice, tx.maxFeePerGas, tx.maxPriorityFeePerGas 管理费用

  • Shanghai (2023)

    • EIP-3651: Warm coinbase
    • EIP-3855: PUSH0 opcode
    • EIP-3860: Initcode size limit
    • EIP-4895: Beacon chain withdrawals
    • 给Solidity带来变化:
      • PUSH0 使Yul中可生成更紧凑字节码
      • 对初始化代码长度警告，Solidity v0.8+ 增加编译时检查

  • Dencun / Cancun (2024)

    • EIP-5656: MCOPY opcode – 高效内存复制
    • EIP-6780: SELFDESTRUCT only in same transaction
    • EIP-1153: Transient storage opcodes – TLOAD & TSTORE
    • EIP-4788: Beacon block roots contract
    • EIP-4844: Blob-carrying transactions
    • 给Solidity带来变化:
      • 在Yul中支持 mcopy(dst, src, length) 操作
      • selfdestruct 行为限制，建议使用更安全的清理模式
      • TSTORE/TLOAD 暂无原生支持，未来Solidity或扩展Yul
      • Blob交易类型不影响Solidity语法，但影响L2 Rollup数据可用性

2025.04.14

35th-L2 EIP

  • 交易类型与访问优化 Transaction Formats & Access Optimization

    • EIP-2718: Typed Transaction Envelope – 定义了一个新的交易类型“信封”，为未来事务类型（如访问列表和 EIP-1559 风格交易）提供扩展机制，奠定了 L2 特定交易格式的基础
    • EIP-2930: Access Lists – 为交易添加 accessList 字段，预声明的状态访问将以折扣气费执行，减少了 rollup 批量交易的成本

  • 数据与状态访问优化 Data & State Access Optimization

    • EIP-2028: Calldata Gas Cost Reduction – 将 Calldata 非零字节的气费从 68 降至 16，显著降低了 calldata 密集型 rollup 数据提交成本
    • EIP-7623: Increase Calldata Cost – 针对主要用于数据可用性的交易提高 calldata 气费（10/40），以减少最大区块大小波动，为增加 blob 容量腾出空间

  • 加密预编译合约支持 ZK Cryptographic Precompiles for ZK

    • EIP-196: alt_bn128 Precompiles – 添加椭圆曲线 alt_bn128 点加和标量乘法预编译合约，支持 zkSNARK 验证
    • EIP-197: Pairing Check Precompile – 添加针对 alt_bn128 曲线的双线性配对检查预编译合约，用于 zkSNARK 验证
    • EIP-1108: Reduce alt_bn128 Precompile Gas Costs – 降低 alt_bn128 预编译合约的气费，促进批量 zk-SNARK 验证和更广泛的私密协议部署
    • EIP-2537: BLS12-381 Precompiles – 引入 BLS12-381 曲线操作预编译合约，实现聚合签名验证，优化 L2 验证流程

  • 数据可用性增强 Data Availability Enhancements

    • EIP-4844: Proto-Danksharding (Blobs) – 引入临时“blob”交易类型，将 rollup 数据以短期存储形式提交，大幅降低 L2 数据发布成本
    • EIP-7691: Blob Throughput Increase – 将区块中 blob 的目标和最大数量从 3/6 提升至 6/9，提高 L2 数据可用性吞吐量
    • EIP-7742: Dynamic Blob Parameters – 使共识层和执行层能够动态设置 blob 目标和最大值，简化未来 blob 参数调整，无需硬分叉

  • 账户灵活性与抽象 Account Flexibility & Abstraction

    • EIP-1014: CREATE2 – 引入 CREATE2 操作码，支持合同地址的可预测部署，便于状态通道和 counterfactual 合约部署
    • EIP-3074: AUTH & AUTHCALL – 增加 AUTH 和 AUTHCALL 操作码，允许 EOA 授权智能合约代表其发起交易，推进执行层抽象
    • EIP-7702: Set Code Transaction – 定义新的 SET_CODE_TX_TYPE 交易类型，EOA 可指定委托代码，实现原生账户抽象与可组合性

  • 审查抵抗与交易包容性 Censorship Resistance & Inclusion

    • EIP-7547: Inclusion Lists – 提供“包含列表”机制，强制指定交易必须包含在区块中，提升 MEV-Boost 环境下的审查抵抗能力

  • 存储气费计量 Storage Gas Metering

    • EIP-2200: Net Gas Metering for SSTORE – 重新定义 SSTORE 的净气费计量，优化存储写入成本，为 rollup 状态更新提供更合理的气费模型

2025.04.15

36th-DEFI&EIP

  • DeFi 概述

    • DeFi 是一系列在以太坊上运行的、无需许可的金融产品和服务，任何拥有互联网连接的人都可参与，无需中心化中介，所有合约代码公开可审计，具有组合性与透明性。
    • DeFi 架构通常分层：
      • 基础层：以太坊区块链，提供去中心化账本与执行环境。
      • 协议层：各类通用金融协议（如交易、借贷、衍生品）。
      • 应用层：基于协议构建的前端或聚合器，面向最终用户。

  • 去中心化交易所

    • 自动做市商 (AMM)
      • 恒定乘积模型 (x × y = k)：Uniswap V2 中，每个交易对的两个资产储备量满足 x·y=k，当有交易时按此公式自动调整价格，无需订单簿。
      • 集中流动性 (Concentrated Liquidity)：Uniswap V3 允许做市商在自定义价格区间内提供流动性，分段常数乘积曲线提高资本效率。
    • 订单簿模型
      • 离线订单簿，链上结算：如 0x 协议，订单（Limit/RFQ/NFT）在链下生成、签名与传播，撮合后将订单与签名提交链上智能合约结算，实现 Maker/Taker 模式，降低 gas 成本。
      • 撮合机制：Maker 创建包含交易细节的 JSON 订单并签名，Taker 提交填单交易后，智能合约验证签名并原子交换资产。

  • 去中心化借贷

    • Compound 协议
      • 利率模型：基于资产利用率（utilization rate = 借出量/供应量），当利用率低于 kink 时按线性公式计算利率，超过 kink 时陡增，以平衡供需。
      • 利息计算：每秒按区块时间戳计提利息，APY 通过 (1 + ratePerBlock)^(blocksPerYear) – 1 计算，示例：blocksPerYear≈5×60×24×365。
    • Aave 协议
      • 双斜率利率模型：定义 optimal usage ratio，低于该值时按较低斜率增长，超过后按更高斜率增长；支持稳定利率与浮动利率两种模式。
      • 可选利率模式：借款人可在稳定利率与浮动利率间切换，智能合约自动处理利率转换与清算。

  • 以太坊支持与 EIP 标准

    • ERC‑20 (EIP‑20)：定义代币基本接口（totalSupply、balanceOf、transfer、approve、transferFrom、allowance），确保跨协议互操作性。
    • Permit (EIP‑2612)：扩展 ERC‑20，增加 permit 函数，允许用户通过 EIP‑712 签名离链批准，无需额外 on‑chain approve 交易，实现 gasless approvals。
    • Typed Data 签名 (EIP‑712)：规范结构化数据签名格式，为 Permit、meta‑transactions 等场景提供安全高效的离链签名方案。
    • 接口检测 (EIP‑165)：定义 supportsInterface(bytes4) 方法，标准化合约发布与检测所实现的接口，便于协议间功能兼容与自动化集成。
    • 费率市场 (EIP‑1559)：引入可变 Base Fee（按区块大小动态调整并烧毁）与 Priority Fee（小费），取代一价拍卖，提高交易费预测性并减少过度竞价。

2025.04.16

37th-GAMEFI&EIP

  • GameFi概述

    • 定义: GameFi是“游戏”（Game）与“金融”（DeFi）的融合，通过区块链技术为玩家提供可赚取经济激励的游戏体验。
    • 组成: 核心包含Play-to-Earn模型、NFT资产所有权和去中心化经济系统。

  • 分层架构

    • 链上层
      • EVM与共识: 基于以太坊虚拟机（EVM）执行智能合约，以太坊已转向PoS共识机制，确保安全性与去中心化。
      • 随机数算法: 使用RANDAO+VDF或Chainlink VRF提供可验证的链上随机性，保障游戏公平性。
    • 协议层
      • 游戏逻辑合约: 定义角色、战斗、升级等核心玩法，所有逻辑在链上执行，透明且可审计。
      • 资产管理: 通过ERC-721和ERC-1155标准实现NFT与半同质化代币的铸造、批量转移与元数据管理。
    • 跨链层
      • 跨链桥: 借助桥接协议（如Zaisan跨链桥、Chainlink跨链消息）实现资产与数据在不同链间的互操作性。

  • 关键算法实现

    • 随机数生成: Chainlink VRF通过生成带有加密证明的随机值，确保每次抽奖、掉落或属性分配的公平性。
    • 资产铸造与转移: ERC-721按需铸造独一无二的NFT，ERC-1155支持多种代币类型的批量操作，提高效率。
    • 经济激励模型: 结合代币发行、质押奖励与收益分配，实现玩家投入与回报的闭环。

  • Ethereum提供的支持与EIP标准

    • ERC-721: NFT基础标准，定义唯一代币接口，用于游戏角色与道具。
    • ERC-1155: 多代币标准，支持批量铸造与转移，适用于游戏中大量道具管理。
    • ERC-6551: Token Bound Accounts，为每个NFT绑定独立账户，使NFT能拥有资产与交互能力，丰富游戏角色功能。
    • EIP-3074: 允许外部拥有账户授权智能合约代为签名交易，实现燃气赞助与批量操作，优化用户体验。
    • EIP-4844: Proto-Danksharding引入临时数据“blobs”，显著降低Layer-2数据发布成本，提升跨链与扩容性能。
    • EIP-1559: 改革手续费市场，引入可销毁的基础费用和小费机制，提升费用可预测性与ETH通缩属性。

  • 安全与保障

    • 智能合约审计: 借助专业安全审计与形式化验证，降低漏洞风险，保障游戏资产安全。
    • 社区治理与EIP流程: 通过公开讨论、审查与核心开发者评审，确保EIP标准透明演进。
    • 基础设施支持: Geth、Nethermind等客户端与Infura、Alchemy节点服务，为GameFi提供稳定链上交互与高可用RPC支持。

2025.04.17

38th-Solidity 编译后结构

  • Standard JSON 输出
    • errors
      编译期间的错误、警告和提示信息。
    • sources 包含所有源文件的结构信息。
      • <sourceFile.sol>
        • id
          源文件的唯一标识。
        • ast
          源文件的抽象语法树。
    • contracts 每个源文件下包含一个或多个合约的编译结果。
      • <sourceFile.sol>
        • 编译后的合约结构。
          • abi
            合约的接口描述，供外部调用使用。
          • metadata
            编译元数据的JSON字符串，包含编译器设置、源文件、ABI等。
          • userdoc
            针对用户的文档（NatSpec）。
          • devdoc
            针对开发者的文档（NatSpec）。
          • ir
            中间表示（IR）代码。
          • irAst
            中间表示的AST。
          • irOptimized
            优化后的IR代码。
          • irOptimizedAst
            优化后IR的AST。
          • storageLayout 合约状态变量在存储中的分布。
            • storage
              状态变量名称、类型与slot映射。
            • types
              用到的所有结构类型定义。
          • transientStorageLayout 临时存储的布局信息。
            • storage
            • types
          • evm EVM相关输出。
            • assembly
              EVM汇编表示。
            • legacyAssembly
              旧版的汇编输出格式。
            • bytecode 编译后尚未部署的字节码。
              • functionDebugData
                函数调试信息。
              • object
                原始十六进制字节码。
              • opcodes
                字节码对应的操作码（人类可读）。
              • sourceMap
                源码到字节码位置的映射。
              • generatedSources 编译期间生成的源文件（如Yul代码）。
                • <Yul 文件>
                  • ast
                  • contents
                  • id
                  • language
                  • name
              • linkReferences 需要外部库链接的位置。
                • <源文件>
                    • start
                    • length
            • deployedBytecode 部署后合约的字节码。
              • object
              • opcodes
              • sourceMap
              • linkReferences
              • immutableReferences
                常量位置映射。
            • methodIdentifiers 函数签名与选择器映射。
            • gasEstimates Gas 估算信息。
              • creation 创建合约的gas消耗。
                • codeDepositCost
                • executionCost
                • totalCost
              • external
                外部函数调用的gas估算。
              • internal
                内部函数调用的gas估算。

2025.04.18

39th-类EVM异同

  • 编译层：Solidity → 字节码（Bytecode）

    • Ethereum、BSC、Polygon、Avalanche C-Chain、Fantom Opera等都支持 Solidity 编译为 EVM 字节码，通常使用的编译器通常为Solc.
    • 相同点
      • 编译器一致（solc / hardhat / foundry 等），输出相同的 EVM 字节码。
      • ABI、合约结构、函数签名等标准完全兼容。
      • 支持的语言特性（如 Solidity 0.8.x 的 SafeMath 内置）是一致的。
    • 差异 “编译”阶段大致无差异，但合约部署后是否能正确执行，取决于链的 VM 实现是否完全等效于EVM。

  • 执行层：字节码在 VM 中的执行

    • 虽然这些链都“兼容 EVM”，但其对 EVM 的实现方式可能不是完全一致：
链名 EVM 实现 opcode 支持 Gas 模型差异 调试一致性
Ethereum 原生 EVM（官方） ✅ 全支持 ✅ 基准模型 ✅ 完整一致
BSC Geth fork → 自建 VM ✅ opcode 基本一致，但 Gas 更低 ❗️Gas 计价更便宜，可能导致 DoS 吞吐异常 ⚠️ 某些内置合约行为有差异
Polygon PoS EVM-compatible ✅ opcode 支持 ⚠️ Gas 成本更低；某些链上 precompile 调用行为不同 ⚠️ 调试中 gas 消耗与 Ethereum 不一致
Avalanche C-Chain 运行 EVM on Avalanche VM ✅ opcode 支持较全 ⚠️ 更高 TPS 下处理更快；Gas 参数由 subnet 决定 ⚠️ 某些 gas-intensive 合约行为差异
Fantom Opera 自研 Lachesis VM + EVM runtime ⚠️ 部分 opcode 存疑 ⚠️ 自定义 Gas 机制、异步事件队列 ❗️调试不完全一致，可能有执行顺序差异
  • 内置合约与 Precompiles

EVM 规定了一些内置合约（如 0x01 ~ 0x09），各链在此基础上可能：

  • 添加额外 precompiles（例如 zk-friendly 合约、跨链桥合约等）
  • 修改 gas 价格，例如：
    • SHA256 合约在以太坊成本较高，在 BSC 可能更便宜；
    • BSC 为提升吞吐而降低一些 precompile 的 gas 成本。

这种差异虽然不会导致合约无法部署，但可能造成预期性能、安全性和攻击成本不同。

  • Debug/Trace 执行差异

调试工具（如 Hardhat Trace、Tenderly、Foundry）在不同链上对执行行为的表现也可能不同：

  • Ethereum：Trace 完整准确，每个 opcode 执行细节可追踪。
  • BSC / Fantom：可能无法完整回放每一条指令，特别是 gas 少时。
  • Polygon PoS：调试稳定性强，但部分链上 tx 与 Ethereum 环境 gas 不对等。
  • Gas 模型差异（影响执行与合约设计）
  • Ethereum 采用最新 EIP-1559 BaseFee 模型；
  • BSC 没有 EIP-1559，仍使用老式 GasPrice 模型；
  • Polygon zkEVM 支持 EIP-1559，Polygon PoS 无；
  • Avalanche/Fantom 通常有自定义 gas 计价逻辑，可能造成交易在主网与其他链执行行为不同。

例如：

assembly {
  let success := staticcall(gas(), someAddr, 0, 0, 0, 0)
}

这段代码在不同链上的执行结果可能不同，因为 gas() 实际返回值不同。

链 编译兼容性 执行兼容性（opcode, precompile） Gas 模型 真正 EVM 等效？
Ethereum ✅ ✅ ✅ ✅
BSC ✅ ⚠️ opcode & gas 差异 ❗️ PoSA 下不一致 ❌
Polygon PoS ✅ ⚠️ precompile 可变 ⚠️ ❌
Polygon zkEVM ✅ ✅ 目标等效 ✅ ✅（官方声称）
Avalanche C‑Chain ✅ ⚠️ 自定义 gas 模型 ⚠️ ❌
Fantom Opera ✅ ❗️执行行为可能不同 ❗️ ❌

2025.04.19

40th-EVM Storage memory

  • EVM 状态层级概览

    • 存储（Storage）：持久化、非易失性，保存在节点本地数据库的 Merkle Patricia Trie 中
    • 内存（Memory）：易失性 byte 数组，交易执行时加载到内存并在结束后丢弃
    • 堆栈（Stack）：最多 1024 个 256-bit 元素，用于指令运算

  • Storage 存储模型

    • 采用 key-value 结构：key = keccak256(slot)，value 为 32 字节
    • 每个合约维护独立的 Storage Trie，其根哈希通过区块头 stateRoot 链接到全局状态树
    • Storage 保存在节点本地 LevelDB/RocksDB 数据库，区块只存 stateRoot 摘要

  • Memory 内存模型

    • 简单字节数组，可从任意偏移读写，大小按需扩展
    • 扩容 gas 成本由多项式函数计算，超过 704 字节后成本陡增
    • 交易执行结束后自动清空，不影响持久状态

  • EIP 标准演进

    • EIP-150：引入 63/64 规则，在跨合约调用时保留调用者 gas，防止 DoS 攻击
    • EIP-1884：重定价 trie 大小依赖的 opcodes（BALANCE、SLOAD 等），平衡 gas 消耗与资源开销
    • EIP-2200：净 gas 计量（net gas metering）变更，结构化定义 SSTORE 费用，减少过高 gas 成本
    • EIP-2929：首次访问冷状态插槽时增加 SLOAD、CALL 等费用，保护节点免受状态访问 DoS 攻击
    • EIP-1967：标准化代理合约存储插槽，统一逻辑合约地址、管理员地址等信息位置

  • 与区块和链的关系

    • 区块头 stateRoot 字段存储全局状态树根哈希，用于验证和共识
    • 新区块执行交易后，节点更新本地状态数据库并计算新的 stateRoot，形成链式演变
    • 轻节点通过 stateRoot 与 Merkle 路径验证单个存储值，无需全量状态数据

  • 演变与实践

    • Yellow Paper 首次定义了存储、内存、堆栈三大区域及其 gas 模型
    • 随着网络规模和安全需求，EIPs 不断优化 gas 定价与存储访问，提升性能与抗攻击能力
    • 开发者应关注各版本 EIP 对合约设计的影响，如存储插槽冲突、代理模式、安全访问控制等

2025.04.20

41th-各链address兼容与转换

  • address兼容性问题
    • 地址编码格式：比如 Base58（Bitcoin、Solana）、Bech32（Cosmos、Bitcoin SegWit）、Hex（以太坊）。
    • 公钥哈希算法：不同链对公钥的哈希方式不同，如 sha256 + ripemd160（比特币） vs keccak256（以太坊）。
    • 前缀标识（版本字节）：用于标识地址类型和所属链，例如比特币地址以 1 或 3 开头，以太坊地址以 0x 开头。
    • 签名算法（曲线）：如 ECDSA（secp256k1），Ed25519，BLS 等。签名算法不兼容时地址基本无法转换。
  • 各主流链的地址格式
链 签名算法 地址格式 说明
Bitcoin ECDSA/secp256k1 Base58Check P2PKH/P2SH/Bech32 支持
Ethereum ECDSA/secp256k1 Hex（0x前缀） keccak256(publicKey)[12:]
Solana Ed25519 Base58 公钥直接编码
Tron ECDSA/secp256k1 Base58Check 与 ETH 结构相似，前缀不同
Cosmos系链 ECDSA/secp256k1 Bech32（如 cosmos1...） 公钥哈希后编码
Polkadot sr25519/ed25519 Base58 + SS58 有链特定前缀（network ID）
Aptos/Sui Ed25519 Hex（无前缀） 公钥哈希或直接取前几位

  • 常见的地址转换与映射方式

    • Tron <-> Ethereum

      • Tron 地址其实和 Ethereum 结构上是兼容的，只是前缀不同：

        • ETH 地址：0x + keccak256(pubkey)[12:]
        • TRON 地址：Base58Check(0x41 + ETH地址后20字节)

      • 转换方式（代码示例）：

        // ETH => Tron
function ethToTronAddress(ethAddress: string): string {
  const hex = ethAddress.replace(/^0x/, '');
  const tronHex = '41' + hex;
  const bytes = Buffer.from(tronHex, 'hex');
  const hash = sha256(sha256(bytes));
  const checksum = hash.slice(0, 4);
  const base58 = base58Encode(Buffer.concat([bytes, checksum]));
  return base58;
}

      • 注意：Tron 默认地址前缀是 41，Base58Check 编码后才变成以 T 开头的地址。

    • Cosmos / Polkadot 系链（Bech32 / SS58）

      • 这类链支持多前缀，地址转换时要重新编码：

        • Cosmos 使用 Bech32（如 cosmos1...，osmo1...）
        • Polkadot 使用 SS58（带不同链的网络 ID）

      • 常用工具：

        • Cosmos：使用 bech32 库（如 bech32.encode(prefix, words)）
        • Polkadot：使用 @polkadot/util-crypto 的 encodeAddress(pubkey, prefix)