在以太坊上開發Dapp的瓶頸和門檻有哪些？
編者按：本文來自區塊鏈大本營（ID：blockchain_camp）編者按：本文來自
區塊鏈大本營（ID：blockchain_camp）
區塊鏈大本營（ID：blockchain_camp）
區塊鏈大本營（ID：blockchain_camp）
區塊鏈大本營（ID：blockchain_camp）
區塊鏈大本營（ID：blockchain_camp）
二級標題
區塊鏈大本營（ID：blockchain_camp）
去中心化應用程序（Dapp）被廣泛認為是可以為像銀行業（Di-Fi）和遊戲業等領域帶來顛覆性創新的。但是，即使是最有創新性的解決方案，如果不能滿足消費者的期望，也不會被認可。
消費者需要的是流暢和成熟的用戶體驗，而實現這個目標對以太坊的Dapp 開發者來說又是一個重大挑戰。
經典的以太坊Dapp 架構
二級標題
一般來說，以太坊上的Dapp 包含三個主要部分：
前端代碼，用Java 編寫的。
後端——一般是用標準的以太坊區塊鏈節點。前端與後端的通信一般是使用節點提供的JSON-RPC 或GraphQL API。
二級標題
自建後端節點
二級標題
在以太坊的早期，開發者必須運營自己的以太坊節點。 Dapp 發布了以後，他們還必須運營生產級別的節點（或節點集群）。運營區塊鏈節點這項工作繁重，也會對開發者的效率造成負擔。
二級標題
主要的局限性包括：
上述的這個挑戰促成了一些例如Infura，以及相對新的Nodesmith、Quiknode、Blockdaemon、Ethernode、Chainstack、Alchemy、CloudFlare 等公司的“節點服務” 平台的興起。
這些平台為開發者提供了基於雲端的以太坊節點，從而節省了開發者運營節點的精力。用於開發和生產的解決方案。這些平台可為開發者分擔基層操作系統和節點軟件本身的系統管理，例如補丁和更新。
二級標題
以太坊節點的固有局限性
即使節點服務能成功地替代開發者擔任系統管理員的職責，它無法幫助開發者實現的用戶體驗去構建更好的Dapp，這是因為來自節點服務的架構以及以太坊節點支持的JSON-RPC 和GraphQL 接口的固有局限性。
主要的局限性包括：
1、觀測到的state 信息不一致
為了擴展到單個節點的容量之上同時提供更高的可靠性，作為服務平台的節點是通過負載平衡器提供對節點池的訪問的。
由於這些節點中是都作為以太坊網絡中的對等節點自主運行的，因此當信息在通過網絡傳播的某一個時刻，不同的節點可能處於不同的區塊高度上，甚至處於不同的分叉上。這意味著Dapp 可能收到區塊鏈狀態的信息是不一致的，因為它的請求獲得的結果是由負載均衡器背後的不同節點提供的。
節點服務平台通常試圖通過負載平衡器上的會話粘性來解決此問題，總是會去嘗試將指定前端的查詢發送到同一個後端節點，但是這種方法在多種情況下會失敗：
當前端產生的請求多於單個後端節點能負擔的處理量時；
當網絡問題導致前端與後端斷開連接時，而且必須重新連接；
多個節點服務平台會將不同類型的前端請求（例如，發送交易或搜索鏈歷史記錄）路由到針對該查詢類型優化的不同後端節點組。
那麼由於前端經常訪問多個後端節點，而這些後端節點獲取的區塊鏈狀態與彼此不一致，因此Dapp 很難處理鏈重組。向後追溯鏈歷史的時候，Dapp 可能突然發現它想找的父區塊不存在了（原因是它現在正在與在不同分叉上的另一個節點交互）。那麼Dapp 開發者就不得不去專門寫代碼來解決這個問題（方法通常是通過反复地重連，直到它找到一個節點）。這樣給Dapp 增加了不必要的複雜性，並且可能導致呈現給用戶的信息有出入。
2、在區塊鏈上搜索信息很慢、有局限性
Dapp 搜索交易或鏈上歷史的能力受限，因為標準以太坊節點不適合支持精確搜索或執行實時數據的篩選式監聽。想要以高性能的方式進行操作，我們需要對數百萬個區塊和交易做大量的索引，但是：
以太坊節點不索引內部交易（當智能合約調用另一合約的方法時發生）的數據
3、缺乏原子性
以太坊節點使用Bloom 過濾器執行搜索，因此它始終是模糊搜索，並且會產生偽陽性的匹配。精確匹配需要前端進行額外的處理，前端必須獲取模糊匹配的整個區塊或交易，對其再次檢索而找到精確匹配的結果。這不僅需要開發者的精力，而且浪費了前端和節點之間的帶寬
可用的搜索語法非常有限——僅支持基本的選擇以及簡單的替換
JSON-RPC 非常浪費帶寬——返回的數據遠遠超出你所真正所需。 GraphQL 接口使用的帶寬較少，但不提供串流傳輸功能（前端必須進行輪詢更新）
二級標題
3、缺乏原子性
同樣，這個負擔就落在了前端代碼上，通過重複輪詢來弄清楚具體發生了什麼，而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 平台的一項集成功能，不會增加合約執行的資源成本
3、原子操作
搜索找到的是完全匹配的結果，而不是模糊搜索的結果。無需編寫額外的前端代碼來重複檢驗搜索結果，也不用浪費帶寬去批量獲取不需要的數據
提供出色的性能——可以在不到一秒鐘的時間，按照指定的搜索條件，搜索全鏈歷史記錄，找到一組完全匹配的項
快速
通過GraphQL 能提供簡潔的響應，但又不犧牲串流功能，兩全其美——我們的GraphQL 界面提供了完整的實時過濾搜索，可為用戶有效地提供動態更新
3、原子操作
快速
提供了一個串流讀取端點，該端點了解交易可能進入的所有復雜狀態，並在其滿足最終性時通知你。無需去費力地通過重複輪詢或檢查多個數據源去跟踪交易的狀態，你只需要把交易推送上去並保持連接即可接收實時狀態更新，從而也可以向你的用戶提供交易的實時狀態。
一個好的平台會為您提供了一個可以啟動事件的主動後端。比如，可以根據你指定的精確標準（通過上述的搜索以及其他功能）調用你所選擇的lambda 函數（或云函數）。這讓Dapp 實現了異步的體系結構，數據更新可以通過多個通信渠道流暢、實時地發布給用戶。
快速
