來源 | CSDN 部落格
責編| Carol
出品 | 區塊鏈大本營（blockchain_camp)
去中心化應用程式（Dapp）被廣泛認為是可以為像銀行業（Di-Fi）和遊戲業等領域帶來顛覆性創新的。但是，即使是最有創新性的解決方案，如果不能滿足消費者的期望，也不會被認可。
消費者需要的是流暢和成熟的使用者體驗，而實現這個目標對以太坊的 Dapp 開發者來說又是一個重大挑戰。
本文將概述典型的 Dapp 架構，並指出當今標準以太坊堆疊的一些固有侷限性，正是這些侷限性導致開發者難以打造出能有說服力使用者體驗。接著會介紹下以太坊基礎設施領域中的一些能幫助開發者克服這些挑戰的創新。
經典的以太坊 Dapp 架構
一般來說，以太坊上的 Dapp 包含三個主要部分：
智慧合約，通常以 Solidity 編寫，使用 Truffle Suite 等框架構建並部署在以太坊區塊鏈上。
前端程式碼，用 Java 編寫的。
後端——一般是用標準的以太坊區塊鏈節點。前端與後端的通訊一般是使用節點提供的 JSON-RPC 或 GraphQL API。
還有各種促進前端與 Eth 節點的通訊的庫，其中最受歡迎的是 web3.js 和 ethers.js。也還有許多其他語言（Java，Python，Rust…）的 web3 庫。
自建後端節點
在以太坊的早期，開發者必須運營自己的以太坊節點。Dapp 釋出了以後，他們還必須運營生產級別的節點（或節點叢集）。運營區塊鏈節點這項工作繁重，也會對開發者的效率造成負擔。
節點服務（NaaS）提供商
上述的這個挑戰促成了一些例如 Infura，以及相對新的 Nodesmith、Quiknode、Blockdaemon、Ethernode、Chainstack、Alchemy、CloudFlare 等公司的 “節點服務” 平臺的興起。
這些平臺為開發者提供了基於雲端的以太坊節點，從而節省了開發者運營節點的精力。用於開發和生產的解決方案。這些平臺可為開發者分擔基層作業系統和節點軟體本身的系統管理，例如補丁和更新。
以太坊節點的固有侷限性
即使節點服務能成功地替代開發者擔任系統管理員的職責，它無法幫助開發者實現的使用者體驗去構建更好的 Dapp，這是因為來自節點服務的架構以及以太坊節點支援的 JSON-RPC 和 GraphQL 介面的固有侷限性。
主要的侷限性包括：
1、觀測到的 state 資訊不一致
為了擴充套件到單個節點的容量之上同時提供更高的可靠性，作為服務平臺的節點是透過負載平衡器提供對節點池的訪問的。
由於這些節點中是都作為以太坊網路中的對等節點自主執行的，因此當資訊在透過網路傳播的某一個時刻，不同的節點可能處於不同的區塊高度上，甚至處於不同的分叉上。這意味著 Dapp 可能收到區塊鏈狀態的資訊是不一致的，因為它的請求獲得的結果是由負載均衡器背後的不同節點提供的。
節點服務平臺通常試圖透過負載平衡器上的會話粘性來解決此問題，總是會去嘗試將指定前端的查詢傳送到同一個後端節點，但是這種方法在多種情況下會失敗：
當前端產生的請求多於單個後端節點能負擔的處理量時；
當網路問題導致前端與後端斷開連線時，而且必須重新連線；
多個節點服務平臺會將不同型別的前端請求（例如，傳送交易或搜尋鏈歷史記錄）路由到針對該查詢型別最佳化的不同後端節點組。
那麼由於前端經常訪問多個後端節點，而這些後端節點獲取的區塊鏈狀態與彼此不一致，因此 Dapp 很難處理鏈重組。向後追溯鏈歷史的時候，Dapp 可能突然發現它想找的父區塊不存在了（原因是它現在正在與在不同分叉上的另一個節點互動）。那麼 Dapp 開發者就不得不去專門寫程式碼來解決這個問題（方法通常是透過反覆地重連，直到它找到一個節點）。這樣給 Dapp 增加了不必要的複雜性，並且可能導致呈現給使用者的資訊有出入。
2、在區塊鏈上搜尋資訊很慢、有侷限性
Dapp 搜尋交易或鏈上歷史的能力受限，因為標準以太坊節點不適合支援精確搜尋或執行實時資料的篩選式監聽。想要以高效能的方式進行操作，我們需要對數百萬個區塊和交易做大量的索引，但是：
以太坊節點僅索引交易執行發出的日誌中的某些欄位（要索引的欄位必須在部署合約時由開發者標記出來）
以太坊節點不索引內部交易（當智慧合約呼叫另一合約的方法時發生）的資料
開發者不願意新增額外的索引欄位，因為每多一個索引欄位每個交易的成本都會相對增加，會給合約的使用者帶來額外的費用
以太坊節點使用 Bloom 過濾器執行搜尋，因此它始終是模糊搜尋，並且會產生偽陽性的匹配。精確匹配需要前端進行額外的處理，前端必須獲取模糊匹配的整個區塊或交易，對其再次檢索而找到精確匹配的結果。這不僅需要開發者的精力，而且浪費了前端和節點之間的頻寬
可用的搜尋語法非常有限——僅支援基本的選擇以及簡單的替換
獲取搜尋結果的速度很慢——在大範圍的區塊中執行搜尋可能需要幾個小時
JSON-RPC 非常浪費頻寬——返回的資料遠遠超出你所真正所需。GraphQL 介面使用的頻寬較少，但不提供串流傳輸功能（前端必須進行輪詢更新）
3、缺乏原子性
在大多數現代環境中，例如關聯式資料庫，交易一般是原子操作，但在以太坊（或其他區塊鏈）上不是。每個交易都會經過一系列狀態的轉換，在這個過程中可能遇到多種問題或失敗。Dapp 必須呼叫多個 API，查詢許多不同的資料來源（區塊、mempool、網路狀態）以便跟蹤交易的生命週期，直至其完成。
同樣，這個負擔就落在了前端程式碼上，透過重複輪詢來弄清楚具體發生了什麼，而 Dapp 的使用者會因為 Dapp 執行所有這些額外的工作而經歷延遲和需要重新整理。
4、節點是被動的
以太坊節點是被動的，這意味著它們無法生成事件或回撥和呼叫 Webhooks。所有操作必須由前端來啟動，而前端還必須輪詢節點以獲得更新的資訊。以太坊節點的事件串流讀取功能太有限，無法滿足大多數 Dapp 的需求，並且僅在 JSON-RPC 介面中可用，在 GraphQL 介面上不可用。
重新思考 Dapp 的基礎架構
dfuse 提供的是一個更高階別的區塊鏈 API 的平臺，與區塊鏈節點提供的原生 API 相比，它們可以更輕鬆地完成更多的工作。是為了賦予 Dapp 開發者所需的功能，使其能夠透過快速、流暢的介面構建現代區塊鏈應用程式，從而提供出色的使用者體驗的基礎上而設計的。
希望能透過平臺，解決上述所有限制，打破傳統以太坊節點的侷限性。
1、有一致性的檢視
dfuse 是一個整合的超大規模資料平臺，而不是在負載均衡器上的多個以太坊節點合集。dfuse 平臺在所有連線上、所有時間點上提供鏈的 state 資訊。要麼是看到一個區塊（同時偵測到鏈的分叉和重組），要麼根本不去報告該區塊（在區塊經歷迅速重組並傳播不遠的情況下）。
這樣 Dapp 永遠不會面對一個不一致的鏈狀態檢視，並且可以專注在它的主要功能上，不是去忙著驗證區塊鏈的細節。
2、高速、細粒化的搜尋
使 Dapp 開發者能夠以極細化的顆粒度、非凡的速度和效率來搜尋區塊鏈的歷史記錄，還能透過GraphQL、gRPC 和 Websocket 介面實現實時篩選，串流讀取。
完全索引所有的 Log 欄位——每個交易在 Log 中發出的所有資料都直接適用於高精度搜尋。
完全索引所有內部交易（傳送者、接收者、值、方法、輸入引數），從而在整個呼叫的樹型結構中全面跟蹤合約的操作
索引不會給你的使用者帶來任何額外的 gas 費用——dfuse 的索引是 dfuse 平臺的一項整合功能，不會增加合約執行的資源成本
搜尋找到的是完全匹配的結果，而不是模糊搜尋的結果。無需編寫額外的前端程式碼來重複檢驗搜尋結果，也不用浪費頻寬去批次獲取不需要的資料
提供了一種結構化的查詢語言，類似於 Kibana 或 GitHub 的查詢語言，具有完整的 boolean 操作和直接深入你想找的具體交易或命令的能力
提供出色的效能——可以在不到一秒鐘的時間，按照指定的搜尋條件，搜尋全鏈歷史記錄，找到一組完全匹配的項
透過 GraphQL 能提供簡潔的響應，但又不犧牲串流功能，兩全其美——我們的 GraphQL 介面提供了完整的實時過濾搜尋，可為使用者有效地提供動態更新
無論以太坊網路上的流量如何，效能都是保持一致的
3、原子操作
提供了一個串流讀取端點，該端點了解交易可能進入的所有複雜狀態，並在其滿足最終性時通知你。無需去費力地透過重複輪詢或檢查多個資料來源去跟蹤交易的狀態，你只需要把交易推送上去並保持連線即可接收實時狀態更新，從而也可以向你的使用者提供交易的實時狀態。
4、有主動性的後端
一個好的平臺會為您提供了一個可以啟動事件的主動後端。比如，可以根據你指定的精確標準（透過上述的搜尋以及其他功能）呼叫你所選擇的 lambda 函式（或雲函式）。這讓 Dapp 實現了非同步的體系結構，資料更新可以透過多個通訊渠道流暢、實時地釋出給使用者。
5、一個為尖端 Dapp 打造的現代平臺
dfuse 為你的 Dapp 提供了一個現代化的基礎架構層，即：
快速
可擴充套件
提供對區塊鏈事件的高精度，細粒化的實時訪問
支援主動的 Webhook 形式的回撥
支援原子操作
具有業內最高的可靠性
所以，在以太坊上開發 Dapp遇到以上問題時，可以嘗試用不同的工具解決問題，只有在經歷了產品打磨和使用者培養後，才能促使更多精緻、實用、成熟的 Dapps 面世。
