solidity 编程

以Web3方式构建AI代理 - 0G

视频 AI 总结： 0G 是一个为链上 AI 打造的 Layer1 区块链，兼容 EVM，提供存储、数据可用性层、计算和服务市场四大模块。它支持高效存储大规模 AI 模型、实现可验证推理（通过 TEE 环境）和链上微调，并拥有 ERC-7857 标准为 AI 代理赋予身份。目前主网已上线，具备高吞吐量和低延迟。本次黑客松设有总计 $15,000 的赏金，分为开放云代理、DeFi 应用和 Wildcard 三个赛道。参赛者可利用官方文档、Builder Hub 和 Telegram 群获取资源与支持。 关键信息： 1. Zero-G 是 EVM 兼容的 Layer1 AI 区块链，主网已于 2024 年 9 月启动。 2. 核心组件：内置存储（成本比 AWS S3 低 95%）、高吞吐 DA 层（50 Gbps）、可信执行环境下的可验证推理、服务市场。 3. 创新标准：ERC-7857（INFTs）为 AI 代理提供链上身份。 4. 黑客松奖金：$6,000（开放云代理）、$6,000（DeFi 应用）、$3,000（Wildcard 赛道），总计 $15,000。 5. 支持无代码构建，提供 AI 上下文页面和 Starter Kit；可通过 Telegram 群获取测试代币和技术支持。

339 0 0 2026-06-11 23:37

VibeCoding: Gas 优化实践

视频 AI 总结：课程主要讲解NFT-Marketer合约的Gas优化，核心是通过存储布局合并，将seller（address）和price（uint96）打包到一个存储槽，减少存储操作次数。此外还介绍了使用汇编直接读写storage slot、理解动态数组的链上存储方式，以及通过AI工具快速分析和对比Gas消耗。强调基础理解比死记硬背更重要。 关键信息： - 存储布局合并：address（160位）+ uint96 → 一个slot，可容纳高达7.9×10^28的价格，满足ETH等代币标价。 - 优化效果：list/unlist从两次存储变为一次，显著节省Gas。 - 错误定义优化：用自定义error代替字符串（4字节 vs 动态字符串）可节省Gas。 - 使用forge test --gas-report对比优化前后的Gas消耗。 - 汇编sload/sstore可直接读写指定slot，但面试中较少考察，更注重对EVM存储机制的基本理解。 - 动态数组的起始位置为slot的keccak256哈希，后续元素连续存放，可用getStorageAt按偏移量读取。

8 0 0 2026-06-04 10:59

EVM 执行机制与存储布局

视频 AI 总结： 本视频深入讲解了EVM（以太坊虚拟机）的存储布局机制及其对合约执行和gas优化的影响。核心内容包括EVM执行合约的流程、不同存储空间（存储、内存、栈、临时存储）的特点与成本，以及如何通过结构体合并、动态数据存储布局等技术降低gas消耗。此外，还介绍了使用内联汇编进行极简转账的底层实现，并强调了代码可读性与gas优化之间的权衡。 关键信息： 1. EVM执行合约时，数据存储在storage（永续）、memory（临时）、stack、transient storage（瞬时）等空间，其中storage成本最高。 2. 冷数据（从0变为非0）初始化gas昂贵，热数据读写相对便宜。 3. 使用结构体将常一起使用的变量合并到一个槽位可减少存储读写次数，但需注意函数单独读取时的额外开销。 4. 瞬时存储（transient storage）在交易周期内有效，成本低于永久存储，适用于重入锁等场景。 5. 动态数据（mapping、动态数组）通过哈希方式离散存储，无法直接遍历；数组长度存储在变量槽位，数据从哈希起始位置连续存放。 6. 手写内联汇编可实现极致gas优化，但会降低代码可读性和审计友好性，需权衡。

23 0 0 2026-06-03 07:08

确保以太坊安全：ZK-EVM形式化验证项目

