事件記錄

加密貨幣中的事件記錄是什麼？

事件記錄是智能合約在區塊鏈交易執行期間建立的結構化紀錄。

它讓智能合約能發布資訊，供錢包、去中心化應用程式、區塊鏈瀏覽器、分析平台及其他鏈下系統查找與處理。

在 Ethereum 及其他 EVM 網路上，開發者通常會在 Solidity 中宣告事件，並在相關操作發生時使用 emit 關鍵字建立事件記錄。

例如，代幣合約可能會在代幣轉移、鑄造、銷毀或獲准支出時發出事件。

去中心化金融協議可能會在使用者存入抵押品、借入加密貨幣、償還債務、領取獎勵或平倉時發出記錄。

官方Solidity 事件說明文件指出，事件是建立在 EVM 記錄功能之上的抽象機制。

事件記錄通常不會控制合約狀態，也不會在發出後執行額外的業務邏輯。

相反地，它提供有效率的紀錄，讓外部軟體理解交易期間發生的事情。

因此，事件記錄是鏈上智能合約與向使用者呈現區塊鏈活動的鏈下應用程式之間的重要連結。

事件記錄如何運作？

以太坊虛擬機在交易中的成功執行路徑期間，會建立事件記錄。

智能合約會先宣告事件名稱與參數清單。

接著，程式碼執行至相關指令時，合約便會發出該事件。

Solidity 編譯器會將事件發出指令轉換為 EVM 的記錄操作之一。

產生的記錄包含發出事件的合約地址、可搜尋的主題清單，以及存放其他編碼資訊的資料欄位。

交易納入區塊後，記錄會成為交易收據的一部分。

應用程式可透過以太坊節點、RPC 服務商、區塊鏈瀏覽器或專用區塊鏈索引器取得記錄。

Ethereum 智能合約事件記錄指南說明，去中心化應用程式可監聽已發出的事件，並在事件出現時採取鏈下操作。

若交易回復，回復執行中產生的記錄也會從最終交易結果中移除。

因此，在模擬或執行追蹤中顯示的記錄，若整體呼叫失敗，可能不會出現在已確認的交易收據中。

事件與事件記錄的差異

事件是開發者定義的宣告，用來描述合約可發布哪些資訊。

事件記錄則是合約在交易期間發出事件時建立的實際紀錄。

例如，合約可以在原始碼中定義 Transfer 事件。

每次完成轉帳，都能根據該事件定義建立一筆獨立記錄。

事件就像範本，而每筆記錄都是該範本的一次實際紀錄。

單筆交易可以不產生記錄、產生一筆記錄或產生多筆記錄。

與多個智能合約互動的交易，可能會產生每個相關合約各自的記錄。

應用程式會使用合約的應用程式二進位介面（ABI），將原始記錄與事件宣告比對，並解碼其中的值。

事件記錄儲存哪些資訊？

EVM 事件記錄包含發出事件的合約地址、0 到 4 個主題，以及長度可變的資料欄位。

發出地址可識別建立記錄的合約。

主題包含適合有效篩選與搜尋的值。

未標記為 indexed 的事件參數會存放在資料欄位。

常用 RPC 介面也會隨記錄傳回交易與區塊中繼資料。

中繼資料可能包含交易雜湊值、交易索引、區塊雜湊值、區塊編號及記錄索引。

記錄索引用來識別該記錄在同一區塊其他記錄中的位置。

應用程式建立唯一記錄識別碼時，通常應一併使用鏈 ID、區塊雜湊值、交易雜湊值及記錄索引。

只使用事件名稱或交易雜湊值可能不足，因為單筆交易可能多次發出相同事件。

什麼是事件主題？

主題是放在 EVM 記錄中特定可搜尋欄位的 32 位元組值。

應用程式可用主題篩選區塊鏈歷史，而不必逐筆解碼所有事件資料欄位。

標準的非匿名 Solidity 事件最多可使用 4 個主題。

第一個主題通常用來識別事件類型，最多另外 3 個主題則表示標記為 indexed 的參數。

主題依序排列，因此篩選第二個主題位置的值，與篩選第三個位置的相同值並不相同。

