以太坊交易公钥恢复时哈希与地址无法同时匹配问题求助

你遇到的解码结果不匹配问题，本质是交易签名预处理规则、工具解码逻辑的适配偏差，具体如下：

• 你组装的完整交易RLP十六进制串本身是正确的，各字段编码完全匹配给出的交易参数：
  • nonce=3、gasPrice=50Gwei、gasLimit=2000000、to地址、value=0.001ETH、空input、v/r/s值的RLP编码均符合规范，整串前缀0xf86c对应总长度108字节，编码无错误。
• 两种解码模式结果互斥的原因：
  • 选择Transaction解码模式时，工具会直接对完整RLP交易串做keccak256计算，得到的交易哈希和你给出的链上哈希完全一致，但该模式默认按EIP-155交易规则解析v值，会误将v=0x1c（十进制28，属于前置EIP-155的传统交易v值，仅代表签名y坐标奇偶位）识别为带链ID的EIP-155 v值，导致公钥恢复、地址计算错误。
  • 选择Hex签名恢复模式时，工具默认将你输入的完整十六进制串直接作为待签名原文计算哈希，再做公钥恢复——但传统交易的待签名原文不包含v、r、s签名字段，仅为核心交易字段（nonce、gasPrice、gasLimit、to、value、input）的RLP编码列表，你传入了带签名的完整串，相当于待签名原文错误，此时恢复出的地址匹配只是参数错位下的偶然结果，不具备正确性。

按以下步骤操作即可得到匹配from地址的正确公钥：

1. 从你组装的完整交易RLP串中，剔除末尾的v、r、s签名字段，仅保留核心交易字段的RLP编码作为待签名原文。签名字段总长度为67字节（1字节v + 33字节r编码 + 33字节s编码），对应剔除末尾134个十六进制字符（不含0x前缀）即可。
2. 对待签名原文做keccak256运算，得到32字节签名摘要。
3. 用签名摘要、r值0xe58712e11aaa32ac207e893cde3b91159c1e1dc5be5a9bd18f0476869806feb6、s值0x421eef8f63fc2872c86d79048ac053542980768f4b7638da40353c0a95012473、recovery id=1（v=28对应传统交易recovery id为1）做secp256k1椭圆曲线公钥恢复。
4. 对恢复得到的65字节未压缩公钥（首字节为04前缀）剔除前缀后做keccak256运算，取结果最后20字节，若和from地址0x9acadffa3d622b6f77b2dd625ad41e054eec300e完全一致，即为目标账户公钥。

注意：该交易为前置EIP-155的传统交易，待签名原文不需要追加链ID、0、0三个EIP-155专属字段，否则会导致摘要计算错误。

内容的提问来源于stack exchange，提问作者Bouloukaouze