从 ERC-20 到 ERC-4337:一个 Web3 学习者该真正理解的 10 个 ERC 标准

从 ERC-20 到 ERC-4337:一个 Web3 学习者该真正理解的 10 个 ERC 标准

目录

一、ERC-20:一切 DeFi 的起点

二、ERC-721:NFT 从这里开始

三、ERC-1155:更现实的 NFT 标准

四、ERC-165:合约之间如何“互相认识”

五、ERC-4626:DeFi 的标准金库

六、ERC-2612:不用发交易的授权

七、ERC-1271:合约钱包如何验证签名

八、ERC-4337:账户抽象的核心

九、ERC-6551:NFT 成为钱包

十、ERC-3643:RWA 的核心标准

最后:你该怎么学这些 ERC

刚开始接触 Web3 的时候,我和很多人一样,被各种 ERC 标准搞得有点懵。

ERC-20、ERC-721、ERC-1155、ERC-4337……
名字看起来都很像,但又不知道它们之间到底有什么区别,更不知道哪些是“必须学的”,哪些只是“了解即可”。

后来在写合约、看项目源码、做 DeFi 相关开发的过程中,我慢慢意识到一件事:

ERC 本质上不是规范,而是一套“经验总结”。
它们出现,是因为有人在真实开发中踩过坑。

这篇文章,我不打算用文档式的方式去堆标准,而是从一个学习者的视角,讲清楚 10 个你绕不开的 ERC 标准,以及它们各自解决了什么问题。


一、ERC-20:一切 DeFi 的起点

如果你只学一个 ERC,那一定是 ERC-20。

几乎所有你熟悉的代币——USDT、USDC、UNI、ARB,本质上都是 ERC-20。它定义的事情非常简单:怎么查余额、怎么转账、怎么授权别人使用你的代币。

但它的重要性在于,它第一次让“代币”变成了一个统一的概念。

在 ERC-20 出现之前,每个项目的代币逻辑都是自己写的,钱包无法通用,交易所也无法统一支持。ERC-20 出现后,整个 DeFi 世界才真正开始搭起来。

你可以把 ERC-20 理解成 Web3 世界的“货币协议”,它的存在直接催生了 DEX、借贷、稳定币这些生态。

官方文档在这里:
https://eips.ethereum.org/EIPS/eip-20

如果你后面要学 DeFi、做 Swap、写 Token,ERC-20 是绕不过去的一关。


二、ERC-721:NFT 从这里开始

ERC-721 解决的问题其实很简单:
如何在链上表示“独一无二的东西”。

和 ERC-20 不同,ERC-721 的每一个 token 都是唯一的,它有自己的 tokenId,也有明确的所有者。

这让很多事情成为可能,比如 NFT 图片、游戏角色、链上身份、数字收藏品。

你现在看到的几乎所有 NFT 项目,不管是头像类还是功能型,本质上都是基于 ERC-721。

它的意义不在于“炒图”,而在于第一次让“唯一性资产”在链上有了标准表达方式。

官方文档:
https://eips.ethereum.org/EIPS/eip-721


三、ERC-1155:更现实的 NFT 标准

当项目真正开始做 NFT 时,很快就会发现 ERC-721 的问题:
太贵、太慢、不适合批量操作。

于是 ERC-1155 出现了。

它最大的特点是:
一个合约里可以同时管理多种资产,而且支持批量转账。

这使它非常适合游戏、道具系统、空投场景。你可以把它理解为“更工程化的 NFT 标准”。

很多链游、道具系统,实际上更偏向 ERC-1155,而不是 ERC-721。

官方文档:
https://eips.ethereum.org/EIPS/eip-1155


四、ERC-165:合约之间如何“互相认识”

ERC-165 是一个经常被忽略,但非常基础的标准。

它的作用只有一个:
让合约告诉别人“我支持哪些接口”。

在实际开发中,你经常会看到类似这样的代码:

supportsInterface(bytes4 interfaceId) 

它的存在,让钱包、合约、市场可以自动判断:

  • 你是不是 NFT
  • 你是不是 ERC-1155
  • 你支持哪些功能