官方Ethereum JSON-RPC eth_getLogs 說明文件指出，主題篩選依位置而定，同一位置也可包含多個替代值。

主題特別適合搜尋與錢包地址、代幣識別碼、市場、提案或其他常查詢值相關的事件。

若 indexed 參數選擇不當，應用程式的歷史資料可能難以或成本高昂地搜尋。

什麼是 Topic 0？

Topic 0 通常包含事件標準簽章的 Keccak-256 雜湊值。

標準簽章由事件名稱及依序排列的參數類型組成。

參數名稱與 indexed 關鍵字不會納入事件簽章雜湊。

例如，名稱為 Transfer、參數類型依序為 address、address、uint256 的事件，會產生可預測的事件簽章。

應用程式可將 Topic 0 與已知簽章雜湊值比較，以識別原始記錄代表的事件。

變更事件名稱、參數順序或參數類型，都會產生不同事件簽章。

因此，即使兩個事件名稱相同，只要參數類型不同，Topic 0 的值也會不同。

Solidity 事件 ABI 規格說明事件簽章與事件引數如何編碼至主題及資料欄位。

Indexed 事件參數

Indexed 參數是存放在主題中的事件引數，讓外部系統能有效篩選。

Solidity 的一般非匿名事件最多可使用 3 個 indexed 參數。

剩餘的主題位置會保留給事件簽章。

地址、整數、布林值及其他可放入單一 32 位元組字組的值，可透過符合 ABI 的編碼直接存放於主題。

動態值，例如字串、位元組陣列、動態陣列及複雜結構，則以不同方式處理。

動態值標記為 indexed 時，主題會儲存其編碼值的 Keccak-256 雜湊，而非原始可讀值。

應用程式若已知道要搜尋的值，可依該雜湊進行篩選。

但僅憑雜湊無法還原未知的原始字串或位元組陣列。

開發者有時會將同一資訊存放兩次：在 indexed 參數中放入雜湊版本，並在非 indexed 參數中放入可讀版本。

這種設計可提升搜尋便利性，同時保留可解碼的原始值。

非 Indexed 事件參數

未使用 indexed 關鍵字的參數會存放在記錄的資料欄位中。

這些值會依照 Ethereum ABI 規則編碼。

由於原始記錄資料不會為各個值標示可讀名稱與類型，因此需要 ABI。

應用程式必須取得正確的事件定義，才能可靠解碼資料。

非 indexed 參數可包含比單一主題更大或更複雜的值。

它們適合存放金額、詳細設定值、陣列、字串，以及不需要直接依主題篩選的其他資訊。

一般而言，應用程式無法要求 eth_getLogs 依資料欄位中的任意值篩選。

應用程式必須先依合約地址及主題取得記錄，再於本機解碼與檢查資料。

匿名事件

Solidity 事件可宣告為匿名事件。

匿名事件不會自動在 Topic 0 放入事件簽章雜湊值。

如此一來，4 個主題位置都能用於 indexed 參數。

但移除簽章主題後，外部軟體便更難自動識別事件類型。

若不同匿名事件使用相似的主題與資料結構，也可能難以區分。

匿名事件適合特殊的低階設計，但一般應用程式事件若非匿名，通常更容易索引與解碼。

只有在額外 indexed 主題帶來的明確效益足以抵銷事件識別能力降低時，開發者才應使用匿名事件。

EVM 記錄操作碼

EVM 提供 5 種記錄操作碼，名稱為 LOG0 至 LOG4。

操作碼名稱中的數字代表該記錄包含的主題數量。

LOG0 建立不含主題的記錄，LOG4 則建立包含 4 個主題的記錄。

每種記錄操作也會讀取所選的 EVM 記憶體範圍，並將其存為記錄的資料欄位。

Solidity 事件會編譯為這些較低階的記錄指令。

執行環境會將合約地址附加至記錄，而非將其作為一般事件參數提供。

記錄操作會消耗 Gas，費用取決於主題數量與記錄資料量等因素。

官方Ethereum 操作碼參考資料列出 EVM 記錄指令及其執行成本。

事件記錄與交易收據

交易收據是交易納入區塊後產生的執行紀錄。

