Skip to content

Commit fadcd0a

Browse files
yanyanhoyanyanho
authored
afix the aa task (#1305)
1 parent 08dd73e commit fadcd0a

File tree

10 files changed

+304
-185
lines changed

10 files changed

+304
-185
lines changed

‎basic/37-erc4626/readme.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,8 @@
55
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol
66

77

8+
开发demo:
9+
https://github.com/adamocallaghan/ERC4626_Strategy/blob/main/src/Vault.sol
810

911
## 参考链接
1012

‎basic/38-alloy-rust/readme.md‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
## Outline
22

33
本文旨在介绍如何使用 Rust SDK([alloy-rs](https://github.com/alloy-rs/alloy)) 与链上合约进行交互，进而开发 DApp。
4+
它的前身是ether-rs。
45

56
参考文档：https://alloy.rs/examples/advanced/README
67

@@ -105,3 +106,15 @@ cargo run --bin main
105106

106107
todo
107108
https://alloy.rs/guides/speed-up-using-u256
109+
110+
Uniswap V2 Arbitrage Optimal Amount In： youtube
111+
https://www.youtube.com/watch?v=9EKksG-fF1k
112+
113+
https://github.com/flashbots/simple-blind-arbitrage
114+
https://github.com/paco0x/amm-arbitrageur/blob/master/bot/index.ts
115+
116+
## univ3 arbitrage：
117+
118+
https://pawelurbanek.com/revm-alloy-anvil-arbitrage
119+
120+
## 参考链接：

‎basic/45-Ethereum-2.0/mpt.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,5 @@
11
https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/
22

3+
https://github.com/ebuchman/understanding_ethereum_trie/blob/master/exercises/ex1.py
4+
5+
https://consensys.io/blog/bonsai-tries-guide

‎basic/45-Ethereum-2.0/node.md‎

Lines changed: 92 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,98 @@
1-
## Run your own Ethereum Validator:
1+
## Run your own Ethereum Validator:
22

3-
### EPF
4-
系统课程： https://www.youtube.com/watch?v=nrwKxyBIYYk
3+
### EPF
54

5+
系统课程： https://www.youtube.com/watch?v=nrwKxyBIYYk
66

77
https://medium.com/coinmonks/run-your-own-ethereum-validator-part-1-pbft-casper-ffg-casper-cbc-and-lmd-ghost-e68e8461acf8
88

9+
https://eth2book.info/
10+
11+
## 节点同步
12+
13+
Full node ， archive node
14+
15+
### Full node
16+
17+
同步方式有
18+
19+
1. snap sync: 从最近的特定区块开始同步（checkpoint）， 保留最近的128个区块在内存中。
20+
21+
snap sync 先下载区块头，验证通过后，下载区块体和收据。同时，进行state-sync， geth先下载每个区块的state trie的叶子节点，然后本地自己生成完整的state trie.
22+
用eth.syncing 检查是否同步完成。
23+
24+
- download and verify headers
25+
- download block bodies and receipts. In parallel, download raw state data and build state trie
26+
- heal state trie to account for newly arriving data
27+
28+
--syncmode 默认是snap
29+
30+
2. FUll sync:
31+
full sync 逐个区块的同步，并从创世区块开始执行每个区块的交易，并生成状态。 也只保留128个区块状态。 约25分钟。其他block state会被pruned periddically.
32+
33+
### Archive node
34+
35+
适合用来查历史数据， 会保留所有区块的历史状态。 无需从checkpoint同步。
36+
通过配置geth的垃圾回收， 历史数据就不会被删除。
37+
geth --syncmode full --gcmode archive.
38+
39+
## 共识客户端
40+
41+
eth2.0 ，区块下载是由 共识客户端负责，验证由执行客户端负责。
42+
共识客户端有两个同步方式：
43+
optimistic syncing 和 checkpoint syncing
44+
45+
### optimistic syncing
46+
47+
在执行端验证之前就下载区块。 不能参与出块
48+
49+
### checkpoint sync
50+
51+
从https://eth-clients.github.io/checkpoint-sync-endpoints/ 下载checkpoint。
52+
53+
## Databases
54+
55+
since V1.9.0 , geth将 database分成两个部分。 Recent blocks 和state data 存储在 quick- access storage.
56+
57+
旧数据 和收据 stored in Freezer database。
58+
59+
### Recent blocks
60+
61+
存贮在leverdb。 主要是SSD存储
62+
63+
### Freezer/ ancients
64+
65+
Older segments of the chain are moved out of the LevelDB database and into a freezer database. 主要存在HDD。
66+
67+
the ancient chain segments is inside the chaindata directory
68+
69+
## Pruning
70+
71+
修剪操作依赖于状态数据库的“快照”（snapshots）来判断状态树（state trie）中哪些节点是“有用的”可以保留，哪些是“过时的”可以被删除。快照就像一个参照点，用来对比哪些数据仍然有效。
72+
73+
Geth 的修剪过程分为 三个阶段：
74+
第一步是“遍历快照状态”：Geth 会遍历最底层的快照，并用 布隆过滤器（Bloom Filter） 构建一个集合，这个集合用来快速判断哪些状态树节点是属于目标状态树的。
75+
76+
第二步是“修剪状态数据”：Geth 会删除那些 不在布隆过滤器集合中的状态树节点，也就是不再需要的旧数据。
77+
78+
第三步是“压缩数据库”：修剪后会有很多空闲空间，Geth 会对数据库进行整理以释放出这些空间。
79+
80+
## TXPOOL
81+
82+
pending： 有效的交易
83+
Queued: 未来的交易,nonce更多的
84+
85+
主要有以下几个方法：
86+
87+
- txpool_content
88+
返回pending 和queued的交易
89+
- txpool_contentFrom
90+
返回特定地址的交易
91+
- txpool_inspect
92+
比content的方法内容更详细
93+
- txpool_status
94+
返回pending和queue的数量
95+
96+
### MEV BOT
997

10-
https://eth2book.info/
98+
https://medium.com/@solidquant/how-i-spend-my-days-mempool-watching-part-1-transaction-prediction-through-evm-tracing-77f4c99207f

‎basic/49-Account-Abstraction/7702.md‎

Lines changed: 37 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,20 @@
1-
2-
3-
### EIP-7702 技
1+
### EIP-7702
42

53
EIP-7702 的核心创新在于引入了一种新的交易类型，允许外部账户（EOA）在单次交易中临时转换为智能合约账户，赋予其灵活的功能扩展能力。以下从交易结构、执行流程、Gas 机制和安全性等方面详细阐述其技术实现。
64

7-
85
#### **一、新交易类型的结构设计**
6+
97
EIP-7702 定义了一种新的交易类型（ **Type 4**，具体编号由最终提案确定），其数据结构在现有交易字段基础上扩展了以下关键字段：
108

11-
| 字段名 | 类型 | 描述 |
12-
|-------------------|------------|----------------------------------------------------------------------|
13-
| `code` | `bytes` | 本次交易中临时执行的智能合约代码（字节码）。 |
14-
| `signature` | `bytes` | 覆盖传统 ECDSA 签名的灵活签名格式，支持多签或非 ECDSA 算法（如 BLS）。 |
15-
| `validationGas` | `uint256` | 用于验证阶段（代码执行前）的 Gas 限额。 |
16-
| `executionGas` | `uint256` | 用于代码执行阶段的 Gas 限额。 |
9+
| 字段名 | 类型 | 描述 |
10+
| --------------- | --------- | ---------------------------------------------------------------------- |
11+
| `code` | `bytes` | 本次交易中临时执行的智能合约代码（字节码）。 |
12+
| `signature` | `bytes` | 覆盖传统 ECDSA 签名的灵活签名格式，支持多签或非 ECDSA 算法（如 BLS）。 |
13+
| `validationGas` | `uint256` | 用于验证阶段（代码执行前）的 Gas 限额。 |
14+
| `executionGas` | `uint256` | 用于代码执行阶段的 Gas 限额。 |
1715

1816
**示例结构（伪代码）：**
17+
1918
```solidity
2019
struct EIP7702Transaction {
2120
// 标准交易字段（如 nonce, gasLimit, to, value 等）
@@ -28,68 +27,65 @@ struct EIP7702Transaction {
2827
}
2928
```
3029

31-
32-
3330
#### **二、交易执行流程**
31+
3432
当用户发起 EIP-7702 交易时，以太坊网络按以下步骤处理：
3533

36-
1. **交易验证阶段**
34+
1. **交易验证阶段**
35+
3736
- **签名验证**：不再强制使用 ECDSA 签名，而是根据 `code` 中定义的逻辑验证 `signature`。例如，代码可能要求多签验证或使用 BLS 聚合签名。
3837
- **临时状态注入**：将 `code` 临时绑定到用户的 EOA 地址，模拟智能合约账户的执行环境，但不修改链上账户的永久状态。
3938

40-
2. **代码执行阶段**
39+
2. **代码执行阶段**
40+
4141
- **上下文切换**：在本次交易的执行环境中，用户的 EOA 地址被视为智能合约账户，其权限逻辑完全由 `code` 定义。
4242
- **自定义操作**：代码可执行任意逻辑，如批量交易、代付 Gas（使用 ERC-20 代币）、社交恢复验证等。
4343
- **Gas 分段管理**：`validationGas` 和 `executionGas` 分别限制验证与执行阶段的 Gas 消耗，防止资源耗尽攻击。
4444

45-
3. **状态恢复**
45+
3. **状态恢复**
4646
- 交易完成后，临时注入的 `code` 从账户中移除，EOA 恢复原始状态，不保留任何智能合约痕迹。
4747

48-
49-
5048
#### **三、Gas 优化机制**
49+
5150
EIP-7702 通过以下方式降低 Gas 成本：
52-
1. **减少交易层级**
51+
52+
1. **减少交易层级**
5353
- 相比 EIP-4337 的 UserOperation 需要 Bundler 打包并支付额外 Gas，EIP-7702 直接在协议层处理，省去中间环节。
54-
2. **合并操作**
54+
2. **合并操作**
5555
- 单笔交易可完成多步操作（如授权+转账+跨链调用），减少总 Gas 消耗。
56-
3. **动态 Gas 分配**
56+
3. **动态 Gas 分配**
5757
- 用户可灵活分配 `validationGas` 和 `executionGas`，避免为单一阶段预留过多冗余 Gas。
5858

59-
60-
6159
#### **四、安全机制与风险控制**
62-
1. **代码执行沙盒化**
60+
61+
1. **代码执行沙盒化**
6362
- 临时注入的 `code` 仅在本次交易中有效，无法修改账户的永久存储或触发后续交易。
64-
2. **签名权限隔离**
63+
2. **签名权限隔离**
6564
- `code` 中定义的签名逻辑仅适用于当前交易，不影响账户的其他操作。
66-
3. **钱包防护措施**
65+
3. **钱包防护措施**
6766
- 钱包需对用户展示 `code` 的意图（如“本次交易将执行以下操作...”），防止钓鱼攻击。
68-
4. **Gas 限额强制约束**
67+
4. **Gas 限额强制约束**
6968
- 即使 `code` 包含无限循环，`executionGas` 上限将强制终止执行，避免网络资源滥用。
7069

71-
72-
7370
#### **五、与 EIP-3074 的对比**
71+
7472
EIP-3074 同样允许 EOA 临时委托权限给智能合约，但其机制存在以下差异：
75-
| 特性 | EIP-3074 | EIP-7702 |
73+
| 特性 | EIP-3074 | EIP-7702 |
7674
|---------------------|-----------------------------------|-----------------------------------|
77-
| **权限范围** | 委托给固定合约（AUTH/AUTHCALL） | 每笔交易自定义代码（动态灵活） |
78-
| **签名兼容性** | 仅支持 ECDSA | 支持任意签名算法（由代码定义） |
79-
| **状态影响** | 可能遗留委托关系 | 完全无状态（交易后恢复） |
80-
| **Gas 效率** | 较高（需多次调用） | 较低（单交易内完成） |
81-
82-
75+
| **权限范围** | 委托给固定合约（AUTH/AUTHCALL） | 每笔交易自定义代码（动态灵活） |
76+
| **签名兼容性** | 仅支持 ECDSA | 支持任意签名算法（由代码定义） |
77+
| **状态影响** | 可能遗留委托关系 | 完全无状态（交易后恢复） |
78+
| **Gas 效率** | 较高（需多次调用） | 较低（单交易内完成） |
8379

8480
#### **六、潜在技术挑战**
85-
1. **协议层复杂性**
81+
82+
1. **协议层复杂性**
8683
- 需修改以太坊客户端（如 Geth、Nethermind）的交易处理逻辑，确保临时代码注入与恢复机制稳定。
87-
2. **开发工具适配**
84+
2. **开发工具适配**
8885
- 钱包和 SDK（如 Ethers.js、Hardhat）需更新以支持新交易类型的构建与解析。
89-
3. **测试网验证**
86+
3. **测试网验证**
9087
- 此前测试网曾因类似提案（如 EIP-3074）出现分叉问题，需充分验证边界条件。
9188

92-
93-
9489
### **总结**
95-
EIP-7702 通过引入动态代码注入的交易类型，在协议层实现了 EOA 的灵活升级，兼顾了兼容性与功能性。其技术细节体现了以太坊向智能账户体系演进的核心路径。随着 Pectra 升级的推进，这一提案有望成为链上用户体验革新的关键基础设施。
90+
91+
EIP-7702 通过引入动态代码注入的交易类型，在协议层实现了 EOA 的灵活升级，兼顾了兼容性与功能性。其技术细节体现了以太坊向智能账户体系演进的核心路径。随着 Pectra 升级的推进，这一提案有望成为链上用户体验革新的关键基础设施。

‎basic/49-Account-Abstraction/README.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,10 @@
11
# 简介
22

3+
[账户抽象历史](./development.md)
4+
5+
6+
## build
7+
38
- 示例AA账户见contracts目录
49
- js调用见scripts目录
510

0 commit comments

Comments
 (0)