MilosMicun/solidity-proxy-patterns

# 🧠 Solidity 代理与 Delegatecall 模式 对 EVM 执行上下文、存储行为和代理架构的底层探索。 ## 📚 涵盖主题 - Delegatecall 与 Call - 执行上下文与 `msg.sender` - 存储布局与 Slot 行为 - 存储碰撞漏洞 - 代理模式 (fallback + delegatecall) - 最小代理 (EIP-1167 克隆) ## 🧪 实验 ### Delegatecall 与 Call 相同的函数调用。 不同的执行上下文。 不同的存储结果。 - `call` → 修改目标合约的存储 - `delegatecall` → 修改调用者合约的存储 ### 存储碰撞 不匹配的存储布局： - 相同的 Slot - 不同的含义 结果： - 关键状态覆盖 (`owner`) ### 代理模式 用户与代理合约交互。 - 代理合约转发 calldata - 实现合约执行逻辑 - 状态存储在代理合约中 ### 最小代理 (EIP-1167) 工厂合约部署轻量级代理实例。 - 共享实现合约 - 每个实例拥有独立的存储 - 部署成本低 ## ⚠️ 核心洞察 合约之间的存储布局必须保持一致。 ## 🧠 核心心智模型 - 代码存在于 **实现合约** 中 - 状态存在于 **代理合约** 中 - 执行上下文决定了状态变更的位置 ## 📌 总结 相同的代码。 不同的存储。 截然不同的系统行为。

标签：Delegatecall, EIP-1167, EVM, Exploit, Fallback函数, Proxy Pattern, Solidity, Storage Collision, Web3安全, 代理模式, 以太坊, 区块链安全, 去中心化应用, 合约审计, 合约漏洞, 存储布局, 存储槽, 密码学, 底层调用, 手动系统调用, 智能合约, 智能合约开发, 最小代理, 状态覆盖