收據包含執行狀態、累計 Gas 使用量、日誌布隆過濾器，以及該交易發出的記錄等資訊。

RPC 回應可能額外提供合約建立地址、有效 Gas 價格及單筆交易 Gas 使用量等欄位。

記錄陣列會依序保留執行期間發出事件的順序。

若沒有合約發出事件，成功交易的記錄陣列也可能為空。

失敗交易通常不會留下事件記錄，因為其狀態變更與記錄都已回復。

應用程式應檢查收據狀態，而非將交易雜湊值存在視為執行成功的證明。

Ethereum JSON-RPC 交易收據方法說明執行用戶端傳回的收據欄位。

事件記錄與區塊收據

交易收據會透過區塊的 receipts root 以密碼學方式承諾。

這項承諾讓區塊鏈參與者能驗證收據是否屬於特定區塊歷史。

每份收據都包含該交易產生的記錄。

目前執行區塊格式的區塊標頭也包含布隆過濾器，用於彙整該區塊交易記錄中的地址與主題。

布隆過濾器可協助用戶端判斷某區塊是否可能包含符合查詢條件的記錄。

布隆過濾器符合查詢條件，不代表一定存在相符記錄，因為布隆過濾器可能產生誤判。

若未符合，則表示搜尋的地址或主題未出現在該布隆過濾器中。

應用程式仍須檢查實際收據記錄，才能確認事件值。

事件記錄與合約儲存資料

事件記錄與智能合約儲存資料的用途不同。

合約儲存資料包含未來智能合約執行可直接讀取的永久資料。

事件記錄主要供外部觀察與歷史索引使用。

Solidity 合約無法直接讀取歷史事件記錄，包括同一合約發出的記錄。

Solidity 事件參考資料指出，合約內無法存取記錄與事件資料。

合約絕不能將先前事件作為未來鏈上決策所需資料的唯一來源。

若未來合約邏輯需要某個值，通常應將其存入合約狀態，或透過可驗證機制提供。

若資訊僅供鏈下使用，記錄通常比永久儲存便宜。

不過，以記錄取代儲存資料，會改變智能合約日後能驗證或取得的內容。

事件記錄與函式傳回資料

函式傳回資料會在合約執行期間傳回給直接呼叫者。

事件記錄則會儲存在交易收據中，供日後鏈下查詢。

狀態變更交易不會像事件記錄一樣，以方便查閱的歷史形式向使用者介面提供傳回資料。

應用程式常依賴收據與事件了解已提交交易的結果。

唯讀呼叫可傳回數值，而不建立事件記錄或變更區塊鏈狀態。

開發者應使用傳回值進行即時合約呼叫溝通，並使用事件提供持續可查的鏈下通知。

事件不應視為直接的函式回應，因為單筆交易期間可能有多個合約發出記錄。

應用程式如何查詢事件記錄？

應用程式通常透過 eth_getLogs JSON-RPC 方法查詢歷史事件記錄。

查詢可指定起始區塊、結束區塊、合約地址、區塊雜湊值及主題篩選條件。

該方法會傳回符合篩選條件的記錄陣列。

與一次查詢極大區塊範圍內的所有記錄相比，範圍較小的查詢通常更可靠且有效率。

RPC 服務商可能會限制區塊範圍、回應大小、請求時間或查詢頻率。

應用程式應將大型歷史查詢拆分為較小區塊範圍，並保存處理進度。

請求失敗時，也應透過受控的退避機制重試，而非假設空白或失敗回應代表不存在事件。

使用EIP-234定義的 blockHash 篩選條件，可協助應用程式查詢特定區塊中的記錄。

輪詢與事件訂閱

應用程式可透過輪詢或訂閱尋找新的事件記錄。

輪詢是定期向節點查詢記錄或篩選器變更。

訂閱則會維持即時連線，讓節點在區塊到達時傳送新的記錄通知。

訂閱可提供較快更新，但連線可能中斷，或在服務故障時漏掉資訊。

輪詢較容易復原，因為應用程式可重新查詢已知區塊範圍。

穩健的正式環境系統通常會結合即時訂閱與定期區塊核對。

