从一份合约到一张收据：
币怎么来、交易怎么走、耗费怎么算

gas 的三层账

1. 起步价（intrinsic gas）：每笔交易固定先收 21000 gas，外加 calldata 里每个零字节 4 gas、 每个非零字节 16 gas——这解释了为什么"调用参数越长的交易起步就越贵"，跟合约逻辑本身还没关系。
2. 逐指令计价（opcode gas）：加法这类简单运算只要 3 gas；读一个从没读过的 storage 槽（cold access）要 2100 gas，同一笔交易里读过一次后再读（warm）只要 100 gas；把一个原本是 0 的槽第一次写入 非零值要 20000 gas（这是最贵的常规操作之一，也是为什么"减少 storage 写入"是 gas 优化的核心）。
3. 退款（gas refund）：把一个非零槽清零会退一部分 gas，但退款总额被硬性封顶在 "这笔交易实际耗费的 1/5"（EIP-3529）——防止有人靠"先占满 storage 再清空"骗退款套利。

试算一笔交易：拖动滑块看收据怎么变

交易收据（Transaction Receipt）

事件日志：外部世界"看懂"链上发生了什么的唯一入口

合约不会主动"通知"任何人。它能做的只有在执行时 emit 一条日志，写进这笔交易的 receipt 里。 以最常见的 Transfer(address indexed from, address indexed to, uint256 value) 为例：

topics[0] = keccak256("Transfer(address,address,uint256)")  // 事件签名哈希，固定值
topics[1] = 0x000...<from 地址，左补零到32字节>      // indexed 参数进 topics
topics[2] = 0x000...<to 地址，左补零到32字节>
data      = 0x000...<amount，ABI 编码>              // 非 indexed 参数进 data

钱包、区块浏览器、subgraph 索引器、还有你自己写的套利机器人——全都是靠"订阅特定 topics[0] 的日志" 来知道"哪笔转账发生了""哪个池子被 swap 了"，而不需要逐块重放整条链的状态变化。 这也是为什么 indexed 关键字很重要：只有 indexed 的参数才会被塞进 topics，才能被节点用哈希索引快速过滤（最多 3 个），非 indexed 的参数虽然也在日志里， 但只能靠下载整条 data 再解码才能拿到，没法作为过滤条件。

A. 从源码到一个地址：部署与构造函数到底做了什么

写完 Solidity 源码，编译器（solc）产出三样东西：运行时字节码（部署后长期挂在这个地址上、 真正响应调用的代码）、创建字节码（= 运行时字节码 + 一段只在部署那一刻跑一次的构造逻辑， 打包在一起）、以及 ABI（下面 B 讲）。部署交易的 to 留空， data 就是这段创建字节码（如果构造函数有参数，参数按 ABI 规则编码后直接拼接在 创建字节码最后）。

构造函数在做的事：读出拼在末尾的构造参数，把它们写进 storage（比如把 msg.sender 记成 owner）或者直接**烧进** immutable 变量（`immutable` 不占 storage 槽， 编译器把值直接拼进运行时字节码本身，读取时不用 SLOAD，省一大笔 gas）； 跑完之后用 RETURN 指令把"运行时字节码"这段吐出去交给 EVM 存起来—— 构造函数自己那段逻辑从此不再是这个地址代码的一部分，它只活在部署那一笔交易里， 一次性用完即弃。

新地址怎么算出来：CREATE（普通部署）算法是 keccak256(rlp([发送者地址, 发送者当前nonce])) 取后 20 字节； CREATE2 算法是 keccak256(0xff ++ 部署者 ++ salt ++ keccak256(创建字节码)) 取后 20 字节——CREATE2 的关键价值是地址在真正部署之前就能算出来（只要创建字节码和 salt 不变），Uniswap V2 的交易对地址、ERC-4337 智能账户"先算出地址收币、真正用时才部署"，用的都是这个。

B. ABI：链上从来不存在、但缺了它什么都读不懂的说明书

链上只有字节码，没有任何"函数叫什么名字、参数是什么类型"这类人类可读信息——这些全部记在 一份链下的 JSON 文件里，就是 ABI（Application Binary Interface）。钱包、ethers.js/web3.py 这类库、 区块浏览器，全靠这份 ABI 才知道"调用这个合约的转账函数要拼什么字节、返回的裸字节该怎么解读成人话"。 这也是为什么 Etherscan 上一个未验证的合约只能看到十六进制字节码、读写面板是灰的—— 没人告诉它 ABI 是什么，它没法帮你拼调用。

