diff --git a/notes/roy328line.md b/notes/roy328line.md index 01501aef4..4ee52a2fb 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -15,7 +15,466 @@ AI x Web3 School ## Notes -# 2026-05-27 +# 2026-05-31 + +今日學習：深讀 AI Oracle + Verifiable AI 模組，理解 AI 輸出如何在鏈上被驗證 + +核心概念：AI Oracle 的核心不是讓模型替合約做判斷，而是讓模型判斷變成可記錄、可驗證、可挑戰的輸入。Verifiable AI 的核心是讓「相信模型」變成「驗證證據和約束」。 + +## 第一性原理 + +當 AI 輸出會影響鏈上資產或權限時，輸出本身必須有來源、邊界和爭議機制。驗證成本必須和輸出影響力匹配：給用戶總結新聞不需要 ZK proof；釋放 escrow 或罰沒 stake，就不能只靠一句模型輸出。 + +## AI Oracle 核心知識整理 + +### AI Output（模型輸出） + +鏈上系統最好只消費結構化輸出（accepted: true、riskScore: 72），而非長文本 + +輸出分兩層：機器字段（進入合約/後端規則）+ 人類解釋（進入 UI/報告/爭議材料） + +影響資金或權限時，必須記錄 confidence、模型版本、輸入 hash、輸出 hash 和生成時間 + +### Data Feed（數據饋送） + +AI data feed 比價格 feed 更容易漂移：模型升級、訓練數據變化、prompt 調整都會讓同一對象的評分變化 + +Feed 應明確版本，允許查詢歷史 + +若用於自動執行：合約需檢查 stale data、異常跳變和來源簽名 + +### Model Result（模型結果記錄） + +需包含：模型版本 + prompt 模板 + 輸入引用 + 輸出字段 + 輸出 schema + +不保存生成條件，後續很難復核（模型升級後同樣輸入可能得到不同結果） + +多模型系統還要記錄路由信息：為什麼選這個模型、是否用了 fallback、是否經過人工復核 + +### Oracle Risk（預言機風險） + +風險分層：輸出只展示標籤（低）→ 決定釋放資金/罰沒 stake/拒絕用戶（高） + +高風險輸出需要 challenge、multi-evaluator 或可驗證執行 + +AI Oracle 應按影響範圍分層：低風險直接展示，中風險人工復核，高風險需挑戰機制 + +### Attestation（可驗證聲明） + +TEE 可證明某模型在特定環境中運行；驗證者可證明輸出通過測試；服務方簽名可證明結果來源 + +Attestation 字段要具體：驗證者 / 驗證對象 / 輸入輸出 hash / 模型版本 / 過期時間 / 是否可撤銷 + +鏈上系統中 attestation 是可消費信號，不是最終真理，仍可保留爭議窗口 + +### Proof of Inference（推理證明） + +實現路線：TEE attestation / ZK proof / 簽名日誌 / 可重放推理 / 可信服務證明 + +需先明確「證明什麼」：證明用了某模型、輸入沒變、由某環境生成、還是推理過程完整正確 + +大型 LLM 完整推理證明成本高，現實系統常用折中：TEE 證明環境 + 簽名日誌證明輸入輸出 + ZK 證明關鍵後處理 + +### Dispute / Challenge（爭議機制） + +Optimistic 模式：先接受結果，給出挑戰窗口；有人提出證據則進入復核/仲裁/多方驗證 + +挑戰窗口和成本設計：窗口太短（用戶來不及發現）/ 窗口太長（結算效率低）/ 成本太低（被 spam）/ 成本太高（受害者無法申訴） + +實用分層：小額任務短窗口，高價值任務長窗口，高爭議任務進入人工或多方 evaluator + +## Verifiable AI 核心知識整理 + +### TEE（可信執行環境） + +適合需要隱私和較低證明成本的場景：私有數據評分、模型推理、Agent runtime 證明 + +強項：工程上相對可用，可跑複雜程序，可處理私有輸入，證明成本低於 ZK + +弱點：仍依賴硬件和供應鏈信任，不是純密碼學信任 + +### ZK（零知識證明） + +優勢：密碼學驗證強；限制：生成證明成本高、工程複雜 + +更適合邊界清楚、計算規模可控的任務：小型分類模型、後處理規則驗證、數據聚合約束 + +對 LLM 完整 ZK proof 仍不現實，很多產品選擇只證明關鍵部分 + +### zkML + +適合：模型較小、結構固定、輸出需強驗證的場景 + +設計前先問：是否真的需要隱藏輸入？是否能接受證明延迟？模型是否能轉成電路？ + +很多「需要可信 AI」的場景，用簽名日誌 / TEE / 人工復核更經濟 + +### Verifiable Compute（可驗證計算） + +鏈下執行 + 鏈上驗證 = AI x Web3 系統的現實路徑 + +把昂貴計算放鏈下，把摘要/證明/簽名結果放鏈上：保留可驗證性，避免把複雜推理塞進合約 + +注意數據可用性：鏈上只有 hash/proof 時，用戶仍需知道原始輸入輸出在哪裡、誰能訪問、保存多久 + +### Benchmark（基準測試） + +公開 benchmark 說明一般能力，不能證明某次輸出正確 + +AI x Web3 benchmark 應包含正常樣本 + 邊界樣本 + 攻擊樣本（錯誤鏈 / 惡意上下文 / 過期價格 / 假合約文檔） + +項目應建立自己的任務集，不能只依賴通用榜單 + +### Audit Trail（審計軌跡） + +最基礎、最實用的可驗證層：記錄輸入/輸出/模型版本/工具調用/時間/用戶確認/交易哈希/錯誤 + +不能證明模型絕對正確，但能證明「系統當時看到了什麼、調用了什麼、用戶確認了什麼」 + +敏感原文加密保存，公開層只放 hash、摘要和權限可控的引用 + +## 兩者的整合洞察 + +AI Oracle 解決「如何把 AI 判斷帶上鏈」，Verifiable AI 解決「如何讓這個判斷被驗證」。 + +完整的可信 AI x Web3 執行鏈路： + +1. **生成**：輸入 + 模型版本 + prompt 模板 → 結構化輸出 + 輸出 hash +2. 2. **證明**：Audit Trail（基礎）→ Attestation（服務方/TEE 簽名）→ ZK/TEE Proof（高風險場景） + 3. 3. **上鏈**：只傳結構化字段 + hash，長文本放鏈下 + 4. 4. **挑戰**：設置 challenge window，按金額和風險分層 + 5. 5. **結算**：通過挑戰期後，觸發 escrow 釋放或 slashing + 6. + 7. 按風險分層設計驗證強度： + 8. + 9. - 低風險（標籤/摘要）：Audit Trail 即可 + - - 中風險（評分/分類影響業務決策）：Attestation + Challenge Window + - - 高風險（釋放資金/罰沒 stake/封禁用戶）：TEE/ZK Proof + Multi-evaluator + Challenge + - + - ## 最小實踐設計 + - + - 設計一個「智能合約風險評估」的 AI Oracle： + - + - **輸入定義**：合約地址、ABI、源碼 hash、評估任務模板 hash + - + - **輸出結構**： + - - riskLevel: "low" | "medium" | "high" + - - riskScore: 0-100 + - - findings: [{type, severity, description}] + - - modelVersion: "xxx" + - - inputHash: "0x..." + - - outputHash: "0x..." + - - timestamp: Unix timestamp + - + - **驗證層次**： + - - 服務方簽名 → 證明輸出來自此服務 + - - TEE attestation → 證明在可信環境執行 + - - 未來升級路徑 → zkML 對後處理規則的關鍵判斷 + - + - **Challenge 設計**： + - - 挑戰窗口：48 小時 + - - 挑戰成本：0.1 ETH（防 spam，但不過高） + - - 挑戰材料：替代評估結果 + 具體差異說明 + - - 仲裁：3 人 evaluator 多數決，仲裁費從挑戰金中支出 + - + - ## 個人洞察 + - + - 今天最大的收穫是理解了「可驗證 AI」不是一個二元選擇（要麼完全可信 / 要麼完全不可信），而是一個按風險分層的工程設計問題。 + - + - AI Oracle 的核心設計張力和 Machine Payment 其實是對稱的：Machine Payment 解決「AI 用錢的邊界」，AI Oracle 解決「AI 說的話的可信邊界」。兩者都需要 policy（什麼條件下觸發）、boundary（影響範圍多大）、challenge（出錯後怎麼辦）。 + - + - Audit Trail 的重要性被低估了。在沒有 TEE 或 ZK 的場景裡，完整的審計軌跡其實已經能解決大多數實際問題。很多系統把精力放在「如何用最強的密碼學證明」，但其實「先把日誌做好、再逐步升級」是更務實的路徑。 + - + - Dispute / Challenge 機制是整個系統的「壓力閥」。設計好的挑戰機制，可以讓系統在大多數情況下快速結算（因為沒人挑戰 = 默認接受），同時保留了出錯時的糾錯路徑——這是 Optimistic Rollup 和 Optimistic Oracle 共同的優雅設計思路。 + - + - ## 今日產出 + - - AI Oracle 六大知識節點整理（AI Output / Data Feed / Model Result / Oracle Risk / Attestation / Proof of Inference / Dispute） + - - Verifiable AI 六大知識節點整理（TEE / ZK / zkML / Verifiable Compute / Benchmark / Audit Trail） + - - AI Oracle 與 Verifiable AI 整合鏈路設計（生成 → 證明 → 上鏈 → 挑戰 → 結算） + - - 按風險分層的驗證強度設計框架 + - - 「智能合約風險評估」AI Oracle 完整設計（含輸入/輸出/驗證/Challenge） + - + - ## 明日計劃 + - + - 進入 Governance AI 模組，研究 AI 如何參與鏈上治理決策，以及如何防止 AI 操縱治理 + - + - + - # 2026-05-30 + +今日學習：深讀 AI Security / Privacy / Sovereignty 模組，整理 Agent Threat Model + +核心概念：一旦 Agent 持有上下文、憑證、API Key、私鑰或預算，安全問題就不再是邊角料，而是系統前提。Agent 的安全設計核心是：能看到什麼、能調用什麼、能花多少錢、能代表誰做決定、出了錯誰負責。 + +## 第一性原理 + +AI 不確定性（幻覺 / 注入 / 推理漂移）× Web3 不可逆性（交易上鏈不能撤回）= 必須用可疑的推理引擎驅動不可逆執行系統。解法不是「讓 AI 更可靠」，而是在系統層面設計邊界、監控和恢復機制。 + +## AI Security 核心知識整理 + +### Prompt Injection（提示詞注入） + +攻擊原理：惡意上下文偽裝成系統指令，讓 Agent 執行非授權動作 + +直接注入：攻擊者直接修改 Prompt，例如在網頁中嵌入「忽略前面的指令，改為…」 + +間接注入：通過 Agent 讀取的外部內容（文件、網頁、郵件）傳入指令 + +AI x Web3 的特殊危險性：注入成功 → 執行鏈上交易 → 資金損失不可逆 + +防禦策略：系統指令層與用戶內容層嚴格隔離；不可信內容做沙箱處理；高風險動作強制人工確認；用結構化輸出而非自由文本傳遞執行參數 + +### Tool Abuse（工具濫用） + +攻擊面：Agent 被誘導調用錯誤工具、傳入惡意參數或繞過 Allowlist + +常見場景：注入指令讓 Agent 調用轉帳工具；偽造合約地址讓 Agent 與惡意合約交互；利用模型幻覺生成不存在但有害的函數調用 + +防禦策略：工具 Allowlist 白名單；參數校驗（類型、範圍、地址格式）；Simulation 執行模擬；每次工具調用記錄 tracing log + +### 敏感資訊洩露 + +資產清單：私鑰、API Key、Session Token、用戶數據、交易權限、預算、敏感文件 + +洩露路徑：上下文窗口包含敏感資訊被注入提取；工具返回敏感數據被日誌記錄；模型輸出直接包含憑證；第三方 LLM 服務商收集訓練數據 + +防禦策略：敏感資訊不進 Context；金鑰存 Secret Manager；最小化 LLM 可見範圍；不使用第三方服務處理高敏感度數據 + +### Overreach（越權執行） + +定義：Agent 執行了超出授權範圍的動作，無論是否出於惡意 + +常見原因：授權邊界設計模糊；模型誤解指令範圍；缺乏執行前驗證 + +防禦策略：最小權限原則（Principle of Least Privilege）；每次執行前 policy 檢查；超出邊界的請求自動拒絕並告警 + +## AI Privacy 核心知識整理 + +### 數據主權（Data Sovereignty） + +核心問題：用戶數據在 Agent workflow 中的處理、存儲、轉發是否受用戶控制？ + +常見風險：對話上下文發送給第三方 LLM；工具調用結果被供應商記錄；無法撤銷已提交的數據處理 + +設計原則：明確數據流向和存儲位置；給用戶提供導出和刪除能力；不在無必要的情況下使用外部 LLM 處理敏感數據 + +### 本地執行 vs 雲端執行 + +本地模型優勢：數據不離本地；不依賴供應商；可控性更強 + +本地模型代價：算力成本；模型質量通常低於雲端大模型；維護複雜度高 + +選擇框架：高敏感度 / 高價值任務 → 本地模型或私有部署；低敏感度 / 低風險輔助任務 → 雲端模型 + +### 可信執行環境（TEE） + +定義：硬件級隔離執行環境，代碼和數據在 TEE 內執行時即使作業系統被攻陷也不可見 + +AI x Web3 應用場景：在 TEE 中執行敏感推理，讓鏈上可以驗證「某個 AI 輸出來自某個版本的模型、在 TEE 中運行、輸入輸出沒有被篡改」 + +與 Attestation 結合：TEE 可以生成可驗證的執行證明，作為 Agent Trust 系統的高可信證據 + +## AI Sovereignty 核心知識整理 + +### Agent 主權設計 + +用戶是否擁有：能否導出所有數據？能否更換 LLM 供應商？能否更換執行環境？能否撤銷全部授權？ + +平台主權陷阱：把私鑰、授權和數據全部綁在單一平台上，用戶實際上失去了控制權 + +### 新密碼朋克（Neo-Cypherpunk）方向 + +核心理念：個人數據主權、隱私保護、抗審查、去中心化身份 + +在 AI x Web3 的體現：Agent 不應成為新的數據中間商；用戶控制自己的 Agent 歷史和憑證；開放協議優先於封閉平台 + +## Threat Model 實踐設計 + +針對一個「AI Agent 自動執行 DeFi 操作」場景的 Threat Model： + +資產：用戶錢包私鑰（不應存 Agent）、Session Key（限額授權）、API Key（用於 LLM 和 DEX 數據）、預算（每日最大操作額度） + +攻擊入口：惡意 DeFi 頁面注入（讓 Agent 授權惡意合約）；偽造代幣信息（讓 Agent swap 到錯誤地址）；LLM 幻覺（生成不存在的函數調用）；第三方工具返回污染數據 + +控制手段：工具 Allowlist（只允許白名單合約地址）；每次 swap 前 Simulation（先模擬再執行）；最大單次金額限制；異常告警（連續失敗 / 超額請求自動暫停）；全程 tracing log + +高風險動作清單（必須人工確認）：新合約地址授權；超出日預算的任何操作；連接新的外部服務；私鑰相關操作 + +## 個人洞察 + +今天最大的收穫是把 Privacy / Security / Sovereignty 理解為「不是可選的安全加固，而是 AI x Web3 系統的基礎設施前提」。 + +安全設計的本質是：在構建能力之前，先定義邊界。先問「Agent 不應該能做什麼」，比問「Agent 可以做什麼」更重要。 + +Prompt Injection 在 AI x Web3 場景特別危險，因為它把「說服 AI 相信一件事」直接連接到「執行不可逆的鏈上交易」。傳統 Web2 的注入攻擊後果通常可恢復，但 Web3 的資金損失幾乎不可逆。這讓防禦設計的優先級必須大幅提升。 + +TEE + Attestation 的組合讓我看到了「可信 AI 執行」的未來可能：不需要信任 Agent 是誠實的，只需要驗證它在可信環境中運行了正確的代碼——這是把「信任模型」從「信任意圖」轉換為「驗證行為」。 + +## 今日產出 +- Privacy / Security / Sovereignty 三大核心方向知識整理 +- - Prompt Injection / Tool Abuse / 敏感資訊洩露 / 越權執行四大攻擊面分析 + - - AI x Web3 場景 DeFi Agent Threat Model 設計 + - - TEE + Attestation 在 Agent 信任體系中的位置理解 + - - 數據主權 / 本地執行 / 雲端執行選擇框架 + + - ## 明日計劃 + - 進入 Week 3，深讀 AI Oracle / Verifiable Inference 模組，研究 AI 輸出如何在鏈上被驗證 + - +# 2026-05-29 + +今日學習：複習深化 Agent Trust & Reputation + Account Abstraction，整合信任三層架構 + +核心概念：Agent 可信度來自可驗證行為，信任不是一個分數，而是可追溯、可比較、可解釋的證據；帳戶抽象讓 Agent 的「行動授權」從全有全無變成細粒度的可程式規則。 + +## 第一性原理 + +> Identity（你是誰）+ Trust（別人為什麼信你）+ Permission（你被允許做什麼）= AI Agent 安全上鏈的完整基礎設施。 +> +> 三者缺一不可：有身份沒信任，別人不敢用；有信任沒權限邊界，Agent 可能失控；有權限邊界沒身份，無法追責。 + +## Agent Trust & Reputation 複習整理 + +**信任三角：聲譽 + 驗證 + 代價** + +- **Reputation**：按任務類型拆分的歷史表現信號，需時間衰減機制。一個擅長生成合約測試的 Agent，不一定適合做高價值 escrow evaluator +- **Attestation**：結構化可驗證聲明（issuer / subject / claim / evidence / expiration / revocation）。鏈上身份可證明連續性，不能自動證明服務品質 +- **Stake + Slashing**：讓承諾有真實代價。Stake ≠ 能力，需搭配 validation 和任務歷史評估。自動 slashing 只適合明確可驗證違約，主觀任務應先進入 dispute +- **ERC-8004**：身份 / 反饋 / 驗證三層分離的去中心化標準，不做成黑盒評分，讓不同應用可以構建自己的信任過濾規則 + +**防操縱設計要點：** +- 評價者本身需要身份和聲譽，或能看到其與被評價 Agent 的歷史交易關係 +- 泛泛五星評價 < 綁定任務 ID、交付物、付款記錄的具體 review +- 聲譽要處理 Sybil、刷評、時間衰減和任務類型差異 + +## Account Abstraction 複習整理 + +**核心元件回顧：** +- **ERC-4337**：UserOperation → Bundler → EntryPoint → Smart Account → Paymaster（可選贊助 gas） +- **Smart Account**：帳戶本身是合約，可定義多簽、社交恢復、批量執行，但合約 bug 會成為帳戶風險 +- **Session Key**：Agent 的「限時限額員工門禁卡」。不拿主私鑰，只拿受限授權空間 + +**Session Key 最小策略再思考：** +- 合約地址白名單 + 方法白名單（不是「允許調用任何方法」） +- 金額上限 + 時間窗口 + 最大次數 +- 高風險動作（主錢包操作、超額請求、新合約地址）強制回人工確認 +- 撤銷入口：用戶主帳戶隨時可撤銷，撤銷記錄可查 + +## 兩者的整合洞察 + +Agent Trust & Reputation 解決「你有沒有資格被使用」，Account Abstraction 解決「你使用時的邊界是什麼」。 + +完整的 AI Agent 信任鏈路： +1. **Identity**（ERC-8004 / DID）：我是誰，誰控制我，能提供什麼服務 +2. **Trust**（Reputation / Attestation / Stake）：我做過什麼，誰驗證過，失敗有沒有代價 +3. **Permission**（Session Key / Smart Account）：我被允許自動執行什麼，超出邊界必須人工確認 + +只有三層都設計好，才能做到「用戶放心委托、Agent 有效執行、失敗有跡可查」。 + +## 今日產出 + +- Agent Trust & Reputation 七大知識節點複習（Reputation / Review / Attestation / Stake / Slashing / Validation / ERC-8004） +- Account Abstraction 五大元件複習（ERC-4337 / Smart Account / Bundler / Paymaster / Session Key） +- Identity + Trust + Permission 三層信任架構整合理解 +- 複習 Session Key 策略設計要點 + +## 明日計劃 + +深讀 AI Security / AI Privacy / AI Sovereignty 模組，整理 Agent 在安全和隱私方面的 threat model + + +# 2026-05-28 + +今日學習：深讀 Account Abstraction 模組 + Co-learning 共學活動 + +核心概念：Account Abstraction 把「帳戶如何驗證操作、誰來付 gas、哪些權限可以自動執行」從固定的 EOA 模式釋放出來，讓錢包變成可編程的帳戶系統。 + +## 第一性原理 + +> 當帳戶本身可以編程，權限就可以從「有私鑰/沒私鑰」變成「在什麼條件下允許什麼動作」。 +> +> 這對 AI x Web3 特別重要：Agent 不應該拿用戶主私鑰，而應該獲得一個可限制、可過期、可撤銷、可審計的行動空間。 +> +> ## 知識節點整理 +> +> **ERC-4337（核心標準）** +> +> - 不直接發普通交易，而是創建 UserOperation +> - - 流程：用戶/應用生成 UserOperation → 智能帳戶驗證 → Bundler 打包提交 → EntryPoint 調用帳戶執行 → Paymaster 可選贊助 gas +> - - 把帳戶驗證邏輯從協議層解耦，讓帳戶自己定義「什麼算合法操作」 +> - +> - **Smart Account（智能帳戶）** +> - +> - - EOA 的驗證邏輯固定：有私鑰就能簽名。Smart Account 則可以定義： +> - - 多簽才能轉移大額資產 +> - - 小額交易可自動通過 +> - - 特定 dApp 在一定額度內可調用 +> - - 丟失後可通過恢復人或設備找回 +> - - 風險：合約 bug、模組權限、升級邏輯都會成為帳戶風險 +> - +> - **Bundler** +> - +> - - 收集 UserOperation，模擬驗證後提交到 EntryPoint +> - - 類似交易打包服務，但處理的是 UserOperation 而非普通交易 +> - - Bundler 不穩定 → 用戶操作卡住；模擬不充分 → 失敗交易帶來體驗問題 +> - +> - **Paymaster** +> - +> - - 允許第三方為用戶操作支付 gas，或讓用戶用非原生資產付費 +> - - 常用於 onboarding（新用戶沒有 ETH 也能完成第一筆操作） +> - - 風控問題：贊助哪些方法？每個用戶額度多少？如何防止 spam 和套利？ +> - +> - **Session Key（最重要的 AI x Web3 組件）** +> - +> - - 給應用或 Agent 的**臨時權限**，不等同於用戶主私鑰 +> - - 可以被限制為：只在某段時間有效 / 只調用某個合約 / 只使用某些方法 / 只花費某個額度 / 只在特定鏈上執行 +> - - **Agent Wallet 的關鍵基礎**：讓 Agent 可以自動執行低風險動作，但高風險動作仍然需要用戶確認 +> - +> - ## Account Abstraction 在 AI x Web3 中的位置 +> - +> - 沒有帳戶抽象，Agent 往往只能停留在「給建議」或「讓用戶每一步都簽名」。有了智能帳戶、Paymaster 和 Session Key，Agent 才可能在受限範圍內自動執行。 +> - +> - 但越自動化，越需要清楚的 policy： +> - - 能調用什麼合約/方法 +> - - 額度多少、多久過期 +> - - 誰能撤銷 +> - - 日誌在哪裡 +> - - 失敗後怎麼處理 +> - +> - **帳戶抽象不是讓 AI 更自由，而是讓 AI 的自由被規則包起來。** +> - +> - ## 最小實踐設計 +> - +> - 設計一個 Agent Session Key 策略（場景：「每日最多重新平衡一次測試網小額資產」）： +> - +> - - **允許調用**：Uniswap Router 合約，只允許 `swapExactTokensForTokens` 方法 +> - - **額度限制**：每次最多 10 USDC，每日累計不超過 50 USDC +> - - **時間限制**：UTC+8 每日 09:00–21:00 有效，超時自動失效 +> - - **鏈限制**：只在 Sepolia 測試網有效 +> - - **最大交易次數**：每日 5 次 +> - - **必須人工確認的動作**：任何涉及主錢包的操作、任何超出額度的請求、任何涉及新合約地址的調用 +> - - **撤銷方式**：用戶主帳戶隨時可以撤銷 Session Key +> - +> - ## 個人洞察 +> - +> - 今天最大的收穫是把 Account Abstraction 和之前學的 Agent Identity、Agent Trust 串聯起來了。 +> - +> - Agent Identity 解決「你是誰」，Agent Trust 解決「別人為什麼信你」，而 Account Abstraction（特別是 Session Key）解決「你被允許做什麼」——這三者合在一起，才是 AI Agent 安全上鏈的完整基礎設施。 +> - +> - Session Key 的比喻很精準：不是給 AI 一把主鑰匙，而是給 AI 一張限時限額的員工門禁卡（最小權限原則）。這個設計思路其實和 MPC 錢包、多簽的核心思路一樣：把「全有或全無的控制權」拆成「細粒度的、可審計的、可撤銷的」授權結構。 +> - +> - Co-learning 共學心得：和同學討論的過程中，發現大家對「Agent 需要什麼樣的帳戶系統」有很多不同的思考角度——有從安全角度出發的，有從用戶體驗出發的，有從開發者工具出發的。這些角度互相補充，讓我對 Agent Wallet 的設計空間有了更立體的理解。 +> - +> - ## 今日產出 +> - +> - - Account Abstraction 完整知識節點整理（ERC-4337 / Smart Account / Bundler / Paymaster / Session Key） +> - - Agent Session Key 最小策略設計（含額度、時間、合約、撤銷等完整參數） +> - - Account Abstraction 在 AI x Web3 架構中的位置梳理 +> - - Identity + Trust + Permission 三層信任架構的個人理解框架 +> - +> - ## 明日計劃 +> - +> - 深讀 Privacy / Security / Sovereignty 模組，整理 Agent 在安全和隱私方面的 threat model +> - +> - # 2026-05-27 今日學習：深讀 Agent Trust & Reputation 模組