此方式可讓應用程式發現網路中斷或節點重新啟動期間遺漏的記錄。

官方Ethereum JSON-RPC API 說明文件介紹用於取得上次輪詢後新增記錄的篩選器方法。

事件記錄與鏈重組

鏈重組是指先前被視為有效鏈一部分的區塊，遭另一段區塊歷史取代。

被取代區塊中的記錄不再屬於正典區塊鏈。

若應用程式已立即依據這些記錄採取行動，可能需要撤銷本機資料庫變更。

部分 RPC 訂閱回應可能指出，先前回報的記錄因重組而已移除。

但網路中斷可能導致應用程式收不到移除通知。

可靠的索引器會追蹤區塊雜湊值與父區塊關係，以獨立偵測被取代的區塊。

依區塊雜湊篩選記錄的設計理念說明，應用程式必須謹慎處理重組與連線失敗情況。

金融系統通常應等待適當的確認或最終性門檻，再將事件視為不可逆。

所需門檻取決於區塊鏈、應用程式價值，以及過早採取行動的後果。

事件記錄與最終性

新發出的事件可能先出現在提議區塊中，之後該區塊才達到更高的共識最終性。

若連線用戶端支援，應用程式可使用 latest、safe 或 finalized 等區塊標籤查詢記錄。

latest 標籤提供較快資訊，但可能包含重組風險較高的區塊。

finalized 標籤提供較高確定性，但會增加延遲。

投資組合介面可能接受 latest 事件供畫面顯示；跨鏈橋或大額金融轉帳則可能需要更高確認程度。

應用程式應依經濟風險選擇確認政策，而非對所有事件套用同一規則。

代幣合約中的事件記錄

代幣標準會使用事件記錄，讓錢包與區塊鏈資料系統能查看轉帳與授權。

同質化代幣通常會在資產於地址間轉移時發出 Transfer 事件。

代幣持有者變更其他地址的支出額度時，也可能發出 Approval 事件。

NFT 合約通常會發出包含代幣識別碼的轉移與授權事件。

多代幣合約可發出單筆轉移與批次轉移事件。

標準化事件結構讓外部工具能以相同解碼邏輯支援多種代幣合約。

不過，代幣仍可能發出誤導性事件，或未正確遵循標準。

單一事件無法證明合約合法、具有價值或安全。

去中心化金融中的事件記錄

去中心化金融協議會使用事件記錄描述複雜金融操作。

常見例子包括存款、提領、兌換、貸款、還款、強制平倉、利息更新、領取獎勵及治理變更。

使用者介面可能監控這些事件，以更新餘額與交易紀錄。

分析系統可能彙整事件，計算交易量、流動性、借貸活動或協議營收。

風險監控服務可能監看強制平倉或抵押品事件，以偵測承壓倉位。

一筆 DeFi 交易可能呼叫多個合約，因此收據可能包含許多相關記錄。

應用程式必須考量發出記錄的地址與記錄順序，不能將每個熟悉的事件簽章都視為來自主協議合約。

錢包與區塊鏈瀏覽器中的事件記錄

錢包會利用事件記錄，將原始智能合約交易整理成易讀的歷史紀錄。

代幣轉帳可能不會顯示為交易基本欄位中的原生資產移動。

錢包可解碼代幣合約的 Transfer 事件，顯示資產、寄件者、收件者及金額。

區塊鏈瀏覽器也會使用已驗證合約的 ABI 與已知事件簽章解碼記錄。

若無法取得原始碼或 ABI 資訊，瀏覽器可能只顯示原始主題與資料值。

解碼後的標籤只是對原始記錄的解讀，不是對合約意圖的獨立保證。

使用者應先確認發出事件的合約地址，再相信事件描述。

事件記錄與區塊鏈索引器

區塊鏈索引器會讀取區塊與收據，並將選定的事件資料存入方便查詢的資料庫。

索引器讓難以透過直接 RPC 請求處理的問題更容易查詢。

例如，查詢某錢包的所有代幣轉帳、計算協議活動變化，或追蹤借貸市場中開啟的所有倉位。

索引器通常會從指定區塊開始，依序處理新區塊。

它會解碼相關記錄、建立資料庫資料，並保存處理重組所需的區塊資訊。