可以说,没有 ERC-165,就没有现在这种可组合的 Web3 世界。

官方文档:
https://eips.ethereum.org/EIPS/eip-165


五、ERC-4626:DeFi 的标准金库

如果你接触过 DeFi,一定见过各种 Vault、收益池、存币生息。

ERC-4626 做的事情,其实非常关键:
它统一了“存钱 → 换份额 → 赎回”的整个逻辑。

在它出现之前,每个 DeFi 项目的资金池逻辑都不一样,前端难写,审计难做,用户也难理解。

ERC-4626 把这些流程标准化了,这也是为什么现在很多新 DeFi 项目都会直接基于它开发。

官方文档:
https://eips.ethereum.org/EIPS/eip-4626

如果你想真正理解 DeFi 的运行机制,这是一个必须认真看的标准。


六、ERC-2612:不用发交易的授权

你在用 DEX 的时候,可能注意到一个细节:
有些操作不需要先 approve,就能直接完成。

这背后用的就是 ERC-2612。

它允许用户用“签名”代替“交易”,从而省下一笔 gas。
这在体验上是一次非常大的优化。

现在很多钱包和协议都已经支持它,你不一定需要手写实现,但一定要知道它是怎么回事。

官方文档:
https://eips.ethereum.org/EIPS/eip-2612


七、ERC-1271:合约钱包如何验证签名

当钱包从 EOA 发展到合约钱包时,一个问题出现了:
合约没有私钥,那它怎么签名?

ERC-1271 就是为了解决这个问题而出现的。

它定义了一套标准接口,让合约可以通过逻辑判断签名是否有效,而不是依赖私钥。

这也是多签钱包、智能账户、AA 钱包的基础之一。

官方文档:
https://eips.ethereum.org/EIPS/eip-1271


八、ERC-4337:账户抽象的核心

ERC-4337 是近几年最重要的 ERC 之一。

它的目标只有一个:
让钱包体验接近 Web2。

通过它,你可以做到:

  • 没有 ETH 也能发交易
  • 第三方帮你付 Gas
  • 一次操作完成多个动作
  • 用合约实现账户逻辑

这也是为什么现在很多新钱包、AA 方案,都围绕它来设计。

官方文档:
https://eips.ethereum.org/EIPS/eip-4337


九、ERC-6551:NFT 成为钱包

ERC-6551 是一个非常有想象力的标准。

它允许:
每一个 NFT 都拥有自己的账户地址。

这意味着:

  • NFT 可以持币
  • NFT 可以交互
  • NFT 可以作为 AI Agent 或角色主体

很多 AI + Web3 的项目,底层逻辑都依赖这个标准。

官方文档:
https://eips.ethereum.org/EIPS/eip-6551


十、ERC-3643:RWA 的核心标准

如果说前面的 ERC 面向的是加密世界,那 ERC-3643 面向的就是现实世界。

它解决的是:
如何让股票、债券、房产等现实资产,合规地上链。

它内置了:

  • KYC 机制
  • 转账限制
  • 权限控制
  • 合规模块

目前很多 RWA 项目都基于它实现。

官方文档:
https://eips.ethereum.org/EIPS/eip-3643


最后:你该怎么学这些 ERC?

我给你一个非常现实的建议。

不要试图一次性全部掌握。
正确的路径是:

先理解 ERC-20 / 721 / 1155
再理解 4626 / 2612 / 1271
最后再看 4337 / 6551 / 3643

你会发现,ERC 并不是零散的知识点,而是一套逐步演进的系统设计。

当你真正理解这些标准后,再去看任何 Web3 项目,你都会有一种感觉:

“哦,原来它是这么拼起来的。”

Read more

ctfhub——文件上传(无验证,前端验证,.htaccess,MIME绕过,00截断,双写后缀,文件头检测)