视频 AI 总结： 本视频中，Veridise的CEO Kostas Fernandes与以太坊基金会Alexander Higgs讨论了ZKVM验证计划。核心目标是确保ZKVMs（零知识虚拟机）的安全性，以支持以太坊L1的扩展。项目分为三个轨道：ZKVM电路、EVM访客程序和密码学证明系统，已取得显著进展，包括RISC-V电路的形式化验证和证明速度优化。最终目标是在2026年实现L1上的可选证明，并逐步过渡到强制证明，以提升性能和安全性，同时引入LLZK等工具链推动编译和验证的标准化。 关键信息： - ZKVM对以太坊扩展至关重要，可替代重执行，提高gas限值。 - 项目分三轨：验证ZKVM电路安全性、EVM访客程序的正确性、以及证明系统的形式化规范。 - 主要进展：RISC-V电路已针对SAIL规范完成形式化验证；证明时间从数月缩短至10周；预编译（如Keccak）验证取得成果。 - LLZK（基于MLIR的中间表示）用于统一电路编译，支持多DSL并集成验证后端。 - 目标时间线：2026年实现L1可选证明，2027-2028年实现强制证明。 - 未来影响：ZKVMs将改变执行层和共识层，可能推动EVM演变或直接支持RISC-V智能合约，编译器工具链成为关键。 Timestamps: 00:00 Introductions 00:16 What are the main goals of the Ethereum Foundation’s ZK-EVM Verification Project? 02:12 Current progress: what has been accomplished so far, and what’s coming next? 20:57 Deep dive into LLZK: Current use cases. What developers are building now and in the future? 32:47 Where to learn more about the mentioned LLZK projects and how to contribute? 34:20 The future of Ethereum, the EVM, and ZK-VMs: will users interact with ZK-VMs or L1 directly? 40:00 Could ZK-VMs eventually replace the EVM? 45:33 Closing remarks

263 0 0 2026-05-29 08:30

Onyx - 基于FHEVM的机密工资单

视频 AI 总结： 本视频由 Zcorp 的 CEO Thomas 介绍其项目 Onyx，这是一个利用全同态加密（FHE）实现链上机密金融流（Confidential Financial Flux）的平台。它允许企业以加密方式在链上发放工资或任何资金流，只有发送方和接收方能看到金额，公共链和智能合约均无法获取具体数值，从而解决了传统链上支付完全公开、易被竞争对手或员工反向工程的问题。视频通过演示展示了如何创建、解锁和取消加密流，并强调了其在 payroll、grants 和 TGE 解锁等场景的应用，与 Superfluid、Sablier 等公开方案相比，Onyx 增加了隐私保护，认为链上金融的未来必须兼顾隐私才能大规模采用。 关键信息： - 传统链上支付：完全公开，泄露工资单，竞争对手可逆向分析，员工可即时对比，DAO 无法保密。 - ONIX 方案：使用 FHE 加密金额，发送方和接收方解密后可见，合约执行时保持隐私。 - 技术特点：支持线性解锁、悬崖（cliff）、取消流（可放弃取消权）等灵活设置。 - 对比竞品（Superfluid、Sablier）：它们有机构合规和无信任执行，但完全公开；ONIX 在此基础上增加了隐私。 - 应用场景：工资发放、拨款管理（grants）、VC 代币解锁（TGE）等。 - 团队：Zcorp 致力于用新技术解决复杂问题。 - 核心论断：链上金融的未来需要隐私才能规模化。

92 0 0 2026-05-25 16:47

ERC20代币标准