索引器應能在故障後恢復，且不會漏掉或重複事件。

解碼架構或應用程式邏輯變更時，也應重新處理歷史資料。

Ethereum 資料與分析說明文件介紹區塊鏈資料系統如何使用記錄、收據、追蹤及其他執行資訊。

事件記錄與鏈下自動化

鏈下服務可監聽事件記錄，並在區塊鏈以外觸發操作。

服務可能在存款後傳送通知、交易後更新內部資料庫，或在治理投票後啟動另一項流程。

事件記錄本身不會強制鏈下服務採取行動。

服務必須維持上線、接收事件、驗證資料並決定後續操作。

鏈下自動化執行敏感操作前，應驗證鏈 ID、合約地址、區塊狀態及解碼值。

系統也應具備冪等性，也就是重複處理同一事件不會造成錯誤的重複結果。

由於重試、重新連線及鏈重組可能使同一記錄被觀察多次，這項防護非常重要。

智能合約能讀取事件記錄嗎？

智能合約無法透過一般 EVM 執行直接搜尋歷史事件記錄。

事件記錄是為外部應用程式設計，而非合約可讀取的狀態。

合約若需要過往事件中的資訊，必須透過其他機制取得。

可用機制包括合約儲存資料、密碼學證明、預言機或跨鏈訊息協議。

合約使用提交的資訊前，必須確認其可信度。

這項限制可避免智能合約自動將鏈下 RPC 回應視為有效鏈上資料。

事件記錄可以修改嗎？

已確認的記錄無法與產生它的交易及區塊分開編輯。

若要變更記錄，就必須取代或使包含該收據的區塊鏈歷史失效。

在達到較高最終性前，鏈重組可能將記錄從有效鏈歷史中移除。

新交易可以發出更正或反向事件，但不會抹除先前的正典記錄。

應用程式應保留歷史事件，並將更正記錄為後續資料，而非默默改寫原始區塊鏈資料。

事件記錄可以偽造嗎？

任何智能合約都能定義並發出名稱與簽章相似的事件。

因此，惡意合約可以發出看起來與合法代幣合約相似的 Transfer 事件。

事件簽章本身無法識別資產，也無法證明可信合約中確實發生餘額變更。

應用程式必須確認發出事件的合約地址，並了解該合約的程式碼與狀態。

詐騙代幣也可能發出誤導性值，或建立事件，讓閒置錢包看似收到資產。

錢包與區塊鏈瀏覽器不應將每個熟悉的事件簽章視為同等可信。

使用者不應只因交易紀錄出現意外轉帳事件，就與該代幣互動。

事件記錄與智能合約安全

事件設計是智能合約安全的一部分，因為監控系統仰賴準確記錄。

權限、費用、預言機地址、升級實作或緊急設定變更等重要管理操作，都應發出清楚事件。

缺少事件可能讓使用者與安全團隊更難發現危險變更。

錯誤的事件值可能導致鏈下系統顯示與合約狀態不符的結果。

合約應在相關檢查與狀態變更成功後，才發出事件。

開發者應測試每條重要執行路徑是否恰好發出預期記錄一次。

也應測試交易回復後，不會留下誤導性的最終記錄。

事件不能取代合約程式碼中的權限與餘額規則。

事件記錄的 Gas 成本

發出事件會消耗 Gas，因為 EVM 必須處理記錄指令並將資訊加入交易收據。

主題越多、資料欄位越大，記錄成本通常越高。

因此，包含多個大型值的事件，成本可能高於精簡事件。

若資訊只供鏈下使用，記錄通常比將同樣資訊寫入永久合約儲存資料便宜。

不過，不必要的記錄仍會增加使用者交易成本與區塊鏈歷史資料量。

開發者應只發出具備索引、監控、稽核或使用者介面實際用途的資訊。

若外部系統不需要，就應避免將每項內部計算都複製到獨立事件。

Gas 最佳化不應移除安全監控協議活動所需的重要透明度。

事件設計最佳做法

事件名稱應清楚描述發生的操作。

參數名稱應明確，讓開發者與分析人員容易理解其意義。

應考慮將使用者經常搜尋的值設為 indexed 參數。