ABI 编码的核心规则：定长类型（uint256、address、bool） 直接补零对齐到 32 字节；变长类型（string、bytes、数组）用 "偏移量指针 + 长度 + 数据本体"三段式——先在固定位置放一个指针（指向数据本体在整个 calldata 里的字节偏移），数据本体本身统一堆在最后。这是为什么下面 C 的 calldata 图里， 动态参数（比如一个地址数组 path）不是按顺序摆在对应位置，而是"头部放指针， 尾部放真身"。

C. calldata 剖面：一次真实调用长什么样

以 Uniswap V2 风格的 swapExactTokensForTokens(uint256 amountIn, uint256 amountOutMin, address[] path, address to, uint256 deadline) 为例：

selector = keccak256("swapExactTokensForTokens(uint256,uint256,address[],address,uint256)")[:4]
            = 0x38ed1739
0x00 amountIn        // 32 字节，定长
0x20 amountOutMin    // 32 字节，你能接受的最坏成交量（滑点容忍度，见 F）
0x40 path 的偏移量    // 指向 0xa0 处：数组真身放在哪
0x60 to              // 32 字节
0x80 deadline        // 32 字节
0xa0 path.length     // 数组长度，比如 2
0xc0 path[0]         // 第一个地址
0xe0 path[1]         // 第二个地址

D. 链上函数匹配（dispatch）：EVM 怎么知道该跑哪一段

合约的运行时字节码开头，编译器会自动生成一段"分派表"：先用 CALLDATALOAD 读出 calldata 最前面 4 字节，然后是一串 selector 是否等于某个已知值 的比较 （EQ + JUMPI，函数多的话编译器会生成二分查找式的跳转以省 gas）， 命中哪一个 selector，就跳（JUMP）到那段函数体真正开始执行的位置。 全部比对不上：如果调用带了 calldata 但没匹配任何已知函数，走 fallback() （没定义就直接 revert）；如果是纯转 ETH、calldata 是空的，走 receive()。

E. 参数怎么真正"传进去"、返回值怎么"传回来"

1. 编译期，编译器已经根据 ABI 布局把每个参数在 calldata 里的字节偏移量算死了——函数体内直接用 CALLDATALOAD/CALLDATACOPY 从那个固定偏移取值，不需要"查找参数名"这种操作， 变量名早在编译时就被抹掉、变成了纯偏移量。
2. 函数执行完，把返回值按 ABI 规则编码好写进 memory，用 RETURN(offset, length) 把这段裸字节交还给调用方。
3. 调用方——不管是一个外部账户发起的交易、还是另一个合约用 CALL 调过来的—— 都得按自己预期的返回类型去解码这段裸字节；如果 ABI 对不上（比如以为返回 uint256 实际返回 (uint256,uint256)），解码出来的值就是错的或直接崩，链上不会替你检查这件事。
4. 同一套"匹配→执行→编码返回"机制，走的是两条不同的路：eth_call （只读模拟，不广播、不上链、不花 gas，用来跑 view/pure 函数或者 "预检这笔交易会不会成功"）和真正发一笔交易（状态真的被改写、要付 gas）——差别只在 "结果要不要被写进全局状态、要不要收钱"，匹配和执行的逻辑完全一样。

F. 滑点：写进调用参数里的"我能接受的最坏结果"

精确定义：你发起交易时看到的预期成交价格，和交易真正落地那一刻的实际成交价格之间的差。 要理解它为什么会发生，得先回答一个更根本的问题：链上这个"价格"到底是谁定的、买卖动作为什么 能改动它。

价格不是被写进去的，是被"算"出来的公认值

AMM 池子里没有任何地方存着"当前价格"这个字段——池子只老老实实存两个数： 两种代币各自的数量（reserves）。价格是用这两个数量的比例现算出来的： 价格 = reserve_USDC / reserve_WETH。没有人"公告"这个价格，也没有人有权限去 直接改它——它是全网每一笔历史成交共同留下的残留物：谁愿意用多少 A 换多少 B， 成交完这两个数量就永久地变了一点，下一个人看到的"当前价格"，就是所有前人交易行为叠加之后 的这个比例快照。这就是"公认"在链上的准确含义——不是投票表决出来的，是用真金白银的 成交历史"投票"出来的，且这份投票记录（reserves 的当前值）本身就写在链上账本里， 人人可读、人人可验证，不需要任何权威机构来"宣布"价格是多少。