视频 AI 总结： 视频主要讲解了以太坊开发中 ERC20 Token 标准的核心概念与实践。内容涵盖同质化资产（Token）与非同质化资产（NFT）的区别、ERC 标准与 EIP 提案的作用、ERC20 的标准接口定义（如 totalSupply、balanceOf、transfer 等），以及如何使用 OpenZeppelin 库快速实现 ERC20 Token。重点强调了 Token 与 ETH 转账的区别：ETH 余额存储在账户层，而 Token 余额存储在合约的 mapping 中；转账时目标合约的代码不会被调用，资金可能被锁死。还介绍了小数精度处理（乘以 10^18）及作业中的 token bank 实现要点（必须提供 withdraw 方法）。 关键信息： 1. ERC20 是代币标准，定义了统一的接口（name、symbol、decimals、totalSupply、balanceOf、transfer、transferFrom 等），降低沟通成本，增强互操作性。 2. EIP 是链改进提案（如 EIP-1559 修改手续费机制），由社区讨论、客户端实现；ERC 是应用层合约标准。 3. Solidity 不支持浮点数，用 uint 放大 10^18 倍表示小数（如 decimals 默认为 18）。 4. ETH 转账直接转给接收者地址，余额存在账户；Token 转账需调用合约的 transfer 方法，余额更新在合约内部的 mapping 中，目标合约不会触发 receive/fallback。 5. token bank 合约中，只有合约自身作为 msg.sender 调用 transfer 才能转出 Token，否则资金会永久锁死，必须实现 withdraw 方法。 6. 实现 Token 的核心逻辑：用 mapping 记录地址余额，转账做加减，并进行余额检查和零地址处理。

26 0 0 2026-05-16 10:06

ABI 与 Solidity底层调用

视频 AI 总结： 该视频深入讲解了 Solidity 中的 ABI 编码与底层调用机制，并介绍了 ERC20 相关基础知识。首先回顾了三种交易方式（普通转账、调用合约、创建合约），重点说明了调用合约时如何将函数选择器和参数编码为 ABI 数据。随后详细比较了底层调用 `call`、`delegatecall` 和 `staticcall` 的区别：`call` 切换上下文，`delegatecall` 保持当前合约上下文（常用于库和合约升级），`staticcall` 用于只读操作。此外，视频还介绍了 `library`（库）的两种使用方式（内联代码复制与委托调用）以及 `import` 语法用于代码组织。最后强调了利用 OpenZeppelin 等第三方库提高安全性和开发效率。 视频中提出的关键信息包括： 1. ABI 编码由函数选择器（函数签名哈希前4字节）和参数编码组成，用于在交易 data 中表示调用的函数。 2. 底层 `call` 允许直接传入 ABI 编码数据调用任意合约方法，类似反射机制，但需自行处理返回值。 3. `delegatecall` 不切换上下文，被调用函数的代码在当前合约存储中执行，常用于库和可升级合约模式。 4. 库（library）中的 `internal` 函数会被复制到调用合约中，而 `external/public` 函数则通过委托调用链接。 5. 鼓励使用经过社区审计的第三方库（如 OpenZeppelin）以避免重复造轮子和安全风险。

29 0 0 2026-05-16 10:03

Solidity详解：错误处理与接口继承

