├── .github └── workflows │ └── ReopBot.yml ├── BillyC.md ├── Ellen.md ├── Jack-OuCJ.md ├── MRzzz-cyber.md ├── README.md ├── Sandybaby07.md ├── Sponge.md ├── a39955720.md ├── alexliao.md ├── alichaw.md ├── bamboochen92518.md ├── blahole.md ├── bobs-1.md ├── brucexu-eth.md ├── chesley666.md ├── cxc474.md ├── easyshellworld.md ├── emailpractice.md ├── evshary.md ├── fffuuuming.md ├── gardennn.md ├── gpteth.md ├── helloworldsmart.md ├── images ├── alex │ ├── image1.png │ ├── image2.png │ ├── image3.png │ └── image4.png └── none │ └── 1.PNG ├── jameelovecat.md ├── jjeejj.md ├── k66.md ├── kevinsslin.md ├── keylen.md ├── kris77z.md ├── luleigreat.md ├── narnona.md ├── nghdavid.md ├── nx-xn2002.md ├── qiaopengjun5162.md ├── sync_status_readme.py ├── tofudfy.md ├── universe-ron.md ├── wayhome.md ├── wiasliaw.md ├── wodeche.md ├── xwwkk.md ├── ygy-1231.md ├── york.md ├── yushiwuzheng666.md └── zion.md /.github/workflows/ReopBot.yml: -------------------------------------------------------------------------------- 1 | name: Repo Management 2 | 3 | on: 4 | pull_request_target: 5 | types: [closed] 6 | schedule: 7 | - cron: "0 0 * * *" # 每天午夜运行 8 | push: 9 | branches: [main] # 每次推送到main分支时也运行 10 | 11 | permissions: 12 | contents: write 13 | pull-requests: write 14 | 15 | jobs: 16 | invite-contributor: 17 | runs-on: ubuntu-latest 18 | if: github.event_name == 'pull_request_target' && github.event.pull_request.merged == true 19 | steps: 20 | - name: Invite contributor 21 | id: invite-contributor 22 | uses: actions/github-script@v6 23 | with: 24 | github-token: ${{ secrets.PAT_WITH_INVITE_PERMISSIONS }} 25 | script: | 26 | const { owner, repo } = context.repo; 27 | const username = context.payload.pull_request.user.login; 28 | 29 | console.log(`Checking if ${username} is already a collaborator...`); 30 | 31 | try { 32 | const { data: permissionLevel } = await github.rest.repos.getCollaboratorPermissionLevel({ 33 | owner, 34 | repo, 35 | username, 36 | }); 37 | 38 | if (permissionLevel.permission === 'admin' || permissionLevel.permission === 'write') { 39 | console.log(`${username} is already a collaborator with sufficient permissions.`); 40 | return; 41 | } 42 | 43 | console.log(`${username} is a collaborator but needs permission update.`); 44 | } catch (error) { 45 | if (error.status !== 404) { 46 | console.error(`Error checking collaborator status: ${error.message}`); 47 | throw error; 48 | } 49 | console.log(`${username} is not a collaborator.`); 50 | } 51 | 52 | try { 53 | console.log(`Inviting ${username} as a collaborator...`); 54 | const response = await github.rest.repos.addCollaborator({ 55 | owner, 56 | repo, 57 | username, 58 | permission: 'push' 59 | }); 60 | 61 | if (response.status === 201) { 62 | console.log(`Invitation sent to ${username} as a collaborator with push permission.`); 63 | core.setOutput('invitation_sent', 'true'); 64 | } else if (response.status === 204) { 65 | console.log(`${username}'s permissions updated to push.`); 66 | core.setOutput('invitation_sent', 'false'); 67 | } 68 | } catch (error) { 69 | console.error(`Error inviting/updating collaborator: ${error.message}`); 70 | core.setFailed(`Error inviting/updating collaborator: ${error.message}`); 71 | } 72 | 73 | - name: Comment on PR 74 | if: steps.invite-contributor.outputs.invitation_sent == 'true' 75 | uses: actions/github-script@v6 76 | with: 77 | github-token: ${{ secrets.GITHUB_TOKEN }} 78 | script: | 79 | const { owner, repo } = context.repo; 80 | const issue_number = context.payload.pull_request.number; 81 | const username = context.payload.pull_request.user.login; 82 | try { 83 | await github.rest.issues.createComment({ 84 | owner, 85 | repo, 86 | issue_number, 87 | body: `Thanks for your contribution, @${username}! You've been invited as a collaborator with push permissions. Please check your email for the invitation.` 88 | }); 89 | console.log(`Comment posted on PR #${issue_number}`); 90 | } catch (error) { 91 | console.error(`Error posting comment: ${error.message}`); 92 | core.setFailed(`Error posting comment: ${error.message}`); 93 | } 94 | 95 | update-readme: 96 | runs-on: ubuntu-latest 97 | if: github.event_name == 'schedule' || github.event_name == 'push' 98 | steps: 99 | - uses: actions/checkout@v2 100 | - name: Set up Python 101 | uses: actions/setup-python@v2 102 | with: 103 | python-version: "3.x" 104 | - name: Install dependencies 105 | run: | 106 | python -m pip install --upgrade pip 107 | pip install PyGithub pytz 108 | - name: Update README 109 | env: 110 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 111 | START_DATE: ${{ vars.START_DATE }} 112 | END_DATE: ${{vars.END_DATE }} 113 | FILE_SUFFIX: ${{vars.FILE_SUFFIX}} 114 | FIELD_NAME: ${{vars.FIELD_NAME}} 115 | run: python sync_status_readme.py 116 | - name: Check for changes 117 | id: git-check 118 | run: | 119 | git diff --exit-code README.md || echo "modified=true" >> $GITHUB_OUTPUT 120 | - name: Commit changes 121 | if: steps.git-check.outputs.modified == 'true' 122 | run: | 123 | git config --local user.email "action@github.com" 124 | git config --local user.name "GitHub Action" 125 | git add README.md 126 | git commit -m "Update commit status table" 127 | git push 128 | 129 | notify-api: 130 | runs-on: ubuntu-latest 131 | if: github.event_name == 'pull_request_target' && github.event.pull_request.merged == true || github.event_name == 'push' 132 | steps: 133 | - name: Setup Node.js 134 | uses: actions/setup-node@v3 135 | with: 136 | node-version: "16" 137 | 138 | - name: Install axios 139 | run: npm install axios 140 | 141 | - name: Call API 142 | uses: actions/github-script@v6 143 | with: 144 | github-token: ${{ secrets.GITHUB_TOKEN }} 145 | script: | 146 | const axios = require('axios'); 147 | const commit_sha = context.sha; 148 | const { owner, repo } = context.repo; 149 | 150 | try { 151 | const { data: commit } = await github.rest.repos.getCommit({ 152 | owner, 153 | repo, 154 | ref: commit_sha 155 | }); 156 | 157 | // Get user details 158 | const { data: user } = await github.rest.users.getByUsername({ 159 | username: commit.author.login 160 | }); 161 | 162 | 163 | // Output information 164 | console.log('Commit Author Information:'); 165 | console.log('------------------------'); 166 | console.log(`Name: ${commit.commit.author.name}`); 167 | console.log(`Email: ${commit.commit.author.email}`); 168 | console.log(`GitHub Username: ${commit.author.login}`); 169 | console.log(`User ID: ${user.id}`); 170 | console.log(`Account Type: ${user.type}`); 171 | console.log(`Created At: ${user.created_at}`); 172 | 173 | const response = await axios.get(`https://api.intensivecolearn.ing/api/programs/createByRepo/${owner}/${repo}`); 174 | 175 | console.log('API response:', response.data); 176 | 177 | const updateUserNotesResp = await axios.get(`https://api.intensivecolearn.ing/api/programs/updateStudynotes?owner=${owner}&repo=${repo}&userGitId=${user.id}`); 178 | 179 | console.log('updateUserNotesRespAPI response:', updateUserNotesResp.data); 180 | 181 | } catch (error) { 182 | console.error('Error calling API:', error.message); 183 | core.setFailed(`Error calling API: ${error.message}`); 184 | } 185 | -------------------------------------------------------------------------------- /BillyC.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. Billy 11 | 2. Yes, will try my best 12 | 3. TG: ounaiewfo 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | ### 2025.05.15 21 | 22 | ### 2025.05.16 23 | 24 | EIP-7702 是為了讓傳統 EOA具備智慧帳戶能力而提出的提案，概念是透過一種特殊的Delegation Designator（0xef0100 || address），讓 EOA 指向外部的智能合約。 25 | 26 | 這讓 EOA 能有更多功能，包括： 27 | - 批次交易執行：可在單一交易中完成多個操作，提高效率與用戶體驗。 28 | - Gas Support：允許第三方支付交易費用（如 Dapp 為新用戶贊助 Gas）。 29 | - 多簽與替代簽章邏輯：可將驗證邏輯改為社交恢復、多重簽章等形式。 30 | 31 | 此外，此提案也與帳戶抽象化目標一致，讓以太坊未來的錢包可以自由定義驗證機制與控制權限架構。但要注意以下安全問題： 32 | 33 | - Delegated若未妥善設計存取控制，將導致任意執行邏輯（Access Control Risk） 34 | - Constructor可被front run，導致帳戶被接管 35 | - 多次委派間若未考慮Storage Collision，會出現邏輯漏洞 36 | - 雜湊與簽名機制若不嚴謹，可能導致 replay 攻擊或錯誤授權（Replay / Verification Risk） 37 | 38 | ### 2025.05.17 39 | 40 | 1. 閱讀 https://hackmd.io/@colinlyguo/SyAZWMmr1x 41 | 42 | ``` 43 | contract Proxy { 44 | address immutable implementation; 45 | 46 | constructor(address impl) { 47 | implementation = impl; 48 | } 49 | 50 | fallback() external payable { 51 | address impl = implementation; 52 | assembly { 53 | calldatacopy(0, 0, calldatasize()) 54 | let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0) 55 | returndatacopy(0, 0, returndatasize()) 56 | switch result 57 | case 0 { revert(0, returndatasize()) } 58 | default { return(0, returndatasize()) } 59 | } 60 | } 61 | } 62 | ``` 63 | 64 | 2.Idea發想 65 | 66 | Session Key可以使用在DeFi登入，減少User friction並增加交易速度 67 | 結合access control限制session key使用情境 68 | 69 | 例如Game Fi如果需要短時間內多次跟合約互動特定function，就可以使用 70 | 71 | 72 | ### 2025.05.18 73 | 74 | 75 | 76 | -------------------------------------------------------------------------------- /Ellen.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | # Ellen 5 | 6 | 1. 自我介绍: 大家好，我是 Ellen ，喜欢用 Rust JS Golang 搞点小工具玩，坚决不炒币的穷逼技术，不赚钱只交朋友 7 | 2. 你认为你会完成本次残酷学习吗？： 能 （信心是要有的 8 | 3. 你的联系方式（推荐 Telegram）: @WGB5445 9 | 10 | ## Notes 11 | 12 | 13 | 14 | ### 2025.07.11 15 | 16 | 笔记内容 17 | 18 | ### 2025.07.12 19 | 20 | 21 | -------------------------------------------------------------------------------- /Jack-OuCJ.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # Jack_OuCJ 9 | 10 | 1. 自我介绍 最近在转行 Web3，希望能参与社区学习Web3相关知识，然后回馈社区。 11 | 2. 你认为你会完成本次残酷学习吗？会 12 | 3. 你的联系方式（推荐 Telegram）@Jack_OuCJ 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | * 以太坊账户类型 20 | * 什么是 EIP-7702 21 | * EIP-7702 关键组成部分 22 | * 与EIP-4337 的对比 23 | 24 | Day 1 笔记：https://www.notion.so/Day-1-EIP-7702-1f4f5920d54c801cbcb8ccf347843864?pvs=4 25 | 26 | ### 2025.05.15 27 | * 背景概述 28 | * 访问控制风险（Access Controls） 29 | * 初始化风险（Initialization Challenges） 30 | * 存储冲突风险（Storage Collisions） 31 | * 总结 32 | 33 | Day 2 笔记：https://www.notion.so/Day-2-EIP-7702-1f4f5920d54c80b4a53dd6077209648b?pvs=4 34 | 35 | ### 2025.05.16 36 | 记录了 EIP-7702智能账户的执行过程 37 | 38 | Day 3 笔记：https://www.notion.so/Day-3-EIP-7702-1f5f5920d54c804ea27bfe51c819817c?pvs=4 39 | 40 | ### 2025.05.17 41 | 记录了 EIP-7702 Recovery过程 42 | 43 | Day 4 笔记：https://www.notion.so/Day-4-EIP-7702-Recovery-1f5f5920d54c809eb873ec4d1db33f88?pvs=4 44 | 45 | ### 2025.05.18 46 | 记录了 EIP-7702 一些疑问和展望 47 | 48 | Day 5 笔记：https://www.notion.so/Day-5-1f7f5920d54c80c3b566f9817dcc1972?pvs=4 49 | 50 | ### 2025.05.19 51 | 记录了Set Code 代付 Gas 的代码实践 52 | 53 | Day 6 笔记：https://www.notion.so/Day-6-Set-Code-Gas-1f8f5920d54c8022a639ce72f1b86faa?pvs=4 54 | 55 | ### 2025.05.20 56 | 记录了EIP-7702 相关技术思考 57 | 58 | Day 7 笔记：https://www.notion.so/Day-7-EIP-7702-1f9f5920d54c8099bfb4c22a30959b4d?pvs=4 59 | 60 | ### 2025.05.21 61 | 62 | 记录了和账户抽象相关的协议，分析优缺点 63 | 64 | Day 8 笔记：https://www.notion.so/Day-8-7702-EIP-1faf5920d54c80eb8358d71e32e6327b?pvs=4 65 | 66 | ### 2025.05.22 67 | 记录了7702协议对 DEFI 的影响 68 | 69 | Day 9 笔记：https://www.notion.so/Day-9-7702-DEFI-1fbf5920d54c808e9ec0e92529dc5d6d?pvs=4 70 | 71 | ### 2025.05.23 72 | 记录了7702的一些视频实践内容 73 | 74 | Day 10 笔记：https://www.notion.so/Day-10-7702-1fcf5920d54c809b9123c936744c0a62?pvs=4 75 | -------------------------------------------------------------------------------- /MRzzz-cyber.md: -------------------------------------------------------------------------------- 1 | timezone: UTC+8 2 | --- 3 | 4 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 5 | 6 | 7 | # MRzzz-cyber 8 | 9 | 1. Marcus 10 | 2. 我会，我有很多关于 EIP-7702 改造和做应用的想法，我想通过系统的学习来实现这些内容 11 | 3. TG:@Marcuszheng 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.05.14 18 | ### EIP 7702 是什么 19 | EIP-7702 是以太坊的一项提案（Ethereum Improvement Proposal），旨在为账户抽象（Account Abstraction，AA）提供一种新的解决方案，主要特点是 EOA 可以转换为智能合约 20 | 21 | 主要的 2 点机制 22 | 23 | 临时角色转换：EOA（普通用户钱包）在单笔交易中可临时转换为智能合约账户，执行完交易后恢复为EOA，无需永久改变账户类型。 24 | 25 | 兼容性：与现有以太坊基础设施（如钱包、浏览器）保持兼容，减少升级阻力。 26 | 27 | 28 | EIP 7702 在提出之前也有其他的 EIP，如 EIP-4377 和 EIP-3074 29 | 30 | EIP 4337 和 EIP 7702 的区别 31 | EIP-4337 32 | 33 | 无需协议层改动：通过智能合约和“用户操作内存池”（UserOperation mempool）实现账户抽象，完全在应用层运行。 34 | 35 | 兼容性优先：不修改以太坊底层协议，避免硬分叉，适合渐进式推广。 36 | 37 | EIP-7702 38 | 39 | 协议层优化：直接修改以太坊协议，允许外部账户（EOA）在单笔交易中临时转换为智能合约账户，结束后恢复为 EOA。 40 | 41 | EOA 功能扩展：旨在为传统 EOA 赋予智能合约钱包的能力（如批量交易、Gas代付），同时保留EOA的简单性。 42 | ![image](https://github.com/user-attachments/assets/e8d88450-536a-464a-a695-7756c56df014) 43 | 44 | 45 | EIP - 3074 46 | EIP 3074 也是和 7702 差不多的思路，EIP-3074 试图赋予 EOA 更多权力，允许他们将其 EOA 的控制权委托给智能合约，但是目的是为了调用 EOA，而不像 7702 这么灵活，7702 允许一个用户任何帐户历史记录、ETH、NFT、代币的 EOA 成为一个智能合约 47 | 3074 的一个最大问题「如果有人制定恶意合约并且用户委托给他们怎么办？」，毕竟委托给恶意合约可能会导致用户的钱包里的所有加密资产都被抽走。 48 | 49 | 解决这个问题的方法是钱包服务提供商甚至不允许用户对任何合约进行授权，他们可能会保留一份用户可以委托授权的智能合约白名单列表，并且此列表之外的任何合约都不会显示给用户。限制了 3074 的使用 50 | 51 | EIP 7702 对比 3074 会更加好 52 | 53 | （1）安全性显著提升 54 | 3074的风险： 55 | 56 | 一旦EOA通过AUTH授权调用者合约，后者可无限期代表EOA发起交易，若合约被攻击或作恶，用户资产可能被盗。 57 | 58 | 需用户主动撤销授权（类似Token的approve漏洞）。 59 | 60 | 7702的改进： 61 | 62 | 授权仅对单笔交易有效，交易完成后权限自动失效，从根本上杜绝长期风险。 63 | 64 | （2）用户体验更简单 65 | 3074要求用户理解“委托授权”流程，并主动调用AUTH；而7702直接嵌入交易，用户无需额外操作。 66 | 67 | 例如：Gas代付在7702中由协议自动处理，而3074需依赖调用者合约的配合。 68 | 69 | （3）协议层优雅性 70 | 3074引入AUTH/AUTHCALL等新操作码，增加了协议复杂性； 71 | 72 | 7702通过扩展交易类型（类似EIP-1559的风格）实现，更符合以太坊长期设计哲学。 73 | 74 | ![image](https://github.com/user-attachments/assets/52973e2b-71ea-4314-b075-8092a4b01736) 75 | 76 | 77 | ### 2025.05.15 78 | 79 | Gas 代付的实现，交易者和发起者可以是不一样的 80 | ![image](https://github.com/user-attachments/assets/4f136e34-da8d-47c7-99b6-fa799d999c8a) 81 | 82 | 如果同时授权多个条目，只有最后一个条目会实现，其他的被覆盖掉 83 | ![image](https://github.com/user-attachments/assets/f1018444-6e2e-4222-a0a0-c85fa67cdc4f) 84 | 85 | 86 | 执行方式 87 | ![image](https://github.com/user-attachments/assets/1910f5a4-a778-449e-8d6c-4ee8890b31bd) 88 | 89 | 整个实现过程，类似于 DelegateCall 合约 90 | ![image](https://github.com/user-attachments/assets/219e3838-994f-4549-b327-d089274f4531) 91 | 92 | 私钥依然是最高管理权限，如果你在部署完 7702 后，将私钥删除，依然无法找回你的账户 93 | 94 | Chain ID 如果为 0，那么你是可以在任何的支持 ERC-20 的 EVM 链进行同样操作的，但是同样的 Chain，在不同的链上的代码可能不一致，这时候如果遇见 Chain ID 为 0 的合约，就需要多加注意 95 | ![image](https://github.com/user-attachments/assets/f2044657-bef6-4a70-8ce9-046e0f4c81eb) 96 | 97 | 98 | 7702 可以允许其他用户来帮他发起一个委托交易 99 | ![image](https://github.com/user-attachments/assets/c957e0fc-c25f-4b8c-9f18-caf89d17a202) 100 | 101 | 102 | ![image](https://github.com/user-attachments/assets/8c3fc2ed-f67f-4b3c-9386-843ced478376) 103 | 104 | 思考的思路：智能合约充值，智能合约加油站 105 | 106 | 目前带给开发者一个问题：假设交易发起者是 EOA 钱包发起者将不再可行 107 | 108 | 钓鱼产业的确会加剧 109 | 110 | 我有一个疑问，当我委托给一个新的 EIP-7702 合约的时候，以前的老的那个合约会取消吗，明天再学习一下，然后看一看应用 111 | 112 | 113 | ### 2025.05.16 114 | 115 | EIP-7702 的一些应用方向 116 | 117 | 118 | 1. Gas 赞助——EOA 需要 ETH 来进行任何交易。（类似于钱包里面的加油站，可以帮助用户快速体验 Dapp） 119 | 120 | 2. 交易批处理 - 将多笔交易批处理为单笔交易 - 即在一笔交易中（批准+交换）。（DeFi 三件套批量授权器，自己做聚合器策略等等） 121 | 122 | 3. 帐户恢复、继承——如果私钥丢失或所有者去世，可以恢复您的帐户的方法。（账户恢复和 4377 差不多） 123 | 124 | 4. 权限降级——每天仅允许花费 1% 的 ETH。（基于这个感觉可以做一个 DeFi 冷静期或者合约冷静期的功能，当你爆仓或者） 125 | 126 | 5. 双因素授权，基于生物特征的签名。 127 | 128 | 以太坊的最终目标是RIP-7560（原生账户抽象） 129 | 130 | 7702 的实现路径 131 | ![image](https://github.com/user-attachments/assets/478e3268-5048-423c-a743-a3767ad3ecf4) 132 | 133 | 134 | 7702 的未来 135 | 136 | 可以肯定地说，对于大多数钱包提供商和 EOA 账户来说，EIP-7702 + ERC-4337 基础设施是极有可能的未来。 137 | 138 | 7702 + 4337“增强版 EOA”简化了几乎所有智能账户功能。智能账户的普及速度将比预期更快。 139 | 140 | EOA 的 Gas 赞助和付款机制将为 Dapps 增添更多精彩功能。预计无 Gas 交易将成为主流。 141 | 142 | 143 | ### 2025.05.17 144 | 145 | 今天学习的是 7702 所带来的一些问题，主要是用户在面临钱包迁移到智能合约所带来的一些问题 146 | 147 | 当用户迁移到智能账户时： 148 | 149 | 他们会获得一个全新的区块链地址 150 | 他们的EOA的交易历史不会被转移 151 | 他们的链上声誉和身份变得支离破碎 152 | NFT、POAPs和其他数字收藏品留在旧地址 153 | 他们失去了与识别其先前地址的dApp的连接 154 | 155 | ### 以太坊的账户类型 156 | EOA：私钥控制的专有账户： 157 | 1. 可以发起交易 158 | 2. 不能包含代码 159 | 3. 完全由私钥控制 160 | 4. 必须使用原生ETH支付手续费 161 | 162 | 合约账户：智能合约 163 | 1. 包含并执行代码 164 | 2. 由其代码逻辑控制 165 | 3. 无法发起交易（只能响应交易） 166 | 4. 不能直接支付手续费（由调用者支付） 167 | 168 | 智能账户：用户账户可编程化 169 | 1. 多种授权方法：包括多重签名要求、社交恢复和时间锁 170 | 2. 手续费抽象：使用ERC-20代币支付费用，而不使用ETH或由第三方赞助费用 171 | 3. 批量交易：在单个交易中执行多个操作 172 | 4. 可编程权限：会话密钥、支出限额和特定于应用的权限 173 | 5. 恢复机制：在没有助记词的情况下恢复访问的选项 174 | 6. 模块化组件：可插拔验证、执行、Hook和回退 175 | 176 | 177 | 178 | ### 2025.05.18 179 | 180 | 今天系统的调研一下 EIP-7702 的应用场景以及现在出现的应用分析 181 | 182 | ### 交易批处理 183 | 一次交易确定多笔交易，如把签名授权和交易打包在一起，还有就是可以把一笔交易的输出作为下一笔交易的输入 184 | 有点像是我将 Uniswap，Aave，makerDAO 等的一系列操作打包成一笔交易，用户只需要签名一笔即可完成，聚合交易方向 185 | 而且他和传统的 yearn 聚合器理念还不一样 186 | 187 | 1. EIP-7702 的打包交易能力 188 | 189 | 如何实现聚合交易？ 190 | 临时智能合约逻辑： 191 | 用户可以在单笔交易中注入一段代码，动态组合多个操作（例如：在 Uniswap、SushiSwap 之间比价，选择最优路径兑换代币，并将结果存入 Aave）。 192 | 193 | 原子性执行： 194 | 所有操作在同一笔交易中完成，无需预先授权或多次签名 195 | 196 | 核心优势： 197 | 用户主权：用户自定义聚合逻辑，无需依赖第三方协议。 198 | 199 | 无中间合约：直接通过临时代码实现，减少信任假设。 200 | 201 | 灵活性：每笔交易可动态调整策略（如更换 DEX 或调整参数）。 202 | 203 | 2. Yearn 等传统聚合器的工作原理 204 | 如何实现聚合交易？ 205 | 预先部署的智能合约： 206 | Yearn 的聚合策略（如 yVault）由团队开发并固定在合约中，用户需将资产存入合约，由合约自动执行最优策略。 207 | 208 | 中心化策略管理： 209 | 策略逻辑由 Yearn 团队或社区提案更新，用户无法实时自定义。 210 | 211 | 示例流程： 212 | 213 | 用户存入 ETH 到 Yearn 合约。 214 | 215 | Yearn 合约自动在多个 DeFi 协议间分配资产（如兑换、质押、借贷）。 216 | 217 | 用户赎回时，Yearn 清算头寸并返回收益。 218 | 219 | 核心优势： 220 | 自动化：用户无需主动管理，适合被动收益需求。 221 | 222 | 规模效应：资金池共享 Gas 成本和流动性。 223 | 224 | ![image](https://github.com/user-attachments/assets/3d1a9b1e-cf80-450c-8939-8ac7c01c27c9) 225 | 226 | EIP-7702 像 “自己写脚本”： 227 | 你临时写一段代码（如 Python 脚本）抓取多个网站数据并处理，完全按需定制。 228 | 229 | Yearn 像 “订阅服务”： 230 | 你使用一个现成的 SaaS 工具（如 Zapier），功能固定但省心。 231 | 232 | 233 | 234 | 235 | 236 | ### 费用赞助 237 | 应用程序可以为其用户的交易支付费用 238 | 用户可以使用ERC-20代币而不是ETH支付手续费 239 | 服务可以提供交易打包和费用优化 240 | 241 | ### 权限管理 242 | 只能与特定应用交互的密钥 243 | 每天只能支出其持有的1% 的密钥 244 | 可以交易ERC-20代币但不能交易ETH的密钥 245 | 246 | 247 | 明天思考一下赞助费用和权限管理的应用场景 248 | 249 | 250 | 251 | ### 2025.05.19 252 | 理解聚合器很简单：就是一套金融组合策略，通过智能合约自动执行，通常是一些低风险金融策略，但是组合起来也挺高的，最简单的道理就是复投策略，你传统的手动 Claim 再复投，而聚合器可以设置一个时间周期 Claim 再复投的策略 253 | 然后聚合器首先需要的是读取不同 DeFi 协议的输出，然后组合，并通过 Token 可以读取标准化的 APR 输出，并转移到提供最佳回报的地方。 254 | 255 | 256 | 今天在思考一个 7702 的应用场景，类似于聚合器，传统的聚合器问题在于 257 | ![image](https://github.com/user-attachments/assets/6289ebf3-5440-4fe1-8991-0ba0f5c16c35) 258 | 259 | 我其实在想的是一种能自动显示目前 DeFi 协议 apy 的产品，比如 uniswap 稳定币或者借贷产品的收益，然后像一个一个的组件显示在前端，用户可以自由拖动这些产品，最后组装成一个策略包，一键发起交易（其中就运用到 7702 打包交易的功能） 260 | 和 AI 的对话 261 | ![image](https://github.com/user-attachments/assets/a40f2d25-e007-4e49-9c76-4dcd7bc1889d) 262 | 263 | ![image](https://github.com/user-attachments/assets/403b94e9-f2b8-4c33-9877-35feec22a173) 264 | 265 | MVP 需求实现 266 | ![image](https://github.com/user-attachments/assets/2de53015-b1a7-41d4-9667-2a83a8914552) 267 | 268 | 269 | 270 | 271 | 272 | ### 2025.05.20 273 | 7702 的另外一个应用方向：钱包授权 274 | 在了解 7702 之前，我先体验了一下目前的钱包授权工具:Revoke 和 rabby 内置的钱包取消授权功能 275 | https://revoke.cash/ 276 | ![image](https://github.com/user-attachments/assets/fd42f72b-b5f1-4294-b983-8ac61afd7db8) 277 | 278 | Revoke Cash 我觉得是比较适合于批量取消授权的的，然后也足够简单,不需要链接钱包等等 279 | 7702 带给钱包+授权方面的思考，我的想法是有几点 280 | 1. 批量授权，比如针对一个 DeFi 三件套的授权 281 | 2. 授权的范围大小，我授权的范围在我每天只花 1% 的 ETH 282 | 3. 授权的代币范围，适用于 PayFi 方面 283 | 284 | 285 | ### 2025.05.21 286 | 7702 的另外一个应用方向：Gas 代付 287 | 这会是下一个大规模应用的起点，大部分的钱包新人面临的第一个问题在于 Gas 没有，需要从交易所里进行充值并冲入，其实我觉得这一步完全可以不需要 288 | 一、Gas 代付的核心应用场景 289 | 1. 新用户引导（Onboarding） 290 | 场景：新用户没有原生链代币（如 ETH、MATIC），无法支付 Gas。 291 | 292 | 解决方案： 293 | 294 | 项目方或赞助商代付 Gas，让用户直接与 DApp 交互（如 Mint NFT、参与空投）。 295 | 296 | 结合 账户抽象（AA），实现无 Gas 交易（如 Biconomy、Stackup）。 297 | 298 | 2. 批量交易 & 企业级应用 299 | 场景：企业需要批量执行链上操作（如发放工资、NFT 空投）。 300 | 301 | 解决方案： 302 | 303 | 赞助商（企业）统一支付 Gas，用户只需签名，无需持有 Gas 代币。 304 | 305 | 例如：LayerZero 的 Omnichain 跨链 Gas 代付。 306 | 307 | 3. 游戏 & 社交应用 308 | 场景：链游玩家或社交用户不希望频繁购买 Gas 代币。 309 | 310 | 解决方案： 311 | 312 | 游戏开发商代付 Gas，玩家只需关注游戏体验。 313 | 314 | 例如：Immutable X 的 Gas-free NFT 交易。 315 | 316 | 4. 广告 & 营销激励 317 | 场景：项目方希望吸引用户完成特定任务（如注册、分享）。 318 | 319 | 解决方案： 320 | 321 | 赞助 Gas 作为奖励（如完成链上任务后返还 Gas）。 322 | 323 | 例如：QuestN 或 Galxe 的任务平台。 324 | 325 | 5. DeFi 协议优化 326 | 场景：用户因 Gas 过高不愿执行小额交易（如借贷、质押）。 327 | 328 | 解决方案： 329 | 330 | DeFi 协议补贴 Gas，鼓励用户交互（如 Aave 的 Gas 返还计划）。 331 | 332 | 例如：1inch Fusion 的 MEV 保护 + Gas 补贴。 333 | 334 | 6. 跨链 & 多链交互 335 | 场景：用户需要跨链操作但缺乏目标链 Gas。 336 | 337 | 解决方案： 338 | 339 | 跨链桥或中继器代付目标链 Gas（如 Socket、LiFi）。 340 | 341 | 例如：Connext 的跨链 Gas 代付。 342 | 343 | 344 | 345 | ### 2025.05.22 346 | 请假 347 | 348 | ### 2025.05.23 349 | 看了一下这个产品 350 | https://www.bundlebear.com/eip7702-overview/all 351 | 352 | 目前整体来说是以太坊第一，Base,Optimism,BSC 在后列 353 | ![image](https://github.com/user-attachments/assets/7e2d80da-cec0-401a-b3d6-6d0b4dd9b100) 354 | 现在应用分了三个，Bundles,Paymasters, 355 | 356 | ![image](https://github.com/user-attachments/assets/50818e50-87f8-4f66-a4cc-633d4730b0d0) 357 | 358 | 整理了一些 DAPP,后面可以研究一下 359 | ![image](https://github.com/user-attachments/assets/3f9c9c49-e58d-47a6-821b-b7b68d90fbb1) 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # EIP-7702 残酷共学 4 | 5 | ## 介绍 6 | 7 | 10 天了解 EIP-7702, 激发想法，开发潜在生态应用 8 | 9 | ## 关键词 10 | 11 | EIP-7702, EIP, ERC, Ethereum 12 | 13 | ## 面向人群 14 | 15 | - 开发者：想深入 EIP-7702 并构建应用 16 | - 产品经理：探索账户抽象的商业潜力 17 | - 研究员：了解以太坊最新技术趋势 18 | - 任何对 Web3 创新感兴趣的人 19 | 20 | ## 报名时间 21 | 22 | - 开始时间：2025-05-08 23 | - 结束时间：2025-05-13 24 | 25 | ## 共学时间 26 | 27 | - 开始时间：2025-05-14 28 | - 结束时间：2025-05-23 29 | 30 | ## 发起人 31 | 32 | - 姓名：Marcus 33 | - GitHub ID：MRzzz-cyber 34 | - Telegram：marcuszheng 35 | - Email：zqsanjingshou@gmail.com 36 | 37 | ## 发起组织 38 | 39 | - [LXDAO](https://lxdao.io/) organization-logo 40 | - [OP 中文力量](https://x.com/optimismzh) organization-logo 41 | - [ETHPanda](https://ethpanda.org/) organization-logo 42 | - [DeFiHackLabs](https://x.com/DeFiHackLabs) ![DeFiHackLabs_logo_no_bg (1)](https://github.com/user-attachments/assets/6d595f1d-6d28-42fb-8100-12b835233622) 43 | 44 | 45 | 46 | ## 请假规则 47 | 48 | 每周请假 1 次，需补卡 49 | 50 | ## 社群 51 | 52 | Telegram：https://t.me/LXDAO/24572 53 | 54 | ## 学习资料/课程安排 55 | 56 | - **技术基础** 57 | - 解读 EIP7702 提案（与EIP4337/6551对比） 58 | - 关键特性：账户抽象升级、交易批处理、Gas优化等 59 | - **应用场景分析** 60 | - 现有 钱包 /DAO/DeFi 的痛点解决方案 61 | - 任务：列举 3 个潜在用例并提交报告 62 | - **专家分享会** 63 | - 邀请专家线上答疑 64 | 65 | - **学习资料** 66 | 67 | 学习方向在于了解 7702 的基础概念，应用方向，实际案例，以及和其他 EIP 提案的结合 68 | 69 | | 阶段 | 名称 | 类型 | 链接 | 推荐理由 | 70 | | -------------- | ------------------------------------------------------- | -------- | ------------------------------------------------------------ | ------------------------------------------------------------ | 71 | | 🧩 账户抽象起点 | EIP-86: AA via TX abstraction (未采纳) | EIP 草案 | https://eips.ethereum.org/EIPS/eip-86 | 最早提出 AA 概念，探索通过新交易结构使 EOA 可配置 | 72 | | 🧩 账户抽象现状 | EIP-4337: Account Abstraction without consensus changes | EIP 草案 | https://eips.ethereum.org/EIPS/eip-4337 | 当前主流智能账户标准，无需协议层改动，Safe、Stackup 等项目实现了 | 73 | | 🧠 4337 解读 | Vitalik Medium: ERC-4337: Account Abstraction without Ethereum protocol changes | 博客 | https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a | Vitalik 详细介绍 ERC-4337 的设计理念和实现方式，强调无需对以太坊共识层进行更改即可实现账户抽象的可能性 | 74 | | 🧠 实操开发 | Stackup ERC-4337 Dev Docs | 文档 | https://docs.stackup.sh/docs | 最全面的 4337 实战文档，适合动手尝试 | 75 | | ⚙️ 协议层方向 | EIP-2938: Native AA tx type (废弃) | EIP 草案 | https://eips.ethereum.org/EIPS/eip-2938 | 提出引入原生 AA 交易类型，但未落地，可作为失败方案分析 | 76 | | ⚙️ 授权合约尝试 | EIP-3074: AUTH + AUTHCALL | EIP 草案 | https://eips.ethereum.org/EIPS/eip-3074 | 一种以 opcode 为核心的 AA 探索，最终被 7702 替代 | 77 | | ⚠️ 对比视角 | EIP-7702 与 EIP-3074 的比较分析 | 博客 | https://medium.com/buildbear/eip-3074-and-eip-7702-a-new-era-to-account-abstraction-80bf2c177cd9 | 详细比较了两者的设计理念、实现方式以及各自的优缺点 | 78 | 79 | 80 | 81 | EIP 7702 技术概念：https://docs.biconomy.io/eip7702/explained/ 82 | 83 | EIP 7702 提案：https://eips.ethereum.org/EIPS/eip-7702 84 | 85 | EIP 7702 总结：https://media.licdn.com/dms/image/v2/D4D22AQG03Xobor9mqQ/feedshare-shrink_2048_1536/B4DZaUVG9DG0Ao-/0/1746245285654?e=1749081600&v=beta&t=pmXk3YrFztt99aRZ_icekl4ENfAgiWLW0fWoc-HuCb0 86 | 87 | 什么是账户抽象：https://learnblockchain.cn/article/5946 88 | 89 | 面向应用程序的综合 EIP-7702 指南: https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/ 90 | 91 | 92 | EOA 智能合约以及应用：https://hackmd.io/@colinlyguo/SyAZWMmr1x 93 | 94 | 95 | 7702 的一些实践：https://www.youtube.com/watch?v=uZTeYfYM6fM 96 | 97 | 98 | 7702 与安全性：https://www.nethermind.io/blog/eip-7702-attack-surfaces-what-developers-should-know 99 | 100 | 101 | 7702 的未来方向：https://mirror.xyz/0x9FFC14AB8754E4De3b0C763F58564D60f935Ad6F/eiLgBj9iPFmy4s4bmjY2jvEW_7g8YxYMQaHvqm9Xw_o 102 | 103 | 104 | 深度技术思考：https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923/3 105 | 106 | 107 | ## 共学激励 108 | 109 | 打卡成功者福利：https://www.notion.so/lxdao/3eab258b4df44c9cb97319452b2be13b 110 | 111 | ## 更多信息 112 | 113 | 在 EIP-7702 残酷共学结束后，我们将开启休闲黑客松，完成 EIP-7702 残酷共学的同学都可以报名并参加 114 | 115 | ## 报名和打卡规则 116 | 117 | 因为残酷共学的报名和打卡是基于 GitHub 进行开展的，如果你是非开发者或者对 git 操作不熟悉，请先阅读此文档：[残酷共学 GitHub 新手教程](https://www.notion.so/lxdao/GitHub-bd65b981146947fea1fb675942567a45) 118 | 119 | - 报名: 120 | 121 | - Step01：Fork 本仓库。 122 | - Step02：复制 Template.md 创建你的个人笔记文件，并根据文档指引填写你的信息，并将文件重命名为你的 GitHub ID：YourGitHubID.md。 123 | - Step03：创建一个 PR 到当前仓库，本残酷共学助教会对你的 PR 进行 review，review 通过后，你的 PR 会被 merge 到 main 分支，这个时候你会收到邀请加入这个仓库 contribution 的邮件，接受邀请后，你会自动获得 main 分支的 push 权限。 124 | - Step04：完成以上三个步骤，恭喜你报名成功，后续就可以将你的学习记录直接 push 到 main 分支进行更新。 125 | - 请加入 xxx 群组保持交流：（请添加你创建的群组链接)。加入群组后请在群里报到一下方便助教记录。 126 | 127 | - 打卡： 128 | - 报名成功后，你将拥有 main 分支的 push 权限，你需要将每天学习笔记按日期更新到你的 YourName.md 文档中，提交更新后，我们会自动更新你的打卡状态到下面的打卡记录表。 129 | - 如果你不在 UTC+8 时区，需要添加时区 code 到你的 YourName.md 文件的开始，错误的时区设置可能会使自动化打卡脚本错误计算打卡时间，具体请参考：https://github.com/IntensiveCoLearning/template/blob/main/Template.md?plain=1#L1 130 | - 当你提交笔记时，请确保以下几点，否则打卡可能会失败： 131 | - 在 YourName.md 文档，请将笔记内容放到以下代码块中，且 `` 和 `` 不能删除: 132 | ``` 133 | 134 | ### 日期 135 | 笔记内容 136 | 137 | ``` 138 | - 日期格式为 `### 2024.07.11`，请不要随意更改 139 | 140 | ## 残酷共学打卡记录表 141 | 142 | ✅ = Done ⭕️ = Missed ❌ = Failed 143 | 144 | 145 | | Name | 5.14 | 5.15 | 5.16 | 5.17 | 5.18 | 5.19 | 5.20 | 5.21 | 5.22 | 5.23 | 146 | | ------------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 147 | | [jameelovecat](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/jameelovecat.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 148 | | [k66](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/k66.md) | ✅ | ⭕️ | ✅ | ⭕️ | ❌ | | | | | | 149 | | [Jack-OuCJ](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/Jack-OuCJ.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 150 | | [wayhome](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/wayhome.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 151 | | [nx-xn2002](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/nx-xn2002.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 152 | | [qiaopengjun5162](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/qiaopengjun5162.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 153 | | [MRzzz-cyber](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/MRzzz-cyber.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | 154 | | [brucexu-eth](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/brucexu-eth.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | 155 | | [jjeejj](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/jjeejj.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 156 | | [Sponge](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/Sponge.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | 157 | | [yushiwuzheng666](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/yushiwuzheng666.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 158 | | [universe-ron](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/universe-ron.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 159 | | [cxc474](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/cxc474.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 160 | | [fffuuuming](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/fffuuuming.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 161 | | [Sandybaby07](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/Sandybaby07.md) | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | 162 | | [a39955720](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/a39955720.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 163 | | [xwwkk](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/xwwkk.md) | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | 164 | | [bamboochen92518](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/bamboochen92518.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | 165 | | [keylen](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/keylen.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 166 | | [york](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/york.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 167 | | [Ellen](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/Ellen.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 168 | | [evshary](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/evshary.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | 169 | | [emailpractice](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/emailpractice.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 170 | | [wiasliaw](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/wiasliaw.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | 171 | | [BillyC](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/BillyC.md) | ⭕️ | ⭕️ | ✅ | ✅ | ❌ | | | | | | 172 | | [tofudfy](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/tofudfy.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 173 | | [gpteth](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/gpteth.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | 174 | | [bobs-1](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/bobs-1.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 175 | | [gardennn](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/gardennn.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 176 | | [narnona](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/narnona.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 177 | | [nghdavid](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/nghdavid.md) | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | 178 | | [easyshellworld](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/easyshellworld.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | 179 | | [alichaw](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/alichaw.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | 180 | | [ygy-1231](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/ygy-1231.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 181 | | [luleigreat](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/luleigreat.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 182 | | [blahole](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/blahole.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | 183 | | [wodeche](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/wodeche.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | 184 | | [helloworldsmart](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/helloworldsmart.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | 185 | | [alexliao](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/alexliao.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | 186 | | [chesley666](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/chesley666.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | 187 | | [kevinsslin](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/kevinsslin.md) | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | 188 | | [zion](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/zion.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 189 | | [kris77z](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/kris77z.md) | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 347 | ## 统计数据 348 | 349 | - 总参与人数: 43 350 | - 完成人数: 18 351 | - 完成用户: Jack-OuCJ, wayhome, nx-xn2002, qiaopengjun5162, MRzzz-cyber, universe-ron, cxc474, fffuuuming, a39955720, york, emailpractice, wiasliaw, gardennn, nghdavid, luleigreat, alexliao, chesley666, zion 352 | - 全勤用户: Jack-OuCJ, wayhome, qiaopengjun5162, universe-ron, cxc474, fffuuuming, a39955720, york, emailpractice, gardennn, luleigreat, zion 353 | - 淘汰人数: 25 354 | - 淘汰率: 58.14% 355 | - Fork人数: 43 356 | 357 | -------------------------------------------------------------------------------- /Sandybaby07.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍 Hihi 我是Sandy 11 | 2. 你认为你会完成本次残酷学习吗？ 應該會：） 12 | 3. Telegram :sandyyy0707 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | #### DESIGNATING A SMART CONTRACT TO AN EOA 21 | role: EOA/Sequencer/Node 22 | 23 | image 24 | 25 | ```odyssey_sendTransaction``` 26 | 27 | odyssey_sendTransaction request that executes an EIP-7702 Transaction to designate a contract to the EOA (via authorizationList), as well as executing a function on it (via data): 28 | 29 | ``` 30 | curl 'https://odyssey.ithaca.xyz/' --data '{ 31 | "jsonrpc":"2.0", 32 | "id":0, 33 | "method":"odyssey_sendTransaction", 34 | "params":[{ 35 | "authorizationList":[{ 36 | "address":"0x35202a6E6317F3CC3a177EeEE562D3BcDA4a6FcC", 37 | "chainId":"0xde9fb", 38 | "nonce":"0x0", 39 | "r":"0xc9e930f2051c331b994ca1ec5d398379923dc1aae3b1aaaccf4242e872b8ce79", 40 | "s":"0x182672f89807a836962b0f29ce566f30b1588bd8b6bd4f9a8e24b3675ed11c3e", 41 | "yParity":"0x0" 42 | }], 43 | "data":"0xdeadbeef00000000000000000000000000000000000000000000000000000000cafebabe", 44 | "to":"0xFC7b76a8cA893f00976a14559D08b77aa4e4Bf2e" 45 | }] 46 | }' 47 | ``` 48 | #### EXECUTING A CALL TO A DELEGATED EOA 49 | image 50 | 51 | odyssey_sendTransaction request that executes an EIP-1559 Transaction to execute a function on a delegated EOA (via data): 52 | ``` 53 | curl 'https://odyssey.ithaca.xyz/' --data '{ 54 | "jsonrpc":"2.0", 55 | "id":0, 56 | "method":"odyssey_sendTransaction", 57 | "params":[{ 58 | "data":"0xdeadbeef00000000000000000000000000000000000000000000000000000000cafebabe", 59 | "to":"0xFC7b76a8cA893f00976a14559D08b77aa4e4Bf2e" 60 | }] 61 | }' 62 | ``` 63 | #### SEQUENCER 64 | Sequencer 應僅處理符合以下條件的交易： 65 | 66 | - 為 EIP-7702 類型，且將智慧合約指定給一個 EOA（外部擁有帳戶），或為 EIP-1559 類型且指定至 EOA； 67 | 68 | - 不超過 Sequencer 定義的每筆交易 gas 上限 69 | 70 | - 不包含 value 欄位（或其值設為 0） 71 | 72 | - 不包含 nonce 欄位（由 Sequencer 管理） 73 | 74 | - 不包含 from 欄位（由 Sequencer 管理） 75 | 76 | ### 2025.05.15 77 | #### Nonce 增加機制 78 | EIP-7702 提出一套全新的機制，每次成功授權後就會增加 EOA（外部持有帳戶）的 nonce 值。處理 nonce 的流程是： 79 | 80 | 首先，檢查交易的 nonce 是否跟帳戶目前的 nonce 相符，然後把交易 nonce 加一 81 | 接著檢查每個授權清單中的 nonce 確認用的是正確的數值，成功授權後相對應的授權 nonce 也會加一 82 | 83 | 這代表如果一筆交易包含授權清單，而且授權簽署者跟交易簽署者是同一人，你就必須把： 84 | 85 | tx.nonce 設定為 account.nonce 86 | authorization.nonce 設定為 account.nonce + 1 87 | 88 | 若一筆交易包含多個由同一個 EOA 簽署的授權（雖然實際上很少見啦），每個授權的 nonce 必須按順序一個一個加上去。總之，這個機制需要 SDK 正確處理 nonce 值。 89 | 90 | #### 授權清單規範與委託機制 91 | EIP-7702 要求 authorization_list 不能是空的，確保每筆 EIP-7702 交易都明確表達要授權某個實作地址的意圖。協議還會檢查每個 authorization_list 元組的參數，包括： 92 | 93 | address 長度 94 | chain_id、nonce、y_parity、r 和 s 的合理範圍 95 | 96 | 在 authorization_list 的每個元組中： 97 | 98 | address 欄位是被授權的地址 99 | 簽署者的地址則是從簽名和資料中算出來的 100 | 101 | ps1: 贊助交易：這種設計讓 EIP-7702 能把支付 Gas 費的責任從被授權的 EOA 轉移出去，實現了大家常說的「贊助交易」功能 102 | 103 | ps2:Layer 2 整合： 104 | Layer 2 的Sequencer可以直接整合 EIP-7702 錢包建立介面 105 | 也可以加入 API 來收集使用者授權並用 authorization_list 批次提交 106 | 107 | ps3:錢包服務提供商的應用：錢包服務商可以幫沒幣的使用者送出交易！ 108 | 109 | ### 2025.05.17 110 | 111 | #### 錢包服務 112 | User 在使用錢包服務時最大的進入障礙往往是註記詞、私鑰的問題，在passkey普及的狀況下，所有需要密碼登入的服務都紛紛採用無密碼登入的方式，作為開發者也很期待把這格功能在web3錢包上實現，但是在7702還沒出來之前，使用4337搭配Passkey的實作仍不盡理想，沒有經驗的使用者使用的合約還是會受第三方制約，不夠去中心化，而EOA上搭載合約德發生，大大提升了可用性，使用者可以完全自託管錢包，同樣可以在無密碼的場景下使用合約錢包，另外gas station 的服務不在指定原生幣作為燃料，降低初學者的使用門檻，也讓服務保有很大的彈性。 113 | 114 | ### 2025.05.19 115 | 116 | ㆍEIP-7702: Set EOA account code 117 | User signs over [ChainID, Contract_Wannabe, Nonce] with his 118 | private key and gets transformed into the Contract_Wannabe,可以自己發送安裝合約的交易或是由服務幫忙 119 | 120 | ChainID=0 means transformation is applicable to any chain 121 | but Nonce has to match,當設定Chain id =0時表示EOA在任何鏈都可以變成SCA,但是要注意在各個鏈上的nonce一樣要照順序,要注意 122 | 123 | ㆍContract_Wannabe=0 means transforming back to EOA 124 | 125 | 即便變成SCA還是能做原本的EOA的流程 126 | 127 | 安全程度與原本的EOA是相通的,仍然好好保管私鑰 128 | 129 | Storage不會被清空,更換合約時要注意,即便變回EOA也是一樣 130 | 131 | 沒有初始化的動作,沒有搶跑問題,,在變成合約錢包之前要檢查EOA signature 132 | 133 | ### 2025.05.20 134 | msg.sender 的安全假設檢查在7702的架構下假設交易發起 tx.origin為EOA不再可行 135 | 136 | msg.sender==tx.origin 來判斷重入攻擊也會失效,開發者必須假設所有的參與者有可能是合約 137 | 138 | 需要注意是否實作ERC721或ERC777等token 需要的hook functions ,確保user可以與主流的協議兼容 139 | 140 | 141 | 142 | 143 | -------------------------------------------------------------------------------- /Sponge.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | # Sponge 5 | 6 | 1. 自我介绍 藍頭寶寶，希望自己按時學習 7 | 2. 你认为你会完成本次残酷学习吗？ 會的 8 | 3. 你的联系方式（推荐 Telegram）@sponge_242 9 | 10 | ## Notes 11 | 12 | 13 | 14 | ### 2025.05.14 15 | 16 | [Day1](https://github.com/SpC242/EIP-7702-CoLearning/blob/main/Day1.md) 17 | 18 | ### 2025.05.15 19 | I forgot to update Day2. 20 | 21 | ### 2025.05.16 22 | [Day3](https://github.com/SpC242/EIP-7702-CoLearning/blob/main/Day3.md) 23 | 24 | ### 2025.05.17 25 | [Day4](https://github.com/SpC242/EIP-7702-CoLearning/blob/main/Day4.md) 26 | 27 | ### 2025.05.18 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /a39955720.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # Denny 9 | 10 | 1. 自我介绍 大家好，我目前專注於 Solidity 智能合約的開發與審計，希望可以透過這次活動學習到更多相關知識。目前也正在尋找相關職缺，如果有相關機會，歡迎推薦給我！ 11 | 2. 你认为你会完成本次残酷学习吗？ 一定可以 12 | 3. 你的联系方式（推荐 Telegram）Telegram:@a39955720 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | ## EIP-7702 是什麼？ 21 | 22 | EIP-7702 是一個新的提案，目的是讓傳統的 EOA 可以持久升級成像合約帳戶一樣，具備更多功能，比如一次完成多步操作、讓別人幫你付 gas，或是限制某個 key 只能做特定操作。 23 | 24 | 這是透過一種新的交易格式來做到的（type 0x04），交易裡會附帶一個「授權清單」，告訴鏈上：「這些帳戶現在起 delegate 給特定合約的 code，直到我再指定新的 code 或清空為止。」 25 | 26 | --- 27 | 28 | ## 跟 EIP-4337 和 EIP-6551 有什麼不同？ 29 | 30 | | 功能 | EIP-7702 | EIP-4337 | EIP-6551 | 31 | | ---- | ---------------- | ------------------- | ------------- | 32 | | 對象 | 普通錢包 (EOA) | 完整合約錢包系統 | NFT 擴展錢包 | 33 | | 特色 | 輕量、即插即用、不需額外基礎設施 | 架構完整，可完全替代 EOA | 讓 NFT 擁有自己的錢包 | 34 | | 複雜度 | 低 | 高，需要 EntryPoint 等配合 | 中 | 35 | | 適合場景 | 想快速提升 EOA 體驗 | 長期帳戶抽象路線 | Web3 遊戲、身份系統等 | 36 | 37 | --- 38 | 39 | ## 核心功能介紹 40 | 41 | ### 1. Batching（多步操作一次完成） 42 | 43 | 像是先 approve、再 transfer，不用兩筆交易，EIP-7702 讓這變成一筆就能搞定。 44 | 45 | ### 2. Sponsorship（讓別人幫你出 gas） 46 | 47 | 你簽好交易內容後，可以請第三方幫你發送並支付 gas，他們甚至能用穩定幣或其他 token 向你收費。 48 | 49 | ### 3. Sub-permissions（權限分級） 50 | 51 | 你可以發出一把「權限受限」的子鑰匙，例如只能花 ERC20 但不能動 ETH，或設定一天最多只能花 1% 資產。 52 | 53 | --- 54 | 55 | ## 它怎麼運作？ 56 | 57 | * 當你發送 type 0x04 的交易時，你可以在裡面加一個授權清單。 58 | * 每個授權項目會將指定帳戶的 code 設成特殊的「委派指標」，告訴 EVM：「這個帳戶的邏輯現在委派給另一個合約。」 59 | * 執行像 CALL、DELEGATECALL 等指令時，會自動到被委派的合約中抓 code 來執行。 60 | 61 | --- 62 | 63 | ## 特別設計小細節 64 | 65 | * **Code 不用自己寫**：只要給一個已部署合約的 address 就行，省空間、省 gas。 66 | * **一次授權、多次使用**：7702 的授權設置是持久性的，不像 4337 要每次都包進 EntryPoint，7702 設完之後可以一直用。 67 | * **可以自己贊助自己**：EOA 自己就能發這種交易，不需要別人幫你 relayer。 68 | 69 | --- 70 | 71 | ## Gas 成本 72 | 73 | * 基礎成本與 EIP-2930 相似，再加上每個授權 tuple 先一次性收取最高可能成本 25000 gas。 74 | * 如果授權帳戶原本非空，則會在執行中退回部分 gas，實際成本為 12500 gas；空帳戶則無退還，成本為完整 25000 gas。 75 | 76 | --- 77 | 78 | ## 安全提醒 79 | 80 | * 被授權的 delegate contract 要小心撰寫，應具備 nonce、限額、目標合約白名單等 replay protection 機制，避免簽名被重放攻擊。 81 | * 開發者應避免用 `require(tx.origin == msg.sender)` 這種方式做安全檢查，因為這提案可能會破壞這個邏輯。 82 | * 若要變更授權合約，必須注意 storage collision 風險，建議使用 ERC-7201 標準管理 storage，或清空 storage 後再進行授權更換。 83 | 84 | --- 85 | 86 | ### 2025.05.15 87 | 88 | 昨天把 EIP-7702 的官方文檔讀過一遍，雖然大致理解設計理念，但還是有一些地方不是很清楚，所以決定自己整理一份自問自答。 89 | 90 | --- 91 | 92 | **Q:** 為什麼要在授權清單裡加上 chain\_id？ 93 | 94 | **A:** 95 | 主要是為了**防止跨鏈重放攻擊**。chain\_id 就像是「這份授權只給這一條鏈用」，確保你在主網簽的授權，別人不能拿去測試網或其他鏈重放。要全鏈通用的話，chain\_id 可以設成 0。 96 | 97 | --- 98 | 99 | **Q:** EIP-7702 的 y\_parity 到底是什麼？以前不是都用 v 嗎？ 100 | 101 | **A:** 102 | `y_parity` 就是以前簽名裡那個 `v` 的「奇偶位」，本質上就是 `v` 去掉鏈 ID 之後剩下的那 1 bit。 103 | 0 代表偶數、1 代表奇數。新標準直接用 0 或 1，少了 27/28 或鏈 ID 這些混淆，比較直覺好用！ 104 | 105 | --- 106 | 107 | **Q:** 我想把一個普通錢包變成 7702 代理模式，流程大致怎麼走？ 108 | 109 | **A:** 110 | 111 | 1. 先準備好你要委派的合約 address。 112 | 2. 構造一個 type 0x04 的交易，填好授權清單。 113 | 3. 交易發上鏈，鏈上會把你的 EOA code 設定成「委派指標」，所有對你這個 EOA 的 CALL 都會去執行指定合約的邏輯。 114 | 4. 要恢復成純 EOA，只要再發一次授權為 0x0 的交易即可。 115 | 116 | --- 117 | 118 | **Q:** 如果我委派到一個也在委派別人的合約，EVM 會怎麼辦？會不會死循環？ 119 | 120 | **A:** 121 | EIP-7702 明確規定**只會追蹤第一層委派**，不會繼續往下找，這樣就不會出現委派 loop 或無限遞迴的 bug。 122 | 所以如果你指到另一個有 delegation indicator 的帳戶，EVM 只會拿第一個委派的 address 來執行，不會跳第二、三層。 123 | 124 | --- 125 | 126 | ### 2025.05.16 127 | 128 | 今天我做了一個利用 EIP-7702 來進行一筆同時 approve 和 transfer 的簡單 demo 129 | 130 | GitHub Repository: [eip7702-demo](https://github.com/a39955720/eip7702-demo) 131 | 132 | --- 133 | 134 | ### 2025.05.17 135 | 136 | ## EIP-7702 可能的應用場景 137 | 138 | ### 1. 一次性多步驟操作（Batch Transactions） 139 | 140 | * **說明**：傳統 EOA 用戶如果想在去中心化交易所（DEX）進行操作，往往需要先單獨批准（approve）代幣，再另外發送兌換（swap）等多筆交易，既耗時又費 gas。EIP-7702 允許用戶臨時將帳戶變成智慧合約，在一筆交易內自動完成「批准 + 兌換」、「跨多協議的資產搬移」等多步驟操作。 141 | * **範例**：用戶只需一次簽名，就能將手上的 USDC 兌換成 ETH，並直接轉帳給另一個帳戶，省去重複簽名和多筆礦工費。 142 | * **潛在影響**：大幅提升 DeFi 使用體驗，減少出錯風險，讓複雜操作更容易被主流用戶接受。 143 | 144 | --- 145 | 146 | ### 2. Gas 贊助（Gas Abstraction） 147 | 148 | * **說明**：新用戶往往卡在「沒有 ETH 無法發送第一筆交易」這道門檻。EIP-7702 可讓 Dapp 或第三方臨時插入「由他人代付 Gas」的合約邏輯，用戶在不持有 ETH 的情況下也能順利上鏈互動。 149 | * **範例**：遊戲、NFT 首次鑄造、空投活動等場合，用戶在網站操作時，Dapp 自動替用戶支付 Gas 費，讓 onboarding 流程更加順暢。 150 | * **潛在影響**：降低 Web3 入口門檻，有助於用戶大規模成長。 151 | 152 | --- 153 | 154 | ### 3. 社交恢復（Social Recovery） 155 | 156 | * **說明**：私鑰遺失是鏈上資產最大的風險。EIP-7702 支持臨時加載社交恢復邏輯（如多數好友簽名、家族成員共識），僅在恢復時需要，多數時間仍為一般帳戶。 157 | * **範例**：用戶遺失私鑰時，只要指定的三位好友同時同意，就能臨時加載恢復邏輯，協助重設帳戶存取權。 158 | * **潛在影響**：讓以太坊帳戶兼具自主管理與可靠的救援機制，降低資產永久丟失機率。 159 | 160 | --- 161 | 162 | ### 4. 交易權限控制（Transaction Policy） 163 | 164 | * **說明**：EIP-7702 支持臨時加入各種資產管控邏輯，例如白名單、黑名單、多重簽章、多重驗證等，靈活限制帳戶資金流動或提現行為。 165 | * **範例**：公司帳戶可設定大額轉帳需多位管理員同意，或者臨時限制對某些地址的付款，防止內部濫用或外部詐騙。 166 | * **潛在影響**：提升機構、家庭、DAO 等多種場景的安全與資產管控彈性。 167 | 168 | --- 169 | 170 | ### 5. 隱私交易與混幣（Privacy/Mixing） 171 | 172 | * **說明**：EIP-7702 可臨時加載隱私協議邏輯，執行如 zk-SNARK、混幣、跳板合約等操作，強化資金隱私。 173 | * **範例**：臨時將資金經由混幣協議轉到新地址，或一次性使用零知識證明隱藏交易路徑。 174 | * **潛在影響**：滿足高端用戶與機構對隱私的需求，同時避免永久性複雜設定。 175 | 176 | --- 177 | 178 | ### 6. 自定義簽章驗證（Custom Signature Validation） 179 | 180 | * **說明**：EIP-7702 可讓帳戶臨時切換到多因素認證（2FA）、生物識別驗證、硬體錢包驗證等進階簽章邏輯，針對大額或高風險操作加強安全。 181 | * **範例**：用戶進行高額轉帳時，錢包自動要求手機 App 二次驗證或生物辨識，普通日常操作則無需額外手續。 182 | * **潛在影響**：大幅提升大戶、機構或重視安全用戶的資產保障層級。 183 | 184 | --- 185 | 186 | ### 2025.05.18 187 | 188 | ![image](https://github.com/user-attachments/assets/2e388bef-f65b-473e-b8e1-733c7ef074b2) 189 | 190 | 191 | ## EIP-7702 流程與原理圖解筆記 192 | 193 | ### 1. 帳戶創建與簽名 194 | 195 | * 用戶用錢包 App 創建帳戶（EOA），拿到 `address` 和 `private key`。 196 | * 透過私鑰簽名，構造一筆 type-4（Set code transaction）交易。 197 | 198 | ### 2. 授權清單（authorization list） 199 | 200 | * 交易裡包含一個授權清單，指定： 201 | 202 | * `chain_ID`：僅適用於特定鏈 203 | * `address`：要代理的合約地址（填 0x0 代表清除委派） 204 | * `nonce`：防止重放 205 | * `signature`：對這些資料的簽名 206 | 207 | ### 3. 交易提交與上鏈 208 | 209 | * 用戶可選擇自己或交給第三方贊助者（someone with gas）送出交易。 210 | * 交易被送進節點（node）並正式寫進鏈上。 211 | 212 | ### 4. 帳戶狀態變化 213 | 214 | * 一般 EOA 的 address 沒有 code。 215 | * type-4 交易執行後，該 address 的 code 會變成 `0xef100
`（特殊前綴 + 被代理合約地址）。 216 | * 這表示之後所有對這個 address 的 call，實際都會代理執行指定的合約 code。 217 | 218 | ### 5. 代理行為與影響 219 | 220 | * 只要被設為代理，這個 EOA 就像 smart contract wallet 一樣，能跑多步操作、批次執行。 221 | * 呼叫如 CALL、DELEGATECALL、STATICCALL 都會進到代理合約邏輯。 222 | * 但像 EXTCODESIZE 這種讀 code 長度的操作，只會看到前綴本身。 223 | 224 | ### 6. 安全與升級注意 225 | 226 | * 被代理的 code 誰能控制？能否升級？有安全審查嗎？ 227 | * 用戶如果要更換委派合約，只需再發一次 type-4 交易，address 設為 0x0 就能清除。 228 | * 用戶需了解委派合約功能及風險，避免授權給惡意合約。 229 | 230 | #### 來源 231 | 232 | [https://www.youtube.com/watch?v=ZFN2bYt9gNE](https://www.youtube.com/watch?v=ZFN2bYt9gNE) 233 | 234 | --- 235 | 236 | ### 2025.05.19 237 | 238 | ## ERC-4337（帳戶抽象）重點筆記 239 | 240 | 最近剛看完 EIP-7702，今天換來複習一下帳戶抽象（ERC-4337）。這個提案其實是目前智能合約錢包的主流實現，整理一些關鍵內容跟自己做個對比筆記： 241 | 242 | ### 什麼是帳戶抽象（ERC-4337）？ 243 | 244 | 帳戶抽象讓用戶直接用「智能合約錢包」作為主帳戶，帳戶驗證、權限和 Gas 支付邏輯都能自訂，不再受限於傳統 EOA。 245 | **無需更改主網協議，已在以太坊主網運作。** 246 | 247 | --- 248 | 249 | ### 核心流程與組件 250 | 251 | 1. **UserOperation**： 252 | 用戶構造一個特殊的「操作請求」（可多步操作），發送到 ERC-4337 專屬 mempool。 253 | 254 | 2. **Bundler**： 255 | 節點監控 UserOperation，將多個操作打包成一筆交易，提交到 EntryPoint 合約。 256 | 257 | 3. **EntryPoint 合約**： 258 | 驗證並執行所有 UserOperation，處理交易與費用。 259 | 260 | 4. **Paymaster**： 261 | 合約可為用戶贊助 Gas，也可用 ERC20 代幣付費，降低新手上手門檻。 262 | 263 | 5. **Aggregator**： 264 | 多重簽名聚合驗證，降低 callData 成本。 265 | 266 | --- 267 | 268 | ### 和傳統 EOA 差異 269 | 270 | | 特性 | ERC-4337 合約帳戶 | 傳統 EOA | 271 | | ------ | ------------- | --------- | 272 | | 驗證方式 | 可自訂（多簽、2FA等） | 單純私鑰簽名 | 273 | | Gas 支付 | 可由第三方或代幣支付 | 必須自己付 ETH | 274 | | 批次操作 | 一筆 UserOp 可多步 | 一次只能一個操作 | 275 | | 發送方式 | Bundler 打包後上鏈 | 直接廣播到鏈上 | 276 | 277 | --- 278 | 279 | ### 實際應用 280 | 281 | * 批次交易（比如一鍵 approve + swap） 282 | * 免 ETH onboarding（Dapp 幫你付 Gas） 283 | * 社交恢復、多簽、多重驗證安全加強 284 | * 支援 USDC、USDT 等多種代幣支付手續費 285 | 286 | --- 287 | 288 | ### 與 EIP-7702 的最大區別 289 | 290 | | | ERC-4337 | EIP-7702 | 291 | | ---- | -------------------- | ---------------- | 292 | | 目標 | 直接推廣合約錢包 | 讓 EOA 具備代理/批次能力 | 293 | | 運作方式 | 需 Bundler、EntryPoint | 原生鏈上支援 type-4 交易 | 294 | | 用戶體驗 | 彈性最高 | 過渡型方案、兼容 EOA 環境 | 295 | 296 | **參考連結**： 297 | 298 | * [Alchemy 原文](https://www.alchemy.com/overviews/what-is-account-abstraction) 299 | * [LearnBlockChain 中文](https://learnblockchain.cn/article/5946) 300 | 301 | --- 302 | 303 | ### 2025.05.20 304 | 305 | ## EIP-7702 的現實挑戰與新標準協作 306 | 307 | ### 1. 為什麼用戶不愛換智能帳戶？ 308 | 309 | * 換帳戶要部署新合約、搬資產、學新介面、要有 ETH 付部署費，流程繁瑣。 310 | * 地址一換，交易紀錄、NFT、POAP 都割裂，身份分散、連到 Dapp 的授權要重來。 311 | * EOA 私鑰在各錢包通用，智能帳戶實作各異，跨錢包與跨鏈遷移困難。 312 | 313 | --- 314 | 315 | ### 2. 生態碎片化與錢包主導 316 | 317 | * 各家錢包可自訂 EIP-7702 實作（不同合約、授權機制），未來生態會更碎片化。 318 | * **應用（Dapp）不能直接設定 EIP-7702 授權**，必須透過錢包，由用戶選擇是否升級。 319 | * 嵌入式錢包（如 Privy, Magic 等）可自訂授權方案，但也多半有預設合約實作。 320 | 321 | --- 322 | 323 | ### 3. 開發者要面對的新挑戰 324 | 325 | * 未來不只 EIP-7702，還會有 ERC-7710/7715/5792 等新標準並存，要因應多種錢包支援方式。 326 | * **Companion Account（伴生帳戶）**：每個 Dapp 可部署專屬智能帳戶幫用戶處理批量、限權、資產管理等高階操作，彈性最大。 327 | * 工具如 Biconomy AbstractJS 可協助開發者處理多標準、錢包支援偵測與批次交易封裝，降低碎片化複雜度。 328 | 329 | --- 330 | 331 | ### 4. 新標準重點說明 332 | 333 | #### ERC-7710 334 | 335 | * 標準化智能合約之間的授權接口，讓帳戶能指定其他合約（如伴生帳戶）獲得特定操作權限，超越僅限 ERC20 的 approve 概念。 336 | 337 | #### ERC-7715 338 | 339 | * 增加 `wallet_grantPermissions` 方法，應用可請求錢包開放操作權限，由用戶確認授權，提升互動性與細緻權限管理。 340 | 341 | #### ERC-5792 342 | 343 | * 提供 `wallet_sendCalls` API，允許應用一次發送多筆合約呼叫，由錢包整合成單次簽名，簡化用戶一鍵多步操作（如批量 NFT 發送、approve+swap）。 344 | 345 | --- 346 | 347 | ### 5. 總結 348 | 349 | * **EIP-7702 提供 EOA 智能升級方案，降低用戶換帳戶門檻，但功能主導權在錢包商。** 350 | * **開發者需適應多標準、碎片化、伴生帳戶設計，並運用新標準 ERC-7710/7715/5792 進行高級功能協作。** 351 | * 未來區塊鏈用戶體驗將更友好，但錢包生態會有一段陣痛與標準並存的適應期。 352 | 353 | **參考連結**： 354 | 355 | * [A Comprehensive EIP-7702 Guide for Apps](https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/) 356 | 357 | --- 358 | 359 | ### 2025.05.21 360 | 361 | ## EIP-7702 深度拆解（進階細節與開發實踐） 362 | 363 | ### 1. 協議新結構與流程 364 | 365 | * **SET\_CODE\_TX\_TYPE (0x04)**：新增的交易型別，允許 EOA 直接指定 implementation address 作為“智能 EOA”執行合約邏輯。 366 | * **authorization\_list**：每筆 EIP-7702 交易必帶，明確指定授權給哪個合約地址（可單筆或批量處理），可支援第三方代送交易與贊助 gas。 367 | * **簽名結構**：簽名 domain 以 magic number(0x05) 區隔類型，能提升安全性與跨鏈複用能力（若 nonce 一致）。 368 | * **nonce 雙層驗證與自動遞增**：tx.nonce 與授權內 nonce 分開處理，支援一筆交易多個授權批次，每個授權都能安全同步帳號狀態。 369 | 370 | --- 371 | 372 | ### 2. 重要協議設計亮點 373 | 374 | * **授權可由第三方批量提交**：如 L2 Sequencer、錢包伺服器可幫用戶提交多個授權（sponsored transaction）。 375 | * **多條鏈跨鏈授權**：可設 chain\_id 為 0 跨鏈複用（但受限於 EOA nonce 必須同步，實務上具挑戰）。 376 | * **授權撤銷（revocation）**：設 address = 0x0 可清空代理、重設為純 EOA，支援簡單反覆切換。 377 | * **重複授權與 re-delegation**：需管理 storage layout 衝突（建議用 ERC-7201/7779 進行 storage 隔離與安全遷移）。 378 | 379 | --- 380 | 381 | ### 3. EVM 運作細節調整 382 | 383 | * **opcode 代理邏輯**：CALL、DELEGATECALL、STATICCALL 會去執行指定 implementation 的 code（由 EOA 地址指向的合約地址載入 code）。 384 | * **禁止遞迴代理**：協議只允許一層代理，不支援鏈式委派，簡化驗證流程與防止迴圈 bug。 385 | * **特殊 code 編碼**：智能 EOA 的 code 以 0xef0100 + address 開頭，確保與合約空間不衝突（利用 EIP-3541, 3540 格式區隔）。 386 | * **nonce 增減新邏輯**：每次 SET\_CODE 交易和每個授權操作都會自動增減帳號 nonce，SDK 需同步處理。 387 | 388 | --- 389 | 390 | ### 4. 實作與錢包開發要點 391 | 392 | * **新錢包設計流程**： 393 | 394 | 1. 生成 EOA（或接入現有私鑰）。 395 | 2. 用 EOA 簽署授權資訊（指向合約地址）。 396 | 3. 可在一筆交易內同時代理新合約與設定多組 session/sub-keys，降低用戶多次簽名麻煩。 397 | 4. 支援第三方提交（不一定要本人發送交易）。 398 | * **多簽/多算法支援**：如 WebAuthn、P256/BLS key，兼容不同簽名演算法與 session key 應用。 399 | * **狀態查詢與同步**：要查詢智能 EOA 當前狀態，可用 eth\_getCode 查 code、ParseDelegation 工具判斷現況。 400 | 401 | --- 402 | 403 | ### 5. 應用與安全性新範例 404 | 405 | * **實現 stealth address**：基於 EOA 轉型流程更簡單，易於做私密/隱身資產管理。 406 | * **批次操作/批量授權**：合約支援 batch call（如 multiSend），一次處理多步指令，減少 gas 成本與簽名負擔。 407 | * **WebAuthn/zke-mail 結合**：可設定 email、手機、第三方服務商多簽或 zk 驗證，達到更彈性的 social recovery。 408 | * **用戶資產私隱維護**：可多地址分流，驗證時用 zk proof 證明持有或參與但不暴露全部歷史。 409 | 410 | --- 411 | 412 | ### 6. 協議兼容與未來路線 413 | 414 | * **ERC-4337/7702 組合應用**：EIP-7702 可直接指定 ERC-4337 智能帳戶為 implementation，無縫融入現有生態。 415 | * **L2 原生帳戶抽象（AA）**：未來 RIP-7560、EIP-7701 等都會影響帳戶抽象底層邏輯，EIP-7702 則可作為過渡/橋接方案，幫現有 EOA 使用者平滑升級、支援新接口。 416 | * **新型 session key 與訂閱**：可針對不同 Dapp、支付型業務設專用 session key，提升安全與用戶便利性。 417 | 418 | --- 419 | 420 | ### 7. 額外細節 421 | 422 | * **交易池與 nonce 行為需全面調整**：因 EOA 可被代理/批量授權，過去 pending tx 失效邏輯需全新設計。 423 | * **DoS 防禦機制**：批次授權時，某個授權失敗不影響其他授權繼續執行，提高系統穩健度。 424 | 425 | **參考連結**： 426 | 427 | * [EIP-7702: A Deep Dive into Smart EOAs with Implementation Examples](https://hackmd.io/@colinlyguo/SyAZWMmr1x) 428 | 429 | --- 430 | 431 | ### 2025.05.22 432 | 433 | ## EIP-7702 Security Risks Developers Shouldn’t Ignore 434 | 435 | ### 1. 新的安全威脅來源 436 | 437 | * **EOA 代理合約不等於智能帳戶**：EIP-7702 讓 EOA 指向代理合約，但本質上 EOA 的私鑰永遠有最高權限，私鑰一旦外洩一切防線失效。 438 | * **同一代理合約可被多個 EOA 共用**，合約資料隔離與權限管理需特別小心。 439 | 440 | --- 441 | 442 | ### 2. 開發/部署常見安全漏洞 443 | 444 | #### （1）存取控制漏洞 445 | 446 | * 若代理（delegate）合約**沒有適當權限控制**，任何人都可發送交易、操作資產。 447 | * 實例：合約函數無任何 `onlyOwner` 或 `msg.sender` 限制，導致任意地址可發起敏感操作（如轉帳、批次執行 call）。 448 | 449 | #### （2）初始化/建構子陷阱 450 | 451 | * 指定代理合約時**不會執行 constructor**，所有初始邏輯無法自動設定。 452 | * 若需初始設值，**必須有獨立的 initialize 函數，且需和代理設置同時完成**，否則易遭前置攻擊（frontrun）。 453 | 454 | #### （3）初始化重入與前置攻擊 455 | 456 | * 如果初始化和代理操作分開執行，攻擊者可預先呼叫 initialize 奪取控制權。 457 | * **建議：一律同筆交易設置代理與初始化，並嚴格檢查 initialize 只能執行一次。** 458 | 459 | #### （4）儲存碰撞（Storage Collision） 460 | 461 | * 代理合約升級或切換時，原有 storage 不會被清空。 462 | * 不同版本的代理合約若資料結構不同，**存取型別錯誤**將導致邏輯異常或安全漏洞（如 bool 變 uint）。 463 | * **必須確保升級前後 storage layout 兼容，或設計清除/遷移機制。** 464 | 465 | --- 466 | 467 | ### 3. 開發者易忽略的行為與新攻擊面 468 | 469 | * **可隨時還原為純 EOA**：只需設代理地址為 0，即清除所有合約邏輯，帳戶恢復為一般 EOA。 470 | * **可多次重複設置/更換代理**：每次更換都要審查新代理合約安全性，防止“舊資料污染”或不安全初始化。 471 | * **不同 EOA 共用同代理合約時**，要考慮跨帳戶資料分離、不可互相覆蓋。 472 | 473 | --- 474 | 475 | ### 4. 與 EIP-4337 的安全模型對比 476 | 477 | * EIP-4337 依賴 EntryPoint 與 off-chain Bundler，有額外多重驗證與過濾層。 478 | * **EIP-7702 為直接協議級代理，若代理合約有安全漏洞，所有指向它的 EOA 都暴露於風險之下。** 479 | * 實務部署時，開發者需意識到兩者安全責任分界完全不同。 480 | 481 | --- 482 | 483 | ### 5. 實務建議 484 | 485 | * **嚴格設計 access control（如 onlyOwner、whitelist）**，只允許 EOA 本人/授權地址操作敏感功能。 486 | * **initialize/upgrade 函數必須有唯一性與防重入設計**，避免初始化被惡意提前佔用。 487 | * **部署/切換代理時強制審查 storage 兼容性**，避免歷史數據造成資料解釋錯誤。 488 | * **全面合約審計，勿輕信開發“直覺安全”**，要有專業安全審查流程。 489 | 490 | **參考連結**： 491 | 492 | * [EIP-7702 Security Risks Developers Shouldn’t Ignore](https://www.nethermind.io/blog/eip-7702-attack-surfaces-what-developers-should-know) 493 | 494 | --- 495 | 496 | ### 2025.05.23 497 | 498 | ## 學習 EIP-7702 心得分享 499 | 500 | 最近把 EIP-7702 研究了一遍，覺得真的很酷！原本以為帳戶升級成智能合約帳戶一定很複雜，結果 7702 其實讓 EOA 也能有一堆新功能，像是多步操作、社交恢復、甚至別人幫你出 gas。對新手或不想換地址的老用戶超友善。 501 | 502 | 但學到越多也發現很多坑。像代理合約沒設好權限，別人就能亂動你的資產；初始化沒處理好還有可能被搶先控制，甚至升級時 storage 撞到也很麻煩。感覺未來要做相關合約，安全真的是第一優先，光靠直覺寫肯定不行。 503 | 504 | 感覺 EIP-7702 很有潛力，對想做用戶體驗更好的 Dapp 或錢包超有幫助，但真的不能只顧方便，安全設計還是得下功夫。學完覺得自己對帳戶抽象和安全審計理解更深，之後會繼續追最新的進展，也希望之後有更多實作機會！ 505 | 506 | --- 507 | 508 | 509 | -------------------------------------------------------------------------------- /alichaw.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. alichaw 11 | 2. Yes, will try my best 12 | 3. TG: alichen88 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | - Smart EOA 概念理解 20 | - EIP-7702 的目的 21 | - 和 EIP-4337、帳戶抽象的關係 22 | - Pectra 23 | 24 | [Day1 學習筆記](https://medium.com/@alichen308/day-1-eip-7702-%E6%A6%82%E5%BF%B5%E8%88%87%E8%83%8C%E6%99%AF%E7%90%86%E8%A7%A3-1fb81d56793f) 25 | 26 | ### 2025.05.15 27 | - 新交易類型：SET_CODE_TX_TYPE (0x04) 28 | - 授權列表 `authorization_list` 格式與驗證流程 29 | - 簽名 domain：MAGIC = 0x05 30 | - Nonce 增量邏輯（tx.nonce 與 auth.nonce 的對應） 31 | 32 | [Day2 學習筆記](https://medium.com/@alichen308/day-2-eip-7702-%E6%8A%80%E8%A1%93%E7%B5%90%E6%A7%8B%E8%88%87%E7%B0%BD%E7%AB%A0%E6%A9%9F%E5%88%B6-a76440fb415a) 33 | 34 | ### 2025.05.16 35 | - 批量交易（批次轉帳、approve+swap） 36 | - 氣費贊助（sponsored txs） 37 | - 權限細分（session keys、子密鑰） 38 | - Social recovery 與 ZK 恢復流程 39 | 40 | [Day3 學習筆記](https://medium.com/@alichen308/day-3-eip-7702-%E6%87%89%E7%94%A8%E5%A0%B4%E6%99%AF%E8%88%87%E5%84%AA%E5%8B%A2%E5%AF%A6%E4%BE%8B-084888ebc08a) 41 | 42 | ### 2025.05.17 43 | - 常見弱點總覽（Quantstamp、SlowMist 整理）： 44 | - tx.origin 假設破壞 45 | - initialize frontrun 46 | - storage collision 47 | - fake recharge 攻擊（CEX 對 smart EOA 未辨識） 48 | - replay delegation 49 | - EIP-1271 簽名驗證可被繞過？ 50 | 51 | [Day4 學習筆記]([https://medium.com/p/7ac22d44f398/edit](https://medium.com/@alichen308/day-4-eip-7702%E5%AE%89%E5%85%A8%E8%88%87%E9%98%B2%E7%A6%A6-7ac22d44f398)) 52 | 53 | -------------------------------------------------------------------------------- /bamboochen92518.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # bamboo 9 | 10 | 1. 自我介绍：我是bamboo，目前是一個大學生，對智能合約開發和審計都有興趣，請多多指教 11 | 12 | 2. 你认为你会完成本次残酷学习吗？ 會 13 | 3. 你的联系方式（推荐 Telegram）[t.me/bamboo92518](http://t.me/bamboo92518) 14 | 15 | ## Notes 16 | 17 | 18 | 19 | ### 2025.05.14 20 | 21 | 參考資料： 22 | 23 | 1. [DeFiHackLabs 解說影片](https://www.youtube.com/watch?v=uZTeYfYM6fM) 24 | 2. [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) 25 | 3. [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) 26 | 4. [EIP-4337 Video](https://www.youtube.com/watch?v=PZ8svp68NXM&ab_channel=PatrickCollins) 27 | 5. [EIP-6551](https://eips.ethereum.org/EIPS/eip-6551) 28 | 6. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) 29 | 7. [Ethereum Accounts](https://decrypt101.gitbook.io/decrypt101/blockchain-platforms/ethereum/ethereum-accounts) 30 | 31 | #### EIP 3074 32 | 33 | 1. EIP-3074 引入兩個新操作碼（opcode）： 34 | 1. **`AUTH`**：驗證某個 EOA 的簽名，授權一段後續操作。 35 | 2. **`AUTHCALL`**：代表該授權帳戶去執行一次交易，就像那個帳戶自己發的交易一樣。 36 | 2. 不像 ERC-4337 需要創建新的 smart account，EIP-3074 能讓現有 EOA 的功能升級。 37 | 3. 新增 opcode，執行上更有效率；不需 Bundler、EntryPoint 合約等配套系統。但由於必須修改 EVM opcode，因此升級需要社群共識。 38 | 39 | #### EIP 4337 40 | 41 | 1. 不需要透過私鑰才能交易，各種off-chain的驗證方法也行（驗證邏輯由智能合約決定） 42 | 2. 交易會先被送到Alt-MemPool Node（又稱 UserOperation Pool or Bundler），由於這東西不在鏈上，所以不一定要用native token交易（甚至可由第三方代付），且可以把多筆交易打包成一個atomic operation 43 | 3. 交易送到Alt-MemPool Node並處理後，會再被送到鏈上的 `EntryPoint` 合約處理 44 | 4. 不需要對 Ethereum protocol 本身修改，完全在應用層完成 45 | 46 | #### EIP 6551 47 | 48 | 1. 可以為每一個NFT（ERC721 token）創建一個合約帳戶，讓 NFT 能夠擁有資產、簽署訊息、執行操作 49 | 2. 因為帳戶與 NFT 綁定，轉移 NFT 就等於轉移帳戶擁有權，實現身份/資產一次轉移。 50 | 51 | #### EIP 7702 52 | 53 | 1. `EOA` -> set code tx (0x04) -> Smart Contract Account 54 | 2. 在 Transaction Payload 新增`authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]` 55 | 1. `chain_id`是你想在哪條鏈上交易 56 | 2. `address`是你想呼叫（或授權）的合約地址 57 | 3. `nonce`是你想在哪個nonce執行這個交易 58 | 4. `y_parity, r, s`都是用來簽名的東西 59 | 5. 即使list中的其中一筆交易沒過or失敗，剩下的還是會照樣執行（prevent DoS） 60 | 3. Account code part 是 delegate designator，格式為`0xef + 0100 + target address` 61 | 1. Delegation indicators use the banned opcode `0xef`, defined in [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541), to indicate that the code must be handled differently than regular code. 62 | 63 | #### EIP 7702 vs EIP 3074 and EIP 4337 64 | 65 | 1. EIP 7702 不像 EIP 3074 新增一個 opcode，而是新增一個 transaction type，`AUTH` 被替換成 `verify` 或者 `authorize()`，`AUTHCALL`被替換成`execute`。 66 | 2. EIP 7702 不像 EIP 4337 需要在off-chain做驗證，也不需要`EntryPoint`和`UserOperation Pool`等，`UserOperation Pool`被替換成類似`authorization_list`的東西，因為 EIP 7702 的所有操作都在鏈上，自然不需要`EntryPoint`去連接鏈嚇得驗證到鏈上 67 | 3. 由於EIP 7702 可以將現有的EOA升級，不需要像 EIP 4337 用 `initcode`創建一個新的 smart contract wallet，比較省gas fee 68 | 69 | ### 2025.05.15 70 | 71 | 參考資料： 72 | 73 | 1. [EIP 7702 Example Guide](https://www.quicknode.com/guides/ethereum-development/smart-contracts/eip-7702-smart-accounts) 74 | 2. [EIP 7702 Example Repo](https://github.com/quiknode-labs/qn-guide-examples/tree/main/ethereum/eip-7702) 75 | 76 | 77 | #### Build and Test Smart Accounts 78 | 79 | 注意事項： 80 | 81 | 1. 要先用`foundryup`把版本升到最新 82 | 2. 要在`foundry.toml`加上`evm_version = "prague"`，才有支援EIP-7702的TransactionType之類的東西 83 | 84 | ### 2025.05.16 85 | 86 | 前天主要認識了EIP 7702以及和EIP 3074, 4337的差異 87 | 88 | 昨天則是學習如何透過foundry實做EIP 7702，包括batch transaction以及授權交易 89 | 90 | 今天在學習上沒什麼想法，希望明天可以想到一些有趣的應用。 91 | 92 | ### 2025.05.17 93 | 94 | 今天想到個有趣的應用 95 | 96 | 通常在某調鏈上交易的時候，都會需要native token才能做事情 97 | 98 | （前幾天我想在polygon這條L2上的uniswap提供流動性，但我並沒有POL，只有WETH，但我也不能透過swap用WETH轉成POL，因為我沒辦法支付gas fee） 99 | 100 | 但如果有個dApp可以讓我在另一條我常用的鏈上支付gas fee，就不會有這個問題了。 101 | 102 | 假設我想用A鏈的native token在B鏈做事情，具體的實做流程可能是： 103 | 104 | 1. 我先在A鏈把我預計要出的gas fee (maybe再加上手續費) 給那個要幫我做事的dApp。 105 | 2. 之後把我要執行的function寫好，給那個要幫我做事的dApp，並且授權他可以用我的身份交易。 106 | 3. 接著他就可以用我的身份做事了 107 | 108 | 明天再想想程式碼要怎麼寫吧！ 109 | 110 | ### 2025.05.18 111 | 112 | 本以為昨天的想法很好實踐，畢竟Day 2已經能用foundry實踐Batch transaction以及授權交易了。 113 | 114 | 殊不知，我似乎對先前讀的內容有些誤解：我一直以為`chain_id`可以被設為任意和Pectra Upgrade兼容的所有鏈（例如`authorization_list`的第一個設成1，第二個設成2之類的），但這是不行的！因為`chain_id`只能被設成0或current chain id，是不跳來跳去的（why?） 115 | 116 | 此外，我似乎沒有搞懂如果`chain_id`被設成0會發生什麼事，所以之後來研究一下。 117 | 118 | 最後寫一下第一次參加殘酷共學的心得。我覺得自己除了前兩天比較認真也比較有研究的方向之外，剩下三天其實蠻迷茫的（可能是因為不知道要往哪個方向讀，或者其他事情太多導致我沒辦法花太多時間研究） 119 | 120 | 但Telegram群裡似乎說這個共學會再延長，希望之後再群裡可以看到更多大老的分享，然後找到自己有興趣的學習目標！ 121 | 122 | 123 | -------------------------------------------------------------------------------- /blahole.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | # Tofu 8 | 9 | 1. 自我介绍：本人拥有半年的区块链资金追踪工作经验。 10 | 2. 你认为你会完成本次残酷学习吗？会 11 | 3. 你的联系方式（推荐 Telegram）：@blahole 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.05.14 18 | #### 账户抽象的背景和动机 19 | 1. 外部拥有账户（Externally Owned Accounts, EOAs）是以太坊区块链中最基础的账户类型，由用户通过私钥直接控制。与智能合约账户（Contract Accounts, 20 | CAs）不同，EOAs的功能较为简单，主要用于发起交易、转账以太币（ETH）以及与智能合约交互。 21 | 2. 智能合约账户（Contract Accounts, CAs）是以太坊区块链中的一种账户类型，与外部拥有账户（Externally Owned Accounts, EOAs）相对。与EOAs由私钥控制不同，CAs由部署在区块链上的智能合约代码控制，具备高度的可编程性和灵活性，能够实现复杂的逻辑和自动化操作。 22 | 3. 账户抽象（Account Abstraction） 23 | * 账户抽象是以太坊生态系统中的一个重要概念，旨在通过改进账户模型，增强以太坊的灵活性、安全性和用户体验。它试图模糊以太坊中外部拥有账户（Externally Owned Accounts, 24 | EOAs）和智能合约账户（Contract Accounts, CAs）之间的界限，使所有账户都具有可编程性，从而实现更复杂的交易逻辑、更低的使用门槛和更强的安全性。 25 | * 以太坊账户抽象通过赋予所有账户可编程性，重塑了用户体验、安全性和开发者灵活性。ERC-4337和EIP-7702 26 | 作为核心实现路径，分别通过链下基础设施和协议级修改推动了这一目标。账户抽象的优势包括简化操作、增强安全性、支持创新和金融包容性，但也面临安全风险、Gas成本和生态迁移等挑战。 27 | * 账户抽象被认为是实现以太坊“终极账户抽象”（Endgame Account Abstraction）的关键步骤，最终目标是让所有账户默认具备智能合约功能，同时保持简单性和低成本。 28 | 29 | ### 2025.05.15 30 | #### 深入了解账户抽象 31 | 1. 账户抽象的核心概念 32 | 账户抽象的核心是将账户的验证逻辑和执行逻辑从协议层面下放到用户定义的智能合约层面。具体来说，它允许用户自定义以下方面： 33 | 34 | - 验证逻辑（Signature Verification） 35 | 传统EOAs依赖ECDSA签名验证，账户抽象允许用户定义任意验证机制，例如： 36 | 多重签名（Multi-Sig）：需多个密钥持有人同意。 37 | 替代签名方案：如Schnorr签名、WebAuthn、手机通行密钥。 38 | 无私钥验证：如基于生物识别或零知识证明（ZKP）。 39 | 这种灵活性提高了安全性和用户体验，支持量子抗性签名等未来技术。 40 | 41 | - 执行逻辑（Execution Logic） 42 | 账户抽象允许用户定义交易的执行方式，例如： 43 | 批量交易（Batching）：将多个操作（如授权、转账）合并为单笔交易，减少Gas费用和用户交互。 44 | 权限控制（Spending Controls）：设置交易限制，如每日转账上限或特定DApp的代币支出额度。 45 | 自动化操作：支持订阅支付、定投（DCA）、自动申领空投等。 46 | 47 | - Gas支付灵活性 48 | 传统EOAs要求用户支付Gas费用（需持有ETH），账户抽象允许： 49 | Gas赞助（Gas Sponsorship）：第三方（如DApp或钱包提供商）支付Gas费用。 50 | 支付代币多样化：允许用ERC-20代币（如USDC）支付Gas。 51 | 这降低了新用户进入门槛，提升了金融包容性。 52 | 53 | - 社交恢复（Social Recovery） 54 | 账户抽象支持用户指定“守护者”（如朋友、家人）或恢复机制（如多签），在私钥丢失时恢复账户。无需创建新地址或迁移资产，简化了恢复流程。 55 | 56 | - 协议级抽象 57 | 账户抽象将账户逻辑从以太坊协议（EVM）中解耦，交给智能合约处理，减少对核心协议的修改，保持兼容性。 58 | 59 | 60 | 2. 账户抽象的实现路径 61 | 以太坊社区通过多个提案和标准推动账户抽象，主要包括ERC-4337、EIP-7702（替代EIP-3074）等。以下是详细介绍： 62 | 63 | - EIP-2938：提议将账户抽象直接集成到以太坊协议，引入原生支持（需重大协议修改，短期内未采纳）。 64 | 65 | - EIP-3074（2020年提出，已被EIP-7702替代）：引入AUTH和AUTHCALL操作码，允许EOAs授权智能合约执行交易。 66 | 67 | - ERC-4337（2023年发布）：ERC-4337是一种通过链下基础设施实现账户抽象的标准，无需修改以太坊协议。引入“用户操作”（User Operations, UserOps）：用户发送包含自定义逻辑的交易请求。 68 | 69 | - ERC-7201：定义命名空间标准，防止存储冲突。 70 | 71 | - EIP-7702（2024年提出，替代EIP-3074）：EIP-7702是账户抽象的最新进展，旨在通过协议级修改增强EOAs功能，已纳入Pectra升级（预计2025年5月上线）。 72 | 73 | - ERC-7779（草案）：标准化重新委托流程，优化EIP-7702实现。 74 | 75 | 76 | 3. 账户抽象的优势 77 | - 用户体验提升： 78 | 批量交易和Gas赞助简化操作，降低Gas费用。 79 | 无需持有ETH即可交易，吸引新用户。 80 | 社交恢复和权限控制降低资产丢失风险。 81 | 82 | - 安全性增强： 83 | 自定义验证逻辑支持多签、WebAuthn等，减少私钥依赖。 84 | 权限控制防范钓鱼攻击和未经授权的支出。 85 | 未来可支持量子抗性签名。 86 | 87 | - 开发者灵活性： 88 | 开发者可设计复杂交互逻辑，如自动化的DeFi策略、NFT竞标、链上游戏。 89 | 支持AI代理操作，如自动优化投资组合。 90 | 91 | - 生态整合： 92 | EIP-7702和ERC-4337的兼容性减少了生态碎片化。 93 | 支持跨链统一余额和与传统金融系统的整合。 94 | 95 | - 金融包容性： 96 | Gas赞助和支付代币多样化降低了使用门槛，吸引新兴市场用户。 97 | 98 | 99 | 4. 账户抽象的挑战与风险 100 | - 安全风险： 101 | 恶意合约：授权的智能合约可能包含漏洞或恶意逻辑，需严格审计。 102 | 钓鱼攻击：用户可能被诱导签名恶意授权，导致资金全损。 103 | 存储冲突：重新委托时，合约存储结构不兼容可能导致账户锁定（可通过ERC-7201缓解）。 104 | 105 | - Gas成本： 106 | 对于简单转账，账户抽象的Gas成本高于传统EOA（EIP-7702约增加50%）。 107 | 复杂逻辑（如权限检查）可能显著增加Gas费用。 108 | 109 | - 基础设施依赖： 110 | ERC-4337依赖打包者和中继者，可能引入中心化风险或单点故障。 111 | 需开发者和钱包广泛支持新交易类型（如EIP-7702）。 112 | 113 | - 用户教育： 114 | 普通用户可能难以理解授权签名和智能合约的风险。 115 | 需钱包提供直观的界面和安全提示。 116 | 117 | - 生态迁移： 118 | 现有DApp和钱包需更新以支持账户抽象，短期内可能面临兼容性问题。 119 | 社区需协调标准（如ERC-7201、ERC-7779）以确保一致性。 120 | 121 | 122 | 5. 账户抽象的未来 123 | 账户抽象是以太坊迈向主流采用的关键技术，其未来发展方向包括： 124 | 125 | - Pectra升级（2025年5月）： 126 | EIP-7702将作为核心组件上线，预计显著提升EOA功能。 127 | 其他提案（如EIP-7251）可能进一步优化账户逻辑。 128 | 129 | - 标准化与互操作性： 130 | ERC-7201、ERC-7779等标准将确保存储安全和重新委托的可靠性。 131 | 跨链签名标准可能进一步统一多链生态。 132 | 133 | - 用户教育与安全： 134 | 钱包需开发直观的界面，提示授权风险。 135 | 社区需推广合约审计和安全最佳实践。 136 | 137 | - AI与链上自治： 138 | 账户抽象将推动AI驱动的链上代理，开启去中心化自治组织（DAO）的新篇章。 139 | 140 | - 量子抗性： 141 | 账户抽象支持的自定义签名方案为以太坊应对量子计算威胁提供了基础。 142 | 143 | 144 | ### 2025.05.16 145 | #### ERC-4337 146 | 147 | ERC-4337 是一个以太坊标准，旨在通过链下基础设施实现账户抽象（Account Abstraction, AA），无需修改以太坊核心协议。它于 2023 年 3 月正式部署到以太坊主网，通过引入“用户操作”（User Operations, UserOps）、入口点（EntryPoint）合约和打包者（Bundlers）等机制，赋予账户可编程性，提升用户体验、安全性和开发者灵活性。ERC-4337 被视为以太坊账户抽象的重要里程碑，与 EIP-7702 一起推动了“终极账户抽象”（Endgame Account Abstraction）的实现。 148 | 在 ERC-4337 之前，账户抽象的尝试（如 EIP-3074）因需要修改以太坊协议或引入新操作码（如 AUTH 和 AUTHCALL）而受阻。ERC-4337 的创新在于通过链上智能合约和链下基础设施实现账户抽象，无需硬分叉或协议变更，部署迅速，已在主网广泛应用。 149 | 150 | 1. ERC-4337 的核心机制 151 | 152 | - 核心组件 153 | 154 | - 用户操作（User Operations, UserOps）： 155 | * UserOp 是一个数据结构，包含用户的交易意图（如调用数据、Gas 限制、签名）。它不是标准的以太坊交易，而是通过链下网络提交。 156 | - 格式：sender, nonce, initCode, callData, callGasLimit, verificationGasLimit, preVerificationGas, maxFeePerGas, 157 | maxPriorityFeePerGas, paymasterAndData, signature。 158 | - 作用：定义账户的执行逻辑（如转账、合约调用）和验证方式。 159 | - 打包者（Bundlers）： 160 | - 链下节点，负责收集 UserOps，验证其有效性（如签名和 Gas 可用性），并将其打包为标准以太坊交易，提交到入口点合约。 161 | - 类似矿工或验证者，需运行以太坊全节点或 RPC 节点。 162 | - 激励：通过 Gas 费用或支付者合约的奖励获利。 163 | - 入口点（EntryPoint）合约： 164 | 一个全局的智能合约，地址固定（如主网为 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789），负责处理 UserOps 的验证和执行。 165 | 功能： 166 | - 验证 UserOp 的签名和支付者逻辑。 167 | - 执行 UserOp 的调用数据（callData）。 168 | - 处理 Gas 支付和退款。 169 | 入口点标准化了账户抽象流程，确保钱包和 DApp 的互操作性。 170 | - 支付者（Paymasters）： 171 | 智能合约，负责支付 UserOp 的 Gas 费用，支持 Gas 赞助。 172 | 类型： 173 | - DApp 提供的支付者，为用户补贴 Gas。 174 | - 代币支付者，允许用户用 ERC-20 代币（如 USDC）支付 Gas。 175 | - 第三方支付者，如钱包服务商。 176 | 支付者需验证 UserOp 的合法性，并与入口点交互完成 Gas 支付。 177 | - 智能合约账户（Smart Contract Wallets）： 178 | - 用户部署的智能合约，定义账户的验证逻辑（如多重签名、时间锁）和执行逻辑。 179 | - 与传统 EOA 不同，智能合约账户由代码控制，支持复杂功能。 180 | - 聚合器（Aggregators）： 181 | - 可选组件，优化签名验证。例如，多个 UserOps 的签名可以通过聚合器批量验证，降低 Gas 成本。 182 | - 常见实现：基于 BLS 签名的聚合。 183 | 184 | - 执行流程 185 | 186 | - 用户生成 UserOp： 187 | 用户通过钱包（如 MetaMask、Safe）创建 UserOp，指定调用数据、Gas 限制和签名。 188 | 如果是新账户，UserOp 包含 initCode 用于部署智能合约账户。 189 | 190 | - UserOp 提交： 191 | UserOp 通过链下网络（如 P2P 或 RPC）发送到打包者。 192 | 打包者验证 UserOp 的签名、Gas 可用性和支付者逻辑。 193 | 194 | - 打包与提交： 195 | 打包者将多个 UserOps 合并为一个以太坊交易，调用入口点合约的 handleOps 函数。 196 | 交易格式：from: Bundler, to: EntryPoint, data: handleOps(UserOps[])。 197 | 198 | - 入口点处理： 199 | 入口点合约验证每个 UserOp 的签名和支付者逻辑。 200 | 执行 UserOp 的 callData，触发智能合约账户或其他目标合约。 201 | 处理 Gas 支付，可能从支付者合约扣款。 202 | 203 | - 链上记录： 204 | 链上记录显示为打包者调用入口点合约，资金流和操作细节隐藏在 UserOp 的 callData 中。 205 | 206 | - Gas 模型 207 | - ERC-4337 引入了多层次 Gas 机制： 208 | - callGasLimit：执行 UserOp 的调用数据所需的 Gas。 209 | - verificationGasLimit：验证签名和支付者逻辑的 Gas。 210 | - preVerificationGas：链下预验证和打包的 Gas（如网络传输成本）。 211 | - 支付者或用户需预存 ETH 或代币，确保 Gas 支付。入口点合约退还多余 Gas。 212 | 213 | 2. 功能 214 | 215 | - 可编程验证： 216 | 支持自定义签名方案，如多重签名、WebAuthn、硬件安全模块（HSM）或生物识别。 217 | 例如，一个账户可以要求 3 个签名中的 2 个同意，或结合面部识别和密码。 218 | 219 | - 批量交易： 220 | 多个操作（如授权、转账、兑换）合并为单笔 UserOp，减少 Gas 成本和用户交互。 221 | 示例：用户可以在一次签名中完成 ERC-20 的 approve 和 Uniswap 的 swap。 222 | 223 | - Gas 赞助： 224 | 支付者合约允许 DApp 或第三方支付 Gas 费用，用户无需持有 ETH。 225 | 支持代币支付 Gas（如 USDC），支付者合约处理兑换。 226 | 227 | - 社交恢复： 228 | 账户可以通过信任人或多重签名恢复，无需迁移到新地址。 229 | 示例：用户丢失私钥后，3 个信任人中的 2 个可以授权恢复。 230 | 231 | - 权限控制： 232 | 设置代币支出限额、时间限制或应用白名单，防范钓鱼攻击。 233 | 示例：限制某 DApp 每日最多转账 100 USDC。 234 | 235 | - 自动化操作： 236 | 支持定投（DCA）、订阅支付或自动申领空投。 237 | 示例：智能合约账户定期将 USDC 兑换为 ETH 并存入 DeFi 协议。 238 | 239 | - 跨链兼容性： 240 | UserOps 可以在 L2 网络（如 Arbitrum）上执行，通过跨链桥与主网交互。 241 | 支付者机制支持跨链 Gas 支付。 242 | 243 | ### 2025.05.17 244 | #### EIP-7702的核心机制 245 | 246 | EIP-7702 的核心是通过引入一种新交易类型（称为“设置代码交易”，SET_CODE_TX_TYPE，编码为 0x04）实现 EOAs 的临时智能合约化。其机制基于协议级委托，允许 EOAs 247 | 在单笔交易中“借用”智能合约代码，交易完成后恢复原始状态。 248 | - 交易结构 249 | EIP-7702 基于 EIP-2718（以太坊交易类型的通用框架），定义了一种新交易类型，数据结构为： 250 | rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, 251 | authorization_list, signature_y_parity, signature_r, signature_s]) 252 | chain_id：指定交易有效的链，防止跨链重放攻击。 253 | nonce：EOA 的交易计数器，防止重放攻击。 254 | max_priority_fee_per_gas, max_fee_per_gas：EIP-1559 风格的 Gas 费用参数。 255 | gas_limit：交易的最大 Gas 限制。 256 | destination：目标地址（可为 EOA、合约或空）。 257 | value：转账的 ETH 金额。 258 | data：调用数据（call data），指定交易执行的逻辑。 259 | access_list：EIP-2930 的访问列表，优化 Gas 成本。 260 | authorization_list：EIP-7702 的核心字段，包含多个授权条目（authorization entries）。每个条目格式为：[chain_id, address, nonce, y_parity, r, s] 261 | - chain_id：授权有效的链（0 表示跨链重用）。 262 | - address：委托的智能合约地址（delegation address）。 263 | - nonce：授权的计数器，防止重放攻击。 264 | - y_parity, r, s：授权签名的 ECDSA 参数，验证授权合法性。 265 | 266 | signature_y_parity, signature_r, signature_s：EOA 的 ECDSA 签名，验证交易合法性。 267 | 268 | 269 | 270 | - 临时代码设置 271 | EIP-7702 的核心创新是“临时代码设置”机制，允许 EOA 在交易执行期间临时关联智能合约代码： 272 | 273 | - 初始化： 274 | 当节点处理 EIP-7702 交易时，检查 authorization_list 中的每个授权条目。 275 | 对于每个有效授权（签名验证通过，nonce 匹配），EOA 的代码字段（code field）被临时设置为一个委托指示器（delegation indicator），格式为： 276 | 0xef0100 || address 277 | 0xef0100：固定前缀，表示委托操作。 278 | address：授权条目中的智能合约地址（20 字节）。 279 | 280 | - 执行： 281 | 在交易执行期间，任何对 EOA 的 CALL、DELEGATECALL 或 STATICCALL 操作都会加载委托指示器，并跳转到指定的智能合约代码。 282 | EOA 的上下文（如 msg.sender、msg.value）保持不变，确保调用逻辑以 EOA 身份执行。 283 | 284 | - 清理： 285 | 交易完成后，EOA 的代码字段被清空（恢复为 0x），确保 EOA 恢复为普通账户状态。 286 | 这种临时性避免了持久性更改，降低了授权滥用风险。 287 | 288 | 289 | - 协议级委托 290 | - 委托机制： 291 | EIP-7702 的委托是在以太坊协议层面实现的，无需为每个用户部署代理合约（如 ERC-1967 代理）。 292 | 委托指示器通过协议直接处理，节点在执行交易时自动解析 0xef0100 || address，调用对应的智能合约代码。 293 | - Gas 效率： 294 | 每次授权的 Gas 成本约为 12,500 Gas（包括签名验证和代码设置），远低于部署代理合约的 500,000+ Gas。 295 | 相比 EIP-3074（依赖新操作码），EIP-7702 不修改 EVM，减少维护负担。 296 | 297 | - 签名与安全 298 | - 授权签名： 299 | 每个授权条目包含 EOA 的 ECDSA 签名，基于 chain_id、address 和 nonce 生成。 300 | 签名通过 ecrecover 验证，确保授权来自合法 EOA。 301 | - 防重放攻击 302 | chain_id 限制授权的链范围（0 表示跨链重用）。 303 | nonce 确保每个授权唯一，防止重复使用。 304 | - 自动撤销： 305 | 交易完成后，委托关系自动失效（代码字段清空），无需用户手动撤销，降低授权被滥用的风险。 306 | 307 | - 兼容性设计 308 | 309 | EIP-7702与ERC-4337完全兼容，现有ERC-4337钱包和基础设施可以直接利用其机制。它不引入新的操作码，减少了对EVM的修改，确保与现有以太坊客户端的兼容性。 310 | 311 | - EVM 修改： 312 | EIP-7702 不引入新操作码，仅扩展交易类型和代码字段的处理逻辑。 313 | EVM 在解析 CALL 等操作时，识别委托指示器（0xef0100 || address），加载目标合约代码。 314 | 315 | - 存储与状态： 316 | 委托合约的存储（storage）与 EOA 分离，遵循 ERC-7201（命名空间标准）以避免冲突。 317 | EOA 的状态（如余额、nonce）在交易期间保持一致，委托合约仅影响执行逻辑。 318 | 319 | 320 | 321 | 322 | ### 2025.05.18 323 | #### EIP-7702对资金追踪的影响 324 | 325 | - 账户抽象（Account Abstraction, AA）通过增强以太坊账户的灵活性和可编程性，对交易地址资金追踪产生了一定的影响。这种影响既有正面作用（如提高隐私性和追踪复杂性），也带来新的挑战（如增加分析难度和潜在的洗钱风险）。 326 | - 智能合约代理执行的交易改变了以太坊链上资金流的记录方式，导致传统追踪方法（如基于 EOA 的地址关联分析）失效。以下是资金链难以追踪的具体原因： 327 | - 资金流被合约交互掩盖： 328 | 在传统 EOA 交易中，资金流直接表现为地址 A 到地址 B 的转账，链上记录清晰（如 from: EOA_A, to: EOA_B, value: 1 ETH）。 329 | 在账户抽象中，资金流可能表现为 EOA 与智能合约的交互，或智能合约之间的调用。例如： 330 | EIP-7702 交易记录显示 EOA 调用委托合约，实际资金可能通过合约内部逻辑转移到多个地址。 331 | ERC-4337 交易记录显示入口点合约执行 UserOp，资金流可能涉及智能合约账户、支付者合约和其他目标地址。 332 | 追踪需解析合约代码，理解其逻辑（如转账条件、目标地址生成规则），而非简单跟踪地址。 333 | - 批量交易合并资金流： 334 | 批量交易将多个操作合并为单笔交易，链上仅记录一次交互。例如，用户可能同时执行 ERC-20 代币的 approve、Uniswap 兑换和 ETH 转账，但链上仅显示一个 EOA 到委托合约的调用。 335 | 这种合并隐藏了资金的逐条流向，追踪工具需拆解合约的内部调用栈，分析每个操作的输入和输出。 336 | - Gas 赞助隐藏发起者： 337 | Gas 赞助允许支付者合约或其他第三方支付交易费用，链上记录的 Gas 支付方与实际资金发起者分离。 338 | 例如，用户 A 的交易可能由 DApp 的支付者合约支付 Gas，链上记录显示 Gas 来自合约地址，而非用户 A 的 EOA。这使得追踪工具难以关联真实发起者的资金来源。 339 | - 多层合约与动态逻辑： 340 | 智能合约代理可能嵌套多层调用，例如委托合约调用另一个合约，再触发第三方协议（如 Aave 或 Curve）。 341 | 合约逻辑可能是动态的（如根据链上状态选择目标地址），或涉及存储变量（如权限表），追踪需实时解析合约状态和代码。 342 | 例如，一个智能合约账户可能通过多重签名将资金分散到多个地址，追踪需还原签名者和资金的最终去向。 343 | - 跨链与 L2 交互： 344 | EIP-7702 的授权签名支持跨链重用，资金可能在以太坊主网、L2 网络（如 Arbitrum）或其他链之间转移，追踪需跨链分析。 345 | ERC-4337 的 UserOps 可能在 L2 上执行，资金流通过跨链桥或打包者处理，增加了数据整合的复杂性。 346 | - 隐私增强机制： 347 | 账户抽象支持自定义验证（如 WebAuthn、生物识别）或社交恢复，减少了链上地址与现实身份的直接关联。 348 | 例如，一个账户可能通过信任人恢复，链上记录仅显示新授权的合约地址，而非原始私钥持有者。 349 | - 账户抽象（特别是 EIP-7702 和 ERC-4337）对以太坊交易地址资金追踪产生了双重影响： 350 | - 正面：增强了用户隐私，通过批量交易、Gas 赞助和可编程逻辑模糊资金流，增加了追踪复杂性，保护了合法用户。 351 | - 负面：提高了分析工具的适配难度，隐藏了真实控制者，可能被用于洗钱或欺诈，增加了监管挑战。 352 | - 为应对这些影响，区块链分析公司需升级工具以解析智能合约逻辑，钱包和 DApp 需提高透明度和用户教育，监管机构需与社区协作制定合规标准。EIP-7702 的测试网部署（Pectra 升级，预计 2025 年 5 353 | 月上线）和钱包支持表明其影响已在显现，但全面适配仍需时间。账户抽象的普及将推动以太坊生态的隐私性和灵活性，同时要求资金追踪技术与时俱进。 354 | 355 | 356 | 357 | -------------------------------------------------------------------------------- /bobs-1.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # Bobs-1 9 | 10 | 1. 自我介绍: Hi everyone，我是 bobs-1，Ethereum生态的从业者，想趁这个机会深入学习下底层技术 11 | 2. 你认为你会完成本次残酷学习吗？： 能，必须的 12 | 3. 你的联系方式（推荐 Telegram）: @Bob_Sui 13 | 14 | 15 | ## Notes 16 | 17 | 18 | 19 | ### 2025.07.11 20 | 21 | 笔记内容 22 | 23 | ### 2025.07.12 24 | 25 | 26 | -------------------------------------------------------------------------------- /brucexu-eth.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+12 3 | --- 4 | 5 | # Bruce Xu 6 | 7 | 1. 自我介绍：E 卫兵 8 | 2. 你认为你会完成本次残酷学习吗？：会 9 | 3. 你的联系方式（推荐 Telegram）：@brucexu_eth 10 | 11 | ## Notes 12 | 13 | 14 | 15 | ## 2025.05.14 16 | 17 | # https://eip.fun/eips/eip-7702 18 | 19 | This EIP therefore focuses on adding short-term functionality improvements to EOAs which will allow UX improvements to permeate through the entire application stack. 20 | 21 | 三大用例（TODO 分别制作 Demo）： 22 | 23 | - Batching：多个交易合并一笔 24 | - Sponsorship：使用其他账号和 ERC-20 来为当前账号代付 gas 25 | - Privilege de-escalation：授权 sub-keys 用于低安全性使用场景，这样可以减少签名的操作 26 | 27 | # 2025.05.15 28 | 29 | authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...] 30 | 31 | The authorization list is processed before the execution portion of the transaction begins, but after the sender's nonce is incremented. 32 | 33 | EOA 的执行流程： 34 | 35 | 1. 发送 SET_CODE_TX_TYPE 0x04 + authorization_list 交易，包含授权的信息 36 | 2. EOA 对 authorization_list 签名 + 循环验证 pre-execution checks 37 | 3. 依次处理 `authorization_list` 中的每个授权条目：验证授权并将有效授权设置到对应 EOA 的代码区，使其指向一个委托合约地址（即设置 Delegation Indicator）。若同一 EOA 有多个授权，则以列表中最后一个有效授权为准。 38 | 4. `authorization_list` 处理完毕后，执行交易的主要操作（如 `data` 字段中定义的调用）。此时，被成功设置了 Delegation Indicator 的 EOA 将作为代理（proxy）执行其委托合约的代码。 39 | 5. 交易完成后，EOA 上设置的 Delegation Indicator 会持续存在，除非通过新的 EIP-7702 交易来更改或清除它。 40 | 41 | Delegation Indicator： 42 | 43 | - 设置到 EOA code 字段，告诉 EVM 用特殊的方式执行这个 code 44 | - 使用 0xef0100 开头，后面是 20 bytes 的以太坊地址，是一个智能合约，包含了当前 EOA 被调用时候，真正的执行逻辑 45 | - 存在 code 的 EOA，行为上像是代理合约 46 | - 当有交易跟 EOA 交互，EVM 会加载 indicator 指向的合约代码 47 | - 作为代理合约，被执行的合约代码使用 EOA 的 context，所以 msg.sender 和 msg.value 都是当前 EOA 的 48 | - 通过 7702 设置了 Delegation Indicator 就会一直存在，除非被另一个 7702 tx 修改或者清理，不会自动消失，实现持久性 49 | 50 | TODO Delegation Indicator 会有多个吗？还是单例？如果设置过多个 authorization tuple，会是什么效果？ 51 | 52 | # 2025.05.16 53 | 54 | 可以直接指向 ERC-4337 或者 RIP-7560，这样可以低成本使用。TODO 做一个 Demo。 55 | 56 | ## Self-sponsoring: allowing tx.origin to set code 57 | 58 | tx.origin 始终是最初的 EOA，msg.sender 可能是根据调用递进的。所以之前用 tx.origin == msg.sender 来判断是否有中间调用以及当前调用者是不是一个 EOA。 59 | 60 | 关于合约里面这个判断逻辑的安全风险，EIP 上面做了简单的分析。 61 | 62 | 传统的基于 relayer 的 gas sponsorship 流程是这样的： 63 | 64 | 1. 用户打算对一个 dapp 交互，但是没有 ETH，签署这个交易意图，链下发送给 relayer 65 | 2. relayer（有 ETH 的 EOA），验证有效性和从用户的其他途径收费，然后组装发送 tx，支付 gas 66 | 3. 合约被调用，此时 tx.origin 和 msg.sender 是 relayer，但是合约需要有能力验证签名，将实际功能作用于实际意图发起者 67 | 68 | 基于 7702 的新的流程： 69 | 70 | 1. 用户发起 0x04 交易，将 EOA Code 指向委托合约逻辑，然后直接执行委托合约的逻辑 71 | 2. gas 还是需要自己支付，但是不需要 relayer 进行执行 72 | 73 | 7702 可以让 EOA 可以设置 code 到某些更复杂的 AA 账号，使用相应功能，但是第一步的 Delegation Indicator 的设置费用还是需要的，如果后面不被清理，这是一次性的费用。估计还是需要让钱包进行赞助。 74 | 75 | TODO 这里 AA 钱包项目其实可以开发一个 gas airdrop 项目，如果确定要设置和使用当前 AA，则可以在这里领取 gas，同时用于设置 Delegation indicator 到当前 AA。 76 | 77 | # 2025.05.17 78 | 79 | This EIP breaks a few invariants: 80 | 81 | - An account balance can only decrease as a result of a transaction originating from that account. 82 | - Once an account has been delegated, any call to the account may also cause the balance to decrease. 83 | - 之前的任何 balance 的变动，都是要 EOA 自身去支付 gas 和转账，有了 7702 之后，EOA 变成了 Smart EOA，外部可以调用这个 EOA，然后实际上调用了委托逻辑合约的代码，然后对 EOA 的余额进行操作 84 | - 好危险啊，TODO 做一个安全的案例，授权了不安全的委托逻辑合约，可以被外部调用，盗走测试币。如果一个 EOA 曾对某个（可能是恶意的）合约进行了 ERC-20 代币的无限额度授权（approve(spender, type(uint256).max)），然后该 EOA 又通过 EIP-7702 委托给了一个可以被外部调用的、能触发该 spender 合约 transferFrom 的委托逻辑，那么风险会进一步放大。 85 | - An EOA nonce may not increase after transaction execution has begun. 86 | - Once an account has been delegated, the account may call a create operation during execution, causing the nonce to increase. 87 | - tx.origin == msg.sender can only be true in the topmost frame of execution. 88 | - Once an account has been delegated, it can invoke multiple calls per transaction. 89 | 90 | EIP-7702 本身不提供直接的风险缓解机制，它赋予了 EOA 这种强大的能力，同时也要求用户和开发者承担相应的责任，TODO 可以做一些基础设施： 91 | 92 | - 只委托给受信任的、经过审计的合约：这是最重要的一点。用户在通过 EIP-7702 设置 Delegation Indicator 时，必须极端谨慎，确保其指向的合约地址是完全可信的、代码是安全的、并且经过了严格的第三方安全审计。 93 | - 合约审计查询和安全报告 94 | - 最小权限原则：如果可能，委托的合约应该遵循最小权限原则，只暴露必要的功能，并对这些功能进行严格的访问控制。 95 | - 7702 合约授权权限解释工具 + 可能的潜在风险 96 | - 使用成熟的、标准化的钱包实现：例如，如果 EOA 委托给一个符合 ERC-4337 标准的、经过良好测试的智能账户实现，那么可以依赖该标准和实现的安全性。 97 | - 4337 AABeat 的安全性测试标准 98 | - 权限降级用例的谨慎设计：在实现“权限降级”（例如，创建一个只能与特定 DApp 交互的子密钥）这类用例时，委托逻辑合约需要被精心设计，以确保它不能被滥用来执行超出预期的操作。 99 | - 权限控制面板，支持精细化的自定义权限等，或者进行权限管理、撤销等 100 | - 用户教育和钱包的责任：钱包提供商在支持 EIP-7702 时，有责任向用户清晰地解释这种委托操作的潜在风险，并提供工具来审查和管理委托。可能需要有明确的警告，告知用户他们正在将其账户的控制权（部分或全部）交给另一个合约。 101 | - 对 Delegation Indicator 进行 AI 自动化安全扫描和解析，并提示可能风险 102 | - 及时撤销委托：如果用户怀疑委托的合约有问题，或者不再需要该委托，应尽快通过发送一个新的 EIP-7702 交易，将 Delegation Indicator 指向零地址（0x00...00）来清除委托，或指向一个已知的安全合约。 103 | - 急救合约，在调用真实合约的前面，增加一个急救合约 wrapper，可以实现快速的合约调用切断。这个合约可以由安全公司和团队进行管理，仅支持阻断交易的功能 104 | 105 | # 2025.05.18 106 | 107 | 安全的风险还是很高的，EOA delegated to code 之后，任何人都可以发起对这个 EOA Code 的调用，可能会直接清零。所以相关系统可能需要多加注意，不能静态的计算当前 EOA 的余额信息等。 108 | 109 | ## https://docs.biconomy.io/eip7702/explained/ 110 | 111 | EIP-7702 bridges this gap by enabling EOAs to behave like smart accounts while maintaining their original addresses and established on-chain history. 112 | 113 | ## https://media.licdn.com/dms/image/v2/D4D22AQG03Xobor9mqQ/feedshare-shrink_2048_1536/B4DZaUVG9DG0Ao-/0/1746245285654?e=1749081600&v=beta&t=pmXk3YrFztt99aRZ_icekl4ENfAgiWLW0fWoc-HuCb0 114 | 115 | 需要注意的安全事项和详细的解释案例： 116 | 117 | - Reentrancy Guard 重入攻击，不要在使用 tx.origin 进行保护 118 | - 重入攻击是 Contract A 调用 Contract B 的时候，没有结束之前，重新调用了 Contract A，如果 balance 设置不正确，就会被恶意抽走 119 | - 之前有一种方式是判断 tx.origin == msg.sender 来阻断重入攻击，因为在重入之后，Contract B 成为了 msg.sender，这是不应该出现的 120 | - TODO 模拟一个 EOA 调用自己的 Contract，以及 reentrancy attack 看看相关的 tx.origin 和 msg.sender 的内容 121 | 122 | # 2025.05.19 123 | 124 | - Safe Initialization: Avoid atomic init() calls – use initWithSig to prevent frontrunning. 125 | - frontrunning 就是抢跑，看到 mempool 里面的交易，用更高的 gas 去抢跑执行，所以在 init call 的时候可以抢先执行，将 initialize(ownerAddress) 等操作设置为自己 126 | - initWithSig 包括真正 owner 的 sig，然后合约里面进行验证 127 | - 在代理合约模式、工厂合约模式等等，通常使用额外的 initialize tx 来对合约进行初始化参数 128 | 129 | TODO 搞一个 Demo，看看 7702 能不能完全 0 gas（第一笔通过 relayer 的方式）实现指向。 130 | 131 | TODO 做一个 7702 小游戏，I need your help，跟朋友一起玩，可以生成一个求助链接，然后朋友帮忙代付 gas 132 | 133 | # 2025.05.26 134 | 135 | - Use EntryPoint: Require initialization to be called from ERC-4337's EntryPoint for added safety 136 | - EntryPoint 合约是 AA 的全局、单例智能合约，是 AA 账户的统一入口，负责验证、执行 UserOperations、Paymaster 等 137 | - 这一条建议要求在合约里面判断 initialization call 是从 EntryPoint 合约发出的，这样可以借用 EntryPoint 合约对安全性提供更多检查 138 | - TODO 做一个 demo，使用 EOA 调用 EntryPoint 创建一个 AA 账号，以及额外的安全漏洞 demo 139 | - Avoid Storage Collisions: Switching delegation contracts can cause bugs if storage layouts conflict 140 | - 因为合约变量值的存储是按照 slot 位置进行的，所以切换了不同的合约，数据还在，可能产生读取敏感数据或者写入覆盖等问题 141 | - 最好使用命名空间、兼容布局或者清理存储等方式 142 | - Phishing Risks: Only delegate to immutable, CREATE2-deployed contracts - never metamorphic ones 143 | - CREATE2 地址计算 address = keccak256(0xff + factory + salt + keccak256(initCode)) 保证了防止指向的合约代码替换 144 | - Minimize Trusted Surface: Keep delegation contract logic minimal and auditable to avoid critical bugs 145 | - 使用必要的核心逻辑合约，不要用大而复杂的，聚焦在模块化的具体功能上面 146 | 147 | 一些最佳实践： 148 | 149 | - Delegation contract should align with AA standards 150 | - Stay Permissionless: Don't hardcode relayers; anyone should be able to relay & censorship resistance 151 | - Pick 4337 Bundlers: Use EntryPoint >= 0.8 for gas abstraction 152 | - dApp integration: Utilize ERC-5792 or ERC-6900, no standardized methond for dApps to request 7702 authorization signatures directly 153 | - Avoid Lock-In: Stick to open, interoperable standards like Alchemy's Modular Account 154 | - Preserve Privacy: Support ERC-20 gas payments, session keys, public mempools to minimize data exposure 155 | - Use Proxies: Delegate to proxies for upgrades and modularity without requiring additional EIP-7702 authorizations for each change 156 | 157 | # 2025.05.28 158 | 159 | ## ERC-4337 基础知识 160 | 161 | 用户发送 UserOperation 的交易，包含更多指令和附加数据等。发送到 mempool 节点上。大概结构如下： 162 | 163 | ``` 164 | struct UserOperation { 165 | address sender; 166 | uint256 nonce; 167 | bytes initCode; 168 | bytes callData; 169 | uint256 callGasLimit; 170 | uint256 verificationGasLimit; 171 | uint256 preVerificationGas; 172 | uint256 maxFeePerGas; 173 | uint256 maxPriorityFeePerGas; 174 | bytes paymasterAndData; 175 | bytes signature; 176 | } 177 | ``` 178 | 179 | mempool 里面的 bundler 会将 UserOperation 打包成真实交易。 180 | 181 | Bundler 是一个 mempool，监听 UserOperation，将多个 UserOperation 打包成一个交易，然后提交给 EntryPoint 合约，通过抽取 gas fee 维持。 182 | 183 | EntryPoint 是一个单例智能合约，验证和执行 UserOperation，通过 calldata 来执行，从智能合约账户中取 gas 来支付。 184 | 185 | Paymaster 也是一个智能合约，处理 Gas 支付方式等，消除原生代币才能支付 gas 的限制，实现代付。 186 | 187 | ## https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/ 188 | 189 | EIP-7702 aims to solve these user experience issues by allowing EOAs to delegate their execution to smart contracts, effectively giving them programmable capabilities without requiring users to migrate to entirely new wallets. 190 | 191 | In simpler terms, your EOA can say: "When I receive transactions, run this smart contract code instead." 192 | 193 | How It Works: 194 | 195 | - A user signs a special authorization message from their EOA 196 | - This authorization is included in a transaction 197 | - When processed, the Ethereum network records that this EOA should delegate to a specific smart contract 198 | - Future transactions to this EOA will execute the smart contract's code 注意，这个 tx 可以是外部发起对当前 EOA 的调用，这样跟一个 contract 没什么区别，但是调用的上下文是 EOA 的。所以如果 delegate 的合约地址有问题，就比较大了 TODO 做一个安全攻击的 example 199 | - Importantly, the msg.sender in these transactions remains the EOA's address 200 | 201 | This is different from a proxy contract because the delegation happens at the protocol level - there's no separate contract deployed for each user. Instead, the EOA appears to have code attached to it directly. 202 | 203 | TODO 黑客松 Transaction Batching demo 204 | TODO 黑客松 Gas Sponsorship demo 205 | TODO 黑客松 Permission Management demo 206 | 207 | 几个限制： 208 | 209 | - eoa 的 pk 还是最高权限，可以随时清理 Delegation 210 | - eoa 的 Delegation 可以更换，所以这个不是真正的不可变合约 211 | - 多个 chain 需要分别 sign authorization，除非 sign 的时候，chain_id 设置为 0，但是 nonce 每个 chain 是不一样的，所以还是没法用的。导致跨链一致性和互操作性是有问题的 212 | - app 无法 control eoa 的 7702 delegation，这个是 wallet 端自己的限制，他们拒绝 app 发起的 tx 包含 auth。wallet 会让 eoa 指向自己的实现，但是这样 app 无法引导用户使用自己喜欢的 smart accounts，针对不同的 wallet 会产生不同的实现 213 | 214 | TODO 7702 smart account marketplace，列出来不同的 AA 可以让大家选择，可以借用某种机甲风格作为概念，相当于钢铁侠的机甲或者高达，或许变成了某种游戏？比如使用不同的人物角色 215 | 216 | 其他相关的可以一起使用的 EIP、ERC： 217 | 218 | - ERC-7710: Creates a standard interface for smart contracts to delegate permissions to other contracts. Think of it as an extension of the ERC-20 approve function but for arbitrary permissions. 219 | - ERC-7715: Introduces a new JSON-RPC method called wallet_grantPermissions that applications can use to request permissions from wallets. 220 | - This approach utilizes the wallet_sendCalls JSON-RPC method defined in ERC-5792 221 | 222 | TODO https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/ 这个加入黑客松 223 | 224 | One, often overlooked, feature of EIP-7702 is that it enables developers to deploy new smart accounts for users up to 80% cheaper than before. It achieves this by leveraging the fact that an EIP-7702 proxy costs only 12,500 gas to set up. By using a few clever cryptographic tricks - such as Nick’s method and signature packing - developers can deploy fully featured smart accounts (with support for resource locks, time locks and multi sigs) - by using just EIP-7702. 225 | 226 | TODO 使用 PREP 方法部署一个 companion account https://blog.biconomy.io/provably-rootless-eip7702-proxy/ 227 | 228 | Companion Account: An application-specific smart account that acts as an intermediary between users and applications. 229 | 230 | 对于 app dev 来说，不同的 wallet 会使用不同的实现，所以需要兼容主流的钱包的一些方法，而且不是所有 chain 都会支持，这样的话，岂不是会造成 app 端更加的混乱？ 231 | 232 | ## https://hackmd.io/@colinlyguo/SyAZWMmr1x 233 | 234 | TODO 一个 7702 权限管理平台，类似 Web3 的 Google Account，用户可以签约授权，然后方便外面的 Web2、Web3 网站使用 OIDC 来调用当前权限管理平台进行登录。统一了登录接口，然后避免用户泄露了私钥，然后支持授权。 235 | 236 | 237 | -------------------------------------------------------------------------------- /chesley666.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | # chesley666 8 | 9 | 1. 自我介绍：web2测试工程师转web3 10 | 2. 你认为你会完成本次残酷学习吗？会 11 | 3. 你的联系方式（推荐 Telegram）：@rorozn_OvQ_ 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.05.14 18 | 1. 解读[EIP7702]([https://eips.ethereum.org/EIPS/eip-7702])提案 [视频资料](https://www.youtube.com/watch?v=uZTeYfYM6fM)/[文字版](https://slowmist.medium.com/in-depth-discussion-on-eip-7702-and-best-practices-968b6f57c0d5) 19 | - EOA: externally owned account外部拥有账户 20 | - EIP7702： 21 | 钱包将指向链上的智能合约，功能上类似starknet账户 22 | 引入一种新的交易类型（0x04），允许账户自行设置和委托代码。它不再将完整的合约代码直接存储在账户中，而是存储一个**委托指示符**，该指示符由一个特定的前缀加上一个地址 ( (0xef0100 || address))组成。这个指针指向实际智能合约代码在链上的位置。 23 | 7702交易的destination不能为空：不能是创建合约的交易。 24 | 25 | - 用途： 26 | 让EOA账户拥有合约账户那样灵活的能力 27 | 保持原有地址不变，兼容现有工具 28 | L1层面支持多签、社交恢复、 29 | gas替付等能力：可以使用代币或者第三方等结算gas 30 | 批量合约调用：比如把approve和swap通过合约打包成1比交易，可以减少gas 31 | 会话session：比如定期转账或者授权dapp定投等 32 | 33 | - 数据结构： 34 | 授权列表：与1559对比：增加委托列表，至少1条 [chain_id授权的链, address目标合约地址, nonce, y_parity签名, r, s] 35 | 同一条链只有最后1条生效 36 | **chainid为0**的话，在所有支持7702的连上重放/授权，务必先确定每条链都是安全的 37 | 通过tx==msg.sender来检查交易是否合法的合约，需要重新设计安全检查，因为有了7702之后，交易发起者不一定是实际用户 38 | 39 | - 与 EIP-4337 比较： 40 | - EIP-7702 和 ERC-4337 都旨在推进账户抽象（Account Abstraction, AA），使外部拥有账户（EOA）能够拥有类似智能合约的功能. 41 | - EIP-7702 集成更精简，而 EIP-4337 提供更全面的账户抽象模型，两者可针对不同场景共存。7702无需中转合约调用，相比4337多次合约调用，bundler打包，消耗更少的gas。 42 | - 7702需要通过硬分叉，节点、rpc、钱包都需要升级才能支持，而4337目前已经支持。 43 | - [参考](https://mirror.xyz/0x9FFC14AB8754E4De3b0C763F58564D60f935Ad6F/eiLgBj9iPFmy4s4bmjY2jvEW_7g8YxYMQaHvqm9Xw_o) 44 | 45 | ### 2025.05.15 46 | 2. 安全相关: [8类安全问题](https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day02.md#security-risk-of-eip-7702) 47 | - 存储冲突：修改授权合约时，要确保修改前后合约存储的slot内容对应一致，[slot相关介绍](https://mixbytes.io/blog/collisions-solidity-storage-layouts)，或者利用ERC7201，使用[存储命名空间](https://www.rareskills.io/post/erc-7201)来避免冲突 48 | - 骗gas的爆破？【待实践】 49 | - 老的链上合约，有些使用require(msg.sender == tx.origin)来检验交易是否合法，在7702升级之后需要升级合约，因为存在7702的账户在和这种老合约交互的时候，tx.origin并不一定是真实用户的地址 50 | 3. 链上数据浏览 51 | - [链上智能账户统计](https://www.bundlebear.com/eip7702-overview/all) 52 | - [okx的代理合约](https://etherscan.io/address/0x80296FF8D1ED46f8e3C7992664D13B833504c2Bb) 53 | ```solidity 54 | /** 55 | * @dev Modifier to make a function callable by the account itself or EOA address under 7702 56 | */ 57 | 58 | modifier onlySelf() { 59 | if (msg.sender != address(this)) revert Errors.NotFromSelf(); 60 | _; 61 | } 62 | ``` 63 | - [设置7702的EOA](https://holesky.etherscan.io/tx/0x29252bf527155a29fc0df3a2eb7f5259564f5ee7a15792ba4e2ca59318080182) 对比 [取消设置的EOA](https://holesky.etherscan.io/tx/0xd410d2d2a2ad19dc82a19435faa9c19279fa5b96985988daad5d40d1a8ee2269#authorizationlist)(代理合约地址0x0..0，注意和chainid=0区分) 64 | 取消代理2：直接把 code hash 重設為空值，真正回歸純 EOA 65 | 66 | ### 2025.05.16 67 | 3. 协议实现细节：[交易流程](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/wayhome.md#20250516) 68 | 4. [gas成本为什么是12500](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/universe-ron.md#2-gas-%E5%B8%B3%E6%9C%AC---%E7%82%BA%E4%BD%95%E8%A6%81%E6%94%B6-12-500) 69 | 70 | ### 2025.05.17 71 | [跟着大佬学习](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/easyshellworld.md) 72 | 5. Pectra升级 73 | IP‑7702提案随 Ethereum 2025 年 5 月 7 日上线的 Pectra 升级一并激活，Pectra 是迄今为止最全面的一次硬分叉，包含共 11 项 EIP 标准。 74 | | EIP 编号 | 名称 | 功能简介 | 75 | | -------- | --------------------------- | ------------------------------ | 76 | | EIP‑7702 | Smart Accounts for Everyone | 让 EOA 临时具备智能账户能力 | 77 | | EIP‑7251 | Enterprise‑Grade Staking | 单验证者质押上限从 32 ETH 提升至 2,048 ETH | 78 | | EIP‑7002 | Execution‑Layer Exits | 允许执行层发起验证者主动退出 | 79 | | EIP‑6110 | On‑Chain Deposit Handling | 缩短验证者激活时间从 \~12h 到 \~13min | 80 | | EIP‑7691 | Increased Blobspace | 区块中 Blobspace 翻倍，促进 L2 数据可用性 | 81 | | EIP‑7523 | State Bloat Mitigation | 清理空账户、防止无谓合约创建 | 82 | | EIP‑2537 | BLS Precompile | 内建 BLS12‑381 操作，加速聚合签名 | 83 | | EIP‑2935 | Historical Hashes | 存储历史区块哈希，支持无状态客户端 | 84 | | EIP‑7594 | Peer-to-Peer DAS | P2P 数据可用性抽样，强化 L2 安全 | 85 | | … | … | 其他如安全与开发者体验优化等 | 86 | 87 | 88 | 6. 从本地发起7702交易(rust) 89 | ```rust 90 | use alloy::{ 91 | eips::eip7702::Authorization, 92 | network::{EthereumWallet, TransactionBuilder, TransactionBuilder7702}, 93 | node_bindings::Anvil, 94 | primitives::U256, 95 | providers::{Provider, ProviderBuilder}, 96 | rpc::types::TransactionRequest, 97 | signers::{local::PrivateKeySigner, SignerSync}, 98 | sol, 99 | }; 100 | use eyre::Result; 101 | 102 | // 使用 Solidity 合约代码生成 Rust 接口 103 | sol!( 104 | #[allow(missing_docs)] 105 | #[sol(rpc, bytecode = "608080604052...")] 106 | contract Log { 107 | #[derive(Debug)] 108 | event Hello(); 109 | event World(); 110 | 111 | function emitHello() public { 112 | emit Hello(); 113 | } 114 | 115 | function emitWorld() public { 116 | emit World(); 117 | } 118 | } 119 | ); 120 | 121 | #[tokio::main] 122 | async fn main() -> Result<()> { 123 | // 启动本地 Anvil 节点，启用 Prague 硬分叉 124 | let anvil = Anvil::new().arg("--hardfork").arg("prague").try_spawn()?; 125 | 126 | // 创建两个用户，Alice 和 Bob 127 | let alice: PrivateKeySigner = anvil.keys()[0].clone().into(); 128 | let bob: PrivateKeySigner = anvil.keys()[1].clone().into(); 129 | 130 | // 使用 Bob 的钱包创建提供者 131 | let rpc_url = anvil.endpoint_url(); 132 | let wallet = EthereumWallet::from(bob.clone()); 133 | let provider = ProviderBuilder::new().wallet(wallet).on_http(rpc_url); 134 | 135 | // 部署 Alice 授权的合约 136 | let contract = Log::deploy(&provider).await?; 137 | 138 | // 创建授权对象，供 Alice 签名 139 | let authorization = Authorization { 140 | chain_id: U256::from(anvil.chain_id()), 141 | address: *contract.address(), 142 | nonce: provider.get_transaction_count(alice.address()).await?, 143 | }; 144 | 145 | // Alice 对授权对象进行签名 146 | let signature = alice.sign_hash_sync(&authorization.signature_hash())?; 147 | let signed_authorization = authorization.into_signed(signature); 148 | 149 | // 准备调用合约的 calldata 150 | let call = contract.emitHello(); 151 | let emit_hello_calldata = call.calldata().to_owned(); 152 | 153 | // 构建交易请求 154 | let tx = TransactionRequest::default() 155 | .with_to(alice.address()) 156 | .with_authorization_list(vec![signed_authorization]) 157 | .with_input(emit_hello_calldata); 158 | 159 | // 发送交易并等待广播 160 | let pending_tx = provider.send_transaction(tx).await?; 161 | 162 | println!("Pending transaction... {}", pending_tx.tx_hash()); 163 | 164 | // 等待交易被包含并获取收据 165 | let receipt = pending_tx.get_receipt().await?; 166 | 167 | println!( 168 | "Transaction included in block {}", 169 | receipt.block_number.expect("Failed to get block number") 170 | ); 171 | 172 | assert!(receipt.status()); 173 | assert_eq!(receipt.from, bob.address()); 174 | assert_eq!(receipt.to, Some(alice.address())); 175 | assert_eq!(receipt.inner.logs().len(), 1); 176 | assert_eq!(receipt.inner.logs()[0].address(), alice.address()); 177 | 178 | Ok(()) 179 | } 180 | 181 | ``` 182 | 183 | ### 2025.05.18 184 | 7. demo方向 185 | - [**7702Defender**](https://www.hackquest.io/zh-cn/projects/ETH-Beijing-2025-7702Defender): 谷歌浏览器插件，自动识别交易风险 186 | - **链上跟单分成系统**：比如一个小虾米A账户订阅鲸鱼B账户，如果赚到钱了，那么通过代理合约自动分成，虾米70%，鲸鱼30% 187 | - **按周期/区块高度的订阅付费**： 188 | - **0gas账户**：钱包A有ETH作为gas，钱包B没有，钱包A发送EIP-7702交易，设置钱包B的授权合约，前提是需要签名验证的rsv参数。[测试代码](https://sepolia.etherscan.io/tx/0x18ac3032d0a11d9c5f7e9b4cde0b99ce68a0bae44442fbf955c059182ba5fe35#authorizationlist) 189 | - **社交**：用户在链上发帖、点赞、打赏，平台或广告商替其付费 190 | - **交易返佣／补贴**：币安、OKX 等中心化平台可在链上做“免 gas 交易” 191 | - **DAO治理免gas投票** 192 | - **游戏**：先玩后付，免费铸造，活动期间免费mint 193 | - **gas token 二级市场** 194 | 195 | 196 | ### 2025.05.19 197 | 8. [测试7702交易](https://github.com/IntensiveCoLearning/EIP-7702/blob/main/wayhome.md#%E6%B5%8B%E8%AF%95-eip-7702-%E4%BA%A4%E6%98%93) 198 | - 合约，批量处理逻辑 199 | ```solidity 200 | /// @notice 代表批量调用中的单个调用。 201 | struct Call { 202 | address to; 203 | uint256 value; 204 | bytes data; 205 | } 206 | 207 | /** 208 | * @notice 直接执行一批调用。 209 | * @dev 此函数旨在供智能账户本身（即 address(this)）调用合约时使用。它检查 msg.sender 是否为合约本身。 210 | * @param calls 包含目标地址、ETH 值和 calldata 的 Call 结构体数组。 211 | */ 212 | function execute(Call[] calldata calls) external payable { 213 | require(msg.sender == address(this), "Invalid authority"); 214 | _executeBatch(calls); 215 | } 216 | 217 | 218 | /** 219 | * @notice 内部函数，用于执行批量调用。 220 | * 合约使用一个随机数（nonce）来防止重放攻击。每次成功执行后，随机数（nonce）都会递增。如果没有实现随机数 221 | *（nonce），攻击者可能会多次重放同一笔交易 222 | */ 223 | function _executeBatch(Call[] calldata calls) internal { 224 | uint256 currentNonce = nonce; 225 | nonce++; 226 | 227 | for (uint256 i = 0; i < calls.length; i++) { 228 | _executeCall(calls[i]); 229 | } 230 | 231 | emit BatchExecuted(currentNonce, calls); 232 | } 233 | 234 | 235 | /** 236 | * @dev 内部函数，用于执行单个调用。 237 | * @param callItem 包含目标地址、价值和调用数据的 Call 结构体。 238 | */ 239 | function _executeCall(Call calldata callItem) internal { 240 | (bool success,) = callItem.to.call{value: callItem.value}(callItem.data); 241 | require(success, "Call reverted"); 242 | emit CallExecuted(msg.sender, callItem.to, callItem.value, callItem.data); 243 | } 244 | ``` 245 | - 签名验证 246 | ```solidity 247 | bytes32 digest = keccak256(abi.encodePacked(nonce, encodedCalls)); 248 | require(ECDSA.recover(digest, signature) == msg.sender, "Invalid signature"); 249 | ``` 250 | - 执行 和 赞助方执行 251 | ```solidity 252 | function execute(Call[] calldata calls) external payable { 253 | // The caller executes the calls directly 254 | } 255 | function execute(Call[] calldata calls, bytes calldata signature) external payable { 256 | // A sponsor executes the calls on behalf of the caller 257 | } 258 | ``` 259 | - 运行脚本 260 | ```bash 261 | anvil --hardfork prague 262 | forge install && forge build 263 | forge script ./script/BatchCallAndSponsor.s.sol --tc BatchCallAndSponsorScript --broadcast --rpc-url 127.0.0.1:8545 264 | ``` 265 | ### 2025.05.20 266 | 9. 代付gas场景测试(源自群友) 267 | ```solidity 268 | import { privateKeyToAccount } from 'viem/accounts' 269 | import { createWalletClient, http } from 'viem' 270 | import { sepolia } from 'viem/chains' 271 | 272 | const walletA = createWalletClient({ 273 | account: privateKeyToAccount('0x...'), // 有ETH的钱包 274 | chain: sepolia, 275 | transport: http(), 276 | }) 277 | 278 | const walletB = privateKeyToAccount('0x...') // 无ETH的钱包 279 | const delegatedContract = '0x80296F...2Bb' // 共享的授权合约 280 | 281 | // Step 1: A 为 B 签署授权绑定 delegatedContract 282 | const authorization = await walletA.signAuthorization({ 283 | account: walletB, 284 | contractAddress: delegatedContract, 285 | }) 286 | 287 | // Step 2: A 发起交易，帮 B 完成代码设置 + 初始化调用 288 | const hash = await walletA.sendTransaction({ 289 | authorizationList: [authorization], 290 | data: '0x8129fc1c', // initialize() 函数选择器 291 | to: walletB.address, 292 | }) 293 | 294 | ``` 295 | b钱包没有eth，a代发7702交易并设定b的合约逻辑；合约中msg.sender是b而不是a； 296 | 这使得 tx.origin == msg.sender 不再能判断eoa发起人，因为7702的msg.sender是b，而不是现实世界的交易发起者a 297 | 298 | ### 2025.05.21 299 | 休息 300 | ### 2025.05.22 301 | 10. 金融方面影响 302 | - 利好 303 | - 账户抽象，降低交易成本，可以实现0gas交易等运营活动，提升用户接受度，吸引用户 304 | - pectra成功实施，证明了基金会在推动技术更替方面的能力，未来可能推动更多提效变革 305 | - 提升L2网络扩展性能，降低交易费用 306 | - 吸引更多eth质押 307 | - 利空 308 | - 可能产生安全漏洞，恶意代理合约 309 | - 小白用户因为误解导致资金损失 310 | - 基金会借机抛售，超出运营需要的合理范畴 311 | - L2项目转向其他链发展，或减少对eth的依赖 312 | 313 | - 重点观察事件 314 | - 用户数量变化：cex交易量，链上活跃地址数量，7702相关地址数量 315 | - 安全事件：因为代理而引起的安全漏洞 316 | - 基金会：内部变动；eip erc 推进效率；是否超额抛售并且和升级有关联； 317 | - 生态占比：eth市值占比；L2生态的项目是否转到其他网络； 318 | - 质押：质押总量和集中度 319 | 320 | ### 2025.05.23 321 | 322 | 323 | -------------------------------------------------------------------------------- /cxc474.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍: Chen-Yuan Chung，我在台灣，想多學習以太坊的知識，希望未來可以參與開發。 11 | 2. 你认为你会完成本次残酷学习吗？ 會 12 | 3. 你的联系方式（推荐 Telegram） cxc474@case.edu 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | https://www.nethermind.io/blog/eip-7702-attack-surfaces-what-developers-should-know 20 | 21 | 以太坊區分兩種帳戶類型： (1) Externally Owned Accounts (EOAs) 外部擁有帳戶; (2) Smart Contract Accounts 智能合約帳戶。 22 | EIP 7702 提議允許 EOA(外部擁有帳戶) 擁有程式碼。此變更將使以太坊更接近帳戶抽象化，透過允許 EOA 批次處理操作、實作原生多重簽名或替代簽名方案，但也引入了新的安全風險，如果實作沒有經過仔細設計和審計。 23 | EIP 7702 的核心是引入一種新的交易類型，允許帳戶在自身上設定和委派程式碼。它不是直接將完整的合約程式碼儲存在帳戶上，而是儲存一個委託指示符 delegation designator，它是一個特定的前綴，後跟一個地址 ( (0xef0100 || address) )，這個指標指示實際的智能合約程式碼在鏈上的位置。簡單來說，錢包將指向一個鏈上的智能合約，而該合約的邏輯決定了帳戶的行為方式。 24 | EIP 7702 代表了以太坊帳戶模型的一個重大演變。透過允許 EOA 納入程式碼，它開啟了更豐富功能的可能性，例如批次交易、gas 贊助和可自訂的邏輯。然而，這種增加的靈活性是以增加攻擊面為代價的，其中存在許多潛在的漏洞。 25 | 開發人員在將此 EIP 整合到其協議之前需要考慮的風險: (1) 缺乏存取控制; (2) 初始化挑戰; (3) 儲存體衝突。 26 | 27 | ### 2025.05.15 28 | https://hackmd.io/@colinlyguo/SyAZWMmr1x 29 | 30 | EIP-7702 引入了一種新的交易類型，允許外部擁有帳戶 (EOA) 指定一個地址作為指向其實現的指標。例如，這個地址可以是一個通用的代理或最小代理合約，將呼叫訊息轉發到一個可升級的錢包實現。 31 | 32 | EIP-7702 有效地將 EOA 升級為像智能合約錢包一樣運作，為 EOA 使用者解鎖了可程式性和可組合性，並啟用了以下功能： 33 | (1)社交恢復：EIP-7702 支援 EOA 使用者的社交恢復。這對於害怕遺失私鑰的使用者特別有利，他們只需透過簡單的社交恢復設定即可克服這個問題。 34 | (2)交易批次處理：使用者可以透過擺脫傳統的 ERC-20 代幣「批准和轉帳」兩步驟授權模型，或進一步批次發送轉帳，來簡化交易流程。 35 | (3)交易贊助：使用者可以將交易執行和 gas 費用支付延遲給第三方，例如排序器或錢包伺服器。此功能為可能沒有用於 gas 支付的原生代幣的使用者提供了便利。 36 | (4)任意簽署金鑰：錢包可以利用各種金鑰類型（例如 WebAuthn、P256、BLS 等）來驗證操作，從而在設計空間中提供更大的靈活性。 37 | (5)會話金鑰：使用者可以將具有生命週期和範圍權限的會話金鑰委託給金鑰託管服務，從而實現訂閱模式。此外，使用者可以在受限制的「沙盒」環境中與 DApp 互動，透過防止惡意行為者存取其完整的錢包或資產，顯著降低網路釣魚攻擊的風險和影響。 38 | (6)自定義 gas 代幣、多重簽名方案的權限控制等等… 39 | 40 | 透過 EIP-7702，從 EOA 的角度來看，ETH 餘額現在不僅可以透過簽署的交易減少，還可以透過觸發合約執行的交易減少。從智能合約的角度來看，EOA 可以直接發送交易來更改帳戶狀態。這引入了以下考量： 41 | (1)過去，EOA 只能透過簽署交易發送 ETH，這使得交易池可以透過檢查新區塊中發送者的餘額來使發送者餘額不足的待處理交易失效。然而，透過 EIP-7702，委派的程式碼可以隨時修改 EOA 的餘額，這使得這種不變性不相容，需要重新考慮相關的交易池邏輯。 42 | (2)EIP-7702 錢包實作不能依賴本地維護的不變性，並且必須查詢真實的帳戶狀態，因為 EOA 可以隨時發起交易來改變他們的餘額。 43 | 44 | ### 2025.05.16 45 | https://eips.ethereum.org/EIPS/eip-7702 46 | 47 | 儘管智能合約錢包生態系統取得了巨大進展，但 EOA 阻礙了跨應用程式的 UX 改善的廣泛採用。因此，EIP-7702 著重於為 EOA 增加短期功能改進，這將使 UX 改善滲透到整個應用程式堆疊中。EIP-7702 圍繞設計的三個特定功能是： 48 | (1)批次處理：允許來自同一使用者的多個操作在一個原子交易中進行。一個常見的例子是 ERC-20 批准，然後花費該批准。這是 DEX 中常見的工作流程，目前需要兩筆交易。批次處理的高級用例偶爾涉及依賴關係：第一個操作的輸出是第二個操作的輸入的一部分。 49 | (2)贊助：帳戶 X 代表帳戶 Y 支付交易費用。帳戶 X 可以因這項服務而獲得一些其他 ERC-20 的支付，或者它可以是免費包含其使用者交易的應用程式營運商。 50 | (3)權限降級：使用者可以簽署子金鑰，並授予它們比全域存取帳戶弱得多的特定權限。例如，花費 ERC-20 代幣但不花費 ETH 的權限，或每天花費不超過總餘額的 1% 的權限，或僅與特定應用程式互動的權限。 51 | 52 | ### 2025.05.17 53 | https://mirror.xyz/0x9FFC14AB8754E4De3b0C763F58564D60f935Ad6F/eiLgBj9iPFmy4s4bmjY2jvEW_7g8YxYMQaHvqm9Xw_o 54 | 55 | EIP-7702：為單一交易設定 EOA 帳戶程式碼新增一種新的交易類型，可以在一次交易執行期間設定 EOA 的程式碼。 56 | 此 EIP 引入了一種新的交易類型，允許外部擁有的帳戶 (EOA) 在一次交易中擁有智能合約代碼。 57 | 簡單來說，在執行此類型的交易期間，EOA 將充當智能合約/智能錢包，並且在交易執行後，它將變回沒有代碼的原始 EOA。 58 | ![image](https://github.com/user-attachments/assets/6c73f409-4377-4299-a1bf-eb20b2ef01b4) 59 | 60 | EOA 使用者錢包簽署 contract_code 並在交易中提供簽名。驗證此簽名後， contract_code 會儲存在 EOA 中，並且在整個交易過程中，它會像一個智能合約一樣運作。交易執行後，程式碼會被清空，而 EOA 再次像普通帳戶一樣運作。 61 | EOA 在交易期間升級為「supercharged EOAs」。 62 | 63 | ### 2025.05.18 64 | https://decentralizedsecurity.es/eip-7702-ethereums-next-step-toward-a-more-flexible-account-model 65 | 66 | 在以太坊中，外部擁有帳戶（EOA）和智能合約傳統上是截然不同的：EOA 由私鑰控制，可以發起交易，而智能合約可以在被觸發時執行代碼，但不能發起交易。 67 | EIP-7702 彌合了這一差距，允許 EOA 執行代碼，有效地模糊了它們與智能合約之間的界限。 這項提案代表了邁向原生帳戶抽象的重要一步，增強了以太坊的可用性、安全性和可編程性。 68 | 傳統上，EOA 具有空的代碼雜湊值 ( 0x )，而智能合約具有從其部署的位元組碼衍生的代碼雜湊值。然而，EIP-7702 改變了這一點——EOA 現在可以具有格式為 (0xef0100 ++ address) 的非空代碼雜湊值。這個值，稱為委託指示符(delegation designator)，指向一個持有可執行代碼的智能合約。 69 | 當交易被發送到具有委託指示符的 EOA 時，它會執行儲存在指定智能合約地址的代碼，就像它是自己的代碼一樣，類似於 delegatecall 在 Solidity 中的工作方式。這使得 EOA 能夠像智能合約一樣運作，同時保持其功能，例如發送交易。 70 | EIP-7702 引入了一種新的交易類型 (0x04)，稱為 setcode，它允許 EOA 與智慧合約關聯，以委託程式碼執行。該交易包含以下欄位： 71 | ![image](https://github.com/user-attachments/assets/94ff8871-ec21-4de2-ab50-16e41f3ab18f) 72 | 73 | 為了建立這種關係，新增了一個名為 authorizationList 的結構，其中包含授權元組，具有以下欄位 [chain_id, address, nonce, y_parity, r, s] ，其中： 74 | chain_id ：識別區塊鏈網路。 75 | address ：指定已部署的智能合約，EOA 將指向該合約以進行程式碼委託。 76 | nonce ：確保唯一性並防止重放攻擊。 77 | signature ：由 EOA 簽署，證明授權。 78 | 79 | ### 2025.05.19 80 | https://docs.biconomy.io/eip7702/explained/ 81 | 82 | EIP-7702 是一項以太坊改進建議，它引入了一種新的交易類型，允許外部擁有帳戶（EOAs）將其執行委派給智能合約。這項協議層的增強有效地為傳統的 EOAs 提供了可編程能力，而無需用戶遷移到全新的錢包地址。 83 | 以太坊生態系統長期以來在賬戶類型上存在根本的分歧。傳統的用戶錢包（EOAs）提供簡便性，但缺乏可編程性，而智能合約賬戶提供強大的功能，但要求用戶採用全新的地址。用戶被迫在保留他們已建立的鏈上身份或獲取高級功能之間做出選擇。可以理解的是，許多用戶由於數位身分的碎片化和所涉及的複雜性而拒絕遷移。 84 | EIP-7702 彌合了這個差距，使 EOA 能夠像智慧帳戶一樣運作，同時保持其原始地址和已建立的鏈上歷史記錄。 85 | EIP-7702 的核心是引入了一種新的交易類型，其中包含一個「授權」欄位。當 EOA 所有者簽署特殊的授權訊息時，以太坊協議會在網路層級記錄此委託。未來發送到此 EOA 的交易將執行委託的智慧合約程式碼，同時仍將 EOA 維持為這些交易中的 msg.sender 。 86 | 這種方法與代理合約有根本的不同，因為委託發生在協議層級。無需為每個使用者部署單獨的合約，從使用者的角度來看，該過程顯著提高了 gas 效率且更加無縫。 87 | EIP-7702 透過啟用三項關鍵增強功能來轉換傳統 EOA： 88 | (1)首先，它啟用交易批次處理，允許使用者將多個操作合併為單個原子交易。例如，先前需要單獨簽名的代幣批准和交換操作可以一次執行。 89 | (2)其次，它為替代 gas 支付機制打開了大門。使用者可以讓應用程式贊助交易、使用 ERC-20 代幣而不是 ETH 支付費用，或受益於最佳化的交易捆綁服務。 90 | (3)第三，它引入了複雜的權限管理。使用者可以創建具有有限權限的專用存取金鑰，用於特定應用程式、實施支出限制或限制某些功能，同時保持核心帳戶安全。 91 | 92 | ### 2025.05.20 93 | https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/ 94 | 95 | 目前 Ethereum 帳戶類型： 96 | 1. 外部擁有的帳戶 Externally Owned Accounts (EOAs)：這些是由私鑰控制的傳統使用者帳戶。當您建立 MetaMask 錢包時，您正在建立一個 EOA。 97 | 2. 合約帳戶 Contract Accounts：這些是您部署的智能合約。 98 | 3. 智慧合約帳戶 Smart Accounts：這些是設計為作為使用者帳戶運作的智能合約。它們提供眾多可程式化的功能：在這個領域有多個標準（ERC-4337、ERC-7579、ERC-6900）以及多個提供智慧合約帳戶解決方案的供應商，如 Biconomy Nexus、Safe、Kernel、Alchemy 等。雖然這些實作在架構上可能有所不同，但它們都旨在提供超越 EOA 所能提供的增強功能。 99 | 100 | 問題在於，大多數使用者都擁有來自 MetaMask 等錢包的 EOA，而遷移到智慧帳戶需要額外的步驟和教育。EIP-7702 提供了一條中間道路，透過增強 EOA 的一些智慧帳戶功能。 101 | EIP-7702 引入了一種新的交易類型，其中包含一個「authorizations」欄位。這個欄位允許 EOA 所有者將其帳戶的執行委託給智能合約。簡單來說，您的 EOA 可以說：「當我收到交易時，請改為執行此智能合約程式碼。」 102 | 103 | 運作方式： 104 | {1} 使用者從他們的 EOA 簽署一個特殊的授權訊息。 105 | {2} 此授權包含在交易中。 106 | {3} 處理後，以太坊網路會記錄此 EOA 應委託給特定的智能合約。 107 | {4} 未來發送到此 EOA 的交易將執行智能合約的程式碼。 108 | {5} 重要的是，這些交易中的 msg.sender 仍然是 EOA 的地址。 109 | 110 | ### 2025.05.21 111 | https://safe.global/blog/eip-7702-smart-accounts-ethereum-pectra-upgrade 112 | 113 | 雖然 EIP-7702 是朝著將 EOA 遷移到智慧合約帳戶邁出的重要一步，但它並非完整實現完全帳戶抽象，也沒有完全將 EOA 轉換為智慧合約帳戶。從帳戶抽象的角度來看，它有幾個限制： 114 | - 私鑰仍是安全風險：EOA 的私鑰保留對帳戶的完全控制權，就像後門一樣，可以覆蓋智慧帳戶的功能。這使得保護私鑰至關重要，因為任何惡意行為者只要獲得存取權，就可以完全控制並竊取所有資金。 115 | - 多重簽名信任問題：在從 EOA 創建多重簽名智能帳戶的情況下，其他所有者必須完全信任原始 EOA 所有者。由於 EOA 的私鑰仍然可以在單筆交易中清除智能帳戶，這破壞了多重簽名設置所需的安全性和信任，使得多個所有者依賴遷移的 EOA 變得不太實際。 116 | - 有限的帳戶恢復：如果私鑰遺失或洩露，則無法完全恢復對 EOA 的控制。唯一的解決方案是替換私鑰，這可能具有挑戰性，並且不提供直接的恢復機制。 117 | - 缺乏量子抗性：為了未來防範量子運算的威脅，使用者最終將需要轉移到完全具備量子抗性的智慧帳戶。具有擴展功能的 EOA 仍然容易受到潛在的量子演算法攻擊，這些演算法可能會洩露其私鑰。這突顯了在後量子時代，需要逐步遷移或緊急更新以保護帳戶安全。 118 | - 無法鎖定資源或作為託管：由於私鑰始終具有轉移資金的權限，因此建立在 EOA 上的智能合約無法有效地作為託管或安全地鎖定資金。這種限制限制了需要資源鎖定的智能帳戶功能的使用。 119 | 120 | ### 2025.05.22 121 | https://docs.gelato.network/smart-wallets/introduction/erc-4337-vs-eip-7702 122 | 123 | ERC-4337 和 EIP-7702 的基本區別和潛在目標，兩者都旨在透過不同的方式增強以太坊的帳戶抽象能力。 124 | - ERC-4337：引入一個智慧帳戶框架，該框架與現有基礎設施（如 bundler 和 paymaster）整合，而無需對以太坊協議進行任何更改。 125 | - EIP-7702：提出了一種協議層級的增強方案，使用一種新的交易類型將 EOA（外部擁有帳戶）升級為智能帳戶smart accounts，這需要一次硬分叉。 126 | 127 | 這兩個標準並非競爭對手，而是互補的。事實上，它們可以協同工作：EIP-7702 可以將 EOA 轉換為智能帳戶，然後該帳戶可以與 ERC-4337 基礎設施無縫交互，以實現中繼和 gas 抽象。 128 | 鑑於 ERC-4337 已經部署並被廣泛採用，它目前是智能帳戶使用的主要標準，並且即使對於啟用 EIP-7702 的帳戶，它也可能繼續成為基礎。 129 | 130 | ERC-4337 提供了一個靈活且可擴展的基礎，已被不斷發展的生態系統採用，而 EIP-7702 則通過將複雜性推入協議本身來簡化體驗。結合使用，它們有望實現強大的組合——使 EOA 能夠無縫加入智能帳戶系統，從而受益於現代抽象功能。 131 | 132 | ### 2025.05.23 133 | 134 | https://www.openfort.io/blog/eip-7702-with-erc-4337 135 | 136 | EIP-7702 背後的基本概念簡單但具有革命性：它使任何 EOA 能夠暫時或永久地採用現有智能合約的功能。正如官方 EIP 文件中所述，它透過允許 EOA「根據任何現有智能合約設定其程式碼」來「賦予 EOA 超能力」。這代表著與傳統以太坊帳戶模型的重大背離，在傳統模型中，EOA 和智能合約一直保持著嚴格分離的功能。 137 | 138 | EIP-7702 的核心是引入了一種新的交易類型 (0x04)，通常稱為「設定程式碼」交易。此交易類型包含一個名為「authorization_list」的新欄位，其中包含必要的簽名和資料，以使 EOA 能夠委託給智能合約實作。 139 | 140 | 交易酬載結構遵循以下格式： 141 | ![image](https://github.com/user-attachments/assets/0b4aa9c5-2cd3-4ad0-a8a6-48552f7d158b) 142 | 143 | authorization_list 包含由以下元素組成的元組： 144 | 145 | ![image](https://github.com/user-attachments/assets/407e4782-8d8c-4a9b-b835-c1eb649748e0) 146 | 147 | 每個元組代表一個授權 EOA 採用指定智能合約地址程式碼的簽名。該簽名是透過簽署這些組件的 keccak256 雜湊值來建立的，以確保升級請求的完整性和真實性。 148 | 149 | 150 | -------------------------------------------------------------------------------- /easyshellworld.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | # none 6 | 7 | 无名的人阿！ 8 | 9 | >我是这路上 没名字的人 10 | 我没有新闻 没有人评论 11 | 要拼尽所有 换得普通的剧本 12 | 曲折辗转 不过谋生 13 | 我是离开 小镇上的人 14 | 是哭笑着 吃过饭的人 15 | 是赶路的人 是养家的人 16 | 是城市背景的 无声 17 | 我不过 想亲手触摸 18 | 弯过腰的每一刻 19 | 留下的 湿透的脚印 是不是值得 20 | 这哽咽 若你也相同 21 | 就是同路的朋友 22 | 23 | 24 | 坚持走完这一路 25 | 26 | ## Notes 27 | 28 | 29 | 30 | ### 2025.05.14 31 | #### EIP-7702缘起 32 | * **why**提出要EIP-7702? 33 | * 传统EOAz账户只能发起交易，却无法执行合约逻辑，用户体验与智能合约钱包相去甚远。EIP‑7702 允许在单笔交易上下文中「暂时为 EOA 设置合约代码」，赋予其智能账户能力，从而简化UX。相较于此前的EIP‑3074引入新操作码导致生态碎片化，7702通过新增交易类型（SET_CODE_TX_TYPE）而非扩展 EVM 指令，兼容性更佳，不需额外调用代理合约，进一步对齐ERC‑4337路线图。 34 | * 兼容并衔接 ERC‑4337。EIP‑4337 已提出基于「用户操作（UserOp）」的抽象账户架构，而 EIP‑7702 可直接在现有 EOA 上执行 Account Abstraction，无需迁移新地址，并与已部署的智能合约钱包共存。 35 | * **who**提出的EIP‑7702 36 | * EIP‑7702 的撰写者和提案人是 Vitalik Buterin，同时 Tin Erispe 和 Ayush Bherwani 也对该提案做出了贡献。 37 | * EIP‑7702的核心目的 38 | * 智能账户能力：EOA 可临时执行合约逻辑，实现批量交易（batching）、Gas 赞助（sponsorship）、社交恢复（social recovery）等功能。 39 | * 简化钱包UX：无需预先持有 ETH、单签名即可完成多步操作，用户可享受类似 Web2 的流畅体验。 40 | * 安全可控：链 ID 绑定、Nonce 绑定、可撤销授权等多重防护，避免被永久锁定或跨链滥用。 41 | * Pectra 42 | * EIP‑7702提案随 Ethereum 2025 年 5 月 7 日上线的 Pectra 升级一并激活，Pectra 是迄今为止最全面的一次硬分叉，包含共 11 项 EIP 标准，除 EIP‑7702 外，还包括企业级质押（EIP‑7251）、验证者可编程退出（EIP‑7002/6110）、Layer‑2 提效（EIP‑7691/7523）、以及若干预编译与历史哈希等安全性能优化提案。 43 | 44 | | EIP 编号 | 名称 | 功能简介 | 45 | | -------- | --------------------------- | ------------------------------ | 46 | | EIP‑7702 | Smart Accounts for Everyone | 让 EOA 临时具备智能账户能力 | 47 | | EIP‑7251 | Enterprise‑Grade Staking | 单验证者质押上限从 32 ETH 提升至 2,048 ETH | 48 | | EIP‑7002 | Execution‑Layer Exits | 允许执行层发起验证者主动退出 | 49 | | EIP‑6110 | On‑Chain Deposit Handling | 缩短验证者激活时间从 \~12h 到 \~13min | 50 | | EIP‑7691 | Increased Blobspace | 区块中 Blobspace 翻倍，促进 L2 数据可用性 | 51 | | EIP‑7523 | State Bloat Mitigation | 清理空账户、防止无谓合约创建 | 52 | | EIP‑2537 | BLS Precompile | 内建 BLS12‑381 操作，加速聚合签名 | 53 | | EIP‑2935 | Historical Hashes | 存储历史区块哈希，支持无状态客户端 | 54 | | EIP‑7594 | Peer-to-Peer DAS | P2P 数据可用性抽样，强化 L2 安全 | 55 | | … | … | 其他如安全与开发者体验优化等 | 56 | 57 | ### 2025.05.15 58 | #### EIP‑7702 交易数据格式 59 | * 交易类型 60 | ``` 61 | TransactionType = 0x04（Set‑Code 交易） 62 | ``` 63 | * TransactionPayload 64 | ``` 65 | [ 66 | chain_id, 67 | nonce, 68 | max_priority_fee_per_gas, 69 | max_fee_per_gas, 70 | gas_limit, 71 | destination, // 不能为 null 72 | value, 73 | data, 74 | access_list, // 同 EIP‑4844 75 | authorization_list, 76 | signature_y_parity, 77 | signature_r, 78 | signature_s 79 | ] 80 | 81 | ``` 82 | * authorization_list 83 | ``` 84 | [ chain_id, address, nonce, y_parity, r, s ] 85 | ``` 86 | 87 | ### 2025.05.16 88 | 在本地 Anvil 节点上，通过 Alloy 库发送 EIP-7702 类型的交易 89 | ```rust 90 | use alloy::{ 91 | eips::eip7702::Authorization, 92 | network::{EthereumWallet, TransactionBuilder, TransactionBuilder7702}, 93 | node_bindings::Anvil, 94 | primitives::U256, 95 | providers::{Provider, ProviderBuilder}, 96 | rpc::types::TransactionRequest, 97 | signers::{local::PrivateKeySigner, SignerSync}, 98 | sol, 99 | }; 100 | use eyre::Result; 101 | 102 | // 使用 Solidity 合约代码生成 Rust 接口 103 | sol!( 104 | #[allow(missing_docs)] 105 | #[sol(rpc, bytecode = "608080604052...")] 106 | contract Log { 107 | #[derive(Debug)] 108 | event Hello(); 109 | event World(); 110 | 111 | function emitHello() public { 112 | emit Hello(); 113 | } 114 | 115 | function emitWorld() public { 116 | emit World(); 117 | } 118 | } 119 | ); 120 | 121 | #[tokio::main] 122 | async fn main() -> Result<()> { 123 | // 启动本地 Anvil 节点，启用 Prague 硬分叉 124 | let anvil = Anvil::new().arg("--hardfork").arg("prague").try_spawn()?; 125 | 126 | // 创建两个用户，Alice 和 Bob 127 | let alice: PrivateKeySigner = anvil.keys()[0].clone().into(); 128 | let bob: PrivateKeySigner = anvil.keys()[1].clone().into(); 129 | 130 | // 使用 Bob 的钱包创建提供者 131 | let rpc_url = anvil.endpoint_url(); 132 | let wallet = EthereumWallet::from(bob.clone()); 133 | let provider = ProviderBuilder::new().wallet(wallet).on_http(rpc_url); 134 | 135 | // 部署 Alice 授权的合约 136 | let contract = Log::deploy(&provider).await?; 137 | 138 | // 创建授权对象，供 Alice 签名 139 | let authorization = Authorization { 140 | chain_id: U256::from(anvil.chain_id()), 141 | address: *contract.address(), 142 | nonce: provider.get_transaction_count(alice.address()).await?, 143 | }; 144 | 145 | // Alice 对授权对象进行签名 146 | let signature = alice.sign_hash_sync(&authorization.signature_hash())?; 147 | let signed_authorization = authorization.into_signed(signature); 148 | 149 | // 准备调用合约的 calldata 150 | let call = contract.emitHello(); 151 | let emit_hello_calldata = call.calldata().to_owned(); 152 | 153 | // 构建交易请求 154 | let tx = TransactionRequest::default() 155 | .with_to(alice.address()) 156 | .with_authorization_list(vec![signed_authorization]) 157 | .with_input(emit_hello_calldata); 158 | 159 | // 发送交易并等待广播 160 | let pending_tx = provider.send_transaction(tx).await?; 161 | 162 | println!("Pending transaction... {}", pending_tx.tx_hash()); 163 | 164 | // 等待交易被包含并获取收据 165 | let receipt = pending_tx.get_receipt().await?; 166 | 167 | println!( 168 | "Transaction included in block {}", 169 | receipt.block_number.expect("Failed to get block number") 170 | ); 171 | 172 | assert!(receipt.status()); 173 | assert_eq!(receipt.from, bob.address()); 174 | assert_eq!(receipt.to, Some(alice.address())); 175 | assert_eq!(receipt.inner.logs().len(), 1); 176 | assert_eq!(receipt.inner.logs()[0].address(), alice.address()); 177 | 178 | Ok(()) 179 | } 180 | 181 | ``` 182 | 183 | ### 2025.05.17 184 | * EIP-4337 与 EIP-7702 对比 185 | 186 | * EIP-4337 通过高层内存池（mempool）实现账号抽象，使用 `UserOperation` 对象、Bundlers（打包者）、EntryPoint 合约和可选 Paymasters（支付代理），无需共识层更改。 187 | * EIP-7702 通过新增 EIP-2718 “Set Code Transaction” 类型，使外部账户（EOA）在交易执行期间临时注入智能合约代码，交易后即丢弃代码。 188 | * 在 EIP-4337 中，智能合约账户为永久部署的合约，存储自有代码和状态；而 EIP-7702 的代码注入仅在交易生命周期内有效，之后恢复为普通 EOA。 189 | * EIP-4337 完全兼容现有 EVM 行为，只实现用户态内存池，无需共识层变更；EIP-7702 则需通过硬分叉（如 Pectra）在协议层新增交易类型和授权元组解读。 190 | * EIP-4337 适合通过工厂合约离链创建智能合约钱包，并使用 Paymasters 赞助 Gas；而 EIP-7702 使传统 EOA（热/冷钱包）无需部署独立合约即可获得智能钱包特性。 191 | * 两种标准都支持 Gas 抽象，但 EIP-4337 通过 Paymaster 合约正式化 Gas 赞助（接受 ETH 或 ERC-20 费用），而 EIP-7702 关注通过交易内代码注入提高 Gas 效率。 192 | * 安全模型不同：EIP-4337 已成熟，提供多种插件（如多签、限额、社交恢复）及工厂合约审计模式；EIP-7702 则需确保授权元组安全，防止前置攻击、存储冲突和未授权升级。 193 | 194 | * 支持的智能合约库 195 | 196 | * **eth‑infinitism/account‑abstraction**：EIP-4337 官方参考实现，包含 EntryPoint、StakeManager、ValidationLogic 等核心合约，用于接收并执行 `UserOperation` 对象，并管理账户创建和操作验证。 197 | * **@mev‑boost‑aa/contracts**：针对 MEV Boost 的 ERC-4337 智能合约套件，提供扩展 EntryPoint、Paymaster 和跨链 MEV 收益提取逻辑。 198 | * **@tisaacontracts/contracts**：一组针对 EIP-4337 的 Solidity 合约，包括 Wallet 实现、Factory、EntryPoint 接口和基础 Paymaster 模板。 199 | * **Biconomy SCW Contracts（bcnmy/scw‑contracts）**：Biconomy 智能合约钱包实现，包含 BaseSmartAccount.sol、Proxy.sol、SmartAccountFactory.sol、EntryPoint.sol，支持 ERC-4337 与 ERC-6900。 200 | * **bcnmy/biconomy‑paymasters**：示例级 Paymaster 合约合集，涵盖验证、预付费和自定义资费规则，用于在链上为用户操作赞助 Gas，支持 ERC-20 计费和订阅模式。 201 | * **Mirror‑Tang/Account‑abstraction‑coding‑security‑library**：聚焦 EIP-4337 安全性边界的测试库，提供多种攻击场景测试合约和常见漏洞检出脚本。 202 | * **4337Mafia/awesome‑account‑abstraction**：精选资源仓库，包含多种 Solidity 合约实现（如 EIP-4337、EIP-2718、EIP-6900），并链接至各项目源码。 203 | * **OpenZeppelin EIP‑4337 审计代码**：尽管不是独立库，但 OpenZeppelin 在其博客中审计并引用了 eth‑infinitism 合约，尤其是 EntryPoint 和 StakeManager。 204 | 205 | * 支持的 SDK 206 | 207 | * **@account‑abstraction（UserOp.js）**：EIP-4337 官方 JS 库，用于构建、模拟和发送 `UserOperation` 对象，与 EntryPoint 合约交互。 208 | * **ZeroDev SDK**：支持 EIP-4337 和 EIP-7702，提供智能账户创建、Gas 赞助、批处理交易、代理调用和账户迁移等高级 API。 209 | * **Biconomy SDK**：集成 EIP-4337 Paymasters 和 UserOperations，简化免 Gas 交易、元交易和多签流程的 dApp 接入。 210 | * **Etherspot SDK**：TypeScript 库，简化 EIP-4337 打包、Paymaster 集成、交易赞助及跨链账号抽象。 211 | * **Safe Core SDK（Gnosis Safe）**：JavaScript 库，部署和管理兼容 EIP-4337 的模块化智能账户，内置多签、会话密钥和安全策略插件。 212 | * **Alchemy AA SDK v3.0**：全功能账户抽象 SDK，支持 EIP-4337 和 EIP-6900，提供会话密钥插件、电邮/通行证认证及 viem 客户端集成。 213 | * **Stackup SDK（userop.js）**：开发者工具包，用于生成和打包 `UserOperation` 对象，与 EntryPoint 和 Paymaster 合约交互，并通过 Stackup 基础设施监控操作状态。 214 | * **Argent & Argent X SDKs**：钱包库，内置 EIP-4337 账号抽象，支持社交恢复、每日限额、Gas 赞助及模块化安全功能。 215 | 216 | 217 | ### 2025.05.18 218 | * **`authorizationList` 是什么** 219 | * EIP‑7702 新增交易类型（类型号 `0x04`）的特有字段，用于承载离线签名的授权信息。 220 | * 该列表至少包含一个元组，每个元组代表一次授权；若列表为空或元组格式不符合规范，整个交易将被视为无效。 221 | 222 | * **字段详解** 223 | * **`chain_id`** 224 | * 指定签名时使用的链 ID，用于防止重放攻击。 225 | * 在执行交易时，节点会校验元组中的 `chain_id` 与交易对象中的 `chainId` 字段是否一致。 226 | 227 | * **`address`** 228 | * 代表希望注入并执行的合约部署地址，也称为“Delegate 合约”地址。 229 | * 该地址必须对应一个已部署的合约，并且节点会在执行前将此地址写入 EOA 的代码槽中。 230 | 231 | * **`nonce`** 232 | * 用于标识该授权的顺序，防止同一授权被重复使用。 233 | * 与普通交易的 `nonce` 类似，但独立于 EOA 的交易 `nonce`，专门用于授权管理。 234 | 235 | * **签名部分：`y_parity`、`r`、`s`** 236 | * 三者共同构成 ECDSA 签名的分离格式： 237 | * `r`, `s`：签名的两大数值部分。 238 | * `y_parity`：恢复签名时的恢复位（v 的奇偶性），用于精确还原签名者地址。 239 | * 通过 `ecrecover` 恢复出签名者地址，确保只有合法 EOA 所有者的授权才会生效。 240 | 241 | * **验证流程** 242 | * **格式校验**：节点检查 `authorizationList` 非空，且每个元组包含恰好 6 个元素。 243 | * **边界检查**：元组中数值字段（如 `chain_id`, `nonce`, `y_parity`, `r`, `s`）需在 EIP‑7702 规定的范围内。 244 | * **签名验证**：节点使用 `ecrecover` 对 `(chain_id, address, nonce)` 进行哈希运算并验证签名，恢复出的地址必须与交易目标 EOA 一致。 245 | * **代码注入**：验证通过后，节点将按照 `0xef01 00 || address` 的格式，将合约地址写入 EOA 的代码槽中，使其在后续操作中表现如同合约账户。 246 | * **执行与恢复**：交易执行完成后，节点恢复 EOA 原始代码槽（通常为空），保证账户状态不发生永久改变。 247 | 248 | * **错误情况与边界** 249 | * **空列表**：`authorizationList` 长度为零时，交易直接失效。 250 | * **签名不匹配**：若 `ecrecover` 恢复的地址与目标 EOA 不符，视为无效授权。 251 | * **格式不符**：元组元素数量非 6 或字段类型错误均会导致交易失败。 252 | 253 | * **实践建议** 254 | * **使用可靠库**：优先采用成熟工具（如 ethers.js v6+ 的 `signAuthorization`、`prepareTransaction`）来构建和管理 `authorizationList`，以避免编码错误。 255 | * **严格审计**：仅对已审计的 Delegate 合约地址进行授权，防范恶意或漏洞合约注入风险。 256 | * **权限管理**：对于多重签名场景，合理设置 `nonce` 和签名顺序，防止重放攻击或授权滥用。 257 | 258 | ``` 259 | import { JsonRpcProvider } from "ethers"; 260 | 261 | const provider = new JsonRpcProvider("https://sepolia.infura.io/v3/YOUR_KEY"); 262 | const relayer = new Wallet(RELAYER_KEY, provider); 263 | 264 | // 查询 nonce 265 | const txCount = await provider.getTransactionCount(signer.address); // 用户 EOA 的 nonce :contentReference[oaicite:4]{index=4} 266 | 267 | // 构造 tx 268 | const tx = { 269 | type: 0x04, 270 | chainId: chainId, 271 | nonce: txCount, 272 | maxPriorityFeePerGas: utils.parseUnits("2", "gwei"), 273 | maxFeePerGas: utils.parseUnits("50", "gwei"), 274 | gasLimit: 200000, 275 | to: signer.address, // 通常目标设为自身，EIP‑7702 处理后会执行委托 276 | value: 0, 277 | data: "0x", // 可留空或携带调用 payload 278 | accessList: [], // EIP‑2930 访问列表，可选 279 | authorizationList: [ 280 | [chainId, delegateAddr, authNonce, yParity, r, s] 281 | ], // 我们生成的授权列表 282 | }; 283 | 284 | // 通过第三方 Relayer（付 gas）发送 285 | const receipt = await relayer.sendTransaction(tx); 286 | console.log("交易哈希:", receipt.hash); 287 | ``` 288 | ### 2025.05.19 289 | * **摘要**：Viem 对 EIP‑7702 提供了原生支持，包括在文档与 API 中专门的扩展，使您能够生成并管理授权元组 `(chain_id, contract_address, nonce, y_parity, r, s)`，无需手动构造，即可在链上调用中使用授权列表。 290 | 291 | * **EIP‑7702 扩展位置**： 292 | 293 | * 在官方文档的 “EIP‑7702” 专栏（版本 2.29.4）中详细介绍了该提案及其在 Viem 中的实现。 294 | * EIP‑7702 本身定义了一种新的以太坊交易类型（`0x04`），允许 EOA 将执行权限委托给智能合约，实现批量操作、燃气赞助以及权限委派。 295 | 296 | * **核心动作（Actions）**： 297 | 298 | * **prepareAuthorization**：准备授权数据的哈希输入。 299 | * **signAuthorization**：签名授权并返回已封装的授权元组，直接可用于 `authorizationList`。 300 | 301 | * **辅助工具（Utilities）**： 302 | 303 | * **hashAuthorization**：对授权数据进行哈希计算。 304 | * **recoverAuthorizationAddress**：从授权签名中恢复签名者地址。 305 | * **verifyAuthorization**：验证授权签名的合法性。 306 | 307 | * **集成指南**： 308 | 309 | * **合约调用示例**：展示如何将 `authorizationList` 传递给客户端的 `execute`（或等效）方法，以在 EIP‑7702 上下文中调用合约函数。 310 | * **交易发送示例**： 311 | 312 | ```ts 313 | import { encodeFunctionData } from 'viem' 314 | import { privateKeyToAccount } from 'viem/accounts' 315 | import { walletClient } from './config' 316 | import { abi, contractAddress } from './contract' 317 | 318 | const eoa = privateKeyToAccount('0x...') 319 | const authorization = await walletClient.signAuthorization({ 320 | account: eoa, 321 | contractAddress, 322 | }) 323 | const hash = await walletClient.sendTransaction({ 324 | to: eoa.address, 325 | data: encodeFunctionData({ abi, functionName: 'initialize' }), 326 | authorizationList: [authorization], 327 | }) 328 | ``` 329 | 330 | 提交一个 EIP‑7702 交易，使 EOA 委托合约执行初始化逻辑。 331 | 332 | * **批量与赞助示例**： 333 | 334 | * 准备多个授权以实现原子化多步流程（如 ERC‑20 批准与转账），并可由中继者代付燃气： 335 | 336 | ```ts 337 | const auth1 = await client.signAuthorization({ contractAddress: A }) 338 | const auth2 = await client.signAuthorization({ contractAddress: B }) 339 | const txHash = await client.execute({ 340 | address: eoa.address, 341 | batches: [ /* ... */ ], 342 | authorizationList: [auth1, auth2], 343 | }) 344 | ``` 345 | 346 | 可将多个操作捆绑为一个事务，同时保持私钥离线。 347 | 348 | * **生态系统集成**： 349 | 350 | * **Wagmi**：已将 Viem 的 EIP‑7702 支持上游合并，提供 React Hooks。 351 | * **Foundry & QuickNode**：示例代码展示如何在本地分叉及主网中通过 Viem 客户端测试 EIP‑7702。 352 | 353 | ### 2025.05.20 354 | ![测试中](./images//none/1.PNG) 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | -------------------------------------------------------------------------------- /emailpractice.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍 seashell，在工作之餘學習了 smart contract audit 兩個月，目前嘗試了兩次審計比賽跟一次 codehawk 的 first flight. 11 | 2. 你认为你会完成本次残酷学习吗？ 會 12 | 3. 你的联系方式（推荐 Telegram） https://t.me/emailpractice 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | - What is EIP-7702 ? 21 | EIP-7702 turns every account into a smart contract. 22 | Alone, that’s useless — no user wants to write Solidity. 23 | But with more and more "plugin" being deployed, wallets can really start to be customized : 24 | 25 | ✅ Set transfer limits to prevent hacks 26 | ✅ Pay gas with USDT or any token 27 | ✅ Batch txs, automation, allowlists... 28 | ________________________________________ 29 | - one of EIP-7702's problem 30 | EIP-7702 lets EOAs temporarily act like smart accounts by attaching custom contract code during a single transaction. 31 | 32 | Under the hood, these work via DELEGATECALL. 33 | 34 | That means: 35 | → Your wallet storage is being directly modified by external contracts (plugins). 36 | → Multiple plugins = multiple contracts sharing the same storage space. 37 | 38 | This is one of the biggest blockers to EIP-7702 adoption. 39 | 40 | Solution 41 | a. ERC-7201: it assigns unique storage slots to modules, avoiding collisions by design. 42 | 43 | ________________________________________ 44 | - EIP-7702 is compatible with older implementation of customize transaction ( ERC-4337 ) 45 | 46 | compatible means less pain of adopting newer EIP. that can greatly promote the usage of 7702. 47 | 48 | 前情提要，什麼是 4337? 49 | 同樣都要讓用戶能自訂交易邏輯。 4337 是去工廠去生出符合規範的智能合約，然後智能合約自然而然就能自訂交易邏輯 ; 有點像是EVM本身不予許自訂交易，所以要靠著一個額外的4337智能合約去當中介。 就是 4337 體系送出的交易不是讓 EVM 去驗證的，而是讓一個 bundler 去處理，總之就是盡量繞開EVM。 7702 才是真的去讓EVM接受客製交易 50 | 7702 不是靠著智能合約，而是讓 EOA自己可以在transaction的時候delegate call別人合約的程式碼，進而控制自己的交易邏輯； 51 | 在4337的情境下，用戶為了客製交易需求，不僅需要新部屬一個智能合約，還要把 EOA 的資產轉過去智能合約。 而7702就可以方便的使用原本的帳戶來達成客製交易 52 | 53 | 54 | 而 4337 能與 7702 相容的原因是 55 | EIP-7702 要求 EOA 在transaction的時候填寫的資料規範，與 EIP-4337 的工廠所要求的交易函數格式吻合。 所以EOA所送的交易，也能被 4337 的 bundler 處理。 56 | ________________________________________ 57 | 58 | ### 2025.05.15 59 | auth list可以放很多個，但只有最後一個會生效。 60 | proxy poxy 會怎樣? 講者也還不知道 61 | 62 | 智能合約能做到的功能都能做吧，真的要思考的事情是"插件的來源"，因為目前對 proxy 合約的格式沒有規範，用戶完全可能簽到惡意合約。而且地址是可以做到仿造得很像知名協議的，如果前端的錢包應用沒有主動在簽名的時候提供一些檢查。 比如顯示這個地址是不是知名協議， 7702 對一般用戶是很難使用的，因為要檢查合約地址真的太費神了 63 | 64 | 7702 可能可以做的應用 : 65 | 給這筆交易設一個交易門檻，交易會在 proxy 合約那邊做一些條件檢查，決定要不要revert 這筆交易 66 | 67 | 可以用 proxy 合約來製作 session key。 就是製作一個 被限縮權限，只能做一點事情的 key。 68 | 69 | 7702 不能做的應用: 70 | 自動化交易機器人。 因為transaction 不能持續監聽價格，就是得要直接地把一筆交易完成。 71 | 72 | 給自己設定一個轉帳門檻嗎 讓自己無論如何都只能轉出這麼多錢 : 73 | 自動化每筆交易都delegate call 一個proxy合約來為我檢查。 用其他的技術更實在，7702 就是拿來客製化"單筆"交易的 74 | ________________________________________ 75 | ### 2025.05.16 76 | how to implement 77 | 78 | 參考別人的打包交易實作 https://github.com/defispartan/approve/blob/main/app/actions/Permit.tsx 79 | 但這是一個EIP 5792 交易是送給另一個合約。 到那邊才會用到 7702 的邏輯， delegate call之類的) 看不到 7702 的 delegatecall 的原因：不是自己實作 7702 的錢包邏輯。 80 | 這個repo就負責打包交易送出交易。 81 | 他這邊好像就是送出交易給錢包而已，可能是ㄧ些主流的錢包吧 比如alchemy 或 metamask 然後他們那邊會自動判斷，如果送交易的是EOA 它就會用7702的方式去幫現在的合約進入delegate call 82 | 疑惑 : all batch supply of the repo does is send an EIP-5792 transaction, and the wallet (e.g., MetaMask) handles the 7702 implementation under the hood? 83 | there is no 7702 implementation is this repo right? And that is normal because it is better done by third party wallet? 84 | 85 | actions/BatchSupply.tsx : 86 | 87 | // 一、 先打包資料 88 | 89 | const handleSupply = async () => { 90 | const approveData = encodeFunctionData({ 91 | abi: IERC20_ABI, 92 | functionName: 'approve', 93 | args: [AaveV3Sepolia.POOL,tokenBalance] 94 | }); 95 | const supplyData = encodeFunctionData({ 96 | abi: IPool_ABI, 97 | functionName: 'supply', 98 | args: [AaveV3Sepolia.ASSETS.AAVE.UNDERLYING, tokenBalance, address || '0x0', 0] 99 | }); 100 | 101 | // 二 send call送出交易 sendcalls 會自動調用MetaMask、或其他兼容 EIP-4337 / EIP-7702 的錢包，跳出來讓用戶簽名。 102 | 103 | 下面似乎就等同於 104 | //IERC20(token).approve(poolAddress, tokenBalance); 105 | //pool.supply(token, amount, userAddress, 0); 106 | 107 | sendCalls({ 108 | calls: [ { 109 | to: AaveV3Sepolia.ASSETS.AAVE.UNDERLYING, 110 | data: approveData, 111 | }, 112 | { 113 | to: AaveV3Sepolia.POOL, 114 | data: supplyData, 115 | },], 116 | 117 | // 三、paymaster不知道是怎麼實作的 目前就是看到.env裡面有一個paymaster的連結 118 | 119 | capabilities: { 120 | paymasterService: { 121 | [toHex(chainId)]: { 122 | optional: true, 123 | url: paymasterUrl, 124 | } 125 | } 126 | }, 127 | }) 128 | } 129 | 130 | 131 | 132 | actions/Permit.tsx : await signTypedData({ domain, types, message }) 有提供先讓使用者預先簽名的功能。 這樣使用者如果採用傳統的交易(approve再轉帳)而不是打包交易，那原本會需要用到兩次的 gas fee 。就是先approve，消耗掉一次gas。再交易 。 permit 就是在試著做到鍊下簽名: 我先取得用戶的簽名，然後之後就直接送出交易，不需要預先approve。 付出一次gas fee就好。 133 | 134 | note簽名的內容跟簽名要在一起，一起去生成一組 v r s 135 | note 如果沒有透明顯示簽名內容，使用者以為自己簽了5 token 但實際上簽了100 token 136 | 137 | state/TokenProvider.tsx : 從permit拿到簽名，然後儲存資料在前端瀏覽器(本地)的樣子。 簽名存在這裡， 刪除簽名資料、查看餘額 等等的功能好像也在這個檔案 138 | 139 | ___ 140 | ### 2025.05.17 141 | - 新交易格式：SET_CODE_TX_TYPE（Type = 0x04） 142 | 採用 RLP 編碼，包含以下字段（部分與 EIP-1559 相似）： 143 | 144 | chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit 145 | 146 | destination, value, data, access_list 147 | 148 | authorization_list（新增） 149 | 150 | 簽名字段：y_parity, r, s 151 | 152 | authorization_list 是核心 153 | 必填，非空 154 | 每個授權條目包含 6 個字段： 155 | chain_id: 0 = 可跨鏈重放（需 Nonce 一致） 156 | address: 被委託執行的目標合約地址 157 | nonce: 授權者的當前帳戶 nonce 158 | y_parity, r, s: 授權者對 (chain_id, address, nonce) + magic number 0x05 的簽名（用 keccak256） 159 | 160 | - 一筆交易可以包含多個授權，但： 161 | 同一授權者的多個條目 → 只有最後一個會被使用 162 | 簽名驗證失敗 → 不會使交易失敗，只跳過該條目（防 DoS） 163 | 164 | - 交易與授權分離（支持 Meta-Tx / Gas 贊助） 165 | 交易的 sender（支付 Gas 的人）與授權 signer（真正要執行的人）可以不同。 166 | 167 | 這讓第三方幫你發送交易成為可能，例如： 168 | 169 | 170 | 171 | - 交易執行流程簡述 172 | 驗證 transaction nonce 與 sender 的帳戶匹配 173 | 遍歷 authorization_list，對每條目進行： 174 | 驗簽 175 | 檢查 nonce 176 | nonce 驗證通過 → nonce +1 177 | 178 | 設定授權者的帳戶 code 為 0xef0100 || address 179 | 0xef0100 是委託指示符，address 是目標智能合約 180 | 若 address 為零地址，則清除 code 181 | 最後執行 destination 的 call，但會載入委託 code 執行 182 | 183 | - 委託行為：智能 EOA 184 | 一旦授權成功，該 EOA 會被視為一個「智能 EOA」： 185 | 186 | CALL / DELEGATECALL 等操作，會執行委託合約的代碼 187 | CODESIZE / CODECOPY 取得的是委託合約的 code 188 | EXTCODESIZE / EXTCODECOPY 仍作用於原 EOA 189 | 190 | 禁止多層委託（遞歸） 191 | 192 | - Gas 成本 193 | 內在成本：基於 EIP-2930，外加： 194 | PER_EMPTY_ACCOUNT_COST × 授權條目數量（約 12500 Gas / 條） 195 | 即使授權失敗或重複，也會收取 Gas 196 | 若授權帳戶先前已存在 → 可部分退還 Gas（避免 DoS） 197 | 198 | ### 2025.05.18 199 | 7702 會影響一些 opcode 的行為，像是 delegatecall 和 call 和 static call 200 | 201 | 7702 set account 在被呼叫的情況下，行為和 delegatecall 幾乎雷同 202 | 203 | 所以 204 | 1. 在 wallet: msgsender 是原本的 EOA 205 | 2. delegation contract: msgsender 是原本的 EOA 206 | 3. external call 過去: msgsender 也還是原本的 EOA 207 | 208 | 社交恢復或是批量交易等等的都不是 7702主要的功能，這些之前就有了。 7702提供的就只是 "讓錢包變成可以有更直接使用這些功能的途徑" 209 | 210 | ### 2025.05.19 211 | 安全相關的問題 212 | 213 | 與 EIP-3074 類似處理方式：AUTH + AUTHCALL，但更簡潔直接。 214 | 215 | Bytecode Behavior 深潛 216 | 7702 的核心設計是在交易執行過程中注入 code，即： 217 | 218 | - pre-tx: EOA has no code 219 | - during-tx: 220 | - code is injected at `msg.sender` 221 | - calldata is executed (like a contract call) 222 | - post-tx: code is self-destructed or removed, back to EOA 223 | 在實際操作上，client 會在交易開始前將 tx.origin 設為某段 bytecode，像是： 224 | 225 | 具體 bytecode 是 signer 設定的，可以是靜態 template，也可以是 per-tx injected。這代表任意合約邏輯可以透過 EOA address 暫時存在，但不會永久佔用 code slot。 226 | 227 | 和 EIP-4337 的實際差異 228 | 項目 EIP-4337 EIP-7702 229 | EntryPoint 必須使用 centralized EntryPoint 無需 EntryPoint，直接在 EVM 層發生 230 | Address 使用方式 Contract Wallet（如 SimpleAccount） 傳統 EOA（如 MetaMask address） 231 | 模組化 高度模組化（paymaster, bundler） 自由注入邏輯，但模組化需手動實作 232 | 安全性風險 由 EntryPoint 審查、bundler 驗證 code 注入過程極度自由，風險更高 233 | 234 | EIP-7702 的 code injection 沒有“容錯框架”，安全研究者必須假設 attacker 有完全自由的 execution context。 235 | 236 | ### 2025.05.20 237 | 238 | 缺點 : 239 | Gas Costs: While EIP-7720 introduces efficient mechanisms for deferred transfers, executing multiple scheduled transfers may still incur significant gas costs, especially when dealing with a large number of recipients. 240 | 241 | 242 | Implementation Complexity: Developers need to ensure that the smart contracts handling deferred transfers are secure and free from vulnerabilities, as they manage future token distributions. 243 | 244 | 245 | ### 2025.05.21 246 | 247 | Scheduled Withdrawals: Enables the scheduling of token transfers, facilitating use cases like vesting schedules, delayed payments, or time-locked rewards. 248 | 249 | ### 2025.05.22 250 | note簽名的內容跟簽名要在一起，一起去生成一組 v r s 251 | 252 | note 如果沒有透明顯示簽名內容，使用者以為自己簽了5 token 但實際上簽了100 token 253 | 254 | ### 2025.05.23 255 | 設定授權者的帳戶 code 為 0xef0100 || address 256 | 0xef0100 是委託指示符，address 是目標智能合約 257 | 若 address 為零地址，則清除 code 258 | 259 | ### 2025.07.12 260 | 261 | 262 | -------------------------------------------------------------------------------- /evshary.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | # evshary 6 | 7 | 1. 自我介绍： 8 | Web3 新手，最近對區塊鏈相關知識非常有興趣，想透過殘酷共學跟大家一起學習。 9 | 2. 你认为你会完成本次残酷学习吗？ 10 | 會 11 | 3. 你的联系方式（推荐 Telegram） 12 | t.me/evshary 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | #### 為何需要 EIP-7702 （目前遇到什麼問題） 21 | 22 | 以太坊主要有兩種位址： 23 | 1. EOA (Externally Owned Accounts) 24 | 2. 智能合約帳戶 (Contract Account) 25 | 26 | 在 EIP-7702 之前，EOA 的功能相對簡單，主要是發送交易功能。不能像是智能合約錢包能夠執行程式碼。 27 | 因此使用者必須要先把資產轉移到智能合約錢包，對使用者來說十分麻煩。 28 | 29 | 在 EIP-7702 之後，EOA 就能支援批次交易處理、gas 贊助、或是複雜權限管理，少了一個轉帳的動作。EOA 更加接近抽象帳戶的概念。 30 | 31 | #### EIP-7702 的運作方式 32 | 33 | 1. 使用者用 EOA 創建新的交易類型 34 | 2. 交易中會指定一個智能合約地址，EOA 在該交易中會臨時地像這個智能合約一樣運作 35 | 3. 用 EOA 私鑰簽署交易 36 | 4. EVM 在處理這筆交易時，會臨時地將發送方的 EOA 視為位於指定智能合約地址的合約，並執行該合約地址上的程式碼 37 | 5. 完成交易後，EOA 會回復正常模式 38 | 39 | #### 引入 EIP-7702 的可能風險 40 | 41 | 1. 委託的智能合約如果沒有適當的存取限制，攻擊者可以存取 EOA 內的所有資產 42 | 2. 開發者確保初始化程式碼有正確的執行，不然可能會有邏輯錯誤或是被攻擊者利用 43 | 3. 委託程式碼不會清除現有儲存，因此某些變數在切換合約時可能會遺留舊數據 44 | 4. 過去 EOA 相對來說被認為比較安全，現在也引入了智能合約相關的風險 45 | 46 | ### 2025.05.15 47 | 48 | 學習目標：比較 EIP-4337 和 EIP-6551 49 | 50 | #### EIP-4337 51 | 52 | 完整實現帳戶抽象，允許使用者直接用智能合約帳戶當成自己的以太坊帳戶。 53 | 這些帳戶就如同智能合約可以執行程式，如多重簽名、恢復帳戶等等進階功能。 54 | 55 | * 優點： 56 | * 完整帳戶抽象：使用者可以直接擁有智能合約帳戶的各種進階功能 57 | * 不需要硬分叉：沒有改變以太坊的共識機制 58 | * 缺點： 59 | * 無法無痛移轉：使用者需要創建並管理新的智能合約帳戶 60 | * 複雜性高：智能合約帳戶本身就比 EOA 複雜 61 | * 風險提高：會有智能合約相關的風險 62 | 63 | #### EIP-6551 64 | 65 | 允許 NFT 有自己的智能合約帳戶，也就是 TBA (Token-Bound Account)。 66 | 這樣 NFT 就不再只是收藏品，也有管理資產以及跟其他 DApp 互動的能力。 67 | 這個帳戶由 NFT 的擁有者所控制。 68 | 69 | * 優點： 70 | * 提高 NFT 價值：讓 NFT 能夠管理資產 71 | * 簡化體驗：和 NFT 相關的資產可以一起管理 72 | * 缺點： 73 | * 依賴 ERC-721：只針對 ERC-721 的 NFT 74 | * 風險提高：會有智能合約相關的風險 75 | 76 | #### 小結 77 | 78 | 簡單來說，EIP-7702 是讓使用者最低成本享受到智能合約功能的方式，不像是 EIP-4337 需要重新創個帳戶。 79 | 至於 EIP-6551 則只是針對 NFT，這就是另一個故事了。 80 | 81 | ### 2025.05.16 82 | 83 | #### EIP-7702 實際封包差異 84 | 85 | 在 EIP-2718 前的格式(Type 0, Legacy Transaction)為如下： 86 | [nonce, gasPrice, gasLimit, to, value, data, v, r, s] 87 | 88 | 而在 EIP-2718 之後則引入了 Typed Transactions，允許有多種交易種類。 89 | 當地一個 byte 小於 0x7f，表示是 EIP-2718 定義的 typed transaction，常見有如下幾種： 90 | 91 | * (0x01) Type 1 (EIP-2930 Access List Transaction)：增加 AccessList 欄位 92 | * (0x02) Type 2 (EIP-1559 Transaction): 引入了新的 Gas 費用機制 93 | * (0x03) Type 3 (EIP-4844 Blob Transaction): 用來處理大量的 Blob 數據 94 | * (0x04) Type 4 (EIP-7702): 也就是我們要探討的主角 95 | 96 | 下面是 EIP-7702 的格式： 97 | [chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s] 98 | 99 | 最主要核心是增加了 authorization_list，這個列表，包含了多個 authorization tuples，每個 tuple 有如下資訊 100 | 101 | * chain_id: 鏈的 ID 102 | * address: 被授權執行程式碼的智能合約位置 103 | * nonce: EOA 的 nonce 104 | * y_parity, r, s: 對特定訊息的簽名，用於授權 105 | 106 | destination 不能為空，代表不能是創建合約的交易。另外 authorization_list 也不能為空。 107 | 讓我們用 Gas 贊助的例子來說明 destination 和 authorization_list 的差異： 108 | 109 | 1. EOA 發起 EIP-7702 交易，destination 是目標智能合約、authorization_list 包含 Gas 贊助智能合約的地址 110 | 2. 該 authorization tuples 會包含 EOA 簽名，代表有授權給贊助地址 111 | 3. EVM 會驗證 authorization_list 的 Gas 贊助智能合約 112 | 4. Gas 贊助智能合約會以某種形式為交易支付 Gas 費用 113 | 5. 交易成功送出，原發送者仍為該 EOA，但 Gas 成本由授權合約負擔 114 | 115 | 雖然交易由 EOA 簽名發出，但授權合約可以攔截交易並代為執行、支付 Gas，類似於 Account Abstraction 的使用者操作（UserOperation）行為 116 | 117 | ### 2025.05.17 118 | 119 | EIP-7702 要注意的問題 120 | 121 | * 私鑰仍然需要仔細保管 122 | * 注意簽署 chainID 為 0 的委託，有可能有多鏈重放的問題 123 | * EIP-7702 只有更新位址的 code 欄位，並沒有做初始化 124 | * 如果使用者從 A 合約委託到 B 合約，存儲的結構有可能有變化。所以要確保重新委託後存儲結構是沒有問題。 125 | * 注意假儲值的風險 126 | * 外部合約不能假設發起交易的人都是 EOA，可能是 smart contract 127 | * 開發者要確保跟主流基礎設施兼容 128 | * 釣魚的風險：如果使用者把 EOA 委託給有問題的智能合約，就會有問題 129 | 130 | EIP-7702 可以撤銷授權：把 address 設定為 `0x0000000000000000000000000000000000000000`，就可以把帳戶的 code 欄位變成空 131 | 132 | ### 2025.05.18 133 | 134 | EIP-7702 和 EIP-3074 最主要差別是，前者是一次性事件(該交易生效)，後者則是會持續性生效 135 | 136 | EIP-7702 能夠在交易時讓 EVM 多執行某一段我們想要的邏輯 137 | 138 | 例如 139 | * 遊戲中使用智慧合約帳戶邏輯但仍保留 EOA 地址 140 | * 說明：在遊戲或 DeFi App 中，使用者可以動態地指定交易驗證邏輯來符合遊戲或 App 所需的條件，例如內建的 cooldown 時間或是條件性轉帳。 141 | * 實例： 142 | * 玩家要移動資源，交易會在智慧合約中檢查 cooldown 時間是否已結束 143 | * 玩家交易中加入條件驗證：「如果資源已達到一定量，才能移動」。 144 | * 支援「付款條件」的付款驗證（如 Paymaster） 145 | * 說明：EIP-7702 可以與 Paymaster 模式結合，讓使用者用任意的 token 支付 gas，或在交易中加入複雜條件邏輯（如贊助、後付款）。 146 | * 實例：一次性交易：使用者透過 Paymaster 合約簽章來支付交易費。 147 | * 安全策略臨時更換（如出現異常活動時） 148 | * 說明：若偵測到帳戶異常行為，可以透過 EIP-7702 臨時引入更強的驗證邏輯。 149 | * 實例：自動啟用「多簽 + 指紋驗證」模式。 150 | 151 | 152 | -------------------------------------------------------------------------------- /gardennn.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # Garden 9 | 10 | 1. Hi 我是 Garden 11 | 2. 盡力完成 12 | 3. TG: @gardenxu 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | ### EIP-7702：概念入門與背景脈絡 21 | 22 | #### 為什麼需要帳戶抽象？Account Abstraction 的動機 23 | 24 | 以太坊原生帳戶分為： 25 | - EOA（Externally Owned Account）：傳統錢包，只有私鑰，不能內建邏輯。 26 | - 合約帳戶（Contract Account）：有程式邏輯，可自訂執行規則，但部署後不易修改。 27 | 28 | 帳戶抽象（Account Abstraction）希望打破這個二分法： 29 | - 讓 EOA 也能支援自訂邏輯（如多簽、限額、社交恢復）。 30 | - 支援批次交易、自訂驗簽邏輯、由 DApp 代付 Gas 等功能。 31 | 32 | #### EIP-4337 回顧與限制 33 | 34 | EIP-4337（Account Abstraction via EntryPoint contract）為第一代帳戶抽象方案，其設計包含： 35 | - **Bundler**：收集使用者操作（UserOperation）並統一送出。 36 | - **EntryPoint** 合約：統一處理驗證與執行。 37 | - 支援 `paymaster`（由他人代付 gas）。 38 | 39 | 但也存在限制： 40 | - 需要獨立 mempool，不被所有客戶端支援。 41 | - 執行流程複雜、學習曲線高。 42 | - 不屬於 L1 協議層功能，執行效率與整合有限。 43 | 44 | #### EIP-7702：核心概念與創新 45 | 46 | EIP-7702 是 Vitalik 主導的新提案，核心為： 47 | - 為 EOA 提供 **動態邏輯委派** 的能力。 48 | - EOA 的 `code` 欄位可暫時設定為 `0xef0100 || address`，即指向某個邏輯合約（Delegation contract）。 49 | - 在交易結束後，自動清除 `code` 欄位，回到原始狀態。 50 | 51 | 特色如下： 52 | - 無需 Bundler，直接支援在 L1 上的帳戶抽象。 53 | - 無需在帳戶地址重新部署合約，即可為 EOA 附加執行邏輯。 54 | - 適合批次操作、gas 贊助、動態簽名驗證。 55 | 56 | #### Type 4 新交易格式與比較 57 | 58 | | 類型 | 名稱 | 特點 | 對應 EIP | 59 | |------|------------|------------------------------|-------------| 60 | | 0 | Legacy | 最早期的交易格式 | 無 | 61 | | 1 | EIP-2930 | 支援 `access list` | Berlin | 62 | | 2 | EIP-1559 | 動態 gas 模型（Base Fee） | London | 63 | | 4 | EIP-7702 | 動態附加 delegation 行為 | Pectra | 64 | 65 | Type 4 是 7702 引入的專屬格式，允許一次性附加 delegation code pointer 與 authorization list。 66 | 67 | #### delegation pointer 的格式與意義 68 | 69 | EIP-7702 使用的 delegation pointer： 70 | ``` 71 | 0xef0100 || address 72 | ``` 73 | - `0xef0100` 是 prefix，代表這是一筆 delegation。 74 | - `address` 是被委託的邏輯合約位址。 75 | - 整體構成帳戶 `code` 欄位的內容，讓 EVM 執行時判斷要用 delegatecall 呼叫此地址。 76 | - 此機制使得 EOA 能像 proxy 一樣執行外部邏輯，並保留自身的 storage context、msg.sender、msg.value 77 | 78 | ### 2025.05.15 79 | 80 | ### EIP-7702：Set Code Transaction 81 | 82 | #### Set Code Transaction 概述 83 | 84 | EIP-7702 引入了 Type 4 交易，一種新的交易格式，允許 EOA（Externally Owned Account）將帳戶行為委派給指定的邏輯合約。這是透過 `authorization_list` 欄位實現：該欄位中記錄的簽名授權資訊會讓帳戶的 `code` 欄位被設定為 `0xef0100 || address`，形成 delegation 指示器，使該帳戶具備如同 proxy 的行為能力。 85 | 86 | #### Type 4 交易格式 87 | 88 | Type 4 是基於 EIP-2718 的擴充格式，其交易結構如下： 89 | 90 | ```js 91 | rlp([ 92 | chain_id, 93 | nonce, 94 | max_priority_fee_per_gas, 95 | max_fee_per_gas, 96 | gas_limit, 97 | destination, 98 | value, 99 | data, 100 | access_list, 101 | authorization_list, 102 | signature_y_parity, 103 | signature_r, 104 | signature_s 105 | ]) 106 | ``` 107 | 108 | 其中 `authorization_list` 是由帳戶簽名的一組授權資料，用來指定委派邏輯： 109 | 110 | ```js 111 | authorization_list = [ 112 | [chain_id, address, nonce, y_parity, r, s], 113 | ... 114 | ] 115 | ``` 116 | 117 | #### 授權驗證與 Delegation 設定流程 118 | 119 | 當交易執行前，Ethereum 會依序處理 `authorization_list` 中的每一筆授權： 120 | 121 | 1. 驗證 `chain_id` 是否為 0 或等於當前鏈 ID。 122 | 2. 驗證 `nonce` 是否小於 2^64。 123 | 3. 使用 `ecrecover` 驗證簽章並取得授權帳戶 `authority`。 124 | 4. 驗證該帳戶的 `code` 欄位為空或已有 delegation。 125 | 5. 若條件符合，設定帳戶 `code = 0xef0100 || address`。 126 | 6. 若 `address == 0`，則代表清除 delegation，回復為一般 EOA。 127 | 7. 將 `authority` 的 nonce 增加 1，防止重放攻擊。 128 | 129 | 注意：即便交易邏輯 `revert`，上述 code 設定仍會生效不會被還原。 130 | 131 | #### Delegation 指示器的 EVM 行為 132 | 133 | 當帳戶的 `code` 欄位為 `0xef0100 || address`（23 bytes），EVM 在執行該帳戶時會套用以下邏輯： 134 | 135 | - CALL / CALLCODE / DELEGATECALL / STATICCALL 這些指令，會跳轉至 delegation contract 的邏輯執行。 136 | - 執行邏輯時，仍保有原 EOA 的 `msg.sender`、`msg.value`、storage context。 137 | - CODESIZE / CODECOPY 等會從 delegation contract 讀取實際邏輯。 138 | - EXTCODESIZE / EXTCODECOPY / EXTCODEHASH 則仍讀取原帳戶自身資訊（僅看到 delegation indicator 的 23 bytes）。 139 | 140 | 此機制讓 EOA 擁有像 proxy 合約的能力，但無需部署 smart contract 即可享有抽象帳戶邏輯。 141 | 142 | ### 2025.05.16 143 | 144 | ### EIP-7702：交易流程解析（自我發起與贊助者） 145 | 146 | EIP-7702 的核心在於讓 EOA 在不部署合約的前提下，藉由設定特殊 code delegation（`0xef0100 || address`），具備動態執行邏輯的能力。主要分為兩種交易流程： 147 | 148 | --- 149 | 150 | #### 一、自我發起（Self-sponsored） 151 | 152 | 當 EOA 自身擁有 ETH 且能支付 gas 時，可主動發送 Type 4 交易完成 delegation 與執行邏輯： 153 | 154 | 1. **EOA 自行簽署授權並發送 Type 4 交易** 155 | - 使用者（sender）即 signer，簽署一筆 [chain_id, address, nonce] 的授權資料。 156 | - authorization 格式：`[chain_id, address, nonce, y_parity, r, s]`。 157 | - 簽章的 msg 為 `keccak256(0x05 || rlp(chain_id, address, nonce))`，ecrecover 還原出 authority（即該 EOA），其 code 欄位會被設為 delegation pointer。 158 | 159 | 2. **EVM 處理授權與 delegation 設定** 160 | - 驗證簽章正確、nonce 合理、帳戶 code 必須為空或可覆蓋 delegation。 161 | - 驗證通過後，將該帳戶 code 設為 `0xef0100 || address`，即指向 delegation contract。 162 | 163 | 3. **執行交易 data（call）** 164 | - 若交易目的地址即為 authority，則會觸發代理邏輯（執行 delegation contract 的邏輯，保留原 msg.sender、msg.value、storage）。 165 | - 若 call revert，則交易執行結果會回滾，但 code 設定不會還原。 166 | 167 | --- 168 | 169 | #### 二、贊助者模式（Sponsored） 170 | 171 | 當 EOA 沒有 ETH 或希望他人代付 gas，可採用贊助者模式： 172 | 173 | 1. **使用者簽署離線授權資訊** 174 | - 被授權的 EOA 簽署 [chain_id, address, nonce]，產生簽章（signer 僅用於設定該 EOA 的 code）。 175 | - 簽章的 msg 為 `keccak256(0x05 || rlp(chain_id, address, nonce))`，ecrecover 還原出 authority（即被授權帳戶），其 code 欄位會被設為 delegation pointer。 176 | - 授權中的 nonce 必須匹配該 EOA 當前 nonce，確保每筆 delegation 只能設定一次，無法重放。 177 | 178 | 2. **Sponsor 組合並提交 Type 4 交易** 179 | - Sponsor 僅負責將授權清單（authorization_list）與 call data 組成交易並送出，不參與簽章。 180 | - 可同時包含多筆授權（多個 EOA），以及單一或批次 call data。 181 | - 簽名僅用於設定授權者帳戶的 code，而不是 signer 的帳戶。 182 | 183 | 3. **EVM 處理授權與 delegation 設定** 184 | - 對每筆授權資料，驗證簽章、nonce 是否正確，並檢查該帳戶 code 必須為空或 delegation indicator。 185 | - 若授權資料無效（簽章錯誤、nonce 不符、code 非空），則該筆授權被拒絕，略過不處理。 186 | - 驗證通過者，將其 code 設為 delegation pointer，並將 nonce 增加 1。 187 | 188 | 4. **執行交易主體 call** 189 | - 每筆 call data 會以對應的 delegated EOA 為上下文執行（透過 delegation contract）。 190 | - 若多個授權帳戶共用相同 call data，delegation contract 需根據 `msg.sender` 區分執行邏輯，否則可能導致混淆或資安問題。 191 | 192 | 5. **revert 與批次處理行為** 193 | - 若交易過程中任一筆 call 發生 revert，整體交易會回滾（atomicity preserved）。 194 | - 若僅 delegation 授權失敗（如簽章錯誤、nonce 不符、code 非空），則不影響其他授權與主體 call 的執行。 195 | 196 | --- 197 | 198 | #### 驗證與安全性補充 199 | 200 | - **簽章不可重複使用**：每筆 delegation 授權必須綁定唯一 nonce，只有 nonce 與帳戶當前 nonce 相符時才能設定 delegation。這確保 replay protection。 201 | - **多筆交易含相同簽章會被拒絕**：若多筆交易嘗試重用相同簽章，因 nonce 不符或 code 非空，授權步驟會被拒絕。 202 | - **簽章驗證方式**：`ecrecover(keccak256(0x05 || rlp(chain_id, address, nonce)), y_parity, r, s)` 取得 authority（即被授權帳戶）。 203 | 204 | --- 205 | 206 | 此兩種模式皆允許 EOA 在無需預先部署智能合約的前提下，實現一次性或動態委派自訂邏輯，並配合 L1 交易機制執行，為帳戶抽象提供更原生且彈性的架構。 207 | 208 | ### 2025.05.17 209 | 210 | ### EIP-7702：安全性考量 211 | 212 | #### 常見風險與防範建議 213 | 214 | - **避免使用 `tx.origin` 作為重入保護（Reentrancy Guard）**： 215 | EIP-7702 改變了 `msg.sender == tx.origin` 的判斷方式，建議使用 transient 儲存或標準鎖機制取代 `tx.origin`。 216 | 217 | - **避免使用原子初始化（atomic init）**： 218 | 原子化 `init()` 呼叫可能遭到前置攻擊（frontrunning），建議使用 `initWithSig` 搭配簽章驗證初始化邏輯。 219 | 220 | - **初始化應透過 EntryPoint 呼叫以提升安全性**： 221 | 若採用 4337-compatible 的架構，初始化邏輯應限制由 EntryPoint 呼叫以避免未授權配置。 222 | 223 | - **避免 storage layout 衝突（Storage Collisions）**： 224 | 切換 delegation contract 時應確保使用 ERC-7201 命名空間等機制，避免不同合約之間發生存儲欄位覆蓋。 225 | 226 | - **避免委派至具動態行為的合約（如 upgradeable 或 selfdestruct）**： 227 | 僅應委派至透過 `CREATE2` 部署、不可變的邏輯合約，防止釣魚與意外邏輯改變。 228 | 229 | - **最小化信任基礎與攻擊面（Trusted Surface）**： 230 | Delegation contract 應保持邏輯簡單、功能封閉、可審計，避免動態 dispatch 或不必要的外部呼叫。 231 | 232 | - **選用已審計與可信任的標準合約模組**： 233 | 優先採用來自 Ambire、Alchemy、MetaMask 或 EF 等已知團隊維護並審計過的模組化合約設計。 234 | 235 | ### 2025.05.18 236 | 237 | ### EIP-7702：Delegation 合約的設計原則 238 | 239 | #### 一、設計核心與部署原則 240 | 241 | - 委派合約應透過 **CREATE2 部署**，保證 deterministic address，可預先驗證與靜態指向。 242 | - 合約邏輯應明確不可變，**避免使用 upgradeable patterns 或具毀損性的 selfdestruct**。 243 | - 每個 delegation contract 應對應特定業務目的，避免萬用 dispatch 結構。 244 | 245 | #### 二、簽章驗證與使用者授權綁定 246 | 247 | - 每筆簽章應與交易中實際使用的 **msg.sender、calldata、gas、value、nonce（或 salt）一致**。 248 | - EIP-7702 的簽章驗證格式為：`ecrecover(keccak256(0x05 || rlp([chain_id, address, nonce])), y_parity, r, s)` 249 | - 為提升互通性與安全性，推薦使用 **EIP-712 標準格式** 建立簽章內容。 250 | 251 | #### 三、多使用者支援設計 252 | 253 | - 若允許多帳戶共用 delegation contract，應設計適當資料結構以管理權限，例如： 254 | ```solidity 255 | mapping(address => Permission) public permissions; 256 | ``` 257 | - 可擴充設計如： 258 | - 每個 signer 可被限制僅能呼叫特定函式 selector 259 | - 支援每日限額、可互動的 target contract 白名單等 260 | 261 | #### 四、meta 資訊與風控擴充欄位 262 | 263 | - 建議加入簽章參數： 264 | - `purpose`：明確表示簽章用途（如 mint、transfer） 265 | - `chainId`：防止跨鏈重放攻擊 266 | - `deadline`：簽章過期時間 267 | - 可考慮加上 session ID、防重放 hash、或交易 domain 作為額外驗證。 268 | 269 | #### 五、安全與審計建議 270 | 271 | - 每筆簽章只能用一次，nonce 應與帳戶當前 nonce 精準匹配，避免重複授權。 272 | - delegation 合約實作應通過靜態分析工具（如 Slither）與形式驗證（如 MythX）。 273 | - 請避免動態 dispatch 結構與過多 call、delegatecall，減少潛在攻擊面。 274 | - 設計應符合最小信任原則與模組化（如 OpenZeppelin AccessControl）。 275 | 276 | > EIP-7702 的 delegation contract 並非萬用 proxy，應精確對應特定交易型態或邏輯，實作時宜採 whitelist、限權、風控多層交叉驗證，並以低複雜度、高可審計為原則。 277 | 278 | ### 2025.05.19 279 | 280 | ### EIP-7702 × ERC-4337：整合實作與應用策略 281 | 282 | EIP-7702 提供 L1 原生帳戶抽象功能，不依賴 EntryPoint，設計更輕量且與現有交易邏輯相容；而 ERC-4337 則透過 Bundler 與 EntryPoint 提供 L2 抽象化錢包架構。兩者可互補整合，形成混合型帳戶抽象框架。 283 | 284 | #### 結合方式與應用邏輯 285 | 286 | - **Delegation contract 可實作 `validateUserOp()` 與 `execute()`**，與 ERC-4337 的 EntryPoint 完整對接，實現兼容型帳戶抽象。 287 | - **於 4337 wallet 中引入 delegation pattern**，可支援 fallback recovery、session key、限權交易等彈性機制。 288 | - **EIP-7702 提供 fallback 機制**：若主驗簽失效，可改由 delegation contract 實作 `isValidSignature()` 驗證邏輯。 289 | - **支援二階段授權架構**：簽名與執行行為可由不同 signer 操作，實現授權與使用責任分離。 290 | - **UserOperation 可增設 `delegationProof` 欄位**，提供基於 EIP-7702 授權的額外驗證來源與風控依據。 291 | - **混合模式可依需求分流**：批次處理交由 ERC-4337 處理，細緻操作則由 EIP-7702 進行個別授權。 292 | 293 | #### 優勢總結 294 | 295 | - **組合彈性高**：EIP-7702 可提供 L1 安全且可控的邏輯授權，ERC-4337 提供策略封裝與批次處理功能。 296 | - **安全設計更進階**：fallback 機制讓帳戶擁有多層次驗簽途徑與備援邏輯。 297 | - **未來可建構 Layered Account Abstraction 架構**：4337 為策略與排程層，7702 提供底層 delegation 邏輯與執行控制。 298 | 299 | > EIP-7702 與 ERC-4337 並非對立，而是互補：前者強化 L1 執行安全性與簡潔性，後者擴展錢包行為與批次能力。未來帳戶抽象標準中，EIP-7702 有潛力成為 recovery、fallback、限權 session 的關鍵元件。 300 | 301 | ### 2025.05.20 302 | 303 | ### EIP-7702：交易建構與 Viem 實作 304 | 305 | #### Viem 實作交易流程 306 | 307 | 透過 Viem 發送 EIP-7702 類型（Type 4）的 smart account 交易，流程如下： 308 | 309 | 1. 使用 `signAuthorization()` 對某個 delegation contract 產生簽章。 310 | 2. 建立交易時，將 `to` 設為 **EOA 自己的地址**。 311 | 3. `data` 為呼叫 implementation contract（即代理邏輯合約）的 `execute(calls)` 方法。 312 | 4. 帶入 `authorizationList`，確保授權生效。 313 | 5. 可由自己或 sponsor 代為送出交易（sponsored execution）。 314 | 315 | --- 316 | 317 | #### Viem TypeScript 實作程式碼 318 | 319 | ```ts 320 | import { createWalletClient, http, parseEther } from 'viem'; 321 | import { anvil } from 'viem/chains'; 322 | import { privateKeyToAccount } from 'viem/accounts'; 323 | import { eip7702Actions } from 'viem/experimental'; 324 | import { abi, contractAddress } from './contract'; // Assuming you have already deployed the contract and exported the ABI and contract address in a separate file 325 | 326 | const account = privateKeyToAccount('0x...'); // EOA 的私鑰產生帳戶 327 | 328 | const walletClient = createWalletClient({ 329 | account, 330 | chain: anvil, 331 | transport: http(), 332 | }).extend(eip7702Actions()); // 加入 EIP-7702 擴充功能 333 | 334 | // Step 1: 產生對 implementation contract 的簽章授權 335 | const authorization = await walletClient.signAuthorization({ 336 | contractAddress, 337 | }); 338 | 339 | // Step 2~4: 組裝與送出交易 340 | const hash = await walletClient.sendTransaction({ 341 | to: walletClient.account.address, // 設為 smart account 本身地址 342 | authorizationList: [authorization], 343 | data: encodeFunctionData({ 344 | abi, 345 | functionName: 'execute', 346 | args: [ 347 | [ 348 | { 349 | to: '0xcb98643b8786950F0461f3B0edf99D88F274574D', 350 | value: parseEther('0.001'), 351 | data: '0x', 352 | }, 353 | { 354 | to: '0xd2135CfB216b74109775236E36d4b433F1DF507B', 355 | value: parseEther('0.002'), 356 | data: '0x', 357 | }, 358 | ], 359 | ], 360 | }), 361 | }); 362 | ``` 363 | 364 | #### Flow of EIP-7702 Transaction 365 | ![image](https://github.com/user-attachments/assets/5cf8e323-3ccb-475a-887e-1866b7866c1e) 366 | 367 | ### 2025.05.21 368 | 369 | 🔗 範例來源：https://github.com/quiknode-labs/qn-guide-examples/blob/main/ethereum/eip-7702/src/BatchCallAndSponsor.sol 370 | 371 | ### EIP-7702：範例 Delegation 合約 `BatchCallAndSponsor.sol` 重點筆記 372 | 373 | #### 合約目的 374 | - 作為 EOA 的委派邏輯合約（delegation contract）。 375 | - 支援 batch 呼叫與 sponsor 執行邏輯，符合 EIP-7702 的臨時升級設計。 376 | 377 | #### 簽章邏輯 378 | - 使用 `keccak256(nonce, calls)` 作為簽名內容，搭配 ECDSA 驗證。 379 | - 透過 `ECDSA.recover(...) == address(this)` 驗證該筆操作確實來自該 smart account。 380 | - 使用 `MessageHashUtils.toEthSignedMessageHash(...)` 將 digest 包裝為標準 Ethereum 簽章格式。 381 | 382 | #### 執行方式 383 | - `function execute(Call[] calldata calls)`：僅允許 smart account 自身呼叫。 384 | - `function execute(Call[] calldata calls, bytes calldata signature)`：由 sponsor 呼叫，需附帶離線簽章。 385 | 386 | #### 結構定義 387 | ```solidity 388 | struct Call { 389 | address to; 390 | uint256 value; 391 | bytes data; 392 | } 393 | ``` 394 | - 用於批次執行多筆交易，每筆交易可帶金額與 calldata。 395 | 396 | #### Replay Protection 397 | - 使用 `public nonce` 作為每筆交易的防重放機制。 398 | - 簽章時與執行時皆需驗證 nonce 是否一致，成功執行後自動遞增。 399 | 400 | #### 邏輯拆分 401 | - `_executeBatch()`：處理批次內所有呼叫，包含 nonce 增加與 emit event。 402 | - `_executeCall()`：單筆 call 的具體執行行為。 403 | 404 | #### 事件記錄 405 | - `event CallExecuted(...)`：單筆 call 執行。 406 | - `event BatchExecuted(...)`：整批 call 執行。 407 | 408 | #### 補充 409 | - 合約可收 ETH（實作 `fallback()` 與 `receive()`）。 410 | - 本範例合約為「單帳戶專用」，如需多人共用應加入 mapping 權限管理。 411 | - 該合約設計簡潔明確，為理解 EIP-7702 delegation 機制的重要範例，實作可直接用於 Foundry 測試與 Viem integration。 412 | 413 | ### 2025.05.22 414 | 415 | ### Delegation 合約：呼叫流程與可擴充設計 416 | 417 | Delegation 合約內部的執行邏輯，觀察其批次執行與授權流程，並思考延伸可能性。 418 | 419 | #### 執行流程解析： 420 | 421 | - 使用 `execute(Call[] calldata calls)` 批次執行多筆交易，每筆 call 包含 `to`, `value`, `data`。 422 | - 驗證是否由合約自身（即原始帳號）呼叫，拒絕未授權 sender。 423 | - 批次執行採原子處理，任何一筆失敗則全部 revert，符合 EVM 原生特性。 424 | - replay protection 透過 `public nonce` 控制簽名唯一性。 425 | 426 | #### 可擴充性想法： 427 | 428 | - 將執行權限做更多元限制： 429 | - 僅允許特定 function selector 430 | - 限制執行時間（timestamp） 431 | - 限定最大轉帳金額 432 | - 加入 mapping 結構管理多個使用者 session key 權限，支持 whitelist 模式。 433 | 434 | > 透過乾淨封裝的執行流程，加上簡潔的 nonce 驗證，可以讓 delegation 合約具備彈性同時保有安全性基礎。 435 | 436 | ### 2025.05.23 437 | 438 | ### Delegation 合約：安全實踐與風險應對 439 | 440 | 進一步檢視 `BatchCallAndSponsor.sol` 的安全細節與潛在防禦措施，針對真實部署場景整理幾點關鍵觀察。 441 | 442 | #### 安全機制重點： 443 | 444 | - 簽名驗證結合 nonce 與 call digest，確保操作不可重複。 445 | - sponsor 執行版本需提供離線簽名，僅允許驗證後才執行。 446 | - 僅限合約自身觸發內部批次邏輯，避免外部任意操控。 447 | 448 | #### 攻擊場景與防範： 449 | 450 | - **無授權檢查的 call dispatch**： 451 | - 必須針對 caller 做嚴格 `msg.sender` 限制。 452 | - **儲存空間衝突風險**： 453 | - 若日後切換 delegation contract，應使用明確 slot 規劃（如 ERC-7201）。 454 | - **session key 撤銷機制**： 455 | - 設計 revoke function，可一鍵取消所有已簽 session key 授權。 456 | 457 | #### 延伸應用： 458 | 459 | - 搭配 DApp 可支援「限時自動簽名」與「臨時登入快取」模式。 460 | - 若加入 event tracking，可針對授權操作做鏈上證明，利於合規審查。 461 | - 能夠搭建成簡易 smart middleware，成為一種「帳號外掛系統」。 462 | 463 | > Delegation 合約的風險來自於**行為邊界不清楚**。若能夠從一開始就對執行者、資料與時間設限，則該合約可作為安全且高度可控的 Smart EOA 邏輯中繼層。 464 | 465 | -------------------------------------------------------------------------------- /gpteth.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍 11 | 2. 你认为你会完成本次残酷学习吗？ 12 | 3. 你的联系方式（推荐 Telegram） 13 | 1. Alan 工作经验: 5年 14 | 技术栈: Solidity Golang 15 | 16 | 多年web3智能合约开发经验，用Solidity开发过EVM生态DEFI、 NFT 、Dapp，对web3特别感兴趣 17 | 2. 会完成 18 | 3. @JudasLuo 19 | 20 | ## Notes 21 | 22 | 23 | 24 | ### 2025.05.14 25 | 以太坊區分兩種帳戶類型： (1) Externally Owned Accounts (EOAs) 外部擁有帳戶; (2) Smart Contract Accounts 智能合約帳戶。 26 | EIP 7702 提議允許 EOA(外部擁有帳戶) 擁有程式碼。此變更將使以太坊更接近帳戶抽象化，透過允許 EOA 批次處理操作、實作原生多重簽名或替代簽名方案，但也引入了新的安全風險，如果實作沒有經過仔細設計和審計。 27 | EIP 7702 的核心是引入一種新的交易類型，允許帳戶在自身上設定和委派程式碼。它不是直接將完整的合約程式碼儲存在帳戶上，而是儲存一個委託指示符 delegation designator，它是一個特定的前綴，後跟一個地址 ( (0xef0100 || address) )，這個指標指示實際的智能合約程式碼在鏈上的位置。簡單來說，錢包將指向一個鏈上的智能合約，而該合約的邏輯決定了帳戶的行為方式。 28 | EIP 7702 代表了以太坊帳戶模型的一個重大演變。透過允許 EOA 納入程式碼，它開啟了更豐富功能的可能性，例如批次交易、gas 贊助和可自訂的邏輯。然而，這種增加的靈活性是以增加攻擊面為代價的，其中存在許多潛在的漏洞。 29 | 開發人員在將此 EIP 整合到其協議之前需要考慮的風險: (1) 缺乏存取控制; (2) 初始化挑戰; (3) 儲存體衝突。 30 | 31 | ### 2025.05.15 32 | EIP-7702 引入了一種新的交易類型，允許外部擁有帳戶 (EOA) 指定一個地址作為指向其實現的指標。例如，這個地址可以是一個通用的代理或最小代理合約，將呼叫訊息轉發到一個可升級的錢包實現。 33 | 34 | EIP-7702 有效地將 EOA 升級為像智能合約錢包一樣運作，為 EOA 使用者解鎖了可程式性和可組合性，並啟用了以下功能： 35 | (1)社交恢復：EIP-7702 支援 EOA 使用者的社交恢復。這對於害怕遺失私鑰的使用者特別有利，他們只需透過簡單的社交恢復設定即可克服這個問題。 36 | (2)交易批次處理：使用者可以透過擺脫傳統的 ERC-20 代幣「批准和轉帳」兩步驟授權模型，或進一步批次發送轉帳，來簡化交易流程。 37 | (3)交易贊助：使用者可以將交易執行和 gas 費用支付延遲給第三方，例如排序器或錢包伺服器。此功能為可能沒有用於 gas 支付的原生代幣的使用者提供了便利。 38 | (4)任意簽署金鑰：錢包可以利用各種金鑰類型（例如 WebAuthn、P256、BLS 等）來驗證操作，從而在設計空間中提供更大的靈活性。 39 | (5)會話金鑰：使用者可以將具有生命週期和範圍權限的會話金鑰委託給金鑰託管服務，從而實現訂閱模式。此外，使用者可以在受限制的「沙盒」環境中與 DApp 互動，透過防止惡意行為者存取其完整的錢包或資產，顯著降低網路釣魚攻擊的風險和影響。 40 | (6)自定義 gas 代幣、多重簽名方案的權限控制等等… 41 | 42 | 透過 EIP-7702，從 EOA 的角度來看，ETH 餘額現在不僅可以透過簽署的交易減少，還可以透過觸發合約執行的交易減少。從智能合約的角度來看，EOA 可以直接發送交易來更改帳戶狀態。這引入了以下考量： 43 | (1)過去，EOA 只能透過簽署交易發送 ETH，這使得交易池可以透過檢查新區塊中發送者的餘額來使發送者餘額不足的待處理交易失效。然而，透過 EIP-7702，委派的程式碼可以隨時修改 EOA 的餘額，這使得這種不變性不相容，需要重新考慮相關的交易池邏輯。 44 | (2)EIP-7702 錢包實作不能依賴本地維護的不變性，並且必須查詢真實的帳戶狀態，因為 EOA 可以隨時發起交易來改變他們的餘額。 45 | 46 | ### 2025.05.16 47 | 儘管智能合約錢包生態系統取得了巨大進展，但 EOA 阻礙了跨應用程式的 UX 改善的廣泛採用。因此，EIP-7702 著重於為 EOA 增加短期功能改進，這將使 UX 改善滲透到整個應用程式堆疊中。EIP-7702 圍繞設計的三個特定功能是： 48 | (1)批次處理：允許來自同一使用者的多個操作在一個原子交易中進行。一個常見的例子是 ERC-20 批准，然後花費該批准。這是 DEX 中常見的工作流程，目前需要兩筆交易。批次處理的高級用例偶爾涉及依賴關係：第一個操作的輸出是第二個操作的輸入的一部分。 49 | (2)贊助：帳戶 X 代表帳戶 Y 支付交易費用。帳戶 X 可以因這項服務而獲得一些其他 ERC-20 的支付，或者它可以是免費包含其使用者交易的應用程式營運商。 50 | (3)權限降級：使用者可以簽署子金鑰，並授予它們比全域存取帳戶弱得多的特定權限。例如，花費 ERC-20 代幣但不花費 ETH 的權限，或每天花費不超過總餘額的 1% 的權限，或僅與特定應用程式互動的權限。 51 | 52 | ### 2025.05.17 53 | EIP-7702：為單一交易設定 EOA 帳戶程式碼新增一種新的交易類型，可以在一次交易執行期間設定 EOA 的程式碼。 54 | 此 EIP 引入了一種新的交易類型，允許外部擁有的帳戶 (EOA) 在一次交易中擁有智能合約代碼。 55 | 簡單來說，在執行此類型的交易期間，EOA 將充當智能合約/智能錢包，並且在交易執行後，它將變回沒有代碼的原始 EOA。 56 | ![image](https://github.com/user-attachments/assets/6c73f409-4377-4299-a1bf-eb20b2ef01b4) 57 | 58 | EOA 使用者錢包簽署 contract_code 並在交易中提供簽名。驗證此簽名後， contract_code 會儲存在 EOA 中，並且在整個交易過程中，它會像一個智能合約一樣運作。交易執行後，程式碼會被清空，而 EOA 再次像普通帳戶一樣運作。 59 | EOA 在交易期間升級為「supercharged EOAs」。 60 | 61 | 62 | ### 2025.05.18 63 | 64 | 65 | -------------------------------------------------------------------------------- /helloworldsmart.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | # helloworldsmart 5 | 6 | 1. 自我介绍 Michael，希望自己按時學習 7 | 2. 你认为你会完成本次残酷学习吗？ 會的 8 | 3. 你的联系方式（推荐 Telegram 9 | 10 | ## Notes 11 | 12 | 13 | 14 | ### 2025.05.14 15 | 16 | # [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) Introduction 17 | 18 | EIP-7702 is an Ethereum Improvement Proposal introduced by Vitalik Buterin in 2024. Its goal is to improve the user experience and security related to **Account Abstraction**, particularly addressing the challenges of transforming **Externally Owned Accounts (EOAs)**. 19 | 20 | --- 21 | 22 | ### Core Concept 23 | 24 | EIP-7702 proposes a new approach that allows a traditional EOA (e.g., a regular Ethereum wallet address) to **temporarily act as a smart contract account within a specific transaction**, enabling it to leverage account abstraction functionalities (such as custom verification logic, alternative gas payment methods, batch transactions, etc.). 25 | 26 | --- 27 | 28 | ### How It Works 29 | 30 | EIP-7702 introduces: 31 | 32 | #### `tx.accountCode` Field 33 | 34 | A new transaction field that specifies the contract code the user wants their address to temporarily execute during the transaction. 35 | 36 | * This code is deployed to the address before transaction execution. 37 | * Once the transaction is completed, the code is automatically removed, and the address reverts to a pure EOA state. 38 | 39 | --- 40 | 41 | ### Advantages over EIP-4337 42 | 43 | | Feature | EIP-4337 | EIP-7702 | 44 | | ------------------------------------------- | ----------------------------------- | ----------------------------------- | 45 | | Model | Full simulation on Layer 2 | Modifies L1 native EOA behavior | 46 | | Requires Paymaster / Bundler | Yes | Not necessarily | 47 | | User Sovereignty | Contract account created by factory | User retains their original address | 48 | | Support for Cold Wallets / External Signers | More complex | Simpler | 49 | | Miner-Friendliness | Poor (non-native) | Native transaction support | 50 | 51 | --- 52 | 53 | ### 📌 Use Cases 54 | 55 | * Users can use their existing EOA wallet address to temporarily perform actions like: 56 | 57 | * Multi-step transactions (e.g., DEX swap + NFT minting) 58 | * Custom gas payment logic 59 | * ZK proof-based signature replacement 60 | * After the transaction, the address reverts back to a normal EOA without becoming a permanent smart contract account. 61 | 62 | 63 | 64 | ### 2025.05.15 65 | 66 | 67 | -------------------------------------------------------------------------------- /images/alex/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/EIP-7702/d3c6b6a8d742eab7f10fea6a8e8251082ee02fea/images/alex/image1.png -------------------------------------------------------------------------------- /images/alex/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/EIP-7702/d3c6b6a8d742eab7f10fea6a8e8251082ee02fea/images/alex/image2.png -------------------------------------------------------------------------------- /images/alex/image3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/EIP-7702/d3c6b6a8d742eab7f10fea6a8e8251082ee02fea/images/alex/image3.png -------------------------------------------------------------------------------- /images/alex/image4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/EIP-7702/d3c6b6a8d742eab7f10fea6a8e8251082ee02fea/images/alex/image4.png -------------------------------------------------------------------------------- /images/none/1.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/EIP-7702/d3c6b6a8d742eab7f10fea6a8e8251082ee02fea/images/none/1.PNG -------------------------------------------------------------------------------- /jameelovecat.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # Jamee 9 | 10 | 1. 自我介绍：看到这个介绍的伙伴幸会了，我叫Jamee，目前是在做Web3市场营销、产品运营相关的事情，平时也比较关注趋势和技术的重大更新迭代，但一般是阅读别人写好的研报，这次刚好看到朋友发的共学营，我想可以参加进来，从一手的资料开始来学习、思考这次以太坊的技术升级可能带来的影响以及应用的场景。 11 | 2. 你认为你会完成本次残酷学习吗？100% 12 | 3. 你的联系方式（推荐 Telegram）：X: @Jamee_future 13 | Telegram: @jamee_future; 14 | 15 | ## Notes 16 | 17 | 18 | 19 | ### 2025.07.11 20 | 21 | 笔记内容 22 | 23 | ### 2025.07.12 24 | 25 | 26 | -------------------------------------------------------------------------------- /jjeejj.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | # 奕 8 | 9 | 1. 自我介绍：一位向往自由的 web3 开发者 (Node.js、Golang、Solidity 等) 10 | 2. 你认为你会完成本次残酷学习吗？ 会 11 | 3. 你的联系方式（推荐 Telegram）@iyi_jiang 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.07.11 18 | 19 | 笔记内容 20 | 21 | ### 2025.07.12 22 | 23 | 24 | -------------------------------------------------------------------------------- /k66.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | # k66 6 | 7 | 1. 自我介绍: Hi我是k66 8 | 2. 你认为你会完成本次残酷学习吗？ 會 9 | 3. 你的联系方式（推荐 Telegram）k66 10 | 11 | ## Notes 12 | 13 | 14 | 15 | ### 2025.05.14 16 | > 讀[EIP-7702 Attack Surfaces: What Developers Should Know](https://www.nethermind.io/blog/eip-7702-attack-surfaces-what-developers-should-know) 17 | + Ethereum帳戶分2種: EOAs(Externally Owned Accounts)和智能合約帳戶(Smart Contract Accounts) 18 | + EOAs: 由私鑰管理，常見就MetaMask 19 | + Smart Contracts Accounts: 擁有code能執行複雜操作的帳戶 20 | + `EIP-7702讓EOA擁有code` 21 | 22 | ### 2025.05.16 23 | + 續讀[EIP-7702 Attack Surfaces: What Developers Should Know](https://www.nethermind.io/blog/eip-7702-attack-surfaces-what-developers-should-know) 24 | + EIP-7702是一種新的交易型態，致力於讓帳戶可以code on themselves 25 | + a delegation designator, which is a specific prefix followed by an address ((0xef0100 || address)), This pointer indicates where the actual smart contract code resides on-chain. 26 | + 新的交易型態: 27 | + 一串簽署list: A list of authorization tuples(chain ID, 合約佈署的地址, nonce, signature) 28 | + Delegation機制: 貼(附上)code至EOA，這樣帳戶就能執行進階操作 29 | + 如此做法讓EOA像是種智能帳戶，但一旦EOA的私鑰被compromised則駭客能拿到帳戶的完整權限。 30 | + 和EIP-4337的比較 31 | + 資安風險與漏洞 32 | + 多個錢包同時指向同一個deligation designator contract 33 | + 可以從一個deligation重新委託至另一個 34 | + EOA的擁有者可以用delegating to address(0)使得clear the code，這將會使EOA還原。 35 | 36 | 37 | 38 | -------------------------------------------------------------------------------- /kevinsslin.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | # Kevin Lin 5 | 6 | 1. 自我介绍：我是 Kevin，來自台灣，喜歡學習 DeFi 並分享 7 | 2. 你认为你会完成本次残酷学习吗？：會的會的 8 | 3. 你的联系方式（推荐 Telegram）：[@kevinsslin](https://t.me/kevinsslin) 9 | 10 | ## Notes 11 | 12 | 13 | 14 | My Heptabase Note: [link](https://app.heptabase.com/w/28a395444dcaebbd4181a8f86d4205173faa4458527483662c126a7fae3146a7) 15 | 16 | ### 2025.05.14 17 | 18 | see below 19 | 20 | ### 2025.05.15 21 | 22 | # EIP-7702 Proposal Note 23 | 24 | ## One-Sentence Summary 25 | EIP-7702 enables Externally Owned Accounts (EOAs) to set their own code via a special transaction, allowing them to act like smart contract wallets by delegating execution to a contract address. 26 | 27 | ## Motivation: Three Core Features 28 | - **Batching**: Perform multiple operations (e.g., ERC-20 approve + transfer) in a single atomic transaction. 29 | - **Sponsorship**: Allow a third party (like a DApp or relayer) to pay gas fees on behalf of a user. 30 | - **Privilege De-escalation**: Enable sub-keys with limited permissions (e.g., only spend a specific token, set daily limits, or restrict to certain apps). 31 | 32 | ## EIP-2718 "Set Code Transaction" Structure 33 | - **TransactionType**: `SET_CODE_TX_TYPE` (`0x04`) 34 | - **TransactionPayload**: 35 | ```solidity 36 | rlp([ 37 | chain_id, 38 | nonce, 39 | max_priority_fee_per_gas, 40 | max_fee_per_gas, 41 | gas_limit, 42 | destination, 43 | value, 44 | data, 45 | access_list, 46 | authorization_list, 47 | signature_y_parity, 48 | signature_r, 49 | signature_s 50 | ]) 51 | ``` 52 | - **authorization_list**: 53 | ```solidity 54 | [ 55 | [chain_id, address, nonce, y_parity, r, s], 56 | ... 57 | ] 58 | ``` 59 | - Each tuple is a signature authorizing the EOA (authority) to delegate to a contract (address). 60 | - `authority = ecrecover(msg, y_parity, r, s)` 61 | - `msg = keccak(MAGIC || rlp([chain_id, address, nonce]))` 62 | - The outer transaction fields follow the same semantics as EIP-4844. 63 | - The transaction signature (`signature_y_parity`, `signature_r`, `signature_s`) is over `keccak256(SET_CODE_TX_TYPE || TransactionPayload)`. 64 | - **ReceiptPayload**: 65 | ```solidity 66 | rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]) 67 | ``` 68 | 69 | ## Delegation Indicator 70 | - Uses the banned opcode `0xef` (from EIP-3541), so the EVM treats the code as a delegation pointer, not regular code. 71 | - Format: `0xef0100 || address` 72 | - When called, the EVM loads and executes the code at `address` in the context of the EOA (authority). 73 | 74 | ## Misc 75 | - If transaction execution fails (e.g., revert), the delegation indicator is not rolled back — the delegation remains. 76 | - To change or remove delegation, send a new EIP-2718 transaction (set to a new contract or to the zero address to revert to a normal EOA). 77 | - During delegated execution, `CODESIZE` and `CODECOPY` behave differently from `EXTCODESIZE` and `EXTCODECOPY` on the authority. 78 | - For example, when executing a delegated account: 79 | - `EXTCODESIZE` returns 23 (the size of `0xef0100 || address`) 80 | - `CODESIZE` returns the size of the code residing at the delegated address 81 | 82 | ## Breaking Invariants 83 | - `tx.origin == msg.sender` is only true in the topmost execution frame. 84 | - This breaks some legacy patterns: 85 | - Ensuring `msg.sender` is an EOA (no longer reliable) 86 | - Protecting against atomic sandwich attacks (bad practice anyway) 87 | - Preventing reentrancy (rarely used for this purpose) 88 | 89 | ## Security Considerations 90 | - **Storage Management**: Delegated contracts should avoid storage collisions (e.g., use ERC-7201 Storage Namespaces). 91 | - **Replay Protection**: Delegated contracts should implement their own nonces and signature checks. 92 | 93 | ## References 94 | - [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702) 95 | - [EIP-2718: Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718) 96 | - [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) 97 | - [EIP-3541: Reject New Contracts Starting with the 0xEF Byte](https://eips.ethereum.org/EIPS/eip-3541) 98 | - [ERC-7201: Namespaced Storage Layout](https://eips.ethereum.org/EIPS/eip-7201) 99 | 100 | ### 2025.05.16 101 | 102 | ### 2025.05.17 103 | 104 | # 🔍 A Deep Dive into EIP-7702 with Best Practices 105 | 106 | > **Speaker:** Kong (Leader of Security Audit Team) 107 | > [Original Video](https://www.youtube.com/watch?v=uZTeYfYM6fM) 108 | 109 | --- 110 | 111 | ## 📌 Recap & Additional Notes of EIP-7702 112 | 113 | * **Chain ID Replay**: 114 | 115 | * 若將 `chainId` 設定為 `0`，可以在所有支持 EIP-7702 的鏈上進行 replay。 116 | * 對錢包服務商友善，僅需用戶簽署一次鏈下簽名即可在所有鏈上創建智能合約錢包。 117 | 118 | * **交易與授權分離**: 119 | 120 | * 交易的發起者（付 gas fee）和交易的授權者（鏈下簽名者）可以是不同人，實現 gas fee 的代付。 121 | * 同一交易中同一地址的多個授權規則中，只有最新的一條會被應用。 122 | 123 | * **Address Creation Limitations (EIP-3541)**: 124 | 125 | * 開發者無法使用 `new`, `create`, `create2` 等方式創建以 `0xef` 開頭的地址。 126 | 127 | --- 128 | 129 | ## 🚩 Best Practices 130 | 131 | ### 1. 🔑 Private Key Management 132 | 133 | * 即使透過 EIP-7702 可實現如 social recovery 等私鑰遺失的方案，但私鑰仍具最高權限，能重新 delegate 給其他地址。 134 | * 私鑰管理仍極為重要，應設計嚴謹的保護機制。 135 | 136 | ### 2. 🔄 Multi-chain Replay Risks 137 | 138 | * 將 `chainId` 設為 `0` 啟用多鏈 replay，需注意不同鏈上同一地址的智能合約代碼可能不同，存在潛在安全風險。 139 | 140 | ### 3. 🚧 Atomic Initialization and Delegation Issues 141 | 142 | * EIP-7702 不允許在單一交易中同時進行 delegate 和合約初始化（no initcode）。 143 | * 存在搶跑（front-run）攻擊風險，應分開處理 delegation 與 initialization。 144 | 145 | ### 4. 📦 Storage Management 146 | 147 | * Delegation 切換可能引發 storage conflict，建議： 148 | 149 | * for user: 在 re-delegate 前將資金提取以避免損失。 150 | * for dev: 採用 [ERC-7201 Storage Namespaces](https://eips.ethereum.org/EIPS/eip-7201) 分隔儲存空間。 151 | * for wallet service provider: 利用 [ERC-7779](https://eips.ethereum.org/EIPS/eip-7779) 檢查儲存相容性並清理舊的儲存資料。 152 | 153 | ### 5. 🚨 False Top-up 防範 154 | 155 | * 隨著智能合約錢包增多，交易所可能遭遇更多智能合約 deposit 的情況。 156 | * 建議透過交易追蹤（tracing）防止 false top-up 攻擊（[詳細說明](https://slowmist.medium.com/how-does-the-false-top-up-attack-break-through-the-defense-of-the-exchange-d6e8ebb434f5)）。 157 | 158 | ### 6. 🔄 Account Conversion (EOA ↔ CA) 159 | 160 | * EOA 和智能合約帳戶（CA）之間的轉換可能，使得 `msg.sender == tx.origin` 的假設失效。 161 | * 開發者不應再假設交易發起者一定是 EOA。 162 | 163 | ### 7. ✅ Contract Compatibility 164 | 165 | * Delegated contract 須確認與各種 token 或協議的相容性，例如 ERC-721 NFT 需要實作 `onERC721Received()` callback。 166 | 167 | ### 8. 🎣 Phishing Risks 168 | 169 | * EIP-7702 的鏈下簽名授權將使釣魚攻擊更容易執行。 170 | * 錢包服務提供商應詳盡提醒用戶授權合約的詳細資訊以防範攻擊。 171 | 172 | --- 173 | 174 | ### 📖 Sources & Further Reading 175 | 176 | * [EIP-7702 Official Documentation](https://eips.ethereum.org/EIPS/eip-7702) 177 | * [EIP-3541 Details](https://eips.ethereum.org/EIPS/eip-3541) 178 | * [ERC-7201: Storage Namespaces](https://eips.ethereum.org/EIPS/eip-7201) 179 | * [ERC-7779 Storage Compatibility Checks](https://eips.ethereum.org/EIPS/eip-7779) 180 | * [SlowMist's False Top-up Explanation](https://slowmist.medium.com/how-does-the-false-top-up-attack-break-through-the-defense-of-the-exchange-d6e8ebb434f5) 181 | 182 | ### 2025.05.18 183 | 184 | check in first lolll 185 | 186 | 187 | 188 | 189 | -------------------------------------------------------------------------------- /keylen.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. web3开发者，探索7702的更多想象... 11 | 2. 不好说 12 | 3. tg:Keylen3_14 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.5.14 19 | 20 | - 研读okxwallet的钱包实现 https://etherscan.io/address/0x80296FF8D1ED46f8e3C7992664D13B833504c2Bb#code 21 | - 在本地实现了sender指定多笔交易的交易构建与前端交互（不过目前没有实现拉起钱包交互） 22 | - 参考资料：https://learnblockchain.cn/article/11498 23 | -------------------------------------------------------------------------------- /kris77z.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍: Kris Jiang，Web3创业公司产品经理，努力丰富自己技术方面的知识，享受coding。 11 | 2. 你认为你会完成本次残酷学习吗？ 會 12 | 3. 你的联系方式（推荐 Telegram） kris jiang 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | 21 | ### 2025.05.15 22 | 23 | EOA账户： 24 | 25 | 1. 由私钥控制。拥有私钥的人可以完全控制该账户及其中的资产，并可以发起交易 26 | 2. 没有与之关联的智能合约代码。它们的功能仅限于发送和接收交易 27 | 3. 可以直接发起交易 28 | 4. 安全性完全依赖于私钥的保护。私钥一旦丢失或泄露，账户中的资产将面临风险 29 | 30 | SC账户： 31 | 32 | 1. 由智能合约代码控制。账户的行为和资产管理逻辑在合约中预先定义。账户的控制权可以由多个密钥或账户共同管理（例如多重签名） 33 | 2. 包含与之关联的智能合约代码，这些代码定义了账户的功能和规则 34 | 3. 不能直接发起交易。所有相关的操作都需要由 EOA 发起一笔交易来调用 SC 的智能合约代码 35 | 4. Gnosis Safe 等多重签名钱包是典型的 SC 36 | 5. 安全性取决于智能合约代码的安全性以及控制权的管理方式。通过多重签名等机制，可以提高账户的安全性。 37 | 6. 可以实现比 EOA 更复杂的功能，例如：多重签名、交易限额、交易撤销、Gas 费代付、账户恢复、批量交易 38 | 39 | EIP-7702 旨在通过允许 EOA 在单笔交易中临时具备智能合约功能，从而显著提升用户体验 。核心目标是弥合当前 EOA 的简洁性与 SC 的功能（如 gas 赞助、交易批量处理和账户恢复）之间的差距 。EIP-7702 的提出与以太坊长期致力于实现原生账户抽象（AA）的目标相一致，并与 EIP-4337 和 EIP-6551 等其他相关提案形成互补 。 40 | 核心思想是在单笔交易的持续时间内，赋予 EOA 临时的智能合约能力 。通过这种方式，现有的 EOA 可以像智能合约账户一样运作，完成特定的交易后再恢复到其原始状态 。 41 | 临时性的智能合约有意地限制了 SC 功能的持续时间，与那些赋予账户长期控制权的提案不同，EIP-7702 将增强的功能限定在单笔交易之内，这些都极大增强了安全性。 42 | 43 | ### 2025.05.16 44 | 45 | EIP-7702 特性： 46 | 47 | 1. 批量处理 (Batching): 允许用户在单笔原子交易中执行多个操作。一个常见的例子是，用户可以在一笔交易中完成批准 ERC-20 代币的使用和实际花费该批准额度的操作 。   48 | 2. 赞助 (Sponsorship): 允许一个账户（X）为另一个账户（Y）的交易支付 gas 费用。这有助于实现应用程序为其用户支付交易费用，或者用户使用其他代币支付服务费用的场景 。   49 | 3. 权限降级 (Privilege De-escalation): 允许用户创建和签署具有特定、有限权限的子密钥，而不是授予对其账户的完全访问权限。例如，一个子密钥可能仅被授权花费特定类型或特定数量的代币，或者仅能与特定的应用程序进行交互 。   50 | 51 | EIP-7702 的设计原则 :   52 | 53 | 1. 代码委托的持久性 (Persistence of Code Delegation): 代码委托在交易完成后仍然存在。这种设计旨在增加用户频繁部署新的、独特的委托的成本，从而鼓励围绕智能合约钱包统一用户体验的改进，而不是创建相互竞争的“EOA 脚本”。 54 | 2. 无初始化代码 (No Initcode): EIP 有意避免引入初始化代码（在合约创建期间执行的代码）。这简化了设计，降低了测试的复杂性，并防止 EOA 获得超出标准智能合约钱包的独特执行能力。这也鼓励对于更复杂的初始化需求使用完整的智能合约钱包解决方案 。   55 | 3. 通过模板创建 (Creation by Template): 用户通过指向链上已部署代码的地址来指定他们想要运行的代码，而不是直接在交易数据中包含字节码。这更具成本效益，并防止 EOA 执行在交易调用数据中指定的任意代码，从而进一步使其功能与智能合约钱包保持一致 。   56 | 与未来账户抽象的前向兼容性 (Forward-Compatibility with Future Account Abstraction): EIP-7702 被设计为与未来的账户抽象提案（如 ERC-4337）兼容。授权中的 address 可以指向现有的 ERC-4337 钱包代码，确保在未来所有账户本质上都是智能合约的情况下能够平滑过渡 。   57 | 4. 自赞助 (Self-Sponsoring): EIP 允许 tx.origin（交易的原始发送者）设置代码并执行其自己的委托代码。这使得用户能够利用 EIP-7702 的功能，而无需依赖第三方基础设施进行赞助。智能合约通常使用 msg.sender == tx.origin 来确保某个操作是由用户直接发起的，而不是通过合约进行的。  58 | 5. 仅委托代码执行 (Delegation of Code Execution Only): 诸如 EXTCODEHASH 之类的操作不会自动跟随委托，而是对委托指示符本身进行操作。这可以防止账户临时伪装成具有特定的代码哈希，这可能会破坏依赖代码哈希来定义账户行为的合约 。   59 | 6. 预先收取最高成本 (Charge Maximum Cost Upfront): 交易最初会为每个委托收取最坏情况下的 gas 成本，如果账户已存在于状态中，则稍后会退款。这通过最小化交易初始验证期间的状态查找来优化 gas 成本计算 。   60 | 7. 无 Blobs，无合约创建 (No Blobs, No Contract Creation): EIP 专注于改进用户体验，不包括 blob 提交（如 EIP-4844）或在同一交易类型中创建合约的功能，以避免不必要的复杂性并保持重点明确 。   61 | 8. 需要非空的授权列表 (Non-Empty Authorization List Required): 设置代码交易必须包含至少一个授权才能被认为是有效的。这阻止了将此交易类型用作通用交易格式，因为它与诸如 EIP-1559 之类的其他交易类型相比，对交易池具有不同的影响 。 62 | 63 | > Blobs 是附加到以太坊交易上的大量额外数据，可以理解为携带交易的“边车”。主要目的是为 Layer 2 (L2) 扩展方案（如 Rollup）提供更便宜的数据存储方式，从而显著降低 L2 向以太坊主网提交交易数据的成本（Gas 费用），是临时储存，不可直接访问。 64 | 65 | ### 2025.05.17 66 | 67 | 技术不再深入了，有点云里雾里，产品层面的理解主要就是： 68 | 1. 交易批量处理：在一次交易中完成批准 ERC-20 代币的使用并实际花费这些代币的操作，能减少交易次数和 Gas 费用 69 | 2. gas 赞助：提供了无需持有原生 ETH 即可进行交易的可能性。（UX这类链抽象dapp） 70 | 3. 权限降级：可以创建和签署具有特定、有限权限的子密钥，而不是授予对其账户的完全访问权限。（花费特定类型的代币或在特定的时间段内有效） 71 | 4. 临时SC：EIP-7702 允许 EOA 在单笔交易中临时拥有智能合约的功能，这意味着 EOA 可以执行更复杂的逻辑，而不仅仅是简单的转账。也避免了与永久性智能合约相关的复杂性和潜在风险 72 | 73 | ### 2025.05.17 74 | 75 | 差不多了，纯技术的东西要重新学很多东西 76 | 77 | 78 | -------------------------------------------------------------------------------- /luleigreat.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | 6 | 7 | # Jerry 8 | 9 | 1. 自我介绍：我是一名区块链开发者，之前做过以太坊，OP相关的开发，建设及维护一条OP-Stack L2公链有近一年时间，目前已关停 10 | 2. 你认为你会完成本次残酷学习吗？：会 11 | 3. 你的联系方式（推荐 Telegram）：Telegram 用户名：@Jerry3721 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.05.14 18 | #### EIP-7702：从EOA到智能账户 19 | **钱包能力提升**： 20 | - 批量交易：如"approve"与"swap"可以在一笔交易中执行 21 | - Gas捐赠：允许他人代支付交易手续费 22 | - 身份认证：多种安全硬件可以用来验证账户身份，而不是只能通过私钥签名 23 | - 消费限额：可以设置一个应用可以消耗多少token，或者一天最多消费多少token，提高账户安全性 24 | - 恢复机制：当忘私钥时，可以通过多个不同选项来保护资产，而不是只能重新建立一个新账户 25 | 26 | **用法**： 27 | 28 | 要使用EIP-7702,EOA需要签署授权交易，指向它想要执行其代码的特定委托地址，设置好后，账户获得了代理合约账户的代码能力（批量执行、Gas捐赠、授权逻辑等）。由于选择一个代理目标会交出很大控制权，EIP-7702会强制做以下检查： 29 | - ChainID 30 | - 账户nonce值 31 | - 撤销机制：可取消代理设置，或者设置一个新的代理 32 | 33 | 34 | ### 2025.05.15 35 | 学习了[EIP-7702：深入探讨智能EOA及其实施示例](https://learnblockchain.cn/article/13256)，发现还有很多新的知识点需要去了解，笔记如下： 36 | 37 | 1. EIP-7702引入新的交易类型 `SET_CODE_TX_TYPE` ( 0x04)，交易中有个`authorization_list`，是个授权列表: 38 | ``` 39 | authorization_list=[[chain_id,address,nonce,y_parity,r,s],…] 40 | ``` 41 | 最终实现的效果是： 42 | - 从负载（chain_id，address,nonce）和签名（y_parity，r,s）恢复出来的EOA地址设置address字段的地址为委托地址 43 | - nonce值要与签名恢复出的EOA地址最新nonce一致，且每次授权后，nonce会+1 44 | - 如果委托地址没被授权，会消耗25000的Gas成本，如果已授权则会部分退款12500 45 | 2. 撤销：用户可以利用 EIP-7702 修改授权地址。如果将 address 字段设置为 0x0000000000000000000000000000000000000000，则以往的授权将被撤销。这将清除账户的代码并将账户的代码哈希重置为空哈希。 46 | 3. 重新委托时，通过ERC-7201避免了存储位置的冲突 47 | 4. 查询交易状态，可以使用`eth_getTransactionReceipt`，查询当前授权，可以通过`eth_getCode`查询code，前缀为"0xef01"开头代表已设置代理地址 48 | 5. 指令集修改，如果账户授权了代理，以下指令会： 49 | - EXTCODECOPY 仅返回0xef01 50 | - EXTCODESIZE 仅返回2 51 | - EXTCODEHASH 仅计算0xef01的Keccak256哈希 52 | - CALL,CALLCODE、DELEGATECALL、STATICCALL将从委托代码地址加载代码并在EOA的上下文中执行 53 | 6. 与智能EOA交互，类似于调用智能合约，只需要将to字段设置为智能EOA地址 54 | 55 | 56 | #### 问题 57 | 1. 如果A要设置B为委托地址，那么是A来签名一个授权，指定B为委托地址，然后放到`authorization_list`中，A再对整个交易签名、发送？这样A在一个交易中签名了两次，文章中说可以用这种签名解耦实现授权交易的Gas代付，没明白怎么操作 58 | 2. 为什么授权交易中，是一个授权列表，而不是单个授权，什么场景下会有多个授权在一个交易中出现？ 59 | 3. 文章中提到 ERC-7201通过全名空间解决多次委托时存储位置冲突的问题，ERC-7201已经在主网上线了是吗 60 | 4. 调用智能EOA，还得是智能EOA的私钥来签名交易吧？也就是tx.origin与交易中的to地址相同？ 61 | 5. 具体怎么实现与ERC-4337的兼容 62 | 63 | 64 | ### 2025.05.16 65 | 66 | 今天通过观看[Slowmist对EIP-7702的代码解析](https://www.youtube.com/watch?v=uZTeYfYM6fM)视频，以及查询一些其它资料，解答了昨天一些疑惑： 67 | 1. 需要明确的是，每个账户只能设置一个代理地址，如果设置多个，后面的会覆盖前面，最终只有一个会生效 68 | 2. 授权列表有多个，是一种批量授权的场景（同时解决了Gas代付问题），比如A，B，C，D都要设置地址X为代理地址，但是A-D账户都没有ETH，那么可以分别签署授权，然后把签名及授权payload交给一个有ETH的账户，一起发送到链上，同时实现对4个账户的授权操作 69 | 3. ERC-7201是一种合约规范，像ERC-4337一样，是没有修改链上实现的，需要开发者自己通过合约实现，具体的还得再研究下[ERC-7201 Storage Namespaces Explained](https://www.rareskills.io/post/erc-7201) 70 | 4. EIP-7702还是需要与ERC-4337配合才能实现Gas代付、批量交易等功能，智能EOA只能取代ERC-4337中的钱包账户能力（EOA + CA） 71 | 72 | 73 | #### 问题 74 | 1. 设置完代理合约地址后，智能EOA账户自己可以调用自己来修改合约状态存储，如果是其它账户调用智能EOA呢，会修改其它账户的状态存储还是智能EOA账户的 75 | 2. 社交恢复的具体实现 76 | 3. 通过其它方式进行身份认证（而非账户私钥） 77 | 78 | ### 2025.05.17 79 | 80 | 今天跑了一遍[viem上的7702示例](https://viem.sh/docs/eip7702)，加深了对EIP-7702的理解： 81 | 1. 如果签名授权后，账户要自己发送SetCode交易，那么需要注意nonce值问题（授权增加nonce，发交易又增加一次），失败交易参考：[sepolia](https://sepolia.etherscan.io/tx/0xff9e60c0f5b0ab0ac3055d9f7dcfe7fdb6b1005a00aa9ee8252aaeba19ae966b#authorizationlist) 82 | ``` 83 | const authorization = await walletClient.signAuthorization({ 84 | // account: eoa, //这样是有问题的，会设置失败 85 | contractAddress, 86 | executor: 'self' //注意这一行，这样设置没问题 87 | }); 88 | 89 | const hash = await walletClient.writeContract({ 90 | abi, 91 | address: walletClient.account.address, 92 | authorizationList: [authorization], 93 | functionName: "initialize", 94 | }) 95 | ``` 96 | 2. 在发送SetCode做授权的同时，还可以在同一笔交易中做智能EOA的调用，见上面的代码(`initialize`) 97 | 3. 昨天的第一个问题，如果其它账户调用智能EOA账户成功（有权限），修改的也是智能EOA账户自己的状态 98 | 99 | ### 2025.5.18 100 | 今天又找了一些EIP-7702的资料，对升级有了更深刻的理解： 101 | 1. 关于批量执行操作，[这篇文章](https://learnblockchain.cn/article/11498)给出了一个自己实现批量上链逻辑： 102 | ``` 103 | struct Call { 104 | address to; 105 | uint256 value; 106 | bytes data; 107 | } 108 | 109 | function execute(Call[] calldata calls) external payable { 110 | //交易发送者为智能EOA账户，自己发起的多个操作打包，不需要签名验证 111 | require(msg.sender == address(this), "Invalid authority"); 112 | _executeBatch(calls); 113 | } 114 | 115 | function _executeBatch(Call[] calldata calls) internal { 116 | uint256 currentNonce = nonce; 117 | nonce++; 118 | 119 | for (uint256 i = 0; i < calls.length; i++) { 120 | _executeCall(calls[i]); 121 | } 122 | 123 | emit BatchExecuted(currentNonce, calls); 124 | } 125 | 126 | function _executeCall(Call calldata callItem) internal { 127 | (bool success,) = callItem.to.call{value: callItem.value}(callItem.data); 128 | require(success, "Call reverted"); 129 | emit CallExecuted(msg.sender, callItem.to, callItem.value, callItem.data); 130 | } 131 | ``` 132 | 2. Gas赞助，类似于ERC-4337中的实现：用户签名`UserOperation`发送给Bundler统一打包上链： 133 | ``` 134 | //直接上链 135 | function execute(Call[] calldata calls) external payable { 136 | // 调用者直接执行调用 137 | } 138 | //赞助者在验证签名是由 EOA 签署后，代表调用者执行调用。 139 | function execute(Call[] calldata calls, bytes calldata signature) external payable { 140 | byte32 encodedCalls = abi.encodePacked(calls); 141 | bytes32 digest = keccak256(abi.encodePacked(nonce, encodedCalls)); 142 | //这里还原签名地址后可能与白名单进行比较，不一定是msg.sender 143 | require(ECDSA.recover(digest, signature) == msg.sender, "Invalid signature"); 144 | // 赞助者代表调用者执行调用 145 | } 146 | ``` 147 | 148 | ### 2025.5.19 149 | 150 | #### EIP-7702 带来的影响与机会 151 | EIP-7702 是一项重大改变，对区块链行业中的各个参与方都带来了重大影响，也提供了许多新的机会。 152 | 153 | **合约钱包服务商** 154 | 155 | 从提案本身的标题和实现机制中可以看出，EIP-7702 本身并不专门提供有关账户抽象（Account Abstraction, AA）的上层能力（如 gas 抽象，nonce 抽象, 签名抽象等），只是提供了将 EOA 转化成 Proxy 合约 的基础能力。因此该提案并不与现行的各类合约钱包基础设施（如 Safe, ERC-4337 等）相冲突。相反，EIP-7702 与现有的合约钱包可以几乎无缝融合。允许用户的 EOA 转变成 Safe 钱包，ERC-4337 钱包。从而集成合约提供的多签、gas 代付、批量交易、passkey 签名等等功能。合约钱包提供商如果能快速、顺滑地集成 EIP-7702，可以有效扩展用户群体，提升用户体验。 156 | 157 | **DApp 开发者** 158 | 由于 EIP-7702 对 AA 钱包的用户体验上有所提升，DApp 开发者可以考虑更大范围的接入 AA 钱包，为用户与 DApp 交互提供更便捷安全的体验。如利用合约钱包的批量交易能力一次性完成多个 DeFi 操作。 159 | 160 | 另一方向 DApp 也可以考虑根据项目特性为用户定制开发 Delegation 合约，为用户提供专有的复杂合约交互功能。 161 | 162 | **资产托管方** 163 | 对于交易所、资金托管方，通常需要管理大批量的地址作为其用户的充币地址，并定期进行资金归集。传统的资金归集模式中使用 EOA 地址作为充币地址，进行归集时需要向充币地址充值一定金额的 gas，并由充币地址向出金地址进行转账交易。整个资金过程涉及大量的交易发送，流程很长且需要支付高额的 gas 费用。历史上也出现过机构进行资金归集导致链上交易费用攀升，交易拥堵的情况。 164 | 165 | EIP-7702 的出现可以将 EOA 地址无缝转化成合约钱包，由于 EIP-7702 的 gas 代付机制，不再需要 gas 充值交易的存在。同时可以利用合约钱包的可编程性，将多笔归集转账打包在单笔交易中，减少交易数量并节约 gas 消耗。最终提高归集效率，降低归集成本。 166 | 167 | ### 2025.5.20 168 | 今天查EIP-7702关于与ERC4337融合的资料，找到如下内容，明天仔细研究下： 169 | - [eip7702.io](https://eip7702.io/examples) 有关于用智能EOA生成 `UserOperation`的示例 170 | - [ZeroDev](https://docs.zerodev.app/) 提供了关于智能EOA与智能合约账户（ERC-4337）的工具包 171 | 172 | ### 2025.5.21 173 | 今天看了下ZeroDev的文档，笔记如下： 174 | ZeroDev 通过以下方式改进 Web3 UX： 175 | - 密钥抽象 176 | - 通过passkey或社交账户登录 177 | - 如果用户丢失登录信息，可通过passkey等方式恢复帐户 178 | - Gas抽象 179 | - 为用户赞助Gas 180 | - 支持用户用ERC20代币支付gas 181 | - 交易抽象 182 | - 批量发送交易 183 | - 通过session key 自动发交易（对AI Agent友好） 184 | - 链抽象 185 | - 不需要跨链即可在任意链上花费代币 186 | - 与任何交易所都有出入口，甚至在 L2 上 187 | 188 | ZeroDev 是 AA 中最值得信赖的解决方案，为 100 多个团队在 30 多个网络上的 400 多万个智能账户提供支持。 189 | 190 | 试了一下通过passkey生成账户，并由ZeroDev官方代付Gas的示例：https://passkey-demo.zerodev.app/， 记录如下： 191 | - passkey 生成账户需要手机的解锁密码 192 | - 每次给passkey账户签名，都需要输入电脑的解锁密码 193 | 194 | ### 2025.5.22 195 | #### ZeroDev 196 | 1. 今天看了下ZeroDev的DashBoard，发现有些类似Alchamy或Infura，要做Gas赞助，是这样的： 197 | - 在DashBoard创建Project 198 | - 设置Gas赞助，会生成一个ChainID绑定的rpc地址 199 | 2. 跑了下[7702的示例](https://github.com/zerodevapp/zerodev-examples/tree/main/7702)，没跑通，报错了，通过错误发现ZeroDev的rpc地址是一个自己提供的服务地址，服务封装了一些接口，如`pm_getPaymasterStubData` 200 | 3. 决定先不去研究ZeroDev了，原因如下： 201 | - ZeroDev对账户抽象的实现比较复杂，封装比较深，一时没研究明白 202 | - Github上的star数量并不多 203 | - 这种类似于Alchamy的服务形式，注定后期要收费才能盈利 204 | 205 | #### 7702 206 | **应用场景** 207 | - 批量交易，如approve + swap，要比ERC4337的方案省很多Gas 208 | - Gas用ERC20代付，解决用户没有ETH的情况下也能交易的问题 209 | **安全风险** 210 | - chainid设置为0的情况下，别人可在其它链上通过重放交易来给账户设置代理 211 | - [目前已经出现欺诈场景](https://www.iyiou.com/briefing/202505201776633)，因为eoa最终签名的是个hash，通过钓鱼网站，可以做到签名内容与hash不一致，为用户设置一个欺诈代理，把资产转移 212 | 213 | ### 2025.5.23 214 | #### 总结篇 215 | EIP-7702学习告一段落，本来是定的5天学完，其实5天已经把细节都学差不多了，该体验的也体验了，后来加到10天，由于后面工作繁重，没能花太多精力在上面，所以内容水了很多。 216 | 217 | 今天翻了翻其它同学的笔记，发现牛人还是很多的，言归正传，个人认为7702未来的方向预测： 218 | - Metamask，OKX等钱包会集成EIP-770，加一个设置授权地址的功能，安全措施要不要做呢？从产品角度，好像超出了钱包的能力，但是还是期待能有这方面的方案 219 | - 之前的ERC-4337方案都会支持EIP-7702 钱包，但是也有可能出现更轻量的方案集成EIP-7702实现Gas代付逻辑 220 | - zkLogin、passKey等方案会被广泛应用，用户私钥恢复、web2方式登录会更加普及 221 | - 由于门槛降低，web3用户会出现一波增量 222 | 223 | 224 | 还有一些问题后面需要继续研究： 225 | - 私钥社交恢复的具体实现 226 | - erc20代付gas的代码研究 227 | - 存储冲突的解决，具体怎么用ERC-7201？ 228 | 229 | 230 | 231 | -------------------------------------------------------------------------------- /narnona.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍: 大家好，我是卡卡。一个去中心爱好者，喜欢智能合约开发和安全研究，目前EVM生态合约开发在职。 11 | 2. 你认为你会完成本次残酷学习吗？： 会尽力的 12 | 3. 你的联系方式（推荐 Telegram）: @tupongren 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.07.11 19 | 20 | 笔记内容 21 | 22 | ### 2025.07.12 23 | 24 | 25 | -------------------------------------------------------------------------------- /nghdavid.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. David 11 | 2. Yes, will try my best 12 | 3. TG: nghdavid 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.15 19 | EIP-7702 是以太坊創辦人 Vitalik Buterin 於 2024 年提出的一項關鍵提案，旨在推動帳戶抽象（Account Abstraction）的發展，讓傳統的外部擁有帳戶（EOA）在不更換地址的情況下，獲得智能合約帳戶的靈活性與功能。 20 | 21 | --- 22 | 23 | ### EIP-7702 的核心機制 24 | 25 | EIP-7702 引入了一種新的交易類型，允許 EOA 在單筆交易中臨時掛載智能合約代碼（`contract_code`），使其在交易期間具備智能合約的能力。交易結束後，該代碼會自動移除，EOA 恢復為原始狀態。 26 | 27 | 具體流程如下： 28 | 29 | 1. **設置代碼**：若 EOA 的合約代碼為空，則在交易開始時設置為提供的 `contract_code`。 30 | 2. **執行交易**：根據 `contract_code` 中定義的邏輯執行交易，通常包括 `verify`（驗證）和 `execute`（執行）兩個函數。 31 | 3. **移除代碼**：交易完成後，將 EOA 的合約代碼重置為空，恢復其原始狀態。 32 | 33 | 這一機制類似於 EIP-3074 中的 `AUTH` 和 `AUTHCALL` 操作碼，但 EIP-7702 不需引入新的操作碼，避免了對以太坊虛擬機（EVM）的永久性更改。 34 | 35 | --- 36 | 37 | ### 與其他提案的關係 38 | 39 | * **EIP-3074**：EIP-7702 被視為 EIP-3074 的替代方案，提供了類似的功能，但通過交易類型實現，避免了新增操作碼帶來的潛在風險。 40 | * **EIP-4337**：EIP-7702 與 EIP-4337 高度兼容，允許 EOA 利用現有的智能合約錢包代碼，實現如交易批處理、Gas 贊助等功能，促進了帳戶抽象的統一生態系統。 41 | * **EIP-5003**：EIP-7702 為未來可能的永久性帳戶轉換（如 EIP-5003 提出的 EOA 永久轉換為智能合約帳戶）鋪平了道路。 42 | 43 | --- 44 | 45 | ### 實際應用與影響 46 | 47 | EIP-7702 已被納入以太坊 2025 年的 Pectra 升級中，並受到社群廣泛支持。 48 | 49 | **對用戶的好處**： 50 | 51 | * **交易批處理**：可將多個操作合併為單筆交易，提升效率。 52 | * **Gas 贊助**：允許第三方為用戶支付交易手續費，降低使用門檻。 53 | * **無縫身份驗證**：支持多種簽名方式，如生物識別，提高安全性與便利性。 54 | * **會話密鑰與限權帳戶**：實現臨時授權，提升操作靈活性。 55 | * **靈活的安全策略**：支持多簽與社交恢復等安全機制。 56 | * **跨鏈與模組化體驗**：支持跨多個網路使用同一套授權邏輯。 57 | * **無需更換地址**：用戶可在不更換地址的情況下，享受智能合約帳戶的功能。 58 | 59 | **對開發者的意義**： 60 | 61 | * **錢包開發**：可在不改變用戶地址的情況下，提供智能帳戶功能。 62 | * **智能合約/模組開發**：擴大智能合約錢包代碼的適用範圍，降低開發和維護成本。 63 | * **DApp 集成**：可設計更複雜的交互流程，提升用戶體驗。 64 | 65 | --- 66 | 67 | 68 | ### 2025.05.16 69 | *Security Risks* 70 | 71 | - Lack of access control 72 | 73 | If the delegate contract lacks proper access controls, attackers can execute arbitrary logic on behalf of the EOA, such as transferring the tokens out of the wallet. 74 | 75 | - Initialization challenges 76 | 77 | * Constructors: when you delegate code to an account, the constructor of the delegation designator contract does not execute in the context of the EOA 78 | * Front running and (re)initialization: If the contract uses an initialization pattern, users must make sure that the initialize function has proper access controls and that the contract can not be reinitialized by a malicious user. As a user, you’ll need to delegate and call the initialize function in the same transaction. 79 | 80 | - Storage collisions 81 | 82 | Persistent state across redelegations and upgrades: Delegating code does not clear existing storage. When migrating from one delegation designator contract to another, users and developers must account for the old storage data to prevent storage collisions and unexpected behaviors. 83 | 84 | ### 2025.05.17 85 | *Gas sponsorship* 86 | Any bundler/relayer can call this contract with correct calldata. EOA performs this required operation, while gas fees are incurred by relayer/bundler. 87 | 88 | *Phishing attack of EIP-7702 wallet* 89 | A malicious EIP-7702 signature can drain your wallet in a single transaction. 90 | 91 | *Transaction batching* 92 | Batch multiple transactions into single transaction 93 | 94 | ### 2025.05.18 95 | *Account Abstraction* 96 | - UserOperation 97 | ``` 98 | struct UserOperation { 99 | address sender; 100 | uint256 nonce; 101 | bytes initCode; 102 | bytes callData; 103 | uint256 callGasLimit; 104 | uint256 verificationGasLimit; 105 | uint256 preVerificationGas; 106 | uint256 maxFeePerGas; 107 | uint256 maxPriorityFeePerGas; 108 | bytes paymasterAndData; 109 | bytes signature; 110 | } 111 | ``` 112 | * 附加字段 - UserOperation 交易结构中的有一些新字段(如: paymasterAndData 等) 113 | * 另一个mempool - UserOperation 被发送到一个单独的mempool, 在那里捆绑器可以将 UserOperation 打包成真实的交易，并被包含在一个区块中。 114 | * 认证方式 - 对于一个传统交易, 认证总是通过一个私钥的签名来完成, 这个私钥对于一个给定的发起者来说永远不会改变。在UserOperation中,认证是可编程的。 115 | 116 | - 捆绑器(Bundler) 117 | 捆绑器会监控一个专门为UserOperation建立的 mempool。捆绑器将多个UserOperation捆绑成一个交易, 并将该交易提交给入口点(EntryPoint)合约。捆绑器通过抽取部分 Gas 费用来获得补偿。 118 | - 入口点(EntryPoint) 119 | EntryPoint是一个单例智能合约,用来接收来自捆绑器的交易,然后验证和执行UserOperation 120 | - EntryPoint的执行过程是如何进行的? 121 | 在执行过程中, EntryPoint合约通过使用UserOperation中指定的 calldata 来执行UserOperation, 并从智能合约账户中取钱给捆绑器报销合适的ETH来支付Gas 122 | - Paymaster 123 | * Paymaster 是一个ERC-4337定义的智能合约,处理Gas 支付政策。支付政策为 Gas 的支付方式（例如，用什么货币）和由谁支付创造了灵活性，这消除了用户持有区块链原生代币才能与区块链交互的限制。 124 | * 允许应用程序开发人员使用其他ERC-20代币实现 Gas 支付 125 | - 聚合器(Aggregator) 126 | * 聚合器是一个智能合约，它实现了一个支持聚合的签名方案 127 | * 通过将多个签名合并成一个签名, 聚合器有助于节省calldata成本 128 | 129 | ### 2025.05.19 130 | *Important Limitations* 131 | 132 | - The EOA's Private Key Remains All-Powerful 133 | * The private key can always override any delegation by signing a new transaction 134 | - No Deployment Permanence 135 | * Unlike a deployed smart contract account with its own address, an EIP-7702 delegation can be overwritten 136 | - Multichain Challenges 137 | * EIP-7702 authorizations are chain-specific, which means users would need to sign separate authorizations for each chain 138 | - Controlled by wallets, not applications 139 | * Wallet providers have made it clear that they will reject transactions containing authorization fields from applications 140 | * Applications cannot directly use EIP-7702 to delegate user accounts to their preferred smart accounts 141 | - ERC-7710/7715 Approach 142 | * ERC-7710: Creates a standard interface for smart contracts to delegate permissions to other contracts. Think of it as an extension of the ERC-20 approve function but for arbitrary permissions. 143 | * ERC-7715: Introduces a new JSON-RPC method called wallet_grantPermissions that applications can use to request permissions from wallets. 144 | - Work flow 145 | * A wallet uses EIP-7702 to delegate the user's EOA to a smart contract that supports EIP-7710 146 | * An application requests permission via EIP-7715 to spend funds from the user's account 147 | * The wallet displays this request to the user 148 | * If approved, the application can now execute actions through the delegation 149 | - Applications 150 | * Request direct permission for their contract to interact with the user's account, or 151 | * Deploy their own smart account (called a "companion account") that interacts with the user's account 152 | 153 | ### 2025.05.22 154 | *BEST PRACTICES* 155 | - Delegation contract should align with AA standards (ERC-4337 compatible) 156 | - Stay Permissionless: Don’t hardcode relayers; anyone should be able to relay & censorship resistance 157 | - Pick 4337 Bundlers: Use EntryPoint ≥ 0.8 for gas abstraction 158 | - dApp Integration: Utilize ERC-5792 or ERC-6900, no standardized method for dApps to request 7702 authorization signatures directly 159 | - Avoid Lock-In: Stick to open, interoperable standards like Alchemy’s Modular Account 160 | - Preserve Privacy: Support ERC-20 gas payments, session keys, public mempools to minimize data exposure 161 | - Use Proxies: Delegate to proxies for upgrades and modularity without requiring additional EIP-7702 authorizations for each change 162 | 163 | ### 2025.05.23 164 | *Set Code Transaction* 165 | We have 4 slots in an EOA 166 | - nonce 167 | - balance 168 | - code 169 | - storage root 170 | 171 | EIP-7702 introduces a new way to set code field by sending a new type of EIP-2718 transaction 172 | The transaction code is different from a normal transaction from EIP-1559, it has to send more data in the transaction payload 173 | 174 | An EOA has to sign the message with these additional four information: 175 | - chain_id: The chain on which the transaction will take place 176 | - address: The smart contract address that the EOA wants to point to 177 | - nonce: Security protection for replay purposes 178 | - y_parity (== v), r and s: Components of the signature that are used to recover the authority 179 | 180 | ``` 181 | rlp([ 182 | chain_id, 183 | nonce, 184 | max_priority_fee_per_gas, 185 | max_fee_per_gas, gas_limit, 186 | destination, 187 | value, 188 | data, 189 | access_list, 190 | "authorization_list", 191 | signature_y_parity, 192 | signature_r, 193 | signature_s 194 | ]) 195 | ``` 196 | 197 | ``` 198 | authorization_list = [ 199 | [chain_id_1, address_1, nonce_1, y_parity_1, r_1, s_1], 200 | [chain_id_2, address_2, nonce_2, y_parity_2, r_2, s_2], 201 | ... 202 | ] 203 | ``` 204 | 205 | 206 | 207 | 208 | 209 | 210 | -------------------------------------------------------------------------------- /nx-xn2002.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 倪响 9 | 10 | 1. 自我介绍 北京邮电大学大四学生，在 24 年接触并了解到 Web3，对 Web3 技术和理念很感兴趣，希望能够进一步学习 Web3 知识并在未来能够参与到 Web3 生态的建设当中 11 | 2. 你认为你会完成本次残酷学习吗？ 会 12 | 3. 你的联系方式(推荐 Telegram) @nx_xn2002 1870230468@qq.com 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | 今天是共学的第一天，我打算先通过粗读 EIP-7702 提案原文，对涉及到的相关概念有一个初步的了解。 21 | 22 | 首先，在 Abstract 摘要中我了解到，该提案新增了一种交易类型，允许 EOA 在**一笔交易**中通过签名授权某些合约来代理其行为，换句话说，就是使得 EOA 在该交易中**临时拥有执行合约代码的能力**。 23 | 24 | 在此前的学习中，我了解到以太坊中有两类账户类型：EOA（**Externally Owned Account**，外部拥有账户）和智能合约账户（**Contract Account**）。像我们常用的 MetaMask 等钱包创建的地址，几乎都是 EOA。EOA 具有以下几个特点： 25 | 26 | 1. 账户中没有可执行的合约代码，不能响应调用，只能主动发起交易 27 | 2. 可以向其他账户发送 ETH 或调用合约方法 28 | 3. 由用户持有私钥控制，只有持有私钥的人才能发起交易 29 | 4. 每次交易需要自行支付 gas 费用 30 | 31 | 按我的理解，EIP-7702 是因为原本的 EOA 仅能用于签名和发起交易，功能非常有限，而此次提案尝试通过一种类似“代理模式”的方法，让 EOA 在单次交易中“**临时委托**”某个合约地址的代码来代理其执行逻辑，重点在于这种代理仅在该笔交易的生命周期内有效。 32 | 33 | 因此我总结为一句话： 34 | **EIP-7702 是一种以“一次交易”为生命周期的、临时性合约代理机制，使 EOA 能在该交易中由指定合约代码代理其行为。** 35 | 36 | 今天时间有限，我还阅读了 Motivation 动机部分。大致了解到，该提案的动因主要是因为当前 EOA 的设计限制了许多提升用户体验的应用场景。EIP-7702 的设计重点围绕以下三个功能展开： 37 | 38 | - 批处理 39 | - 赞助（gas fee abstraction） 40 | - 权限降级（delegated control） 41 | 42 | 明天我将从这几个功能出发，深入理解其实现方式与潜在应用。 43 | 44 | > 保留疑问：我是从后端初入 web3 领域的，据我了解代理模式是扩展现有系统功能的一种常见方法，但为什么以太坊发展至今才尝试引入类似机制对 EOA 进行扩展（或者之前已有类似机制？）是否是由于最初的设计约束，还是出于安全性方面的考虑？希望在后续学习中能逐步找到答案。 45 | 46 | ### 2025.05.15 47 | 48 | 今天继续阅读 EIP-7702 提案原文。 49 | 50 | 延续昨天的内容，我今天进入了 Specification（规范）部分的阅读。提案定义了一种全新的交易类型，称为 **set code transaction**，是基于 EIP-2718（统一交易类型架构）之上的扩展。该交易类型允许 EOA 在发起交易时，携带一个“委托指示器”（delegation indicator），即一段特定格式的合约代码（如 `0xef0100 || address`），用于指定一个代理执行的合约地址。 51 | 52 | 这一机制的核心变化之一，是修改了 **EIP-3607** 的限制。查阅后发现 EIP-3607 的原意是防止含有代码的账户发起交易，以提升网络安全性。而 EIP-7702 放宽了这一限制，允许具有特定格式（即代理指示器）的代码账户作为合法的交易发送者。虽然这样提升了 EOA 的扩展能力，但也确实引入了更多攻击面，属于在安全性与功能性之间的一种权衡 53 | 54 | 在 **General design philosophy（设计理念）** 部分，提案作者讨论了代码委托（Code Delegation）的持久性问题。最初的设想是采用临时授权机制：在一笔交易中暂时写入合约代码，执行完毕后立即清除。这种方式相对安全，避免了永久性修改账户状态。但实践中发现，这种设计容易被用户当作脚本引擎使用，而非作为智能钱包的正式升级路径，导致用户体验发展方向割裂：一边是轻量脚本化 EOA，一边是全功能合约钱包。 55 | 56 | 为统一发展路径，提案后来倾向于采用 **持久化委托** 机制。这样一来，部署成本与复杂度变高，能有效降低滥用的概率，也促使开发者将其视为一种正式的钱包扩展手段，而非临时性的 hack。这种“制造一定摩擦”的策略，是为了防止生态在“智能钱包 vs EOA 脚本”之间产生分裂。 57 | 58 | 我认为这个权衡很有意思：技术上，临时委托可以更灵活、快速地落地，但长期来看会让系统形态更发散、不统一；而持久化委托虽然牺牲了一定便捷性，却可能促进生态统一走向可维护、安全性更高的方向。 59 | 60 | 阅读至此，我有一个更明确的感受：**EIP-7702 并不仅仅是为了解决某一个用户操作上的不便，而是在构建一种面向未来的钱包账户形态，在 EOA 与智能合约钱包之间建立“可过渡的中间形态”**，以引导用户逐步迈向合约钱包世界。 61 | 62 | 明天我准备从提案所提到的实际应用出发，比如批处理、Gas 抽象和权限管理等方面，寻找一些现有代码或 Demo 项目，看看能不能加深理解和思考 63 | 64 | > 疑问延续：EIP-7702 的出现是否代表 EOA 的生命周期正在逐渐结束，未来是否所有钱包都将演进为某种形式的智能合约账户？ 65 | 66 | ### 2025.05.16 67 | 68 | 请假 69 | 70 | ### 2025.05.17 71 | 72 | 今天看到群里有朋友讨论 EIP-7702 的一个潜在应用场景：**Social Recovery（社交恢复）**。这是当前智能钱包中常见的一种功能，用于帮助用户在私钥丢失或无法访问账户的情况下，**恢复对账户的控制权**。值得注意的是，这里强调的是“恢复控制权”而非“找回原始私钥”，因为从安全角度出发，私钥应始终保持不可泄露。 73 | 74 | 结合前几天对 EIP-7702 的学习，我突然意识到：**这项提案本质上为 EOA 引入了“可被代码代理控制”的能力，等于是为传统不可扩展的 EOA 打开了权限恢复的可能性**。原本，一旦用户丢失私钥，EOA 便无法再被控制；但在 7702 中，用户可以预先通过一笔 `set code` 交易，为自己的 EOA 设置一段可代理执行的合约逻辑，从而在合约层面实现权限校验与恢复策略。 75 | 76 | 以 EIP-7702: A Deep Dive into Smart EOAs with Implementation Examples 中所举的例子为例，常见的恢复机制包括： 77 | 78 | - **M-of-N 签名机制**：如 2-of-3 guardian 模式，用户可指定多个可信账户（朋友、设备、服务）共同协助恢复权限 79 | - **ZK-email 验证**：通过 zk 证明用户控制某个邮箱，实现无需暴露隐私信息的权限确认 80 | - **社交图授权**：利用链上社交图谱确定可信关系网络，实现去中心化的恢复流程 81 | 82 | 这些机制本来只能在智能合约钱包中实现，而 EIP-7702 的出现，使得它们首次成为 EOA 用户的可能选项。 83 | 84 | 从我的角度来看，EIP-7702 很像一种“分层管理员”的权限架构： 85 | 86 | - **EOA 本身类似于超级管理员（root）**，拥有最初的签名权限，可以任意指定或撤销代理合约 87 | - **代理合约则扮演系统管理员（admin）** 的角色，执行日常操作，并内嵌各种权限控制逻辑 88 | - 这样即使用户暂时无法访问超级管理员权限（丢失私钥），只要代理逻辑设置得当，仍有可能通过其他机制恢复访问权 89 | 90 | 这其实是传统 Web 安全设计中的常见做法，只不过在链上执行，需要在不牺牲去中心化与安全性的前提下完成 91 | 92 | 当然，**EIP-7702 的开放性也意味着潜在的安全挑战**。一旦用户误授权了一个恶意合约为代理，便可能彻底失去账户控制权。因此我认为： 93 | 94 | - 对 `set code` 交易的内容审计至关重要 95 | - 钱包和浏览器层应该在授权代理逻辑时提供更透明的 UI 和合约行为分析 96 | - 用户教育也应同步跟上，避免因轻信而转交控制权 97 | 98 | ### 2025.05.18 99 | 100 | 和昨天一样，今天的学习也从群友的技术讨论引发了新的思考。这次引起我注意的话题是关于 EIP-7702 是否能实现 **0gas 账户的可信入场**，以及在这个过程中 `msg.sender` 是否仍然能够正确表示签名者身份的问题。 101 | 102 | #### 🧩 起点：7702 能否在 0gas 账户场景中设置正确的 `msg.sender`？ 103 | 104 | 在讨论中，一位群友提出这样一个设想： 105 | 106 | > 一个新创建的 0gas 账户，只签署一笔交易但自己没有 Gas，由中继者帮它发送出去，那么合约内读取 `msg.sender` 的话，是否还能识别出是这个账户自己？ 107 | 108 | 这时另一位群友表示支持： 109 | 110 | > “7702 就因为改了底层，对这种代理的 call 会设置好对应的 sender，不然做不到批量 approve 什么的。” 111 | 112 | 这句话引起了我的注意。**按照我以往对以太坊执行逻辑的理解，`msg.sender` 一直都是由最外层的交易调用者决定的**，而如果是由中继者代发交易，`msg.sender` 应该是中继者地址。 113 | 114 | 于是我带着这个疑问去翻阅了 EIP-7702 提案文档。 115 | 116 | #### 🔍 求证：7702 是否“改变了 msg.sender 的语义”？ 117 | 118 | 在 EIP-7702 的 `Security Considerations` 和 `General design philosophy` 部分，我发现了以下几段关键性描述： 119 | 120 | > **“Allowing tx.origin to set code and execute its own delegated code enables what is called self-sponsoring...”** 121 | 122 | > **“However, that means the EIP breaks the invariant that `msg.sender == tx.origin` only happens in the topmost execution frame of a transaction.”** 123 | 124 | > **“This will affect smart contracts containing `require(msg.sender == tx.origin)` style checks.”** 125 | 126 | 这几句话揭示了一个重要事实： 127 | 128 | **EIP-7702 的确改变了传统以太坊中 `msg.sender` 与 `tx.origin` 的关系。** 129 | 130 | 它允许一个 EOA 在没有任何代码的情况下，发送一笔带有临时代码的交易，并在执行中让这段代码以 EOA 自己的身份执行，从而“欺骗” EVM 把 `msg.sender` 设置为这个 EOA 本人。 131 | 132 | 也就是说，即便交易是由中继者代为广播，**只要执行了 7702 规范，EVM 会在交易最外层直接执行该 EOA 的代码，因此在合约中看到的 `msg.sender` 就是 EOA 本身**。 133 | 134 | 这与我之前的理解完全相悖。我原以为 `msg.sender` 总是反映中继人的地址，除非合约中手动读取签名校验。但 EIP-7702 事实上是通过底层的交易处理路径，把这种“自我调用”的语义整合了进来。 135 | 136 | #### 🔐 安全影响：为什么这是个破坏性的变化？ 137 | 138 | 提案也指出了这种变更的几个副作用： 139 | 140 | > - **Breaks reentrancy guards of the style `require(tx.origin == msg.sender)`** 141 | > - **Breaks protections against atomic sandwich attacks** 142 | > - **Allows EOA to set and execute its own code inline** 143 | 144 | 虽然这打破了以往某些合约中对 EOA 的静态假设（比如通过 `tx.origin == msg.sender` 来判断发起者是 EOA），但提案认为这些模式本身就不安全或是反模式，**并愿意为此承担这些破坏性变更的代价**。 145 | 146 | #### 💡 我的理解：7702 合法“伪造” `msg.sender` 是为了去信任地中继 147 | 148 | 可以这么理解： 149 | 150 | - 🧾 EIP-7702 让 EOA 可以携带“临时代码”，在交易执行期间以自己的身份运行 151 | - 🧬 所以从合约的角度，**msg.sender 就是签名者本人，而不是中继者** 152 | - 🛠 这是为了解决传统代付（meta-transactions）中对 relayer 的信任问题 153 | - 🔐 同时带来了新的合约安全挑战（tx.origin 检查失效、重入控制失效等） 154 | 155 | #### 🧠 总结思考 156 | 157 | 这次讨论让我意识到 EIP-7702 不只是“让 EOA 有了 code”这么简单，它实际上通过改动交易生命周期和 sender 处理逻辑，真正做到了让 **用户以自身身份进行 gasless 交互**，而无需过多信任中继者。 158 | 159 | 这也许能成为 EOA->AA 演进过程中的关键桥梁，保留地址连续性与用户可读性，又具备合约的高度可编程性。 160 | 161 | ### 2025.05.19 162 | 163 | 今天的学习仍然来源于群友在共学过程中的实际动手实验。有人分享了一段基于 EIP-7702 的 Demo，演示了如何用一个有 ETH 的钱包（钱包 A）帮助另一个没有 ETH 的钱包（钱包 B）设置授权合约并执行初始化函数。这段代码让我对 **7702 如何实现 zero-gas onboarding 和身份传递** 有了更直观的理解。 164 | 165 | #### 🧪 实验代码：钱包 A 资助 B 的 EIP-7702 交易 166 | 167 | 以下是群友分享的核心代码： 168 | 169 | ``` 170 | import { privateKeyToAccount } from 'viem/accounts' 171 | import { createWalletClient, http } from 'viem' 172 | import { sepolia } from 'viem/chains' 173 | 174 | const walletA = createWalletClient({ 175 | account: privateKeyToAccount('0x...'), // 有ETH的钱包 176 | chain: sepolia, 177 | transport: http(), 178 | }) 179 | 180 | const walletB = privateKeyToAccount('0x...') // 无ETH的钱包 181 | const delegatedContract = '0x80296F...2Bb' // 共享的授权合约 182 | 183 | // Step 1: A 为 B 签署授权绑定 delegatedContract 184 | const authorization = await walletA.signAuthorization({ 185 | account: walletB, 186 | contractAddress: delegatedContract, 187 | }) 188 | 189 | // Step 2: A 发起交易，帮 B 完成代码设置 + 初始化调用 190 | const hash = await walletA.sendTransaction({ 191 | authorizationList: [authorization], 192 | data: '0x8129fc1c', // initialize() 函数选择器 193 | to: walletB.address, 194 | }) 195 | 196 | ``` 197 | 198 | #### 🔍 解构：这段代码到底做了什么？ 199 | 200 | 这个 Demo 实际上完整演示了 EIP-7702 的三大核心能力： 201 | 202 | | 能力 | 描述 | 203 | | ----------------------- | ------------------------------------------------------------ | 204 | | **zero-gas onboarding** | B 钱包无需持有 ETH，A 可以代发 7702 交易并设定 B 的合约逻辑 | 205 | | **合约初始化** | `data` 字段调用的是标准的 `initialize()` 逻辑 | 206 | | **sender 身份透传** | 合约中的 `msg.sender` 是 B（授权账户），而不是 A（中继账户） | 207 | 208 | 209 | 210 | 这在传统 EOA 模型中是完全无法做到的。即使使用 meta-transaction 模式，合约也需要自己验证 `signature`，而 7702 则将这种**“信任透传”**嵌入到了交易生命周期的最低层。 211 | 212 | #### 🧬 为什么 `msg.sender` 是 B，而不是发起交易的 A？ 213 | 214 | 这再次印证了昨天笔记中提到的一个结论： 215 | 216 | > EIP-7702 改变了 EVM 中 `msg.sender` 的推导机制，在满足授权条件下，交易中实际执行的是授权者的逻辑，EVM 自动将 `msg.sender` 设置为授权者本人（即签名者 B），而不是中继者 A。 217 | 218 | 这个特性非常关键——它意味着我们**无需信任中继者**来传递身份信息，也**无需合约内显式处理签名校验逻辑**，大幅简化了授权钱包和合约调用的开发复杂度。 219 | 220 | #### 🔐 安全性与破坏性行为的权衡 221 | 222 | 与昨天分析一致，这种身份透传能力虽然带来了更强的抽象能力，也打破了以下传统假设： 223 | 224 | - `tx.origin == msg.sender` 用于判断 EOA 发起人（已失效） 225 | - `msg.sender` 总是代发人地址（已失效） 226 | - 合约部署前不能调用（已失效） 227 | 228 | 但 EIP-7702 的设计者显然认为：**这些旧有假设不适合构建可扩展、无许可的钱包入口机制**，必须打破现状，才能为模块化钱包、账户即合约铺平道路。 229 | 230 | #### 🧠 总结思考 231 | 232 | 这个 Demo 让我更加理解了 EIP-7702 的设计意图和实际可行性： 233 | 234 | - 它不只是提出一个新的账户绑定方式，而是**重塑了“交易是谁发的”这件事的定义** 235 | - 它让一个无 ETH 的地址，也可以借助他人完成初次上链初始化、绑定合约、调用函数 236 | - `msg.sender` 的“身份欺骗”在这里变成了一种**可信的、自主选择的 delegation 模式** 237 | 238 | 从传统的 `EOA + MetaTx + relayer` 到现在的 `EOA + code + 7702授权`，这可能正是账户抽象平滑演进的中间态。 239 | 240 | ### 2025.05.20 241 | 242 | 今天的学习关注点是 EIP-7702 所引入的**委托合约机制中的访问控制漏洞**，这是一个在任何“以他人身份执行代码”的模型中都必须高度警惕的问题。 243 | 244 | #### 🧩 起点：委托合约缺乏访问控制可能导致的安全问题 245 | 246 | 在一个 7702 风格的 gasless 交互场景中，EOA 用户通过签名授权一段逻辑，在一个“代理合约”中被执行。而今天的讨论案例指出了一个关键风险： 247 | 248 | > 如果这个代理合约中没有做好访问权限控制，任何人都可以调用它，**以 EOA 的身份在链上执行任意代码**，造成严重的资产安全威胁。 249 | 250 | 以下是今天看到的一个最小复现示例： 251 | 252 | ``` 253 | solidity复制编辑// SPDX-License-Identifier: MIT 254 | pragma solidity 0.8.20; 255 | 256 | contract VulnerableContract { 257 | function doSomething(bytes memory _data, address _to, uint _value) public payable { 258 | (bool success, ) = _to.call{value: _value}(_data); 259 | require(success); 260 | } 261 | } 262 | ``` 263 | 264 | 这份合约中，`doSomething` 函数允许**任何调用者**传入任意的 `_data` 和目标地址 `_to`，然后直接通过 `call` 执行。这种结构在传统合约中已经是一个典型的危险模式，而在 EIP-7702 的上下文中，问题更为致命： 265 | 266 | > **攻击者可以向这个函数发送带有合约调用数据的交易，从而代替任何关联的 EOA 用户执行转账、操作状态等敏感操作。** 267 | 268 | #### 🔍 实验验证：确实可以用这种方式调用任意合约函数 269 | 270 | 为了验证这个问题，示例中还提供了一个简单的目标合约： 271 | 272 | ``` 273 | solidity复制编辑contract A { 274 | uint public a; 275 | 276 | function increment(uint256 number) public { 277 | a += number; 278 | } 279 | } 280 | ``` 281 | 282 | 我们可以通过以下调用实现跨合约调用，甚至无需目标合约本身做任何授权处理： 283 | 284 | - `_to`: 合约 `A` 的地址 285 | - `_data`: `increment(10)` 的函数选择器与参数编码： 286 | `0x7cf5dab0000000000000000000000000000000000000000000000000000000000000000a` 287 | 288 | 执行 `doSomething` 后，合约 A 中变量 `a` 的值成功被增加了 10。这个例子充分说明了： 289 | 290 | > **只要委托合约缺乏对调用者身份的验证，攻击者就可以利用它在链上为所欲为。** 291 | 292 | #### 🔐 安全影响：EIP-7702 引入强大能力，也带来了强烈安全假设变化 293 | 294 | 在传统 EOA 模式下，合约可以默认认为 `msg.sender` 是“唯一且可信”的用户身份。但在 7702 之后： 295 | 296 | - 合约调用路径可以被临时代码劫持 297 | - 签名者身份可能被滥用执行任意 call 298 | - 如果代理合约不做签名校验或访问控制，会**扩大攻击面** 299 | 300 | 这与昨天的笔记中提到的 **msg.sender “合法伪造”** 是一体两面 —— 它为去信任中继带来了便利，也极大放宽了对“交易发起者”的安全假设。 301 | 302 | #### 💡 我的理解：EIP-7702 开启了“合约式 EOA”，也带来了合约式的攻击面 303 | 304 | 从今天的案例我得出一个重要结论： 305 | 306 | - ✅ EIP-7702 让 EOA 拥有了像合约一样的行为能力 307 | - ⚠️ 但也要求开发者具备构建合约的安全意识，特别是： 308 | - 委托合约必须验证签名 309 | - 必须限制“谁”可以发起交易调用 310 | - 建议设置合理的权限模型与合约防火墙 311 | 312 | #### 🧠 总结思考 313 | 314 | 今天的例子虽然简短，却再次强调了一个 Web3 安全的核心原则： 315 | 316 | > **赋予账户能力的同时，必须建立对应的控制机制。** 317 | 318 | EIP-7702 带来了身份与代码的融合，但随之而来的风险也更加接近“合约世界”的复杂度。**开发者不能再把“账户是安全的”当作默认前提，必须从合约角度重新审视账户的每一次行为** 319 | 320 | ### 2025.05.21 321 | 322 | 今天在看完大部分 EIP-7702 共学资料后，仍觉得对提案的来龙去脉不够清晰。为了补全背景，我回头学习了早期的 EIP-86。 323 | 324 | EIP-86 是 Vitalik 在 2017 年提出的账户抽象提案，核心思想是让用户通过合约验证签名，实现“合约即账户”，可看作是账户抽象的最早尝试。虽然由于与现有架构不兼容最终被搁置，但它的设计理念直接影响了后来的 4337 和 7702。 325 | 326 | 通过学习 EIP-86，我更清楚地理解了 7702 想解决的问题：在不放弃 EOA 的前提下，引入更灵活的合约行为。这种“回退式合约账户”的设计，某种程度上是对 EIP-86 理想的一种现实妥协。 327 | 328 | ### 2025.05.22 329 | 330 | 为了更好理解 EIP-7702 的背景和改进之处，今天重点学习了 EIP-4337。 331 | 332 | EIP-4337 是当前以太坊主流的账户抽象方案，核心设计是不修改协议层，而是通过引入 **Alt Mempool（UserOperation 池）+ EntryPoint 合约** 实现类似账户抽象的功能。它允许用户自定义签名验证逻辑、支持 Gas 代付、批量交易等高级用法。 333 | 334 | 相比之下，EIP-7702 不是另起炉灶，而是试图把“合约账户行为”引入 EOA，让传统钱包也能在交易中临时具备自定义逻辑，相当于在 EOA 与 4337 的合约账户之间架了一座桥。 335 | 336 | 通过对比，我更明确了 7702 的定位：它不是取代 4337，而是为现有钱包生态提供一个过渡式、兼容性的增强路径。 337 | 338 | ### 2025.05.23 339 | 340 | 今天是最后一天了，对之前学习的内容做一个简单的总结： 341 | 342 | 这次共学我是从 EIP-7702 入手，初步理解了它提出的“让 EOA 在一笔交易中临时拥有合约逻辑”的设计。相比 EIP-4337，7702 更轻量、无需额外 mempool，也更容易被现有钱包和用户接受。它提供了一种在不破坏 EOA 本质的情况下，引入自定义验证和批处理能力的方式。 343 | 344 | 但随着学习深入，我意识到仅了解 7702 很难真正理解账户抽象的全貌。于是我回头补充了 EIP-86（最早提出 AA 概念）、4337（当前主流解决方案）以及 3074、2938 等提案的内容，从中梳理了账户抽象在协议层与执行层的不同演进路径，也更清楚地看到了各个提案背后的设计权衡与历史脉络。 345 | 346 | 最终，这轮学习不仅让我对 7702 有了扎实理解，也建立了账户抽象技术从概念、实现到落地之间的整体认知框架。7702 可能不是终局方案，但它在当前生态下提供了一个非常实用的中间层方案，也让我对以太坊未来账户体系的演进多了一份判断力。 347 | 348 | 349 | -------------------------------------------------------------------------------- /qiaopengjun5162.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | # 你的名字 8 | 9 | 1. 自我介绍 10 | 我是一名Web3 开发者，对区块链技术非常感兴趣，希望能在本次残酷学习中学习到更多相关知识。 11 | 2. 你认为你会完成本次残酷学习吗？ 12 | 我相信只要我坚持不懈，努力学习，一定能够完成本次残酷学习。 13 | 3. 你的联系方式（推荐 Telegram） 14 | 我的联系方式是 @Qiao4812，欢迎随时与我交流学习心得和问题。 15 | 16 | ## Notes 17 | 18 | 19 | 20 | ### 2025.05.14 21 | 22 | 概述：EIP-7702 是以太坊的一项提案，允许外部拥有账户（EOAs）集成链上代码，推动账户抽象化，支持批量交易、多重签名等功能。然而，这也带来了开发者必须关注的重大安全风险。 23 | EIP-7702 核心特性： 24 | 新交易类型：EOAs 可通过委托指示器（前缀+链上代码地址）将行为委托给智能合约。 25 | 授权列表：包含链 ID、委托合约地址、随机数和签名。 26 | 委托机制：支持批量操作或燃气费用赞助等高级功能，但 EOA 的私钥仍完全控制账户，若私钥泄露，账户将面临风险。 27 | 与 EIP-4337 比较：EIP-7702 集成更精简，而 EIP-4337 提供更全面的账户抽象模型，两者可针对不同场景共存。 28 | 安全风险： 29 | 访问控制问题： 30 | 若委托合约缺乏访问控制，攻击者可代表 EOA 执行任意逻辑，如转移代币。 31 | 示例：无访问控制的 doSomething 函数可被任何人调用，执行恶意交易。 32 | 初始化挑战： 33 | 委托时，合约构造函数不执行，可能导致行为预期错误。 34 | 需使用初始化模式（如代理合约），但必须设置访问控制，防止攻击者抢先调用或重新初始化。 35 | 存储冲突： 36 | 重新委托时，原存储数据不清除，可能导致冲突（如 bool 被误解为 uint），引发未定义行为或安全漏洞。 37 | 结论：EIP-7702 增强了以太坊账户模型的灵活性，但也扩大了攻击面。开发者需精心设计、彻底审计并强化访问控制，以确保安全实施。 38 | 39 | ### 2025.05.15 40 | 41 | 交易不能是创建合约的交易 42 | 43 | 在以太坊标准交易中，msg.To == nil 表示试图创建合约，而 EIP-7702 交易不能是创建合约的交易，因此禁止 msg.To == nil。 44 | 45 | EIP-7702 交易必须包含至少一条授权条目，否则因空授权列表（ErrEmptyAuthList）而被拒绝。 46 | 47 | 如果 EIP-7702 交易的授权列表中包含同一个用户的多个授权条目，只有最后一个条目会生效，其余会被覆盖。 48 | 49 | 如果 EIP-7702 交易的授权条目关联的账户与发起者是同一账户，仍需两次签名：一次为交易签名，一次为授权条目签名。 50 | 51 | ### 2025.05.16 52 | 53 | 在 EIP-7702 交易中，msg.To == nil 表示试图创建合约被禁止，交易必须包含至少一条授权条目，若授权条目与发起者同账户需两次独立签名，且授权 nonce 与交易 nonce 通常独立，理论上无需比交易 nonce 多 1。 54 | 55 | ### 2025.05.17 56 | 57 | 在 EIP-7702 交易中，如果当前授权条目在执行过程中遇到错误（例如，签名无效或逻辑失败），它不会导致整个交易失败，而是会被跳过，EVM 会继续处理授权列表中的下一条条目。 58 | 59 | 在 EIP-7702 交易中，若某个授权条目执行时遇到错误，它会被跳过而不影响交易整体成功，EVM 会继续处理下一个授权条目。 60 | 61 | ### 2025.05.18 62 | 63 | 64 | 65 | ```go 66 | // Otherwise install delegation to auth.Address. 67 | st.state.SetCode(authority, types.AddressToDelegation(auth.Address)) 68 | 69 | ``` 70 | 71 | 72 | 73 | 74 | 75 | ```go 76 | // DelegationPrefix is used by code to denote the account is delegating to 77 | // another account. 78 | var DelegationPrefix = []byte{0xef, 0x01, 0x00} 79 | 80 | // AddressToDelegation adds the delegation prefix to the specified address. 81 | func AddressToDelegation(addr common.Address) []byte { 82 | return append(DelegationPrefix, addr.Bytes()...) 83 | } 84 | ``` 85 | 86 | ### 2025.05.19 87 | 88 | Best Practices 89 | 90 | - PrivateKey Management 私钥保护 91 | - Multi-chain replay chainId 0 相同的合约地址代码是否一定相同 92 | - No initcode 初始化权限检查 避免抢跑 93 | - Storage Management 插槽 ERC-7201 ERC-7779 验证 插槽 94 | - False Top-up 假充值 检查状态 95 | - Account Conversion 打破 msg.sender == tx.origin 安全检查 96 | - Compatibility 兼容性 ERC-721 ERC-777 97 | - Phishing 钓鱼风险 98 | 99 | Remember: Not your keys, not your coins. 100 | 101 | ### 2025.05.20 102 | 103 | 如果某个授权条目在执行过程中因无效签名或逻辑失败等原因出错，该条目会被 EVM 跳过，而不会导致整个交易失败，EVM 会继续处理授权列表中的下一个条目。这种机制增强了交易的容错性和灵活性，适用于批量授权或账户抽象化场景，但开发者需注意 Gas 消耗和潜在的安全问题。若在测试 EIP-7702 交易时遇到 HTTP 502 错误，可能是 RPC 节点问题，建议切换提供商或检查节点状态。 104 | 105 | ### 2025.05.21 106 | 107 | ERC-4337（账户抽象）通过智能合约钱包替代传统外部账户（EOA），优化区块链用户体验，核心组件包括UserOperation（可编程交易意图）、Bundler（打包交易）、EntryPoint（执行验证）、Paymaster（灵活支付Gas）和Aggregator（聚合签名）。它在不修改底层链的情况下运行，支持无Gas交易、多代币支付等功能，是以太坊生态的重要升级，此前基于EIP-2938和EIP-3074的探索。 108 | 109 | ### 2025.05.22 110 | 111 | EIP-7702 是 Biconomy 博客于 2025 年 2 月 28 日由 Mislav Javor 发布的一篇文章中介绍的以太坊改进提案，旨在通过允许外部拥有账户（EOAs）委托执行给智能合约来提升用户体验，而无需迁移到新的智能账户。它解决了 dApp 交互中的摩擦问题，支持交易批量处理、燃气费赞助和权限管理，同时保持 EOA 的地址和兼容性。然而，EIP-7702 由钱包而非应用控制，可能导致不同钱包采用不同实现方式而产生碎片化。开发者可利用 ERC-7710、ERC-7715 和 ERC-5792 标准，或通过 Biconomy 的伴侣账户和 AbstractJS SDK 简化整合，大幅降低智能账户部署成本。尽管存在 EOA 私钥保留完全控制权和多链挑战等限制，EIP-7702 是迈向更用户友好区块链交互的重要一步。 112 | 113 | ### 2025.05.23 114 | 115 | EIP-7702 是以太坊的一项改进提案，旨在通过引入一种新的交易类型（0x04）增强外部拥有账户（EOA）的功能和安全性。它允许 EOA 在单次交易中临时委托执行给智能合约，从而实现账户抽象化，使普通钱包具备智能合约的灵活性，例如批量交易、自定义验证和更友好的用户体验。与 EIP-3074 相比，EIP-7702 更简洁且兼容 EIP-4337，解决了 EOA 的功能限制问题，同时提升了交易效率和安全性。它是 2025 年以太坊 Pectra 升级的重要组成部分，有望推动智能账户的广泛应用，但也需警惕潜在的授权安全风险。 116 | 117 | 118 | -------------------------------------------------------------------------------- /tofudfy.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | # Tofu 8 | 9 | 1. 自我介绍：本人拥有2年的区块链开发以及多年的区块链研究经验。研究方向涉及区块链共识协议、链上激励与价格发现机制。我的工具使用经验包括Hardhat、Foundry、Tenderly、GraphSQL和Nansen，主要用于跨链桥和DeFi类DAPP应用开发，涉及包括智能合约调试和链上活动分析等事项。曾经开发了针对Aave V2和Compound的MEV机器人，能够在以太坊上以低于2毫秒的内存延迟快速执行小规模的清算。此外，我热衷于链上黑客事件追踪，积极追踪链上安全事件。 10 | 2. 你认为你会完成本次残酷学习吗？会 11 | 3. 你的联系方式（推荐 Telegram）：@ttofu2eth 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.05.14 18 | 19 | 笔记内容 20 | 21 | ### 2025.05.15 22 | 23 | ### 2025.05.16 24 | 25 | ### 2025.05.17 26 | 27 | ### 2025.05.18 28 | 29 | 30 | -------------------------------------------------------------------------------- /wiasliaw.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | 6 | # wiasliaw 7 | 8 | 1. 自我介紹：技術上的 E 衛兵 9 | 2. 會完成殘酷學習嗎：會 10 | 3. tg@wiasliaw 11 | 12 | ## Notes 13 | 14 | 15 | 16 | ### 2025.05.14 17 | 18 | #### How it works 19 | 20 | - 7702 透過 eip-2718 引入一個新的交易類型，允許 EOA 指定一個合約作為其程式碼。這樣使得 EOA 可以像是合約執行 evm bytecode 同時能保有發起交易的能力。 21 | 22 | #### set code transaction 23 | 24 | - set code transaction 的 type 為 0x04，主要多出一個 authorization_list 欄位 25 | - 執行 set code transaction 26 | 1. 先驗證 authorization_list 並處理 set code 27 | 2. 再來執行原本的 transaction 28 | - 交易內容如下： 29 | 30 | ```tsx 31 | const eip_7702_transaction = bytes.concat( 32 | // transaction type 33 | "0x04", 34 | // transaction payload 35 | rlp([ 36 | chain_id, 37 | nonce, 38 | max_priority_fee_per_gas, // eip-1559 39 | max_fee_per_gas, gas_limit, // eip-1559 40 | to, 41 | value, 42 | data, 43 | access_list, // eip-2930 44 | authorization_list, // eip-7702 45 | signature_y_parity, 46 | signature_r, 47 | signature_s 48 | ]) 49 | ); 50 | ``` 51 | 52 | 53 | #### authorization_list 54 | 55 | - 要將一個 EOA 升級成 smart contract account 需要 EOA 簽名 authorization 的資料 56 | 57 | ```python 58 | authorization_list = [ 59 | [chain_id, address, nonce, y_parity, r, s], 60 | ... 61 | ] 62 | ``` 63 | 64 | - 對 authorization 的驗證流程如下 65 | 1. 驗證 chain ID 是否為 0 或為當前鏈的 ID。這表示支援 cross-chain replay 66 | 2. 驗證 nonce 是否小於 `2**64 - 1`。 67 | 3. 驗證簽名 `authority = ecrecover(msg, y_parity, r, s)` 68 | 4. 將 authority 加入 accessed_addresses，如 EIP-2929 所定義 69 | 5. 驗證 `authority` 的代碼是否為空或已被委派 70 | 6. 驗證 `authority` 的 nonce 是否等於 `nonce` 71 | 7. 若 `authority` 非空，則向全域退款計數器增加 `PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST` 的 gas 72 | 8. 將 `authority` 的代碼設為 `0xfe0100 || address` 73 | - 如果 address 為 zero address 則清除 authority 的 code region，並將其 code hash 設置成 empty code hash 74 | 9. 將 `authority` 的 nonce 增加 1 75 | - 如果驗證中任一步驟失敗的話，則跳過當前的 authorization element，並開始處理下一個 authorization element 76 | - 如果後續的 transaction revert，authorization 對 EOA 的寫入並不會 revert 77 | 78 | #### delegation indicator 79 | 80 | - 寫入到 `authority` 的資訊不是可以直接執行的 evm bytecode，而是一個指示器，用以指示 evm 要以不同的方式處理 code region 81 | - `*CALL` 都是受影響的 evm opcode，當一讀到指示器時，會從 `address` 讀取其 code region 82 | - 另外受影響的 opcode 還有 `CODESIZE` 和 `CODECOPY`，同樣也會從 `address` 讀取其 code region 83 | - 但是 `EXTCODESIZE` `EXTCODECOPY` `EXTCODEHASH`則不受影響 84 | 85 | #### Reference 86 | 87 | - https://eips.ethereum.org/EIPS/eip-7702 88 | - https://x.com/blainemalone/status/1893428082653962306 89 | 90 | ### 2025.05.15 91 | 92 | #### 7702 對 UX 的影響 93 | 94 | 回顧 7702 之前的 account 分成 EOA 和 Smart Wallet Account。EOA 主要流程是對 target contract 發起交易，並為交易簽名。這樣的流程使得 EOA 需要先有一些 ETH 作為手續費才可以使用： 95 | 96 | ![image.png](https://img.notionusercontent.com/s3/prod-files-secure%2F0e13fc79-68f6-4250-ac7b-770fd24029db%2Fac7d5225-2a67-49e0-8788-0ae5ccd3d210%2Fimage.png/size/w=2000?exp=1747293492&sig=jH2hf3EM29JNlwlWFWi-KMT7rPKO4VJgwJ5s-Km7YF4&id=1f4098e3-5fa6-8016-99f4-e6d7e4548602&table=block&userId=b83e83cc-a393-4f23-82e9-22582fd02e8d) 97 | 98 | Smart Wallet Account 則是以 EOA 作為某個 Smart Contract Wallet 的 owner，Smart Contract Wallet 會驗證 msg.sender 或是簽名來執行或是呼叫其他的合約。Programmable Wallet 由此開始，可以在交易過程執行一些邏輯，例如多簽或是 batch transaction 等等： 99 | 100 | ![image.png](https://img.notionusercontent.com/s3/prod-files-secure%2F0e13fc79-68f6-4250-ac7b-770fd24029db%2Fbd3fc784-08bb-422c-8bf7-bc82ae1ebd98%2Fimage.png/size/w=2000?exp=1747293581&sig=MtVUNMdLfSShyzVBveMOQDR3fKaWg7P9kvF1Bu64Uls&id=1f4098e3-5fa6-808c-90ff-d47e26697497&table=block&userId=b83e83cc-a393-4f23-82e9-22582fd02e8d) 101 | 102 | 7702 上線後，EOA 可以同時做到上述 EOA 和 Smart Contract Wallet 的兩種行為。EOA 可以有擴充的邏輯可以使用，現在也支援其他簽名演算法。將 EOA 擴充成 4337 進而擴充 Wallet 的用途： 103 | 104 | ![image.png](https://img.notionusercontent.com/s3/prod-files-secure%2F0e13fc79-68f6-4250-ac7b-770fd24029db%2Fc93bc3cc-0794-4502-9b79-d0bf0e7d1617%2Fimage.png/size/w=2000?exp=1747293605&sig=CQyGE6ievAM0BLLk7BnYL86YWwp5Te-2-R4Lpc1fXss&id=1f4098e3-5fa6-80e2-9b9b-e67859af1c31&table=block&userId=b83e83cc-a393-4f23-82e9-22582fd02e8d) 105 | 106 | ### 2025.05.16 107 | 108 | #### Best Practice 109 | 110 | - Private Key Management 111 | - 透過 7702 委託後，雖然可以合約錢包實作的 social recovery 機制來取回權限，但是 EOA 還是有非常高的權限，像是撤銷 7702 委託，所以 Private Key 依舊要保管好 112 | - Storage Management 113 | - 根據 7702，撤銷委託只會清除 code region 不會清除 contract storage。對錢包開發者來說，需要 storage 時需要特別注意 storage layout 的規劃 114 | - Initialization Issue 115 | - 使用 7702 委託，只會更新 code region，並沒有額外函式可以為 code region 做初始化。 116 | - 在 7702 委託後，如果要做初始化，開發者應在初始化期間做檢查。 117 | - 如果是委託給 4337 錢包，確保是使用 0.8 的 EntryPoint (有實作兼容 7702) 118 | 119 | ### 2025.05.17 120 | 121 | #### 4337 compliance 122 | 123 | - 在啟用 7702 的鏈上，eth_sendUserOperation rpc endpoint 可以接受 7702 auth list 的資料。bundler 必須以 set code transaction 打包所有的 auth list 124 | - 4337 建立 smart wallet account 的資料存在於 PackedUserOperation.initCode。initCode 資料如果以 7702 開頭並以 0x00 填充，則表示此 account 是使用 7702 部署。initCode 不會和 factory 合約互動。initCode 超過 20 bytes，其餘的資料會用於初始化 125 | - https://eips.ethereum.org/EIPS/eip-4337#support-for-eip-7702-authorizations 126 | 127 | ### 2025.05.20 128 | 129 | - 在 7702 的設計底下，由於 EOA 仍保留了直接發送交易的能力，所以其 private key 仍有非常大的權力 130 | - 透過 Nick's Method 以構造出來的 ECDSA 簽名發送 7702 authorization 的資料讓一個沒有私鑰的 EOA 升級成 7702 set account，然後初始化一組 key 做管理。這樣就能削減 EOA 權限過大的問題。 131 | - https://blog.biconomy.io/prep-deep-dive 132 | 133 | ### 2025.05.21 134 | 135 | - 本文闡明了 4337 frontrun 相關的經驗 136 | - https://www.notion.so/ananthvivekanand/Adventures-in-ERC4337-frontrunning-1f0c5df4b3ed80278d83c9d7d87a3784 137 | 138 | ### 2025.05.22 139 | 140 | #### 和 3074 的比較 141 | 142 | - 3074 引入兩個新的 opcode，`AUTH` opcode 可以讓 Alice's EOA 授權給 Invoker Contract，使其可以以 `AUTHCALL` 以 Alice's EOA 做為 sender 和其他合約互動 143 | - 3074 並不會讓 EOA 的 code region 固定，而是以簽名讓 EOA 暫時可以使用 Invoker Contract 的邏輯。7702 則會直接去修改 EOA 的 code region 144 | - https://eips.ethereum.org/EIPS/eip-3074 145 | 146 | ### 2025.05.22 147 | 148 | #### 和 3074 的比較 149 | 150 | - 3074 引入兩個新的 opcode，`AUTH` opcode 可以讓 Alice's EOA 授權給 Invoker Contract，使其可以以 `AUTHCALL` 以 Alice's EOA 做為 sender 和其他合約互動 151 | - 3074 並不會讓 EOA 的 code region 固定，而是以簽名讓 EOA 暫時可以使用 Invoker Contract 的邏輯。7702 則會直接去修改 EOA 的 code region 152 | - https://eips.ethereum.org/EIPS/eip-3074 153 | 154 | 155 | -------------------------------------------------------------------------------- /wodeche.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | # Ellen 5 | 6 | 1. 自我介绍: 大家好，我是 Wodeche 7 | 2. 你认为你会完成本次残酷学习吗？： 能 8 | 3. 你的联系方式（推荐 Telegram）: @wodeche1 9 | 10 | ## Notes 11 | 12 | 13 | 14 | ### 2025.07.11 15 | 16 | 笔记内容 17 | 18 | ### 2025.07.12 19 | 20 | 21 | -------------------------------------------------------------------------------- /xwwkk.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍 11 | Kevin 12 | 2. 你认为你会完成本次残酷学习吗？ 13 | 会，而且想对安全方面进行更加深度的挖掘。 14 | 3. 你的联系方式（推荐 Telegram） 15 | @Kev1nWeb3 16 | 17 | ## Notes 18 | 19 | 20 | 21 | ### 2025.05.14 22 | 23 | #### Day1 研究EIP-7702的过去：从账户抽象到原生合约钱包的演化 24 | 在以太坊中，传统的 EOA（外部拥有账户）功能有限且风险较高，因此，如何对 EOA 账户进行抽象和拓展，一直是许多过去提案试图解决的重要目标。 25 | - EIP-4337 26 | - EIP-3074 27 | - EIP-5003 28 | 29 | 只有在了解先前这些提案的基础上，我们才能对 EIP-7702 有一个更加完整和深入的认识。 30 | ##### EIP-4337 31 | 账户抽象（Account Abstraction） 32 | 通过高层基础设施实现账户抽象，避免更改共识层协议。主要组件包括： 33 | - 智能合约钱包：链上部署的合约，管理用户账户权限和资源。 34 | - Bundler：EOA钱包，代表用户验证和执行UserOperation交易。 35 | - Entry Point Contract：链上全局合约，Bundler通过它执行UserOperation，充当Bundler与智能合约钱包的中介。 36 | - Paymaster：实现Gas抽象，支持用ERC20代币支付Gas或无Gas交易。 37 | - Wallet Factory：用于创建智能合约钱包的合约。 38 | - Signature Aggregator：优化签名验证，降低交易成本。 39 | 整体流程： 40 | 1. 用户通过前端构造UserOperation以及签名 41 | 2. Bundler收集UserOperation，并验证签名的有效性，将其打包成批量交易（Paymaster介入，可以用ERC20代币支付Gas或无Gas交易； Signature Aggregator用于优化签名验证，降低交易成本） 42 | 3. Entry Point Contract收到Bundler的批量交易，调用智能合约钱包执行UserOperation，交易上链。 43 | 目前的一些数据（2025/5/14） 44 | ETH： 45 | 61,115 Accounts, 277,345 UserOps, 278,291 Transactions, 400.31 ETH gas, 125.8517 ETH revenue(Bundler) 46 | ##### EIP-3074 47 | 在EVM中引入了两条新指令`AUTH`和`AUTHCALL`，允许外部拥有账户（EOA）将其控制权委托给智能合约，从而实现批量交易、Gas 赞助、交易到期设置和脚本化操作等功能。这增强了 EOA 的灵活性和用户体验，与智能合约钱包的部分功能类似，但无需更改账户类型。 48 | ##### EIP-5003 49 | 引入了一个新的操作码`AUTHUSURP` 50 | EOA先通过EIP-3074的机制授权某个智能合约，然后`AUTHUSURP`允许将代码直接部署到这个EOA的地址上 51 | 52 | ### 2025.05.15 53 | 54 | #### Day2 EIP-7702 55 | EIP-7702 引入了一种机制，允许 EOA（外部拥有账户）通过授权将执行委托给智能合约，同时保留 EOA 的核心特性。 56 | **工作原理** 57 | 58 | 1. 用户使用 EOA 私钥签署一条特殊授权消息，指定委托的智能合约 59 | 2. 授权包含在交易中，提交至以太坊网络。 60 | 3. 网络记录该 EOA 的委托状态，未来对该 EOA 的交易将执行指定智能合约的代码 61 | 4. 交易中的 msg.sender 保持为 EOA 地址，而非智能合约地址 62 | **重要保留** 63 | 64 | EOA 的私钥保留最终控制权，可通过签署新交易覆盖或撤销任何授权 65 | **主要功能** 66 | 67 | 1. 交易批处理：允许将多个操作打包成单笔交易，由智能合约执行，提升效率 68 | 2. 费用赞助：智能合约可实现 gas 费用由第三方支付，降低用户直接支付的负担 69 | 3. 权限管理：智能合约可定义复杂的权限逻辑，增强 EOA 的功能（如限制性执行规则） 70 | EIP-7702是一个平衡创新与实用性的提案，为以太坊用户提供了灵活的账户抽象功能，特别是在交易批处理和费用赞助方面 71 | 72 | ### 2025.05.18 73 | 74 | #### Day5 EIP-7702的安全问题 75 | EIP-7702引入一个新的交易类型，是通过一个委托指针来指定一个智能合约来执行相关逻辑，主要包括一个授权列表包括\[chain_id, address, nonce, y_parity, r, s\] 76 | 77 | **可能的漏洞** 78 | 79 | 1. 权限控制：智能合约中的函数相关的权限控制未合理设置，其他用户可能调用合约来转账授权钱包内的货币 80 | 2. 初始化：初始化抢跑，在用户delegate后再进行初始化，初始化操作存在被抢跑风险 81 | 3. 存储冲突：delegate调用的合约中的相关存储类型不同，如contractA中为boolean，user 授权 A delegatecall B，contractB中为uint 82 | 83 | **具体的例子** 84 | 85 | 1. 用`tx.origin == msg.sender`阻止合约账户的调用可能存在风险，来防御闪电贷和重入攻击的方式可能存在巨大风险 86 | 87 | 原因是EOA不能执行代码的基本逻辑被改变了，加大了被攻击的概率 88 | 如EOA账户委托给恶意合约，合约在fallbalk函数中对目标合约进行重入；EOA账户委托给闪电贷合约，贷取一定的货币进行套利，原有的防御无法判断是否为合约调用 89 | 90 | 2. 合约地址判断的失效（isContract(address)） 91 | 92 | 通过`extcodesize/code.length`来判断是否是合约地址可能会失效，原因是有委托的EOA账户中也存有字节码，无法正确判断 93 | 94 | 3. EOA账户接受代币异常 95 | 96 | 原先对EOA账户的转账是非常简单的，可是EIP-7702后，对有委托的EOA账户进行转账可以也存在拒绝收款的操作（实际上调用了委托合约的fallback函数） 97 | 98 | **安全建议** 99 | 100 | 设计新合约时，请假设“无代码”的EOA账户最终可能不复存在`tx.origin`。 101 | 102 | ### 2025.05.19 103 | 104 | 计划利用EIP-7702实现自由组合多笔交易的合约 105 | 106 | #### 规划阶段 107 | 108 | 目标：深度理解 EIP-7702 的应用场景。 109 | 110 | 功能需求： 111 | 支持用户通过单个 EIP-7702 交易调用多个智能合约操作，如转账、代币交换、NFT 铸造等。 112 | 113 | 允许动态指定目标合约、函数调用和参数，实现交易的自由组合。 114 | 115 | 优化 Gas 消耗，通过批量执行减少多次交易的开销。 116 | 117 | 确保安全性，处理异常情况（如部分交易失败）。 118 | 119 | 提供用户友好接口，方便提交批量交易请求。 120 | 121 | 122 | 123 | 124 | 125 | 126 | -------------------------------------------------------------------------------- /ygy-1231.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍 11 | 从事区块链的前端开发一年 12 | 2. 你认为你会完成本次残酷学习吗？ 13 | 会。 14 | 3. 你的联系方式（推荐 Telegram） 15 | Guangyu Yu 16 | 17 | ## Notes 18 | 19 | 20 | 21 | ### 2025.05.14 22 | 23 | 笔记内容 24 | 25 | ### 2025.05.18 26 | 27 | 28 | -------------------------------------------------------------------------------- /york.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍 York 11 | 2. 你认为你会完成本次残酷学习吗？ I will do my best. 12 | 3. 你的联系方式（推荐 Telegram）Telegram group -> York 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | #### EIP-7702 20 | Key Points 21 | 1. What is EIP-7702 22 | 2. How it works? 23 | 3. What is Set Code? 24 | 4. Difference between EIP-4337 and EIP-3074 25 | 26 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day01.md 27 | 28 | ### 2025.05.15 29 | #### Security Risk of EIP-7702 30 | Key Points 31 | 1. Private Key Leakage Risk 32 | 2. Delegated Contract Vulnerabilities Affect All Delegators 33 | 3. Storage Collision and Incompatibility Risk 34 | 4. Cross-Chain Replay Attack 35 | 5. Fake Deposit Risk 36 | 6. Account Conversion Breaks Security Assumptions 37 | 7. No Constructor Initialization Risk 38 | 8. Phishing and User Misguidance Risk 39 | 40 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day02.md 41 | 42 | 43 | ### 2025.05.16 44 | #### Follow EIP-7702 sample code 45 | Key Points 46 | 1. Prepare the environment 47 | 2. Sample Code Review 48 | 3. Local Testing and Deployment 49 | 4. Thoughts 50 | 51 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day03.md 52 | 53 | ### 2025.05.17 54 | #### EIP-7702 potential vulnerabilities POC 55 | Key Points 56 | 1. Dangers of EIP-7702 57 | 2. Proof of Concept (POC) 58 | 3. Metamask Smart Account 59 | 60 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day04.md 61 | 62 | ### 2025.05.18 63 | #### EIP-7702 Modular Architecture with PREP 64 | Key Points 65 | 1. What is PREP (Programmable Runtime EOA Proxy) 66 | 2. Stateless delegation and modular logic 67 | 3. Why modular Smart Accounts matter 68 | 69 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day05.md 70 | 71 | ### 2025.05.19 72 | #### Persistent Delegation and Multi-chain Use 73 | Key Points 74 | 1. Moving from single-use to persistent delegation 75 | 2. Cross-chain authorization with `chainId = 0` 76 | 3. Smart Account evolution: 4337, 7702, and beyond 77 | 78 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day06.md 79 | 80 | ### 2025.05.20 81 | #### Future of EIP-7702 and Modular Account Ecosystem 82 | Key Points 83 | 1. How EIP-7702 fits into ERC-6900 modular AA 84 | 2. Delegation as plug-in logic 85 | 3. ZyFi’s vision: infra-light, user-first abstraction 86 | 87 | Notre Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day07.md 88 | 89 | ### 2025.05.21 90 | #### Real-world EIP-7702 Application: Ambire Wallet 91 | Key Points 92 | 1. How Ambire integrates EIP-7702 into its wallet 93 | 2. Gasless transactions and ERC-20 fee payment 94 | 3. Temporary smart account logic with no address change 95 | 4. Batch execution and transaction simulation 96 | 5. Recovery and session key support for secure UX 97 | 98 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day08.md 99 | 100 | 101 | ### 2025.05.22 102 | #### Real-world EIP-7702: Privy and ZeroDev 103 | Key Points 104 | 1. Sign EIP-7702 authorizations with embedded wallets 105 | 2. Enable gasless transactions with Paymaster via ZeroDev 106 | 3. Configure custom wallet UI using PrivyProvider 107 | 4. Create temporary smart accounts (7702 kernel) via SDK 108 | 109 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day09.md 110 | 111 | 112 | ### 2025.05.23 113 | #### Advanced EIP-7702: Insecure Delegation Patterns in Practice 114 | Key Points 115 | 1. Unprotected execute() calls drain delegated accounts 116 | 2. The Illusion of Guardians 117 | 3. Anyone Can Initialize: Insecure Setup of Delegated Contracts 118 | 4. Replayable Signatures: Initialization Can Be Cloned Across Chains 119 | 5. Upgrade and Storage Collision 120 | 6. Replay Attack: oneTimeSend Without Nonce Allows Unlimited Withdrawals 121 | 7. Safe Upgrade with Nonce and Slot Cleanup 122 | 123 | Note Link: https://github.com/Yorkchung/EIP-7702-Learning/blob/main/Day10.md 124 | 125 | 126 | -------------------------------------------------------------------------------- /yushiwuzheng666.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+8 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # yushiwuzheng666 9 | 10 | 1. 自我介绍:我是Marshal，第二次参与残酷共学，继续学习，gogogogo 11 | 2. 你认为你会完成本次残酷学习吗？会 12 | 3. 你的联系方式（推荐 Telegram）@dashuaiff 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.07.11 19 | 20 | 笔记内容 21 | 22 | ### 2025.07.12 23 | 24 | 25 | -------------------------------------------------------------------------------- /zion.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: UTC+2 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区(UTC)，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | 7 | 8 | # 你的名字 9 | 10 | 1. 自我介绍：我是 Zion，目前是一名合约开发者，熟悉 EVM 与 Solana 智能合约开发，基于跨链协议 LayerZero 开发了跨链 Token 与 Dex 合约。 11 | 2. 你认为你会完成本次残酷学习吗？I wish I can 12 | 3. 你的联系方式（推荐 Telegram）X: zlog_in 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.05.14 19 | 20 | #### EIP-7702 速览 21 | 22 | * EIP-7702 目的是将 EOA 账号托管给合约账号，通过引入新的交易类型 `0x04` 实现授权托管与取消托管。 23 | * `0x04` 交易结构： `[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list,y_parity r, s]` 24 | * 其中：`authorization_list = [[chain_id, address, nonce, y_parity r, s], ...]`。 25 | * `authorization_list` 是一组 7702 签名数据，通过 `y_parityr,s` 获取 EOA Signer 地址，并将 `signer.code` 设置为 `0xef0100+address`, `address` 为目标合约地址，如果为〇地址，则为取消授权。 26 | * `0x04` 交易其实是在 `0x03` (EIP-1559)基础上，挂载了一个额外的字段 `authorization_list` ，此字段内容将实现一组授权托管/取消托管操作；外部交易数据依然为一笔正常`0x03`交易，即可以为转账，或合约调用。`0x03` 部分与 `authorization_list` 可彼此独立 27 | * 更详细内容可参见[此资料](https://docs.google.com/presentation/d/1CGHSzlRl-d8nxzPtAYF6Aq5wkCORvxg3SFs96TICAPg/edit?usp=sharing) 28 | 29 | ### 2025.05.15 30 | 31 | #### EIP-7702 影响 32 | * 在 EIP-7702 之前，以太坊 EOA 账号存在一些严格约束：只有私钥才能减少 EOA 账号的 ETH 余额；EOA 账号的 Code 与 Storage 为空；一笔 tx 最多只能将 EOA nonce + 1。 33 | * 在 EIP-7702 之后，Smart EOA （被授权给智能合约的 EOA）余额可由合约代码控制；Smart EOA 的 Code 与 Storage 不再为空，其中 Storage 管理应遵循特定标准，例如[ERC-7201](https://eips.ethereum.org/EIPS/eip-7201)；一笔由 EOA signer 提交的 `0x04` 交易可将 signer nonce + 2。 34 | * 在 EIP-7702 之后，Smart EOA 与 SC 之间界限模糊，仅凭之前的 `address.code.length > 0` 将无法区分，其判断逻辑应如下所示 35 | ``` 36 | ┌────────────────────────┐ 37 | │address.code.length > 0 ├──────────────────► pure eoa 38 | └───────────┬────────────┘ no 39 | │ 40 | │ yes 41 | │ 42 | ▼ 43 | ┌────────────────────────────────────┐ 44 | │ │ 45 | │ address.code.legth == 23 ├──────────► smart contract 46 | │ && address.code.hasPrefix 0xef0100 │ no 47 | │ │ 48 | └────────────────┬───────────────────┘ 49 | │ 50 | │ yes 51 | │ 52 | ▼ 53 | smart eoa 54 | ``` 55 | 56 | ### 2025.05.16 57 | 58 | #### EIP-7702 细节 59 | * 7702 签名过程：`cast wallet sign-auth address --private-key $PRIVATE_KEY --chain chain_id --nonce nonce ==> [chain_id, address, nonce, y_parity r, s]` 60 | * 其中 `address` 地址可以是：一本智能合约地址，或者另外一个 Pure EOA（无效授权）；但不能是另外一个 Smart EOA。 61 | 62 | ### 2025.05.17 63 | 64 | #### EIP-7702 风险 65 | * 7702 签名由钱包工具支持，特别注意的是要严格检查 `chain_id` 与 `nonce`。如果 `chain_id == 0`，则意味该授权签名有可能被重复至其他 EVM 链上，前提是 nonce 刚好匹配。 66 | * 在执行 7702 初次授权时，无法保证授权与 Smart EOA 存储状态的初始化同时发生，因此合约代码的初始化函数需要检查 `msg.sender == address(this)`，确保 Smart EOA 仅能通过私钥初始化。 67 | * 在执行 7702 再授权时，应谨慎管理 Smart EOA 的存款空间，尽量避免存储冲突。最近实践是遵守ERC-7201标准，将存储空间离散化，以尽可能减少冲突风险。 68 | * 因为 Smart EOA 可以调用自身合约接口，通过 `tx.origin == msg.sender` 来判断调用者否是为 EOA 将失效。 69 | * 最大的风险是钓鱼攻击，即用户被诱导授权签名，将 EOA 授权给一本恶意合约，EOA 资产将有合约代码彻底控制。 70 | 71 | ### 2025.05.18 72 | #### EIP-7702 展望 73 | * 通过 EIP-7702 协议，传统私钥控制的 EOA 账号托管给智能合约代码。在不交出私钥的前提下，将 EOA 控制权转交给智能合约，同时保留私钥拥有撤销托管的能力。 74 | * 通过特定合约的实现与链外组件的配合，可帮助用户实现无 gas 交互，无需用户支付 gas fee。 75 | * 可选的 Authorization 包括 WebAuth、Passkey， 来辅助对 EOA 的访问鉴权，将降低链上交互的门槛。 76 | 77 | ### 2025.05.19 78 | #### EIP-7702 应用场景 79 | * 通过 EIP-7702，可以实现智能钱包的升级，将传统 EOA 钱包转变为可编程钱包，支持多签、社交恢复等高级功能。 80 | * 在 DeFi 应用中，用户可以将 EOA 授权给特定的 DeFi 合约，实现自动化的投资策略和风险管理。 81 | * 通过合约托管，可以实现更复杂的交易逻辑，如批量交易、条件触发交易等，提升用户体验。 82 | 83 | ### 2025.05.20 84 | #### EIP-7702 实现建议 85 | * 在开发支持 EIP-7702 的合约时，建议实现标准的接口，如 `IERC7702`，以便于其他合约进行交互和集成。 86 | * 合约应该实现完善的权限管理机制，包括授权管理、撤销机制和紧急暂停功能。 87 | * 建议在合约中实现事件日志，记录所有授权和撤销操作，便于链上追踪和审计。 88 | 89 | ### 2025.05.21 90 | #### EIP-7702 安全影响 91 | * EIP-7702 的长期安全影响主要体现在智能合约的权限管理上。通过将 EOA 的控制权委托给智能合约，实际上是将安全责任从用户转移到了合约代码上。 92 | * 合约代码的质量和安全性将直接影响到用户资产的安全。因此，合约审计和形式化验证变得更加重要。 93 | * 由于 Smart EOA 可以执行更复杂的操作，攻击面也随之扩大。合约开发者需要更加注重安全最佳实践，如重入攻击防护、权限检查等。 94 | * 长期来看，可能会出现专门针对 Smart EOA 的新型攻击方式，需要持续关注和研究。 95 | 96 | ### 2025.05.22 97 | #### EIP-7702 隐私影响 98 | * EIP-7702 对用户隐私的影响主要体现在链上数据的可追踪性上。Smart EOA 的所有操作都会被记录在区块链上，增加了用户行为的可追踪性。 99 | * 通过分析 Smart EOA 的调用模式，可能会泄露用户的交易习惯和偏好，这对隐私保护提出了新的挑战。 100 | * 长期来看，可能需要开发新的隐私保护机制，如零知识证明或混币技术，来保护 Smart EOA 用户的隐私。 101 | * 合约开发者需要在功能实现和隐私保护之间找到平衡点，避免过度收集用户数据。 102 | 103 | ### 2025.05.23 104 | #### EIP-7702 便利性影响 105 | * EIP-7702 的长期便利性影响主要体现在用户体验的改善上。通过智能合约托管，用户可以享受更丰富的功能和更便捷的操作。 106 | * 无 gas 交易、批量操作、自动化策略等功能的实现，将大大降低用户使用门槛，提升用户体验。 107 | * 长期来看，可能会出现更多创新的应用场景，如社交恢复、多签管理等，进一步简化用户操作。 108 | * 随着工具和基础设施的完善，Smart EOA 的使用将变得更加简单和直观，推动更多用户采用。 109 | --------------------------------------------------------------------------------