常見 indexed 值包括帳戶地址、代幣識別碼、市場識別碼及提案識別碼。

若不需要直接篩選，金額與詳細設定值通常可留在資料欄位。

除非雜湊篩選確實有用，否則開發者應避免將動態值設為 indexed。

每個事件都應提供足夠脈絡，避免解讀時依賴脆弱的交易順序假設。

支援多種資產或市場的合約，應納入相關資產或市場識別碼。

若有助於監控，升級事件應標示變更前後的值。

若外部應用程式仰賴事件簽章與參數配置，事件宣告就應保持穩定。

讀取事件記錄的最佳做法

應用程式除了依預期事件簽章篩選，也應確認合約地址。

應依照該區塊時有效的合約實作版本，使用正確 ABI 解碼記錄。

可升級合約在實作升級後，可能會變更可用事件。

索引器應儲存區塊雜湊值、區塊編號、交易雜湊值、交易索引及記錄索引。

索引器應依正典區塊順序處理記錄，並支援鏈重組後的回復。

大型歷史查詢應拆分成可管理的區塊範圍。

應用程式應區分真正的空白回應，與請求失敗、截斷或遭限流的回應。

金融操作應等待符合其價值與風險的確認程度。

準確性特別重要時，應用程式應將事件推算值與合約狀態比對。

Layer 2 網路上的事件記錄

以 EVM 為基礎的 Layer 2 網路通常採用與以太坊記錄相似的事件記錄結構。

開發者通常可使用熟悉的 Solidity 事件、主題、ABI 及 JSON-RPC 查詢。

但 Layer 2 系統的區塊時間、確認規則、排序器、費用結構及最終結算流程可能不同。

Layer 2 排序器確認的記錄，可能尚未在以太坊上達到最終結算狀態。

跨鏈轉帳的來源鏈與目的鏈可能在不同階段出現跨鏈橋相關事件。

應用程式必須追蹤正確鏈，不能將不同網路的事件視為同一段共享記錄歷史。

不同鏈上的相同合約地址或事件簽章，可能代表不同合約與資產。

跨鏈轉帳中的事件記錄

跨鏈系統常使用事件表示資產已鎖定、銷毀、釋出或鑄造。

鏈下中繼者或目的鏈協議可能會先觀察來源鏈事件，再繼續轉帳流程。

目的鏈操作必須透過跨鏈橋的證明或驗證者設計，確認來源事件有效。

僅透過一般 RPC 服務商看到記錄，並不足以讓無須信任的智能合約證明事件有效。

跨鏈橋也必須考量來源鏈重組與最終性。

若跨鏈橋過早執行，可能處理到之後從正典來源鏈歷史中移除的事件。

使用者應了解，跨鏈橋事件可能代表轉帳開始，而非最終完成。

事件記錄範例

假設使用者將 500 單位的同質化代幣轉給另一個錢包。

使用者提交一筆呼叫代幣合約 transfer 函式的交易。

合約會檢查寄件者餘額，並更新寄件者與收件者餘額。

接著，合約發出 Transfer 事件，其中包含寄件者地址、收件者地址及轉帳數量。

寄件者與收件者可能存放在 indexed 主題中，數量則以 ABI 編碼後放在資料欄位。

事件簽章雜湊值會出現在 Topic 0。

交易納入區塊後，記錄會出現在交易收據中。

錢包會取得並解碼記錄，以易讀方式顯示交易歷史中的代幣移動。

索引器也會記錄事件，讓使用者能搜尋與任一地址相關的所有轉帳。

此例說明單筆事件記錄如何連結合約執行、錢包、區塊鏈瀏覽器及區塊鏈分析。

使用事件記錄的常見錯誤

常見錯誤之一是以為其他智能合約能讀取事件。

另一個錯誤是將熟悉的事件簽章視為發出事件的合約合法的證明。

第三個錯誤是解碼記錄時未檢查合約地址。

第四個錯誤是以為 indexed 字串能直接從其主題雜湊值還原。

第五個錯誤是只用交易雜湊值識別記錄。

第六個錯誤是未處理鏈重組。

