从入门到实战:我的全套 Web3 学习路径(2025版)
你好,我是 Keegan 小钢。 如果你刚开始接触 Web3、准备从 Web2 转型,或者正在寻找一套真正系统、可落地、能带你从入门做到链上实战的学习路径,那么这篇文章会对你非常有帮助。 我是一名有 16 年经验的互联网从业者,过去 8 年专注于 Web3 技术方向,同时持续做个人 IP 超过 13 年。长期以来,我在公众号、知乎、B 站持续输出 Web3 的学习路线、开发知识、工程实践以及真实链上项目的研发过程。如果你对我的经历好奇,可以阅读这篇文章:《复盘我的 13 年个人 IP 之路》。 这几年,越来越多同学加我咨询,他们大多会问:我应该从哪里开始学 Web3?我有一些基础,但做不出完整项目怎么办?有没有适合“从入门到能做项目”的学习路径?我想顺利找到 Web3 工作,该怎么准备?本质上,这些问题可以归结成一句话:“我现在这个水平,下一步该学什么?”为了让不同阶段的同学都能快速找到最适合自己的学习路径,我把过去几年输出的所有 Web3 内容——免费课程、付费课程、AI+Web3 实战营、以及深度服务——做了一次系统性的梳理。 这篇文章是你最清晰、最完整的 「Web3 学习路...
万字长文聊聊Web3的现状与趋势
整体数据现状与趋势首先,先来看看 Web3 的搜索热度情况,我们可以从 GoogleTrends 中看到一些数据。下图是关于 Web3 在全球过去 5 年内的搜索热度趋势图:从图中可以看出,前面几年的搜索热度一直很低,热度值一直保持在 10 以下,但从 2021 年下半年开始逐渐飙升,在 2021 年 12 月底达到了顶峰。虽然随后开始有所回落,但依然保持在很高的热度。 如果再按区域来看搜索热度,就会发现,搜索热度最高的竟然是在中国,且与其他区域的搜索热度差距很大,如下图所示这说明,中国依然是 Web3 最大的潜在市场。 接着,再来看看整个加密货币总市值的趋势图,某种程度上,这也代表了整个 Web3 行业的总市值。下图的数据来自 CoinMarketCap:从图中可以看到,总市值也是在 2021 年出现大幅度飙升,2021 年底到达顶峰,达到了将近 3 万亿美元的总市值。随后不断回落,在 2022 年底跌到了最低点,总市值降到低于 1 万亿,相比高点,跌去了三分之二。但是,就算是最低点也依然比 2021 年之前那些年的总市值高得多。 加密货币的总市值看上去好像不低,但如果跟全球股...
万字长文聊聊Web3的组成架构
Web3 发展至今,生态已然初具雏形,如果将当前阶段的 Web3 生态组成架构抽象出一个鸟瞰图,由下而上可划分为四个层级:区块链网络层、中间件层、应用层、访问层。下面我们来具体看看每一层级都有什么。另外,此章节会涉及到很多项目的名称,因为篇幅原因不会一一进行介绍,有兴趣的可以另外去查阅相关资料进行深入了解。区块链网络层最底层是「区块链网络层」,也是 Web3 的基石层,主要由各区块链网络所组成。 组成该层级的区块链网络还不少,Bitcoin、Ethereum、BNB Chain(BSC)、Polygon、Arbitrum、Polkadot、Cosmos、Celestia、Avalanche、Aptos、Sui 等等,还有很多。根据 Blockchain-Comparison 的统计,截止撰文之日的区块链至少有 150 条。这里我们主要说的是公链,联盟链不包括在内。因为区块链实在太多,会有些眼花缭乱,所以有必要进行分门别类。 首先,不同区块链之间存在着分层结构,有 Layer0、Layer1、Layer2 之分。其次,Web3 的繁荣发展,依赖于智能合约技术,而智能合约的运行环境为...
Blockchain engineer
从入门到实战:我的全套 Web3 学习路径(2025版)
你好,我是 Keegan 小钢。 如果你刚开始接触 Web3、准备从 Web2 转型,或者正在寻找一套真正系统、可落地、能带你从入门做到链上实战的学习路径,那么这篇文章会对你非常有帮助。 我是一名有 16 年经验的互联网从业者,过去 8 年专注于 Web3 技术方向,同时持续做个人 IP 超过 13 年。长期以来,我在公众号、知乎、B 站持续输出 Web3 的学习路线、开发知识、工程实践以及真实链上项目的研发过程。如果你对我的经历好奇,可以阅读这篇文章:《复盘我的 13 年个人 IP 之路》。 这几年,越来越多同学加我咨询,他们大多会问:我应该从哪里开始学 Web3?我有一些基础,但做不出完整项目怎么办?有没有适合“从入门到能做项目”的学习路径?我想顺利找到 Web3 工作,该怎么准备?本质上,这些问题可以归结成一句话:“我现在这个水平,下一步该学什么?”为了让不同阶段的同学都能快速找到最适合自己的学习路径,我把过去几年输出的所有 Web3 内容——免费课程、付费课程、AI+Web3 实战营、以及深度服务——做了一次系统性的梳理。 这篇文章是你最清晰、最完整的 「Web3 学习路...
万字长文聊聊Web3的现状与趋势
整体数据现状与趋势首先,先来看看 Web3 的搜索热度情况,我们可以从 GoogleTrends 中看到一些数据。下图是关于 Web3 在全球过去 5 年内的搜索热度趋势图:从图中可以看出,前面几年的搜索热度一直很低,热度值一直保持在 10 以下,但从 2021 年下半年开始逐渐飙升,在 2021 年 12 月底达到了顶峰。虽然随后开始有所回落,但依然保持在很高的热度。 如果再按区域来看搜索热度,就会发现,搜索热度最高的竟然是在中国,且与其他区域的搜索热度差距很大,如下图所示这说明,中国依然是 Web3 最大的潜在市场。 接着,再来看看整个加密货币总市值的趋势图,某种程度上,这也代表了整个 Web3 行业的总市值。下图的数据来自 CoinMarketCap:从图中可以看到,总市值也是在 2021 年出现大幅度飙升,2021 年底到达顶峰,达到了将近 3 万亿美元的总市值。随后不断回落,在 2022 年底跌到了最低点,总市值降到低于 1 万亿,相比高点,跌去了三分之二。但是,就算是最低点也依然比 2021 年之前那些年的总市值高得多。 加密货币的总市值看上去好像不低,但如果跟全球股...
万字长文聊聊Web3的组成架构
Web3 发展至今,生态已然初具雏形,如果将当前阶段的 Web3 生态组成架构抽象出一个鸟瞰图,由下而上可划分为四个层级:区块链网络层、中间件层、应用层、访问层。下面我们来具体看看每一层级都有什么。另外,此章节会涉及到很多项目的名称,因为篇幅原因不会一一进行介绍,有兴趣的可以另外去查阅相关资料进行深入了解。区块链网络层最底层是「区块链网络层」,也是 Web3 的基石层,主要由各区块链网络所组成。 组成该层级的区块链网络还不少,Bitcoin、Ethereum、BNB Chain(BSC)、Polygon、Arbitrum、Polkadot、Cosmos、Celestia、Avalanche、Aptos、Sui 等等,还有很多。根据 Blockchain-Comparison 的统计,截止撰文之日的区块链至少有 150 条。这里我们主要说的是公链,联盟链不包括在内。因为区块链实在太多,会有些眼花缭乱,所以有必要进行分门别类。 首先,不同区块链之间存在着分层结构,有 Layer0、Layer1、Layer2 之分。其次,Web3 的繁荣发展,依赖于智能合约技术,而智能合约的运行环境为...
Blockchain engineer