ctfhub 文件上传 无验证 上传一句话木马 访问成功显示666 连接蚁剑 得到flag ctfhub{149641ca197038f11067df1a} 前端验证 不能直接上传 js前端验证,过滤在前端 所以我们可以通过直接修改前端js文件或BP改包的方式绕过 这里我们用BP 打开BP上传图片文件 改包并上穿 尝试访问成功 连接蚁剑 得到flag ctfhub{1856388f624ce5d680835d50} .htaccess 1.知识点 (1)先简单介绍一下.htaccess文件: .htaccess文件 (或者"分布式配置文件"),全称是Hypertext Access(超文本入口)。 它提供了针对目录改变配置的方法, 即,在一个特定的文档目录中放置一个包含一个或多个指令的文件, 以作用于此目录及其所有子目录。 作为用户,所能使用的命令受到限制。 管理员可以通过Apache的AllowOverride指令来设置。 .htaccess文件是用于apache服务器下的控制文件访问的配置文件,因此Ng

Flutter 三方库 flutter_dropzone 的鸿蒙化适配指南 - 掌握万物皆可拖拽的资源流转技术、助力鸿蒙大屏与 Web 应用构建极致直观的文件导入与交互体系

Flutter 三方库 flutter_dropzone 的鸿蒙化适配指南 - 掌握万物皆可拖拽的资源流转技术、助力鸿蒙大屏与 Web 应用构建极致直观的文件导入与交互体系

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 flutter_dropzone 的鸿蒙化适配指南 - 掌握万物皆可拖拽的资源流转技术、助力鸿蒙大屏与 Web 应用构建极致直观的文件导入与交互体系 前言 在 OpenHarmony 鸿蒙应用全场景覆盖、特别是适配鸿蒙桌面模式(Desktop Mode)、折叠屏大屏交互及鸿蒙 Web 版推送的工程实战中,“文件拖拽(Drag and Drop)”已成为提升生产力效率的标配功能。用户希望能够像在 PC 上一样,直接将图片或文档拖入应用窗口即可完成上传。如何实现这种跨越边界的直观交互?flutter_dropzone 作为一个专注于“拖放区域感知与文件流提取”的库,旨在为鸿蒙开发者提供一套标准的拖放治理方案。本文将详述其在鸿蒙端的实战技法。 一、原原理分析 / 概念介绍 1.1 基础原理 flutter_dropzone

前端模块化开发:从面条代码到结构化代码的蜕变

前端模块化开发:从面条代码到结构化代码的蜕变 毒舌时刻 模块化开发?不就是把代码分成几个文件嘛,有什么大不了的?我见过很多所谓的模块化代码,其实就是把一堆函数随便塞进不同的文件里,根本没有任何结构可言。 你以为把代码分成模块就万事大吉了?别天真了!如果你的模块设计不合理,反而会让代码变得更加混乱。比如那些互相依赖的模块,就像一团乱麻,让你根本理不清头绪。 为什么你需要这个 1. 代码可维护性:模块化代码结构清晰,易于理解和维护,当需要修改某个功能时,只需要修改对应的模块即可。 2. 代码复用:模块化可以让你在不同的项目中复用相同的代码,减少重复开发的工作量。 3. 团队协作:模块化可以让不同的开发者负责不同的模块,减少代码冲突和沟通成本。 4. 性能优化:模块化可以帮助你实现代码分割,减少初始加载时间,提高应用的性能。 反面教材 // 这是一个典型的面条代码 let users = []; let products = []; function fetchUsers() { fetch('https://api.example.com/

【前端】使用Vue3过程中遇到加载无效设置点击方法提示不存在的情况,原来是少加了一个属性

【前端】使用Vue3过程中遇到加载无效设置点击方法提示不存在的情况,原来是少加了一个属性

🌹欢迎来到《小5讲堂》🌹 🌹这是《前端》系列文章,每篇文章将以博主理解的角度展开讲解。🌹 🌹温馨提示:博主能力有限,理解水平有限,若有不对之处望指正!🌹 目录 * 前言 * 提示报错 * 问题分析 * 1. **Options API vs Composition API 风格差异** * ✅ **Options API 写法(方法直接放在外面)** * ✅ **Composition API 写法(方法必须在 setup 中定义)** * ✅ **`<script setup>` 语法糖(最简洁的 Composition API)** * 2. **为什么你的代码会报错?** * 3. **解决方案** * 方案 1:改用 **Options API**(适合从 Vue