| timezone |
|---|
UTC+8 |
GitHub ID: kaixiang-uoa
Telegram: @keson897
希望从web2转型到web3，偏前端，MERN，python。
此刻正在参加毕业典礼。一个月的时间很快，确实很感动。在这个学习计划中做了个小透明。看到群里各种年轻人的聊天，每次，每周的分享。就跟回到了当年我大学的时候，真的非常感慨。10年的自己也是这样意气风发。群里的各位都充满了朝气，热情，特别活跃。真的给了自己很大的感触。同时自己也因为这个计划培养了更好的学习习惯。虽然学习计划结束了，但是我还是要继续在web3上继续走下去。感恩！加油！完结！
-
英语，背单词，练口语。
-
继续看uniswap,理解V3，练习写合约.
-
大概看了一下Motion这个库，练一下在自己的项目里让页面效果更好。
昨天听了Bruce老师关于简历和一些面试的分享。今天修改了一下自己的建立，又重新看了看自己的第一个web3的小项目，感觉应该再重新设计下，尽量体现多一点的东西。不过老师说的推荐深耕一个技术栈的思路我还是很赞同的，以为我之前就学的有点杂，就感觉并不合适，其实应该更多聚焦于一个点然后尽量的去吃透。我现在主要是MERN，很合适转web3，所以我目前决定继续在这个方向上学，wagmi v2 ， viem，RainbowKit，Zod ， React Hook Form 还有Foundry，因为之前练习了也了解，可以继续，当然hardhat也可以，毕竟这个是js的也可以理解。另外一个老大难就是-English。今天又开始继续背单词，刷PTE的题。早上起来就听英语的podcast。继续加油吧！
今天尝试自己做自己的Dapp，根据昨天老师们黑客松的启发，重新设计下，自己的Dapp，然后试试把web2的存储作为桥梁，或者类似缓存的思路来结合web3的链上。尝试下存储的思路然后怎么设计合适。我目前用的是mongoDB。希望能回头做出个样子添加到简历作为自己一个练手学习的项目。
今天看了不少老师的黑客松demo，感觉很受启发，特别是几个项目的思路确实很新颖，也让自己又重新思考了一下对于整个web3的理解。从项目的初衷，设计，从web3的角度出发，包括如何在项目中融入web3的思想，结合区块链的特性来优化和提升项目的实际价值。反思自己的思路还是更偏向web2的思考方式，在看demo的过程中，自己能考虑到到的就是对各位老师项目中如何考虑成本gas的问题。之前自己思考过一些类似的想法，后面主要考虑的就是对于项目中上链的成本，如何控制，数据存储的形式。也想过是否可以用web2的存储方式，又觉得丢失web3的核心。但是今天看demo的时候，老师对作品的评价中提到借助web2作为一个桥梁来实现异步数据上链方式的解释和理解，给我了新的观点和思考。另外也感受到应该更多的去读一些好的文章，论文和资料来扩充自己的对web3思想的认知和理解，以及要锻炼从实际痛点和问题出发，如何通过现有或已知的web3的技术来解决问题，设计项目。这种对问题的解构能力不仅仅对web3，对自己其他方面也很有帮助。
昨天忘记打开，做练习，结果困了直接睡了，今天又被测试网折腾了半天，总是报错，端口的问题，然后继续写代码。最近私事有点多这两天进度又被耽误了。头大。加油明天继续搞代码。也没参加了黑客松，生活一团糟.
从xy=k公式到实际交换：理解自动做市商的核心算法*
问题：当用户想要交换代币时，AMM如何自动计算交换比例和数量？
x * y = k (常数)
其中：
- x = 池子里代币A的数量
- y = 池子里代币B的数量
- k = 恒定乘积，代表池子的"流动性深度"
- 供需平衡：某种代币越稀缺，价格越高
- 自动定价：不需要订单簿，数学公式自动计算价格
- 连续性：任何时候都能交换，只要池子有流动性
池子状态：
ETH: 100个 (x)
USDT: 200,000个 (y)
K = 100 × 200,000 = 20,000,000
当前价格：
1 ETH = 200,000 ÷ 100 = 2,000 USDT
用户Alice用 2,000 USDT 买 ETH
步骤1：计算交换后的池子状态
- 池子USDT变成：200,000 + 2,000 = 202,000
- K保持不变：x × 202,000 = 20,000,000
- 新的ETH数量：x = 20,000,000 ÷ 202,000 ≈ 99.01
步骤2：计算用户获得的ETH
- Alice获得：100 - 99.01 = 0.99 ETH
- 实际价格：2,000 ÷ 0.99 ≈ 2,020 USDT/ETH
价格分析：
- 交换前价格：2,000 USDT/ETH
- 实际成交价：2,020 USDT/ETH
- 滑点：(2,020 - 2,000) ÷ 2,000 = 1%
关键观察：Alice买入ETH后，ETH价格上涨了！
用户Bob用 20,000 USDT 买 ETH
步骤1：计算交换后状态
- 池子USDT变成：200,000 + 20,000 = 220,000
- 新的ETH数量：20,000,000 ÷ 220,000 ≈ 90.91
步骤2：计算Bob获得的ETH
- Bob获得：100 - 90.91 = 9.09 ETH
- 实际价格：20,000 ÷ 9.09 ≈ 2,200 USDT/ETH
价格分析：
- 交换前价格：2,000 USDT/ETH
- 实际成交价：2,200 USDT/ETH
- 滑点：(2,200 - 2,000) ÷ 2,000 = 10%
重要发现：交换金额越大，滑点越高！
function getAmountOut(
uint amountIn, // 输入数量
uint reserveIn, // 输入代币池子储备
uint reserveOut // 输出代币池子储备
) pure returns (uint amountOut) {
// K = reserveIn * reserveOut
// 交换后: (reserveIn + amountIn) * (reserveOut - amountOut) = K
// 解出: amountOut = (amountIn * reserveOut) / (reserveIn + amountIn)
uint numerator = amountIn * reserveOut;
uint denominator = reserveIn + amountIn;
amountOut = numerator / denominator;
}设：
- 输入代币储备：Rin
- 输出代币储备：Rout
- 输入数量：Ain
- 输出数量：Aout
交换前：K = Rin × Rout
交换后：K = (Rin + Ain) × (Rout - Aout)
因为K不变：
Rin × Rout = (Rin + Ain) × (Rout - Aout)
展开：
Rin × Rout = Rin × Rout - Rin × Aout + Ain × Rout - Ain × Aout
简化：
0 = -Rin × Aout + Ain × Rout - Ain × Aout
Rin × Aout = Ain × Rout - Ain × Aout
Rin × Aout + Ain × Aout = Ain × Rout
Aout × (Rin + Ain) = Ain × Rout
最终：
Aout = (Ain × Rout) / (Rin + Ain)
想象一个水池：
- 水越深，舀出一桶水对水位影响越小
- 水越浅，舀出同样的水对水位影响越大
AMM池子同理：
- 流动性越深，交换对价格影响越小
- 流动性越浅，交换对价格影响越大
边际价格变化 = ∂(y/x) / ∂x
对于x*y=k：
y = k/x
∂y/∂x = -k/x²
价格敏感性与 1/x² 成正比
即：代币数量越少，价格越敏感
初始：100 ETH, 200,000 USDT
用户卖出 10 ETH：
- 新储备：110 ETH, ? USDT
- ? = 20,000,000 ÷ 110 ≈ 181,818 USDT
- 用户获得：200,000 - 181,818 = 18,182 USDT
- 实际价格：18,182 ÷ 10 = 1,818 USDT/ETH //跌
价格下跌！符合供需规律
同样的池子状态
用户买入用 18,182 USDT：
- 新储备：? ETH, 218,182 USDT
- ? = 20,000,000 ÷ 218,182 ≈ 91.74 ETH
- 用户获得：100 - 91.74 = 8.26 ETH
- 实际价格：18,182 ÷ 8.26 ≈ 2,201 USDT/ETH //涨
价格上涨！也符合供需规律
function getAmountOut(
uint amountIn,
uint reserveIn,
uint reserveOut
) pure returns (uint amountOut) {
// 扣除手续费：实际输入 = 输入量 × 99.7%
uint amountInWithFee = amountIn * 997;
uint numerator = amountInWithFee * reserveOut;
uint denominator = reserveIn * 1000 + amountInWithFee;
amountOut = numerator / denominator;
}无手续费情况：
Alice用2,000 USDT买ETH → 获得0.99 ETH
有0.3%手续费：
实际用于交换：2,000 × 99.7% = 1,994 USDT
Alice获得：约0.987 ETH （减少了0.003 ETH）
手续费成本：0.003 ETH ≈ 6 USDT
Uniswap池子：1 ETH = 2,000 USDT
Binance价格：1 ETH = 2,100 USDT
套利策略：
1. 在Uniswap用USDT买入ETH（便宜）
2. 在Binance卖出ETH换回USDT（昂贵）
3. 重复直到价格趋于一致
这就是价格发现机制！
深池子：1000 ETH, 2,000,000 USDT
浅池子：10 ETH, 20,000 USDT
同样买入1 ETH的滑点：
深池子滑点：约0.1%
浅池子滑点：约5%
启示：流动性越深，交换体验越好
ps: 本来该开始写代码尝试实现一下这个部分的，不过今天没写，停一下。感觉理解的还不透，总感觉不太形象。明天再试着写吧。
今天又看了V2的内容，这次感觉理解比昨天就清楚多了，还问让G（GPT）老师给举例，渐进式的理解吧。在网上也找了相关视频看了一下。
x * y = k (常数)
其中:
x = Token A 的数量
y = Token B 的数量
k = 恒定常数
假设 ETH/USDT 流动性池:
初始状态:
ETH: 100 个
USDT: 200,000 个
k = 100 * 200,000 = 20,000,000
如果有人用 10 ETH 换 USDT:
新的 ETH 数量: 100 + 10 = 110
根据 k 不变: 110 * y = 20,000,000
新的 USDT 数量: y = 20,000,000 / 110 ≈ 181,818
用户获得: 200,000 - 181,818 = 18,182 USDT
实际汇率: 18,182 / 10 ≈ 1,818 USDT/ETH
价格 = 另一个代币的数量 / 当前代币的数量
// ETH 价格 (以 USDT 计价)
ETH_Price = USDT_Reserve / ETH_Reserve
// 实时价格示例
ETH_Reserve = 100
USDT_Reserve = 200,000
ETH_Price = 200,000 / 100 = 2,000 USDT/ETH每笔交易都会改变池子中代币的比例，从而改变价格：
// 交易前
ETH: 100, USDT: 200,000 → 价格: 2,000 USDT/ETH
// 有人买入 ETH (用 USDT 换 ETH)
ETH: 95, USDT: 210,526 → 价格: 2,216 USDT/ETH //上涨
// 有人卖出 ETH (用 ETH 换 USDT)
ETH: 105, USDT: 190,476 → 价格: 1,814 USDT/ETH //跌流动性提供者向池子同时存入两种代币，获得 LP Token 作为凭证。
收入来源: 交易手续费 (0.3%)
分配方式: 按 LP Token 比例分配
例子:
- 池子总交易量: 1,000,000 USDT/天
- 总手续费: 1,000,000 * 0.3% = 3,000 USDT/天
- 你的 LP Token 占比: 2%
- 你的日收益: 3,000 * 2% = 60 USDT/天
无常损失 (Impermanent Loss): 当代币价格偏离提供流动性时的价格，LP 的总价值会小于单纯持有代币。
简化例子:
提供流动性时: 1 ETH + 2,000 USDT (ETH = $2,000)
ETH 涨到 $4,000 时:
- 单纯持有: 1 ETH + 2,000 USDT = $6,000
- 池子中(按算法): ~0.707 ETH + 2,828 USDT ≈ $5,656
- 无常损失: $6,000 - $5,656 = $344
滑点 = 预期价格与实际执行价格的差异
大额交易会显著改变池子的代币比例，导致后面的代币价格更高/更低。
// 滑点计算示例
初始池子: 100 ETH, 200,000 USDT (价格: 2,000 USDT/ETH)
小额交易 (1 ETH):
- 获得约 1,980 USDT
- 实际价格: 1,980 USDT/ETH
- 滑点: (2,000 - 1,980) / 2,000 = 1%
大额交易 (10 ETH):
- 获得约 18,182 USDT
- 实际价格: 1,818 USDT/ETH
- 滑点: (2,000 - 1,818) / 2,000 = 9.1%直接交易: USDC → ETH (如果有 USDC/ETH 池)
路径交易: USDC → WETH → UNI (通过两个池子)
Uniswap 会自动寻找最优路径，保证用户获得最多代币
USDC → DAI: 可能通过 USDC → WETH → DAI
小众代币 → ETH: 通常需要多跳路径
稳定币互换: 通常有直接池子，滑点较小
Factory Contract: 创建和管理所有交易对
Pair Contract: 每个交易对一个合约，处理 swap 和流动性
Router Contract: 提供便捷接口，处理路径计算
// 简化版核心逻辑
function swap(uint amountIn, address tokenIn, address tokenOut) {
uint reserveIn = getReserve(tokenIn);
uint reserveOut = getReserve(tokenOut);
// 计算输出数量 (扣除 0.3% 手续费)
uint amountInWithFee = amountIn * 997;
uint amountOut = (amountInWithFee * reserveOut) /
(reserveIn * 1000 + amountInWithFee);
// 执行转账
transferFrom(user, address(this), amountIn, tokenIn);
transfer(user, amountOut, tokenOut);
// 更新储备量
updateReserves();
}- 池子同时持有两种代币（X/Y），交换遵循恒定乘积（含手续费），据此定价与结算。
- 价格由池内两资产比例决定（边际价）；套利会把 AMM 价与外部市场拉齐。
- LP 存入两种资产，获得 LP 代币（按份额追踪收益，类似“份额凭证”，但为双资产）。
- 无需订单簿，价格由曲线自动给出。
- 可作为链上价格来源（需考虑被操纵风险）。
- 相比订单簿撮合，整体 Gas 开销更小、实现更简单。
- 每笔交易都会推动价格，容易产生滑点与三明治攻击。
- LP 不能像订单簿那样挂指定价位，只能按池内比例提供流动性。
- 存在无常损失：单边资产上涨时，LP 的总价值可能不如单独持有。
- Factory：创建交易对（Pair）。
- Pair：每个币对一个合约，负责储备与交换；LP 代币本身是 ERC-20。
- Router：提供便捷接口和多跳路由，绝大多数用户交互经由 Router。
- Core / Periphery 分层：核心逻辑尽量精简安全，外围功能放在外层合约与工具。
- 定位池地址：利用
CREATE2，可据Factory + tokenA + tokenB纯计算 Pair 地址（无需读存储）。 - 为何不用 EIP-1167 clone：虽然部署便宜，但交易期需要
delegatecall，高频路径下额外 Gas 不划算。
- Liquidity Providers（LP）：被动/专业 LP、项目方自建流动性等，按交易额收取 0.30% 手续费归 LP。
- Traders（交易者）：普通用户、套利者、DApp 用户与智能合约（如聚合器）都会直接或间接调用 swap。
- Developers（开发者/项目）：前端、钱包、聚合器、衍生品协议等围绕 Uniswap 构建，提升可用性与流动性。
- 三类角色形成正反馈：更多流动性 → 更好价格与深度 → 更多交易与集成 → 手续费回流 LP。
感觉是真的不好理解。还得琢磨琢磨
今天两件事：
看了前端部分的代码，主要是练习，拆分组件，怎么拆，数据流怎么走，状态管理管的是组件中的什么部分，用了一部分自己的代码例子，也尝试让AI给生成了一下练习题。就是急需提升coding的能力，以及怎么设计组件。
- Allowance（授权额度）：把某个 ERC-20 代币的可用额度授权给路由合约（如
SwapRouter），路由才能代扣。 - Approve：链上交易，修改
allowance。前端先读取 allowance，不足再引导授权。 - Permit / Permit2：用签名代替传统
approve交易，可做到一次签名 + 一次 swap，减少交互与费用；注意限额/到期与吊销入口。
- exactInput：给定
amountIn，希望“至少得到”多少（amountOutMin）。最常见、风险可控。 - exactOutput：希望恰好得到
amountOut，允许“最多花”多少（amountInMax）。更易因价格波动失败。 - 初学建议先用 exactInputSingle（单跳）：路径简单、稳定。
-
滑点（成交滑点）：最终成交价格相对你看到的报价变差的幅度。
- 来源 A：你这笔交易沿 AMM 曲线推进引起的价格冲击（池子越浅，冲击越大）。
- 来源 B：等待打包期间市场变动/他人交易/MEV 夹子导致价格变化。
-
滑点容忍度（Slippage Tolerance）：你在前端设定的阈值，告诉路由“价格最差能接受到什么程度”；路由据此计算保护参数：
- exactInput：
amountOutMin = 报价 * (1 - 滑点%) - exactOutput：
amountInMax = 报价 * (1 + 滑点%)
- exactInput：
简单说：滑点是客观发生的价格偏差；滑点容忍度是你愿意忍多少。超过就回滚，不成交。
- 报价：1 A → 100 B
- 你设 1% 滑点 →
amountOutMin = 100 * (1 - 0.01) = 99 - 区块打包时池子被别人先扫了，你最终只会拿到 99.2 B → ≥ 99，成交；
- 若只剩 98.7 B → < 99，回滚，保障你不被“劣价成交”。
- 稳定币对（深池）：
0.1% ~ 0.3% - 主流币/较深池：
0.3% ~ 1% - 长尾/浅池/波动大：
1% ~ 3%+（能成交，但更易被夹，谨慎） - 原则：能成交的前提下尽量小；越大越容易被三明治。
- 防止交易长时间悬而未决被人“摆布”。
- 常用：2~5 分钟；过期自动失败。
- 典型费档：0.01% / 0.05% / 0.3% / 1%。
- 稳定币对偏低费档，波动/长尾偏高费档。一个币对可有多个池，路由会择优。
- decimals：不是都 18（如 USDC 多为 6）。
- 输入/显示：界面用人类单位，链上调用要精确换算。
- 价格：
sqrtPriceX96 → 实际价格时，注意两侧 decimals。
INSUFFICIENT_OUTPUT_AMOUNT：amountOutMin太紧或价格波动 → 提示用户调滑点/重试。- 授权不足：先读 allowance，只给所需额度（或用 Permit2）。
- 链不匹配：提示切换网络。
- 异常代币：fee-on-transfer/非标准 ERC-20 → 事前校验与友好提示。
今天看了一点uniswap,感觉很多东西，学不完。主要就是看了：
- Uniswap：去中心化交易所（DEX）协议：用自动做市商（AMM）而不是订单簿撮合。 有v2,v3,v4不同的版本， V2：恒定乘积 x∙y=k、50/50 流动性、全价区间。 V3：集中流动性（LP 把资金放在某个价格区间），效率更高；LP 头寸是 NFT。 今天主要就是先不管 LP 和复杂路由，把“读数据+报价”跑一下。理解一下。
- 最主流的链上流动性入口：大量 Token 的“参考价”和流动性都在这。
- 标准化接口：有清晰的 Core/Periphery 合约与 SDK，易于做“报价 → 授权 → 交易”的完整链路。
- 可组合性强：我可以把它当作后端服务来“读价格/给用户报价”，再配自己的业务逻辑（限价、风控、白名单等）。
- viem：用它读合约状态（池子的价格、流动性、ticks）和做离线报价（Quoter）。
- wagmi：负责连接钱包、账户与网络状态、签名和发送交易。
- 用户输入 TokenA 数量
- 前端用 Quoter 做离线报价（不上链）拿到预估的 TokenB 数量（Quoter提供的只读合约，用来在链下（eth_call）模拟一次 swap，给出按现在这条路径、这笔数量，大概能换出多少/需要多少的即时报价。）
- 展示实时价格/滑点提示，不做交易. 把 Quoter 当实时计算器：用户输入 → 调 Quoter → 显示预估 amountOut（或 amountIn）。
- 状态管理（React Query/Zustand）缓存池子与报价，提升交互体验
今天有常识了一下hardhat，今天重新部署测试网络，然后删了合同又常识部署了一下，每天就是对前一天的内容先练习回忆一下，而且今天还测试了一下kurtosis测试网连接钱包并且都顺利。然后简答总结一下这两天Foundry 和hardhat的学习。
| 特性 | Foundry | Hardhat |
|---|---|---|
| 主要语言 | Solidity 原生 | JavaScript/TypeScript |
| 学习曲线 | 陡峭 | 平缓 |
| 适用场景 | 高性能、纯 Solidity 项目 | 团队协作、企业级项目 |
| 生态成熟度 | 快速崛起 | 成熟稳定 |
- Foundry: 追求极致的性能和 Solidity 原生体验
- Hardhat: 注重易用性和团队协作
forge build # 编译合约
forge test # 运行测试
forge script # 执行部署脚本
forge create # 直接部署合约
forge verify # 验证合约npx hardhat compile # 编译合约
npx hardhat test # 运行测试
npx hardhat run # 执行脚本
npx hardhat node # 启动本地节点
npx hardhat verify # 验证合约foundry-project/
├── src/ # 合约源码
├── script/ # 部署脚本 (.sol)
├── test/ # 测试文件 (.sol)
├── lib/ # 依赖库
└── foundry.toml # 配置文件
hardhat-project/
├── contracts/ # 合约源码 (.sol)
├── scripts/ # 部署脚本 (.js)
├── test/ # 测试文件 (.js)
├── hardhat.config.js # 配置文件
└── package.json # 依赖管理
- 选择 Foundry: 纯 Solidity 开发、高级开发者
- 选择 Hardhat: TypeScript 项目、学习阶段
- Foundry: Solidity 原生，性能优先
- Hardhat: JavaScript 生态，易用性优先
- 两者都支持: 多网络部署、合约验证、测试框架
- 主要任务：完成本地测试网的部署。
- 问题回顾：
- 之前按照老师的笔记进行操作，但忽略了部署环境配置，导致一直报错，特别是在 端口绑定 部分反复卡住。
- macOS Docker Desktop 在 UDP 端口绑定 方面存在已知问题：
- 解决方案：
- 最终更换 Teku 作为共识层客户端部署成功。
- 部署配置如下：
{ "participants": [ { "el_type": "geth", "cl_type": "teku", "count": 1 } ], "network_params": { "preset": "minimal", "genesis_delay": 20 } }
- 工具：使用 Foundry 部署留言板合约。
- 操作流程：
- 在本地创建 Foundry 项目。
- 创建合约文件并复习合约的基本结构、方法、修饰符。
- 逐行理解部署脚本与测试文件的结构，并添加注释方便复习。
- 个人理解：
- 在理解 Solidity 代码时，以 Java OOP 思维 的方式去理解会更顺畅。
- 这种思路有助于后续的合约学习与架构理解。
- 结果：
- 本地部署成功并通过简单测试。
- 尝试使用 Hardhat 进行合约部署。
- 继续完善 Dapp 前端部分，借鉴老师及同学们的实际项目思路，使自己的项目更具实际意义。
感想
今天在部署过程中再次体会到环境配置的重要性，也收获了针对不同客户端的部署经验。Dapp 开发不应仅仅是为了完成任务，而是应考虑实际应用价值。再接再厉。
今天先打上卡，写一点，今天主要是继续修改了一下Dapp的UI部分，然后学习设置了一下tailwindcss。并且在前端添加了个页面，准备把链上留言板做到页面中，在留言板的合约里添加了两个function。然后复习了solidity的基本语法，写起来总是没有头绪，而且很多关键字不熟练，还得查看学习手册，还是写的少，然后我现在练习不管是solidity练习写简单的合约，还是next、react前端组件部分，都让自己一遍说一遍写，比如这个组件只做一件事，props传什么， state怎么管理，作用是什么。这个方法的输入输入出是什么。这样锻炼自己的一个构建思路。我现在不是很没思路或者需要特别优化的部分（比如我自己写个UI，奇丑无比，我需要AI帮我优化一下）都尽量不用AI，就尽量自己写，然后不会就看文档，不理解就问AI，让后让他不要直接给代码，先讲思路。不然太依赖AI自己写代码的能力感觉都越来越弱（本来也很弱）。其次现在还在创建本地测试网络，报错很多，正在尝试中ing....，另外晚上的知识分享会听的一脸懵逼。这个不是一两个月时间积累出来的。但是内心还很羡慕。还是要静下心继续学习。现在先去配置测试网。今天先这么多吧，明天再多不充点吧。
这两天我用到两份合约：一个是训练营的链上留言板 Message，另一个是教程里的 mint NFT 合约 MyFirstMint。把它们放在一起对比一下。
-
基础结构 文件头是
SPDX和pragma solidity（锁编译器大版本）。MyFirstMint里import的是 OpenZeppelin 5.3.0；contract Name is A, B { ... }表示继承（MyFirstMint继承ERC721+Ownable；Message不继承）。 -
MyFirstMint的铸造方法 暴露的safeMint(address to, uint256 tokenId)内部调用_safeMint(to, tokenId)。 在 Solidity 里可见性靠public/external/internal/private控制，不是靠下划线； OpenZeppelin 只是约定内部/底层实现用下划线前缀（例如_safeMint），表示“内部使用，不对外暴露”。 -
ERC-721 标准接口 包括但不限于 常用函数：
balanceOf、ownerOf、approve、getApproved、setApprovalForAll、isApprovedForAll、transferFrom、safeTransferFrom（含两个重载） 事件：Transfer、Approval、ApprovalForAll注：totalSupply/按序枚举不在核心标准，需要ERC721Enumerable或自己维护计数。我的合约里没有这些，所以前端读不到总量。 -
权限
MyFirstMint用onlyOwner：只有 owner 能safeMint；这是运行时权限校验。Message没有限制：任何人都能leaveMessage(string)。 -
构造与运行期参数
MyFirstMint的constructor(address initialOwner)是部署时一次性参数； 运行期只有safeMint(to, tokenId)，nonpayable不需要value。
-
数据流不变：
connect → read → (simulate) → write → wait → refresh。 这几天不断复习这个流程，现在看到 hook 基本能对上它处在哪个环节。 -
读取 NFT 个数：用合约的
balanceOf这里我彻底分清了：- ETH 余额：
useBalance({ address: 钱包地址 }) - NFT/代币余额：对着合约地址用
useReadContract(functionName: 'balanceOf', args: [钱包地址])返回的是bigint，UI 用.toString()显示。
- ETH 余额：
useReadContract({
address: nftContract as `0x${string}`, // NFT 合约地址
abi: erc721Abi,
functionName: 'balanceOf',
args: [walletAddress as `0x${string}`], // 查这个钱包在该合约下拥有多少枚 NFT
chainId: 11155111,
query: { enabled: !!walletAddress },
})- 为什么有些读不到
我的
MyFirstMint没实现totalSupply，tokenURI也没重写，所以读不到总量、元数据可能是空。这和标准的范围有关，不是前端问题。
现在的 MyFirstMint 需要我自己传 tokenId，同一个只能用一次。明天改成自增，不过这也是练习；实际项目一般会在合约里自增分配（前端不填 id，只调 mint() 或 mint(amount)）。
今天因为私人事情学习量大幅减少，只是完成了链上留言板的练习。我感觉 Solidity 的语法有点像 Java，也算是强类型的语言,然后OOP的风格。对于老师给的链上留言板的合约例子，大部分还是比较能理解只有几个点自己还是又琢磨了一下：
event + indexed 的理解：event NewMessage(address indexed sender, string message); 这里的indexed 就像给日志字段建索引，前端/后端在订阅或查询事件日志时可以按 sender 高效过滤。（今天没有实践，明天练一下）。然后事件不改变状态，但可被前端监听，实现“链上写入 → 前端实时更新”。
memory 的语义：string memory initMsg = "Hello ETH Pandas"; 仅在当前函数执行期存在（临时内存，不上链）。将 initMsg push 到 messages[...] 时，才会把数据写入 storage（持久化，上链并消耗 gas）。
public view returns (string memory)：这里是手写的只读函数，不是自动 getter，开始我以为只要是public就会自动生成getter方法；自动 getter 是由 public messages 这种“公共状态变量”生成的。 view 只读、链下调用不花 gas；返回 string memory 代表返回内存拷贝，不暴露 storage 引用。
mapping 与数组的组合：mapping(address => string[]) 相当于：每个地址 → 它的留言数组。这个就跟Java的map(Map<Address, List>)和 python的字典(dict[address, list[str]])一样的结构,都是键值对。 但是只是存储结构一样，但是特性区别很大，solidity的mapping 本身不可遍历，所以要是后续要“全量列出所有人消息”，需要额外维护用户地址列表或事件汇集。也就是自己要维护索引，比如维护一个address的数组[]。这个点也是明天要继续学习的。
希望明天有多点时间，然后把这个链上留言板的合约和前端集成一下。
今天把“从连接到真上链”的闭环跑通了: RainbowKit 负责连接钱包，wagmi 这边用 useAccount 拿到 address/chainId，然后按我确立的主线 connect → read → (simulate) → write → wait → refresh 一步步走。核心是先做 simulate 预演，通过了再发交易，最后等确认并刷新读数据。
合约这块我用了 OpenZeppelin Wizard 生成一个简单的合约，然后再remix上部署了一个带 onlyOwner 的 ERC-721，公开方法是 safeMint(address to, uint256 tokenId)。我明确了两类参数：部署时的 constructor(address initialOwner)（只在部署那一刻填一次），运行期的 safeMint 两个参数（前端要传 to 和 BigInt 的 tokenId）。同时也弄清楚权限：因为有 onlyOwner，必须用部署者钱包调用。
前端组件上，我加了 useSimulateContract 做预演（传了 account: address，并显式硬码了 chainId: 11155111），通过后用 useWriteContract 的 writeContractAsync 发送，useWaitForTransactionReceipt 等确认。按钮的禁用与文案完整覆盖了状态：未连接/链不对/模拟中/模拟失败/发送中/确认中。交易成功后把哈希渲染成 Etherscan 链接，并在确认后 refetch 了我这份 balanceOf 的读取。
然后我分清了三类余额：useBalance 读原生 ETH；useReadContract(balanceOf) 读 ERC-20；useReadContract(balanceOf) 读我这个 NFT 合约的“持有数量”。此外我也用 useReadContract(owner) 做了仅用于提示的 owner 读取（帮助提前给出 onlyOwner 的预期）。另外，totalSupply 这份 ABI 里没有，所以读不到——这一点我也记下了：要么合约自己实现，要么走 Enumerable/索引器。
最后在 Sepolia 上的 Transfer 事件里第 3 个参数就是本次的 tokenId，前端也显示了 Confirmed，证明我的 simulate → write → wait → refresh 已经闭环。这里我也顺带把 ETH / ERC-20 / ERC-721 的区别彻底理顺：useBalance 读账户 ETH；ERC-20/721 都是“合约里记账”，要用 useReadContract 对着“代币合约地址/ NFT 合约地址”去读 balanceOf。
最后同时学习到在商业项目里 tokenId 通常由合约内部自增分配，前端不填 id，不过我目前这份由OpenZeppelin Wizard 完成的合约里 safeMint(to, id) 是在前端硬码写了，主要还是先吃透数据流，然后跑通整个闭环。
并且晚上老师的技术分享课上，看了关于solidity的部分，关于如何写合约，决定明天尝试自己写一个最简单的合约，先从熟悉架构来。今天的这个OpenZeppelin Wizard生成的合约倒是也自己看了，然后感觉大概有点了解，感觉挺像OOP的结构。另外预习很总要，今天白天先跑了一遍自己的练习，晚上老师讲的时候，基本都可以听的明白，架构，数据流包括前端集成用到的Rainbowkit 和 wagmi自己能跟的上。明天继续冲！
今天主要把钱包连接、读取合约数据、以及发起 mint 交易这条线跑通了一遍。先按旧视频把 wagmi 的老版本再过一遍，确认能连到钱包、看到地址和网络；然后对照官方文档，用 wagmi 新版本把同样的功能自己重写了一次。整体感觉很明确：API 的写法在变，但背后的思路其实是一致的。
对我来说最关键的是把数据流吃透，而不是把每个 hook 背下来。现在我的理解就是：connect → read → (simulate) → write → wait → refresh。先连钱包拿到 address/chainId，要是没连就把写入操作禁用，链接了再读链上状态，让页面钱包的信息展示出来；也可以用 simulate 预检查和估算 gas，尽量在签名前发现参数或权限问题；然后发交易拿到 hash；等待回执确认；最后刷新读取的状态（或监听事件）让 UI 更新结果。
这次也踩了几个坑，我一开始把钱包地址当成了合约地址，直接导致“合约不存在该函数”；按钮禁用条件本来写成“本地函数是否存在”，后来改成看 isConnected / isPending / isConfirming / simLoading 这些状态更合理；ABI 和合约签名对不上也会立刻失败，比如把 uint32 手快打成了 unit32，或者合约里其实是 uint256 我却按 uint32 写；再就是链上整数要用 BigInt，不要用普通 number；如果合约的 mint 是 payable，调用时必须带上 value。感觉这些错都得再看看。除了粗心的，其他的感觉还是得记住都需要什么参数，如何设计代码结构更合理。
我对照过和用到的 hook 主要是这些，有些还是名字一样。 视频里之前用的wagmi：useAccount、useContractRead、usePrepareContractWrite、useContractWrite、useWaitForTransaction 我看官网新的：useAccount、useReadContract / useReadContracts、useSimulateContract、useWriteContract（含 writeContractAsync）、useWaitForTransactionReceipt
不过wagmi 的封装确实方便，不过主要还是今天理解了自己这个练习的数据流。流程相对来说已经清楚了，哪怕只靠官方文档，我也能一步步把功能扣出来；看别人的代码也知道它处在流程的哪一段、为什么这么写。后面还要把这个再复习一下，不然很容易忘记。
今天我正式开始了自己的第一个 Web3 项目开发，项目名称叫做“First-web3-app”。整个过程对我来说非常新鲜，也收获了不少。
首先，我用 Next.js 创建了项目骨架，并引入了 RainbowKit 和 Wagmi 这两个非常流行的 Web3 工具库。RainbowKit 主要负责实现钱包的连接功能，支持多种主流钱包，集成起来也很简单，界面体验很棒。Wagmi 则为与以太坊区块链的交互提供了强大的 hooks 和工具，让我可以方便地调用链上的各种功能。
在链的选择上，我选用了 Sepolia 测试网，这样可以在不消耗真实资产的情况下进行开发和测试。为了保证节点的稳定性，我还配置了 Alchemy 的 API Key，作为区块链数据的提供方。
样式方面，我用的是 Tailwind CSS，方便快速地搭建页面和调整样式。
目前，项目的主要功能是实现钱包连接。用户可以通过页面上的按钮连接自己的钱包，为后续的 NFT mint 测试做准备。
关于 NFT 的 mint 功能，目前我还没有完成。这部分我还有些不太理解，尤其是合约的部署和 mint 流程。我的理解是，需要先用 Remix 写一个智能合约（比如 ERC721 或 ERC1155），然后把合约部署到测试网（比如 Sepolia），这样前端才能通过 Wagmi 等工具调用合约的 mint 方法，实现 NFT 的铸造。我看到很多视频教程里，作者都是先在 Remix 上写好合约并部署，然后再在前端调用合约的 mint 功能。明天我准备先用 Remix 写一个简单的 NFT 协议，实际操作一遍，加深理解。
NFT 新手入门 & 实践安全手册
-
NFT 基础知识
1.1 NFT 是什么？ NFT（Non-Fungible Token，非同质化代币） 是一种区块链上唯一的数字资产凭证，不可互换、不可拆分。 对比同质化代币（FT, Fungible Token），如 USDT、ETH，这些币之间没有差别，可以等价互换。 NFT 像“数字身份证”，常用于：数字艺术品、门票、游戏道具、数字证书等。
1.2 NFT 的特性与价值 唯一性和限量性：每个 NFT 都有独一无二的编号和元数据。 可转让、可交易：通过链上智能合约，NFT 可在市场自由买卖和转让。 价值多元：不仅仅是“投资品”，还可以有纪念价值、艺术价值、社区属性、工具属性等。 例：一幅数字画作、一个门票 NFT、游戏装备、DAO 社区入场券等。
1.3 NFT 参与前的思考方法——DYOR DYOR（Do Your Own Research） 进入 NFT 或任何加密领域前，务必做独立调研。 不要只听别人说“稳赚”，更不要盲目跟风或被朋友圈带节奏。 常见情绪陷阱 FOMO（Fear Of Missing Out）：害怕错过，“看别人都买我也要冲！” FUD（Fear, Uncertainty, Doubt）：恐惧、不确定、疑虑时容易低价卖出或观望。 参与前提问自己 我喜欢这个 NFT 的艺术、故事或社区吗？ 我的主要目的是收藏、社交、支持项目、还是炒作投机？ 如果价格归零我是否也不后悔？ 当前价格合理吗？自己是否真心愿意为此买单？
-
Web3 新手实操与安全
2.1 钱包安全与资产管理 常见损失原因 助记词/私钥泄露 假官网、钓鱼网站 插件被劫持、设备中毒 钱包热/冷混用不当 新手实用建议 资产分散：热钱包（浏览器/手机）只放小钱，大额用冷钱包（硬件钱包等）。 定期换新钱包：减少长时间暴露同一地址的风险。 只认官网和官方社交账号：不要在不明链接、论坛或群聊里安装任何钱包、输入助记词。 多思考，慢操作：遇到转账、授权、空投、客服消息时务必核查三遍。 安全第一：区块链世界一旦资产被盗，几乎无法追回。
2.2 获取 ETH（Gas Fee） 铸造、转账、任何链上操作都要支付手续费（Gas Fee），币种为 ETH。 推荐在正规交易所购入后，**核对地址、网络（Ethereum Mainnet）**再转入自己钱包。
2.3 链接钱包 & 铸造 NFT 基本流程 设计/选择 NFT：如头像、数字艺术等，部分平台可自定义。 连接钱包：点击 Web3 项目“Connect Wallet”或“连接钱包”按钮，用 MetaMask 等钱包授权。 铸造（Mint）：点击“Mint”/“铸造”，钱包弹窗会显示交易信息和 Gas Fee。 确认支付 Gas Fee：等待区块确认后，NFT 到账。 结果查询：可以在 OpenSea 等 NFT 市场，用钱包地址查看自己 NFT。 Gas Fee 会浮动：高峰期费用高，建议低峰操作。
-
继续编程练习-next.js
- 第一次了解remix这个IDE，全新的接触，这个之前用差别还挺大的。需要继续探索。目前依旧保持用VScode，cursor作为个人主要开发工具
- 在https://speedrunethereum.com/challenge/simple-nft-example 尝试了这个例子，算是自己的第一次web3的开发例子。这个有点意思。并且在YouTube上找了个视频来讲解开发过程晚些时候准备跟着做一下看看效果如何。
- 主要继续复习一下react和看了一部分next.js。然后继续做自己web2的全栈练习项目，主要是MERN的技术栈，所以很大一部分和web3的前端包括后端有重合。今天大部分时间都是放在这个部分了，修改一些bug，并且完成了重新部署和后端部分的迁移。预计接下来的几天都会在next.js的地方多做练习和停留，以便更好的熟悉用法。 4.看到群里同学提及笔记中的职场软技能，又回去翻看了一遍，感觉这个应该没事就看看，养成自己的习惯和形成意识，就不用刻意去记。这些软技能和专业硬技能在职场中都会相辅相成。
一、区块链/Web3 岗位全景速览
- 技术岗主要分类 前端工程师 负责 Dapp（去中心化应用）的界面和链上数据展示、钱包连接、合约交互等，技术栈常用 React/Vue、TypeScript、Viem（替代 ethers/web3）、钱包集成等。基本上和web2的框架一样，区别是web3用ethers，（web3.js看网上说比较老）就可以实现和链上区块（也可以理解为web3分布式中的点）的通信。ethers是一个封装RPC的js 库，底层走的是JSON-RPC的协议或者websocket。不同于传统的分布式的的通信方式grpc，消息队列等。所以next.js 做前端的话根据项目需求和业务需求有些可以采取轻后端或者没有后端的方式，直接用ethers来和链上通信。但是涉及并发，复杂的链下计算等就需要考虑重后端来维护业务逻辑的稳定。 后端工程师 负责后端 API、链上数据检索、交易逻辑、和智能合约的集成。主流用 Node.js/Python/Go，常见数据库 MySQL/PostgreSQL，熟悉链上数据操作和多钱包集成。（正在研究...） 智能合约工程师 负责 Solidity 智能合约的设计、开发、部署和安全审计。熟练主流链（Ethereum/Polygon 等），要懂典型漏洞、审计流程、事件机制等，常用工具 Foundry/Hardhat/Remix。
- 非技术岗 产品/运营 负责项目需求、产品迭代、用户增长和数据分析，要求懂 Web3 基本逻辑、会用数据工具和社区运营方式。 社区管理 管理 Telegram/Discord/Twitter 等社群，活动策划和品牌维护，懂社交平台玩法。 行业研究 做行业竞品分析、写白皮书/深度报告，要懂 DeFi/经济模型、会用数据分析工具（Python、Glassnode 等）。
- 常用技术栈 HTML/CSS/JS，React/Vue，TypeScript，Next.js，Viem，Solidity，Foundry/Hardhat，Docker/K8s，Git 等。
二、安全与合规 中国大陆监管极为严格，禁止一切 Token 融资/交易/挖矿，参与即有刑事风险。 合同关系模糊，境外项目普遍无正式劳动合同、无社保公积金，薪资结构多为 USDT/Token，需警惕出金风险（洗钱/冻结）。 入行一定要看清项目白皮书、合规材料，别踩雷。 Token/USDT 直接参与“换汇”很容易卷进非法经营和洗钱案，案例很多。 强调安全意识：不要随便连接钱包、泄露私钥、信群内“官方”消息，资产分离管理，注意各类社交/钓鱼攻击和插件、依赖风险。 昨天的安全分享会是个很好的学习视频，今天又看了一次。并且结合unphishable.io的练习，确实学到了很多防钓鱼的点。特别是授权等操作的时候一定要认真检查相关的信息。这个也需要补充一些基础知识，理解操作的流程信息内容，以防被修改信息却也不清楚正确信息的格式和内容。
三、智能合约开发/Dapp 基本流程
- Dapp 典型架构 前端：主要负责 UI/钱包连接/与合约交互（JS/TS + React/Vue + Viem/Wagmi + 钱包插件）。 智能合约：用 Solidity 编写核心业务，链上自动执行，不可篡改。 数据检索器（Indexer）：用于同步链上事件，写入数据库，方便前端查数据（常用 subgraph、ponder）。 去中心化存储：用 IPFS/Arweave 保存链外大文件。
- 智能合约开发流程 需求分析→合约设计/编写→测试（单测+审计）→前端集成→测试网部署→主网部署 主流开发工具：Foundry（Rust，快）、Hardhat（JS，生态好）、Remix（网页版，适合入门测试）
- Solidity 合约基本范式 版本声明 状态变量（链上永久存储） 函数/修饰符（权限、payable、view/pure） 事件机制（链上触发，前端监听） 常用安全点：重入（Checks-Effects-Interactions，ReentrancyGuard）、整数溢出（Solidity 0.8+ 自动检测）、访问控制（onlyOwner/AccessControl） Gas 优化：减少存储操作、使用 memory、合理循环、external/public 区分
- 合约部署和前端集成 测试流程： 本地节点 or 测试网（Sepolia 等）部署 前端用 Viem/Wagmi 绑定合约 ABI 和地址 钱包连接（MetaMask）发起交易签名 前端交互流程： connectWallet → 实例化合约 → 发送交易/读取数据
- 合约审计要点 常用工具：Slither、MythX、Foundry 测试 检查点：重入/整数溢出/权限/未初始化代理/预言机/三明治攻击等
- 团队协作规范 分支管理（main/develop/feature/fix） PR 审查/代码风格/单元测试/Issue 标签
一、区块链黑暗森林自救手册-前半部分
- 基础安全防护
- 钱包相关： 助记词/私钥的生成、存储和离线备份，最好是物理隔离，比如手抄下来，永远不要截图或拍照留在手机里。不要把私钥存在聊天软件、云盘、邮箱里。只用可靠的设备（自己控制的电脑/手机）来创建和使用钱包。
- 签名&交易安全 ：每次交易签名前都要确认清楚细节，尤其是授权和转账，防止误签恶意合约。不随便点别人发来的签名请求链接、二维码，尤其是社交群、推特、微信群那种。养成习惯，看合约地址和交互内容，不懂的就不要贸然操作。
- 防钓鱼和反诈骗：所有自称“官方客服”、突然空投的“福利”、让你充值返现的活动一律警惕，遇到这种先冷静下来。访问官网建议手动输入网址，不通过百度、谷歌广告或者群里别人发的链接。永远不要把钱包私钥、助记词给任何人，包括任何“客服”或者自称项目方的人员。
- 进阶风险防控与应急
- 隐私与隔离: 钱包分离，日常小额操作和大额资产最好用不同的钱包，防止一次意外损失全部资产。重要操作最好用专用的电脑或手机，不随便装各种来路不明的软件、插件。避免用公共 WiFi，实在要用也最好加 VPN 增加一层防护。
- 新型攻击/高阶防御: 对陌生的 DeFi、NFT、GameFi 合约要小心，很多钓鱼合约和闪电贷攻击，签名前可以查查这个项目有没有被社区曝光或者做过安全审计。千万别习惯性点“授权无限额度”，用多少授权多少，减少潜在风险。
- 安全事件应急: 钱包一旦资产被盗或者怀疑中招，第一步是赶紧撤销合约授权，然后报警、联系相关项目方/安全团队。及时止损，之后要总结原因，完善备份和安全措施，防止重蹈覆辙。
二、unphishable.io 新手挑战要点 做 unphishable.io 初级题目的一些经验：题目主要围绕各种钓鱼和社工攻击的识别，比如钓鱼邮件、假官网、恶意授权页面等。 常见的判断方法： 1. 仔细检查网址域名，很多钓鱼站会少一个字母或者换个拼音； 2. 只要页面要求输入私钥或者助记词，基本都是假的； 3. 任何官方团队都不会主动联系你索要钱包信息； 4. 各种空投、奖励、福利活动一般是骗局，不要随便参与。 有些题目的页面按钮设计得很混淆，或者假冒官方标志、认证，要特别留意细节，宁可多查几次也不要着急操作。 明天继续学习黑暗森林自救手册后半部分和继续做一下unphishable.io中级题目，并且准备尝试跟着视频做一下web3开发练习。
区块链定义：
一种去中心化的分布式账本，安全且透明，不可篡改。有时间顺序相连接的“区块”。区块链的核心组件是由去中心化的分布式网络，区块（节点），以及加密货币组成的。
区块：
- 每个“区块”包含：交易数据，元数据。以此确保完成性和可追溯性。
- 在一定时间内打包，限定时间不同，例如10分钟，且每个“区块”存储空间有限。
区块链特性：
- 不可篡改：由于区块是有时间顺序串联起来，因为对于历史数据的修改将直接对后续数据造成影响，也必须修改。
- 公开透明，匿名：公开透明指区块链中的每一个区块的内心公开透明，例如交易数据，原数据。但是对于区块信息，或者说是钱包的拥有者匿名。
- 快速交易：不受地理位置限制，只受网络通信制约，只要可以连接互联网，用户交易数据就可以被打包在区块链中完成自动交易。
区块链形式：
- 以分布式网络的形式记录每个节点的交易信息和原数据。
- 分布式网络：多个计算机在不同地理位置通过网络连接，共同完成一个任务或者维护某种服务。期中每个节点（计算机）之间共享数据，协同工作。
- 区块链+分布式： 基于分布式的特点，更加保证区块链的安全。从数据的角度来看，区块的数据分别存储在分布式网络中的每一个节点上，这也就提高了数据安全:
- 数据冗余：一个节点数据被篡改可以很容易被发现。保证数据的一致性
- 数据备份: 一个节点挂掉，其他节点依旧有数据备份。不会像集中式的情况服务器或者数据库挂掉对数据影响极大。
- 分布式的灵活性：因为不局限于特定地理位置，主要依赖于网络通信，因此任何人都可以在任何地方加入，下载账本，验证数据的真实性。
代币：一种具备货币意义，对网络服务商提供服务奖励的代币，统称为加密货币。例如：比特币，代币中的一种。
- 加密货币指的是一种可交易、总量有限，并且以密码学为核心保障安全和信任的数字货币。这里的“加密”不是货币本身隐形，而是指整个交易过程、身份认证和数据存储都采用了密码学算法，确保系统安全和数据不可篡改。
- 公开且匿名：基于区块链之上的加密货币也具备公开和匿名的双重性质。每个用户会有一个随机生成的钱包地址，该地址的交易操作在线上是公开的，但是钱包的所有者是匿名的。
- 区块链的与加密货币：去中心化的分布式网络的维持需要各网络服务商，每个网络服务商可做为链上的一个节点（一个账本，区块）。这些网络服务商维护区块链的操作被称为挖矿，提供维护服务的人被称为矿工。交易中的燃料费（gas fee）是矿工的工资。而加密货币测试对矿工的奖励。
- 代币的获取：可通过挖矿奖励，也可以通过法币交换。 法币（Fiat Money）：国家为单位发型的法定货币。
- 利弊：虽然加密货币具备账户匿名，公开透明且不可篡改的主要优点，但是也存在难以追踪的弊端，因为成为黑产和洗钱的一种手段。并且由于区块打包要10分钟所以存在滞后性，同时每个区块存储量有限。
区块链的运行：
- 用户发起交易：用户通过钱包应用发起转账、智能合约调用等操作
- 交易广播：交易信息被广播到整个网络中的各个节点
- 节点验证：网络中的矿工节点验证交易的合法性（余额是否足够、签名是否正确等）
- 打包成块：通过共识机制（如工作量证明），矿工将验证过的交易打包成新的区块
- 链接上链：新区块被添加到区块链上，更新全网的账本状态
- 奖励发放：成功打包区块的矿工获得代币奖励和交易手续费
公链 vs 私链 vs 联盟链总结
| 区块链类型 | 节点加入方式 | 数据可见性 | 管理模式 | 适合场景 |
|---|---|---|---|---|
| 公链 | 任何人自由加入 | 所有人可见 | 去中心化（大家投票） | 加密货币、公共存证 |
| 联盟链 | 需联盟成员邀请/审批 | 仅联盟成员可见 | 多中心化（董事会决策） | 供应链、金融协作 |
| 私链 | 由老板严格审批 | 仅内部成员可见 | 中心化（老板说了算） | 企业内部管理、审计 |
以太坊（Ethereum）：
一个去中心化的平台，核心创新力在于智能合约（Smart Contracts）。以太币（ETH）是以太坊的原生代币。
主要是由包括 L1（主网）、L2（二层扩展解决方案）、侧链（Sidechains）组成的高吞吐量和低费用的交易处理。
以太坊主要分为：
- 应用层（Application Layer） 用户直接交互的应用和界面：DeFi 应用：Uniswap（去中心化交易所）、Aave（借贷协议）、Compound（借贷协议） NFT 平台：OpenSea、Foundation、SuperRare 钱包应用：MetaMask、Coinbase Wallet、Rainbow DAO 工具：Snapshot、Aragon、Colony
- 协议层（Protocol Layer） 以太坊的核心基础设施：
- 共识层客户端：Prysm、Lighthouse、Nimbus、Teku 执行层客户端：Geth、Nethermind、Erigon、Besu 核心协议：EVM、状态管理、Gas 机制
- 扩展层（Scaling Layer） 提升性能和降低成本的解决方案：
- Layer 2 Rollups：Arbitrum、Optimism、Polygon zkEVM、zkSync Era 侧链：Polygon PoS、xDAI（Gnosis Chain） 状态通道：Lightning Network for Ethereum。
- 以太坊的三个关键机制：账户系统、Gas 模型 和 以太坊虚拟机（EVM）。
-
账户系统 - 数字身份：
- 外部账户（EOA）：用户控制，以公钥和私钥形式保证账户安全
- 公钥：暴露在外，以便用户交易。例如接收转账
- 私钥：用户严格保密，用来登录账户。
- 合约账户（CA）：只能合约控制。只能合约的部署会自动产生合约账户，通过代码驱动，非用户控制。
- 外部账户（EOA）：用户控制，以公钥和私钥形式保证账户安全
-
每个账户包含四个信息：
- Nonce：防止重复交易的计数器（EOA 记录发送次数，CA 记录创建合约次数）。
- 余额：账户持有的 ETH 数量（单位为 Wei）。
- CodeHash：EOA 为空哈希，CA 存储合约字节码的哈希值。
- StorageRoot：记录账户数据的 Merkle 树根哈希（如 NFT 归属关系）。
-
gas模型：交易燃料费。
- 计算方式：Gas 费用 = 用多少 × 每单位多少钱。
- Gas Limit（限额）：最多愿意付多少额度费用。
- Gas Price (单价）：每单位燃料多少钱。用Gwei表示：1 Gwei = 0.000000001 ETH.
-
以太坊虚拟机EVM：代码引擎，是以太坊的大脑，专门用来运行只能合约的。利用分布式网络的特点，运行在每个节点上，保证结果都一致，且可信任。
EVM的特点：
- 图灵完备：像真正电脑一样，可执行条件判断，循环等逻辑操作。
- 全球同步：每个矿工/节点都会执行代码确数据的保一致性。
- 隔离安全：虚拟机采用沙盒运行保护系统安全。
以太坊和比特币的差异对比：
| 维度 | 比特币（Bitcoin） | 以太坊（Ethereum） |
|---|---|---|
| 目标与定位 | 去中心化的数字货币，强调安全、稳定和稀缺性（总量 2100 万枚） | 去中心化平台，支持智能合约和 Dapps，定位为“区块链 2.0” |
| 编程能力 | 脚本语言有限，仅支持简单的交易验证逻辑 | 图灵完备的编程语言（如 Solidity），可开发复杂智能合约 |
| 共识机制 | 工作量证明（PoW），矿工通过算力竞争记账权 | 从 PoW 转向权益证明（PoS），通过 The Merge 实现能源效率优化 |
| 交易速度 | 每 10 分钟生成一个区块，交易确认较慢 | 区块时间约 12 秒，交易确认更快，适合高频应用 |
| 经济模型 | 总量固定，强调抗通胀属性 | 供应灵活，通过 EIP-1559 等机制可能呈现通缩趋势 |
两者在技术路线和目标地位上存在差异，以太坊更加灵活支持场景更多。比特币则专注作为数字黄金的价值。
去中心化 vs. 中心化交易所的好处：
| 特点 | 去中心化 | 中心化 |
|---|---|---|
| 交易不需要中介，快速方便 | 你直接用自己的钱包进行交易，不需要像中心化交易所那样注册账户、上传身份证等繁琐步骤。 | 需要通过一个平台来进行配对和交易，往往存在人工审核、系统延迟等问题，交易可能比较慢。 |
| 24/7 全天候交易 | 无论你身在何处，任何时候都能进行交易。没有交易时间的限制。 | 通常会受到全球市场交易时间、服务器维护等因素的影响。尤其是某些交易所还可能进行系统升级或停机。 |
| 大额交易更便捷 | 你不需要等待层层审批，特别是对于一些大额资金的交易，完全依赖智能合约和流动性池来完成。所有交易都直接在链上进行，快速而高效。 | 大额资金的交易通常需要通过银行、金融机构等审批环节，可能还要经过反洗钱审查等复杂的程序，时间较长。 |
DAO（Decentralized Autonomous Organization，去中心化自治组织）：
不依赖传统的公司架构，而是通过智能合约和社区投票来做决策。它不需要一个管理层，所有事情都由持有代币的社区成员共同治理，公开透明，没有什么事情可以背着大家，尤其是利益分配相关的问题。
未来方向：
- Web3+乡建-南塘DAO-希望，未来！
- 2025新趋势-自己感兴趣的：
- AI+web3的融合。