處理乙太坊 LOG1-2-3-4 操作碼：如何正確解析它們？

我正在嘗試對來自事務操作碼的事件進行一些分析，但我發現很難理解如何找到 index_topics 和事件返回的值。例如：

{
 pc: 1243,
 op: 'LOG2',
 gas: 95970,
 gasCost: 1381,
 depth: 2,
 stack: [
   '0xd0e30db0',
   '0x3d2',
   '0x7a250d5630b4cf539739df2c5dacb4c659f2488d',
   '0xe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c',
   '0x20',
   '0x60'
 ],
 memory: [
   '0000000000000000000000007a250d5630b4cf539739df2c5dacb4c659f2488d',
   '0000000000000000000000000000000000000000000000000000000000000003',
   '0000000000000000000000000000000000000000000000000000000000000060',
   '0000000000000000000000000000000000000000000000000de0b6b3a7640000'
 ]
}

在此日誌中，地址0x7a250d5630b4cf539739df2c5dacb4c659f2488d(index_topic_1) 將 1 Eth ( 0xde0b6b3a7640000)（事件返回的數據）存入 WEth。index_topic_0 是0xe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c. 所以我可以看到我需要的所有數據（觸發事件的合約地址除外）都在那裡，我只是不確定它是否總是按這個順序排列並且我可以信任它。

在其他事件中，我確實在堆棧和記憶體中找到了我需要的返回數據，但我不知道如何自信地從記憶體中解析它。

我有一些問題：

• 記憶體對象3和60位置 1 和 2 是什麼？
• 如何找到觸發此事件的地址？我能想到的唯一方法是查找最新CALL的STATICCALL,DELEGATECALL或CALLCODE並查找to參數，但這聽起來很麻煩
• 我如何解釋堆棧上的其餘內容？我看到它們在index topics那裡，但在對我沒有任何意義的位置（堆棧索引 = 2 中的 index_topic_1 和堆棧索引 = 3 中的 index_topic_0，我不知道堆棧中的其他 4 個項目是什麼，不是確定它們是否甚至與事件日誌有關）

如果您能提供有關解析此事件操作碼的任何類型的資訊，我將不勝感激，謝謝。

從 LOG 操作碼的黃紙文件中，格式為：

• 堆$$ 0 $$指針記憶體
• 堆$$ 1 $$記憶體大小
• 堆$$ 2 $$第一個話題
• 堆$$ 3 $$第二個主題等等

從您的擷取中，堆棧被反轉

 stack: [
   '0xd0e30db0',
   '0x3d2',
   '0x7a250d5630b4cf539739df2c5dacb4c659f2488d',
   '0xe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c',
   '0x20',
   '0x60'
 ],

• 0x60 指向0000000000000000000000000000000000000000000000000de0b6b3a7640000
• 0x20 長度 = 32 字節
• 第一個話題 0xe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c
• 第二個主題0x7a250d5630b4cf539739df2c5dacb4c659f2488d（它將被填充到 32 字節

---

如果我沒記錯的話，記憶體 0x0-0x3f 是一些可靠操作使用的暫存記憶體。

0x40-0x5f 處的記憶體是指向空閒記憶體的指針。在這種情況下，可用記憶體從 0x60 開始。

同樣在較新的 solc 版本中，0x60-0x7f 處的記憶體地址被故意歸零，空閒記憶體從 0x80 開始。

---

我認為你是正確的，訪問目前的契約你必須跟踪這些操作碼。

引用自：https://ethereum.stackexchange.com/questions/107746