以太坊交易(tx) 分析

Posted 2023-05-05

参考技术A 更多请参考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相对应的，比如 60 对应就是 operation PUSH1,合约编译后的字节码即为一组的 operation 。

合约部署其实就是实例化一个 contract 对象，并将 data 的值设给 Code属性 。

创建合约的tx中，input字段对应的是合约的字节码，即指令数组。

其中 input 字段对应所要调用的函数签名的前四个字节（771602f7）以及对应的参数（1,2）

其中 input 字段为所要调用的合约函数签名的前四个字节（72a099b7）

关于函数调用，Call会把对应的Code读出来，依次解析，Code中会把所有的public签名的函数标志（4字节）push到栈里。然后依据 input 中需要调用函数的签名标志（前4字节）来匹配 Code， 匹配之后跳转到对应的 opcode 。

为啥无法解码这个以太坊 tx 输入数据？

【中文标题】为啥无法解码这个以太坊 tx 输入数据？

【英文标题】：Why can't this etherum tx input data be decoded?为什么无法解码这个以太坊 tx 输入数据？

【发布时间】：2021-05-06 16:54:14

【问题描述】：

如果你去this transaction page on etherscan，向下滚动到Input Data部分并点击Decode Input Data按钮——它什么也没给你，我只能假设意味着 etherscan 无法解码给定该合约的 ABI 的输入数据。

我的问题是，为什么？该合约/ABI（或任何类似的合约）有什么特别之处会阻止交易被解码？

【参考方案1】：

被调用函数签名为0xfaa916d3，其余数据为参数。合约 ABI 没有定义任何可以转换为 0xfaa916d3 签名的函数。这意味着调用了回退函数。

在这种情况下，回退函数充当代理，创建内部事务并将调用委托给目标合约（理论上可以执行相同操作或创建多个其他内部事务等）

但是，Etherscan 目前仅将签名与根交易接收者的 ABI 进行比较，而在“解码输入数据”功能中忽略了内部交易接收者的 ABI。

为什么？我的猜测是只扫描一个级别更容易，而不是实现和考虑所有边缘情况（例如具有相同签名的多个内部调用）的高优先级。但是你需要问他们真正的原因。 :)