视频 AI 总结： 本视频主要介绍了 Solidity 中的修改器（Modifier）、错误处理、事件、接口和继承等核心概念。视频首先解释了修改器作为代码复用的语法糖，用于条件检查（如权限控制）。接着重点讲解了 Solidity 的错误处理机制，包括 require、assert、revert 和 try-catch 的用法，强调 EVM 交易的原子性（全部成功或全部回滚），并指出只有外部调用的错误才能被捕获。随后介绍了事件（event）作为链上日志记录的作用，以及索引（indexed）字段对日志查询的优化。最后讲解了接口（interface）用于抽象函数调用，以及继承（inheritance）和抽象合约（abstract contract）在编译时的代码复用，包括 virtual、override 和 super 关键字的使用。 关键信息： 1. **修改器（Modifier）**：一种语法糖，用于代码复用，常见于权限检查（如 onlyOwner）。编译时进行代码扩展，可能增加字节码大小。 2. **错误处理原子性**：EVM 交易具有原子性，出错时所有状态回滚到最初状态（与数据库事务类似）。 3. **错误处理方法**： - **require**：用于检查外部输入条件，不满足时抛出异常。 - **assert**：用于检查内部编码错误（如数组越界、除零）。 - **revert**：可携带错误消息或自定义 error（推荐使用 error 以节省 gas）。 - **try-catch**：仅能捕获**外部调用**（如其他合约的函数调用）产生的错误；内部调用、合约不存在、out of gas（非程序指定）等错误无法被捕获。 4. **事件（Event）**：用于记录链上日志，便于外部监听。其中 `indexed` 字段会存入 topic 建立索引，非 indexed 字段存入 data。 5. **接口（Interface）**：函数声明的抽象，用于编译时的类型检查。调用时依赖具体实例的合约地址，接口与实现合约之间不需要显式继承，只要函数签名匹配即可。 6. **继承与抽象合约**：继承是编译时的代码复用，部署时只有最终派生合约存在。使用 `virtual` 标记可重写函数，`override` 表示重写，`super` 调用父合约方法。抽象合约不能部署，专为代码复用设计。

35 0 0 2026-05-15 07:48

Solidity 详解：函数调用与特殊函数

视频 AI 总结： 视频主要讲解了 Solidity 中合约函数调用的两种方式——内部调用和外部调用，以及特殊函数（构造函数、receive、fallback）的触发条件与用途。内部调用在同一 EVM 环境，直接用函数名；外部调用需用合约地址，可用 this 或实例调用，并可指定 value 和 gas。构造函数仅在部署时执行，链上代码不含构造函数；receive 在合约接收普通转账（无数据）时调用，消耗 2300 gas；fallback 在调用不存在的函数时触发，也可在无 receive 时处理转账，常用于代理升级模式，转发所有调用。 关键信息： 1. 内部调用直接使用函数名；外部调用必须通过合约地址（如 this 或合约实例）。 2. 外部调用时可通过 value 和 gas 指定传递的 ETH 数量和 gas 上限。 3. 构造函数只在部署时执行，链上运行时代码不含构造函数；有参数的构造函数部署交易需包含参数编码。 4. receive 函数在合约接收无附加数据的转账（普通转账）时被调用，gas 限制为 2300。 5. fallback 函数在调用不存在的函数时触发，若无 receive 也会处理转账；常用于代理合约，将所有调用转发到实现合约，实现合约升级。

27 0 0 2026-05-15 07:45

VibeCoing：实现 Bank 合约

视频 AI 总结： 本节课讲解了上一节的 Bank 合约作业，利用 AI 工具（Codex）快速生成了包含管理员、存款（payable）、取款（transfer/call）及前三名排序功能的合约代码。讲师重点指出了常见错误：不必存储用户余额（账户自带余额），并且 view 函数不会降低其被调用的 gas 成本（内部计算量仍计入总 gas）。最后鼓励同学自行实践并理解合约的余额管理逻辑。 关键信息： - 使用 AI 辅助编写 solidity 合约，需提供上下文（如运行环境）以确保生成独立文件。 - 合约部署时管理员由 `msg.sender` 确定。 - 存款函数通过 `payable` 接收 ETH，用 `msg.value` 获取金额并存入 mapping。 - 取款时使用 `address(recipient).transfer()`（旧写法）或更推荐 `call{value: amount}("")`（解决 gas 限制问题）。 - 合约无需额外变量记录总余额或用户余额，链上每个账户已有 balance 属性。 - 在 public 函数内部调用 view 函数仍会消耗 gas，view 仅免除交易费中的 gas 价格部分，计算量 gas 不会消失。 - 避免冗余存储（如单独记录前三名数组），尽量复用已有数据，降低链上存储成本。

33 0 0 2026-05-15 07:42

Solidity基础：函数与变量

