@@ -15,6 +15,139 @@ timezone: UTC+8
1515## Notes
1616
1717<!-- Content_START -->
18+ # 2025-08-16
19+
20+ ## 1. 安全范式之变:从被动防御到主动进攻
21+
22+
23+
24+ 顶级的安全不仅是写出没有漏洞的代码,更是构建在最坏情况下依然能维持系统不变性的架构,并主动用工具去攻击它。
25+
26+
27+
28+ ### 不变性测试 (Invariant Testing)
29+
30+
31+
32+ 这是思维上的一次飞跃。传统的单元测试验证的是“当输入X时,应输出Y”。而不变性测试验证的是“** 无论进行何种合法的操作序列,系统的某个核心属性必须永远为真** ”。
33+
34+ - ** 什么是不变性 (Invariant)?**
35+ - 一个 DeFi 借贷协议的“总借出量 + 总流动性”应永远等于“总存入量”。
36+ - 一个 AMM 池的 ` x * y = k ` (在不考虑费用的情况下)。
37+ - 一个代币合约的“总供应量”应永远等于“所有用户余额的总和”。
38+ - ** 如何实践?**
39+ - ** 模糊测试 (Fuzzing)** : 使用 ** Foundry 的模糊测试引擎** 或 ** Echidna** 等工具,生成海量的随机输入和随机函数调用序列,主动尝试去打破设定的“不变性”。如果工具找到了一个可以破坏不变性的交易序列,那么就发现了一个严重的安全漏洞。
40+ - ** 思维转变** : 从“我的代码能否正常工作?”转变为“** 我的代码在何种极端情况下会崩溃?** ”。
41+
42+
43+
44+ ### 形式化验证 (Formal Verification)
45+
46+
47+
48+ 这是智能合约安全的最高标准,通常用于数十亿美元级别的核心协议。
49+
50+ - ** 核心思想** : 使用严格的数学方法,将 Solidity 代码和一份正式的数学规范进行对比,以** 数学方式证明** 代码在任何可能的输入下都符合规范。
51+ - ** 过程** : 开发者需要用一种规范语言(如 Certora 的 CVL)来描述合约应该遵守的规则(例如,“只有管理员才能调用这个函数”,“用户的余额永远不会无故减少”)。然后,验证工具会尝试在代码中寻找任何违反这些规则的路径。
52+ - ** 意义** : 它能发现人类审计员或模糊测试都可能错过的、隐藏在极端逻辑深处的漏洞。
53+
54+ ------
55+
56+
57+
58+ ## 2. 跨链与多链架构的深思
59+
60+
61+
62+ “赢者通吃”的单链时代已经结束。未来的顶级应用必须是多链原生的。
63+
64+
65+
66+ ### 跨链通信的“不可能三角”
67+
68+
69+
70+ 理解跨链通信的核心挑战在于权衡:** 信任最小化、通用性、和扩展性** 。
71+
72+ - ** 信任最小化通信 (Gold Standard)** :
73+ - ** 轻客户端验证** : 例如 Cosmos 的 IBC 协议。链 A 上运行一个链 B 的“轻客户端”,它可以独立验证链 B 的区块头。这实现了无需信任任何第三方中介的通信,但开发和维护成本极高。
74+ - ** 依赖外部验证者的通信 (Common Approach)** :
75+ - ** 多签/MPC桥** : 由一组受信任的外部节点监听源链事件,并在目标链上执行操作。这类桥的安全性直接取决于这组验证者的诚实和安全。
76+ - ** LayerZero & Axelar** : 它们是更现代的互操作性协议,通过“预言机”和“中继者”等角色分离来分散信任,但根本上仍依赖于外部验证者的假设。
77+ - ** 架构启示** : 在设计跨链应用时,必须清楚地向用户阐明其所依赖的信任模型。一个应用的安全水平取决于其最薄弱的跨链依赖。
78+
79+
80+
81+ ## 3. 下一代账户与意图驱动架构
82+
83+
84+
85+ 这是对 DApp 用户体验和交易模式的根本性重塑。
86+
87+
88+
89+ ### 账户抽象 (ERC-4337)
90+
91+
92+
93+ ERC-4337 通过将用户的账户变成一个智能合约,彻底释放了钱包的可能性,开发者必须理解其核心组件:
94+
95+ - ** ` UserOperation ` ** : 一个描述用户“意图”的数据结构,例如“我想调用合约A的X函数”。
96+ - ** ` Bundler ` ** : 一个寻找 ` UserOperation ` 并将其打包上链的节点运营者。
97+ - ** ` EntryPoint ` ** : 一个全局单例合约,负责验证和执行 ` UserOperation ` 包。
98+ - ** ` Paymaster ` ** : 一个可选的合约,可以为用户代付 Gas 费,实现 Gas 赞助。
99+ - ** 对开发者的影响** : 可以为DApp 设计专属的用户体验,例如:
100+ - ** 社交恢复** : 用户不再需要担心丢失助记词。
101+ - ** 会话密钥 (Session Keys)** : 为链游授权一个临时密钥,允许在1小时内进行无签名交易。
102+ - ** 批量交易** : 将“授权(Approve)”和“转账(Transfer)”合并为一次原子操作。
103+
104+
105+
106+ ### 意图驱动架构 (Intent-Based Architecture)
107+
108+
109+
110+ 这是继账户抽象之后的又一次范式革命。
111+
112+ - ** 交易 vs. 意图** :
113+ - ** 交易 (Transaction)** : 用户精确地告诉网络“** 如何做** ”(例如:在Uniswap V3用X路由将1 ETH兑换为USDC)。用户承担了所有的执行风险和复杂性。
114+ - ** 意图 (Intent)** : 用户只声明“** 想要什么** ”(例如:我想用1 ETH换取尽可能多的USDC,可以接受最多0.5%的滑点)。
115+ - ** 求解器 (Solvers)** : 用户签署并广播他们的“意图”。一个由专业参与者(称为“求解器”或“搜寻者”)组成的竞争性市场会寻找最优的路径来实现这个意图,他们可能会通过聚合流动性、利用 MEV 机会等方式来完成,并从中赚取差价。
116+ - ** 开发者启示** : 未来的 DApp 可能不再是简单的“功能提供者”,而是“** 意图的生成和解决市场** ”。
117+
118+ ------
119+
120+
121+
122+ ## 4. EVM 极限探索与未来
123+
124+
125+
126+
127+
128+ ### Merkle 树证明
129+
130+
131+
132+ 这是在链上验证大规模数据集的终极 Gas 优化技术。
133+
134+ - ** 应用场景** : 空投白名单、投票资格验证等。
135+ - ** 工作原理** : 与其将一个包含数万个地址的白名单数组存储在链上(这将消耗天文数字的Gas),只需将这批地址的 ** Merkle 树根 (一个32字节的哈希值)** 存储在链上。
136+ - ** 验证流程** : 用户在前端计算出自己的地址属于这棵树的“证明路径”(Merkle Proof),并将其作为 ` calldata ` 提交给合约。合约只需进行几次哈希计算即可验证该证明是否有效,从而确认该用户是否在白名单内。整个验证过程的 Gas 成本是固定的,与白名单大小无关。
137+
138+
139+
140+ ### Transient Storage (EIP-1153)
141+
142+
143+
144+ 这是在 Cancun/Deneb 升级中引入的一个全新的、革命性的 EVM 特性。
145+
146+ - ** 核心概念** : ` tstore ` 和 ` tload ` 操作码引入了一种新的存储类型。** 瞬时存储** 的行为介于 ` storage ` 和 ` memory ` 之间。它在** 单笔交易的生命周期内是全局的** (像 ` storage ` 一样,可以在不同的合约调用之间传递状态),但在交易结束后会被完全清除(像 ` memory ` 一样,不产生永久的 Gas 成本)。
147+ - ** 颠覆性用例** :
148+ - ** 可重入锁 (Re-entrancy Locks)** : 在交易开始时设置一个瞬时存储锁,交易结束时自动清除,比传统的存储锁更便宜、更简洁。
149+ - ** 复杂回调与钩子** : 在多合约调用流程中(如A调用B,B再回调A),可以安全地传递状态,而无需昂贵的 ` storage ` 读写或复杂的函数参数传递。
150+
18151# 2025-08-15
19152
20153## 1. EVM 核心与底层机制
0 commit comments