第七個錯誤是在 RPC 重試或應用程式重新啟動後重複處理相同記錄。

第八個錯誤是查詢極大的區塊範圍，並將逾時請求誤認為空白結果。

第九個錯誤是未來智能合約邏輯需要相同資料時，仍只依賴事件。

第十個錯誤是以為事件成功解碼，就能證明所有預定狀態變更都正確發生。

常見問題

加密貨幣中的事件記錄是什麼？

事件記錄是智能合約發出的結構化紀錄，用來描述區塊鏈交易執行期間發生的操作。

Ethereum 事件記錄儲存在哪裡？

Ethereum 事件記錄會納入交易收據，並作為區塊執行歷史的一部分受到承諾。

事件與記錄有何不同？

事件是智能合約程式碼中的宣告；記錄則是事件發出時建立的實際紀錄。

智能合約能讀取舊事件記錄嗎？

不能。智能合約無法透過一般 EVM 執行直接搜尋或讀取歷史記錄。

Ethereum 事件記錄中的 Topic 0 是什麼？

Topic 0 通常包含事件名稱及標準參數類型的 Keccak-256 雜湊值。

事件記錄最多有幾個主題？

EVM 記錄最多有 4 個主題；一般 Solidity 事件通常會保留一個主題存放事件簽章。

Solidity 事件中的 indexed 是什麼意思？

Indexed 參數會存放在主題中，讓外部應用程式可依該值篩選記錄。

事件記錄可以將字串設為 indexed 嗎？

可以，但 indexed 字串會以 Keccak-256 雜湊值表示，而非原始可讀字串。

交易回復時，事件記錄會怎麼處理？

回復執行期間產生的記錄會從最終交易結果中移除。

事件記錄需要 Gas 嗎？

需要。發出記錄會消耗 Gas，費用部分取決於主題數量與資料大小。

事件記錄能證明代幣合法嗎？

不能。任何合約都能發出熟悉的事件，因此使用者必須確認發出事件的合約及其實際狀態。

開發者如何取得事件記錄？

開發者可透過 eth_getLogs、收據查詢、篩選器、訂閱、區塊鏈瀏覽器或索引服務取得記錄。

鏈重組能移除事件記錄嗎？

可以。被取代區塊中的記錄會從正典鏈歷史中移除。

所有 EVM 鏈的事件記錄都相同嗎？

基本結構通常相似，但鏈 ID、合約、區塊歷史、最終性及 RPC 行為可能不同。

事件記錄比合約儲存便宜嗎？

若用於鏈下歷史資訊，記錄通常較便宜；但不能取代未來智能合約執行必須讀取的儲存資料。

錢包為什麼使用事件記錄？

錢包會利用事件記錄識別代幣轉帳、授權、兌換及其他無法單從交易基本欄位判讀的智能合約操作。

結論

事件記錄是連結智能合約執行與錢包、去中心化應用程式、區塊鏈瀏覽器、分析系統及其他鏈下服務的結構化紀錄。

事件記錄透過 EVM 記錄指令建立，交易成功執行後會儲存在交易收據中。

記錄包含發出事件的合約地址、可搜尋主題及 ABI 編碼的事件資料。

Topic 0 通常用於識別事件簽章，而 indexed 參數則提供額外篩選方式。

非 indexed 參數會存放在資料欄位中，須使用正確 ABI 才能解碼。

事件記錄不同於合約儲存資料，因為智能合約無法直接讀取歷史記錄。

事件記錄也不同於函式傳回資料，因為記錄是為鏈下歷史處理而設計，並可供日後查閱。

應用程式可透過 JSON-RPC 篩選器、訂閱、交易收據、區塊鏈瀏覽器及專用索引器取得記錄。

可靠系統必須處理重複處理、RPC 限制、鏈重組、合約升級及不同確認程度。

使用者應記得，熟悉的事件名稱不代表發出事件的合約值得信任，也不代表代幣合法。

開發者應設計名稱清楚、indexed 參數實用、脈絡充分且架構穩定的事件。

了解事件記錄，有助於加密貨幣使用者與開發者更準確地解讀代幣轉帳、DeFi 活動、智能合約變更、交易收據及鏈上應用程式資料。