视频 AI 总结： 本视频主要讲解 Solidity 的基础语法，包括值类型、引用类型、映射类型、函数定义、可见性及状态可变性。Solidity 是静态编译型高级语言，专为 EVM 设计，语法类似 C++ 和 JavaScript。通过 Remix 工具演示了函数可见性（public、private、internal、external）和状态可变性（view、pure、payable）的实际效果，并强调了整数溢出在新版本中会被自动检查并 revert。 关键信息： - Solidity 是静态编译型语言，需先编译再运行。 - 函数可见性共有 4 种，public 内外可见，private 仅合约内部，internal 合约及继承访问，external 仅外部访问。 - 状态可变性：默认修改链状态；view 只读不写；pure 纯计算；payable 可接收 ETH。 - 值类型包含 bool、整数（uint/int）和地址类型（address/address payable），整数需注意位数和溢出问题（新版本自动检查）。 - address payable 才能接收转账，transfer 仅消耗 2300 gas。 - 常量有 constant（编译时确定）和 immutable（构造函数赋值），不占用存储空间。

55 0 0 2026-05-14 09:36

Solidity基础：合约类型与引用类型

视频 AI 总结： 视频围绕 Solidity 的 gas 机制与数据类型展开，重点解释了 `view`/`pure` 函数虽然不收取手续费（base fee 和 tips fee 为零），但本地执行仍需消耗计算 gas，并受 EVM gas 上限限制。随后系统介绍了地址类型、合约类型、枚举、值类型与引用类型（数组、结构体、映射）的用法，强调数据存储位置（memory/storage/calldata）的重要性。最后提醒开发者提前进行 gas 优化，避免因动态数组无限增长或不当操作导致合约失效。 **关键信息：** 1. `view`/`pure` 函数不支付网络手续费，但本地计算仍消耗 gas，受 EVM 限制（约 2^24 单位）。 2. 引用类型（数组、结构体）必须显式指定存储位置：状态变量默认 `storage`，参数默认 `calldata`，内部变量默认 `memory`。 3. 相同存储位置间赋值是引用，不同位置间赋值是拷贝（增加 gas 开销）。 4. 数组操作是单向的（从末尾 push/pop），删除中间元素推荐交换到末尾再 pop，以减少 gas 消耗。 5. 映射（mapping）只能作为状态变量，无法遍历，key 不能是复杂类型（数组等），但 string/bytes 可以。 6. 结构体常作为 mapping 的 value，实现类似数据库表的功能；结构体内不应包含 mapping。 7. 合约部署后不可修改，gas 优化必须在编码时前置考虑，避免循环依赖动态数组长度导致交易超出 gas 上限。

47 0 0 2026-05-14 09:35

以太坊核心概念与第一个合约

视频 AI 总结： 本视频系统介绍了以太坊的核心概念与创新。以太坊在比特币基础上加入了 EVM 虚拟机，支持链上运行通用程序（智能合约），实现了图灵完备。内容涵盖以太坊的诞生背景、POS 共识机制、EVM 执行流程、智能合约开发（Solidity 语言）、账户分类（外部账户与合约账户）、三种交易类型以及 Gas 收费机制（包括 EIP-1559）。通过 Remix IDE 演示了合约的编译、部署与调用过程，并强调了 EVM 的封闭性与确定性执行。 关键信息： 1. 以太坊核心创新：引入 EVM 虚拟机，支持在链上运行通用程序（智能合约），实现图灵完备。 2. 智能合约：用 Solidity 编写，编译为字节码后部署到链上，通过交易调用执行，所有节点重复执行以确保一致性。 3. 账户类型：外部账户（EOA，私钥控制）与合约账户（代码控制），合约只能被动执行，交易必须由 EOA 发起。 4. 交易类型：普通转账、合约部署（to 地址为空）、合约调用（to 地址为合约地址，附带 input data）。 5. Gas 机制：衡量每次计算的工作量，防止无限循环；EVM 每执行一个操作码就扣除对应 Gas，Gas limit 与 Gas price 需合理设置；EIP-1559 将费用拆分为基础费用（销毁）和小费（矿工），动态调节用户体验。 6. 共识机制：POS 通过质押以太坊随机选取区块提议者与见证者，降低能源消耗，出块时间约 12 秒。 7. 区块链浏览器：用于查看链上数据、交易状态与合约代码。 8. EVM 兼容链：如 BNB Chain、Base、Polygon 等，EVM 生态强大，合约可跨链部署。

