ABI encoding

在 Yul 中使用 staticcall 调用其他合约

该视频的核心内容是讲解了Solidity中call data的工作原理，以及如何在Yaw语言中使用call data进行跨合约调用。 **关键论据/信息：** 1. **Call Data 结构:** 当向智能合约发送交易时，call data 的前四个字节代表要调用的函数签名，后续的32字节增量分组代表函数参数。Solidity会忽略超出预期的数据。 2. **函数签名生成:** 可以使用 Foundry 工具包中的 `cast` 命令生成函数签名。例如，`cast sig "balanceOf(address)"` 可以生成 `balanceOf` 函数的签名。 3. **Call Data 生成:** 可以使用 `cast calldata` 命令生成完整的 call data，包括函数签名和参数。例如，`cast calldata "balanceOf(address)" 0x...`。 4. **ABI 编码:** Solidity 中可以使用 `abi.encodeWithSignature` 函数生成 call data。但它会在数据末尾填充零，以确保总长度是32字节的倍数。 5. **Yaw 中使用 Call Data:** Yaw 允许打破 Solidity 的 call data 约定，提供更大的灵活性。视频展示了如何在 Yaw 中使用内联汇编（Yul）通过 `staticcall` 指令调用另一个合约的函数，并传递 call data。`staticcall` 需要指定 gas 限制、目标合约地址、call data 的内存位置和长度，以及用于存储返回值的内存位置。 6. **工具介绍:** 视频介绍了 `cast` (Foundry) 用于生成函数签名和 call data，以及 `Chisel` 用于在 REPL 环境中测试 Solidity 代码。

使用 Yul 在内存中进行 ABI 编码

该视频主要讲解了Yul语言中ABI编码对内存分配的影响，重点对比了`abi.encode`和`abi.encodePacked`两种编码方式在内存使用上的差异。 **核心内容/主要观点：** * Yul中的ABI编码会影响内存的使用和分配。 * `abi.encode` 会将数据填充到32字节的字长，即使数据本身小于32字节，也会进行填充，导致占用更多内存。 * `abi.encodePacked` 会尝试将数据打包到尽可能小的空间，避免填充，从而节省内存。 **关键论据/关键信息：** * Yul使用自由内存指针（Free Memory Pointer）来管理内存分配，该指针的初始位置为0x80，存储在地址0x40。 * `abi.encode` 会在实际数据之前添加一个32字节的字，用于指示后续数据的长度。 * 视频通过具体的例子展示了`abi.encode`和`abi.encodePacked`在编码相同数据时，自由内存指针的移动距离不同，从而验证了`abi.encodePacked`更节省内存的结论。 * 视频通过调试工具展示了内存中的数据布局，清晰地展示了填充和打包的区别。

ABI编码 | EVM内存8

智能合约返回的数据采用ABI编码。在调用其他合约时，返回的数据以及使用汇编调用外部合约时返回的数据都必须进行ABI编码。对于小于或等于32字节的值类型，左侧填充零；对于固定大小的字节类型（如bytes4、bytes16、bytes32），则右侧填充零。结构体和固定大小数组以32字节块返回，而动态数组则需要编码偏移量、长度和32字节元素。 例如，地址类型在ABI编码时左侧填充零，返回32字节，其中20字节为地址内容。结构体的编码则会将每个数据类型填充至32字节，返回时会包含多个32字节块。固定大小数组与结构体类似，返回时不编码长度，而是直接返回32字节块。动态数组则包含偏移量和长度，元素同样以32字节编码。 了解这些编码规则对于使用汇编进行外部调用和返回数据至关重要。