在上一篇文章中，我們介紹了以太坊節點的固有限制以及它們對開發人員產生的約束，並說明了 dfuse 平臺是如何幫助解決這些問題的。在本文中，我們將重點介紹以太坊上覆雜的交易生命週期；開發者在這些情況下嘗試讓 dapp 提供理想的用戶體驗的挑戰；以及 dfuse 是如何幫助突破這些挑戰的。
每當一筆交易提交到以太坊網絡上時，它會經歷一系列相當複雜的狀態，而並非每個狀態轉換都是向前的——交易可能回滾到較早的狀態、可能被另一個交易替換、還可能完全分叉。 （下文中會詳細描述交易的生命週期。）
在 dapp 中跟蹤交易的進程併爲用戶提供良好的體驗是具有挑戰性的。如今，許多基於以太坊的 dapp 都可以提供吸引人但還是相對靜態的用戶體驗：應用能顯示某個時間點上的交易狀態，但必須通過刷新（點擊刷新或 dapp UI 定期刷新頁面）才能得到信息的更新。市面上有相對更動態的接口，但提供的數據粒度還是不夠細，或者/同時以高網絡流量爲代價，在其底層區塊鏈節點上施加高負載。
接下來我們討論下造成這種情況的原因，以及如何以高效利用網絡和服務器的方式、細粒度的交易狀態更新在 dapp 中提供符合現代標準的、流暢的用戶體驗。
當今的 Dapp 接口
每個 dapp 都需要向用戶顯示正在執行的交易的區塊鏈底層信息——無論是 Ether 轉賬、代幣轉賬還是智能合約調用，而當下的許多 dapp 的界面顯示這些信息的時候顯示的是區塊鏈在單個時間點上的狀態。
用戶在交易過程中經常需要更新信息（例如，知道轉賬什麼時候完成了），因此 dapp 會在界面上放一個 “刷新” 按鍵（或定期自動爲用戶刷新頁面），或者用戶需要直接點擊瀏覽器的刷新按鈕來獲取更新。
有些用戶體驗更成熟的 dapp 會向用戶顯示交易的動態更新。它們會在後臺輪詢 AJAX 請求，重複檢查其以太坊節點是否有更新，然後將更新發布到前端。這麼做是非常複雜的，因爲 dapp 必須進行大量 API 調用，查詢許多不同的數據源（包括區塊、內存池和網絡條件），從而才能從頭到尾的跟蹤交易的生命週期。
這種處理方式會有弊端：要麼交易的更新不頻繁、信息粒度大，導致用戶想去重複點擊“刷新”而去更快地獲取更新；或者 dapp 必須高頻輪詢區塊鏈，從而產生大量網絡流量，在底層區塊鏈節點上施加高負載。
爲什麼不使用基於鏈上事件的接口？
對於 dapp 開發人員，做靜態頁面或輪詢一直是僅可用的兩個選項，這反映了以太坊節點提供的 API 的性質。如果有一個基於鏈上事件的接口，可以接收推送到鏈上的交易狀態更新並實時反饋用戶，dapp 才能提供更好的用戶體驗——而標準的以太坊節點並不提供豐富的實時交易數據。
以太坊節點確實提供了鏈上事件的流讀取功能，但功能有限，只能通過使用以太坊的 JSON-RPC 接口的 PUB/SUB 功能纔可用（在使用 GraphQL 時不可用）。PUB/SUB 接口允許 dapp 接收一些事件類型的通知：
- newHeads——每次新的區塊 header 附加到鏈上
- logs——根據指定的條件過濾匹配包含在新導入的區塊中的日誌
- newPendingTransactions——進入待處理狀態並被節點中可用密鑰簽名的所有交易的哈希（而這種情況在公共節點上很少見）
- syncing——指示節點何時開始或停止同步
（有關詳細信息，請參見此處）
根據這些事件類型獲取信息很受限，dapp 無法通過它們跟蹤交易的完整生命週期。
以太坊交易生命週期
以太坊交易是有複雜的生命週期的。每個交易都會經過多個的 state （狀態），在整個過程中經歷各種 state 的變更，可能前進也可能回滾。
交易狀態
以太坊交易從提交上鍊到（在一定的成功機率下）入塊，它會經歷如下的一系列狀態：
- UNKNOWN （未知）：一個未被網絡檢測到或未被處理的交易被定義爲處於 UNKOWN 狀態。
- PENDING （待處理）：交易在等待礦工揀選和處理，位於我們所稱的 mempool （內存池）中。礦工通常會首先選擇 gas 價格較高的交易，因此 gas 價格較低的交易可能會長期處於 PENDING 狀態。Gas 價格最低的交易可能永遠都不會被選中，那就會導致它們無限期地處於 PENDING 狀態。
- IN_BLOCK（入塊）：當礦工成功選擇交易並將其處理進入區塊，交易將進入IN_BLOCK 狀態。如果交易進入 IN_BLOCK 狀態，但它所在的區塊分叉了，則交易可能回到 PENDING 狀態。
- REPLACED（被替換）：在以下兩種情況下，交易可以從 PENDING 狀態變爲 REPLACED 狀態：
- 另一筆來自同一發送者且有相同 nonce 的交易進入了 IN_BLOCK 狀態，或
- 另一筆來自同一發送者且有相同 nonce 但 gas 價格高出12％的另一筆交易進入了 PENDING 狀態
下圖顯示了這些狀態以及它們之間的過渡。
States（狀態）轉換
如上圖所示，狀態之間的轉換也是有名稱定義的。
- POOLED（入池）：處於 UNKOWN （未知）狀態的交易進入等待礦工選擇的交易池，被稱爲 POOLED 並進入 PENDING （待處理）狀態。處於 REPLACED（被替換）狀態的交易，如果替換條件不再成立（例如：在極少數情況下，處於 IN_BLOCK （入塊）的低 gas 價格的交易被分叉，而替代它且具有相同 nonce 和發送者的交易仍在網絡上游動），則也有可能再次變爲 POOLED 狀態。
- MINED （被挖礦）：被挖礦的交易是由礦工處理過的交易，這過程會創建一個區塊。一旦被挖，交易就被算做處於 IN_BLOCK （入塊）狀態。由於以太坊網絡的點對點性質，從一個指定節點的角度監測，交易可以從 UNKNOWN （未知）狀態直接進入到 IN_BLOCK （入塊）狀態，無需明顯地通過 PENDING （待處理）狀態。出於相同的原因，從一個指定節點的角度監測，交易也可以不通過 PENDING （待處理）狀態而直接從 REPLACED（被替換）狀態轉換爲 IN_BLOCK （入塊）狀態。
- REPLACED（被替換）：從 PENDING （待處理）狀態進入到 REPLACED 狀態的交易也被稱爲 REPLACED。請參見文中交易狀態中列出的 REPLACED 狀態。
- FORKED（被分叉）：當已被挖的交易處於被網絡撤消的區塊中時，就是產生了被分叉的交易。那個區塊內的所有交易將接連被分叉，從 IN_BLOCK （入塊）狀態轉回到 PENDING （待處理）狀態。
- CONFIRMED（已確認）：處於 IN_BLOCK （入塊）狀態的交易會在每次它後續的子區塊被挖時而被確認。
如上所述，以太坊上的交易的生命週期是非常複雜的，這使得 dapp 很難去準確的跟蹤它並向用戶提供無縫式、流暢的更新。
毫不費力地跟蹤交易狀態
dfuse 平臺爲提供了一個豐富的、能夠串流監聽的接口，該接口支持實時詳細跟蹤以太坊交易的生命週期。 dfuse 以太坊交易狀態跟蹤器 API 使開發人員能夠提交以太坊交易，然後在同一數據通道上即刻獲取精細的狀態更新，跟隨交易在其整個生命週期中的進展。
使用 GraphQL，您可以實時監聽指定類型交易的變化，同時可以精確指定每次交易發生變化時您想收到的數據。dfuse 平臺處理了跟蹤交易這項工作的複雜性，並會在事件發生時實時傳輸給 dapp。
這樣一來，您無需撰寫和運行復雜的後臺邏輯和重複進行輪詢，也不會浪費帶寬和多次運行同樣的查詢。簡單地監聽您所需的更新，然後在界面中把這些更新反饋給用戶。
下面的動圖展示的是一個經歷了這種複雜生命週期的交易——它經歷了八個狀態轉換，最後才被包含在區塊中並得到確認。
如果沒有使用 dfuse，dapp 則必須一次次的訪問區塊鏈以捕獲交易經歷的所有轉換再更新給用戶，並且後端代碼需要去準備好應對每個狀態轉換。
使用 dfuse，dapp 僅需要通過單個連接獲取串流更新，dfuse 會爲您跟蹤交易經歷的各種曲變化，直到它的命運被最終確定。
爲先進的 Dapp 提供的現代化平臺
Lifecycle （生命週期） API 只是 dfuse 平臺的重要的一小部分。dfuse 爲 dapp 提供了完整的現代化基礎架構層，即：
- 快速，
- 可擴展，
- 提供對區塊鏈事件的高度精細的串流監聽，
- 支持主動的 Webhook 形式的回調，
- 具有業內最高的可靠性。
立即試用 dfuse。如有任何疑問/建議，請在微信或 Telegram 上與我們聯繫，跟我們分享下您構建以太坊 dapp 的經驗——我們也很想知道您是否對我們所提供的服務感到滿意。