110 0 0 2026-05-13 08:37

如何借助 AI 在以太坊上构建

视频 AI 总结： 本视频是开发者 Kevin Jones 在以太坊黑客松上的演讲，核心内容是演示如何结合使用 Scaffold-Eth 开发框架与 AI 工具（如 Cursor、OpenClaw）来快速构建和部署一个去中心化拍卖应用。他通过对比传统手动编码和 AI 辅助开发两种方式，展示了 AI 在提升开发效率方面的潜力，同时也指出了其当前存在的局限性和成本问题。 视频中提出的关键信息包括： 1. **Scaffold-Eth 介绍**：它是一个以太坊全栈开发入门套件，集成了前端（Next.js）、智能合约开发环境（Hardhat/Foundry）、本地测试链和预置组件，能帮助开发者快速从零搭建可部署的 DApp。 2. **AI 辅助开发流程**：演示了如何使用 Cursor（结合 Claude 等模型）和 OpenClaw 等 AI 工具，根据自然语言指令生成和修改 Solidity 智能合约、前端代码及测试。 3. **ETHskills 的重要性**：强调在 AI 开发中为智能体提供“护栏”和上下文（如通过 ETHskills.com 的知识库）至关重要，能确保其以安全可靠的方式在以太坊上部署合约。 4. **开发与部署实践**：现场演示了从初始化项目、编写拍卖合约、运行测试、部署到 Base 链，到最终将前端部署至 IPFS 和 Vercel 的完整流程。 5. **AI 工具的局限性**：指出 AI 在开发中可能犯错误（如错误选择开发框架）、生成代码质量不稳定，且高级工具（如 OpenClaw）可能非常昂贵且复杂。 6. **安全与最佳实践**：提醒不要使用测试网的私钥，应生成并加密新密钥；强调验证智能合约以及使合约可升级的重要性。 7. **相关资源与项目**：提到了 Speedrun Ethereum（学习平台）、Build Guild、以及演讲者自己开发的 AI 代理密钥管理工具 One Claw。

150 0 0 2026-04-20 11:46

VibeCoding： 合约挑战 - Delegatecall重入清空金库

视频 AI 总结： 本视频详细讲解了一个智能合约挑战作业的解题思路，核心内容是利用`Delegatecall`漏洞和重入攻击来清空目标合约（Vault）中的所有资金。通过分析合约结构和执行流程，揭示了如何绕过权限控制，最终实现资金盗取，从而满足挑战的`isSolved`条件。 关键信息： 1. **合约架构**：存在一个用户交互合约（Vault）和一个逻辑实现合约，Vault合约通过`Delegatecall`委托调用逻辑合约。 2. **攻击目标**：将Vault合约的余额清零。 3. **`Delegatecall`漏洞利用**：`ChangeOwner`函数在Vault合约上下文中执行时，其密码验证实际上是检查Vault合约的`slot 1`，即逻辑合约的地址。攻击者可将逻辑合约地址作为密码，修改Vault合约的Owner。 4. **攻击步骤**： * 利用逻辑合约地址作为密码，调用`ChangeOwner`将Vault合约的Owner修改为攻击者地址。 * 以攻击者身份调用`Open Withdrawal`，打开取款开关。 * 调用`Withdrawal`函数，并利用重入攻击机制，在一次取款操作中多次执行取款逻辑，清空合约内所有资金。 5. **涉及技术**：`Delegatecall`机制、Solidity存储槽位（slot）原理、重入攻击。

46 0 0 2026-04-01 08:20