Subscribe to Keegan小钢

Subscribe to Keegan小钢
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
这是我的 AI + Web3 实战营 的第七篇研发日志,前六篇如下:
AI+Web3实战营日志 #4 | Rebalancer合约
另外,关于 AI + Web3 实战营的相关介绍则有如下几篇文章:
之前我们一直采用每天晚上 8 点直播的方式推进研发,每次 1.5–2 小时,一周六天。
不过随着参与直播的同学越来越少,加上每天的时间投入有限,整体进度偏慢。于是我提出取消直播,改为我白天集中录制研发过程,大家根据自己的时间去看回放。这样不仅能让我投入更多时间推进项目,也有余力去做功能迭代和完善。征得大家同意后,从当天起,直播正式取消。
过去两天,我录制了 4 个视频,总时长近 5 小时。加上最初的 1.5 小时测试时间,累计约 6.5 小时,终于把 BlockETFCore 合约的所有测试用例全部跑通。
下面就来总结下这次测试成果。
针对 BlockETFCore 合约,总计设计并完成 337 个测试用例,涵盖 9 大模块,具体如下:

代码覆盖率详情则如下,涵盖了所有公开函数和内部函数:
╔════════════════════════════════════════════════════════════════╗
║ 文件/函数 │ 语句覆盖 │ 分支覆盖 │ 函数覆盖 ║
╠════════════════════════════════════════════════════════════════╣
║ BlockETFCore.sol │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 核心业务功能 │ │ │ ║
║ │ ├─ initialize() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ mint() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ mintExactShares() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ burn() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ flashRebalance() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ executeRebalance() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ adjustWeights() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 计算核心函数 │ │ │ ║
║ │ ├─ calculateMintRatio() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ calculateBurnAmounts() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ calculateRequiredAssets() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ calculateManagementFee() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 管理与配置功能 │ │ │ ║
║ │ ├─ collectManagementFee() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setManagementFeeRate() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setWithdrawFeeRate() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setFeeCollector() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setRebalancer() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setPriceOracle() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ pause() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ unpause() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 查询与状态函数 │ │ │ ║
║ │ ├─ getRebalanceInfo() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ assetInfo() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ isAsset() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ feeInfo() │ 100.00% │ 100.00% │ 100.00% ║
║ └─ 内部辅助函数 │ │ │ ║
║ ├─ _collectFee() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ _updateReserves() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ _validateWeights() │ 100.00% │ 100.00% │ 100.00% ║
║ └─ _transferAssets() │ 100.00% │ 100.00% │ 100.00% ║
╚════════════════════════════════════════════════════════════════╝
安全测试方面,也覆盖了重入、溢出、访问控制、抢先交易、闪电贷、拒绝服务、预言机操纵、精度损失等常见攻击向量,均未发现漏洞:

在完整测试过程中,我们也发现并完成了多项优化:
Oracle 初始化流程:原本需要先部署合约,再单独调用 setPriceOracle,过程有点繁琐,也存在中间步骤失败的风险。于是我们把 Oracle 地址直接放进构造函数里,部署时一步完成,既减少操作步骤,也更直观。
防止重入攻击:初始化函数涉及到多次外部调用。为避免潜在的重入风险,我们给 initialize 函数加上了 nonReentrant 修饰符,让逻辑执行更安全。
代币转账的安全性:原本用的是直接 transferFrom,这种方式在失败时可能静默不报错。现在统一改为 SafeERC20,确保转账失败会直接 revert,避免出现账面和实际不一致的问题。
减少 for 循环:initialize 函数最初有 4 个独立 for 循环,最终优化到只有 1 个 for 循环,大大节省了 gas。
铸造时返还多余资产:之前的铸造函数逻辑,调用者如果转入了多余的资产,会直接留在合约里;之后优化为把多余资产返还给用户,对用户更加友好了。
移除最小铸造份额限制:原来的版本,铸造时会有最小份额的限制,但考虑到随着 ETF 份额净值不断增长,就算是最小份额也可能会变成挺高的一个门槛,最终决定移除了这个最小份额限制,提高了灵活性。
完善预估函数的计算:铸造和销毁的三个预估计算函数,之前缺少了对管理费的计算,测试时发现预估值与实际值存在差异,于是在预估计算时,把管理费的计算也添加到了计算中,保证了预估计算和实际铸造销毁时的数额的一致性。
再平衡内部调用权限问题:合约里有两个再平衡函数,flashRebalance 和 executeRebalance,两个函数都有 onlyRebalancer 的条件限制, executeRebalance
正是因为有了非常完善全面的测试,我们才能发现这些优化的地方。
这一次,我们在 BlockETFCore 合约测试 上累计投入了 6 个半小时,时间甚至超过了合约本身的开发。但这种投入非常值得:
保障了核心模块的稳定性与安全性:337 个测试用例 + 100% 覆盖率,让整个合约基础更加牢固。
推动了架构和细节的优化:从 Oracle 初始化到再平衡权限,很多潜在问题在测试中被提前解决。
为后续测试奠定了模板:这套完整的流程和经验,将直接应用到 Router、Rebalancer 等其他合约测试中,加快整体进度。
如果放在传统的测试流程中,这样规模的测试通常需要一个 2–3 人的测试团队,至少耗时 2–3 周 才能完成。而我们仅凭个人+AI 协作,就在不到 7 个小时里完成了同等甚至更高质量的测试。这种效率差距,本身就是一次 研发范式的变革。
从这一步开始,我们真正建立起了“开发 + 测试 + 优化”的完整闭环。下一步,我们将继续推进 Router、Rebalancer、Oracle 等合约的全面测试,直到整个 BlockETF 系统实现端到端的安全与稳定。
这个实战营,每一天都在进步。 🚀
这是我的 AI + Web3 实战营 的第七篇研发日志,前六篇如下:
AI+Web3实战营日志 #4 | Rebalancer合约
另外,关于 AI + Web3 实战营的相关介绍则有如下几篇文章:
之前我们一直采用每天晚上 8 点直播的方式推进研发,每次 1.5–2 小时,一周六天。
不过随着参与直播的同学越来越少,加上每天的时间投入有限,整体进度偏慢。于是我提出取消直播,改为我白天集中录制研发过程,大家根据自己的时间去看回放。这样不仅能让我投入更多时间推进项目,也有余力去做功能迭代和完善。征得大家同意后,从当天起,直播正式取消。
过去两天,我录制了 4 个视频,总时长近 5 小时。加上最初的 1.5 小时测试时间,累计约 6.5 小时,终于把 BlockETFCore 合约的所有测试用例全部跑通。
下面就来总结下这次测试成果。
针对 BlockETFCore 合约,总计设计并完成 337 个测试用例,涵盖 9 大模块,具体如下:

代码覆盖率详情则如下,涵盖了所有公开函数和内部函数:
╔════════════════════════════════════════════════════════════════╗
║ 文件/函数 │ 语句覆盖 │ 分支覆盖 │ 函数覆盖 ║
╠════════════════════════════════════════════════════════════════╣
║ BlockETFCore.sol │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 核心业务功能 │ │ │ ║
║ │ ├─ initialize() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ mint() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ mintExactShares() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ burn() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ flashRebalance() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ executeRebalance() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ adjustWeights() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 计算核心函数 │ │ │ ║
║ │ ├─ calculateMintRatio() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ calculateBurnAmounts() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ calculateRequiredAssets() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ calculateManagementFee() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 管理与配置功能 │ │ │ ║
║ │ ├─ collectManagementFee() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setManagementFeeRate() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setWithdrawFeeRate() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setFeeCollector() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setRebalancer() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ setPriceOracle() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ pause() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ unpause() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ 查询与状态函数 │ │ │ ║
║ │ ├─ getRebalanceInfo() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ assetInfo() │ 100.00% │ 100.00% │ 100.00% ║
║ │ ├─ isAsset() │ 100.00% │ 100.00% │ 100.00% ║
║ │ └─ feeInfo() │ 100.00% │ 100.00% │ 100.00% ║
║ └─ 内部辅助函数 │ │ │ ║
║ ├─ _collectFee() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ _updateReserves() │ 100.00% │ 100.00% │ 100.00% ║
║ ├─ _validateWeights() │ 100.00% │ 100.00% │ 100.00% ║
║ └─ _transferAssets() │ 100.00% │ 100.00% │ 100.00% ║
╚════════════════════════════════════════════════════════════════╝
安全测试方面,也覆盖了重入、溢出、访问控制、抢先交易、闪电贷、拒绝服务、预言机操纵、精度损失等常见攻击向量,均未发现漏洞:

在完整测试过程中,我们也发现并完成了多项优化:
Oracle 初始化流程:原本需要先部署合约,再单独调用 setPriceOracle,过程有点繁琐,也存在中间步骤失败的风险。于是我们把 Oracle 地址直接放进构造函数里,部署时一步完成,既减少操作步骤,也更直观。
防止重入攻击:初始化函数涉及到多次外部调用。为避免潜在的重入风险,我们给 initialize 函数加上了 nonReentrant 修饰符,让逻辑执行更安全。
代币转账的安全性:原本用的是直接 transferFrom,这种方式在失败时可能静默不报错。现在统一改为 SafeERC20,确保转账失败会直接 revert,避免出现账面和实际不一致的问题。
减少 for 循环:initialize 函数最初有 4 个独立 for 循环,最终优化到只有 1 个 for 循环,大大节省了 gas。
铸造时返还多余资产:之前的铸造函数逻辑,调用者如果转入了多余的资产,会直接留在合约里;之后优化为把多余资产返还给用户,对用户更加友好了。
移除最小铸造份额限制:原来的版本,铸造时会有最小份额的限制,但考虑到随着 ETF 份额净值不断增长,就算是最小份额也可能会变成挺高的一个门槛,最终决定移除了这个最小份额限制,提高了灵活性。
完善预估函数的计算:铸造和销毁的三个预估计算函数,之前缺少了对管理费的计算,测试时发现预估值与实际值存在差异,于是在预估计算时,把管理费的计算也添加到了计算中,保证了预估计算和实际铸造销毁时的数额的一致性。
再平衡内部调用权限问题:合约里有两个再平衡函数,flashRebalance 和 executeRebalance,两个函数都有 onlyRebalancer 的条件限制, executeRebalance
正是因为有了非常完善全面的测试,我们才能发现这些优化的地方。
这一次,我们在 BlockETFCore 合约测试 上累计投入了 6 个半小时,时间甚至超过了合约本身的开发。但这种投入非常值得:
保障了核心模块的稳定性与安全性:337 个测试用例 + 100% 覆盖率,让整个合约基础更加牢固。
推动了架构和细节的优化:从 Oracle 初始化到再平衡权限,很多潜在问题在测试中被提前解决。
为后续测试奠定了模板:这套完整的流程和经验,将直接应用到 Router、Rebalancer 等其他合约测试中,加快整体进度。
如果放在传统的测试流程中,这样规模的测试通常需要一个 2–3 人的测试团队,至少耗时 2–3 周 才能完成。而我们仅凭个人+AI 协作,就在不到 7 个小时里完成了同等甚至更高质量的测试。这种效率差距,本身就是一次 研发范式的变革。
从这一步开始,我们真正建立起了“开发 + 测试 + 优化”的完整闭环。下一步,我们将继续推进 Router、Rebalancer、Oracle 等合约的全面测试,直到整个 BlockETF 系统实现端到端的安全与稳定。
这个实战营,每一天都在进步。 🚀
flashRebalancethisflashRebalancethisflashRebalancemsg.senderrebalanceronlyRebalancerflashRebalancepublicthisflashRebalancethisflashRebalancethisflashRebalancemsg.senderrebalanceronlyRebalancerflashRebalancepublicthis
No activity yet