本文介绍了智能合约工厂模式,它通过一个智能合约来部署、初始化和跟踪其他合约,实现标准化、可发现性、初始化安全和确定性部署。文章通过一个 Foundry 示例,展示了如何使用工厂合约部署和交互合约,并解释了为什么现代协议几乎都包含工厂模式。
本文介绍了EIP-1167最小代理(Minimal Proxy)合约,它通过部署极小的bytecode stub,将所有调用委托给单个实现合约,从而降低了大量合约实例的部署成本。与普通代理不同,最小代理不可升级,但非常小巧高效,适用于需要大量相同逻辑但独立状态的场景,例如DEX中的流动性交易对。
本文介绍了 UUPS 代理模式,它将升级逻辑从代理合约转移到实现合约中,从而减少了 bytecode 大小、部署成本和复杂性。通过将升级功能放在实现合约中,每个实现都可以定义自己的升级规则。文章还通过 Foundry 演示了 UUPS 代理的部署和升级过程。
本文详细解释了以太坊智能合约的部署过程,包括部署交易的原理、EVM如何确定合约地址,以及如何使用CREATE和CREATE2预先计算合约地址。文章通过示例展示了如何手动计算合约地址,并解释了CREATE2在预先确定合约地址方面的重要作用。
本文介绍了以太坊智能合约升级的常用模式:透明代理(Transparent Proxy,EIP-1967)。文章解释了代理合约如何通过 delegatecall 将调用转发到可替换的实现合约,从而在保持合约地址不变的情况下实现逻辑升级。文章还通过 Foundry 演示了代理合约的部署、升级和状态保持的过程,并强调了 EIP-1967 标准化存储槽位的重要性。
delegatecall
本文介绍了以太坊虚拟机(EVM)中事件(也称为日志)的工作原理,包括事件的定义、存储位置(交易回执日志而非合约存储)、以及如何通过eth_getLogs直接查询事件。文章详细解释了topics(索引字段,用于过滤)和data(非索引字段,存储原始字节)的结构,并通过ERC-20代币转账事件的示例,展示了如何手动解码日志以及如何在区块浏览器上理解事件信息。
eth_getLogs
topics
data
本文介绍了以太坊节点的不同类型(完整节点、归档节点和轻节点)以及主要的执行客户端(如Geth、Nethermind、Erigon和Besu)。讨论了它们的数据保留、同步方法和RPC实现如何影响调试、追踪和重放交易的能力,以及何时应该运行自己的节点。
本文介绍了 EIP-712 的原理、作用以及如何使用 EIP-712 实现安全的链下签名,使得钱包能够显示可读的信息,合约可以在链上验证签名。同时,通过一个 Go 语言和 Solidity 语言的例子,展示了如何在 Polygon Amoy 测试网上验证 EIP-712 签名,并介绍了基于 EIP-712 构建的 EIP-2612 Permit 签名流程。
EIP-4844 (proto-danksharding) 引入了blob交易,为Rollup在以太坊上提供临时的数据空间,显著降低存储成本。通过分离执行数据和blob数据,并在短期保留后丢弃blob,网络在不增加状态大小的情况下获得带宽的显著提升。 此次升级弥合了当前Rollup扩展和完整数据分片之间的差距,降低了费用,提高了吞吐量。
本文介绍了以太坊的访问列表交易(Access List Transaction),它是EIP-2930在柏林硬分叉中引入的。访问列表通过预先声明交易将访问的地址和存储槽来优化gas消耗并提高可预测性。文章还演示了如何使用eth_createAccessList RPC方法生成访问列表,以及如何在Go语言中构建和广播EIP-2930交易。
eth_createAccessList