fix aa task

basic/37-erc4626/readme.md

@@ -5,6 +5,8 @@
  https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol
 
 
+ 开发demo:
+ https://github.com/adamocallaghan/ERC4626_Strategy/blob/main/src/Vault.sol
 
 ## 参考链接
 

basic/38-alloy-rust/readme.md

@@ -1,6 +1,7 @@
 ## Outline
 
 本文旨在介绍如何使用 Rust SDK([alloy-rs](https://github.com/alloy-rs/alloy)) 与链上合约进行交互，进而开发 DApp。
+它的前身是ether-rs。
 
 参考文档：https://alloy.rs/examples/advanced/README
 
@@ -105,3 +106,15 @@ cargo run --bin main
 
 todo
 https://alloy.rs/guides/speed-up-using-u256
+
+Uniswap V2 Arbitrage Optimal Amount In： youtube
+https://www.youtube.com/watch?v=9EKksG-fF1k
+
+https://github.com/flashbots/simple-blind-arbitrage
+https://github.com/paco0x/amm-arbitrageur/blob/master/bot/index.ts
+
+## univ3 arbitrage：
+
+https://pawelurbanek.com/revm-alloy-anvil-arbitrage
+
+## 参考链接：

basic/45-Ethereum-2.0/mpt.md

@@ -1,2 +1,5 @@
 https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/
 
+https://github.com/ebuchman/understanding_ethereum_trie/blob/master/exercises/ex1.py
+
+https://consensys.io/blog/bonsai-tries-guide

basic/45-Ethereum-2.0/node.md

@@ -1,10 +1,98 @@
-## Run your own Ethereum Validator: 
+## Run your own Ethereum Validator:
 
-### EPF 
-系统课程： https://www.youtube.com/watch?v=nrwKxyBIYYk
+### EPF
 
+系统课程： https://www.youtube.com/watch?v=nrwKxyBIYYk
 
 https://medium.com/coinmonks/run-your-own-ethereum-validator-part-1-pbft-casper-ffg-casper-cbc-and-lmd-ghost-e68e8461acf8
 
+https://eth2book.info/
+
+## 节点同步
+
+Full node ， archive node
+
+### Full node
+
+同步方式有
+
+1. snap sync: 从最近的特定区块开始同步（checkpoint）， 保留最近的128个区块在内存中。
+
+snap sync 先下载区块头，验证通过后，下载区块体和收据。同时，进行state-sync， geth先下载每个区块的state trie的叶子节点，然后本地自己生成完整的state trie.
+用eth.syncing 检查是否同步完成。
+
+- download and verify headers
+- download block bodies and receipts. In parallel, download raw state data and build state trie
+- heal state trie to account for newly arriving data
+
+--syncmode 默认是snap
+
+2. FUll sync:  
+   full sync 逐个区块的同步，并从创世区块开始执行每个区块的交易，并生成状态。 也只保留128个区块状态。 约25分钟。其他block state会被pruned periddically.
+
+### Archive node
+
+适合用来查历史数据， 会保留所有区块的历史状态。 无需从checkpoint同步。
+通过配置geth的垃圾回收， 历史数据就不会被删除。
+geth --syncmode full --gcmode archive.
+
+## 共识客户端
+
+eth2.0 ，区块下载是由 共识客户端负责，验证由执行客户端负责。
+共识客户端有两个同步方式：
+optimistic syncing 和 checkpoint syncing
+
+### optimistic syncing
+
+在执行端验证之前就下载区块。 不能参与出块
+
+### checkpoint sync
+
+从https://eth-clients.github.io/checkpoint-sync-endpoints/ 下载checkpoint。
+
+## Databases
+
+since V1.9.0 , geth将 database分成两个部分。 Recent blocks 和state data 存储在 quick- access storage.
+
+旧数据 和收据 stored in Freezer database。
+
+### Recent blocks
+
+存贮在leverdb。 主要是SSD存储
+
+### Freezer/ ancients
+
+Older segments of the chain are moved out of the LevelDB database and into a freezer database. 主要存在HDD。
+
+the ancient chain segments is inside the chaindata directory
+
+## Pruning
+
+修剪操作依赖于状态数据库的“快照”（snapshots）来判断状态树（state trie）中哪些节点是“有用的”可以保留，哪些是“过时的”可以被删除。快照就像一个参照点，用来对比哪些数据仍然有效。
+
+Geth 的修剪过程分为 三个阶段：
+第一步是“遍历快照状态”：Geth 会遍历最底层的快照，并用 布隆过滤器（Bloom Filter） 构建一个集合，这个集合用来快速判断哪些状态树节点是属于目标状态树的。
+
+第二步是“修剪状态数据”：Geth 会删除那些 不在布隆过滤器集合中的状态树节点，也就是不再需要的旧数据。
+
+第三步是“压缩数据库”：修剪后会有很多空闲空间，Geth 会对数据库进行整理以释放出这些空间。
+
+## TXPOOL
+
+pending： 有效的交易
+Queued: 未来的交易,nonce更多的
+
+主要有以下几个方法：
+
+- txpool_content  
+  返回pending 和queued的交易
+- txpool_contentFrom  
+  返回特定地址的交易
+- txpool_inspect
+  比content的方法内容更详细
+- txpool_status
+  返回pending和queue的数量
+
+  ### MEV BOT
 
-https://eth2book.info/ 
+  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

@@ -1,21 +1,20 @@
-
-
-### EIP-7702 技
+### EIP-7702
 
 EIP-7702 的核心创新在于引入了一种新的交易类型，允许外部账户（EOA）在单次交易中临时转换为智能合约账户，赋予其灵活的功能扩展能力。以下从交易结构、执行流程、Gas 机制和安全性等方面详细阐述其技术实现。
 
-
 #### **一、新交易类型的结构设计**
+
 EIP-7702 定义了一种新的交易类型（ **Type 4**，具体编号由最终提案确定），其数据结构在现有交易字段基础上扩展了以下关键字段：
 
-| 字段名           | 类型       | 描述                                                                 |
-|-------------------|------------|----------------------------------------------------------------------|
-| `code`            | `bytes`    | 本次交易中临时执行的智能合约代码（字节码）。                        |
-| `signature`       | `bytes`    | 覆盖传统 ECDSA 签名的灵活签名格式，支持多签或非 ECDSA 算法（如 BLS）。 |
-| `validationGas`   | `uint256`  | 用于验证阶段（代码执行前）的 Gas 限额。                             |
-| `executionGas`    | `uint256`  | 用于代码执行阶段的 Gas 限额。                                       |
+| 字段名          | 类型      | 描述                                                                   |
+| --------------- | --------- | ---------------------------------------------------------------------- |
+| `code`          | `bytes`   | 本次交易中临时执行的智能合约代码（字节码）。                           |
+| `signature`     | `bytes`   | 覆盖传统 ECDSA 签名的灵活签名格式，支持多签或非 ECDSA 算法（如 BLS）。 |
+| `validationGas` | `uint256` | 用于验证阶段（代码执行前）的 Gas 限额。                                |
+| `executionGas`  | `uint256` | 用于代码执行阶段的 Gas 限额。                                          |
 
 **示例结构（伪代码）：**
+
 ```solidity
 struct EIP7702Transaction {
     // 标准交易字段（如 nonce, gasLimit, to, value 等）
@@ -28,68 +27,65 @@ struct EIP7702Transaction {
 }
 ```
 
-
-
 #### **二、交易执行流程**
+
 当用户发起 EIP-7702 交易时，以太坊网络按以下步骤处理：
 
-1. **交易验证阶段**  
+1. **交易验证阶段**
+
    - **签名验证**：不再强制使用 ECDSA 签名，而是根据 `code` 中定义的逻辑验证 `signature`。例如，代码可能要求多签验证或使用 BLS 聚合签名。
    - **临时状态注入**：将 `code` 临时绑定到用户的 EOA 地址，模拟智能合约账户的执行环境，但不修改链上账户的永久状态。
 
-2. **代码执行阶段**  
+2. **代码执行阶段**
+
    - **上下文切换**：在本次交易的执行环境中，用户的 EOA 地址被视为智能合约账户，其权限逻辑完全由 `code` 定义。
    - **自定义操作**：代码可执行任意逻辑，如批量交易、代付 Gas（使用 ERC-20 代币）、社交恢复验证等。
    - **Gas 分段管理**：`validationGas` 和 `executionGas` 分别限制验证与执行阶段的 Gas 消耗，防止资源耗尽攻击。
 
-3. **状态恢复**  
+3. **状态恢复**
    - 交易完成后，临时注入的 `code` 从账户中移除，EOA 恢复原始状态，不保留任何智能合约痕迹。
 
-
-
 #### **三、Gas 优化机制**
+
 EIP-7702 通过以下方式降低 Gas 成本：
-1. **减少交易层级**  
+
+1. **减少交易层级**
    - 相比 EIP-4337 的 UserOperation 需要 Bundler 打包并支付额外 Gas，EIP-7702 直接在协议层处理，省去中间环节。
-2. **合并操作**  
+2. **合并操作**
    - 单笔交易可完成多步操作（如授权+转账+跨链调用），减少总 Gas 消耗。
-3. **动态 Gas 分配**  
+3. **动态 Gas 分配**
    - 用户可灵活分配 `validationGas` 和 `executionGas`，避免为单一阶段预留过多冗余 Gas。
 
-
-
 #### **四、安全机制与风险控制**
-1. **代码执行沙盒化**  
+
+1. **代码执行沙盒化**
    - 临时注入的 `code` 仅在本次交易中有效，无法修改账户的永久存储或触发后续交易。
-2. **签名权限隔离**  
+2. **签名权限隔离**
    - `code` 中定义的签名逻辑仅适用于当前交易，不影响账户的其他操作。
-3. **钱包防护措施**  
+3. **钱包防护措施**
    - 钱包需对用户展示 `code` 的意图（如“本次交易将执行以下操作...”），防止钓鱼攻击。
-4. **Gas 限额强制约束**  
+4. **Gas 限额强制约束**
    - 即使 `code` 包含无限循环，`executionGas` 上限将强制终止执行，避免网络资源滥用。
 
-
-
 #### **五、与 EIP-3074 的对比**
+
 EIP-3074 同样允许 EOA 临时委托权限给智能合约，但其机制存在以下差异：
-| 特性                | EIP-3074                          | EIP-7702                          |
+| 特性 | EIP-3074 | EIP-7702 |
 |---------------------|-----------------------------------|-----------------------------------|
-| **权限范围**         | 委托给固定合约（AUTH/AUTHCALL）   | 每笔交易自定义代码（动态灵活）    |
-| **签名兼容性**       | 仅支持 ECDSA                      | 支持任意签名算法（由代码定义）    |
-| **状态影响**         | 可能遗留委托关系                  | 完全无状态（交易后恢复）          |
-| **Gas 效率**         | 较高（需多次调用）                | 较低（单交易内完成）              |
-
-
+| **权限范围** | 委托给固定合约（AUTH/AUTHCALL） | 每笔交易自定义代码（动态灵活） |
+| **签名兼容性** | 仅支持 ECDSA | 支持任意签名算法（由代码定义） |
+| **状态影响** | 可能遗留委托关系 | 完全无状态（交易后恢复） |
+| **Gas 效率** | 较高（需多次调用） | 较低（单交易内完成） |
 
 #### **六、潜在技术挑战**
-1. **协议层复杂性**  
+
+1. **协议层复杂性**
    - 需修改以太坊客户端（如 Geth、Nethermind）的交易处理逻辑，确保临时代码注入与恢复机制稳定。
-2. **开发工具适配**  
+2. **开发工具适配**
    - 钱包和 SDK（如 Ethers.js、Hardhat）需更新以支持新交易类型的构建与解析。
-3. **测试网验证**  
+3. **测试网验证**
    - 此前测试网曾因类似提案（如 EIP-3074）出现分叉问题，需充分验证边界条件。
 
-
-
 ### **总结**
-EIP-7702 通过引入动态代码注入的交易类型，在协议层实现了 EOA 的灵活升级，兼顾了兼容性与功能性。其技术细节体现了以太坊向智能账户体系演进的核心路径。随着 Pectra 升级的推进，这一提案有望成为链上用户体验革新的关键基础设施。
+
+EIP-7702 通过引入动态代码注入的交易类型，在协议层实现了 EOA 的灵活升级，兼顾了兼容性与功能性。其技术细节体现了以太坊向智能账户体系演进的核心路径。随着 Pectra 升级的推进，这一提案有望成为链上用户体验革新的关键基础设施。

basic/49-Account-Abstraction/README.md

@@ -1,5 +1,10 @@
 # 简介
 
+[账户抽象历史](./development.md)
+
+
+## build
+
 - 示例AA账户见contracts目录
 - js调用见scripts目录