数量怎么决定价格冲击：一个公式 + 一张实测表

正因为价格 = 数量之比，你交易的数量相对池子里已有的数量越大，你自己这一笔就把这个比例 搬动得越多——这是"机制性滑点"真正的数学根源，不是设计者刻意刁难，是"价格由数量比例定义" 这件事必然带来的推论。以 x·y=k 恒定乘积为例，往 x 这一侧投入 Δx，能换出的 另一侧数量 Δy 精确满足：

Δy = y · Δx / (x + Δx)         // 换出数量
有效成交价 = Δx / Δy = (x + Δx) / y   // 你实际付出的单价
现货价（瞬时价）= x / y               // 池子当前的比例
价格溢价 = Δx / x                    // 你把价格往上搬动的幅度

换句话说：你交易的数量（Δx）占池子里已有数量（x）的比例越大，你要多付的溢价就越大， 而且是接近线性的关系（小额交易时）。拿一个具体池子实测一下（1,000,000 USDC / 500 WETH， 现货价 2,000 USDC/WETH）：

池子越浅（两边数量越少）、你交易的数量相对越大，"少拿"的比例越夸张——这就是为什么同样一笔 10,000 USDC 的换币，在深度几千万美元的池子里几乎无感，在一个刚建的小池子里可能直接吃掉 两位数百分比。"币的数量"（池子深度 vs 你的交易量）决定了买卖动作对价格的冲击力度， 这是纯几何/代数关系，跟有没有人恶意操纵无关。

两种完全不同的滑点成因，很多人混为一谈：

• 机制性滑点（跟有没有人抢跑无关）：就是上面这张表——你的交易本身相对池子深度越大， 把价格顺着曲线推得越远，成交均价就必然比"下单前一刻的瞬时价格"差，池子深度不变、 没有第三者插手也会发生。
• 时间差滑点（跟第三节的竞价排序直接相关）：从你的钱包拿到报价，到这笔交易真正被打包执行， 中间隔着排队等待的时间；如果别的交易先成交、把上面那个"数量之比"先挪走了，你实际吃到的价格就比 报价时更差——这部分滑点的大小，取决于你的 tip 出得够不够高、排得够不够靠前。

竞争机制怎么把这个"公认价格"拉回外部市场

如果这个池子算出来的价格，和交易所/其他池子的价格不一致，就出现了一个免费午餐： 套利者可以在这个池子里把便宜的一边买走，同时在别处把它卖掉赚差价——而套利者这笔交易， 恰恰就是上面那个公式里的"Δx 投入"，会把池子的数量比例往"正确"的方向推，直到两边价格重新对齐 为止。池子价格能跟得上外部市场，靠的不是任何人维护，是套利这个财务动机自动驱动的。 而"谁先发现价差、谁先把这笔套利交易打包上链"，回到第三节，本身也是一场竞价——多个套利者 同时盯着同一个价差，靠 priority fee 竞速，谁的交易先被打包，谁就吃到这份差价， 池子价格因此常常在一个区块之内就被拉回去。

买卖为什么会反过来影响链上"币的价值"本身

把前面几点串起来看一个更深的结论：在没有外部预言机的情况下，一个代币在链上的"价值"， 不是被写进链上的一个既定事实，而是完全由买卖双方的交易数量史构造出来的一个可读数值—— 每一次买卖，不只是让交易发起人自己承受滑点，还永久性地重写了下一个人将要看到的"公认价格"。 这也是为什么"价格发现"这个词用在 AMM 上格外贴切：价格不是被发现了一个客观外部真相， 是被每一笔实际发生的买卖持续构造出来的——你的买入把价格往上推一点，你的卖出把价格往下压 一点，下一个交易者面对的，就是包含了你这笔交易残留影响的新起点。

amountOutMin（或反过来做买单时的 amountInMax）就是"滑点容忍度"在调用参数里 的具体落地：你能接受的最差成交结果，写死在 C 里那段 calldata 的第二个 32 字节里。链上执行到检查 "实际输出是否 ≥ amountOutMin"这一步，如果不满足，整笔交易 revert——回到第四节讲过的规则， revert 之前已经消耗的 gas 依然要付。

G. 串起来看：一次 swap 调用的完整剖面

这张表把一、三、四、五节抽象讲过的概念，全部落在"这一次具体调用"的某个字节、 某个参数、某条判断上——这就是"底层"这个词的准确含义：不是更难，是更具体。