diff --git a/basic/37-erc4626/readme.md b/basic/37-erc4626/readme.md index 53c555815..0aae19c19 100644 --- a/basic/37-erc4626/readme.md +++ b/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 ## 参考链接 diff --git a/basic/38-alloy-rust/readme.md b/basic/38-alloy-rust/readme.md index cef2a81fb..4c4eccd7d 100644 --- a/basic/38-alloy-rust/readme.md +++ b/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 + +## 参考链接： diff --git a/basic/45-Ethereum-2.0/mpt.md b/basic/45-Ethereum-2.0/mpt.md index 730e0c399..5961c876c 100644 --- a/basic/45-Ethereum-2.0/mpt.md +++ b/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 diff --git a/basic/45-Ethereum-2.0/node.md b/basic/45-Ethereum-2.0/node.md index 4a9f0c744..61e098121 100644 --- a/basic/45-Ethereum-2.0/node.md +++ b/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 diff --git a/basic/49-Account-Abstraction/7702.md b/basic/49-Account-Abstraction/7702.md index bff812ef3..1c9c82c59 100644 --- a/basic/49-Account-Abstraction/7702.md +++ b/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 升级的推进，这一提案有望成为链上用户体验革新的关键基础设施。 \ No newline at end of file + +EIP-7702 通过引入动态代码注入的交易类型，在协议层实现了 EOA 的灵活升级，兼顾了兼容性与功能性。其技术细节体现了以太坊向智能账户体系演进的核心路径。随着 Pectra 升级的推进，这一提案有望成为链上用户体验革新的关键基础设施。 diff --git a/basic/49-Account-Abstraction/README.md b/basic/49-Account-Abstraction/README.md index f0cce629e..23a958e5e 100644 --- a/basic/49-Account-Abstraction/README.md +++ b/basic/49-Account-Abstraction/README.md @@ -1,5 +1,10 @@ # 简介 +[账户抽象历史](./development.md) + + +## build + - 示例AA账户见contracts目录 - js调用见scripts目录 diff --git a/basic/49-Account-Abstraction/demowallet/test/Test.js b/basic/49-Account-Abstraction/demowallet/test/Test.js index aedac4eb2..f356f890c 100644 --- a/basic/49-Account-Abstraction/demowallet/test/Test.js +++ b/basic/49-Account-Abstraction/demowallet/test/Test.js @@ -1,36 +1,36 @@ -const { - time, - loadFixture, -} = require("@nomicfoundation/hardhat-network-helpers"); -const { anyValue } = require("@nomicfoundation/hardhat-chai-matchers/withArgs"); -const { expect } = require("chai"); -const { ethers } = require("hardhat"); -const { ERC4337EthersProvider, ERC4337EthersSigner, HttpRpcClient } = require("@account-abstraction/sdk"); -const {BaseAccountAPI} = require("@account-abstraction/sdk/dist/src/BaseAccountAPI"); -const {EntryPoint__factory} =require("@account-abstraction/contracts"); -const { BigNumber } = require("ethers"); -const abi = require("../artifacts/contracts/DemoAccount.sol/DemoAccount.json").abi; - -describe("ContractUnitTest", function () { +const { time, loadFixture } = require('@nomicfoundation/hardhat-network-helpers'); +const { anyValue } = require('@nomicfoundation/hardhat-chai-matchers/withArgs'); +const { expect } = require('chai'); +const { ethers } = require('hardhat'); +const { ERC4337EthersProvider, ERC4337EthersSigner, HttpRpcClient } = require('@account-abstraction/sdk'); +const { BaseAccountAPI } = require('@account-abstraction/sdk/dist/src/BaseAccountAPI'); +const { EntryPoint__factory } = require('@account-abstraction/contracts'); +const { BigNumber } = require('ethers'); +const abi = require('../artifacts/contracts/DemoAccount.sol/DemoAccount.json').abi; + +describe('ContractUnitTest', function () { // We define a fixture to reuse the same setup in every test. // We use loadFixture to run this setup once, snapshot that state, // and reset Hardhat Network to that snapshot in every test. async function deployContract() { // Contracts are deployed using the first signer/account by default const [owner, owner2, entryPointSigner] = await ethers.getSigners(); - - const DemoAccount_factory = await ethers.getContractFactory("DemoAccount"); - const demoAccount = await DemoAccount_factory.deploy(entryPointSigner.getAddress(), 2, owner.getAddress()); - await demoAccount.deployed(); - + + const DemoAccount_factory = await ethers.getContractFactory('DemoAccount'); + const demoAccount = await DemoAccount_factory.deploy(entryPointSigner.getAddress(), 2, owner.getAddress(), [ + owner.getAddress(), + owner2.getAddress(), + ]); + await demoAccount.waitForDeployment(); + await (await demoAccount.connect(owner).setSigner(owner.address, true)).wait(); await (await demoAccount.connect(owner).setSigner(owner2.address, true)).wait(); await (await demoAccount.connect(owner).changeThreshold(2)).wait(); - return { demoAccount, entryPointSigner, owner, owner2}; + return { demoAccount, entryPointSigner, owner, owner2 }; } - it("should validate user op successfully ", async function (){ - const { demoAccount, entryPointSigner, owner, owner2} = await loadFixture(deployContract); + it('should validate user op successfully ', async function () { + const { demoAccount, entryPointSigner, owner, owner2 } = await loadFixture(deployContract); var aaProvider = await getAAProvider(entryPointSigner.address, demoAccount, owner, owner2); //Convert transaction to userop const tx = await demoAccount.populateTransaction.changeThreshold(1); @@ -38,50 +38,52 @@ describe("ContractUnitTest", function () { target: tx.to ?? '', data: tx.data?.toString() ?? '', value: tx.value, - gasLimit: tx.gasLimit - }) + gasLimit: tx.gasLimit, + }); userOperation = await ethers.utils.resolveProperties(userOperation); //Validate userop const requestId = aaProvider.smartAccountAPI.getUserOpHash(userOperation); - var receipt = await (await demoAccount.connect(entryPointSigner).validateUserOp(userOperation, requestId, ethers.constants.AddressZero, 0)).wait(); + var receipt = await ( + await demoAccount.connect(entryPointSigner).validateUserOp(userOperation, requestId, ethers.constants.AddressZero, 0) + ).wait(); // console.log(receipt); }); - it("should run account business logics ", async function (){ - const { demoAccount, entryPointSigner, owner, owner2} = await loadFixture(deployContract); - const calldata = await demoAccount.interface.encodeFunctionData("changeThreshold", [3]); + it('should run account business logics ', async function () { + const { demoAccount, entryPointSigner, owner, owner2 } = await loadFixture(deployContract); + const calldata = await demoAccount.interface.encodeFunctionData('changeThreshold', [3]); await (await demoAccount.connect(entryPointSigner).execute(demoAccount.address, 0, calldata, 0)).wait(); const threshold = await demoAccount.threshold(); expect(threshold).to.be.equal(3); }); }); -describe("Test contract from entrypoint", function () { +describe('Test contract from entrypoint', function () { async function deployContract() { // Contracts are deployed using the first signer/account by default const [owner, owner2, bundler] = await ethers.getSigners(); - + //Deploy EntryPoint. Use our version of entrypoint, to better debug. - const EntryPoint__factory = await ethers.getContractFactory("EntryPointDbg"); + const EntryPoint__factory = await ethers.getContractFactory('EntryPointDbg'); const entryPoint = await EntryPoint__factory.deploy(); - await entryPoint.deployed(); - console.log('entry point deployed to ', entryPoint.address) + await entryPoint.waitForDeployment(); + console.log('entry point deployed to ', entryPoint.address); //Deploy DemoAccount - const DemoAccount_factory = await ethers.getContractFactory("DemoAccount"); + const DemoAccount_factory = await ethers.getContractFactory('DemoAccount'); const demoAccount = await DemoAccount_factory.deploy(entryPoint.address, 2, owner.getAddress()); - await demoAccount.deployed(); - + await demoAccount.waitForDeployment(); + await (await demoAccount.connect(owner).setSigner(owner.address, true)).wait(); await (await demoAccount.connect(owner).setSigner(owner2.address, true)).wait(); await (await demoAccount.connect(owner).changeThreshold(2)).wait(); - //Fund DemoAccount - await entryPoint.connect(owner).depositTo(demoAccount.address, {value: ethers.utils.parseEther("1.0")}); + //Fund DemoAccount + await entryPoint.connect(owner).depositTo(demoAccount.address, { value: ethers.utils.parseEther('1.0') }); console.log(`${demoAccount.address} now has ${await entryPoint.balanceOf(demoAccount.address)}`); - return { demoAccount, entryPoint, owner, owner2, bundler}; + return { demoAccount, entryPoint, owner, owner2, bundler }; } - it("should simulateValidation successfully from entrypoint", async function(){ - const { demoAccount, entryPoint, owner, owner2} = await loadFixture(deployContract); + it('should simulateValidation successfully from entrypoint', async function () { + const { demoAccount, entryPoint, owner, owner2 } = await loadFixture(deployContract); const aaProvider = await getAAProvider(entryPoint.address, demoAccount, owner, owner2); //get UserOperation const tx = await demoAccount.populateTransaction.changeThreshold(2); @@ -89,16 +91,15 @@ describe("Test contract from entrypoint", function () { target: tx.to ?? '', data: tx.data?.toString() ?? '', value: tx.value, - gasLimit: tx.gasLimit - }) + gasLimit: tx.gasLimit, + }); userOperation = await ethers.utils.resolveProperties(userOperation); //simulateValidation - await expect(entryPoint.simulateValidation(userOperation)).to.be.revertedWithCustomError(entryPoint, "ValidationResult"); + await expect(entryPoint.simulateValidation(userOperation)).to.be.revertedWithCustomError(entryPoint, 'ValidationResult'); }); - it("should handleOps successfully from entrypoint", async function(){ - - const { demoAccount, entryPoint, owner, owner2, bundler} = await loadFixture(deployContract); + it('should handleOps successfully from entrypoint', async function () { + const { demoAccount, entryPoint, owner, owner2, bundler } = await loadFixture(deployContract); const aaProvider = await getAAProvider(entryPoint.address, demoAccount, owner, owner2); //get UserOperation const tx = await demoAccount.populateTransaction.changeThreshold(2); @@ -106,59 +107,55 @@ describe("Test contract from entrypoint", function () { target: tx.to ?? '', data: tx.data?.toString() ?? '', value: tx.value, - gasLimit: tx.gasLimit - }) + gasLimit: tx.gasLimit, + }); userOperation = await ethers.utils.resolveProperties(userOperation); //handleOps await (await entryPoint.handleOps([userOperation], bundler.address)).wait(); //replay is not allowed - await expect(entryPoint.handleOps([userOperation], bundler.address)).to.be.revertedWithCustomError(entryPoint, "FailedOp"); + await expect(entryPoint.handleOps([userOperation], bundler.address)).to.be.revertedWithCustomError(entryPoint, 'FailedOp'); //bad signature is not allowed userOperation.nonce = BigNumber.from(1); - await expect(entryPoint.handleOps([userOperation], bundler.address)).to.be.revertedWithCustomError(entryPoint, "FailedOp"); + await expect(entryPoint.handleOps([userOperation], bundler.address)).to.be.revertedWithCustomError(entryPoint, 'FailedOp'); }); -}) - +}); class MultiSignerAccountAPI extends BaseAccountAPI { - constructor(params) { - super(params); - this.signers = params.signers; + super(params); + this.signers = params.signers; } async getAccountInitCode() { - //对应initCode字段 - return "0x"; + //对应initCode字段 + return '0x'; } async getNonce() { - //对应nonce字段 - const senderAddr = await this.getAccountAddress(); - const accountContract = new ethers.Contract(senderAddr, abi); - const originalProvider = this.provider; - const nonce = await accountContract.connect(originalProvider).nonce(); - return nonce; + //对应nonce字段 + const senderAddr = await this.getAccountAddress(); + const accountContract = new ethers.Contract(senderAddr, abi); + const originalProvider = this.provider; + const nonce = await accountContract.connect(originalProvider).nonce(); + return nonce; } - async encodeExecute(target, value, data){ - // const senderAddr = await this.getAccountAddress(); - return data; + async encodeExecute(target, value, data) { + // const senderAddr = await this.getAccountAddress(); + return data; } - async signUserOpHash (userOpHash) { - //对应signature字段。你可以使用BLS等各式各样的签名手段，只要链上可以验证即可 - var signatures = []; - const userOpHashBytes = ethers.utils.arrayify(userOpHash); - for (var signer of this.signers){ - const addrStr = signer.address.substring(2);//remove 0x - const sigStr = (await signer.signMessage(userOpHashBytes)).substring(2);//remove 0x - signatures.push(addrStr);//remove 0x - signatures.push(sigStr);//remove 0x - } - return "0x"+ signatures.join(''); + async signUserOpHash(userOpHash) { + //对应signature字段。你可以使用BLS等各式各样的签名手段，只要链上可以验证即可 + var signatures = []; + const userOpHashBytes = ethers.utils.arrayify(userOpHash); + for (var signer of this.signers) { + const addrStr = signer.address.substring(2); //remove 0x + const sigStr = (await signer.signMessage(userOpHashBytes)).substring(2); //remove 0x + signatures.push(addrStr); //remove 0x + signatures.push(sigStr); //remove 0x + } + return '0x' + signatures.join(''); } } - - async function getAAProvider(entryPointAddress, accountContract, originalSigner, originalSigner2) { const originalProvider = ethers.provider; const clientConfig = { @@ -167,27 +164,25 @@ async function getAAProvider(entryPointAddress, accountContract, originalSigner, walletAddres: accountContract.address, }; - const chainId = await ethers.provider.getNetwork().then(net => net.chainId); + const chainId = await ethers.provider.getNetwork().then((net) => net.chainId); const httpRpcClient = new HttpRpcClient(clientConfig.bundlerUrl, clientConfig.entryPointAddress, chainId); const entryPoint = EntryPoint__factory.connect(clientConfig.entryPointAddress, originalSigner); - - const smartAccountAPI = new MultiSignerAccountAPI( - { - provider: originalProvider, - entryPointAddress: clientConfig.entryPointAddress, - accountAddress: clientConfig.walletAddres, - signers: [originalSigner, originalSigner2] - } - ); + + const smartAccountAPI = new MultiSignerAccountAPI({ + provider: originalProvider, + entryPointAddress: clientConfig.entryPointAddress, + accountAddress: clientConfig.walletAddres, + signers: [originalSigner, originalSigner2], + }); const aaProvider = await new ERC4337EthersProvider( - chainId, - clientConfig, - originalSigner, - originalProvider, - httpRpcClient, - entryPoint, - smartAccountAPI + chainId, + clientConfig, + originalSigner, + originalProvider, + httpRpcClient, + entryPoint, + smartAccountAPI ); return aaProvider; -} \ No newline at end of file +} diff --git a/basic/49-Account-Abstraction/development.md b/basic/49-Account-Abstraction/development.md index 01a051cf2..53bbb1720 100644 --- a/basic/49-Account-Abstraction/development.md +++ b/basic/49-Account-Abstraction/development.md @@ -1,83 +1,90 @@ Ethereum AA（账户抽象）钱包的历史梳理，从技术提案、生态实践到未来方向分阶段展开： ### **阶段一：早期探索（2015-2020）** + #### **背景与问题** + - **EOA 的限制**：以太坊初始设计中，只有外部账户（EOA，由私钥控制）能主动发起交易，合约账户（CA）需依赖 EOA 触发，功能受限。 - **用户痛点**：EOA 依赖私钥管理、仅支持 ECDSA 签名、无法批量操作或代付 Gas。 #### **关键提案** -1. **EIP-86（2017）** + +1. **EIP-86（2017）** - 首次提出账户抽象概念，允许合约作为交易发起者，但因共识层改动复杂被搁置。 -2. **EIP-2938（2020）** +2. **EIP-2938（2020）** - 定义新的交易类型（`AA_TX_TYPE`），允许合约账户主动发起交易，需修改共识层，进展缓慢。 #### **实践尝试** -- **元交易（Meta Transaction）**：通过中继者（Relayer）代付 Gas，用户用签名授权操作（如 Gas Station Network）。 -- **局限性**：依赖中心化中继者，无法完全实现账户抽象。 - +- **元交易（Meta Transaction）**：通过中继者（Relayer）代付 Gas，用户用签名授权操作（如 Gas Station Network）。 +- **局限性**：依赖中心化中继者，无法完全实现账户抽象。 ### **阶段二：协议层突破（2021-2023）** + #### **核心提案** -1. **EIP-3074（2021）** - - 允许 EOA 将权限临时委托给智能合约（通过 `AUTH` 和 `AUTHCALL` 操作码），实现批量交易和 Gas 代付。 + +1. **EIP-3074（2021）** + - 允许 EOA 将权限临时委托给智能合约（通过 `AUTH` 和 `AUTHCALL` 操作码），实现批量交易和 Gas 代付。 - **问题**：安全隐患（恶意合约可能盗取资金），最终被 EIP-7702 取代。 -2. **EIP-4337（2021）** - - **免共识层升级的账户抽象方案**，引入 `UserOperation` 对象和 Bundlers（交易打包节点），允许合约账户自主管理交易逻辑。 +2. **EIP-4337（2021）** + - **免共识层升级的账户抽象方案**，引入 `UserOperation` 对象和 Bundlers（交易打包节点），允许合约账户自主管理交易逻辑。 - **创新点**：独立内存池、Paymasters（代付 Gas）、签名算法灵活化。 #### **AA 钱包落地** -- **Safe{Wallet}（原 Gnosis Safe）**：基于多签的智能合约钱包，支持权限分级和批量交易。 -- **Argent**：社交恢复钱包，用户可通过守护人（Guardian）重置私钥。 -- **Braavos（StarkNet）**：首个 L2 原生 AA 钱包，支持签名算法混合（如 ECDSA + 手机生物识别）。 - +- **Safe{Wallet}（原 Gnosis Safe）**：基于多签的智能合约钱包，支持权限分级和批量交易。 +- **Argent**：社交恢复钱包，用户可通过守护人（Guardian）重置私钥。 +- **Braavos（StarkNet）**：首个 L2 原生 AA 钱包，支持签名算法混合（如 ECDSA + 手机生物识别）。 ### **阶段三：生态爆发与优化（2023-2024）** + #### **技术演进** -1. **EIP-7702（2024）** + +1. **EIP-7702（2024）** - 结合 EIP-3074 和 4337 的优点，允许 EOA **单次交易内动态升级为合约账户**，降低 Gas 成本并提升兼容性。 -2. **ERC-4337 标准化** +2. **ERC-4337 标准化** - 定义 AA 钱包的通用接口，推动 Bundler、Paymaster 等组件的去中心化。 #### **生态扩展** -- **L2 集成**：Optimism、Base、zkSync 等链原生支持 AA，Gas 成本降低 90% 以上。 -- **应用场景**： - - **Web3 游戏**：玩家无需管理 Gas，通过会话密钥（Session Key）自动执行操作。 - - **企业财务**：多签 + 审计流 + 自动化付款（如 Safe{Wallet} 的模块化策略）。 -- **钱包竞争**： - - **智能钱包**：Ambire、Coinbase Smart Wallet 支持免助记词和代付 Gas。 - - **MPC 钱包**：ZenGo、Fireblocks 结合 MPC 与 AA，增强私钥安全性。 - +- **L2 集成**：Optimism、Base、zkSync 等链原生支持 AA，Gas 成本降低 90% 以上。 +- **应用场景**： + - **Web3 游戏**：玩家无需管理 Gas，通过会话密钥（Session Key）自动执行操作。 + - **企业财务**：多签 + 审计流 + 自动化付款（如 Safe{Wallet} 的模块化策略）。 +- **钱包竞争**： + - **智能钱包**：Ambire、Coinbase Smart Wallet 支持免助记词和代付 Gas。 + - **MPC 钱包**：ZenGo、Fireblocks 结合 MPC 与 AA，增强私钥安全性。 ### **阶段四：未来方向（2024+）** + #### **技术趋势** -1. **协议层深度集成** + +1. **协议层深度集成** - EIP-7702 纳入以太坊 Pectra 升级，推动 AA 成为默认账户模式。 -2. **签名算法多样化** +2. **签名算法多样化** - 支持 BLS 聚合签名、抗量子算法（如 STARKs），提升安全性和效率。 -3. **无感化体验** +3. **无感化体验** - 通过 ERC-7579 等标准，实现跨链 AA 钱包的自动适配和 Gas 优化。 #### **挑战与解决方案** -- **安全性**：需防范临时代码注入攻击（EIP-7702 的沙盒化执行是关键）。 -- **教育成本**：用户需理解智能账户与传统 EOA 的差异，钱包需简化交互界面。 + +- **安全性**：需防范临时代码注入攻击（EIP-7702 的沙盒化执行是关键）。 +- **教育成本**：用户需理解智能账户与传统 EOA 的差异，钱包需简化交互界面。 - **去中心化**：Bundler 和 Paymaster 网络的抗审查性与稳定性仍需优化。 +### **关键项目与链接** +1. **提案文档** + - [EIP-4337: Account Abstraction via Entry Point Contract](https://eips.ethereum.org/EIPS/eip-4337) + - [EIP-7702: Dynamic Account Conversion](https://github.com/ethereum/EIPs/pull/7702) +2. **AA 钱包案例** + - [Safe{Wallet}](https://safe.global/) + - [Argent](https://www.argent.xyz/) + - [Braavos](https://braavos.app/) +3. **生态分析** + - [以太坊账户抽象现状报告](https://ethereum.org/en/roadmap/account-abstraction/) + - [Vitalik 谈 AA 未来](https://vitalik.eth.limo/general/2023/01/20/account_abstraction.html) -### **关键项目与链接** -1. **提案文档** - - [EIP-4337: Account Abstraction via Entry Point Contract](https://eips.ethereum.org/EIPS/eip-4337) - - [EIP-7702: Dynamic Account Conversion](https://github.com/ethereum/EIPs/pull/7702) -2. **AA 钱包案例** - - [Safe{Wallet}](https://safe.global/) - - [Argent](https://www.argent.xyz/) - - [Braavos](https://braavos.app/) -3. **生态分析** - - [以太坊账户抽象现状报告](https://ethereum.org/en/roadmap/account-abstraction/) - - [Vitalik 谈 AA 未来](https://vitalik.eth.limo/general/2023/01/20/account_abstraction.html) - - -Ethereum AA 钱包的演进是从“外挂式解决方案”（如元交易）到“协议层原生支持”的过程，核心目标是**让智能合约账户获得 EOA 的主动能力**，同时保留可编程性。未来，随着 EIP-7702 的落地和 L2 的普及，AA 钱包有望成为 Web3 用户的标准入口，彻底改变私钥管理和链上交互的体验。 \ No newline at end of file +Ethereum AA 钱包的演进是从“外挂式解决方案”（如元交易）到“协议层原生支持”的过程，核心目标是**让智能合约账户获得 EOA 的主动能力**，同时保留可编程性。未来，随着 EIP-7702 的落地和 L2 的普及，AA 钱包有望成为 Web3 用户的标准入口，彻底改变私钥管理和链上交互的体验。 + +### [7702介绍](./7702.md) diff --git a/basic/84-MPC/README.md b/basic/84-MPC/README.md new file mode 100644 index 000000000..09359e692 --- /dev/null +++ b/basic/84-MPC/README.md @@ -0,0 +1,7 @@ +## MPC rust + + + + +## 参考链接 +- https://medium.com/@olusojiobah/intro-to-mpc-and-its-implementation-with-rust-a1f8891f38a4 \ No newline at end of file diff --git a/defi/Uniswap-V4/readme.md b/defi/Uniswap-V4/readme.md new file mode 100644 index 000000000..bad92dcac --- /dev/null +++ b/defi/Uniswap-V4/readme.md @@ -0,0 +1,3 @@ + +Dynamic Fees Hook: +https://medium.com/@umbrellaresearch/uniswap-v4-hooks-a-deep-dive-with-captain-hook-ii-44b0efc84e45 \ No newline at end of file